ถามซักนิดก่อนคิด Estimate
To Make Sure You Don’t Waste Your Time Guessing The Useless Numbers
เมื่อไม่นานมานี้ได้มีโอกาสเข้าไปสังเกตการณ์ (บวกให้คำแนะนำ) ใน Sprint Planning Session พวกน้องๆก็เริ่มต้นด้วยการ “จะให้แต้ม” กับ Product Backlog Item ที่อยู่บนๆก่อน (เข้าใจนะว่ามันควรจะให้แต้มกันมาเรียบร้อยตั้งแต่ก่อนเข้า Planning Session แล้ว แต่ที่เป็นแบบนี้ก็ไม่ใช่เรื่องแปลกอะไร) ด้วยความมุ่งมั่นอยากให้แต้มอย่างน่าสงสัย (คือกระตือรือร้นกันมาก) ผมเริ่มรู้สึกว่ามันแปลกๆเลยลองถามน้องในทีมว่า
ผม: “น้องแคร่บ เราจะ Estimate แต้มไปเพื่ออะไรครับ?”
น้อง: “ก็จะได้รู้ว่าเราจะรับงานเข้า Sprint ได้กี่งานอะครับพี่” น้องตอบมาอย่างถูกต้องตามหลักการเป๊ะ แต่ความสงสัยของผมยังไม่หมดไป ขอถามต่อ
ผม: “แล้วงานทั้งหมดใน Sprint ที่ผ่านมามีแต้มครบเลยมั้ย?”
น้อง: “ไม่ครับ”
ผม: “แต่ทีมเราก็ทำงานกันได้โดยไม่ต้องมีแต้มนี่หน่า แล้วที่ผ่านมาส่วนใหญ่แล้วแต้มที่ให้ไปมันตรงกับขนาดงานจริงๆมั้ย?”
น้อง: “ก็ไม่ค่อยนะครับ ถ้างานใหญ่ก็ไม่ตรงเลย”
ผม: “อืมมมม น่าสนใจ แล้วเราเคยได้เอาเรื่อง Estimate ไม่ตรงมาคุยกันตอน Retrospective Meeting ปะครับ?”
น้อง: “แค่ Retrospective Meeting ยังไม่เคยมีเลยครับ” น้องยิ้มแหยๆ
ผม: “โอเค แล้วตอนนี้ Velocity ของทีมเราเป็นเท่าไรครับ?”
น้อง: “ไม่ทราบครับ ไม่เคยเก็บจริงจังอะพี่”
ผม: “อ้าว โอเค ฮ่าๆ” หลังจากซักถามน้องติดๆกันหลายคำถาม ผมก็หันไปขอความคิดเห็นจากพี่ Product Owner บ้างว่า
ผม: “แต้มมีผลต่อการจัดลำดับความสำคัญของงานมั้ยครับ?”
พี่: “ก็ไม่มีนะคะ เรียงตามความสำคัญทาง Business อย่างเดียวเลย”
ณ จุดนั้น ผมได้รับคำตอบมาจนได้ข้อมูลเพียงพอที่จะแนะนำทีมว่าการประเมินแต้มไม่ใช่เรื่องจำเป็นที่ขาดไม่ได้สำหรับการทำงาน (อย่ายึดติดกับหลักการมากเกินไปโดยไม่รู้ที่มาที่ไปและประโยชน์ที่แท้จริงของมัน)
สาระสำคัญของการใช้ตัวเลข 1, 2, 3, 5, 8, … ใน Planning Poker นั้นมีไว้เพื่อสร้างบทสนทนาระหว่างคนในทีมเพื่อทำให้งานนั้นกระจ่างและเป็นที่เข้าใจตรงกัน เช่น คนนึงบอก 2 แต้ม อีกคนบอก 8 แต้มแสดงว่ามันมี Gap ใน Scope ของงานอยู่อย่างชัดเจน ก็พูดคุยกันให้เคลียร์ไป
ดังนั้นผมมีความเชื่อว่าถ้าเราพูดคุยกันเป็นเรื่องปกติอยู่แล้วเราก็ไม่จำเป็นต้องเสียเวลา (มาก) ในการประเมินแต้มซึ่งไม่เคยได้ใช้ประโยชน์จากมันอย่างจริงจังเลย
แล้วผมจบการสังเกตการณ์การประชุมนี้อย่างไร? … ผมแนะนำทีมไปว่า
- ไล่คุยรายละเอียดทีละงานจากบนลงล่าง
- คุยเสร็จแล้วถามว่า คิดว่าทำงานนี้เสร็จมั้ยใน Sprint นี้? ถ้าเสร็จก็จับเข้า Sprint
- วนไปเรื่อยๆจนทีมบอกว่า ไม่เสร็จครับ
- แล้วผมก็ตัดงานสุดท้ายที่ทีมคิดว่าทำเสร็จออกจาก Sprint เพราะที่เราคิดว่าจะทำเสร็จมันจะไม่เสร็จหรอก … เรามักจะ Underestimate เสมอ
- แล้วบอกทีมว่าลองทำแค่นี้ดูก่อน เดี๋ยวผ่านไปครึ่ง Sprint แล้วมารีวิวกันอีกครั้งว่ามันจะออกมาสภาพไหน … ไม่ต้องคิดมากทุกคน JUST DO IT!!!
ผมเขียนบทความนี้เพราะอยากเปลี่ยนแปลงสิ่งที่เป็นอยู่ในอุตสาหกรรมการผลิตซอฟท์แวร์ให้ดีขึ้นตามความเชื่อและประสบการณ์ของผม ถ้าเพื่อนๆเชื่อในแนวทางเดียวกัน เรามาช่วยกันคนละไม้คนละมือทำให้สังคมของเราดีขึ้นครับ จะแชร์บทความนี้ผ่าน Social Network หรือจะแบ่งปันเรื่องราวนี้ให้คนที่นั่งข้างๆฟังบ้างก็ได้
The Future Has Arrived — It’s Just Not Evenly Distributed Yet, William Gibson
อนาคตอยู่ตรงนี้แล้ว เรามีหน้าที่ต้องถ่ายทอดมันออกไปให้คนอื่นได้สัมผัสสิ่งดีๆร่วมกันครับ
