เรื่องเก่าเล่าใหม่ กับ Size Estimation

Image: https://blog.dlvrit.com/blogging-and-seo/

ช่วงนี้กำลังไปช่วยทีม Scrum อีกทีมนึง แล้วทีมมีคำถามเกี่ยวกับการทำ size estimation หรือ story point แล้วมันไม่ตรงกัน ก็เลยอยากเขียนอธิบายไว้แบบละเอียดๆ หน่อย หัวข้อที่จะเล่าให้ฟังก็ประมาณนี้ครับ

• Does estimation matter?
• Size? Not Time?
• Rative Size.
• Size, and Only Size.
• Again, Relative Size.
• Team Velocity & Forecast.
• Team Estimation
• FAQ

Does estimation matter?

ก่อนไปดูเทคนิคการทำ size estimation เรากลับมาดูก่อนว่า การประเมินหรือทำ estimation ในการทำ software เนี่ยะมันสำคัญไหมนะ? ผมตอบได้ 2 แบบครับ คือ

1. สำคัญ — เพราะมันจะได้รู้คร่าวๆ ถึง scope, timeline, budget, effort, เพื่อให้วางแผนเตรียมงานได้ดีขึ้น เพราะถ้า estimate ไม่ได้ แสดงว่ายังรู้รายละเอียดไม่พอ
2. ไม่สำคัญ — หัวหน้าเก่าผมเคยพูดติดตลกว่า “ชื่อจริงของ estimation คือ guess-timation” คือเดานั่นแหละ แค่เดาด้วยหลักอะไรบางอย่างมากกว่าแค่นั่งเทียน แต่สุดท้ายมันไม่ก็เป๊ะหรอก ทำไปก่อนแล้วค่อยด้นสดเอาหน้างาน 😁

พอเอา 2 คำตอบมารวมกัน ก็เลยได้คำตอบแบบกลางๆว่า มันสำคัญนะ เราควร estimate เพื่อให้รู้แผนงานคร่าวๆ ลงรายละเอียดในจุดที่มองข้ามไป แต่เอามาเป็น hard-deadline ไม่ได้ โดยเฉพาะกับงานพัฒนา software เพราะมันเปลี่ยนได้ตลอด (งานอื่นที่ไม่เปลี่ยนแน่ๆอาจจะได้อยู่)

Size? Not Time?

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

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

(Roughly) Relationship between Size & Time

Relative Size

ปัญหานึงของการประเมินคือ มนุษย์เราประเมินอะไรให้ออกมาเป็นตัวเลขเป๊ะๆไม่เก่ง เช่น ถ้าเราถามว่า “คนที่เดินสวนไปเมื่อกี๊สูงกี่ ซม.? ขอเป๊ะๆ เลยนะ” เราจะตอบได้แค่ตัวเลขประมาณนึง ซึ่งมักจะผิด แต่ถ้าถามใหม่ว่า “2 คนที่เดินมาใครสูงกว่ากัน?” แบบนี้เราตอบได้ทันที เพราะมนุษย์เราสามารถเปรียบเทียบขนาดของ 2 อย่างด้วยสายตาได้โดยธรรมชาติ เราจะใช้เทคนิคการเปรียบเทียบขนาดของ 2 อย่างนี่แหละในการประเมินขนาดของงาน … แต่เดี๋ยวค่อยกลับมาดูเรื่องเปรียบเทียบทีหลัง มาดูเรื่องวิธีประเมินขนาดก่อน

Size, and Only Size

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

การทำความเข้าใจเรื่องการประเมินขนาดที่ดีที่สุดคือ ตัวอย่าง ผมมีตัวอย่างให้ลองคิดตาม ลองดูครับ

สมมติผมอยู่คนเดียวและกำลังจะสั่งพิซซ่ามากิน ผมมักจะประเมินว่าจะสั่งถาดขนาดไหนมากินดี ผมจะคิดว่ามันถาดขนาดไหนนะ แล้วตอนที่มาถึงผมจะหิวขนาดที่กินหมดรึเปล่า ถ้าดูจากตัวอย่างแสดงว่าผมกำลังประเมินด้วยตัวแปร 2 ตัว คือ ขนาดพิซซ่า และ ความหิว (หรือความสามารถในการทำลายล้างของผม)

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

Again, Relative Size

คราวนี้ผมจะเริ่มประเมินขนาดละ แต่การประเมินขนาดของงานมันไม่มีประโยชน์ถ้ามันมีชิ้นเดียว เพราะมันไม่มีอะไรให้เปรียบเทียบ เพราะฉะนั้นมันต้องมีหลายชิ้นหน่อย (ตอนทำงานเราก็จะใช้วิธีย่อยงานแทนที่จะประเมินทั้ง project เช่น ย่อยเป็น feature เป็นต้น)

กลับมาที่ตัวอย่างพิซซ่าของเรา สมมติผมสั่ง พิซซ่าถาดใหญ่, สปาเก็ตตี้คาโบนาร่า, สลัดผัก และ โคล่า 1 กระป๋อง

Pizza Time!!!

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

เราจะใช้ Fibonacci Series ในการแทนค่า

เลข Fibonacci จะเป็นเลข series ที่เกิดจากการเอาตัวเลขก่อนหน้า บวกกับเลขปัจจุบัน จะได้เลขถัดไป และทำไปเรื่อยๆ เพื่อสร้างตัวเลขใหม่ไปเรื่อยๆ เช่น 0 + 1 = 1, 1 + 1 = 2, 1 + 2= 3, 2 + 3 = 5, 3 + 5 = 8, …

Fibonacci Series

เพราะฉะนั้นเราจะได้ชุดตัวเลข คือ [ 1, 2, 3, 5, 8, 13, 21 ]ตัวเลขเหล่านี้จะถูกเอามาใช้ประเมินขนาดของงาน

Note 1: บ่อยครั้งจะมีคำถามว่าทำไมไม่ใช้จำนวนเต็มง่ายๆ? เหตุผลก็คือ ลองคิดดูว่าถ้าเป็น 1, 2, 3 เราประเมินง่าย เพราะมันคือ 1 เท่า, 2 เท่า, และ 3 เท่า แต่ถ้าตัวเลขใหญ่ๆ เช่น 13,14,15 มันจะเริ่มเลือกยากละว่าจะเอาเลขไหนดี และทีมจะเริ่มเสียเวลากับการเลือกตัวเลขมากเกินไป ตัวเลข 8, 13, 21 มันเพิ่มเกือบๆ เท่าตัวเพื่อบังคับให้ปัดขึ้นหรือปัดลง เพราะสุดท้ายแล้ว estimate = guess-timation อยู่ดี มันไม่ตรงกัน 100% อยู่แล้ว อย่าใช้เวลากับมันเยอะเกินไป

Note 2: ตัวเลขสูงสุดที่ผมใช้คือ 21 เพราะถ้ามันใหญ่เกิน 21 แสดงว่ามันเริ่มประเมินยากละ ผมจะแบ่งงานให้ย่อยลงจะได้ประเมินง่ายขึ้นและเสร็จเร็วขึ้นด้วย ถ้าใครเคยเห็น planning poker card จะมี 50, 100 ด้วย นอกจากนั้นจะมี card เครื่องหมายคำถาม (?) เพื่อบอกทีมว่า ข้อมูลไม่พอประเมิน และ ☕️ หรือ 🍺 เพื่อบอกว่า เบรคเถอะ ไม่ไหวแล้ว

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

วิธีการก็คือ ก็เริ่มจากอันที่มันขนาดกลางๆ แล้วให้ 5 เลย ผมเลือก “สปาเก็ตตี้คาโบนาร่า” มีขนาด 5 แล้วกัน

Note 3: อย่าลืมว่า สุดท้ายเราต้องการเลขตัวนึงเพื่อกำหนดขนาดงาน “เปรียบเทียบ” กับงานอื่น เราเลยต้องเริ่มซักอันนึง

จากนั้นผมก็ประเมินต่อว่า ของชิ้นไหนที่มีขนาดใกล้เคียงสปาเก็ตตี้ โดยผมจะถามตัวเองทีละ step ตามนี้

1. ชิ้นไหนนะที่ขนาดใกล้ๆ กับสปาเก็ตตี้? ผมเลือก สลัดผัก
2. แล้วสลัดผัก เล็กกว่า เท่ากัน หรือ ใหญ่กว่า สปาเก็ตตี้? อืมมม เล็กกว่า
3. แล้วเล็กกว่า 1 เท่า, 2 เท่า, หรือ…? น่าจะ 2 เท่าตัว คือกินสลัด 2 ถ้วย อิ่มเกือบๆ เท่ากับสปาเก็ตตี้ 1 ที่
4. เพราะฉะนั้นขนาดของสลัดผักคือ? 3 (เล็กกว่า 5 ลงมา 1 step)

จากนั้นก็ทำต่อไปกับของชิ้นอื่นจนครบทุกชิ้น สรุปผมก็จะได้ขนาดที่ estimate แล้วประมาณนี้ รวมแล้ว 22 points

Pizza Size Estimated

Team Velocity & Forecast

หลังจากที่เรากำหนดขนาดให้กับพิซซ่า (งาน) แล้ว คราวนี้เราก็เริ่มเอามาประเมินเวลากันต่อ ถ้าเป็นการประเมินแบบปกติ เราจะคิดต่อไปว่า แล้วต้องใช้เวลาเท่าไหร่จึงจะกินหมด

แต่ในการทำงานแบบ Scrum เราจะกำหนด timebox เป็น Sprint โดยมีระยะเวลาที่ 1–2 สัปดาห์ (ไม่เกิน 4) แล้วประเมินว่าใน Sprint นั้นเราทำงานให้เสร็จได้แค่ไหน หรือเก็บได้กี่ point

กลับมาที่พิซซ่า ให้นึกภาพว่า ระยะเวลา 1 Sprint ก็เหมือนกับพื้นที่ในกระเพาะอาหารของเราว่ามันจุอาหารได้แค่ไหน เพราะฉะนั้นแต่ละคนก็จะกินได้ไม่เท่ากัน สมมติว่าจากเมนูทั้งหมดผมประเมินว่าน่าจะต้องกิน 3 มื้อจึงจะหมด แสดงว่าผมใช้ 3 Sprint ต่อ 22 points หรือคิดในมุมกลับ ก็คือ ผมมีความสามารถในการกินอาหาร 1 มื้ออยู่ที่ (22/3 = 7.33) 7 points ตัวเลขที่ได้เราเรียกว่า Velocity (หรือฝีเท้า)

For 1 person, 3 sprints to complete

ถ้าเปลี่ยนจาก “1 คน” เป็น “1 ทีมที่มีสมาชิก 3 คน” แล้ว 3 คนนั้นกินอาหารชุดนี้อิ่มพอดี แสดงว่าทีมนี้มี Velocity = 22 points คราวนี้เราจะประเมินความสามารถของทีมได้คร่าวๆ แล้ว เช่น “ถ้าทีมนี้ไปกินโต๊ะจีนจะกินหมดไหม” เราก็แค่ประเมิน size โดยเปรียบเทียบแต่ละจานกับเมนูพิซซ่า ก็จะบอกได้แล้วว่าต้องกินโต๊ะจีนกี่มื้อ (sprint)

For 3 people per team, 1 sprint for 22 points

กลับมาที่งาน ถ้าเราทำงานเป็น Sprint เราจะสามารถประเมินเวลาได้ง่ายขึ้น เพราะถ้าเราสามารถกำหนด point ให้กับแต่ละ feature ที่ต้องทำและหา velocity ของทีมได้ เราก็พอจะ forecast ได้คร่าวๆ แล้วว่า ทีมนี้ต้องใช้เวลากี่ sprint จึงจะมี feature มากพอให้ขึ้น production ได้

Team Estimation

ถึงตรงนี้ สมาชิกในทีมจะรู้เทคนิคการประเมิน size ละ เมื่อ PO เอา Product Backlog มาให้ทีมประเมินขนาด ทีมก็จะ vote กัน เทคนิคการ vote ก็มีหลายแบบ เช่น

1. ใช้ Planning Poker คือจะมีไพ่คนละสำรับเอาไว้บอกเลขของแต่ละคน แต่ละคนเลือกขนาดของงาน จากนั้น Facilitator ก็จะขอให้ทุกคนเปิดไพ่ แล้วมาคุยกันถ้าตัวเลขไม่เท่ากัน เมื่อคุยกัน แต่ละคนก็จะแชร์มุมมองที่แตกต่างกันที่จะช่วยให้ทุกคนเห็นภาพเดียวกัน

Planning Poker — http://www.codermojam.com/agile-estimating-planning-planning-poker/

2. Silence Estimation เทคนิคนี้จะใช้การเขียนตัวเลข 1, 2, 3 … เรียงไว้ห่างๆที่ขอบโต๊ะด้านหนึ่ง แล้วเขียนงาน (Product Backlog Item) ลงบน index card จากนั้น facilitator จะกำหนดรอบของเวลา เช่น 5 นาทีต่อรอบ แล้วให้ทีมเดินผ่านโต๊ะทีละคน เมื่อถึงตาใคร ก็ให้เลื่อน card ใบไหนก็ได้ 1 ใบ ไปตำแหน่งที่คิดว่า size น่าจะตรงกับใบอื่น แล้วให้คนต่อไปทำต่อ จนครบเวลา แล้วคุยกันเฉพาะใบที่ไม่เห็นด้วย ซึ่งวิธีนี้ต้องคุยกันก่อนว่าแต่ละใบเป็นยังไงแล้วจึงเริ่มทำ

Silence Estimation

FAQ

ทุกครั้งที่สอนหรือเมื่อทีมเอาไปใช้ มักจะมีคำถามที่เจอบ่อยๆ ผมสรุปได้ประมาณนี้ครับ

1. บางคนบอกว่า การประเมิน size ให้เอาเรื่องความยากง่ายกับประสบการณ์มาคิดด้วย ถ้าไม่เคยทำขนาดมันต้องใหญ่ขึ้นรึเปล่า? แล้วต้องยังไงกันแน่? คำตอบคือ คิดได้ทั้ง 2 แบบครับ

• แบบแรกคือ ให้เปรียบเทียบขนาดเพียวๆ ไม่ต้องสนใจว่าใครทำหรือไม่เคยทำมาก่อน เพราะต่อให้เคยทำหรือไม่เคยทำ ขนาดมันก็เหมือนเดิม (ขนาดของพิซซ่าเท่าเดิมไม่ว่าเราจะหิวมากหรือน้อยก็ตาม) เพื่อให้ขนาดมันสัมพันธ์กับกับงานอื่นๆ ข้อดีคือ ประเมินง่าย เพราะแค่เอาไปเทียบกับงานที่เคยประเมินไปแล้ว แต่ข้อเสียคือ เวลาที่ใช้อาจจะไม่สัมพันธ์กับขนาดเสมอไป (ซึ่งถ้ากลับไปดูนิยามของ estimation มันก็ไม่ตรงอยู่แล้ว แต่การประเมินจะง่ายและไม่ซับซ้อน)
• แบบที่ 2 คือ เอาเงื่อนไขเรื่องประสบการณ์หรือความไม่รู้ว่าจะต้องทำยังไง ประเมินขนาดด้วย แสดงว่า ถ้างานไหนที่ทีมไม่เคยทำเลย ต่อให้เป็น feature เล็กๆ ขนาดก็อาจจะใหญ่กว่าที่ควรจะเป็น เพราะเราใส่ส่วนประกอบอื่นลงไปด้วย (อาจจะมีงาน research ที่ต้องไปทำเพิ่ม ขนาดเลยใหญ่ขึ้น) ข้อดีคือ ขนาดมักจะสอดคล้องกับเวลา (แต่ก็ไม่เสมอไป) แต่ข้อเสียคือ การประเมินมักจะซับซ้อนกว่าแบบแรกและใช้เวลามากกว่า
• เพราะฉะนั้น แบบไหนก็ได้ครับ ให้ทีมตกลงร่วมกันแล้วลองดูว่าแบบไหนที่ทุกคน ok กับมันที่สุด

2. จากตัวอย่างข้างต้น พิซซ่าขนาด 13 แต่ velocity ของคนๆเดียวเท่ากับ 7 แสดงว่าแค่พิซซ่าชิ้นเดียวก็ใส่ลง sprint ไม่ได้แล้ว ต้องทำยังไง?

• ใช้วิธีแบ่งเป็น 2–3 ชิ้นครับ เช่น 8, 5 หรือ 5, 5, 3
• ถ้าแบ่งแล้วได้ 8 แต่ velocity = 7 ถึงจะเกินขนาดไปนิดหน่อย ก็ใส่ลง sprint ได้นะถ้ามั่นใจว่า implement ให้จบได้ เลข 7 มันก็เลขประมาณเหมือนกัน

3. ถ้าทีมเก่งขึ้น Velocity จะค่อยๆเพิ่มขึ้นใน sprint ถัดๆไปไหม?

• ไม่ครับ
• velocity เอาไว้ประเมินฝีเท้าคร่าวๆ ถ้าการประเมินขนาดเหมือนเดิม velocity ไม่ควรจะเพิ่มไปเรื่อยๆ เปรียบเทียบกับการวิ่งมาราธอน ที่ต้องวิ่ง 42 กิโลเมตร นักวิ่งอาจจะวิ่งที่ความเร็วต่อ 1 กิโลเมตร (pace) เร็วขึ้นหรือช้าลงจากเวลาที่ซ้อมได้ แต่สิ่งที่สำคัญที่สุดไม่ใช่การวิ่งแต่ละกิโลให้เร็วขึ้นเรื่อยๆ (ซึ่งเป็นไปไม่ได้อยู่แล้ว) แต่เป็นการวิ่งให้เร็วที่สุดเท่าที่จะไปให้ถึงเส้นชัยที่กิโลเมตรที่ 42 ต่างหาก
• การทำงานเป็นการวิ่งมาราธอนเป็นทีมครับ ไม่ใช่การวิ่งระยะสั้นแบบเดี่ยว

4. หัวหน้าเอา velocity มาประเมินความสามารถของทีม เช่น KPI ได้ไหม

• ไม่ควรทำอย่างยิ่ง
• velocity ได้จากการ estimate ขนาดและเวลา เพื่อ forecast คร่าวๆ มันไม่มีอะไรมากไปกว่าการเดาอย่างมีหลักการ เมื่อไหร่ที่เอา velocity ไปประเมินการทำงาน เช่น KPI (ที่มักจะเอาไปผูกกับเงินเดือน โบนัส) เมื่อนั้นความโปร่งใสหรือ transparency ระหว่างทีมกับ PO หรือหัวหน้า/ลูกน้อง จะหายไป ตามมาด้วยความไม่ไว้ใจกัน สุดท้ายเมื่อมันกลายเป็น culture ทีมจะไม่ยอมบอกปัญหา และเมื่อรู็ปัญหานั้นก็จะกลายเป็นเรื่องใหญ่ไปแล้วก็ได้ ไม่คุ้มครับ วัดเรื่องอื่นดีกว่า

5. แล้วการ estimate แบบนี้มัน ok ไหม

• ยังไง estimate ก็คือการประเมินคร่าวๆ ซึ่งไม่มีวิธีไหนแม่น 100% อยู่แล้ว
• ยิ่งการพัฒนา software มันเป็นปัญหาที่ complex (มีปัญหาที่ซับซ้อนหลายปัญหาซ้อนกันอยู่) การทำงานจึงต้องทำแบบ Experiment & Learn เท่านั้น
• การทำ software แบบ Agile จึงกำหนดเป้าระยะสั้นๆ วางแผนคร่าวๆ และปรับแผนให้เกิดความคล่องตัว การประเมิน size จึงเป็นอีกแนวทางนึงที่ช่วยให้เดาด้วยอีกหลักการนึงครับ

Conclusion

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

การประเมินช่วยให้เห็นคร่าวๆ ครับ ไม่ใช่คัมภีร์หรือสิ่งศักดิ์สิทธิ์ที่ห้ามลบหลู่ เพราะฉะนั้นใช้มันให้ถูกทางครับ เพราะเมื่อไหร่ที่เอามันมาเป็นข้อผูกมัดเช่น commitment มันจะมีปัญหาอื่นตามมา งานพัฒนาซอฟท์แวร์ยากอยู่แล้วครับ อย่าทำให้มันยากกว่าเดิมด้วย hard deadline จาก guess-timation เลย ใช้มันเพื่อ forecast ก็พอ ให้น้ำหนักกับการปรับตัวเมื่อมันไม่เป็นไปตามที่คิดสำคัญกว่าครับ

ก็หวังว่าจะมีประโยชน์นะครับ ขอให้สนุกกับการทำ software ครับ