กับดัก Storypoint และ Man-hour

เมื่อวานนี้แวะเข้าไปที่ Narisa หลังจากที่ไม่ได้เข้าไปนานมาก(คุณroofimonอย่าโกรธนา) อ่านคำตอบหนึ่งแล้วนึกขึ้นได้ว่า เรื่องเกี่ยวกับ storypoint และ man-hour นี่เป็นกับดักสำหรับนักอไจล์มือใหม่ได้เหมือนกัน เดิมนี่ถ้าเราใช้ waterfall เค้าก็จะสอนเราให้ใช้ estimate เป็น man-hour แล้ว ประมาณว่า วันหนึ่งเราทำงานได้กี่ชม. แล้วคำนวณกลับเป็นจำนวนวันที่ต้องใช้ในการทำงานชิ้นนั้นจนเสร็จ เช่น งาน 20 man-hour คนหนึ่งทำได้วันละ 6.5 ชม. (หักเวลาที่ใช้ในการ check mail ประชุม ฯลฯ) ก็จะพบว่า ใช้ประมาณ 3 วันเสร็จ ก็จะเอามา plot ใน Gantt พอเอาทุกงานมา plot ก็จะบอกได้ว่า ทั้งโปรเจ็คเสร็จเมื่อไหร่ ทุกอย่างตรงตัวและสะดวกจริงๆ

เสร็จแล้วประกฏว่ามีเหล่าผู้กล้า(Agile Avagenlist รุ่นแรกๆ) ค้นพบว่ามันไม่จริง(อย่างกับหนัง The Matrix) โปรเจ็คส่วนใหญ่จะ late เสร็จไม่ทัน due-date หรือเสร็จทันก็ต้องทำงานกันหามรุ่งหามค่ำ (เคยคิดมั้ยว่าทำไมคนไอทีไม่มีใครกลับบ้านตรงเวลา) แต่ส่วนใหญ่ก็ยังlateอยู่ดี บางครั้งไม่late แต่ก็ต้องตามแก้ bugs กันตอนหลังมโหฬาร เค้าค้นพบว่าการคิดเป็น man-hour และ คำนวณออกมาเป็น due-date นั้นแหละที่ทำให้เกิดปัญหาเพราะ software ไม่สามารถหา man-hour ที่แท้จริงได้ จึงได้มีการคิดหน่วยวัด สำหรับการ estimate ใหม่ เรียกว่า storypoint

เจ้า storypoint นี่จะแสดง(represent) 3 อย่าง คือ

1. size ขนาดของงาน งานใหญ่ point จะมากกว่า งานเล็ก
2. complexity ความซับซ้อนของงาน งานยาก point จะมากกว่า งานง่าย
3. risk ความเสี่ยง งานที่มีความไม่แน่นอนเช่นมีความรู้น้อยไม่เคยทำ point จะมากกว่า งานที่ตรงตัวตามแบบแผนหรือที่เคยทำมาแล้ว

เหตุผลที่การจัดการโปรเจ็คแบบเดิมสามารถใช้ man-hour ในการประเมินได้เพราะ งานเหล่านั้นเป็นวิศวกรรม งานวิศวกรรมส่วนใหญ่มีความตรงตัวสูง ถูกจัดวางวิชาการ และรูปแบบอย่างดีแล้ว risk และ complexity จึงคงที่ เหลือตัวแปรเดียวคือ size ทำให้ไม่ว่าเอาใครมาทำก็ใช้เวลาเท่ากัน แต่softwareไม่เป็นแบบนั้น ลองอีกคิดว่าเราสร้างตึกมามากกว่า 4,500 ปี ตั้งแต่สมัยบาบิโลนโน่น แต่เราเพ่งรู้จัก software กันแค่ไม่กี่สิบปี Turing machine ซึ่งเป็นต้นแบบแนวคิดในการสร้างคอมพิวเตอร์เพิ่งคิดได้หลังสงครามโลกนี่เอง แต่เราดันเอา software ไปผูกกับวิศวกรรม แล้วเรียกว่า Software Engineering และก็สร้าง software เหมือนสร้างตึกสร้างสะพาน พอไม่สำเร็จก็โทษว่าการจัดการไม่ดี ความจริงแล้วมันผิดกันมาตั้งแต่คิดว่าเป็น Engineering นั่นแหละ

แต่ปัจจุบันนี้เค้าค้นพบกันแล้ว ว่า software เป็น craftmanship เหมือนกันกับ การสร้าง ภาพยนต์ ลองดูหนัง Hollywood ก็ได้ เช้าแก้บทสายถ่ายก็ได้ (Refactoring) หรือ วันดีคืนดีนักแสดงตาย ก็แก้บทให้ ตัวแสดงเป็นคนเดิมแต่ต้องเปลี่ยนหน้าตา เพื่อหนีอันตราย (Embrace change) กำหนดเวลาแน่นอน ว่าจะเข้าโรง ช่วง Summer ปีหน้าเพื่อโกยเงินเด็ก พอถึงเวลาเสร็จแค่ไหนเอาแค่นั้น (Time-boxed) เป็นต้น

เพราะฉะนั้นเราจึงเห็นว่า งานชิ้นเดียวกัน สมมติ 20 points ให้ คนหนึ่งทำอาจจะใช้เวลาไม่เท่ากัน เพราะ skill ไม่เท่ากัน และถ้างานนั้นเป็นงานที่มี complexity สูง skill จะมีผลมาก แต่ถ้างานนั้นเป็นงานที่ size สูง เราก็จะเห็นสองคนใช้เวลาใกล้เคียงกัน หรือถ้าเป็นงาน risk สูง นี่จะบอกอะไรไม่ได้เลย เพราะ skill ต่ำแต่ดวงดี เลือก solution ที่ตอบโจทย์ หรือบังเอิญหาเจอ(research)เจอ ก็อาจเสร็จเร็วกว่าได้

เพราะฉะนั้นระวังนะครับ “ห้าม convert จาก storypoint เป็น man-hour เด็ดขาด” นี่เป็นกับดักสำหรับคนเริ่มต้นทำ Agile ได้จริงๆ

Links
http://www.narisa.com/forums/index.php?showtopic=31561&st=15
https://korn4d.wordpress.com/2010/07/15/why-due-date-is-the-root-of-all-evil/
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
http://agile2009.agilealliance.org/node/908

Advertisements

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s