ทำไมถึงไม่ใช้ Story Points และ Burndown chart แต่ถ้าอยากใช้ มันต้องใช้ยังไงกันแน่นะ? #LearningWithSCK

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

มาเริ่มกันที่ Story Points ก่อน

Story Points

สำหรับเราที่เคยเจอ เป็นรูปแบบของเลข Fibonacci คือ 1, 2, 3, 5, 8, 13, 21, … ซึ่งแต่ละทีม ก็มีการใช้ตัวเลขไม่เหมือนกัน แล้วพอเอาผลมารวมกัน แต่ละทีมก็จะมีตัวเลขของตัวเองว่าในแต่ละ Sprint รับได้ทั้งหมดกี่ Points

ซึ่ง Points ที่ได้มานี่ มันก็เอาไปเทียบกันระหว่างทีมไม่ได้อีก

https://en.wikipedia.org/wiki/Fibonacci_sequence

ด้านพี่นุ่น เจอทั้งตัวเลขและเจอแบบ Size เสื้อ ที่บางที Size ประเมินเท่ากัน แต่เวลาไม่เท่ากัน ตกลงให้เชื่อถือเลขอะไรกันแน่? Size หรือเวลาในการทำงาน

https://www.c-sharpcorner.com/article/agile-story-point-estimation-techniques-t-shirt-sizing/

Story Points เป็นศาสตร์หน่ึงใน Extreme Programming (XP) คิดโดยคุณ Ron Jeffries

• ย้อนไปที่ปี 1999 มีชื่อว่า Gummi Bears และมีอีกชื่อว่า Story Points แล้วคุณ Ron ก็เอามันมาใช้
• ที่เขาใช้ตัวเลข Fibonacci เพราะมันง่ายในการประมาณการ ใช้ดูความห่างของแต่ละตัวเลข ซึ่งตัวเลขแต่ละตัวก็เกิดจากสองตัวข้างหน้าบวกกัน
• จริงๆ แล้ว Story Points ใช้เลขอะไรก็ได้
• Story Points ถูกเอามาใช้ในการ Estimate ตัว User Story (ที่มาจาก XP อีก)
• เหตุผลของการทำ Estimation คือ ใช้ในการสื่อสารให้คนที่ไม่ใช่ Technical สามารถเข้าใจได้ง่าย

การละเล่นนี้ คนที่จะเข้ามา Estimate คือ สมาชิกในทีมพัฒนา

• ซึ่งเราจะเจอการ Estimate แบบนี้ ในการทำงานรูปแบบ Sprint
• ผู้เข้าร่วมคือ Frontend(s), Backend(s), Tester(s)
• แต่ละคนจะมีไพ่ในมือ เรียกว่า Planning Poker ก็จะมีเลข 1, 2, 3, 5, 8, 13 (หรือ Size เสื้อ s, m, l, xl, …)

วิธีการคือ

1. PO หรือ BA เอางานเข้ามา (User Story แต่ละเรื่อง)
2. ทีมพัฒนาทำการพูดคุย ถามข้อสงสัย มองหารายละเอียดในสิ่งที่เกี่ยวข้องกับตัวเอง เพื่อเพิ่มรายละเอียดให้ชัดขึ้น
3. แต่ละคนครุ่นคิด แล้วยกไพ่ที่แสดงเลขของตัวเองในรอบแรก
4. จากนั้นให้บอกเล่าว่า ทำไมถึงเลือกตัวเลขนี้ แต่ละคนจะได้บอกเหตุผลของตัวเลขที่ตัวเองเลือก บางที่อาจจะสุ่ม บางที่อาจจะไล่ตัวเลขจากใหญ่สุดไปเล็กสุด แต่ทุกคนต้องได้พูด
5. เมื่อทุกคนได้พูด ได้ฟังเหตุผลของคนอื่น ได้รับข้อมูลกลับเข้าไปแล้ว ก็วิเคราะห์ใหม่ แล้วเลือกตัวเลขใหม่ ซึ่งจะปรับขึ้น ปรับลด หรือจะคงที่ตัวเลขเดิมก็ได้
6. เล่นไปเรื่อยๆ วนไปหลายๆ รอบ จนกว่าทุกคนจะเห็นภาพตรงกัน ได้เลขเดียวกันทุกคน (ซึ่งการจะได้เลขเดียวกัน จะต่อรอง จะชักจูงอะไรก็ได้ แล้วแต่เลย) ซึ่งตรงนี้เป็น “สมมติฐาน” ของ (เกือบ) ทุกคน ที่เห็นตรงกัน

อ้างอิงจากหนังสือ Agile Estimation and Planning อธิบายว่า มีการประมาณการอยู่สามแบบ คือ

1. Expert Opinion ผู้เชี่ยวชาญในแต่ละด้าน เช่น FE, BE, Tester บอกเหตุผล อธิบายได้ว่าทำไมถึงเป็นตัวเลขนี้ (ซึ่งไม่เกี่ยวกับตำแหน่ง Junior, Senior) เป็นกุศโลบายให้ทุกคนได้พูด ให้เหตุผล ให้คำมั่นสัญญา (ถ้าไม่ทำแบบนี้ จะเคยเจอที่ให้ Senior เลือกตัวเลข และอาจจะบวก % เพิ่ม ถ้าให้น้องทำงานนั้น)
2. Analogy การเทียบเคียง ใหญ่กว่า เล็กกว่า ใน Planning Poker ก็คือ การมีไพ่ในมือ แล้วบอกว่าแต่ละอันมีความใหญ่ต่างกันยังไง (เช่นเดียวกับ Size เสื้อที่ขนาดไม่เท่ากัน)
3. Disaggregation ถ้าใหญ่มาก แตกมันออก ยกตัวอย่างเช่น โต๊ะจีน มีอาหารหลายอย่างมาก คิดไม่ออกว่าต้องใช้เวลาเตรียมการและทำอาหารเท่าไหร่ ก็แตกมันออกทีละอย่าง ทีละเมนู แล้วใช้ข้อ 1., 2. อีกที

Story Points เป็น “สมมติฐาน” ของ (เกือบ) ทุกคน ที่เห็นตรงกัน

• ซึ่ง Points นี้ ไม่สามารถตีกลับไปเป็น manday(s) หรือ manhour(s) ได้
• แม้จะมีหลายคนพยายามสร้างตารางเทียบเคียง ระหว่าง Point กับ hour หรือ day ก็ตาม
• ก็จะมีอีกคำศัพท์ที่เรียกว่า “Velocity” จะ Link ไปที่ จำนวน Point ที่สามารถ Burn ได้ในแต่ละ Sprint

กระบวนการทำงาน

• เราเอา User Story เข้ามาทีละเรื่อง สมมติในภาพนี้มีสี่เรื่อง
• ใน Sprint Planning 1 และ/หรือ 2 ก็ทำการ Estimate ด้วย Planning Poker แล้วก็ได้ Points ของแต่ละการ์ดออกมา

• ทีนี้ ถ้าเราอยาก Track งานระหว่างการทำงานล่ะ? มันก็เกิด Burndown chart ขึ้นมา (ซึ่งหลังๆ ใน Scrum Guide ก็ไม่ค่อยกล่าวถึงคำนี้แล้ว)

ถ้าทีมมีความสามารถในการส่งมอบงานได้ทุกวัน ในอัตราเร็วคงที่ 39 Points จะเสร็จภายใน 10 วัน (1 Sprint) เป็นกราฟตามภาพด้านล่าง (ซึ่งเป็นภาพในอุดมคติมาก)

หลังจบ Sprint Planning นอกจากเราจะได้ Burndown chart มาแล้ว เราจะได้ Sprint Backlog มาอีกหนึ่ง (อาจจะเรียก Kanban Board หรืออะไรก็แล้วแต่ที่ แต่หน้าตาก็จะมีอย่างน้อยสามเลนคือ To Do — Doing — Done)

• เช้าวันที่สอง ก็ลากการ์ดใบแรกเข้าไปที่ Doing เพื่อเริ่มทำงาน (วันแรกไม่ได้ทำงาน เพราะ Planning อยู่ — Plan อะไรเยอะแยะะะะ เอาเวลาไปทำงานกันเถอะ)

• เช้าวันที่สาม Story ที่หน่ึงก็ยังไม่เสร็จ ก็ Plot กราฟ burndown ไปว่า วันที่สองก็ยังไม่มีอะไรเสร็จ

ถ้า Tools เป็น Digital เช่น Jira มันจะพล็อตกราฟอัตโนมัติ ถ้าเป็น Physical จริงๆ แล้วคนที่ควรพล็อตคือ Development Team แต่ส่วนมากก็ไม่ทำหรอก มันก็เลยกลายเป็นหน้าที่ของ Scrum Master หรือ PO หรือแม้แต่ PM

• วันที่สี่ Story ที่หนึ่งก็ยังไม่เสร็จอีก อยู่ระหว่างการทำ Test แต่ Dev ว่างแล้ว ก็เลยลาก Story ที่สองเข้ามาให้ Dev ทำก่อน

• ที่พี่หนุ่มเคยปฏิบัติมาในอดีต ณ วันที่ห้า จะต้องเริ่มดูละว่ามีอะไรเสร็จบ้างไหม

• ผ่านมาห้าวันแล้ว ถ้าไม่มีอะไรเสร็จเลย ต้องทำการ “ขอคืนของ (User Stories)” เช่น Story 3, 4 ไม่ทันแล้วแน่ๆ คืนให้ PO ไปเลย ซึ่ง PO ต้องยอมรับการขอคืนนี้

พอคืนของไป แปลว่า Points ทั้งหมด จาก 39 ลดเหลือ 18

พอคืนของกลับหา PO ได้ ทีมก็ต้องสู้ๆ ต่อไป

• วันที่สิบ ถึงวันที่ต้อง Review แล้ว (สมมติว่างานเสร็จ) กราฟมันจะปักลง

การย้ายไปช่อง Done ได้ จะมี DoD ที่ต้องผ่านทั้งหมด

• DoD คือ ข้อตกลงในการตรวจรับงาน ระหว่าง PO และ Development Team
• ซึ่งบางที่ก็จะเขียน DoD ใน Acceptance Criteria (แต่ที่เคยทำมา ไม่เคยเขียนเลยจ้ะ 55)
• ยกตัวอย่าง DoD เช่น มีการ Test เรียบร้อย และตรวจรับโดย PO

สมมติว่า ทีมเป็นสายแข็ง ไม่คืนของเลย (หรือไม่ PO ก็ไม่ให้คืน)

พอจบ 10 วัน มันก็อาจจะออกมาได้สามท่าคือ

• ไม่เสร็จเลย (เส้นสีชมพู) Velocity = 0 Points
• เสร็จบางส่วน (เส้นสีเขียว) Velocity = 20 Points
• เสร็จหมดแหละ (เส้นสีส้ม) Velocity = 39 Points

Velocity จะมีประโยชน์ ถ้าเราทำการ Re-estimate

• เพราะ Points ที่เราได้มา มันเกิดตอน Planning แปลว่า มันเกิดก่อนการลงมือทำงาน
• แต่เวลาทำจริง ทำเสร็จแล้ว มันอาจจะไม่ได้เลขนั้นตามที่ Plan ไว้ เป็นเลขที่สูงกว่า ต่ำกว่า หรือพอดีเป๊ะก็ได้
• เลยแนะนำให้ re-estimate Points หรือเพิ่มการใส่ Actual Points (ความเป็นจริง) เข้ามาด้วย

ข้อดีของการเอาตัวเลขจริงๆ ไปใช้คือ ช่วยให้ PO (หรือ PM) วางแผนในการประมาณการได้ว่า ทีมมี Velocity (ที่เกิดขึ้นจากการทำงานจริง) เท่านี้ ทีมจะต้องใช้เวลาทำงานทั้งหมดกี่ Sprint(s)

ถ้าทีมยังไม่เก่งมาก กราฟมันก็จะเป็นคลื่นหยึยๆ ไม่ได้มีตัวเลขคงที่ ก็จะหาค่า Avg. เอา ซึ่งจะเป็น Range: Max-Min (แล้วคนเอาไปใช้ส่วนมาก ก็จะหยิบค่า Max ซึ่งมันไม่ได้ไงงงง)

• สมมติใน Product Backlog เตรียมการไว้ประมาณ 200 Points ทีมน่าจะทำงาน 6 Sprints แหละ
• ถ้า Sprint แรก ทีมทำได้จริง 13 Points
• 200–13 = 187 Points แปลว่า ต้องใช้อย่างน้อย 15 Sprints ในการทำงาน (อันนี้คิดกันแบบตรงไปตรงมา)
• ซึ่งจริงๆ แล้ว มันก็คิดตรงไปตรงมาแบบนั้นไม่ได้ เพราะ บาง Story มันอาจจะยากมากกกกก ก็เป็นได้ (ง่ายมากไม่ค่อยเจอ ขอละเว้นเคสนี้ไว้)

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

เลยเป็นเหตุผลว่า ทำไมพี่หนุ่มไม่ใช้ Story Points และ Burndown chart
แต่ใช้ 3 เทคนิคการประมาณการ และ จัดบอร์ด (Sprint Backlog) ให้เป็น Dashboard

สำหรับเราในฐานะที่เคยเป็น Project Manager (PM) มา

Points ก็ไม่ได้ผิดอะไรนะ แค่มัน Convert ยาก เพราะสุดท้ายปลายทางเราอยากรู้ว่า จะใช้เวลาทำงานเท่าไหร่ ไม่ก็ของชิ้นนี้จะเสร็จเมื่อไหร่ ทำไมเราถึงไม่ Estimate กันเป็นชั่วโมงหรือเป็นวันไปเลยนะ (ตารางเปรียบเทียบ Points กับ Manday นี่ก็ผ่านมาแล้ว 5555)

อีกอย่างที่ชอบคือ จะ Estimate Points ก็ได้ แต่ขอ Actual ที่เกิดขึ้นจริงด้วย ขอสองค่าที จะได้รู้ว่าที่แพลนไว้ กับที่ทำได้จริงมันเหมือนกันหรือต่างกันอย่างไร เพราะมันส่งผลกระทบกับแผนงานที่วางไว้ ซึ่งวนกลับไปเรื่องเดิม เราอยากได้ชั่วโมงการทำงานจริงมากกว่า เพราะมันเอาไปทำเรื่อง Timesheet และคิด Budget โครงการต่อได้ง่ายกว่า

ส่วน Burndown เอาจริงๆ ไม่เคยใช้เป็นกิจลักษณะ เพราะอะไร? เพราะไม่เคยลากการ์ดทีละหนึ่งเลยไง 5555 ลากมาเต็มที่ ชีวิตเกินร้อย กองอยู่ตรง To do ครึ่งหนึ่ง กองอยู่ตรง Doing อีกครึ่งหน่ึง แล้วก็ค่อยลากไป Done กันตอนวันท้ายๆ หรือไม่ก็วันที่สิบนั่นแหละ กราฟมันก็เลยไม่ได้ทำหน้าที่ของมัน เพราะเราใช้ไม่เป็น -_- และปกติเมื่อจบแต่ละ Sprint ก็ดูแค่ Velocity ที่เกิดขึ้นจริง ดูซัก 4–5 Sprints ก็จะเริ่มหา Avg. ของทีมได้ ก็จะเอาค่านั้นมาเป็นตุ๊กตาในการจำกัดงานเข้า Sprint แค่นั้นเลย

สุดท้ายแล้ว “Plan to Replan” ยังคงเป็นคำที่ใช้ได้ตลอดไป

เพิ่มเติมอีกคำศัพท์หนึ่งก่อนหมดเวลา

Burnup chart

ยกตัวอย่างเช่น มีของที่รอผลิตอยู่ 20 User Stories แต่ละอันก็มีแต้มของมัน ถ้าทีมพัฒนาทำงานเสร็จ จำนวน Poins ก็เพิ่มขึ้น กราฟมันก็จะพุ่งขึ้น ซึ่งกราฟอาจจะออกมาได้สองหน้าตา เช่น

• สีเหลือง คือ ส่งได้เรื่อยๆ ในทุกๆ Sprint
• สีเขียว คือ มัดรวมก่อน แล้วค่อยไปส่งหลังจากผ่านไป 6 Sprints

(คิดต่อเอง) จริงๆ มันก็อาจจะเป็นเส้นกราฟที่ขั้นบันไดความกว้างไม่เท่ากันก็ได้นะ เช่น Sprint 1 ส่งไม่ได้ Sprint 2 ส่งได้ แต่พอ Sprint 3–4 ส่งไม่ได้อีกละ (ก็จะมี Points เท่ากับ Sprint 2 ยาวๆ ไป) ก็ต้องหาทางจัดการกันอีกทีหนึ่ง ว่าทีมติดปัญหาอะไร แล้วก็ค่อยๆ แก้กันไป

ภาพเต็มๆ ที่พี่หนุ่มวาดไประหว่างการสอน สามารถดูได้ที่ Link นี้