การเปลี่ยนแปลงความคล่องตัวน้ำตกและความต้องการ

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

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

ไม่ขึ้นอยู่กับลักษณะของโครงการ (และกระบวนการ)

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

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

รูปแบบที่คุณติดตามนั้นขึ้นอยู่กับรายละเอียดของแต่ละโครงการ

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

สิ่งนี้ทำให้เดือดร้อนจากหลักการจากแถลงการณ์เปรียว - "บุคคลและการมีปฏิสัมพันธ์กับกระบวนการและเครื่องมือ" และ "การตอบสนองต่อการเปลี่ยนแปลงมากกว่าการทำตามแผน"

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

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

ไม่ว่าปัญหารากคืออะไรคุณต้องแก้ไข การจมอยู่ใต้เลเยอร์ของ "Agile" (หรือวิธีการอื่น ๆ ) จะไม่ทำงาน

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

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

บางทีคุณอาจต้องการการวิ่งที่สั้นกว่านี้?

เพื่อความมีเหตุผลของโปรแกรมเมอร์จะเป็นการดีที่สุดหากข้อกำหนดไม่เปลี่ยนแปลงระหว่างการแก้ไข / การวิ่ง

ในสถานการณ์ของคุณมีสองตัวเลือกที่ชัดเจน:

1. วิ่งสั้นลง
2. ทำให้ลูกค้าเห็นด้วยที่จะไม่เปลี่ยนแปลงข้อกำหนดในระหว่างการแก้ไข / การวิ่งเว้นแต่ว่าการแก้ไข / การวิ่งทั้งหมดจะถูกยกเลิกและวางแผนใหม่

ฉันขอแนะนำทั้งสองอย่าง

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

การเปลี่ยนแปลงที่ง่ายที่สุดที่คุณสามารถทำได้ (หากคุณต้องการติดตามการต่อสู้) คือทำให้การวิ่งสั้นลง - เช่นหนึ่งสัปดาห์ sprints 4 สัปดาห์ถือเป็นตัวเลือกในวันแรกของการต่อสู้ แต่วันนี้ทั่วไปคือ 1 - 2 สัปดาห์และ 3 สัปดาห์ถือเป็นขอบเขตบน 4 สัปดาห์เป็นเวลานานในการเปลี่ยนแปลงสภาพแวดล้อม