ถ้าเลี่ยงการ Estimate Story Point ไม่ได้

How to Make It Less Painful And More Effectively

ถึงเราจะพยายามอย่างยิ่งที่จะหลีกเลี่ยงการทำ Point Estimation เพราะจากประสบการณ์ส่วนตัวกระบวนการนี้ให้ประโยชน์ไม่คุ้มค่ากับเวลาที่เสียไป แต่โลกแห่งความจริงไม่ได้เป็นไปอย่างที่เราหวังไว้ … เราต้อง Estimate Story Point เพื่อสนองนีดคนบางคนอยู่ดี ☹ … ก็ได้วะ ลองดูซักตั้ง

1. Story Point คือขนาดของงานที่ไม่สามารถแปลงมาเป็นวันหรือชั่วโมงได้

ข้อควรจำข้อแรกคือ Story Point คือ Story Point โว้ยยย กรุณาอย่าถามว่ามันแปลว่า 1 Point = 1 วัน = 8 ชั่วโมงใช่มั้ย? มันไม่ใช่ แล้วไม่ต้องพยายามแปลงค่าให้มันด้วยนะ เสียเวลา … Story Point คือขนาดเพียวๆ (Pure Size) ของงานนั้นๆ มันจึงไม่มีหน่วยเป็น ชั่วโมง วัน เดือน ปี ใดๆทั้งสิ้น

2. Story Point บ่งบอกขนาดงานที่มีความสัมพันธ์กัน (Relative Size)

เมื่อพูดถึงขนาด Story Point จะบอกเราได้ถึงขนาดงานที่มีความสัมพันธ์ (Relative Size) กับ User Story อื่นๆใน Product Backlog เช่น ถ้า User Story — A มีขนาด 1 แต้ม ส่วน User Story — B มีขนาด 5 แต้ม แปลว่า User Story — B มีขนาดใหญ่กว่า A ประมาณ 5 เท่า

3. Story Point ควรเป็นเลขจากอนุกรมฟิโบนักชี่

ทำไมถึงต้องเป็นอนุกรมฟิโบนักชี่ (0, 1, 1, 2, 3, 5, 8, 13, …)? คำตอบคือเพราะในช่วงต้นๆความห่างของตัวเลขจะน้อยและจะเพิ่มขึ้นเรื่อยๆเมื่อเราไล่ลำดับที่สูงขึ้น แบบนี้จะช่วยให้เราทำ Estimation ได้มีประสิทธิภาพมากขึ้น … อ่านรายละเอียดเพิ่มเติมที่บทความนี้

4. ไม่ต้องใช้เวลาและความพยายามที่มากเกินไป

มีการศึกษากันมานักต่อนักว่ามนุษย์เราไม่เก่งเรื่องการคาดคะเนและการที่เราใช้เวลาและความพยายามมากขึ้นไม่ได้การันตีว่าผลของการคาดคะเนนั้นจะถูกต้องมากขึ้น ดังนั้นอย่าเสียเวลาอะไรให้มาก

การใช้ Story Point เป็นกุศโลบายอย่างหนึ่งที่เปิดโอกาสให้คนในทีมได้พูดคุยแลกเปลี่ยนความคิดเห็นในเนื้อหาของงานร่วมกัน ตัวเลขที่ต่างกันมากมันชี้ให้เห็นว่าเรามีช่องว่างในความเข้าใจต่างกันมาก แบบว่าคนนึงบอก 3 อีกคนบอก 13 … ก็คุยกันซะให้เรียบร้อย

เป้าหมายไม่ใช้ทำให้ทุกคนเห็นตรงกันหมดว่ามันคือ 5 (เป็นไปได้ยากและเสียเวลาโดนเปล่าประโยชน์) เอาแค่ทุกคนเห็นภาพใกล้เคียงกันแล้วก็เลือกไปเลยว่าจะ 5 หรือ 8 อย่าคิดมาก

คำแนะนำของผมสำหรับกรณีนี้คือให้เลือกตัวเลขที่ใหญ่กว่าเสมอเพราะเรามักหลงตัวเองว่าเก่งทำงานเร็วกว่าความเป็นจริง … Underestimate ประจำ

5. เริ่มที่ 5 แต้ม หรือ 1 แต้ม

เพราะ Story Point เป็นการกำหนดขนาดของงานที่สัมพันธ์กัน เราจะมีเทคนิคที่ทำให้การ Estimate งานครั้งแรกๆง่ายขึ้นด้วย

• 5 = Middle Size Story — ไล่ดูใน Product Backlog ของเรา … งานไหนที่เราคิดว่ามีขนาดกลางๆใกล้เคียงกันให้หยิบมากองไว้แล้วบอกว่า นี่แหละ 5 แต้ม เราใช้ข้อมูลตรงนี้เป็น Baseline เพื่อไล่ Estimate งานอื่นๆต่อไป ถ้าเล็กกว่าเยอะก็เอาไป 2 เล็กว่านิดหน่อยเอาไป 3 ทำแบบนี้เหมือนกันกับงานที่ใหญ่กว่า 5
• 1 = Smallest Size Story — วิธีนี้คือมองหากลุ่มงานที่เล็กที่สุดใน Product Backlog แล้วบอกว่า นี่แหละ 1 แต้ม จากนั้นก็ไล่เทียบกับงานที่ใหญ่ขึ้นตามลำดับ

สำหรับวิธีที่ใช้ 1 แต้มมีข้อเสียอยู่อย่างนึงคือถึงแม้เราจะรู้อยู่ในเวลานั้นว่างานนี้แหละเล็กสุด แต่ในอนาคตเราไม่รู้หรอกว่าจะมีงานที่เล็กกว่านี้เข้ามามั้ย แบบว่าแก้บั๊กโคตรง่าย เปลี่ยน Configuration สองบรรทัด ถ้ามีงานพวกนี้เข้ามาจริงๆเราทำไง? แต้มเล็กสุดเราใช้ไปแล้ว จะกำหนดให้มันเป็น 0.5 แต้มหรือ 0 แต้มหรอ? ผมไม่คิดว่ามันเหมาะเท่าไร (คือเรื่องมากเกินไป) ดังนั้นจึงเป็นเทคนิคที่มีคนแนะนำกันมาว่าเก็บ 1 แต้มไว้ใช้สำหรับงานอะไรที่มันง่ายจริงๆดีกว่า

6. ระหว่างให้แต้มก็จดรายละเอียดที่คุยกันไปด้วย (ห้ามใช้แล็ปท็อป)

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

ห้ามใช้แล็ปท็อปนะ ทำไมหนะเหรอ? ส่วนตัวผมคิดว่ามันช้ากว่าการจดด้วยมือ มันทำลายสมาธิ และมันเป็นการทำลายวินัยในการประชุม มีหนึ่งคนใช้แล็ปท็อปได้ก็จะมีคนที่สอง สาม สี่ตามมา และผมมั่นใจมากว่าคนที่เอาแล็ปท็อปเข้ามาในห้อง 90% ทำอย่างอื่นที่ไม่เกี่ยวกับการประชุม (โคตรเบื่อเลย ขอบอก)

7. Inspect and Adapt Story Point ใน Retrospective

ย้ำเรื่อง Inspect and Adapt เหมือนเดิม หนึ่งในเรื่องที่เราควรคุยกันใน Retrospective Meeting คือช่วงที่ผ่านมาการทำ Point Estimation ของเราแม่นยำแค่ไหน มีอะไรควรปรับปรุงมั้ย

วิธีการง่ายๆคือหยิบ User Story ที่ทำเสร็จหรือไม่เสร็จก็ตามใน Sprint ที่เพิ่งจบไปมานั่งให้แต้มกันใหม่ ดูสิว่ามันตรงหรือไม่ตรงกับของเดิม ถ้าไม่ตรงมันเป็นเพราะอะไร? เราลืมพิจารณาเรื่องอะไรไปรึเปล่า? … จดไว้ เป็น Lesson Learned อย่างดีเลย

สำหรับผมการ Estimate ให้แม่นยำตั้งแต่แรกเป็นไปได้ยากและไม่สำคัญเท่าเรากลับมารีวิวผลงานและหาทางปรับปรุงให้มันดีขึ้นครับ

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

The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson

อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ