ฉันอยู่ในทีมโปรเจคที่มี 4 devs ฉันรวมอยู่ด้วย เราได้มีการพูดคุยกันอย่างยาวนานเกี่ยวกับวิธีจัดการกับงานพิเศษที่เกิดขึ้นในรายการงานชิ้นเดียว
งานพิเศษนี้มักจะเป็นสิ่งที่เกี่ยวข้องกับงานเล็กน้อย แต่ไม่จำเป็นเสมอไปที่จะบรรลุเป้าหมายของรายการ (อาจเป็นความเห็น) ตัวอย่างรวมถึง แต่ไม่ จำกัด เฉพาะ:
- refactoring ของรหัสการเปลี่ยนแปลงโดยรายการงาน
- refactoring code ที่อยู่ใกล้เคียงรหัสที่ถูกเปลี่ยนแปลงโดยรายการ
- ออกแบบพื้นที่โค้ดขนาดใหญ่รอบตั๋วอีกครั้ง ตัวอย่างเช่นหากรายการที่คุณเปลี่ยนฟังก์ชั่นเดียวคุณรู้ว่าตอนนี้ทั้งคลาสสามารถทำซ้ำได้เพื่อให้รองรับการเปลี่ยนแปลงนี้ได้ดียิ่งขึ้น
- ปรับปรุง UI บนแบบฟอร์มที่คุณเพิ่งแก้ไข
เมื่องานพิเศษนี้เล็กเราไม่รังเกียจ ปัญหาคือเมื่องานพิเศษนี้ทำให้ส่วนขยายของรายการเกินกว่าการประมาณจุดคุณลักษณะดั้งเดิม บางครั้งรายการ 5 คะแนนจะใช้เวลา 13 คะแนน ในกรณีหนึ่งเรามีรายการ 13 จุดที่ในการหวนกลับอาจมี 80 คะแนนหรือมากกว่า
ในการสนทนาของเรามีสองทางเลือกสำหรับวิธีจัดการกับปัญหานี้
เราสามารถรับงานพิเศษในรายการงานเดียวกันและเขียนออกเป็นการประเมินที่ผิดพลาด อาร์กิวเมนต์สำหรับสิ่งนี้ได้รวม:
- เราวางแผนสำหรับ "การเติมเต็ม" ในตอนท้ายของการวิ่งเพื่ออธิบายสิ่งนี้
- ปล่อยให้รหัสอยู่ในรูปที่ดีกว่าที่คุณพบเสมอ อย่าเช็คอินงานครึ่งทาง
- หากเราออกจากการปรับโครงสร้างใหม่ในภายหลังมันยากที่จะกำหนดเวลาและอาจไม่เสร็จสิ้น
- คุณอยู่ใน "บริบท" ทางจิตใจที่ดีที่สุดในการจัดการงานนี้ในขณะนี้เนื่องจากคุณอยู่ลึกเข้าไปในรหัสแล้ว ดีกว่าที่จะนำมันออกไปให้พ้นทางและมีประสิทธิภาพมากกว่าที่จะเสียบริบทนั้นไปเมื่อคุณกลับมาในภายหลัง
เราวาดเส้นสำหรับไอเท็มงานปัจจุบันและบอกว่างานพิเศษเข้าสู่ตั๋วแยกต่างหาก ข้อโต้แย้งรวมถึง:
- การมีตั๋วแยกต่างหากช่วยให้การประเมินใหม่ดังนั้นเราจึงไม่โกหกตัวเองเกี่ยวกับจำนวนของสิ่งที่เป็นจริงหรือต้องยอมรับว่าการประเมินทั้งหมดของเรานั้นแย่มาก
- sprint "padding" มีไว้สำหรับความท้าทายทางเทคนิคที่ไม่คาดคิดซึ่งเป็นอุปสรรคโดยตรงต่อการทำตั๋วให้เสร็จสมบูรณ์ มันไม่ได้มีไว้สำหรับรายการด้านที่เป็นเพียง "นิสัยดี"
- หากคุณต้องการกำหนดเวลาการเปลี่ยนโครงสร้างใหม่ให้วางไว้ที่ด้านบนสุดของ backlog
- ไม่มีวิธีที่เราจะบัญชีสิ่งนี้อย่างถูกต้องในการประมาณค่าเนื่องจากดูเหมือนว่าจะเป็นเรื่องค่อนข้างง่ายเมื่อมันเกิดขึ้น ผู้ตรวจสอบรหัสอาจบอกว่า "การควบคุม UI เหล่านั้น (ซึ่งคุณไม่ได้แก้ไขในรายการงานนี้) นั้นสับสนเล็กน้อยคุณสามารถแก้ไขได้หรือไม่" ซึ่งเหมือนชั่วโมง แต่พวกเขาอาจพูดว่า "ถ้าการควบคุมนี้ตอนนี้สืบทอดมาจากคลาสฐานเดียวกันกับที่อื่นทำไมคุณไม่ย้ายโค้ด (หลายร้อยบรรทัด) ทั้งหมดนี้ไปยังฐานและรวบรวมสิ่งนี้ทั้งหมด การเปลี่ยนแปลงเรียงซ้อน ฯลฯ ? " และนั่นใช้เวลาหนึ่งสัปดาห์
- มัน "ปนเปื้อนที่เกิดเหตุ" โดยการเพิ่มงานที่ไม่เกี่ยวข้องลงในตั๋วทำให้จุดคุณลักษณะดั้งเดิมของเราประเมินโดยไม่มีความหมาย
- ในบางกรณีงานพิเศษเลื่อนการเช็คอินออกไปทำให้เกิดการบล็อกระหว่าง devs
พวกเราบางคนกำลังบอกว่าเราควรตัดสินใจว่าจะตัดอะไรบางอย่างออกไปเช่นถ้ามีสิ่งเพิ่มเติมน้อยกว่า 2 FP มันจะไปในตั๋วใบเดียวกันถ้ามากกว่านั้นให้ทำเป็นตั๋วใหม่
เนื่องจากเราใช้เวลาเพียงไม่กี่เดือนในการใช้ Agile ความคิดเห็นของทหารผ่านศึก Agile ที่มีประสบการณ์มากขึ้นรอบ ๆ ที่นี่เกี่ยวกับวิธีจัดการกับเรื่องนี้คืออะไร?