ปัญหา Story Point ใน Agile เมื่อคิดว่าตัวเองเก่ง และชอบคิดว่าจะทำงานทัน แต่เอาเข้าจริงไม่เสร็จทันตามกำหนด
Table of contents
Intro
สวัสดีครับ นี่คือบทค วามเกี่ยวกับ Story Point และปัญหา Agile ที่เกิดขึ้นในการทํางานใน Agile Framework
สำหรับใครที่เคยทำงานในรูปแบบ Agile Framework แต่ไม่เข้าใจว่า Story Point คืออะไร และมีปัญหาอะไร วันนี้เราจะมาพูดคุยเกี่ยวกับ Story Point ใน Agile Framework
Agile Framework คืออะไร ? อ่านได้ที่ Agile Framework คืออะไร
ปัญหาเมื่อคิดว่าตัวเองเก่งเกิน เมื่ออยู่ใน Agile Framework
เคยคิดว่าตัวเองเก่งไหมครับ ? 😄
แบบว่าเหมือนจะหลงตัวเองสักหน่อย หรืออาจจะเพราะว่าเราทำงานนี้มานานจนคิดว่าเราแก้ไขและรับมือได้แทบจะทุกปัญหา และไม่ว่าจะเป็นงานรูปแบบไหนเราก็ทำได้
และเคยมั้ยครับ เมื่อมีผู้สั่งงาน โดยเขาก็ก็ถามว่างานนี้ใช้เวลาเท่าไหร่ หรือกี่วันเสร็จ ?
คุณตอบแบบไหนครับ ? 😄
- ตอบแบบมั่นใจว่างานจะเสร็จในกําหนด และไม่มีปัญหา 2 วัน ครับ
- ตอบแบบไม่มั่นใจว่างานจะเสร็จในกําหนด และไม่มีปัญหา 2 วัน ครับ
ถ้าคุณตอบแบบมั่นใจว่างานจะเสร็จในกําหนด แสดงว่าบางที "คุณอาจจะคิดว่าตัวเองเก่ง และรับมือได้" 😄
แต่เอาเข้าจริง งานเสร็จไม่ทันตามกําหนด ?
เมื่ อเข้าใจว่างานที่เราตั้งใจว่าไว้ 2 วัน แต่เอาเข้าจริงกลับกลายว่าไม่เสร็จทันตามกําหนด คุณคิดว่าปัญหาเกิดจากอะไร ?
ด้วยเหตุผล หลายอย่างที่เราคาดไม่ถึง ? 😄
- งานมีปัญหาระหว่างทาง โดยมีปัจจัยที่เราควบคุมไม่ได้
- เครื่องมือที่ใช้ในการทำงาน มีปัญหาและไม่สามารถใช้งานได้
- ป่วย ?
- ติดภาระกิจสำคัญ ?
- ขี้เกียจ ? 😅
- ปัจจัยที่เราควบคุมได้
- ขอบเขตการทำงาน ไม่เหมือนที่ประเมินไว้
- ขอบเขตการทำงาน เกินไปที่ประเมินไว้
แน่นอนครับ ว่าปัญหาทั้งหมดที่ว่ามา เราสามารถพูดคุยต่อรองระยะเวลาเพิ่มได้ระหว่างทาง แต่อย่าลืมว่า "มันก็ไม่เสมอไป" 😄
เพราะก็มีหลาย ๆ เหตุผล เช่น กรอบระยะเวลาที่ต้องส่งงานบางครั้งก็เลื่อนไม่ได้ อีกท ั้งมันก็เสียคำพูดเราเองที่มั่นใจว่างานจะเสร็จในกําหนด และไม่มีปัญหา และทำให้ต้องปรับปรุง Agile ที่กำลังทำอยู่ เช่น เพิ่ม Sprint ทำให้เกิดระยะเวลาเพิ่มขึ้นไปอีก
ปัญหาของ Story Point
สำหรับใครที่เคยทำงานในรูปแบบ Agile Framework แต่ไม่เข้าใจว่า Story Point คืออะไร ที่จริงผมเคยเขียนไว้อธิบายไว้ที่ "Story Point คืออะไร"
จะนำมาเล่าอีกครั้งคือ
Story Point คือการกำหนดคะแนนความยากของงาน ซึ่งก็จะสัมพันธ์กับระยะเวลาที่ทำงานนั้น ๆ เช่น
- 0.5 story point
- 1 story point
- 2 story point
- 3 story point
- อื่น ๆ แต่ต้องทำความเข้าใจก่อนว่า Story Point คือ คะแนนความยากของงาน เท่านั้น! ย้ำว่าเท่านั้น ไม่ได้หมายถึงระยะเวลาของการทำงาน
เข้าใจว่าอะไรครับ ?
จากข้อมูลข้างบนก็พอดูออกว่าก็เหมือนเป็นการกําหนดคะแนนความยากของงาน (เป็นตัวเลข)
แต่อย่าลืมว่า Story Point ไม่เท่ากับระยะเวลาที่ทำงานนั้น ๆ
แต่ส่วนใหญ่ผู้ที่ใช้ Agile Framework จะเข้าใจว่า Story Point มีความสำพันธ์กับระยะเวลาที่ทำงาน (รวมถึงตัวผมเองด้วย 😅)
เช่น เราบอกว่า 1 story point ทำ 1 วันก็เสร็จ
พอเห็นปัญหาแล้วใช่ไหมครับ 😄
แต่ในความเป็นจริง Story Point ไม่เท่ากับระยะเวลาที่ทำงานนั้น ๆ เช่น
- 1 story point ทำ 1 วันก็เสร็จ
- 1 story point ทำ 3 วันก็เสร็จ
โดยก็ย้ำเสมอว่า Story Point ไม่เท่ากับระยะเวลาที่ทำงานนั้น ๆ ซึ่งเอาจริง ๆ ส่วนตัวก็ไม่ชอบกำหนดว่าจะทำงานกี่วันเสร็จ เพราะเอาเข้าจริงมันก็บอกได้ยาก แต่สุดท้ายเราก็ต้องแจ้งผู้สั่งงานให้ทราบอยู่ดีเพราะ "อย่างน้อยก็เพื่อความหวังว่างานจะเสร็จภายในวันที่ ..."
ดังนั้นมันก็เลี่ยงไม่ได้ที่เราจะพยายามหาความสัมพันธ์ระหว่าง Story Point กับระยะเวลาที่ทำงานนั้น ๆ ใช่ไหมครับ 😄
กฎเกณฑ์ Story Point
ที่จริงกฎเกณฑ์ในการกำหนด Story Point (ไม่ได้มีข้อบังคับ) อธิบายคือ กำหนดเป็นตัวเลขแบบไหนก็ได้ตามหลักการที่เราต้องการ
ทำให้ให้เกิดความยุ่งยากมาก ๆ ในการกำหนด Story Point เช่น
- งานนี้ควรกำหนดกี่ Story Point
- แน่นอนว่าในช่วง Sprint Sprint Retrospective ควรเอาเรื่อง Story Point ที่ผ่านมา เพื่อพูดคุยกับทีมเพื่อปร ับปรุงให้ดีขึ้น
- ทำให้การกำหนด Story Point ก็อยู่ที่ประสบการณ์ล้วน ๆ
แนวทางแก้ปัญหา Story Point
จากที่เราเข้าใจว่า Story Point เป็นการสมมุติตัวเลขขึ้นมาคือความยากของงาน (ไม่เท่ากับระยะเวลาที่ทำงานนั้น ๆ)
ปัญหา
- เรากำหนด Story Point เป็นตัวเลขเท่านี้ แต่งานไม่เสร็จในระยะเวลาที่กําหนด
- มีปัจจัยอื่น ๆ ทั้งที่ควบคุมได้ และควบคุมไม่ได้ ทำระยะเวลาไม่เสร็จในระยะเวลาที่กําหนด
สิ่งที่เราทำได้
- ในช่วง Sprint Retrospective ควรเอาเรื่อง Story Point ที่ผ่านมา เพื่อพูดคุยกับทีมเพื่อปรับปรุงให้ดีขึ้น
- แนวคิดการกำหนด Story Point
- เมื่อได้รับ Backlog ให้แยกย่อยงานใน Backlog ให้เป็น Tasks และให้คะแนน Story Point ใ ห้กับแต่ละ Task
- การแยกย่อย Task ที่เป็นไปได้มากที่สุดใน Backlog (ข้อนี้สำคัญ และค่อนข้างที่จะต้องใช้ประสบการณ์)
แนวคิดการกำหนด Story Point
ถ้าพูดถึงแนวคิดการกำหนด Story Point เรื่องนี้ชัวร์ ๆ เลยว่าหลาย ๆ องค์กรที่ใช้ Agile Framework จะมีการกำหนด Story Point ที่ไม่เหมือนกัน
และถ้าท่านได้อ่านบทความนี้มาตั้งแต่ต้นจนจบจะมองเห็นปัญหาของเรื่อง Story Point ที่ส่งผลในการกำหนดระยะเวลาทำงาน ดังนั้นแนวทางในการแก้ปัญหา (ที่ส่วนตัวคิดขึ้นมา) Story Point คือ
- Story Point ควรเป็นตัวเลขแบบก้าวกระโดด
- แม้ว่า Story Point เป็นการสมมุติตัวเลขขึ้นมาคือความยากของงาน (ไม่เท่ากับระยะเวลาที่ทำงานนั้น ๆ)
- ดังนั้นถ้าเรากำหนด Story Point แบบก้าวกระโดดโดยจะเผื่อเวลาสำหรับปัจจัยที่เราคาดไม่ถึง
เช่น
| Story Point | ระยะเวลา | หมายเหตุ |
|---|---|---|
| 0.5 | 6 ชั่วโมง | ที่จริงผมไม่ชอบให้มี 0.25 โดยถ้างานที่ง่ายก็จะกำหนดเป็น 0.5 แต่สามารถทำเร็วกว่ากำหนดได้ |
| 1 | 1 วัน | |
| 2 | 3 วัน | |
| 3 | 5 วัน | |
| 5 | 7 วัน | |
| 7 | 10 วัน |
ที่จริงตัวเลขนี้มีความสมดุลที่สุดแล้วในแง่ของการ + - ปัจจัยต่าง ๆ ที่จะไม่ขี้เกียจ และขยันจนเกินไป มีสมดุลกับชีวิต
และที่จริงบริษัทอื่น ๆ ที่ใช้ Agile Framework ก็สามารถกำหนด Story Point แบบก้าวกระโดดตามความเหมาะสมในแต่ละโปรเจคได้ ของบริษัทท่านได้
สรุป
สรุป การกำหนด Story Point และแนวทางในการแก้ปัญหามีสิ่งที่ทำจะทำได้คือ
สิ่งที่เราทำได้
- ในช่วง Sprint Retrospective ควรเอาเรื่อง Story Point ที่ผ่านมา เพื่อพูดคุยกับทีมเพื่อปรับปรุงให้ดีขึ้น
- แนวคิดการกำหนด Story Point (แต่ละโปรเจคอาจจะไม่เหมือนกันก็ได้)
- เมื่อได้รับ Backlog ให้แยกย่อยงานใน Backlog ให้เป็น Tasks และให้คะแนน Story Point ให้กับแต่ละ Task
- การแยกย่อย Task ที่เป็นไปได้มากที่สุดใน Backlog (ข้อนี้สำคัญ และค่อนข้างที่จะต้องใช้ประสบการณ์)
และแนวคิดและการพูดคุยปัญหาในบทความนี้ก็หวังว่าจะเป็นแนวทางในการแก้ปัญหา Story Point สำหรับทุก ๆ องค์กรที่ใช้ Agile Framework ให้ดีขึ้นได้ 😊
