Agile Story Points vs Hours: วิธีการประเมินการพัฒนาซอฟต์แวร์ให้ดีขึ้น

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

ในบทความนี้ เราเปรียบเทียบสองโมเดลการประมาณที่นิยมมากที่สุดในการพัฒนาซอฟต์แวร์สมัยใหม่: Agile story points vs hours

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

ชั่วโมงนั้นค่อนข้างเข้าใจง่าย และเป็นแบบจำลองการประมาณหลักในการพัฒนาซอฟต์แวร์มาเป็นเวลานาน ชั่วโมง หรือเรียกอีกอย่างว่าชั่วโมงทำงานหรือชั่วโมงทำงาน คือ จำนวนชั่วโมงที่นักพัฒนาใช้ ไปกับโครงการ

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

สารบัญ:

1. ประเด็นเรื่องคืออะไรกันแน่?
2. วิธีคำนวณคะแนนเรื่องราวใน Agile
3. ข้อดีของการประเมินในประเด็นเรื่อง
4. ข้อเสียของการประมาณในประเด็นเรื่อง
5. ข้อดีของการประมาณค่าเป็นชั่วโมง
6. ข้อเสียของการประมาณค่าเป็นชั่วโมง
7. คุณสามารถแปลงคะแนนเรื่องราวเป็นชั่วโมงได้หรือไม่?
8. Story point vs hours: สิ่งที่ควรเลือกสำหรับการพัฒนาซอฟต์แวร์?

ประเด็นเรื่องคืออะไรกันแน่?

ประเด็นเรื่องเป็นรูปแบบการประมาณสัมพัทธ์ของ Agile และ Scrum พวกเขาประเมิน ความพยายามในการสร้างผลิตภัณฑ์ โดยกล่าวถึงสามด้านของการพัฒนา:

• ปริมาณงานที่สินค้าต้องการ

• ความซับซ้อนของคุณสมบัติของผลิตภัณฑ์

• ความเสี่ยงและความไม่แน่นอนที่อาจส่งผลต่อการพัฒนา

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

ดูเรียบง่ายพอบนพื้นผิว แต่ใครเป็นคนกำหนดจำนวนจุดเรื่องราวในแต่ละเรื่อง?

วิธีคำนวณคะแนนเรื่องราวใน Agile

เช่นเดียวกับชั่วโมง คนที่จะทำงานกับผลิตภัณฑ์มักจะประมาณจุดเรื่องราวเพื่อการพัฒนา อย่างไรก็ตาม กระบวนการประมาณค่าจะแตกต่างกันเล็กน้อยกับประเด็นเรื่อง

ในการกำหนดจุดเรื่องราวให้กับเรื่องราวของผู้ใช้ นักพัฒนาหลายคน มีส่วนร่วม ควรมีอย่างน้อยสองคน แต่บริษัทสามารถขอให้นักพัฒนาทั้งหมดของพวกเขามีส่วนร่วมโดยการเล่นตามที่อุตสาหกรรมเรียกว่า Planning Poker นี่คือกฎของเกม:

1. ผู้พัฒนาแต่ละคนจะได้รับชุดไพ่ Planning Poker

2. นักพัฒนาเลือกเรื่องราวของผู้ใช้และหารือเกี่ยวกับความซับซ้อนและความพยายามในการพัฒนาที่จำเป็น

3. นักพัฒนาแต่ละคนจะมอบการ์ดตามจำนวนคะแนนที่พวกเขาจะมอบหมายให้กับเรื่องราว

4. หากค่าประมาณจุดของเรื่องราวเท่ากัน จำนวนคะแนนโดยประมาณจะถูกกำหนดให้กับเรื่องราว

5. หากประเด็นเรื่องราวที่แนะนำแตกต่างกัน นักพัฒนาจะหารือเกี่ยวกับเรื่องราวของผู้ใช้จนกว่าจะได้คะแนนที่คนส่วนใหญ่อนุมัติ

6. นักพัฒนาเลือกเรื่องราวของผู้ใช้ต่อไป

7. ทำซ้ำขั้นตอนที่ 3 ถึง 5

เมื่อกิจกรรมของเราทั้งหมดออกไปทางไกล กระบวนการนี้ได้รับการแก้ไขแล้ว แทนที่จะใช้การ์ดและการประชุม ประเด็นเรื่องจะถูกตัดสินในการสนทนาออนไลน์ ระหว่างการประชุม Zoom หรือใน Messenger

ดูเหมือนว่านี้:

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

มีสองตัวเลือกที่ใช้บ่อยในการประมาณจุดเรื่องราว คุณสามารถกำหนดคะแนน:

• โดยใช้จำนวนเต็มใดๆ (1, 2, 3… 13,14,15, เป็นต้น)

• โดยใช้ตัวเลขในลำดับฟีโบนักชี (1, 2, 3, 5, 8, 13… 55, 89, 144 เป็นต้น)

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

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

ข้อดีของการประเมินในประเด็นเรื่อง

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

1. เนื้อเรื่องไม่ขึ้นกับผู้พัฒนา

คะแนนเรื่องราวสำหรับแต่ละเรื่องราวถูกกำหนดโดย นักพัฒนาหลายคนในการเจรจา และเหตุผลก็คือจำนวนนั้นไม่ได้กำหนดให้กับผลิตภัณฑ์ใดผลิตภัณฑ์หนึ่งโดยเฉพาะและผู้พัฒนารายหนึ่งรายใดรายหนึ่ง แต่ "โดยเฉลี่ย" ทำไมถึงเป็นสิ่งที่ดี?

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

เมื่อเปลี่ยนแล้ว นักพัฒนารายใหม่อาจมีความเร็วในการทำงานที่ต่างออกไป ซึ่งจะนำไปสู่การประมาณชั่วโมงพนักงานใหม่ที่จำเป็นในการสร้างผลิตภัณฑ์

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

2. เนื้อเรื่องช่วยให้คำนวณเวลาในการพัฒนาได้ง่ายขึ้น

ในการประมาณเวลาแบบ Agile ด้วยคะแนนเรื่องราว ทีมใช้คำว่าความเร็วเพื่ออ้างถึงจำนวนจุดเรื่องราวที่ปล่อยออกมาในการวิ่งครั้งเดียว

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

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

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

3. Story point ดีต่อการติดตามผลงานของทีม

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

ความเร็วเป็นเครื่องมือที่ยอดเยี่ยมในการประเมินประสิทธิภาพของทีมของคุณ ไม่ใช่แค่ในทันทีแต่อย่างต่อเนื่อง

4. การประมาณเวลาเปิดตัวพร้อมเนื้อเรื่องแม่นยำยิ่งขึ้น

ด้วยการติดตามความเร็ว ทีมรู้ด้วยความแม่นยำสูงว่าพวกเขาสามารถปล่อยเรื่องราวได้กี่ประเด็นในการวิ่งครั้งเดียว แม้ว่าทีมพัฒนาแอปจะใช้เวลาสักครู่ในการคำนวณความเร็ว แต่เมื่อคำนวณแล้ว วันที่เปิดตัวโดยประมาณก็คาดการณ์ ได้ง่าย

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

5. คุณสามารถใช้จุดเรื่องราวซ้ำสำหรับโครงการในอนาคตเพื่อเพิ่มความเร็วในการประเมิน

ไม่ใช่เรื่องแปลกที่บริษัทจะเชี่ยวชาญเฉพาะเจาะจง (หรือหลายแห่ง) และสร้างผลิตภัณฑ์มากกว่าหนึ่งรายการที่มีคุณสมบัติคล้ายคลึงกัน หลังจากเสร็จสิ้นโครงการหนึ่งโครงการที่ประเมินในประเด็นเรื่องราวแล้ว นักพัฒนาสามารถ อ้างอิงการประมาณนี้สำหรับโครงการใหม่ ซึ่งจะทำให้ระยะเวลาในการประมาณค่าสั้นลง

อย่างไรก็ตาม การติดตามความเร็วของแต่ละโครงการเป็นสิ่งสำคัญ เนื่องจากสถานการณ์สามารถเปลี่ยนแปลงได้

6. เนื้อเรื่องช่วยเสริมการทำงานเป็นทีม

ตามเนื้อผ้า บริษัทพัฒนามีทีมนักพัฒนาหลายทีม โดยแต่ละทีมทำงานในโครงการแยกกัน เมื่อประมาณค่าเป็นชั่วโมง นักพัฒนาที่ทำงานในโครงการเป็นผู้ประเมิน นี่เป็นเรื่องดีโดยทั่วไป เพราะใครจะรู้ดีว่าจะใช้เวลานานแค่ไหนกว่าคนที่ทำมัน?

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

ข้อเสียของการประมาณในประเด็นเรื่อง

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

1. ควรกำหนดจุดเนื้อเรื่องโดยผู้พัฒนามากกว่าหนึ่งราย

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

2. การประมาณค่าในประเด็นเรื่องต้องใช้งานในมือจำนวนมาก

เพื่อให้ทราบถึงศักยภาพของประเด็นเรื่องราวอย่างเต็มที่ ทีมของคุณจะต้องใช้ เวลาพอ สมควร หากคุณกำลังทำงานในโครงการที่มีคุณลักษณะที่ทีมไม่เคยทำงานมาก่อน (หรือยังไม่ได้ทำงานเต็มเวลา) การวิ่งสองถึงสามครั้งแรกจะคาดเดาประสิทธิภาพได้ยาก จริงอยู่ที่ ยิ่งทีมของคุณมีงานในมือมากเท่าใด การประมาณการของพวกเขาก็จะยิ่งแม่นยำมากขึ้นเท่านั้น เนื่องจากข้อมูลทางสถิติมีมากมาย แต่ประเด็นเรื่องไม่ใช่ระบบที่พร้อมจะดำเนินไปในทันที

3. เนื้อเรื่องมีความซับซ้อนมากขึ้นสำหรับการจัดทำงบประมาณ

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

ประเด็นคือ นักพัฒนาใช้เวลากับโปรเจ็กต์ไม่เพียงแต่ในการเขียนโค้ด (หรือการออกแบบ หรือการทดสอบ) ใช้เวลาในการค้นคว้า อภิปราย — ภายในทีมและกับลูกค้า — ทำการเปลี่ยนแปลง ฯลฯ เวลาที่ใช้ในการประมาณคะแนนเรื่องราวก็เป็นเวลาที่ใช้ในโครงการเช่นกัน แต่จะไม่รวมอยู่ในคะแนนต่อเรื่องราว

การจัดงบประมาณเมื่อประมาณประเด็นเรื่องราวเป็นไปได้ แต่โดยปกติแล้วจะเร็วกว่าและง่ายกว่าในการเทียบเงินกับเวลาที่ใช้ในโครงการ

4. ความเร็วคำนวณต่อทีม

สิ่งนี้หมายความว่าหากทีมผสมกันระหว่างโปรเจ็กต์ คุณจะต้อง คำนวณความเร็วสำหรับ นักพัฒนา แต่ละชุด แยกกัน ดังนั้น การประมาณการสำหรับทีมหนึ่งไม่จำเป็นต้องเป็นจริงสำหรับอีกทีมหนึ่ง และแม้แต่การเปลี่ยนสมาชิกในทีมคนเดียวก็อาจทำให้การประมาณการก่อนหน้านี้เป็นโมฆะได้

ในทางกลับกัน คุณสามารถใช้การประมาณความซับซ้อนเพื่อค้นหาชุดค่าผสมที่ทำงานได้ดีที่สุด มันจะต้องใช้เวลาแม้ว่า

ข้อดีของการประมาณค่าเป็นชั่วโมง

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

1. ชั่วโมงเป็นแบบอย่างที่คุ้นเคย

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

ความแตกต่างในความแม่นยำของการประมาณการอาจไม่มากพอสำหรับนักพัฒนาบางคนในการเปลี่ยนแปลงวิธีการทำสิ่งต่างๆ

2. ลูกค้ามักจะจ่ายเป็นชั่วโมง

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

3. การประมาณค่าตามชั่วโมงสามารถทำได้โดยผู้พัฒนารายเดียว

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

ในทางกลับกัน ชั่วโมง ให้นักพัฒนาที่ทำงานในโครงการสามารถ ประมาณการได้อย่างแม่นยำ

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

ข้อเสียของการประมาณค่าเป็นชั่วโมง

ต่อไปนี้คือสาเหตุที่ทีมอาจตัดสินใจหยุดใช้ชั่วโมงเป็นตัวแบบการประมาณ

1. ความรับผิดชอบในการประมาณการอย่างเดียวคือความกดดันมาก

ในแง่หนึ่ง การประมาณความต้องการเวลาของคุณเองอาจทำได้ง่ายขึ้น เนื่องจากคุณต้องพึ่งพาตัวเองเท่านั้น

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

ยิ่งไปกว่านั้น ความเครียดที่เกิดจากแรงกดดันในการส่งมอบสิ่งที่คุณสัญญาไว้สามารถขัดขวางงานที่ดำเนินไปได้ดี

2. การประมาณการของนักพัฒนาคนหนึ่งมักจะแม่นยำน้อยกว่าของทีมเสมอ

การประมาณการส่วนบุคคลเป็นเรื่องส่วนตัวและเชื่อมโยงกับสถานการณ์ทางอารมณ์และจิตใจของผู้ประมาณ

นักพัฒนาบางคน มักจะประเมินตัวเองสูงเกินไป และกำหนดกรอบเวลาที่พวกเขาพยายามรักษาไว้ในภายหลัง สิ่งนี้ไม่เพียงแต่ขัดขวางการพัฒนา (และทำให้เกิดค่าใช้จ่ายเพิ่มเติมในทีมหากมีค่าปรับ) แต่ยัง ทำให้เกิดความเครียดและความเหนื่อยหน่ายในตัวนักพัฒนา

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

3. ยิ่งงานใหญ่ ยิ่งยากต่อการประมาณเป็นชั่วโมง

สิ่งนี้สัมพันธ์กับสถานการณ์ที่ไม่พัฒนาเช่นกัน เป็นเรื่องง่ายที่จะบอกว่าต้องใช้เวลาเท่าไรในการอ่านหนังสือจุลสารมหาวิทยาลัยสามหน้า แต่ยากกว่าที่จะประเมินว่าต้องใช้เวลานานแค่ไหนกว่าจะเสร็จสิ้น สงครามและสันติภาพ

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

4. มีความยืดหยุ่นน้อย

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

คุณสามารถแปลงคะแนนเรื่องราวเป็นชั่วโมงได้หรือไม่?

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

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

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

ในระดับหนึ่ง การใช้ ลำดับฟีโบนักชี ในการกำหนดประเด็นเรื่องจะพิจารณาความไม่แน่นอนในเวลาพัฒนา แต่ก็ไม่อนุญาตให้มีการแปลงโดยตรงอย่างแน่นอน

นี่คือตัวอย่าง

เรื่องราวแบบจุด 1 เรื่อง (เรื่องพื้นฐาน) ใช้เวลาสองชั่วโมงจึงจะเสร็จสมบูรณ์

เรื่องราวที่มีเนื้อหา 13 เรื่อง อาจ ใช้เวลา 26 ชั่วโมง ในสถานการณ์ที่ดีที่สุด – หากไม่มีอะไรผิดพลาดหรือขัดขวาง ตัวอย่างเช่น หาก API ที่ใช้เข้ากันได้อย่างลงตัว ปลายทางไปยังปลายทาง แต่ถ้าไม่ เรื่องราวอาจต้องใช้เวลาระหว่าง 30 ถึง 50 ชั่วโมง ขึ้นอยู่กับ จำนวนที่ ไม่ตรงกัน ไม่มีใครสามารถพูดได้ล่วงหน้าว่าจะเป็นอย่างไรหากนักพัฒนายังไม่ได้ทำงานกับ API ที่เป็นปัญหา

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

Story point vs hours: สิ่งที่ควรเลือกสำหรับการพัฒนาซอฟต์แวร์?

อย่างที่คุณเห็น ทั้งประเด็นเรื่องและเวลาเป็นตัวเลือกที่ถูกต้องสำหรับนักพัฒนาในการประมาณโครงการ

โดยรวมแล้ว เราคิดว่าบริษัทผลิตภัณฑ์จำนวนมากขึ้นเลือกประเด็นเรื่องในขณะที่ผู้เอาต์ซอร์ซมักจะเอนเอียงไปทางชั่วโมง

บริษัทที่ทำงานกับแบบจำลองราคาคงที่มักจะใช้การประมาณแบบเป็นชั่วโมง ทีมที่ชอบ Scrum มักจะเลือกประเด็นเรื่อง เนื่องจากพวกเขาถือกำเนิดมาจาก Scrum อย่างแท้จริง และมีต้นกำเนิดมาจากวิธีการนี้
จากประสบการณ์หลายปีมานี้ เราได้เห็นสิ่งนี้:

• หากการประมาณวันที่เปิดตัวอย่างถูกต้องมีความสำคัญมากกว่าความเหมาะสมของงบประมาณ ให้ไปที่ประเด็นเรื่อง

• หากงบประมาณมีความสำคัญมากกว่าวันเปิดตัวที่ถูกต้อง ให้พิจารณาชั่วโมง

หรือดีที่สุด รวมทั้งสองอย่างเข้าด้วยกัน

เนื้อเรื่อง สะดวกมากสำหรับทีมพัฒนาที่ทำงานในโครงการขนาดยาว ซึ่งการตรวจสอบความเร็วจะสร้างความแตกต่าง

เวลาทำการ มีความสำคัญสำหรับลูกค้าที่กังวลเรื่องการใช้งบประมาณ นอกจากนี้ ชั่วโมงยังเหมาะสมกว่าสำหรับโครงการระยะสั้น

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