การประเมินในการทำโปรเจคแบบทั่วไปมีเพื่อทำให้เราเห็นภาพคร่าวๆว่าในหนึ่งรอบการทำงานทีมคิดว่าดีที่สุดจะสามารถทำงานได้ปริมาณเท่าไหร่ ซึ่งเป็นสิ่งที่เราอยากให้มันเที่ยงตรงมากทั้งๆที่เรารู้ว่ามันจะไม่ตรงนะ เราก็เฝ้าหาอยู่นั่นแหละทำโน่นทำนี่ทำ Team Velocity ทำ Burn Down Chart ทำแห่นางแมว ไหว้พระเก้าวัด ก็ยังไม่ตรง!!! วันนี้เรามาเปลี่ยนมุมมองนิดนึงกันไหมครับ
การประเมินจะมีความ “ผิดพลาดน้อย” ถ้าเรามีความรู้และเข้าใจใน Problem Domain (ปัญหาอะไรที่เราจะแก้) และ Solution Domain (เราจะแก้ปัญหายังไง) ที่ดี ซึ่งมันกินเวลานานระดับหนึ่งเลย และก็นั่นแหละครับสำหรับผมสิ่งที่ยากกว่าการประเมินคือความเข้าใจที่ตรงกันตั้งแต่ Problem Domain หรือสิ่งที่เพื่อนผมชื่อเจนเรียกว่า Share Understanding เนื่องจากสิ่งที่ยากมากลำดับต้นๆของการทำงานเป็นทีมคือ ทำอย่างไรให้ทีมเข้าใจตรงกันว่าของที่จะทำเวลาทำนี่ตอนจบเป็นยังไง
ยกตัวอย่างเช่นเรามีหน้าจอหนึ่งหน้าจอตามด้านล่าง เข้ามาที่ sprint แรกที่ทีมเพิ่งเริ่มทำงาน มีทั้งคนเก่งที่เคยทำงานที่ บ นี้มาก่อน รวมกับสุดยอดโคตรพ่อ Dev ที่เพิ่งเข้ามาร่วมทีม
ทีมประกอบไปด้วย 5 คนคือ เจน รุ๊ฟ จั๊วะ อู โอ ห้าคนนี้มี experience ต่อองค์กรและระบบที่จะทำไม่เท่ากันพอจะต้องทำ สิ่งหนึ่งที่เกิดเสมอคือแต่ละคนจะเห็นภาพคำว่าเสร็จไม่เท่ากัน
- โอ Product Owner จะเห็นของในแนวระนาบเป็นส่วนใหญ่ เอาแค่ไหนให้พอสำหรับ Review
- อู Dev 69 ที่อยู่ที่ บ นี้มานานจะเห็นของในแนวลึกและระนาบบ้าง
- จั๊วะ Dev 88 จะเห็นแต่ของในแนวลึกด้านนึงมุ่งไปด้านความครบถ้วน
- เจน Dev 33 จะเห็นแต่ของในแนวลึกด้านนึงมุ่งเรื่องความเสถียร
- รุฟ QA สุดหล่อ จะเน้นเรื่องสิ่งที่ต้องป้องโน่นนี่และมองของในภาพรวมกัน คล้ายๆ PO
ถ้าเราปล่อยให้ห้าคนนี้ทำงานไปใน sprint โดยไม่คุยอะไรกันเลยรับรองว่าตอน review น่าจะมีอุทานว่า “พระสงฆ์” ดังนั้นสิ่งสำคัญมากคือทำอย่างไรให้ทั้งหมดเห็นภาพตรงกัน เหมือนเดิมสำคัญกว่านั้นคือ ทำอย่างไรให้ทั้งหมดพูดสิ่งที่อยู่ในหัวออกมาให้คนอื่นได้ยิน? เรามาทำอะไรบางอย่างเพื่อปรับความเข้าใจของแต่ละคนกันหน่อย
ถึงตรงนี้เราต้องใช้กลอุบายบางอย่างที่เรื่มต้นด้วย
- หนึ่งการทำให้ทุกคนรู้สึกว่ามันผ่อนคลายก่อนจะได้กล้าพูด ดังนั้นทำให้มันคล้ายๆเกมโดยที่มี ไอเท็ม ที่เขียนบนกระดาษเป็นแกนกลางของกิจกรรม (card)
- สองของที่เอามาใช้ต้องแสดงให้เห็นชัดเจนมากเรื่องความแตกต่างจากมุมมองของตัวเอง เพื่อเปิดโอกาสให้ทุกคนได้แสดงว่าเห็น (communicatin)
- สามเมื่อได้แสดงมุมมองของแต่ละคนแล้วต้องตกลงร่วมกันว่าท้ายที่สุดทีมเราเห็นว่าไอเท็มนี้เมื่อเสร็จจะมีรายละเอียดดังต่อไปนี้ (confirmation)
เล่ามาถึงตรงนี้พอจะเห็นอะไรกันบ้างนะครับ หยิบปากกากับกระดาษมานั่งคิดกันต่อ จากสามข้อนี้เราจะเห็นว่า
หลายๆทีมจะใช้เครื่องมือที่เรียกว่า Planning Poker (1, 2, 3, 5, 8 , … ) และเราจะเห็นว่าจริงๆแล้วมันคือหนึ่งในกลอุบายล่อหลอกให้เราคุยกันเพื่อแสดงมุมมองของตัวเองโดยที่ Outcome ของมันคือ confirmation และ communication
อย่างไรก็ตามบางทีมพอตกลงกันได้ก็เอาเลขที่ได้ ไปบนการ์ดแล้วที่สำคัญคือเอาเลขไปใช้ต่อเป็น Team Velocity ทำไปทำมาทำจนคิดว่าไอ้เลขนี่แหละสำคัญต้องทำให้มันตรงมัวเมาหาเลขกันไป บางทีมจบ sprint มา re-estimate อีก ทำจนเกร็งกันไปข้างและลืมไปว่าเลขเนี่ยไม่สำคัญเลย มันคือ output ที่จริงๆแล้วมี value น้อยมากเลย ถ้าเทียบกับ C ทั้งสองตัวก่อนหน้า
อย่างไรก็ตาม planning poker เป็นวิธีเดียวไหมที่จะทำให้เราบรรลุเรื่อง communication และ confirmation คำตอบคือ ไม่ มันมีทางอื่นอีกเต็มไปหมดเช่น บางทีมที่ทำงานเข้าข้อกันระดับบเห็นลมหายใจ PO ก็รู้ใจ ทีมแบบนี้จะเห็นว่า estimation หรือ planning poker เป็นของตลกละ เสียเวลา ซึ่งก็ไม่ผิดนะ เพราะเขาไปถึง Papa Shark แล้วระดับที่ PO บอก sprint นี้ 8 ไอเท็มเสร็จ ทีมบอก OK
เขาจะปล่อยปล่อยให้ทีมระดับ Baby Shark สร้าง Knowledge ด้วยการ Planning Poker กันไปก่อนเพราะก่อนจะเป็น Papa Shark ก็ต้องเปืน Baby Shark มาก่อน และแน่นอนว่าทีม Papa Shark พวกนี้บางทีก็ต้องกลับมาทำ Planning Poker กันบ้างเป็นบางจังหวะที่ทีมเห็นว่า Knowledge Gap ในทีมมีเยอะไปละ
ตั้งใจจะเขียนนิดเดียวมาซะยาวเลย ถึงตรงนี้จะเห็นว่าสำหรับผมการ estimate ใน agile ถูกใช้สำหรับประเมินเรื่องความคลาดเคลื่อนเรื่องความเข้าใจ เราไม่ควรเอาไปปนกับเรื่อง commitment หรือ forecast
