Agile เป็นตัวแปรของ RAD หรือไม่?

Wikipedia บอกว่า Agile เป็น "RAD" ประเภทหนึ่งซึ่งฉันเดาว่าไม่ถูกต้อง จากสิ่งที่ฉันรู้ Agile ได้รับการพัฒนาเนื่องจาก RAD เองนั้นไม่เพียงพอใน 90'S (เข้มงวดเกินไปสำหรับการเปลี่ยนแปลง) หรือฉันผิด

(หมายเหตุ: เห็นได้ชัดว่าบทความ Wikipedia เกี่ยวกับการพัฒนาซอฟต์แวร์ Agileได้รับการปรับปรุงในระหว่างนั้นเพียงแค่ระบุว่าRADเป็นผู้บุกเบิกของ Agile ไม่ใช่เป็น superset)

การอ้างอิงจากหนังสือ Radical Project Management (Thomsett)

".. แฟชั่นใหม่ของการพัฒนาเช่น RAD, Agile, Object oriented ... "

ผู้สอบบัญชีระบบข้อมูลรับรอง CISA:

.. ตระหนักถึงซอฟต์แวร์ตัวเลือกสองตัว วิธีการ: การพัฒนาแอพพลิเคชั่นที่คล่องตัวและรวดเร็ว

การจัดการแบบว่องไวสำหรับซอฟต์แวร์:

วิธีการแบบว่องไวส่วนใหญ่มาจากวิธี RAD ที่มีน้ำหนักเบา

แนวทางปฏิบัติที่ดีที่สุดในการประเมินซอฟต์แวร์:

วิธีการหลักของ sw dev สามารถสรุปได้ดังนี้:
1. น้ำตก ..
4. RAD
5. ความคล่องตัว

ประเด็นของคำถามนี้คือ:
RAD ประเภท Agile หรือแนวทางการพัฒนาแบบสแตนด์อโลนหรือไม่?

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

ดังนั้นไม่การพัฒนาซอฟต์แวร์แบบว่องไวไม่ใช่ประเภทของ RAD พวกมันจัดการปัญหาที่ระดับต่าง ๆ ของสิ่งที่เป็นนามธรรม

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

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

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