ทำงานด้วยหลักการ Agile - Scrum Framework ด้วยทีมที่จำกัด หรือคนเดียวจะทำอย่างไร
Table of contents
Intro
สวัสดีครับ วันนี้อยากจะแชร์มุมมองการทำงานด้วย Agile Framework ซึ่งเป็นหลักการทำงานประเภทหนึ่ง แต่สงสัยไหมว่าทำงานก็ต้องมีหลักการ (framework) การทำงานด้วยเหรอ ? ก็เพราะจะได้มีขั้นตอน กระบวนการ และการวัดผลได้
Agile Framework ไม่ใช่เรื่องใหม่อะไร มีนานแล้ว และมีหลาย ๆ องค์กรใช้หลักการนี้ในการบริหารงาน แต่โดยปกติแล้วทำงานด้วยหลักการทำงานด้วย Agile Framework ต้องทำหลายคน แต่ด้วยข้อจำกัด บทความนี้จะพูดถึงถ้าเราต้องทำงานคนเดียวหรือมีทีมไม่กี่คน แล้วอยากใช้ Framework นี้มาช่วยบริหารงานจะทำอย่างไรได้บ้าง 📊
Scrum Work Process from (https://www.mimeo.com/blog/three-reasons-scrum-master-certified/)
ก็อย่างที่บอก Agile Framework ไม่ใช่เรื่องใหม่อะไร หากลองค้นหาข้อมูลใน Google ก็จะพบผู้เขียนบทความและอธิบายไว้ค่อนข้างเยอะ (อาจจะเคยอ่านมาบ้าง) แต่บทความนี้จะนำเสนอ Agile Framework ที่แตกต่างออกไป (จะเรียกว่าสรุปก็ได้) เพื่อให้กระชับและเข้าใจง่ายขึ้น 💡🎉
Agile Framework
TL; DR; Agile Framework คือหลักการบริหารโปรเจคงานแบบหนึ่ง
โฟกัสที่รอบการทำงาน
ที่เรียกว่าSprint
โดยโฟกัสความคืบหน้าตามรอบระยะเวลา เพื่อให้ลูกค้าจะได้ผลงานตามรอบของระยะเวลา และปรับแก้ไขข้อผิดพลาดได้อย่างรวดเร็ว เพื่อให้ตรงกับความต้องการลูกค้า
*Framework คือกรอบหรือข้อตกลงสำหรับการใช้งาน โดย Framework ได้กำหนดกฎเกณฑ์สำหรับการใช้งานไว้แล้วซึ่ง Framework เหมาะสำหรับการพัฒนาระบบเป็นทีม ที่ต้องการความยืดหยุ่น กรอบแบบแผนที่ชัดเจน เพื่อใช้สื่อสารกันในทีมได้ง่าย และประเมินผลได้
คำศัพท์
- Sprint คือรอบของการทำงาน (cycle) โดยการกำหนดรอบขึ้นอยู่กับเราเองหรือทีม ส่วนใหญ่รอบจะเป็น 1-4 สัปดาห์ เช่น 1 Sprint = 2 สัปดาห์
- Product Owner คือผู้ที่เป็นเสมือนลูกค้า หรือตัวแทนลูกค้า
- เขียน Product backlog items
- เขียน User Story ใช้อธิบาย Product
- จัด Backlog ที่เขียนไว้ใส่ใน Sprint เพื่อเรียงลำดับงาน ก่อน-หลัง ที่อยากจะเห็นในแต่ละ Sprint
- Product backlog คือรายการลิส (items) ความต้องการของ Product หรือ Requirement Specification (งานที่ยังไม่ได้ทำ)
- มอง Product เป็นงาน 1 ส่วนของโปรเจค (module)
- 1 Product ประกอบด้วยหลาย Items
- 1 Item ประกอบด้วยความหมายและผลลัพธ์ที่ต้องการ
- Scrum Team คือทีมที่ลงมือทำงานกัน
- ไม่แบ่งว่าใครทำหน้าที่อะไร
- ทุกคนสามารถทดแทนกันได้เสมอ
- ช่วยกันประเมิน Story Point ของ Backlog (อารมณ์เหมือนช่วยกันให้คะแนนความยากง่ายของงาน)
- Scrum Master คือผู้ที่คอยประสานงานระหว่าง Scrum Teams กับ Product Owner
- คอยดูแล Process ของ Framework
- จัดการ Scrum Board
- จัด Sprint Planning Meeting
- จัด Daily Scrum Meeting
- Story Point คือการกำหนดคะแนนความยากของงาน ซึ่งก็จะสัมพันธ์กับระยะเวลาที่ทำงานนั้น ๆ เช่น
- 0.5 story point
- 1 story point
- 2 story point
- 3 story point
- อื่น ๆ
- แต่ต้องทำความเข้าใจก่อนว่า Story Point คือ
คะแนนความยากของงาน
เท่านั้น! ย้ำว่าเท่านั้น ไม่ได้หมายถึงระยะเวลาของการทำงาน
- Sprint Planning Meeting คือการประชุมกันก่อนเริ่มแต่ละ Sprint ผู้มีส่วนร่วมได้แก่
- Scrum Team
- Scrum Master
- Product Owner
- Sprint Review ผู้มีส่วนร่วมได้แก่
- Scrum Team
- Scrum Master
- Product Owner
- Sprint Retrospective ผู้มีส่วนร่วมได้แก่
- Scrum Master
- Scrum Team
- Product Owner [optional]
ขั้นตอนการทำงานแบบ Agile
Scrum Board from (https://www.zoho.com/sprints/what-is-a-scrum-board.html)
- Product Owner เขียน Product backlog
- Sprint Planning Meeting
- นำ Product backlog มาแยกเป็น Tasks ย่อย ๆ
- ให้คะแนน Story Point ของแต่ละ Task
- Scrum Team แบ่ง Backlog task กันทำ
- Daily Scrum Meeting
- Sprint Review
- Sprint Retrospective
การวัดผลการทำงาน
การวัดผลอย่างง่ายของการทำงานแบบ Agile คือการดูผลจากกราฟ Burn Down Chart
Burn Down Chart from (https://worldofagile.com/blog/burn-down-chart/)
กราฟนี้บอกอะไร ? (แกน y คือจำนวน Tasks หรือ Story Point ที่ยังเหลืออยู่ / แกน x คือจำนวนวัน)
ความสัมพันธ์นี้สามารถอธิบายได้ว่า ยิ่ง Story Point ลดลง -> ระยะเวลาการทำงานก็จะลดตาม นั่นก็หมายความว่า
- Estimated Work (สีแดง) เส้นที่บอกว่างานควรเสร็จตอนไหน
- Actual Work (สีน้ำเงิน) เส้นที่บอกว่าครบกำหนดวันที่ควรเสร็จแล้ว แต่ Story Point ยังเหลือ (งานไม่เสร็จทันที่ควรจะเป็น)
ดังนั้นปัญหานี้อธิบายได้ 2 อย่างคือ
- มีบางช่วงที่ทำงานล่าช้า
- มีคนที่ทำงานเก่งกว่าเพื่อนในทีม โดยที่คนอื่น ๆ ยังทำไม่เสร็จ
ทีนี้เราก็จะเห็นแล้วว่า ช่วงไหนที่งานลดลงช้า-เร็ว ก็ต้องมาดูว่าเป็นเพราะอะไร แล้วก็ปรับแก้ไข
ข้อดีของการทำงานแบบ Agile
- ทุกฝ่ายแฮปปี้ ลูกค้าได้ เห็น product เร็วขึ้น (ไม่ต้องรอจนถึง final product)
- มีช่วงเวลาให้ปรับแก้ไข requirement
- ส่วน Developer ก็แฮปปี้ เพราะเห็นเลยว่าในแต่ละ sprint มีงานอะไรจะต้องทำบ้าง
- สามารถจัดแจงการทำงานให้เหมาะสมได้ งานก็จะไม่ overload
- ทุกคนในทีมเข้าใจ product เหมือนกัน สามารถทดแทนการทำงานกันได้
- Product ออกมาเร็ว ถึงแม้จะไม่ใช่ Final Product แต่ก็สามารถเอาไปใช้งานหรือทำให้ลูกค้าเห็นภาพได้ดีมากขึ้น
- สามารถติดตามการทำงาน และประเมินผลการทำงานได้อย่างมีประสิทธิภาพ
ข้อเสียของการทำงานแบบ Agile
- กระบวนการทำงานของ Framework อาจจะล่มได้ ถ้า Scrum Master ไม่จัดการ Process ต่าง ๆ ได้ดีพอ
- ทุกคนต้องเข้าใจ Process ของ Framework และบทบาทหน้าที่ของตนเอง เพื่อจะได้ทำงานอย่างมีประสิทธิภาพ
- เข้มงวดกับการส่งงานให้ทันตามกำหนด
- การทำงาน บางทีก็ขึ้นอยู่กับลูกค้ามากเกินไป ทำให้บางครั้งลูกค้าไม่ชัดเจน หรือ PO สื่อความหมายไม่ชัดเจนอาจจะทำให้งานเดินไปผิดทาง
ตารางสรุป
# | Process | Actors | Mono | Detail |
---|---|---|---|---|
1 | Product Owner เขียน Product backlog | Product Owner | เป็น PO และรับ Requirements | เขียน Epic, เขียน User Story, เขียน Backlog และเรียงลำดับ Backlog ว่าอยากเห็นอะไรก่อนหลัง *สามารถเขียน Blacklog ทิ้งไว้ หรืออะไรที่นึกออกไว้ก่อนก็ได้ |
2 | Sprint Planning Meeting | Product Owner, Scrum Master, Scrum Team | ทำความเข้าใจ Requirements และกำหนดผลลัพธ์ที่อยากเห็น | ก่อนเริ่มแต่ละ Sprint ก็จะต้องมีการคุย/วางแผนกันระหว่าง Product Owner — Scrum Master — Scrum Team เพื่อให้เข้าใจตรงกันทั้งในเรื่องของ Requirement และการทำงานว่า ผลลัพธ์สุดท้ายใน Sprint นั้นจะต้องได้อะไรออกมา (ในจุดนี้การออกแบบระบบจะถูกทำโดย Scrum Team โดยมี Scrum Master เป็นคนตัดสินใจชี้ขาดว่าโอเคหรือไม่โอเค) |
3 | นำ Product backlog มาแยกเป็น Tasks ย่อย ๆ | Scrum Team | ย่อย task จาก Backlog | Scrum Team จะหยิบเอา Backlog แต่ละ card มาแตกออกเป็น task ย่อย ๆ ว่ามีอะไรต้องทำบ้าง |
4 | ให้คะแนน Story Point ของแต่ละ Task | Scrum Team | ให้คะแนน Story Point | ช่วยกันประเมิน Story Point |
5 | Scrum Team แบ่ง Backlog task กันทำ | Scrum Team | เลือก Task ที่ต้องการทำก่อน | Assign task ให้สมาชิกในทีม หรือสมาชิกในทีมอยากเลือก task เองก็ได้เช่นกัน |
6 | Daily Scrum Meeting | Scrum Team | ทุก ๆ 24 ชม. บันทึกข้อความไว้ว่าเราเมื่อวานทำอะไรไปบ้าง ติดปัญหาอะไร วันนี้จะทำอะไร | ทุก ๆ 24 ชม. Scrum Team จะมี Daily meeting โดยจะรวมตัวคุยกัน ทุกวัน ใช้เวลาไม่นาน ว่าเมื่อวานทำอะไรไปแล้วบ้าง ติดปัญหาอะไรหรือเปล่า (ถ้าติดก็จะได้ช่วยกันหาทางออก เช่น อาจจะให้ใครเข้าไปช่วยตรงจุดนั้น) แล้ววันนี้จะทำอะไรต่อ (บางครั้งเรียก Stand-up meeting) |
7 | Sprint Review | Product Owner, Scrum Master, Scrum Team | ประเมินผลลัพธ์ว่าตรงตามที่ต้องการหรือไม่ | เมื่อจบรอบ Sprint แล้ว SM, ST ส่งมอบงานกับ PO อาจจะมีการคุยเกี่ยวกับปัญหาของ Product (backlog) จากนั้น PO ก็จะไปส่งมอบ หรือนำเสนองานกับลูกค้า และเก็บ Feedback กลับมา |
8 | Sprint Retrospective | Scrum Master, Scrum Team | ทบทวนการ Sprint ที่ผ่านมา ปัญหา หรือการให้คะแนน Story Point | เป็นการคุยกันระว่าง ST กับ SM โดยหาก Sprint Review มีไว้เพื่อการพูดคุยเพื่อปรับปรุงตัวโปรเจกต์หรือโปรดักต์ Sprint Retrospective ก็อาจจะมีไว้เพื่อการปรับปรุง "กระบวนการทำ Scrum" ซึ่งอาจเกี่ยวข้องไปถึงการทำงานของสมาชิกแต่ละคน รูปแบบการสื่อสาร กระบวนการ เพื่อให้การทำ Scrum มีคุณภาพดีขึ้นในรอบ Sprint ถัดไป |
References
- HREX, (2022, October 25). คู่มือการทำ Scrum สำหรับ HR ภาคภาษาไทยฉบับสมบูรณ์ | HREX.asia. Th. https://th.hrnote.asia/orgdevelopment/220302-ultimate-scrum-guide-for-hr/
- Pratyaroongroj, T. (2018, August 30). ทำยังไงให้ Sprint Planning ของเรามีประสิทธิภาพ? | by Tanawat Pratyaroongroj | LINE Developers Thailand | Medium. Medium. https://medium.com/p/e60f557aef13
- Ongvisatepaiboon, K. (2016, August 1). เมื่อเรากำลังจะเข้าสู่ยุคของ ‘Agile’ | by Kanmanus Ongvisatepaiboon | Medium. Medium. https://medium.com/p/7f04a6ab554d
- Wikipedia, (2023, June 18). Burndown chart - Wikipedia. En. https://en.wikipedia.org/wiki/Burndown_chart
- Zoho, (2023, July 13). What is Scrum Board? | Online Scrum Boards Vs Physical - Zoho Sprints. Zoho. https://www.zoho.com/sprints/what-is-a-scrum-board.html
- Lukić, D. & Ackerson, D. (2023, April 6). Benefits of Agile Methodology - Semaphore. Semaphoreci. https://semaphoreci.com/blog/agile-methodology
- Mimeo, (2022, November 1). Three Reasons to Become Scrum Master Certified - Mimeo US. Mimeo. https://www.mimeo.com/blog/three-reasons-scrum-master-certified/