Refactoring ในการพัฒนา Agile
ในโครงการพัฒนาแอปขอบเขตทั้งหมดของโครงการไม่ได้รับการพิจารณาในการออกแบบแอป ดังนั้นการปรับโครงสร้างโค้ดบ่อยๆเพื่อรองรับการเปลี่ยนแปลงจึงส่งผลเสียต่อไทม์ไลน์การส่งมอบโครงการซึ่งจำเป็นในระหว่างการวิ่ง จะควบคุมสิ่งนี้ได้ดีที่สุดเพียงใดเพื่อลดความเสี่ยงจากการเกินกำหนดวันส่งมอบโครงการที่ตกลงกันไว้เนื่องจากผู้มีส่วนได้ส่วนเสียไม่เต็มใจที่จะประนีประนอม
คำตอบ
TL; ดร
ส่วนหนึ่งของกรอบการจัดการโครงการใด ๆ แต่โดยเฉพาะอย่างยิ่งกรอบการทำงานที่คล่องตัวเช่น Scrum คือความจำเป็นในการจัดการความคาดหวังของผู้มีส่วนได้ส่วนเสียอย่างต่อเนื่อง ผู้คนต้องการสิ่งที่ต้องการเมื่อต้องการ แต่ส่วนใหญ่ของการจัดการโครงการคือการอธิบายให้ผู้คนทราบว่าพวกเขาสามารถมีอะไรได้บ้างภายในข้อ จำกัด ต่างๆที่ส่งผลกระทบต่อโครงการ เมื่อโครงการพัฒนาขึ้นดังนั้นควรทำความเข้าใจกับสิ่งที่เป็นไปได้ในปัจจุบันภายในข้อ จำกัด ในขณะนั้นโดยเฉพาะอย่างยิ่งเมื่อสิ่งที่เป็นไปได้แตกต่างจากที่วางแผนไว้ในตอนแรก
คาดว่าจะมีการปรับปรุงใหม่
Refactoringการเปลี่ยนแปลงการดำเนินการโดยไม่ต้องเปลี่ยนพฤติกรรมภายนอก คุณไม่ได้ปรับโครงสร้างใหม่จริงๆ คุณกำลังจ่ายหนี้ทางเทคนิคหรือดำเนินการซ้ำและบูรณาการซึ่งไม่ใช่สิ่งเดียวกันภายใน
กรอบงานเช่น Scrum ถือว่างานประเภทต่างๆ (รวมถึงการปรับโครงสร้างและการทำงานซ้ำ) เป็นการแลกเปลี่ยนที่ยอมรับได้สำหรับการควบคุมและการออกแบบเชิงประจักษ์ สิ่งนี้ได้รับการจัดการในขั้นตอนการประมาณค่าและ (อย่างถูกต้อง) จะแสดงเป็นการลากความเร็วเนื่องจากหนี้เทคโนโลยีความซับซ้อนหรือการเปลี่ยนแปลงเพิ่มขึ้น สิ่งนี้เป็นทั้งที่คาดหวังและเป็นที่พึงปรารถนาในกรอบการทำงานซ้ำ ๆ เนื่องจากแต่ละลูปตรวจสอบและปรับเปลี่ยนให้โอกาสในการเปลี่ยนแปลงขอบเขตการจัดลำดับความสำคัญหรือแนวทาง
การทำใหม่เป็นต้นทุนของการควบคุมเชิงประจักษ์ คุณไม่สามารถหลีกเลี่ยงได้จริงในโครงการที่ซับซ้อนเช่นการพัฒนาซอฟต์แวร์ การต่อสู้จะทำให้ทีมงานและผู้มีส่วนได้ส่วนเสียมองเห็นการทำงานซ้ำเป็นต้นทุนในการเปลี่ยนแปลงที่จำเป็นหรือพึงปรารถนา
คงที่ทุกอย่างเป็นไปไม่ได้
"สามเหลี่ยมเหล็ก" วางตำแหน่งที่คุณสามารถปรับเปลี่ยนโครงการโดยการควบคุมงบประมาณขอบเขตหรือกำหนดเวลาโดยมีคุณภาพเป็นมิติที่สี่โดยนัยที่ได้รับผลกระทบจากตัวเลื่อนอีกสามตัว กราฟิกต่อไปนี้แสดงให้เห็นถึงสิ่งนี้
เฟรมเวิร์กแบบ Agile เช่น Scrum โดยทั่วไปถือว่าขอบเขตและโดยเฉพาะขอบเขตโปรเจ็กต์เป็นตัวเลื่อนหลักโดยถามว่า:
ขอบเขตที่เราสามารถใส่ลงในช่องเวลาของ Sprint เดียวได้มากน้อยเพียงใดหรือเหมาะสมกับแผนการเผยแพร่แบบ Agileของเรา?
ขณะนี้โครงการของคุณกำลังพยายามแก้ไขทั้งขอบเขตและกำหนดการ ซึ่งจะทำให้งบประมาณเป็นตัวเลื่อนที่มีอยู่ของคุณเท่านั้น หากคุณพยายามล็อคสิ่งนั้นด้วยเช่นกันโครงการของคุณจะล้มเหลวหรือคุณภาพจะได้รับผลกระทบหรือทั้งสองอย่าง คุณไม่สามารถทำราคาคงที่ขอบเขตคงที่และกำหนดเวลาที่แน่นอนได้อย่างน่าเชื่อถือในกรอบโครงการใด ๆในขณะที่รักษาคุณภาพ การต่อสู้ทำให้ชัดเจนยิ่งขึ้นและทำให้การแลกเปลี่ยนมองเห็นได้ชัดเจนขึ้น
ประเด็นของการต่อสู้ไม่ได้อยู่ที่การทำให้สามเหลี่ยมเหล็กหายไปอย่างน่าอัศจรรย์ แต่จะบังคับให้โครงการ (ตลอดจนผู้มีส่วนได้ส่วนเสียและผู้ให้การสนับสนุน) ตกลงกับการแลกเปลี่ยนโดยธรรมชาติ Scrum ช่วยให้ผู้มีส่วนได้ส่วนเสียสามารถตัดสินได้ว่าสิ่งที่ "ดีพอ" ที่จะจัดส่งเมื่อสิ้นสุด Sprint แต่ละครั้งและเจ้าของผลิตภัณฑ์จะได้รับโอกาสในการปรับขอบเขตและการจัดลำดับความสำคัญในระหว่างการปรับแต่ง Backlog และการวางแผน Sprint ผู้มีส่วนได้ส่วนเสียจำเป็นต้องใช้ประโยชน์จากเหตุการณ์เหล่านี้เพื่อให้แน่ใจว่าพวกเขาได้รับคุณค่าสูงสุดที่เป็นไปได้ภายในแผนการเผยแพร่ มันเป็นสิ่งที่ไม่เคยรับประกันคืนเงินกลับมาว่าโครงการจะเป็นได้ทั้ง 100% ที่สมบูรณ์หรือเหมาะสมกับวัตถุประสงค์ในตอนท้ายของชุดถาวรของลมพัด
ลดต้นทุนจม
อีกแง่หนึ่งของการพัฒนาที่คล่องตัวคือโอกาสที่จะ "ล้มเหลวในช่วงต้น" เมื่อโครงการมีแนวโน้มที่จะล้มเหลวไม่ว่าด้วยเหตุผลใดก็ตามกรอบการทำงานแบบ Agile เช่น Scrum ให้โอกาสเจ้าของผลิตภัณฑ์ในการประหยัดเงินโดยการยกเลิก Sprint และวางแผนงานใหม่ตามความคาดหวังที่เปลี่ยนแปลงหรืออนุญาตให้ผู้มีส่วนได้ส่วนเสียยกเลิกส่วนที่เหลือของโครงการหาก จะไม่ตอบสนองวัตถุประสงค์ของพวกเขา หลังจะไม่ทำให้โครงการประสบความสำเร็จ แต่จะช่วยลดต้นทุนจมที่เกี่ยวข้องกับโครงการ
ไม่มีใครสามารถรับประกันได้ว่าโครงการจะประสบความสำเร็จ สิ่งที่ดีที่สุดที่คุณทำได้คือควบคุมมันและฆ่าโครงการที่ถึงวาระโดยเร็วที่สุดเมื่อความสำเร็จไม่ใช่ทางเลือกอีกต่อไป
สิ่งที่คุณทำได้ตอนนี้
อันดับแรกยอมรับว่าคุณกำลังอยู่ในเส้นทางสู่การเดินขบวนแห่งความตาย หากคุณไม่เผชิญกับความจริงนั้นไม่มีอะไรที่คุณจะทำอีกต่อไป
จากนั้นพิจารณาว่าปัญหาคือการออกแบบหนี้เทคโนโลยีความคาดหวังที่ไม่สมเหตุสมผลหรืออย่างอื่น ไม่สำคัญว่าต้นเหตุหรือสาเหตุคืออะไร คุณเพียงแค่ต้องทำให้พวกเขามองเห็นได้เพื่อให้ทีมและผู้มีส่วนได้ส่วนเสียสามารถร่วมกันพูดคุยกับพวกเขาได้
สุดท้ายสื่อสารสถานะปัจจุบันให้ชัดเจน หากคุณกำลังจะเปิดตัวรุ่นที่มีคุณสมบัติครบถ้วนสองสามรอบหลังจากวันที่ส่งมอบที่คาดการณ์ไว้ในตอนแรกให้หารือว่าโครงการสามารถปรับจุดยอดของ "เวลา" ได้หรือไม่ หากคุณไม่สามารถปรับเปลี่ยนกำหนดการได้หรือไม่ได้แสดงว่าคุณยังสามารถทำตามกำหนดเวลาที่กำหนดได้โดยการเพิ่มค่าใช้จ่ายหรือลดขอบเขต ผู้มีส่วนได้ส่วนเสียจะแลกเปลี่ยนการส่งมอบตรงเวลาเพื่อลดฟังก์ชันการทำงานที่ใช้เวลาน้อยลงหรือไม่? คุณจะไม่รู้เว้นแต่คุณจะถาม
หากโครงการไม่สามารถหรือไม่ทำสิ่งใดสิ่งหนึ่งข้างต้นให้เตรียมพร้อมสำหรับความล้มเหลว ทบทวนประวัติย่อของคุณและหวังว่าคุณจะได้เรียนรู้บทเรียนที่มีค่าซึ่งคุณสามารถใช้ในโครงการถัดไปหรืองานถัดไป ที่สำคัญที่สุดหวังว่าคุณจะได้เรียนรู้ที่จะสื่อสารตั้งแต่เนิ่นๆและบ่อยครั้งเกี่ยวกับสมมติฐานความท้าทายข้อกำหนดของกรอบการทำงานและการแลกเปลี่ยนและกำหนดความสำคัญของการจัดการความคาดหวังของผู้มีส่วนได้ส่วนเสียอย่างต่อเนื่อง
คุณกำลังผลิตผลิตภัณฑ์ที่เพิ่มขึ้นในแต่ละสปรินต์หรือไม่ หากเป็นเช่นนั้นก็จะตรงตามวันที่จัดส่งที่ตกลงกันไว้และนั่นเป็นวิธีที่ดีที่สุดในการลดความเสี่ยงและให้ความมั่นใจแก่ลูกค้าในสิ่งที่คุณกำลังทำ ผู้มีส่วนได้ส่วนเสีย (ผ่านทางเจ้าของผลิตภัณฑ์) ควรตัดสินใจว่าต้องการอะไรและเมื่อใดสิ่งที่สำคัญที่สุดคือพวกเขายังคงเห็นว่าคุณส่งมอบคุณค่าและคุณจะได้รับคำติชมเกี่ยวกับการปรับปรุงเปลี่ยนแปลงและแก้ไขที่จำเป็นสำหรับผลิตภัณฑ์ การรับคำติชมเป็นสิ่งสำคัญที่นี่ ลูกค้าอาจรู้สึกกังวลหากไทม์ไลน์ขยายออกไปโดยไม่มีขอบเขตการทำงานใหม่ ๆ แต่ทันทีที่คุณเริ่มรวมการปรับปรุงล่าสุดที่พวกเขาเห็นว่ามีความสำคัญพวกเขาจะมีแนวโน้มที่จะเข้าใจถึงความต้องการความยืดหยุ่น