มีการศึกษาเกี่ยวกับประสิทธิภาพ / ประสิทธิผลของ Agile vs Waterfall [ปิด]

ในการประชุมเมื่อวันก่อนมีการเรียกร้องว่าความคล่องตัวนั้นมีประสิทธิภาพเพียง 60% ในเวลาในการพัฒนาเมื่อเทียบกับน้ำตก ฉันไม่ต้องการตรวจสอบหรือปฏิเสธการอ้างสิทธิ์นี้ ฉันสนใจในการค้นหาว่ามีการศึกษาใด ๆ ที่เปรียบเทียบ 2 วิธี

มีการศึกษาอะไรบ้างในการเปรียบเทียบทั้งสองนี้?

หนังสือ"การสร้างซอฟต์แวร์: ใช้งานได้จริงและทำไมเราเชื่อ"มีบางบทเกี่ยวกับวิธีการ Agile รวมถึง XP, Scrum, การพัฒนาซอฟต์แวร์แบบไดนามิกและแบบลีนที่มีการสนับสนุนทางวิทยาศาสตร์ที่ดี คุณภาพสูงอย่างที่คุณคาดหวังจาก O'Reilly หนึ่งในบรรณาธิการคือGreg Wilson ที่ยอดเยี่ยมผู้เขียนวิทยาการคอมพิวเตอร์ที่เชื่อถือได้บรรณาธิการและผู้นำเสนอ

หนังสือเล่มนี้สรุปการศึกษาวิจัยหลายงานรวมถึงงานวิจัยที่ว่องไว ส่วนหนึ่งสรุปการวิจัยรวมถึง"มีสองหัวดีกว่าหนึ่งหรือไม่เกี่ยวกับประสิทธิผลของการเขียนโปรแกรมคู่"โดยDybå, T.; Arisholm, E.; Sjøberg, DIK; Hannay, JE; Shull, F .; และ " การศึกษาเชิงประจักษ์ของการพัฒนาซอฟต์แวร์แบบว่องไว: การทบทวนอย่างเป็นระบบ " โดย Tore Dybåและ Torgeir Dingsøyr

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

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

* นี่ไม่จำเป็นต้องเป็นความคิดเห็นของฉัน!

เท่าที่ฉันไม่ชอบชื่อเรื่องฉันเชื่อว่าการปรับสมดุลและความคล่องตัว: คู่มือสำหรับผู้งงอาจมีข้อมูลบางอย่างที่เกี่ยวข้องกับคุณ หนังสือเล่มนี้โดยสองกระบวนการวิศวกรรมซอฟต์แวร์และผู้เชี่ยวชาญด้านการจัดการโครงการซอฟต์แวร์ - Barry Boehm และ Richard Turner หนังสือเล่มนี้จะกล่าวถึงแง่มุมต่าง ๆ ของวิธีการแบบว่องไวและการขับเคลื่อนตามแผนเปรียบเทียบและตัดกันและยังกล่าวถึงการบูรณาการพวกเขาเพื่อให้บรรลุสถานการณ์ "ดีที่สุดของทั้งโลก"

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

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

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

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

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

จากสิ่งที่ฉันอ่านฉันจะต้องไม่เห็นด้วยกับการประเมินเพื่อนร่วมงานของคุณ ฉันแน่ใจว่าคุณสามารถหากรณีศึกษาบางแห่งที่โครงการเปรียวมีประสิทธิภาพน้อยลง 60% เกี่ยวกับการวัดประสิทธิภาพมากกว่าโครงการที่ขับเคลื่อนด้วยแผนคล้ายกัน อย่างไรก็ตามยังมีการศึกษาที่แสดงให้เห็นว่าความคล่องตัวให้ความพยายามน้อยลง 80% เวลาน้อยลง 50% และความพึงพอใจของลูกค้าต่อผลิตภัณฑ์

ฉันไม่ได้เรียน แต่อยากจะเล่าประสบการณ์ของฉัน

ประสิทธิผลของวิธีการดังกล่าวขึ้นอยู่กับนักวิเคราะห์

เมื่อคุณมีเจ้าของผลิตภัณฑ์ที่ยอดเยี่ยมตัวอย่างเช่น SCRUM นั้นเร็วกว่าวิธีน้ำตกที่มีสเป็คที่ไม่ดีอย่างแน่นอน

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

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

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

เปรียวมีประสิทธิภาพเพียง 60% ในเวลาในการพัฒนา

จริง

แต่นั่นเป็นการวัดที่อ่อนแอ

วิธีการแบบเปรียวมักจะให้คุณค่าที่แท้จริงเร็วกว่า

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

ต่อไป

คุณสามารถวัด "เวลาในการพัฒนา" แยกจาก "เวลาในการพัฒนาและทดสอบ"

เปรียวมักจะรวมถึงการทดสอบ ดังนั้นดูเหมือนช้าลง

การพัฒนาน้ำตกสามารถแยกออกจากการทดสอบได้อย่างหมดจด ดังนั้นรหัสคือ "พร้อมที่จะทดสอบ" เร็วกว่า แต่ไม่ได้ "ทำ" จนกระทั่งในภายหลัง

ดังนั้น. มันถูกต้องทั้งหมด สำหรับสิ่งที่พวกเขาวัด