ความเหมือนที่แตกต่างของ Story Point กับ Man Hour
เราจะเลือกยังไง ในเมื่อ Agile นิยมใช้ Story Point ส่วน Traditional Management นิยมใช้ Man Hour ในการทำ Estimation
งานนี้จะเสร็จเมื่อไหร่
งานเสร็จทันมั้ย
งานนี้ต้องใช้กี่คน
คำถามเหล่านี้มักเกิดขึ้นเมื่อมีความสงสัยหรือความไม่มั่นใจในการทำงาน โดยผู้ถามจะใช้คำถามลักษณะนี้เพื่อนำข้อมูลไปใช้ในการวางแผนงานหรือโครงการ ส่วนทีมที่ถูกถามก็ต้องมาประเมินงานที่จะทำเพื่อตอบคำถามและทำงานในขั้นตอนถัดไป
ทีมที่ทำงานแบบ Traditional Management ทั่วไปจะนิยมประเมินการทำงานเป็นเวลาที่ใช้ในการทำงานชิ้นนั้นๆ ออกมาเป็นชั่วโมง หรือที่เราเรียกว่า Man Hour ซึ่งตอบคำถามที่ว่า “งานนี้จะเสร็จเมื่อไหร่” “งานต้องใช้กี่คน” “งานนี้ทำ 3 วันพอมั้ย” ได้อย่างตรงไปตรงมา
ในทางกลับกัน ทีมที่ทำงานแบบ Agile จะประเมินโดยดูที่เนื้องานว่ามีความยากง่ายหรือซับซ้อนมากน้อยแค่ไหนพอเทียบกับงานที่เคยทำมาแล้ว แล้วให้คะแนนชิ้นงานนั้นๆ เราจะเรียกคะแนนประเภทนี้ว่า “Story Point”
เมื่อคำถามไม่ตรงกับคำตอบ เพราะทีมไม่ได้ประเมินการทำงานเป็นชั่วโมง
และนี่คือที่มาของบทความนี้ กับการแปลง Story Point ให้เป็น Man Hour
Common Techniques สำหรับการ Estimation
ไม่ว่าจะบริหารทีมรูปแบบไหน การทำ Estimation นั้นยังคงเป็นสิ่งสำคัญต่อการวางแผนงาน ดังนั้นก่อนจะไปกันต่อว่า 1 Point เท่ากับกี่ชั่วโมง อยากชวนทุกคนมาสำรวจเทคนิคที่นิยมใช้ในการทำ Estimation กันค่ะ
1. Expert Opinion
เป็นการประเมินงานโดยมีผู้ที่เชี่ยวชาญหรือเคยมีประสบการณ์ในงานนั้นๆ มาเป็นผู้ทำการประเมิน ทั้งประเมินว่างานนั้นใช้เวลาทำเท่าไหร่ งานซับซ้อนหรือยุ่งยากแค่ไหน
เทคนิคนี้นิยมใช้กับการบริหารทีมแบบ Traditional Management เนื่องจากงานที่ทีมได้รับมอบหมายให้ทำมักจะเป็นงานที่มีขอบเขตชัดเจน รู้เนื้องานและสิ่งที่ต้องทำมากพอ ประสบการณ์ที่เคยมีจะช่วยให้การประเมินแม่นยำมากขึ้น อาจจะประเมินจบด้วยผู้เชี่ยวชาญเพียงคนเดียว หรือคนจำนวนไม่กี่คน ก่อนจะส่งงานต่อให้ทีม เช่น การประเมินเวลาที่ใช้ในการ Implement ฟีเจอร์โดย Tech Lead ที่เคยมีประสบการณ์กับฟีเจอร์นั้นมาก่อน เป็นต้น
2. Relative Estimation
เป็นการเปรียบเทียบโดยดูจากความสัมพันธ์ของงานที่นำมาเทียบกัน โดยมักจะเริ่มจากงานที่ทีมเคยทำร่วมกันหรืองานที่มีความชัดเจนมากที่สุด เพื่อให้ทีมสามารถสื่อสารให้เข้าใจใกล้เคียงกันและใช้งานดังกล่าวเป็นงานตั้งต้น เพื่อเปรียบเทียบขนาดกับงานชิ้นถัดไป ในภาพรวมของการประเมินงานทั้งหมด เราจะไม่ได้ใช้งานชิ้นเดียวเป็นหลักแล้วเทียบกับงานที่เหลือทุกงาน แต่จะดูความสัมพันธ์ของเนื้องาน งานไหนใกล้เคียงกันจึงจะนำมาเทียบ ช่วยให้เราประเมินได้แม่นยำขึ้น ทั้งนี้เราสามารถนำเทคนิคนี้มาใช้ร่วมกับการประเมินจากผู้เชี่ยวชาญด้วยเช่นกัน
ส่วนงานไหนที่เป็นงานใหม่ ทีมก็จะช่วยกันประเมิน เพื่อให้เกิดการเรียนรู้ร่วมกัน เช่น การใช้ Story Point (มักนิยมใช้ Fibonacci Sequence ในการให้คะแนน) ในการประเมินให้งานชิ้นนี้มี Point เป็น 5 ซึ่งอาจจะเกิดจากการดูเนื้องานเทียบกับงานที่เคยประเมิน Point เป็น 3 แล้วมองว่างานดังกล่าวมีความยุ่งยากมากกว่า แต่ยังน้อยกว่างานที่เคยประเมิน Point เป็น 8 สุดท้ายคะแนนที่เราได้จะสะท้อนถึงสัดส่วนของงานนั้นๆ ที่เปรียบเทียบกันค่ะ
3. Disaggregation
เป็นเทคนิคที่นำมาใช้ในการหั่นงาน ไม่ว่าจะเป็นการหั่นเพื่อให้ใช้เวลาในการทำงานลดลง เพื่อทำให้งานนั้นเสร็จได้ง่ายขึ้น หรือเพื่อให้ทีมมีงานที่เสร็จในระยะสั้นก่อนจะทำทั้งหมดให้เสร็จ ซึ่งหากเรามีงานเป็น Story การประเมินด้วยเทคนิคนี้จะช่วยหั่น Story ให้เล็กลง เกิดเป็น Story ใหม่ที่มีขนาดเล็กลงเพิ่มขึ้น ยกตัวอย่างเช่น หาก 1 Story ดูแล้วใช้เวลาทำงาน 100 วัน การประเมินนี้จะหั่นเวลาในการทำงานเพื่อให้จบ 1 Story ภายใน 2–5 วัน หรือหากเรามี Story ที่จะมาเทียบขนาดน้อยเกินไป จนไม่สามารถเทียบได้ เราก็จะนำเทคนิคนี้มาเปรียบเทียบเรื่องสัดส่วนของเวลาในการทำงานแทนความซับซ้อนของงาน เป็นต้น การประเมินด้วยเทคนิคนี้จะทำให้ทีมทำงานที่มีขนาดเหมาะสมและกระจายงานในทีมกันมากขึ้นค่ะ
นอกจาก 3 เทคนิคนี้ ขอยกตัวอย่างรูปแบบค่าที่คนนิยมนำมาใช้ทำ Estimation ซึ่งจะมีเป็นตัวเลขและขนาด เราจะเรียกการประเมินที่ใช้ข้อมูลจากตัวเลขแม่นยำและมีหน่วยชัดเจนว่า Absolute Estimation ในขณะที่การเปรียบเทียบขนาดจะเรียกว่า Relative Estimation ค่ะ
จากรูปขวดไวน์ จะเห็นว่าถ้าเป็น Absolute Estimation เราจะต้องรู้ปริมาตร ซึ่งมีหน่วยเป็นมิลลิลิตร (ml) ถึงจะสามารถประเมินเปรียบเทียบได้ ส่วน Relative Estimation นั้นจะไม่ใช้หน่วยในการประเมิน แต่จะใช้การเปรียบเทียบขนาดที่มีความสัมพันธ์กันของขวด นั่นคือเล็ก (Small) กลาง (Medium) และใหญ่ (Large) โดยใช้ตัวเลข 3, 5, 8 แทนขนาดในการเทียบให้เห็นถึงความสัมพันธ์โดยจำเป็นต้องรู้ปริมาตร แค่ใช้การเทียบสัดส่วนกัน เราก็จะรู้ความสัมพันธ์ของขนาดได้แล้วค่ะ
Man Hour vs. Story Point
เราได้รู้จัก Common Techniques และรูปแบบของค่าที่ใช้ในการประเมินกันแล้ว ขอกลับมาที่การประเมินโดยใช้ Man Hour ใน Traditional Management และ Story Point ใน Agile Management กันค่ะ
Man Hour
หรือชั่วโมงทำงานที่เราหลายคนคุ้นเคยก่อนจะมาทำ Agile จริงจัง เป็นสิ่งที่เรามักจะนำมาประเมินเพื่อระบุเวลาที่ใช้ในการทำงานนั้นให้สำเร็จ โดยดูจากขอบเขตของงาน ถ้าทีมมีประสบการณ์ในการทำงานนั้นๆ มาแล้ว งานก็จะสำเร็จได้เร็วขึ้น ใช้เวลาทำน้อยลง โดยมีหน่วยในการประเมินเป็นชั่วโมง
Story Point
เป็นตัวเลขที่เราใช้ประเมินจากความซับซ้อนหรือความยากง่ายของงาน โดยจะไม่ได้มีหน่วย แต่จะเป็นตัวเลขที่แสดงถึงความสัมพันธ์ของขนาด ทำให้ทีมเห็นสัดส่วนของชิ้นงานผ่านค่าที่ประเมิน หลายครั้งเราอาจจะเจอ Story Point ที่ไม่ได้เป็นตัวเลข เช่น S, M, L เป็นต้น ดังนั้นหน่วยของ Story Point จะไม่ใช่ชั่วโมง
Estimation สำคัญกับการวางแผนมากแค่ไหน
Estimation เป็นส่วนสำคัญในการวางแผนงาน เพื่อให้แผนที่วางไว้กับผลลัพธ์ที่ได้สอดคล้องกัน ซึ่งถ้าเลือกใช้เทคนิคที่เหมาะสม ก็จะช่วยให้การวางแผนได้ผลดีตามไปด้วย อย่างไรก็ตามรูปแบบการบริหารทีมที่แตกต่างกันในปัจจุบันนั้นนำไปสู่การปรับใช้เทคนิค Estimation ที่ต่างกัน ใน Agile Management นิยมใช้ Story Point และ Traditional Manage นิยมใช้ Man Hour
ทั้งสองอย่างเป็นการทำ Estimation เหมือนกัน แล้วอะไรคือความต่าง?
เพื่อจะตอบคำถามนี้แบบเห็นภาพ อยากชวนทุกคนมาดูรูป The Iron Triangle ที่จะช่วยให้เราเข้าใจความเหมือนที่แตกต่างของการทำ Estimation กันค่ะ
จากรูปจะเห็นว่าการวางแผนในการทำงานแบบ Traditional Management จะกำหนดขอบเขตงานหรือ Requirement ไว้อย่างชัดเจนเพื่อใช้เป็นสิ่งตั้งต้น และใช้การประเมิน (Estimation) เพื่อหาความเสี่ยงของค่าใช้จ่าย (Cost) เวลา (Time) และคุณภาพ (Quality) ทำให้เราได้ผลจากการประเมินออกมาเป็นแผนงานและระยะเวลาที่สอดคล้องกับคุณภาพในการทำงานให้ได้ตาม Requirement นั้นๆ
ส่วนการวางแผนงานใน Agile Management จะกำหนดค่าใช้จ่าย (Cost) และระยะเวลา (Time) ไว้อย่างชัดเจน เช่น ใน Scrum ที่กำหนดระยะเวลาแต่ละ Sprint ไว้ที่ 2 ถึง 4 สัปดาห์ จะใช้ 2 สิ่งนี้เป็นสิ่งตั้งต้นและใช้การประเมิน (Estimation) เพื่อหาขอบเขตงาน (Scope) ที่ทีมจะสามารถส่งมอบได้ภายในระยะเวลาและค่าใช้จ่ายที่กำหนด โดยพิจารณาคุณภาพจากคุณค่าของงานที่เหมาะสมต่อการส่งมอบในช่วงเวลาดังกล่าว
เราจะเห็นว่าสามเหลี่ยมฝั่ง Traditional Management เมื่อประเมินแล้ว จะได้ผลลัพธ์ออกมาเป็นค่าที่มีหน่วย อาจจะเป็นชั่วโมงหรือบาท ในขณะที่สามเหลี่ยมฝั่ง Agile Management จะได้ผลลัพธ์ออกมาเป็นขอบเขตงาน ซึ่งไม่มีหน่วยกำหนดไว้
Man Hour ประเมินจาก Experts ส่วน Story Point ประเมินจากทีม
ในการประเมิน Man Hour นั้นจะตั้งต้นจาก Project Manager/Tech Lead จึงมักจะใช้การประเมินแบบ Expert Opinion เป็นส่วนมาก ร่วมกับการเทียบงานใหม่และงานเก่าที่เคยทำ เพื่อช่วยให้เห็นแนวทางการทำงานและประเมินแผนงานได้
ส่วนการประเมิน Story Point นั้นแตกต่างออกไป เพราะจะตั้งต้นจาก Development Team ที่จะนำงานแต่ละชิ้นมาพูดคุยถึงขอบเขต อธิบายความเข้าใจให้ตรงกัน ก่อนจะคิดเป็นคะแนนที่สะท้อนถึงความซับซ้อนหรือความไม่ชัดเจนของงานค่ะ
Estimation วิธีไหนแม่นยำที่สุด
จริงๆ ต้องบอกว่าทั้ง Man Hour และ Story Point นั้น ไม่มีเทคนิคไหนที่เป๊ะ 100% เพราะ Estimation คือการคาดเดาหรือการประเมินจากข้อมูลที่เรามีในปัจจุบันเพื่อทำนายหรือวางแผนในอนาคต ฉะนั้นสิ่งที่สำคัญกว่าคืออย่าใช้แรงกับการเดาเยอะจนเกินไป เพราะอนาคตมีความไม่แน่นอน แต่อยากให้หมั่นกลับมาอัพเดต Man Hour หรือ Story Point บ่อยๆ เมื่อมีการเปลี่ยนแปลงเกิดขึ้น หรือเมื่อเจอว่าที่เคยประเมินไว้ไม่ถูกต้อง เพื่อให้สอดคล้องกับปัจจุบันมากกว่าจะยึดติดกับแผนที่เคยวางไว้ จากนั้นความเป๊ะก็จะมากขึ้นเรื่อยๆ เองค่ะ
แล้วเราแปลง Story Point เป็นชั่วโมงดีมั้ย
การแปลง Story Point มาเป็นชั่วโมง คือการนำผลของการประเมินที่ไม่มีหน่วยมาแปลงเป็นผลลัพธ์ที่มีหน่วยเป็นชั่วโมง แต่การนำ “ชั่วโมง” มาเป็น Story Point จะทำให้เกิดความเสี่ยง ทำให้ประเมินไม่แม่นมากกว่าเดิม เพราะเมื่อเราประเมินงานที่ยังมีขอบเขตไม่ชัดเจนและเปลี่ยนแปลงได้ ตัวเลขชั่วโมงทำงานที่ประเมินไว้อาจจะคลาดเคลื่อนจากความเป็นจริงไปมาก
Story Point ไม่ควรถูกแปลงหรือตั้งต้นมาจากชั่วโมงทำงาน แต่ทีมควรโฟกัสกับ Sprint ที่วางไว้ตามไทม์ไลน์ เช่น Sprint ส่งมอบงานได้น้อยกว่าที่แพลน
เพราะการใช้ Story Point จะช่วยประเมินสถานการณ์ให้ Project Manage/Team Leader รู้ตัวได้เร็วขึ้นว่ามีงานที่เริ่มดีเลย์
หากทีมเลือกใช้ Story Point งานจะเสร็จทันมั้ย
การที่เราจะประเมิน Story Point เพื่อสะท้อนถึงประสิทธิภาพของทีมนั้นต้องอาศัย Velocity ร่วมด้วย ซึ่งจะช่วยให้เราประเมินได้แม่นขึ้น คาดการณ์ได้ว่างานที่มี Story Point เท่าไหร่ที่เอาเข้า Sprint แล้วทีมจะทำเสร็จ รวมถึงจะต้องใช้อีกกี่ Sprint งานทั้งหมดที่อยู่ใน Backlog จึงจะเสร็จ หมั่นอัพเดตสถานการณ์กันระหว่างทีมและคนบริหารทีมเป็นราย Sprint ว่าทีมส่งมอบงานได้ตามที่แพลนหรือไม่ งานที่ทีมทำสะสมไว้ก็จะค่อยๆ เพิ่มขึ้น ถ้ามากหรือน้อยไปก็จะมีข้อมูลเพียงพอมาอัพเดตแผนกันได้ตลอด
ถ้าทีมที่ใช้ Story Point นั้นเป็นทีมที่อยู่ตัว มีความเป๊ะ ทำงานด้วยกันมาแล้วระยะหนึ่ง ทีมนำงานเข้า Sprint เท่าไหร่ ตอนหมด Sprint ก็จะสามารถส่งมอบงานได้ตามที่แพลน งานก็จะเสร็จทันตามที่วางไว้ในแต่ละ Sprint อยู่เรื่อยๆ ค่ะ
ทั้งนี้หากมีคำถามนี้ส่งมาที่ทีมบ่อยๆ แสดงว่าพอจบ Sprint ทีมไม่ค่อยส่งมอบงานได้ตามที่แพลน เลยทำให้มีงานค้าง กระทบไปยัง Sprint ถัดไป ในภาพรวมเลยดูมีความเสี่ยงที่งานจะไม่สำเร็จตามแผน กรณีนี้อยากให้เราชวนทีมทำแผนและประเมิน Story Point สำหรับงานที่จะ Release ในภาพใหญ่ก่อน แล้วค่อยคาดการณ์ Point ที่จะต้องทำให้ได้ในแต่ละ Sprint จากนั้นหมั่นอัพเดตสถานการณ์ในทุก Sprint เสมอ เพื่อให้ Project Manager หรือ Tech Lead ที่ดูแลแผนงานรับรู้สถานการณ์และปรับแผนได้ทันค่ะ
พอเรามี Story Point ของทีมในหลายๆ Sprint แล้วจะรู้สถานการณ์ทีมในภาพรวมได้อย่างไร
จากรูป เมื่อเราได้ Story Point ในแต่ละ Sprint มาดูความสัมพันธ์ เราจะเห็นความเร็ว (Velocity) ในการทำงานของทีมนั้นๆ โดยจะใช้ Story Point ที่ประเมินตอนวางแผน และ Story Point ที่ทำงานเสร็จใน Sprint นั้นๆ เทียบกัน ก็จะเห็นสถานการณ์ของทีมได้ว่าทีมสามารถทำงานได้ใกล้เคียงกับแผนที่วางไว้หรือไม่
สำหรับการดูงานในหลายๆ Sprint เพื่อให้เห็นการบริหารทีมในภาพรวม เราสามารถใช้ข้อมูล Velocity ในราย Sprint ที่ทีมทำมาเป็นข้อมูลเพื่อใช้ทำนายและปรับแผน Due Date ของโครงการได้ค่ะ
เมื่อเรามีข้อมูลจากทีมที่ทำงานจริงแล้ว เราสามารถนำข้อมูลที่เกิดขึ้นมาใช้ช่วยในการวางแผนงานในอนาคตได้ โดยใช้ Cumulative Flow Diagram (CFD) มาช่วยในการทำนายค่ะ แกนแนวตั้งแสดงขนาดของ Backlog แกนแนวนอนแสดงเวลา และกำหนดค่า Backlog Size ของ Project Scope และ Velocity มาใช้ค่ะ
เราสามารถประเมินกรณีที่ทีมจะทำงานเสร็จเร็วที่สุด ทำงานเสร็จตามแผน และทำงานเสร็จได้ช้าที่สุด ด้วยการใช้ Velocity ที่ต่างกันมาคำนวณ เพื่อดูว่าด้วย Project Scope ที่ขนาดเท่ากัน แต่ Velocity ของทีมต่างกัน ทีมจะใช้เวลาทำงานกี่ Sprint และงานจะเสร็จทัน Due Date มั้ย
ตัวอย่างเช่น กรณีที่ทีมทำงานเสร็จเร็วที่สุด หากเรากำหนด Velocity = 20, Project Scope มีขนาดเท่ากับ 200 และ 1 Sprint = 2 weeks จากค่าเหล่านี้ เมื่อนำไปใส่ในกราฟแล้ว เราจะรู้ว่า Project Scope นี้จะเสร็จ 100% ได้ใน 10 Sprint หากทีมทำงานด้วย Velocity = 20
จากรูปกราฟด้านจะช่วยให้เราและทีมเห็นจุดหมายว่า Due Date ที่เราตั้งกับงานที่ทีมจะทำได้นั้น จะครบถ้วนหรือขาดตกในส่วนไหนไปบ้าง (เกิดเป็น Scope Risk) เมื่อทีมทำงานด้วย Velocity ค่าต่างๆ ค่ะ
แล้ว Estimation นั้นสำคัญกับการทำงานมั้ย?
Estimation ยังคงมีความสำคัญกับการทำงานและเป็นวิธีการที่จะตั้งต้นในการวางแผนงานที่ดีอยู่ ตราบใดที่เราใช้แรง เวลา และรูปแบบของการประเมินที่เหมาะสมกับเป้าหมายในการวางแผน เพราะการใช้แรงเพื่อเดาอะไรมากเกินไปในครั้งเดียว อาจทำให้เราเหนื่อยเกินความจำเป็นได้
และจากเนื้อหาทั้งหมดนี้ มี Do & Don’t สั้นๆ ที่อยากฝากทุกคนทิ้งท้ายสักนิดค่ะ
DO
- ชวนทีมให้ประเมิน Story Point ด้วย Sizing หรือใช้เลข Fibonacci เน้นย้ำถึงการประเมินโดยใช้ความสัมพันธ์ของเนื้องานมากกว่าเวลาที่จะใช้ในการทำงาน
- ชวนให้ทีมทำ Planning Poker และใช้โอกาสจากตัวเลขที่ประเมินไม่ตรงกันมาพูดคุยและโหวตคะแนนใหม่ จนได้เป็นตัวเลขที่เหมาะสม
- ชวนทีมใช้เทคนิคการประเมินแบบ Aggregate ด้วยการแตก Backlog Item ให้เหมาะสม โดยใช้เทคนิคต่างๆ ร่วมด้วย เช่น INVEST
DON’T
- ไม่เอา Story Point กับ Man Hour มาเทียบกันตรงๆ
- อย่าใช้เวลานานมากไปกับการทำ Planning Poker
- ไม่เทียบ Story Point/Velocity ของทีมเรากับทีมอื่น
- หั่นงานให้ขาดออกจากกัน แต่จะไม่ประเมินงานแยกส่วนกัน เพื่อให้ทีมยังเห็นภาพรวมของงาน
สำหรับใครที่ชื่นชอบบทความนี้ อย่าลืมกดติดตาม Medium: KBTG Life เรามีสาระความรู้และเรื่องราวดีๆ จากชาว KBTG พร้อมเสิร์ฟให้ที่นี่ที่แรก
