มารู้จัก Three-point estimation กันเถอะ
สวัสดีครับผู้อ่านทุกท่าน สำหรับผมนั้นห่างหายจากวงการ blogger ไปนานพอสมควร (ประมาณ 2 เดือน) ปกติจะเขียนสัปดาห์ละหนึ่งบทความ แต่ตั้งแต่เปิดเรียน ป โท เสาร์-อาทิตย์ ก็ไม่ได้เขียนอีกเลย งานเยอะมากๆ บางทีอาจารย์ก็ make up class เพิ่มอีก อย่างเช่นวันนี้เรียนตั้งแต่เก้าโมงเช้า ถึงเก้าโมงเย็น เอ้ย! สามทุ่มๆ เบลอมากๆ วันนี้เลยให้เวลาพักผ่อนกับตัวเอง ซึ่งก็คือการเขียน blog นั่นเอง
feeling มาละ แต่ยังไม่มีไอเดียในหัวว่าจะเขียนเกี่ยวกับอะไรดี ก็เลยเอาเนื้อหาบางส่วนที่ได้เรียนนั่นแหละมาแชร์ให้ฟัง เพราะคิดว่าน่าจะเป็นประโยชน์ และสามารถนำไปประยุกต์ใช้ได้หลายอย่าง ซึ่งก็คือทฤษฏี Three-point estimation นั่นเอง เอาล่ะ มาเริ่มกันเลยยย
งานนี้จะใช้เวลาทำโดยคร่าวๆ เท่าไหร่ดี?
เคยไหมครับ คุณเป็น Project Manager ถูก Product Owner push คำถามมาว่า “เฮ้ๆ ยูคิดว่าโปรเจคเนี้ย จะใช้เวลาทำประมาณกี่วันหรอ ช่วยประเมินคร่าวๆ ให้หน่อย ไอต้องเอาคำตอบไปบอกลูกค้า กับ Manager”
เคยไหมครับ คุณเป็น Dev ถูก Project Manager push คำถามมาว่า “ฟีเจอร์เนี้ย จะใช้เวลาทำประมาณกี่วัน ช่วยประเมินอย่างคร่าวๆ ให้หน่อยได้ไหม ผมจะได้แพลน Timeline ได้ถูก”
ซึ่งโดยทั่วไปที่ทำกัน (รวมถึงตัวผมเองที่เป็น Dev) ก็จะใช้สถิติจากโปรเจคที่มีความคล้ายคลึงกันที่เคยทำมาก่อนในอดีต บวกกับประสบการณ์การทำงานของตนเอง กะๆ เวลาให้ไป ซึ่งมันก็ตรงบ้างไม่ตรงบ้างอะเนอะ
Three-point estimation คืออะไร?
ทฤษฎีนี้ผ่านเข้ามาในหูของผมในวิชา Software Project Management ซึ่งเป็นวิชาที่เกี่ยวกับการบริหารจัดการโครงการ หรือก็คือฝึกการเป็น Project Manager นั่นเอง โดยไอ้เจ้า Three-point estimation เนี่ย มันเป็นวิธีการคำนวณระยะเวลาอย่างคร่าวๆ ที่จะต้องใช้ในการทำโปรเจค (แต่ผมมองว่ามันเอาไปใช้กับเรื่องอื่นๆ ได้หมดนะ) แต่ขออธิบายในบริบทของการพัฒนาซอฟต์แวร์ละกัน
Three-point estimation มีหลักง่ายๆ คือ
มองโลกแง่ร้าย มองโลกแง่ปกติ มองโลกแง่ดี แบบ 1:4:1
มองโลกแง่ร้าย (Pessimistic)
การมองโลกแง่ร้าย คือ ให้เราคิดถึงสถาณการณ์ที่ลำบากของเราในการทำงาน แล้วประเมินออกมาเป็นตัวเลข ซึ่งอาจจะเป็นจำนวนวัน หรือจำนวนชั่วโมงก็ได้ ยกตัวอย่างเช่น ผมเป็น iOS Developer ที่จะเขียนฟีเจอร์ registration ด้วย email address, Facebook account, Google account ให้กับแอปพลิเคชันหนึ่งๆ ซึ่งปกติจะใช้เวลาประมาณ 3 วัน รวม UI รวม Unit Test แล้วก็ code สวยๆ หน่อย แต่เผอิญช่วงนั้น Xcode ผมดันงอแง ค้างตลอด บวกกระตุก และทำ file indexing ไม่เสร็จซะที ทำให้ผมต้องเสียเวลาไปหาวิธีแก้ปัญหากับ Xcode ก่อน สมมุติต้องเสียเวลาเพิ่ม 2 วัน ถึงจะทำ registration ต่อได้ แทนที่จะใช้เวลาแค่ 3 วัน ก็กลายเป็น 5 วันล่ะ ทีนี้ก็เก็บตัวเลข 5 วันไว้ในใจก่อน
มองโลกแง่ปกติ (Most likely)
อันนี้ก็ตรงไปตรงมา เราสามารถคาดการณ์ในใจได้อยู่แล้วว่าปกติเราทำงานชิ้นเนี้ย ใช้เวลากี่วัน ยกตัวอย่างเคสผม registration ก็คือ 3 วันนั่นเอง แล้วก็เก็บตัวเลขไว้ก่อนเหมือนเดิม
มองโลกแง่ดี (Optimistic)
อันนี้ก็ลองจินตนาการสถานการณ์ที่ทำให้เราทำงานได้เร็วขึ้น เช่น ออฟฟิตซื้อคอมที่มี spec แรงที่สุดในตลาดให้ผมทำงาน สามารถ debug และ compile code ได้เร็วมาก จากที่ผมต้องใช้ 3 วัน ก็เหลือแค่ 1.5 วันเอง แล้วก็เหมือนเดิม เก็บตัวเลขไว้ก่อน
1:4:1 ratio
เอาล่ะ หลังจากเราได้ตัวเลขทั้งสามค่ามาแล้ว เราก็จะให้น้ำหนักกับแต่ละแบบดังนี้
- มองโลกแง่ร้าย (Pessimistic) 1 ส่วน
- มองโลกแง่ปกติ (Most likely) 4 ส่วน
- มองโลกแง่ดี (Optimistic) 1 ส่วน
ซึ่งรวมกันแล้วเราจะได้ทั้งหมด 6 ส่วน ใช่ม้าาา ทีนี้เราก็เอาตัวเลขจำนวนวันของแต่ละแบบมาคูณกับอัตราส่วนของมัน แล้วนำทั้งสามค่ามาบวกกัน หลังจากนั้นก็หารด้วย 6 ซะ อย่างตัวอย่างของผม ก็จะได้ประมาณนี้
((1.5*1) + (3*4) + (5*1)) / 6 = 3.083 วัน
ผมได้จำนวนวันที่ต้องใช้มาเป็น 3.083 วัน ทีนี้จะเอาไงต่อ เลขไม่ลงตัว คือในทฤษฎีก็ไม่ได้มีบอกว่าจะให้ทำไงต่อ แต่ถ้าเป็นผม ก็จะ buffer ให้ตัวเอง โดยการปัดขึ้นเป็น 4 วันไปเลย (play safe play safe) ดังนั้นผมก็จะตอบ Project Manager ที่มาถามผมว่า “ไอ จะใช้เวลาทำฟีเจอร์ registration+UI+Unit Test รวมทั้งสิ้น 4 วันนะ”
สรุป
อย่างที่บอก Three point estimation เป็นวิธีการคำนวณระยะเวลาที่ต้องใช้ในการทำสิ่งใดสิ่งหนึ่งให้เสร็จอย่างคร่าวๆ ซึ่งผมมองว่า มันก็โอเคกว่าการที่เรากะเวลาเอาเองออกไปแบบไม่มีหลักการอะไรเลย และก็อย่างที่บอกอีกนั่นแหละ เราสามารถเอามันไปใช้กับการประเมินระยะเวลาเรื่องอื่นได้ด้วยนะ ไม่จำเป็นต้องเกี่ยวกับเรื่องงานเสมอไป อันนี้ก็แล้วแต่จะเอาไปพลิกแพลงกันเอง รวมถึงไอ้อัตราส่วน 1:4:1 อ่ะ ถ้าเราเห็นว่าไม่เหมาะสมกับตัวเรา เราก็อาจจะปรับเปลี่ยน (อย่างสมเหตุสมผลได้) เช่น ปรับเป็น 3:7:3 เป็นต้น คือเอาที่เราคิดว่ามันใช่สำหรับเราอ่ะ แต่อย่างน้อยก็ให้จำต้นตำรับไว้ด้วยละกันเนอะ สำหรับวันนี้ก็ลากันตรงนี้เลยละกัน ไว้มีเวลาว่างอีกเมื่อไหร่ จะมาเขียนเรื่องอื่นๆ ต่อนะครับ สวัสดีครับ :)
(T(Pessimistic)+ T(Most likely) * 4 + T(Optimistic)) / 6 เมื่อ T แทนระยะเวลาที่ต้องใช้ในการทำให้งานเสร็จ
ติดตามเรื่องราวต่างๆ ทั้งเทคโนโลยี มุมมองชีวิต การเรียนรู้ การใช้ชีวิต ได้ที่ https://www.facebook.com/itopstory/
