[เสพแล้วเล่า] ตอนที่ 3— Agile Software Development By Siam Chamnankit (SCK)
ในบทความนี้ จะเป็นตอนจบของซีรีย์ Agile Software Development By Siam Chamnankit (SCK) จะเป็นการบอกเล่าเรื่องที่ได้เรียนรู้เกี่ยวกับ สิ่งที่จะเกิดขึ้นภายใน Sprint และการทำ Sprint Review และ Sprint Retrospective ในวันสุดท้ายของ Sprint ว่าจะต้องทำอย่างไรบ้าง
และเช่นเดิมค่ะ ขอฝาก youtube ของสยามชำนาญกิจไว้ด้วยนะคะ ในนั้นจะมีการบอกเล่าเรื่องราวและประสบการณ์การทำงานของพี่ ๆ ในทีม ทั้งเรื่องของการพัฒนาซอฟต์แวร์และการทดสอบซอฟแวร์ ผู้เขียนขอแนะนำให้เสพทุกเรื่องเลยค่าาา
warning! — บทความนี้เกิดขึ้นจากการทำความเข้าใจด้วยตัวของผู้เขียนเองเท่านั้น
สิ่งที่จะเกิดขึ้นภายใน Sprint — in The Sprint
ในกรอบระยะเวลา 10 วัน เราจะแบ่งการทำงานเอาไว้เป็น 3 กรอบระยะเวลา คือ
- วันที่ 1 ของ Sprint
- วันที่ 2 — วันที่ 9 ของ Sprint
- วันที่ 10 ของ Sprint
Sprint Planning Event (วันที่ 1 ของ Sprint)
กรอบระยะเวลา → ไม่เกิน 3 ชั่วโมง เช่น วันจันทร์ 09:00–12:00 น. (ที่ SCK แนะนำ)
กำหนด Sprint Goal : บอกถึงว่าจะต้องมี Product Backlog Items (PBIs) อะไรบ้าง ซึ่งจะต้องเป็น Product Backlog Items (PBIs) ที่ผ่านการ Adding Detail, Estimate และ Ordering มาแล้วเรียบร้อย
Product Owner (PO) จะเป็นคนกำหนดแล้วนำเข้า Sprint เพื่อบอกเล่ากับ Development Team ให้ทราบ
หลังจากนั้น Development Team จะต้องออกแผนการทำงานที่จะเกิดขึ้นในระหว่างวันที่ 2 — วันที่ 9 ของ Sprint ที่จะต้องส่งมอบงาน เพื่อเอาขึ้นไปรันบน UAT หรือ Pre-Production ให้ได้ กำหนดเลยว่าแต่ละ Product Backlog Item จะต้องทำและส่งมอบวันไหนบ้าง
ยกตัวอย่างเช่น ใน Sprint ที่ 2 จะมี 4 Product Backlog Items
Product Backlog Item 1
- Description
- Value
- DoD
- Estimate
และ
Product Backlog Item 2
- Description
- Value
- DoD
- Estimate
และ
Product Backlog Item 3
- Description
- Value
- DoD
- Estimate
และ
Product Backlog Item 4
- Description
- Value
- DoD
- Estimate
Development Team นำเสนอแผนการทำงานให้กับ Product Owner (PO) พร้อมอธิบายการทำงาน อะไรทำได้หรือทำไม่ได้ อย่างไรบ้าง ลำดับมาอะไรจะเสร็จเมื่อไหร่ และ Product Owner (PO) จะได้รู้ว่าเราจะต้องตรวจรับงาน Product Backlog Item ทีละชิ้น ตามลำดับความสำคัญ เมื่อไหร่ เราจะไม่ตรวจรับรวมกันทีเดียว หรือไปตรวจรับนอก Sprint ต้องจบทุกอย่างภายใน Sprint ให้ได้
การวางแผนงานจะเจอ Use Case ดังนี้
Use Case ที่ 1: อยากได้ 4 Product Backlog Items > ส่งมอบให้ได้ 4 Product Backlog Items
Use Case ที่ 2: อยากได้ 4 Product Backlog Items > ส่งมอบให้ได้น้อยกว่า 4 Product Backlog Items
ยกตัวอย่างเช่น
อยากได้ 4 Product Backlog Items > ส่งมอบให้ได้ 3 Product Backlog Items
2.1 Product Owner ตัดสินใจว่าจะยอมรับแผนงานนี้ ก็จะต้องมีการปรับ Sprint Goal ลงมา และนำ Product Backlog Item ที่ 4 เลื่อนไปจัดคิวใหม่ที่ Sprint ถัดไปในอนาคต
2.2 Product Owner ขอเรียงลำดับความสำคัญใหม่ ว่าจะทำ Product Backlog Items ไหนก่อนหลัง กรณีนี้จึงขอเปลี่ยน Product Backlog Item 4 ขึ้นมาทำก่อน และเอา Product Backlog Item 2 ลงไปจัดคิวใหม่ที่ Sprint ถัดไป
Use Case ที่ 3: อยากได้ 4 Product Backlog Items > ส่งมอบให้ได้มากกว่า 4 Product Backlog Items
ยกตัวอย่างเช่น
อยากได้ 4 Product Backlog Items > ส่งมอบให้ได้ 5 Product Backlog Items
กรณีนี้คือ Development Team วางแผนไว้ว่างานจะเสร็จก่อนจบ Sprint จึงร้องขอกับ Product Owner ว่าขอเพิ่มอีก 1 Product Backlog Item ดังนั้น Product Owner จะต้องเลือก Product Backlog Item ที่ผ่านการใส่รายละเอียดมาครบแล้ว เข้ามาทำเพิ่มใน Sprint นั้น ซึ่งเราจะต้องมี Product Backlog Item ที่เตรียมการไว้พร้อมเข้า Sprint แล้วหลายตัวจากการทำ Product Backlog Refinement Workshop
Daily Event กำหนดเป้าหมายรายวันที่ยึดโยงไปที่ Sprint Goal
Daily Scrum Event
- เกิดขึ้นระหว่างวันที่ 2 — วันที่ 9 ของ Sprint
- กรอบระยะเวลา → ไม่เกิน 15 นาที
- แนะนำเป็น วันอังคาร — วันพฤหัสบดี เวลา 09:00–9:15 น. (ใน Scrum ไม่ได้บอกเจาะจงไว้)
Daily Scrum → กำหนดแผนงานรายวัน จะต้องทำะไรบ้าง เพื่อไปสู่ Sprint Goal ได้
วิธีการ รูปแบบ และเทคนิค ขึ้นอยู่กับ Development Team เลือก ตราบใดที่ยังเป็นแผนงานที่ยึดโยงไปสู่ Sprint Goal ได้
แต่ถ้าในทางปฏิบัติจริง ๆ ถ้า Development Team ยังไม่รู้ว่าจะต้องทำยังไงหรือยังไม่เคยมีประสบการณ์ มาก่อน Scrum จึงแนะนำให้ลองเริ่มต้นด้วย 3 คำถามพื้นฐานนี้ไปลองใช้ดูก่อน
คำถามที่ 1: เมื่อวาน ฉัน ทำอะไร ที่ช่วยให้ ทีมเรา สามารถส่งมอบได้ตาม Sprint Goal?
(จากประโยคสั้น ๆ ที่เราอาจคุ้นเคยกัน “เมื่อวานทำอะไร?”)
คำถามที่ 2: วันนี้ ฉัน ทำอะไร ที่ช่วยให้ ทีมเรา สามารถส่งมอบได้ตาม Sprint Goal?
(จากประโยคสั้น ๆ ที่เราอาจคุ้นเคยกัน “วันนี้มีแผนจะทำอะไร?”)
คำถามที่ 3: ฉัน เจอ และ/หรือ เห็นว่า ทีมเรา มีอุปสรรคควากหนาม ที่จะทำให้เราไปสู่ Sprint Goal ไม่ได้?
(จากประโยคสั้น ๆ ที่เราอาจคุ้นเคยกัน “เจอปัญหาอะไรบ้าง?”)
คำถามที่สำคัญที่สุด คือ คำถามที่ 3 เพราะปัญหาที่เกิดขึ้นคือสิ่งที่จะต้องระบุหรือขอความช่วยเหลือจากคนในทีม อะไรที่เจอปัญหาแต่ยังแก้ไม่ได้ หรือที่แก้ได้แล้วแต่ก็ไม่อยากให้คนในทีมเจอเหมือนเรา ก็จำเป็นต้องสื่อสารออกมาให้คนในทีมรับรู้
Development Works พัฒนา และส่งมอบ ทีละชิ้นงานตามลำดับความสำคัญ
Development Works คือ เราจะเปลี่ยนความต้องการ/คำสั่งงาน ออกมาเป็นชิ้นงานยังไง?
- กรอบระยะเวลา → เกิดขึ้นระหว่างวันที่ 2 — วันที่ 9 ของ Sprint
- วันอังคาร — วันพฤหัสบดี เวลา 10:00–18:00 น. (แล้วแต่เวลาเลิกงานของบ.)
- เวลาทำงานก็จะต้องทำตามลำดับความสำคัญ (Order) ที่ Product Owner ได้จัดเรียงไว้ตอนวางแผนงาน (กินข้าวทีละคำ ทำงานทีละอย่าง)
การทำงานเป็น Sprint ไม่ได้ทำให้เราทำงานได้เร็วขึ้น
ยกตัวอย่างเช่น
เริ่มพัฒนา Product Backlog Item 1 ก่อน และจะต้องส่งมอบครบตาม DoD ที่ได้กำหนดไว้ แล้ว Product Owner เปลี่ยนสถานะเป็น Done แล้วถึงจะไปทำ Product Backlog Item 2 ถัดไป
แต่ในความเป็นจริง ไม่ได้ง่ายอย่างที่เห็น เพราะบางครั้ง Product Owner ก็ไม่ได้เป็นเจ้าของ Requirements จะเป็นบุคคลที่ 3 แทน และคนที่จะตรวจรับงานก็จะเป็น เจ้าของ Requirements เอง
ยกตัวอย่างเช่น
K.New เป็น Product Owner → ทำ Mobile Application ของ SCK Bank
K.Jang ฝ่ายสินเชื่อ (เจ้าของ Requirements) → อยากได้ฟีเจอร์ แสดงยอดค้างจ่ายที่เกิน Due และชำระเงินกู้ผ่านทาง QR Code ได้
ประมาณการณ์ไว้ว่าจะเกิดขึ้นระหว่างวันที่ 2 — วันที่ 5 ของ Sprint
เพราะฉะนั้นในชีวิตจริง Product Owner ก็อาจไม่ใช่คนที่รู้รายละเอียดทั้งหมด
หลังจากทีมพัฒนา ดำเนินการพัฒนา Product Backlog Item นี้เสร็จแล้ว มาเป็น Version ที่สามารถใช้งานได้จริง จะติดตั้ง Application ของ SCK Bank บน UAT แล้วส่งมอบต่อให้ K.Jang ตรวจรับ และเปลี่ยนสถานะเป็น Done
ซึ่งวันที่ตรวจรับจะต้องอยู่ในกรอบเวลา ระหว่างวันที่ 2 — วันที่ 5 ของ Sprint ตามที่วางแผนงานเอาไว้เท่านั้น
หลาย ๆ ที่จะบอกว่าเป็นไปไม่ได้ที่จะทำ UAT ภายใน 2–3 วัน จากปกติที่จะ UAT ช่วงท้าย ๆ ของโครงการ
อีกกรณีที่สามารถเกิดขึ้นได้อีกก็คือ ในระหว่างที่พัฒนาอยู่นั้นทีมเจอปัญหา และส่งผลกระทบต่อ Sprint Goal
ยกตัวอย่างเช่น
Development Team กำลังอยู่ระหว่างการพัฒนา Product Backlog Item 2 ซึ่งจะอยู่ในช่วงวันที่ 6 — วันที่ 7 ของ Sprint และคาดว่าจะเสร็จและสามารถส่งมอบได้ในวันที่ 8 ของ Sprint
แต่ Development Team เจอปัญหา และมันส่งผลกระทบต่อ Sprint Goal ที่กำหนดไว้ และไม่สามารถไปต่อได้ เช่น เจอปัญหา วันที่ 7 เวลา 11:45 น. ของ Sprint
ดังนั้น จำเป็นต้องมีการปรับแผนงาน (Replan)
Scrum บอกไว้ว่า “ทีมพัฒนา สามารถขอเรียกประชุมได้ตลอดเวลา หลังจาก Daily Scrum เมื่อเจอปัญหาที่ส่งผลกระทบกับ Sprint Goal เพื่อ แจ้งปัญหา ผลกระทบ และแผนงานที่จะต้องปรับเปลี่ยน”
Product Owner สามารถเรียก Development Team ประชุมได้ทันทีในวันที่ 7 เวลา 11:55–12:30 น. และ Development Team จะบอกเล่าถึงปัญหาที่เจอ ว่าติดปัญหาที่ Product Backlog Item ไหน อย่างไรบ้าง
จากตัวอย่างคือ ทีมเจอปัญหาที่ Product Backlog Item 2
สิ่งที่ Development Team จะต้องทำต่อก็คือ เสนอว่าขอปรับแผนงาน (Replan) จากที่เคยให้สัญญาไว้ว่าจะทำทันทั้งหมด ในตอนที่ทำ Sprint Planning แต่ในวันนี้ Development Team คาดการณ์ว่าจะไม่สามารถทำ Product Backlog Item 3 และ Product Backlog Item 4 ได้ทัน น่าจะทำได้ถึงแค่ Product Backlog Item 2 เท่านั้น
สิ่งที่ Development Team นำเสนอนั้นก็เพื่อให้ Product Owner ตัดสินใจ
เมื่อ Product Owner รับฟังปัญหา เห็นชอบ และตัดสินใจแล้ว ก็จะต้องไปปรับลดใน Sprint Goal ที่จะถูกใช้ใน Daily Scrum + Sprint Review
หลังจากมีการ Replan แล้ว Product Owner จะต้องสื่อสารกลับไปให้ผู้ที่มีส่วนเกี่ยวข้อง ทั้งโดยตรงและโดยอ้อม ได้รับรู้ทุกคน
Sprint Review สาธิตผลิตภัณฑ์พร้อมใช้งาน และสรุปภาพรวมการพัฒนา
Sprint Review จะเกิดขึ้นในวันสุดท้ายของ Sprint
- กรอบระยะเวลา → ไม่เกิน 1–2 ชั่วโมง จะเกิดขึ้นในวันที่ 10 ของ Sprint
- วันศุกร์ เวลา 10:00 — 11:00 น. หรือ 10:00 — 12:00 น.
- เป็นการนำเสนอภาพรวม หรือสาธิตการใช้งาน
ใน Sprint Review จะประกอบไปด้วย Product Owner และ Development Team
และที่ Scrum ไม่ได้ระบุไว แต่สามารถเข้าร่วมได้ ก็คือ Stakeholder ที่ถูกเชิญโดย Product Owner เช่น ผู้ที่เกี่ยวข้องกับ Product หรือ ทีมผู้บริหาร หรือ ตัวแทนลูกค้า
ขั้นตอนการทำ Sprint Review
ลำดับที่ 1
Product Owner กล่าวต้อนรับ และแจ้งเพื่อทราบว่า Sprint นี้มี Product Backlog Item ใดบ้างที่ เสร็จ และพร้อมใช้งานจริง และ มี Product Backlog Item ใดบ้างที่ ไม่เสร็จ หรือ มี Product Backlog Item ใดบ้างที่ ยังไม่ได้ลงมือพัฒนา
ลำดับที่ 2
Development Team แจ้งให้ Stakeholder ทราบ หรือ สรุป เพื่อแบ่งปันข้อมูลว่า Sprint นี้ มีปัญหาอะไรที่เกิดขึ้นและแก้ไขไปแล้ว หรือ เจอปัญหาที่ต้องการการสนับสนุนจาก Stakeholder และ มีเรื่องดี ๆ หรือ สิ่งที่พัฒนาขึ้น เช่น ทักษะ ประสบการณ์ ที่เกิดขึ้น
ลำดับที่ 3
สาธิต Product Backlog Item ที่ เสร็จ และพร้อมใช้งาน และ เอา Product Backlog Item ที่ เสร็จ และพร้อมใช้งาน ให้กับทาง Stakeholder ได้ทดลองใช้งาน หรือ สาธิต Product Backlog Item ที่ยังไม่เสร็จ ให้กับทาง Stakeholder ได้ดูด้วยก็ได้ ซึ่งทั้งหมดนี้จะเป็นใครก็ได้ที่จะสาธิต
และอาจจะสรุปผลลัพธ์ที่ได้จากการนำ Product Backlog Item ที่ เสร็จ และพร้อมใช้งาน ไปทดลองให้กลุ่มเป้าหมายใช้งาน และเก็บผลการใช้งาน ผลความพึงพอใจ
Product Backlog Item ที่เสร็จ หรือไม่เสร็จ ที่จะสามารถสาธิตได้ จะต้องอยู่บน Environments UAT หรือ Pre-Production เท่านั้น จะไม่มาสาธิตผ่านเครื่องของ Developer หรือใน Local ส่วนนี้มาจากที่มีการตกลงกันไว้ก่อนเริ่ม Sprint
ลำดับที่ 4
Stakeholder ให้คำแนะนำ ให้คำติชม มีไอเดียใหม่ ๆ นำมาซึ่งการ ลด ปรับ และ/หรือ แก้ไข ของ Product Backlog Item ที่เสร็จ หรือไม่เสร็จ หรือที่ยังไม่ได้ลงมือทำ
Feedback จาก Stakeholder จะถูกส่งกลับไปให้ Product Owner แล้ว Product Owner ก็จะนำไปประเมินและตัดสินใจว่าจะผลิตหรือไม่ผลิต และถ้าจะผลิต จะอยู่ในช่วงเวลาใด สามารถไปทำใน Product Backlog Refinement Workshops หรือ เวลาอื่น ๆ หลังจากจบ Sprint Review
ลำดับที่ 5
Product Owner สรุปภาพรวมของการพัฒนาผลิตภัณฑ์ เช่น งบประมาณเกินไม่เกิน และกำหนดวันที่จะเปิดให้บริการยังเป็นไปตามแผนหรือไม่
ลำดับที่ 6
Product Owner แจ้งถึง Next Sprint Goal ว่าคืออะไร และการไปสู่ Sprint Goal จะประกอบด้วย Product Backlog Item อะไรบ้าง
และ แผนงานสำคัญ/Key Milestones ของ Sprint เช่น วันที่จะนำไปให้ตัวแทนหรือกลุ่มเป้าหมายทดลองใช้งาน
Sprint Retrospective หาเรื่องที่ต้องพัฒนาดีขึ้นในอนาคตมาทำ
Sprint Retrospective จะเกิดขึ้นในวันสุดท้ายของ Sprint
- กรอบระยะเวลา → ไม่เกิน 2 ชั่วโมง จะเกิดขึ้นในวันที่ 10 ของ Sprint
- วันศุกร์ เวลา 14:00–16:00 น.
Sprint Retrospective ไม่ใช่แค่ Good, Bad, Try
จุดประสงค์จริง ๆ คือ พัฒนาให้ดีขึ้นอย่างต่อเนื่อง (Kaizen หรือ Continuous Improveme)
ถ้า Development Team ยังไม่เคยมีประสบการณ์มาก่อน ก็จะเป็นหน้าที่ของ Scrum Master ที่จะอธิบาย และดำเนินพิธีกรรมนี้ และ Scrum Master จะต้องเก็บหลักฐานเพื่อสะท้อนให้ทีมเห็นว่ามีอะไรเกิดขึ้น (เหมือนเป็นกระจกเงา)
Scrum กำหนดมาให้ว่าจะมีเรื่องอะไรบ้าง ดังนี้
Scrum Master จะเลือกหยิบเรื่องพวกนี้ขึ้นมาคุยกับ Development Team ระบุเลยว่าเรื่องใดบ้างที่เขาอยากจะปรับให้ดีขึ้น โดยเลือกมา 1 หรือ 2 หัวข้อ จากด้านบน
และต่อมาต้องสร้างแผน ว่าเราจะปรับให้มันดีขึ้นอย่างไร พร้อมพิสูจน์ได้ว่าเราดีขึ้นจริง ๆ แล้วนำแผนที่ได้มาไปไว้ที่ Next Sprint Goal ด้วย เพราะฉะนั้นจะเกิดการพัฒนาที่ Next Sprint Goal หรือ Sprint ต่อ ๆ ไป
Development Team จะต้องเป็นคนกำหนดแผนต่าง ๆ ขึ้นเอง แต่ถ้าหากว่า Development Team ทำไม่ได้ ก็เป็นหน้าที่ของ Scrum Master ทำให้ดูเป็นตัวอย่าง
อะไรที่ดีขึ้น คงไว้
อะไรที่ต้องปรับ เอากลับมาวิเคราะห์ และถ้าออกแผนได้ ให้เอาไปใช้ที่ Next Sprint
และที่สำคัญคือ ต้องวัดได้ว่าเราดีขึ้นจริง หรือ มาถูกทางแล้วจริง ๆ
จบแล้วค่าาา ✌🏻
ส่วนตัวเราคิดว่าการได้เรียนรู้เรื่องนี้นั้นอาจจะยังไม่ลงลึกเกี่ยวกับ Agile Software Development มากนัก แต่มันก็ทำให้เราสามารถมองเห็นถึงภาพรวมหรือคอนเซปของ Agile Software Development ได้ค่ะ ทำให้เราพอจะเข้าใจแล้วว่าเขามีพิธีกรรมหรือขั้นตอนการทำงานอย่างไรกันบ้าง
และเราหวังว่าบทความทั้ง 3 ของเรานั้น จะเป็นประโยชน์ต่อคนที่สนใจไม่มากก็น้อยนะคะ เอาไว้ถ้าได้มีโอกาสศึกษาเรื่องนี้อีกเมื่อไหร่ จะมาบอกเล่าให้อ่านกันอีกแน่นอนค่ะ ขอบคุณทุกคนมากนะคะ
