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

ปัญหาคือฉันจะเข้าใกล้เผาไหม้ได้อย่างไร? หากฉันรวมชั่วโมงเข้าด้วยกันให้ถือว่าการประมาณการต่อไปนี้:

10 ชั่วโมง - เวลาการปรับปรุง

4 ชม. - QA

4 ชม. - ตรวจสอบรหัส

ประมาณการงาน = 18 ชม

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

UPDATE

เพื่อช่วยอธิบายสิ่งเล็ก ๆ น้อย ๆ ที่องค์กรของฉันแต่ละงานในเรื่องราวต้องใช้ 3 คน

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

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

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

นั่นคือ 3 ภารกิจไม่ใช่งานเดียว

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

TL; DR

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

ใน Scrum คุณควรวัดความก้าวหน้าของเป้าหมาย Sprint แทนที่จะวัดกล่องเวลาของ Sprint สิ่งนี้จะมุ่งเน้นไปที่ความสามารถของทีมและการส่งมอบคุณลักษณะมากกว่าการปรับการตั้งเวลาอย่างต่อเนื่อง

งานกับเรื่อง

คุณกำลังสร้างความสับสนให้กับงานและเรื่องราว เรื่องราวประกอบด้วยงานทั้งหมดที่จำเป็นในการทำให้เรื่องราวเสร็จสมบูรณ์ตาม "คำจำกัดความของการกระทำของทีม" เรื่องนี้ถือว่าสมบูรณ์ 100%เว้นแต่งานทั้งหมดจะเสร็จสมบูรณ์ ในการต่อสู้เรื่องต่าง ๆ มักจะถูกประเมินในบางวิธี; บ่อยที่สุดพวกเขาถูกประเมินในจุดเรื่องราว

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

มอดไหม้

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

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

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

เวลามวย

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

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

คุณสามารถกำหนดภารกิจ dev เป็น "เสร็จสิ้น" ก่อนที่ QA จะทำส่วนของพวกเขาได้หรือไม่? คุณสามารถกำหนดการทบทวนรหัสว่า "เสร็จสิ้น" ก่อนที่จะทำ dev ได้หรือไม่? QA จะ "เสร็จสิ้น" ได้หรือไม่หาก dev และการตรวจสอบโค้ดไม่ใช่

ฉันจะบอกว่าคุณควรรวมสามรายการไว้ในงานเดียวและทั้งสามคนควรทำงานร่วมกัน

การต่อสู้ไม่ได้บอกว่าสิ่งใดเป็นความรับผิดชอบของสมาชิกในทีมคนใดคนหนึ่ง ตรงข้าม - รายการบันทึกการวิ่งเป็นความรับผิดชอบของทีม ถ้าใช้คนสามคนในการทำงานนั่นก็คือสิ่งที่ต้องทำ

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

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

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

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

เวลาที่เหลืออยู่ของภารกิจไม่สำคัญมาก: ไม่มีอะไรสามารถส่งได้จนกว่าเรื่องราวทั้งหมดจะเสร็จสิ้น

หากคุณต้องการติดตามเวลาที่เหลืออยู่ในเรื่อง (โดยรวม) โดยให้ผู้คนกรอกเวลาที่เหลืออยู่ในงานให้แยกงานต่อคน

ที่กล่าวว่า:

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

แบ่งงานออกเป็นหลาย ๆ งานและป้อนเป็นงานที่แต่ละคนจัดการโดยบุคคลอื่น

งานดั้งเดิม: แก้ไขบางสิ่งบางอย่าง

งานใหม่: (ลูกของผู้ปกครองของงานเดิม)

• Dev A - แก้ไขปัญหา
• Dev B - ช่วย Dev A ในการแก้ไขปัญหา (เช่นการเขียนโปรแกรมคู่การตรวจสอบโค้ด)
• Dev A - dev ทดสอบการแก้ไขโดยใช้ชุดข้อมูล X
• Dev B - dev ทดสอบการแก้ไขโดยใช้ชุดข้อมูล Y