INT144 — Agile & Scrum

1. Agile Principles และแนวคิดที่นำมาสู่ Scrum

อ้างอิง: 2026-INT144-01-Agile Principles and Scrum Concepts.pdf หน้า 7–39

Agile เป็นแนวคิดพัฒนาซอฟต์แวร์ที่เน้นส่งมอบคุณค่า เรียนรู้จากผลที่เกิดขึ้นจริง แล้วปรับวิธีทำงานและสิ่งที่จะสร้างให้เหมาะกับสถานการณ์ เหตุผลคือความต้องการ ความเข้าใจทางเทคนิค และสภาพธุรกิจเปลี่ยนได้ การวางแผนทุกอย่างอย่างละเอียดตั้งแต่ต้นจึงไม่ได้ทำให้อนาคตแน่นอนขึ้นเสมอไป การทำงานเป็นรอบสั้นช่วยให้เห็นความผิดพลาดเร็วและเปลี่ยนทิศได้ขณะที่ต้นทุนยังไม่สูง

Iterative ต่างจาก Incremental อย่างไร

Iterative Development คือการกลับมาพัฒนาและปรับสิ่งที่มีให้ดีขึ้นเป็นรอบ ๆ เช่นสร้างการค้นหาแบบง่ายก่อน แล้วใช้ Feedback ปรับความแม่นยำและหน้าจอ ส่วน Incremental Development คือการเพิ่มส่วนของความสามารถที่ใช้งานได้ เช่นรอบแรกค้นหาสินค้าได้ รอบต่อมาเพิ่มการสั่งซื้อ แล้วเพิ่มการชำระเงิน ทั้งสองแนวคิดใช้ร่วมกันได้: เพิ่มความสามารถพร้อมปรับคุณภาพของสิ่งเดิม

Stepwise Refinement หมายถึงค่อย ๆ เพิ่มรายละเอียด โดยให้ความสำคัญกับสิ่งที่จำเป็นในขณะนั้น ไม่ใช่ทำทุกเรื่องให้ละเอียดเท่ากันตั้งแต่แรก หากยังไม่รู้ว่าลูกค้าต้องการอะไร การลงรายละเอียดหน้าจอทั้งหมดอาจสร้างงานที่ต้องทิ้ง ควรทำส่วนสำคัญให้เห็นผลแล้วใช้ความรู้นั้นตัดสินใจรอบถัดไป

Agile Manifesto: ให้คุณค่าสิ่งใดมากกว่า

Agile Manifesto มีสี่คู่คุณค่า คำว่า over แปลว่าให้ฝั่งซ้ายสำคัญกว่าเมื่อเกิดข้อขัดแย้ง ไม่ได้หมายความว่าฝั่งขวาไม่มีคุณค่าหรือห้ามใช้

ตัวอย่างเช่น ทีมมีเอกสารครบและทำงานตรงแผน แต่ผู้ใช้ยังทำงานหลักไม่ได้ จึงยังไม่ควรถือว่าบรรลุเป้าหมาย Agile ในทางกลับกัน การไม่เขียนเอกสารเลยจนคนดูแลระบบต่อไม่ได้ ก็ไม่ใช่ข้อสรุปที่ Manifesto สนับสนุน

หลักการ Agile ทั้ง 12 ข้อ พร้อมเหตุผล

สไลด์เรียงหลักการตามลำดับของการอธิบาย เนื้อหาด้านล่างคงครบทั้ง 12 ข้อและใช้คำอธิบายเชื่อมกับการทำงานจริง

1. Customer satisfaction through early and continuous delivery: ให้ลูกค้าได้รับซอฟต์แวร์ที่มีคุณค่าตั้งแต่ช่วงต้นและรับเพิ่มอย่างต่อเนื่อง สิ่งสำคัญคือคุณค่าที่ใช้ได้ ไม่ใช่เพียงส่งงานให้ตรงจำนวนครั้ง
2. Frequent delivery: ส่ง Working Software บ่อย โดยเลือกช่วงเวลาสั้นเมื่อทำได้ จะได้ตรวจความเข้าใจและปัญหาเร็ว แทนรอส่งทั้งหมดตอนท้าย
3. Welcome changing requirements: ยอมรับความต้องการที่เปลี่ยน แม้พัฒนาไปแล้ว เพื่อให้ผลิตภัณฑ์ยังสร้างความได้เปรียบแก่ลูกค้า แต่ต้องจัดลำดับและปรับงานอย่างมีเหตุผล ไม่ใช่เพิ่มงานทุกชิ้นทันทีโดยไม่สนข้อจำกัด
4. Business and developers work together daily: คนที่เข้าใจธุรกิจและคนสร้างระบบต้องร่วมกันตลอดโครงการ ลดการเดาความต้องการผ่านเอกสารอย่างเดียว
5. Motivated individuals, support and trust: ให้คนที่มีแรงจูงใจได้รับสภาพแวดล้อม เครื่องมือ และการสนับสนุนที่จำเป็น แล้วเชื่อใจให้รับผิดชอบงาน ไม่ควบคุมทุกขั้นจนทีมตัดสินใจเองไม่ได้
6. Face-to-face conversation: การพูดคุยโดยตรงส่งบริบทและถามกลับได้เร็ว สไลด์เน้นประสิทธิภาพของช่องทางนี้ เหตุผลคือการลดความเข้าใจคลาดเคลื่อน ไม่ใช่การประชุมให้มากที่สุด
7. Self-organizing teams: Architecture, Requirements และ Design ที่ดีเกิดจากทีมที่ร่วมจัดการงานและใช้ความรู้ของสมาชิก ไม่รอคำสั่งทางเทคนิคทุกอย่างจากคนคนเดียว
8. Technical excellence and good design: การดูแลโค้ด การทดสอบ และ Design ทำให้เปลี่ยนระบบได้ง่าย ความคล่องตัวจึงต้องมีความสามารถทางวิศวกรรมรองรับ
9. Simplicity: ทำงานที่จำเป็นต่อคุณค่าจริง และลดงานที่ไม่จำเป็น การทำ Feature ที่ไม่มีใครใช้แม้เขียนได้เร็ว ก็ยังเป็นงานสูญเปล่า
10. Working software as progress: ใช้ซอฟต์แวร์ที่ทำงานได้เป็นตัววัดหลัก แทนจำนวนเอกสารหรือเปอร์เซ็นต์การเขียนโค้ดที่ยังไม่ผ่านการทดสอบ
11. Sustainable development: รักษาจังหวะทำงานที่ผู้สนับสนุน Developers และผู้ใช้ร่วมกันทำต่อเนื่องได้ ไม่อาศัยการเร่งหนักและทำงานเกินกำลังทุก Sprint
12. Reflect and adjust regularly: หยุดทบทวนเป็นระยะว่าวิธีทำงานได้ผลหรือไม่ แล้วปรับพฤติกรรมจริง การประชุมสะท้อนปัญหาแต่ไม่เปลี่ยนอะไรยังไม่ครบหลักการ

Timeboxing, Just-in-time และการพัฒนาเป็น Feature

Timebox คือกรอบเวลาที่มีจุดสิ้นสุดแน่นอน เช่นตกลง Sprint สองสัปดาห์แล้วไม่ยืดเพราะงานยังไม่เสร็จ สิ่งที่ทำคือเลือกขนาดงานให้เหมาะและเรียนรู้จากผล เพื่อวางแผนรอบต่อไปได้ดีขึ้น Just-in-time (JIT) คือเตรียมรายละเอียดเมื่อใกล้ใช้จริง โดยยังมีภาพรวมล่วงหน้า ไม่ใช่เริ่มงานโดยไม่มีเป้าหมาย

ภาพ DSDM ในสไลด์เปรียบเทียบ Traditional Approach ที่ตรึง Features แล้วให้เวลาและต้นทุนเปลี่ยน กับแนวทางที่ตรึงเวลา ต้นทุน และคุณภาพ แล้วปรับขอบเขต Features ให้เหมาะสม ความหมายคือไม่ใช้การลดคุณภาพเป็นตัวแก้ทุกปัญหา และไม่ถือว่าทุก Feature ต้องเป็น Must have

การสร้าง Feature by Feature หมายถึงทำความสามารถที่ผู้ใช้เห็นผลได้ให้ครบทางผ่าน เช่นค้นหาสินค้าพร้อมส่วนหน้าจอ การประมวลผล และการทดสอบ แทนทำฐานข้อมูลทั้งระบบให้เสร็จ แล้วทำ Backend ทั้งระบบ แล้วค่อย Frontend เพราะการแยกเป็นชั้นใหญ่แบบนั้นยังไม่ทำให้ผู้ใช้ใช้ Feature ใดได้เร็ว

Fast Feedback และภาพรวมแนวทาง Agile

Heart of Agile ในสไลด์ใช้วงจร Collaborate → Deliver → Reflect → Improve: ร่วมกันสร้างความคิด ส่งสิ่งเล็ก ๆ เพื่อทดสอบกับโลกจริง คิดทบทวนสิ่งที่เรียนรู้ แล้วปรับทั้งแนวทางผลิตภัณฑ์ เทคนิค และกระบวนการ จุดเชื่อมคือ Feedback ที่มาเร็วพอให้เปลี่ยนสิ่งที่ยังแก้ได้

Scrum คือ Framework สำหรับงานซับซ้อน

Scrum เป็น Framework ที่มีองค์ประกอบและกติกาหลักให้ทีมใช้รับมือปัญหาซับซ้อนที่เปลี่ยนได้ ไม่ใช่รายการขั้นตอนละเอียดที่บอกวิธีแก้ทุกปัญหา สไลด์อธิบายว่า Lightweight, Simple to understand และ Difficult to master: กติกาไม่มากแต่การใช้ให้เกิดคุณค่าต้องอาศัยวินัยและการเรียนรู้

ที่มาของแนวคิดเปรียบเทียบ Relay Race ซึ่งแต่ละฝ่ายส่งไม้ต่อเป็นช่วง กับ Rugby Approach ที่ทีมเคลื่อนเป็นหน่วยเดียว ส่งข้อมูลกลับไปมาและช่วยกันจนถึงเป้าหมาย หลักในงานต้นทางมี Built-in instability, Self-organizing project teams, Overlapping development phases, Multilearning, Subtle control และ Organizational transfer of learning โดยเน้นความยืดหยุ่น การเรียนรู้หลายด้าน และการถ่ายทอดความรู้ไปยังองค์กร

ในลักษณะทั้งหก Built-in instability คือสร้างโจทย์หรือความท้าทายให้ทีมต้องแสวงหาวิธีใหม่ Self-organizing project teams คือทีมจัดวิธีทำงานร่วมกัน Overlapping development phases คือกิจกรรมหลายด้านประสานและย้อน Feedback กันได้ Multilearning คือเรียนรู้หลายระดับและหลายหน้าที่ Subtle control คือมีทิศทางและการควบคุมโดยไม่สั่งทุกขั้น และ Organizational transfer of learning คือส่งต่อความรู้จากทีมสู่องค์กร แนวคิดเหล่านี้อธิบายที่มาของการเคลื่อนร่วมกัน ไม่ใช่รายการ Events เพิ่มของ Scrum

Empirical Process Control และเสาหลักสามต้น

Empiricism คือสร้างความรู้จากประสบการณ์ การสังเกต และการทดลอง แล้วตัดสินใจด้วยสิ่งที่รู้จริง แทนสมมติว่าการคาดการณ์ตั้งแต่ต้นถูกเสมอ Scrum ใช้เสาหลักสามต้นที่ต้องทำงานร่วมกัน

Transparency ไม่เท่ากับมี Board ที่สวยแต่สถานะไม่จริง Inspection ไม่เท่ากับตรวจถี่จนรบกวนงาน และ Adaptation ไม่เท่ากับเปลี่ยนไปเรื่อยโดยไม่ใช้ข้อมูล ถ้าไม่มีมาตรฐานร่วม การตรวจย่อมแปลผลต่างกัน ถ้าตรวจแล้วไม่ปรับ ก็ยังไม่ปิดวงจรเรียนรู้

2. Scrum Overview: ทีม แผน และ Events ทำงานร่วมกันอย่างไร

อ้างอิง: 2026-INT144-02-Scrum Overview.pdf หน้า 5–41 และรายละเอียดทีมจากไฟล์ 05 หน้า 18–22

Scrum Phases ในแบบจำลองที่สไลด์นำมาใช้

สไลด์แสดงภาพ Scrum ยุคต้นเป็น Pre-game → Game → Post-game ควรเข้าใจเป็นโมเดลอธิบายภาพรวมในเอกสาร ไม่ใช้สามคำนี้แทนรายการ Scrum Events ที่จะเรียนต่อ เพราะเป็นการจัดคนละระดับ

Pre-game: Planning เตรียมทีม Backlog ขอบเขต Release ประมาณเวลาและต้นทุน พร้อมประเมินความเสี่ยง ส่วน Architecture วิเคราะห์ Domain และปรับ Architecture/High-level Design เท่าที่จำเป็นกับบริบทใหม่ จึงไม่ใช่ข้อสรุปว่าต้อง Design รายละเอียดทุกอย่างให้เสร็จก่อนสร้างงาน

Game: Development Sprints พัฒนาความสามารถเป็นรอบ ๆ โดยรักษาสมดุลเวลา Requirements คุณภาพ ต้นทุน และการแข่งขัน ส่วนนี้อาศัย Empirical Process เพราะรู้รายละเอียดทั้งหมดล่วงหน้าไม่ได้ จึงมีการตรวจและควบคุมความเสี่ยงแต่ละรอบเพื่อไม่ให้ความยืดหยุ่นกลายเป็นความไร้ระเบียบ ในภาพมี Develop, Wrap, Review และ Adjust วนอยู่ใน Sprints

Post-game: Closure เตรียมผลิตภัณฑ์ออกใช้ทั่วไป เช่น Integration, System Test, User Documentation, Training Material และ Marketing Material การที่โมเดลเก่าแสดงกิจกรรมเหล่านี้ท้ายภาพ ไม่ใช่เหตุให้รอทดสอบหรือ Integration ทั้งหมดจนจบโครงการ ในเนื้อหา Sprint ต่อมาระบุชัดว่าต้องมี Increment ที่ผ่าน Definition of Done ทุก Sprint

Responsibility และ Accountability

Responsibility คือหน้าที่หรือสิ่งที่ต้องลงมือทำ เช่นรับหน้าที่เขียนการทดสอบ ส่วน Accountability คือความเป็นเจ้าของผลลัพธ์และต้องตอบได้ว่าเกิดผลอย่างไร การแบ่ง Task ไม่ได้แปลว่าผลลัพธ์ส่วนรวมไม่มีเจ้าของ

สไลด์ยกตัวอย่างทั่วไปว่า Accountability มักอยู่กับผู้รับผิดผลสุดท้ายคนหนึ่ง แต่ใน Scrum มีทั้ง Accountability เฉพาะของ Product Owner, Scrum Master และ Developers และความรับผิดผลร่วมของ Scrum Team ต่อ Increment ทุก Sprint จึงไม่ควรจำว่า Accountability ห้ามมีร่วมกันทุกกรณี

Scrum Team และสาม Accountabilities

Scrum Team ประกอบด้วย Product Owner หนึ่งคน, Scrum Master หนึ่งคน และ Developers เป็นทีมเดียวที่ไม่มี Sub-teams หรือ Hierarchies ภายในตามนิยาม Scrum ในสไลด์ ไม่ใช่ PO เป็นหัวหน้าสั่งงานผ่าน SM ลงไปหา Developers

Cross-functional หมายถึงเมื่อรวมทักษะของสมาชิกแล้ว ทีมมีสิ่งที่ต้องใช้เพื่อสร้างคุณค่า ไม่ได้หมายความว่าทุกคนต้องเก่งทุกอย่างเท่ากัน Self-managing หมายถึงทีมตัดสินใจภายในว่าใครทำอะไร เมื่อใด และอย่างไร ภายใต้เป้าหมายและกติกา ไม่ใช่แต่ละคนเลือกทำตามใจโดยไม่สนทีม

วางแผนหลายระดับ แทนลงรายละเอียดทั้งหมดตั้งแต่วันแรก

Detailed Up-front Planning มีความเสี่ยงจากข้อมูลไม่ครบ มุมมองต่างกัน และเหตุการณ์ที่คาดไม่ถึง หากลงรายละเอียดไกลเกินไปอาจต้องทิ้งงาน ใช้เวลาแก้แผน และเสียโอกาสส่งสิ่งมีคุณค่า อีกปัญหาคือคนยึดแผนแม้สถานการณ์เปลี่ยนแล้ว

คำตอบในสไลด์คือรักษาสมดุล Up-front + Just-in-time มีทิศทางใหญ่ก่อน แล้วค่อยเพิ่มรายละเอียดเมื่อใกล้ลงมือ ภาพ Multilevel Planning ไล่ Strategy, Portfolio, Product, Release, Sprint และ Daily อีกภาพใช้ Vision, Roadmap, Release, Sprint และ Daily: ทั้งสองสื่อว่าระดับใกล้ปัจจุบันต้องละเอียดกว่าและปรับได้จากการเรียนรู้

Vision อธิบายภาพที่อยากไปถึง Roadmap แสดงแนวทางกว้างของผลิตภัณฑ์ Release Plan วางเป้าหมายชุดที่จะนำออกใช้ Sprint Plan เลือกสิ่งที่จะทำในรอบนี้ และ Daily Planning ปรับการทำงานจากสิ่งที่พบแต่ละวัน ระดับเหล่านี้เชื่อมกัน แต่ไม่ได้เป็นการตรึงรายละเอียดทุกระดับล่วงหน้า

Product Backlog, Sprint Backlog และ Increment

Product Backlog เป็นรายการงานสำหรับผลิตภัณฑ์ทั้งหมดที่รู้ว่าจำเป็น เรียงลำดับและเปลี่ยนได้ต่อเนื่อง ส่วน Sprint Backlog คือ PBIs ที่เลือกสำหรับ Sprint พร้อมแผนทำงานเพื่อบรรลุ Sprint Goal เป็นแผนของ Developers ขอบเขตจึงเล็กกว่า Product Backlog และปรับได้ขณะทำงาน

Increment เป็นส่วนเพิ่มของผลิตภัณฑ์ที่ใช้งานได้และรวมเข้ากับสิ่งเดิมได้ ไม่ใช่จำนวน Task ที่ปิด ถ้าสร้างหน้าจอแล้วแต่ข้อมูลไม่ทำงานและยังไม่ผ่านคุณภาพที่ตกลง ย่อมยังไม่เป็น Increment ที่ Done ตามความหมายนั้น เป้าหมายของทีมคือแปลงงานที่เลือกให้เป็นคุณค่าจริง

ลำดับ Events ภายใน Sprint

Sprint เป็นกรอบเวลาที่ครอบกิจกรรมต่าง ๆ เริ่มด้วย Sprint Planning จากนั้นทำ Development Work พร้อม Daily Scrum ทุกวัน และทบทวนผลิตภัณฑ์ใน Sprint Review ก่อนสะท้อนวิธีทำงานใน Sprint Retrospective เมื่อ Sprint จบ Sprint ใหม่เริ่มต่อทันที Product Backlog Refinement เกิดระหว่างรอบตามความเหมาะสม ไม่ได้ต้องรอหลังจบ Sprint เท่านั้น

Timebox ที่ต้องจำ และจุดที่ตัวเลขในสไลด์ต่างกัน

ตามข้อความในไฟล์ 02 หน้า 31 และ 34–39: Sprint ใช้ 1–4 สัปดาห์ และมีระยะคงที่, Planning สูงสุด 8 ชั่วโมง สำหรับ Sprint 4 สัปดาห์, Daily Scrum 15 นาที, Review สูงสุด 4 ชั่วโมง, Retrospective สูงสุด 3 ชั่วโมง สำหรับ Sprint 4 สัปดาห์ ส่วน Sprint ที่สั้นกว่ามักใช้เวลาของ Events สั้นลง แต่ Daily Scrum ยัง 15 นาที

Team Commitment ต้องเหมาะกับความเป็นจริง

PO เสนอคุณค่าหรือทิศทางที่ต้องการ แต่ไม่เลือกแทน Developers ว่าจะรับปริมาณงานเท่าใด SM ช่วยถาม ท้าทาย และทำให้การวางแผนได้ผล แต่ไม่สั่ง Commitment ให้ทีม ต้องพิจารณา Capacity ความยาก สิ่งที่รู้ และคุณภาพที่ต้องผ่านร่วมกัน

สไลด์ใช้ทั้งคำ Commitment และ Forecast ควรแยก Sprint Goal ที่เป็นเป้าหมายร่วม ออกจาก Forecast ของจำนวนงานที่คิดว่าจะทำได้ แผนและรายละเอียดงานเปลี่ยนได้เมื่อเรียนรู้เพิ่ม โดยไม่ทำให้ Sprint Goal เสี่ยงและไม่ลดคุณภาพเพื่อรักษาตัวเลข

3. Product Backlog, User Stories และการจัดลำดับ Release

อ้างอิง: 2026-INT144-03-Product Backlog.pdf หน้า 4–45

Product Backlog เป็น Single Source of Work

Product Backlog เป็น Emergent, Ordered List ของสิ่งที่ต้องใช้ปรับปรุงผลิตภัณฑ์ รายการจึงไม่ได้มีแค่ Features ใหม่ แต่รวมการเปลี่ยนแปลง Defects, Technical Work และ Knowledge Acquisition ด้วย การรวมไว้ในที่เดียวทำให้เห็นว่าความต้องการเหล่านี้แข่งขันใช้ Capacity เดียวกัน และจัดลำดับร่วมกันได้

Product Backlog Item (PBI) คือหนึ่งรายการใน Backlog มีข้อมูลเช่น Description, Order, Estimate และ Value การมี Estimate ช่วยคาดขนาดงานและเป็นข้อมูลประกอบลำดับ แต่ไม่ใช่ปัจจัยเดียว งานที่เล็กที่สุดไม่ได้ควรขึ้นก่อนเสมอ เพราะงานที่เสี่ยงสูงหรือช่วยเรียนรู้เร็วอาจสำคัญกว่า

ตัวอย่างในสไลด์มีทั้ง Feature สร้าง Ticket, Change เปลี่ยนลำดับผลค้นหา, Defect แก้การค้นหาที่ทำให้ระบบล่ม, Technical Improvement ย้ายเวอร์ชัน DBMS และ Knowledge Acquisition ทำ Prototype เปรียบเทียบ Architecture การซ่อนงานเทคนิคไว้ข้างนอกจนไม่เห็นต้นทุนจริงทำให้การวางแผนคลาดเคลื่อนได้

User Story: ใคร ต้องการอะไร เพื่อคุณค่าอะไร

User Story เป็นคำอธิบายความต้องการจากมุมมองผู้ใช้ ใช้เป็นจุดเริ่มบทสนทนา ไม่ใช่ Specification ทุกเงื่อนไขในประโยคเดียว รูปแบบที่สไลด์แนะนำคือ:

As a <User/Role>, I want to <Action> so that <Benefit/Value>.

Role บอกผู้ได้รับประโยชน์ Action บอกสิ่งที่ต้องทำได้ และ Benefit บอกเหตุผล เช่นลูกค้าธนาคารต้องการถอนเงินจาก ATM เพื่อไม่ต้องขึ้นกับเวลาทำการหรือคิวหน้าเคาน์เตอร์ เมื่อเห็นคุณค่า เราจึงเข้าใจว่าการเข้าถึงบริการและการทำธุรกรรมได้จริงสำคัญกว่ามีหน้าจอสวยอย่างเดียว

ตัวอย่าง Cashier อยากเห็นยอดเงินในลิ้นชัก ต้องถามต่อว่าเพื่อนำไปทำอะไร เช่นตรวจความถูกต้องหรือวางแผนส่งเงิน เหตุผลแต่ละแบบอาจนำไปสู่รายละเอียดต่างกัน การไม่มี Benefit ที่ชัดทำให้ทีมเลือกวิธีสร้างจากการเดาได้ง่าย

รายละเอียดซ่อนอยู่ที่การคุยและการ Refinement

Story ว่า “Customer ยกเลิก Reservation ได้” ยังไม่ตอบว่าจะได้เงินคืนเท่าใด เป็นเงินหรือ Credit ยกเลิกได้ถึงเมื่อใด และมี Confirmation อย่างไร สไลด์แตกต่อเป็น Premium ยกเลิกได้ถึงนาทีสุดท้าย Non-premium ต้องล่วงหน้า 24 ชั่วโมง และส่ง Email ยืนยัน การแตกแบบนี้ทำให้จัดลำดับคุณค่าแต่ละส่วนได้

Epic คือ Story ระดับใหญ่ที่ยังไม่เหมาะหยิบเข้ามาทำครบใน Sprint เช่นลงทะเบียนเรียนออนไลน์ทั้งหมด ค่อยแตกเป็น Stories ที่เล็กลงจน Sprint-ready แล้ว Developers จึงแตกเป็น Technical Tasks ในการวางแผน Story บอกความสามารถที่ต้องได้ ส่วน Task บอกงานที่จะทำเพื่อให้ได้ความสามารถนั้น

DEEP: ลักษณะ Backlog ที่ดี

DEEP เป็นชื่อย่อของคุณลักษณะสี่ด้านที่ต้องดูร่วมกัน ไม่ใช่ขั้นตอนทำครั้งเดียวแล้วจบ

Detailed appropriately ถามว่า “งานนี้ควรละเอียดแค่ไหนตอนนี้” ส่วน Emergent ถามว่า “เมื่อรู้อะไรเพิ่ม รายการและความเข้าใจเปลี่ยนได้ไหม” Backlog จึงมีชีวิต ไม่ใช่เอกสาร Requirements ที่อนุมัติแล้วห้ามแตะ

Value คือประโยชน์ที่คาดหวัง Size/Complexity คือขนาดหรือความซับซ้อน Risk คือความไม่แน่นอนที่อาจกระทบผล และ Learn Fast คือทำสิ่งที่ลดความไม่รู้สำคัญเร็ว ปัจจัยเหล่านี้ต้องชั่งร่วมกัน ตัวอย่างเช่น Feature มีคุณค่าสูงแต่ยังไม่รู้ว่าเทคโนโลยีรองรับหรือไม่ อาจเลือกทดลองสั้น ๆ ก่อนรับงานใหญ่

Backlog Refinement หรือ Grooming ทำอะไร ใครร่วม และทำเมื่อใด

Product Backlog Refinement คือการทำให้ Backlog ชัดและพร้อมต่อการตัดสินใจ เช่นประเมินรายการใหม่ แก้ Estimate จากข้อมูลใหม่ แตก Story ที่ใหญ่เกินไป ลบสิ่งไม่เกี่ยวข้อง เพิ่มความต้องการที่เพิ่งพบ และจัดลำดับใหม่ คำ Grooming ในสไลด์ใช้หมายถึงกิจกรรมกลุ่มนี้

PO รักษาทิศทางและลำดับ Developers ให้ข้อมูลความเป็นไปได้ ขนาด และการแตกงาน SM ช่วยให้การทำงานร่วมกันได้ผล และ Stakeholders ภายใน/ภายนอกให้ข้อมูลตามเรื่องที่เกี่ยวข้อง การร่วมกันให้ข้อมูลไม่ได้ทำให้ PO หมด Accountability ต่อ Backlog

ภาพสไลด์แสดง Refinement ก่อน Planning, ระหว่าง Sprint, หลัง Daily Scrum หรือระหว่าง Review ตามโอกาสที่เหมาะสม จึงไม่จำเป็นต้องเป็นประชุมใหญ่ครั้งเดียวทุกคนทุกเรื่อง และไม่ควรปล่อย Story ใหญ่คลุมเครือจนต้องค้นทุกอย่างใน Planning

Splitting PBI ต้องได้ชิ้นเล็กที่ยังมีคุณค่า

การแตก PBI เป็น Smaller PBIs ต่างจากการแตกเป็น Tasks หลักสำคัญคือแต่ละชิ้นยังให้ Working, Demonstrable Software เช่นแยก “ชำระคำสั่งซื้อได้” เป็นชำระด้วย Wire Transfer กับ Credit Card แต่ละแบบแสดงการใช้งานได้ ในทางกลับกัน “ทำ DB”, “ทำ API”, “ทำ UI” เป็นแผนงานเทคนิคของ Feature ยังไม่ใช่การแบ่งคุณค่าแบบเดียวกัน

การแตกไม่ได้แปลว่าเลือกทำความปลอดภัยหรือคุณภาพทั้งหมดไว้ทีหลังได้ ต้องรักษาระดับคุณภาพและกฎที่จำเป็นต่อความสามารถที่กำลังส่งมอบทุกครั้ง

Fixed Date Release Planning และ Minimum Releasable Features

Fixed Date Release ตรึงวันที่ปล่อยแล้วจัด Scope ให้เหมาะกับเวลาที่มี ทำงานได้เมื่อสร้างงานลำดับสูงก่อน งานนั้น Done จริง และชุดจำเป็นมีขนาดเล็กพอ ถ้าทุก Feature เป็นของจำเป็นและใช้เวลาจนเต็มทุกนาที ก็แทบไม่มีที่ให้รับความไม่แน่นอน

Minimum Releasable Features (MRFs) คือชุด Features ที่ขาดไม่ได้เพื่อให้ Release ยังมีคุณค่าและคุณภาพถึงความคาดหวังขั้นต่ำ ไม่ใช่ทุกสิ่งที่อยากมี สไลด์ให้ Rule of thumb ว่า MRFs ควรใช้ประมาณ 60–70% ของเวลาที่มี แทน 100% เพื่อรับความล่าช้าและ Emergent MRF ที่เพิ่งค้นพบ ตัวเลขนี้เป็นแนวทางของเนื้อหา Release ไม่ใช่สูตรหัก Capacity ของทุก Sprint อัตโนมัติ

MoSCoW: จัดหมวดตามความจำเป็นใน Timeframe นี้

MoSCoW ใช้คุยให้ตรงกันว่าอะไรขาดไม่ได้ อะไรลดได้ และอะไรไม่อยู่ในขอบเขตรอบนี้ โดยผูกกับกรอบเวลาที่ตกลง

Won’t have ไม่ได้แปลว่าจะไม่ทำตลอดไป และ Should have ของ Release 1 ไม่ควรถูกย้ายไป Release 2 แบบอัตโนมัติโดยไม่ประเมินใหม่ เพราะความสำคัญเปลี่ยนตามเป้าหมายและบริบทของแต่ละ Release ได้ ต้องแยก Project-level Priority กับ Release-level Priority

ภาพ Balancing Priorities ยกแนวทาง Must ไม่เกินประมาณ 60% ของ Effort และ Could ประมาณ 20% เพื่อมีพื้นที่ปรับขอบเขต ขณะที่หน้า MRF ยก 60–70% จึงควรจำทั้งสองพร้อมหัวข้อ ไม่ทำให้เป็นข้อบังคับตัวเลขเดียวของ Scrum

ตำแหน่ง Must have กับความเสี่ยงส่งงานไม่ครบ

ถ้าทีมคาดว่าทำได้ 108–132 Story Points สิ่งที่ค่อนข้างมั่นใจว่าจะเสร็จอยู่ก่อนขอบต่ำ 108 ส่วนช่วง 108–132 ยังมีความไม่แน่นอน หาก Must have ทุกชิ้นอยู่ในช่วงที่มั่นใจก็ปลอดภัยกว่าให้บางชิ้นอยู่ในช่วง Might have และแย่ที่สุดคือวาง Must have ไว้ในช่วงที่คาดว่าจะทำไม่ทันตั้งแต่แรก

Story Points ในภาพใช้แสดงขนาดงาน ไม่ใช่เวลาเป็นชั่วโมงโดยตรง จุดที่ต้องอ่านจากภาพคือขอบเขตความเชื่อมั่นในการพยากรณ์ ไม่ใช่สมมติว่าการประมาณแปลว่าได้จำนวนเดียวแน่นอน

ตัวอย่าง Task Board Product Backlog ในสไลด์

ตัวอย่าง VIEW-TASK-TABLE VIEW กำหนดให้เห็น Title, Assignees และ Status เรียงตาม Created Time จากเก่าไปใหม่ และหากไม่มีงานยังแสดงหัวตาราง ส่วน VIEW-TASK-DETAIL กำหนดข้อมูลใน Modal, ข้อความแทน Description/Status ที่ว่าง, วันที่แบบ Local Timezone และพฤติกรรมเมื่อ Task ID ไม่มี เช่น Backend ตอบ 404 แล้ว Frontend แจ้งและกลับหน้าก่อน

ตัวอย่างนี้แสดงว่า PBI ต้องมีเงื่อนไขที่ทีมกับ PO เข้าใจร่วมกันจึงจะออกแบบและทดสอบตรงกัน ไม่ใช่รู้เพียงชื่อ “แสดงรายการ” แล้วถือว่าแต่ละคนตีความอย่างไรก็ได้

4. Scrum Sprints: จาก Sprint Goal ไปสู่ Increment ที่ Done

อ้างอิง: 2026-INT144-04-Scrum Sprints.pdf หน้า 4–52

Sprint Goal ให้เหตุผลและความเป็นหนึ่งเดียวแก่ Sprint

Sprint Goal คือวัตถุประสงค์เดียวของ Sprint ช่วยให้ทีมรวมแรงกับผลลัพธ์ร่วมและยืดหยุ่นในวิธีไปถึง เช่น “ผู้ใช้ส่งคำค้นแบบ Keyword อย่างง่ายได้” ชัดกว่าบอกเพียง “ทำห้า PBI แรกให้ครบ” เพราะข้อความหลังไม่บอกว่าห้ารายการนั้นสร้างผลอะไรด้วยกัน

PO เสนอว่า Sprint นี้จะเพิ่มคุณค่าอย่างไร แล้ว Scrum Team ร่วมทำให้เป้าหมายชัดในการ Planning ระหว่าง Sprint สามารถ Clarify และ Renegotiate Scope กับ PO เมื่อเรียนรู้เพิ่ม Refinement ยังเกิดได้ แต่ ไม่เปลี่ยนจนทำให้ Sprint Goal เสี่ยง และไม่ลดคุณภาพ ความยืดหยุ่นจึงอยู่ร่วมกับ Focus ไม่ใช่เปลี่ยนเป้าหมายตามทุกคำขอ

Sprint Planning ตอบ Why, What และ How

Why is this Sprint valuable? เชื่อมงานกับคุณค่าและ Sprint Goal What can be done this Sprint? Developers ประเมินว่าจะส่งอะไรได้จาก Capacity และความเข้าใจงาน How will the chosen work get done? วางแผนงานเพื่อสร้าง Increment ให้ผ่าน Definition of Done ผลคือ Sprint Goal และ Sprint Backlog ที่ทีมเข้าใจร่วมกัน ไม่ใช่รายการงานที่คนภายนอกสั่งลงมา

การแตก PBI เป็น Tasks ช่วยเปิดรายละเอียดที่ซ่อนอยู่ เช่น Design, DB, Frontend, Backend, Infrastructure, Integration และ Tests สไลด์เสนอให้ Task ส่วนใหญ่ไม่ใหญ่กว่า Effort แปดชั่วโมงเพื่อมองความคืบหน้าได้ แต่ยอมรับว่าบางงานอาจใหญ่กว่าได้ นี่เป็นแนวทางวางแผนในสไลด์ ไม่ใช่กฎว่าทุก PBI หรือ Task ต้องเท่ากับแปดชั่วโมง

Definition of Done ต่างจาก Acceptance Criteria อย่างไร

Definition of Done (DoD) คือมาตรฐานร่วมที่บอกว่าต้องทำงานชนิดใดให้ครบเพื่อถือว่าส่วนเพิ่มมีคุณภาพพร้อมใช้งาน ใช้ร่วมกับ PBIs ไม่ใช่แต่ละคนคิดเอง เช่น Review Design, Code Review/Refactor, Tests ที่ตกลงไว้, อัปเดตเอกสาร และไม่มี Defect ที่ขัดกับมาตรฐานนั้น

Acceptance Criteria (AC) คือเงื่อนไขเฉพาะของ PBI ว่าผลที่ผู้ใช้ได้รับต้องเป็นอย่างไร เช่นช่องค้นหาเริ่มทำงานเมื่อกด Search และรองรับ City/Hotel Name/Street ส่วน Acceptance Test คือกรณีตรวจจริงที่ระบุ Data, Steps และ Expected Results เพื่อพิสูจน์เงื่อนไขนั้น ทั้งสามสัมพันธ์กันแต่ใช้แทนกันไม่ได้

Potentially Shippable Product Increment (PSPI) หมายถึงส่วนเพิ่มที่ทำเสร็จจริงตาม DoD ไม่ใช่ของที่ต้องมาทำ Integration และ Test สำคัญต่อภายหลัง คำว่า Potentially Shippable เน้นความพร้อม ไม่ได้บอกว่าต้องตัดสินใจ Release ให้ผู้ใช้ทุกครั้งเสมอไป ตาราง DoD ในสไลด์มี “Live on production servers” เป็นตัวอย่างของข้อตกลง จึงไม่ควรยกทุกบรรทัดของตัวอย่างเป็นข้อบังคับสากลของทุกทีม

เขียน Acceptance Criteria ได้ทั้ง Scenario และ Rule

Scenario-oriented ใช้ Given–When–Then: Given คือบริบทและเงื่อนไขก่อนเริ่ม When คือเหตุการณ์ที่เกิด Then คือผลที่ต้องเห็น ตัวอย่าง ATM ระบุบัญชีมีสิทธิ์ถอน บัตรถูกต้อง และเครื่องมีเงิน เมื่อผู้ใช้ถอนแล้ว ต้องตัดยอด จ่ายเงิน และคืนบัตร การเขียนแบบนี้ทำให้สัมพันธ์ระหว่างเงื่อนไขกับผลชัด

Rule-oriented เป็นรายการกฎ เช่น Search Field อยู่ด้านบน เริ่มค้นเมื่อกดปุ่ม มี Placeholder สีเทา ข้อความนั้นหายเมื่อเริ่มพิมพ์ และรองรับชุดข้อมูลที่กำหนด เหมาะกับหลายเงื่อนไข UI/Behavior ที่อ่านเป็นข้อได้ ไม่จำเป็นต้องบังคับทุก PBI ให้อยู่ในรูป Scenario เดียว

Acceptance Test จาก Task Table

กรณีแรกมี Test Scenario: ตารางว่าง เตรียมไม่มีข้อมูล เปิด /task แล้วตรวจว่า Frontend ขอ Backend, Backend ตอบ HTTP 200 พร้อม [] และหน้าจอแสดงหัวตารางโดยไม่มีรายการ กรณีที่สองเตรียมชุด TASK_BASE แล้วตรวจทั้งข้อมูลที่ตอบและสี่แถวบนหน้าจอ การทดสอบจึงตรวจผลลัพธ์จริงทั้งระบบ ไม่ใช่เห็น Request ถูกส่งแล้วถือว่าผ่าน

HTTP 200 ในตัวอย่างหมายถึง Request สำเร็จ ส่วน 404 ใน PBI Detail ใช้เมื่อไม่พบ Task ที่ร้องขอ นี่เป็นรายละเอียดตัวอย่างระบบในวิชาเพื่อให้เข้าใจ Acceptance Test ไม่จำเป็นต้องท่องวิธีเขียน API ทั้งหมดเพื่อแยก AC จาก DoD

Team Capacity: ชั่วโมงในปฏิทินไม่เท่ากับชั่วโมงทำ PBI

Capacity คือกำลังทำงานที่มีจริงสำหรับ Sprint ไม่ควรคำนวณ 10 วัน × 8 ชั่วโมง = 80 ชั่วโมงต่อคนแล้วรับงานเต็มทันที ต้องหักวันลา Training, งานนอก Sprint, Scrum Activities และเผื่อ Unplanned Work โดยใช้ชั่วโมงที่ทำงานกับ PBI ได้จริง ไม่หักสิ่งเดียวกันซ้ำสองรอบ

Sprint Buffer คือส่วนเผื่อความไม่แน่นอน เช่นประเมินผิดหรือเกิดปัญหา ควรเรียนรู้ขนาดจากข้อมูลหลาย Sprint ไม่เลือกเปอร์เซ็นต์เดียวตลอดโดยไม่ตรวจผล คำว่า Buffer ไม่ได้อนุญาตให้ซ่อนงานหรือคิดว่าคุณภาพไม่จำเป็น

สไลด์หน้า 21 แสดง Capacity แบบช่วง รวมประมาณ 140–197 Effort-hours จากความพร้อมต่างกันของสมาชิก ช่วงกว้างสื่อความไม่แน่นอน ไม่ใช่ทุกคนมีแปดชั่วโมงทุกวัน ส่วนหน้า 22 และ 28 มีอีกตัวอย่างที่หักประชุมแล้วได้ 48 + 34 + 36 + 40 + 32 = 190 ชั่วโมง และกัน Unplanned Work สมมติ 50 ชั่วโมง เหลืองานที่วางแผนไว้ 140 ชั่วโมง

ถ้า Stories ที่ประเมินเป็น Effort-hours มีขนาด 28, 70, 40 และ 40 รวมสะสมจะเป็น 28, 98, 138 และ 178 ชั่วโมง ภายใต้ 140 ชั่วโมงสามชิ้นแรกอยู่ใน Capacity ส่วนรับทั้งสี่เกิน ตัวอย่างนี้แสดงการเปรียบเทียบหน่วยเดียวกัน และยังต้องพิจารณาทักษะที่เป็นคอขวดกับ Sprint Goal ไม่ใช่มองยอดรวมอย่างเดียว

เลือก PBI ที่ทำเสร็จ และใช้ Spike ลดความไม่รู้

เริ่มเลือกตาม Sprint Goal และลำดับ Backlog ใช้หลัก Don’t start what you cannot finish ถ้ารายการใหญ่เกินให้แตกเป็นส่วนที่แต่ละส่วนมีคุณค่า หรือเลือกงานที่เหมาะกว่า ไม่เริ่มหลายงานจนไม่มีอะไรผ่าน DoD

ถ้ายังประเมิน PBI หรือแตก Tasks ไม่ได้ อาจเป็นสัญญาณว่าต้องเรียนรู้ก่อน Spike คือกิจกรรมหาความรู้ด้วย Prototype, Proof of Concept (PoC), Study หรือ Experiment เพื่อให้ตัดสินใจต่อได้ ไม่ใช่รับ Commitment งานใหญ่อย่างมั่นใจทั้งที่ยังไม่รู้วิธี

Technical Spike ถามว่า “จะสร้างอย่างไร” เช่นส่ง Reminder ผ่าน LINE ได้ไหม จะแสดงเวลา Local Timezone อย่างไร หรือป้องกันคนสองคนจองช่องสุดท้ายพร้อมกันอย่างไร Functional Spike ถามว่า “ควรทำงานอย่างไร” เช่นจะเสนอช่องที่ยกเลิกให้ Waiting List แบบไหนโดยไม่ทำให้หลายคนเข้าใจว่าได้ช่องเดียวกัน การทดลองควรตอบคำถามชัดและทำเมื่อความไม่รู้นั้นมีผลต่อการตัดสินใจ ไม่ทำ Prototype ไปเรื่อยโดยไม่มีข้อสรุป

จาก PBI ไปสู่ Main Tasks และ Subtasks

VIEW-TASK-TABLE VIEW ในสไลด์มีงาน Design API/DB, สร้าง Table, เตรียม Test Data, ทำหน้ารายการ, ทำ GET API, เตรียม Container, Deploy, Unit Test, Integration Test และ Acceptance Test บน Dev Servers รายการนี้แสดงว่า “เขียนหน้าเสร็จ” ยังไม่เท่ากับ PBI เสร็จ

งานหลักยังแตกย่อยได้ เช่น Frontend แยก Environment/Routes กับ Component ที่มี HTML, JavaScript และ CSS ส่วน Backend แยก Repository/DAO, Entity และ REST Controller พร้อม Exception Handling ต้องใช้แผนตามสิ่งที่จำเป็นจริง ไม่คัดทุก Task ไปทุก Feature โดยไม่พิจารณา

Sprint Execution และ Flow Management

Sprint Execution คือการทำทุกงานที่จำเป็นเพื่อให้ได้ Increment ตาม Sprint Goal ไม่ใช่ Coding อย่างเดียว Flow Management ดูให้งานไหลจากเริ่มจนเสร็จ ลดเวลาที่งานรอและลดการส่งต่องานที่ทำให้ข้อมูลขาดหาย เป้าคือเพิ่มคุณค่าที่เสร็จจริงภายใน Sprint

Mini Waterfall คือทำ Design ทั้งชุด ตามด้วย Code ทั้งชุด แล้วค่อย Test ท้าย Sprint แม้ Sprint สั้นก็ยังเจอการกองงานทดสอบและรู้ปัญหาช้า เช่นคนเขียนโค้ดบอกว่างานตนเสร็จแล้วไปเริ่ม Feature ใหม่ ทั้งที่ Testers ยังติดงานค้าง ผลทีมอาจไม่มี PBI ใด Done

การคิดแบบ Value-delivery-focused ให้ทีมจัดงานและช่วยกันตามสถานการณ์ เพื่อจบ PBI ที่เริ่มไว้ ลดงานรอและ Handoffs แทนเพิ่มจำนวนงานที่เปิดพร้อมกัน การใช้คนเต็มเวลาแต่ไม่จบคุณค่า ไม่ได้แปลว่า Flow ดี

Swarming, Pair Programming และ Task Board

Swarming คือสมาชิกที่ยังมี Capacity มาช่วยทำรายการที่เริ่มแล้วให้จบก่อนเริ่มใหม่ อาศัยทัศนคติช่วยทีมและทักษะที่ข้ามงานได้ระดับหนึ่ง เช่นคนที่ทำโค้ดเสร็จช่วยสร้าง Test Data, Review หรือแก้ปัญหาการทดสอบ ไม่ใช่ทุกคนต้องทำอย่างเดียวกันตลอด

Pair Programming ให้สองคนร่วมทำงานอย่างใกล้ชิด มีวงจรเขียน Test, เขียน Code, รัน Test และปรับอย่างรวดเร็ว ช่วยให้ Feedback สั้นลงและพบปัญหาเร็ว ไม่ใช่แบ่งโค้ดกันเขียนเงียบ ๆ แล้วนับว่าเป็น Pair

Task Board ทำให้ความคืบหน้าเห็นร่วมกัน อย่างน้อยมี To-do, Doing, Done ผูกผู้ทำงานกับ Task ได้ตั้งแต่ Planning หรือเมื่อพร้อมรับงาน อาจมีหลายคนช่วยกันและแนบ Output เช่น API Specification, Links หรือ Files เครื่องมือในสไลด์มี GitHub Projects, JIRA, Trello, ClickUp และ Monday แต่ Board จะมีประโยชน์เมื่อข้อมูลตรงจริงและ Done มีความหมายเดียวกัน

Daily Scrum: Inspect, Synchronize และปรับแผนทุกวัน

Daily Scrum เป็นกิจกรรม 15 นาทีของ Developers เพื่อตรวจความก้าวหน้าต่อ Sprint Goal พบ Impediments และปรับแผนร่วมกัน ไม่ใช่ประชุมรายงานให้หัวหน้าให้คะแนน เกิดทุกวันในเวลาและสถานที่สม่ำเสมอ ไม่รอให้งานเสร็จจึงค่อยรายงาน

สไลด์หน้า 45 เสนอห้าคำถาม: ทำอะไรตั้งแต่เมื่อวาน วันนี้ทำอะไร อะไรขวางงาน ลืมอะไรหรือไม่ และเรียนรู้อะไรที่อยากแชร์ ส่วนหน้า 47 ยกแนวทางผลัดตอบสามคำถามหรือสามรอบ จึงควรจำว่าโครงคำถามเป็นแนวทางช่วยคุย ไม่ใช่กฎว่าต้องท่องจำนวนคำถามเดียวทุกครั้ง สิ่งที่ต้องได้คือภาพจริงและแผนที่ปรับต่อเป้าหมาย

หากต้องหารือ Solution ยาว ควรแยกต่อหลัง Daily Scrum กับคนที่เกี่ยวข้องเพื่อรักษา Timebox การแบ่งปันความคืบหน้า การช่วยเพื่อน และการศึกษาที่เกี่ยวกับงานมีประโยชน์ แม้ยังปิด Task ไม่ได้ แต่ต้องพูดให้ชัดว่าเรียนรู้อะไรและช่วยแผนอย่างไร

Technical Debt และ Refactoring

Technical Debt เปรียบเหมือนภาระที่เกิดจากการตัดสินใจหรือสภาพระบบที่ทำให้อนาคตแก้ยากขึ้น อาจยอมใช้วิธีชั่วคราวเพื่อ Feedback เร็วได้ แต่ต้องรู้ว่าจะจ่ายคืนอย่างไร ถ้าปล่อยต่อจะเสียเวลาเพิ่มทุกครั้ง คล้ายดอกเบี้ยของหนี้

สไลด์รวมทั้ง Design ที่เคยเหมาะแต่ไม่เหมาะเมื่อบริบทเปลี่ยน, Defects ที่รู้แล้วไม่แก้ และ Test Coverage ที่ไม่พอ ตัวอย่างเช่นชื่อตัวแปรไม่สื่อ Hard-coded URL, เปิด CORS กว้างโดยไม่จำเป็น, API คืนข้อมูลเกิน, ไม่มี Exception Handling หรือใช้วิธีรัน Frontend ที่ไม่เหมาะกับ Production ประเด็นคือเลือกตามบริบทและคุณภาพที่ต้องการ ไม่ใช่ตีความว่าเทคโนโลยีชื่อหนึ่งผิดเสมอทุกกรณี

Refactoring คือปรับโครงสร้างภายในของโค้ดโดยรักษาพฤติกรรมภายนอก เช่นแยกส่วนซ้ำหรือเปลี่ยนชื่อให้เข้าใจง่าย ช่วยลด Technical Debt และทำให้แก้ต่อได้ง่าย ถ้าจงใจเปลี่ยนผลลัพธ์ธุรกิจหรือเพิ่ม Feature การเปลี่ยนนั้นไม่ได้เป็น Refactoring เพียงอย่างเดียว Tests ช่วยตรวจว่าพฤติกรรมเดิมยังคงอยู่

5. Scrum Values และการทำงานเป็นทีม

อ้างอิง: 2026-INT144-05-Scrum Values and Team.pdf หน้า 5–50

Values ทั้งห้าช่วยให้ Pillars เกิดขึ้นจริง

Values เป็นแนวทางพฤติกรรม ส่วน Pillars เป็นหลักการเรียนรู้และควบคุมแบบ Empirical เมื่อคนไม่กล้าพูดความจริง Transparency ก็อ่อนลง แม้มี Dashboard ครบ ดังนั้น Commitment, Focus, Courage, Openness และ Respect จึงเป็นฐานสร้าง Trust และทำให้การตรวจปรับได้ผล

Commitment ไม่ใช่สัญญาว่าจะทำทุก Feature ด้วยการทำงานเกินกำลัง Focus ไม่ใช่ปฏิเสธช่วยเพื่อน Courage ไม่ใช่ทำเสี่ยงโดยไม่มีข้อมูล Openness ไม่ใช่เพียงเปิดไฟล์ให้เห็น และ Respect ไม่ใช่ห้ามเห็นต่าง ต้องสามารถท้าทายความคิดอย่างให้เกียรติเพื่อผลทีม

Trust Equation

สไลด์แสดง Trustworthiness = (Credibility + Reliability + Intimacy) / Self-Orientation เป็นแบบจำลองช่วยคิดเรื่องความเชื่อใจ ไม่ใช่สูตรคำนวณคะแนนบุคคลอย่างตายตัว

Credibility คือเชื่อคำพูดและความรู้ Reliability คือเชื่อว่าจะทำตามที่บอก Intimacy คือความรู้สึกปลอดภัยพอจะเปิดเผยเรื่องยาก และ Self-Orientation คือความมุ่งประโยชน์ตนเองมากกว่าผู้อื่น ถ้าคนเก่งแต่สนแต่ตัวเองหรือเอาข้อมูลที่เพื่อนเล่าไปโจมตี ความเชื่อใจย่อมไม่สูงตามความเก่งนั้น

Working Group ต่างจาก Working Team

การอยู่ในห้องเดียวกันหรือมีชื่อทีมเดียวกันไม่พอ หากต่างคนต่างปิด Task แล้วไม่มีใครดูว่าระบบใช้ได้จริง ก็ยังขาด Mutual Accountability ที่สไลด์ต้องการ

Efficiency กับ Effectiveness

Efficiency คือใช้เวลา เงิน หรือ Effort อย่างสูญเปล่าน้อย ส่วน Effectiveness คือบรรลุผลที่ต้องการ เช่นทีมทำ Report ที่ไม่มีผู้ใช้ได้เร็วมากอาจ Efficient ในการผลิต แต่ไม่ Effective ต่อเป้าหมาย การเพิ่มความเร็วอย่างเดียวจึงไม่พอ ต้องเลือกคุณค่าที่ถูกและส่งให้สำเร็จด้วย

ลักษณะ Developers ที่ช่วยให้ทีมเคลื่อนเป็นหน่วยเดียว

Self-managing: ทีมร่วมตัดสินใจงานโดยไม่มีแรงสั่งการแบบ Top-down ครอบทุกเรื่อง แต่มี Simple Rules, Feedback และ Accountability ชัด Cross-functionally diverse and sufficient: ทักษะหลากหลายและครบพอ ลดการส่งต่องานข้ามทีมที่ทำให้รอหรือเข้าใจผิด มุมมองต่างกันยังช่วยหาคำตอบและนวัตกรรม

T-shaped Skills: แกนตั้งเป็นความเชี่ยวชาญลึกในสาขาหนึ่ง แกนนอนเป็นความกว้างพอทำงานร่วมและช่วยพื้นที่อื่น จึงมีทั้งความลึกและความยืดหยุ่น ไม่ได้หมายความว่าทุกคนต้องเป็น Specialist ทุกสาย และต้องเรียนรู้อย่างต่อเนื่อง

Musketeer Attitude: ยึด “All for one and one for all” ผลของทีมมาก่อนการแยกความสำเร็จส่วนตัว เชื่อมโดยตรงกับ Swarming เพราะคนพร้อมช่วยสิ่งที่ทีมต้องจบ แม้ไม่ใช่งานประเภทที่ทำประจำ

High-bandwidth Communication: สื่อสารโดยตรงและใกล้กันเพื่อส่งบริบทเร็ว ถามกลับได้ และ Inspect/Adapt บ่อย Transparent Communication: สื่อให้เห็นสถานการณ์จริงเพื่อไม่เกิด Surprise ทั้งสองต่างกัน: ช่องทางเร็วแต่รายงานไม่จริงยังไม่ Transparent; รายงานจริงแต่ข้อมูลผ่านหลายทอดช้ามากก็ยังมีปัญหา Bandwidth

Right-sized: ทีมเล็กพอคล่องตัวแต่ใหญ่พอทำงานสำคัญครบ ลด Social Loafing และเวลาประสานงาน Focused and Committed: ลดงานพร้อมกันหลายโครงการเพื่อรักษาเวลาทำงานที่สร้างคุณค่า Sustainable Pace: รักษาระดับความเข้มที่ทำต่อได้ แทนเร่งหนักปลายทางทุกครั้ง Long-lived: รักษาทีมที่ทำงานร่วมกันได้นานพอสะสมความรู้และวิธีร่วมงาน อาจใช้ Split-and-seed ให้สมาชิกที่มีประสบการณ์ไปช่วยตั้งทีมใหม่เมื่อเหมาะสม

Product Owner: คุณค่า Economics และความเข้าใจร่วม

PO รับผิดผลเรื่อง Product Value และ Effective Product Backlog Management: สื่อ Product Goal ให้ชัด สร้างและอธิบาย PBIs เรียงลำดับ และทำให้ Backlog โปร่งใสและเข้าใจได้ PO ร่วมกับ Stakeholders เพื่อเข้าใจผู้ใช้/ธุรกิจ และร่วมกับ Developers เพื่อให้สิ่งที่สร้างตอบโจทย์และทำได้จริง

Responsibilities ที่ภาพในสไลด์รวมไว้มี Manage Economics, Participate in Planning, Groom Product Backlog, Define Acceptance Criteria and Verify, Collaborate with Development Team และ Collaborate with Stakeholders การ Manage Economics คือชั่งคุณค่า ต้นทุน และผลของการเลือกทำงาน โดยมองทั้ง Backlog ต่อเนื่อง ระดับ Sprint ตอนเริ่ม และทบทวนระดับ Release เมื่อ Sprint จบ

PO จึงต้องคุยกับทีมระหว่างพัฒนาเป็น Feature ไม่ใช่ส่ง Requirements ครั้งเดียวแล้วกลับมาตรวจท้ายโครงการ บทบาท “As Product Manager” สื่อการทำงานกับทิศทางและ Stakeholders ส่วน “As BA/Tester” สื่อการช่วยทำความเข้าใจรายละเอียดและตรวจเงื่อนไข ไม่ได้หมายความว่า PO ต้องเขียนทุก Test หรือทำทุก Task ด้วยตนเอง

Scrum Master: Coach และผู้ช่วยให้ Scrum ได้ผล

SM ช่วยให้ทั้งทีมและองค์กรเข้าใจทฤษฎีกับการใช้ Scrum และรับผิดผลต่อ Scrum Team’s Effectiveness โดยช่วยให้ทีมพัฒนา Practices ภายใน Framework บทบาทนี้ไม่ได้เป็นหัวหน้าสั่งว่าใครต้องทำ Task ใดหรือทำอย่างไร

ถ้าปัญหาทีมแก้ได้ SM ช่วยถามและทำให้ทีมแก้ได้ดีขึ้น ถ้าเป็น Server ไม่เสถียรที่ทีมไม่มีอำนาจควบคุม SM รับเป็นเจ้าของการประสานผู้มีอำนาจ เช่นฝ่าย Operations เพื่อให้คลี่คลาย ไม่จำเป็นว่า SM ต้องซ่อม Server ด้วยตนเอง

ภาพ Executive Coaching แยก Supporter, Coach, Advisor และ Mentor ตามระดับการ Ask/Tell โดย Coach เน้นถามให้ผู้รับการโค้ชคิดและลงมือเอง เทียบกับการบอกคำตอบหรือคำแนะนำให้ตรง ๆ เป้าคือเพิ่มความสามารถของทีม ไม่สร้างการพึ่ง SM ทุกการตัดสินใจ

6. ทวนก่อนสอบ: ความต่าง ตัวเลข และวิธีอ่านโจทย์สถานการณ์

สังเคราะห์จากสไลด์ทั้ง 5 ไฟล์ เนื้อหาส่วนนี้ช่วยเรียกความจำหลังอ่านคำอธิบาย ไม่ใช่ขอบเขตสอบเพิ่มเติม

แยกคู่คำที่มักทำให้เลือกผิด

ตัวเลขที่จำพร้อมเงื่อนไข

อ่านโจทย์สถานการณ์ให้เห็นปัญหาที่แท้จริง

ถ้าโจทย์เล่าว่าทีมทำงานเร็วแต่ผู้ใช้ไม่ได้ประโยชน์ ให้คิดถึง Value, Working Software และ Effectiveness ถ้าเล่าว่าปิดโค้ดมากแต่ Test ค้าง ให้คิดถึง Flow, Mini Waterfall, Swarming และ DoD ถ้าโจทย์มีคำขอใหม่กลาง Sprint ให้ตรวจ Sprint Goal, Scope Negotiation และ Quality ก่อนเลือกว่ารับหรือปฏิเสธทุกอย่าง

ถ้าถามว่าใครทำอะไร ให้เริ่มจากผลที่ต้องเป็นเจ้าของ: PO → Value/Backlog, Developers → Increment/Plan/Quality, SM → Scrum/Effectiveness/Enable Team ถ้าถามว่าประชุมอะไร ให้แยก Planning = วางแผน, Daily = ปรับรายวัน, Review = Product, Retro = Process อย่าตอบจากคำว่า Meeting อย่างเดียว

ถ้าให้ประโยค Story ให้มอง Role–Action–Value และรายละเอียดที่ยังต้องคุย ถ้าให้รายการแตกงาน ให้ดูว่าเป็น คุณค่าที่สาธิตได้ หรือแค่ Technical Layer ถ้าให้ Must/Should ให้ถามว่า “ไม่มีแล้วยังส่งสิ่งที่ใช้ได้หรือมี Workaround หรือไม่” แทนดูว่าผู้ขอพูดด้วยน้ำเสียงเร่งด่วนแค่ไหน

ใช้ Mockup เพื่อเลือกจุดกลับไปอ่าน

ทำชุดสั้นก่อนถ้าต้องการดูว่าหัวข้อใดยังไม่ชัด หลังส่งให้เปิดเฉลยข้อที่ผิดและข้อที่เดาถูก ดูว่าตนสับสนคำไหนหรือพลาดเงื่อนไขใด แล้วใช้ลิงก์กลับไปอ่านตรงนั้น ทำชุดเต็มอีกครั้งหลังทบทวน โดยให้ความสำคัญกับเหตุผลมากกว่าจำตำแหน่งตัวเลือก

แบบทดสอบรายบทมี 5 ชุด ชุดละ 20 ข้อ รวม 100 ข้อ ใช้ภาษาอังกฤษหรือภาษาไทย และจัดทำขึ้นเพื่อประเมินความเข้าใจจากเอกสาร ไม่ใช่ข้อมูลยืนยันจำนวนข้อ เวลาสอบ หรือสัดส่วนข้อสอบจริงของ INT144 เพราะเอกสารที่ให้ไม่มีคำชี้แจงสอบดังกล่าว

เอกสารอ้างอิงและขอบเขตการเรียบเรียง

• 2026-INT144-01-Agile Principles and Scrum Concepts.pdf — Agile Manifesto, Principles, Scrum Concepts และ Empiricism
• 2026-INT144-02-Scrum Overview.pdf — Phases, Team, Planning, Backlogs และ Events
• 2026-INT144-03-Product Backlog.pdf — User Stories, DEEP, Refinement, Splitting, Fixed Date และ MoSCoW
• 2026-INT144-04-Scrum Sprints.pdf — Goal, Planning, DoD, AC, Capacity, Spike, Execution, Flow และ Technical Debt
• 2026-INT144-05-Scrum Values and Team.pdf — Values, Trust, Teamwork, Developers, PO และ SM

คำอธิบายภาษาไทยขยายเหตุผลจากสไลด์เพื่อให้อ่านต่อเนื่อง ตัวอย่างที่ระบุว่าเป็นแนวทางหรือตัวอย่างไม่ใช่กฎสากลทั้งหมด เอกสารอ้างทั้ง Scrum Guide หลายช่วงและ Essential Scrum จึงกำกับข้อแตกต่างที่เห็นในไฟล์ไว้ ไม่แทนเนื้อหาด้วย Framework เวอร์ชันอื่น

แหล่งอ่านเพิ่มเติม

เอกสารต่อไปนี้ใช้สำหรับขยายความเข้าใจ โดยขอบเขตและตัวอย่างสำหรับการสอบยังอิงเอกสารรายวิชาที่ระบุไว้ในสรุป

• Manifesto for Agile Software Development — คุณค่าหลักของ Agile จากเอกสารต้นฉบับ
• Principles behind the Agile Manifesto — หลักการ Agile ทั้ง 12 ประการจากแหล่งต้นฉบับ
• The 2020 Scrum Guide — Accountabilities, Events, Artifacts และ Commitments ของ Scrum