Agile có phải là biến thể của RAD không?

Wikipedia nói rằng Agile là một loại "RAD" mà tôi đoán là không chính xác. Từ những gì tôi biết, Agile đã được phát triển bởi vì RAD không phải là thành công trong 90'S (quá cứng nhắc cho những thay đổi). Hoặc là tôi sai?

(Lưu ý: rõ ràng bài viết Wikipedia về phát triển phần mềm Agile đã được cải thiện ở giữa, nó chỉ liệt kê RAD là tiền thân của Agile, chứ không phải là một superset).

Một tài liệu tham khảo từ một cuốn sách Quản lý dự án cấp tiến (Thomsett)

".. những mốt phát triển mới như RAD, Agile, Object hướng ..."

Kiểm toán viên hệ thống thông tin được chứng nhận CISA:

.. biết về hai phần mềm thay thế dev. phương pháp: Phát triển ứng dụng nhanh và nhanh

Quản lý Agile cho Phần mềm:

Các phương pháp Agile hầu hết có nguồn gốc từ cách tiếp cận nhẹ của RAD.

Dự toán phần mềm thực hành tốt nhất:

Các phương pháp chính của sw. nhà phát triển có thể tóm tắt như sau:
1. Thác nước ..
4. RAD
5. Nhanh nhẹn

Điểm của câu hỏi này là:
Kiểu Agile của RAD hay phương pháp phát triển độc lập?

RAD như một thuật ngữ có trước Agile như một thuật ngữ khoảng mười năm, nhưng nó không thực sự là "cha mẹ" của Agile. Cả hai đều được tạo ra như là phản ứng đối với những thiếu sót nhận thức với các kỹ thuật quản lý phát triển phần mềm truyền thống. Tuy nhiên, RAD là một phương pháp quy định để viết phần mềm, sử dụng các nguyên mẫu liên tiếp để gợi ra các yêu cầu và tinh chỉnh ứng dụng. Agile, ở dạng được giới thiệu ban đầu, là một vị trí triết học mô tả sự khác biệt giữa các phương pháp truyền thống và các giá trị tập trung vào các học viên nhanh nhẹn.

Vì vậy, không, phát triển phần mềm nhanh không phải là một loại RAD; họ giải quyết các vấn đề ở các mức độ trừu tượng khác nhau.

Tôi không nghĩ rằng việc phân loại các phương pháp phát triển trong các nghiên cứu là chính xác. Vì vậy, không có phương pháp nào là "dưới" hoặc "trên" bất kỳ phương pháp nào khác. Sẽ hợp lý hơn nhiều khi nghĩ về những điểm chung của phương pháp luận. Rất thường xuyên, ứng dụng phương pháp trong thế giới thực bao gồm sự kết hợp của nhiều phương pháp tương tự và tùy thuộc vào các nhà quản lý để đưa ra mô hình phát triển làm việc.

Trong trường hợp RAD (mà tôi không có kinh nghiệm) so với Agile, dường như chỉ có điểm chung là phát triển lặp. RAD dường như thích các pha cứng nhắc với các mục tiêu và đầu ra cụ thể. Agile là nhiều hơn về giai đoạn phát triển duy nhất, nơi mọi thứ xảy ra. Agile cũng phát triển phần mềm trực tiếp với khả năng loại bỏ các tính năng thay vì tạo mẫu trước. (có thể kết thúc giống như nhanh nhẹn, vì khá thường các nguyên mẫu được tích hợp ngay lập tức vào phần mềm hoạt động, thay vì thực hiện lại một lần nữa)

Phương pháp Agile có nhiều chế độ dao cạo hơn vì được định hướng xây dựng ứng dụng trong mô hình lặp với trình diễn lặp nhanh cho các bên liên quan. Nó không miễn cho các nhà phát triển giữ các mô hình thiết kế (đặc biệt là mô-đun), nhưng không nhấn mạnh trực tiếp vào nó, trong khi tập trung vào việc cung cấp liên tục các lần lặp và phản ứng nhanh về thay đổi nhanh chóng các yêu cầu kinh doanh. Nó được định hướng để phát triển một sản phẩm biệt lập và hoạt động trong các khung của sản phẩm. Nhưng nó không yêu cầu sử dụng lại các thành phần của các giải pháp và hơn nữa, - để xây dựng bất kỳ nền tảng chung nào cho gia đình sản phẩm ở cấp độ công ty. Không một người quản lý kỹ thuật nào được đề xuất lặp lại cùng một công việc N lần. May mắn thay, RAD tách biệt sự phát triển theo các miền, mô-đun và sự tích hợp của chúng và theo quan điểm kỹ thuật, được áp dụng nhiều hơn cho tổ chức kỹ thuật của mô hình phát triển, hợp lý theo quan điểm quản lý kỹ thuật của một công ty. Điều này làm cho mô hình trở nên linh hoạt hơn và có thể tái sử dụng và giải pháp cho các sản phẩm khác. Cuối cùng, một công ty không phải là một cộng đồng của những người làm việc tự do và có cuộc sống kéo dài hơn so với cuộc sống của một sản phẩm. Tuy nhiên, nếu một công ty sản xuất một sản phẩm duy nhất mà không có bất kỳ sự di chuyển và sửa đổi nào, thì vai trò của RAD không quá rõ ràng. Nhưng thông thường, các thế mạnh kinh doanh của Agile được kết hợp xuất sắc với các thế mạnh tổ chức kỹ thuật của RAD. Cuối cùng, một công ty không phải là một cộng đồng của những người làm việc tự do và có cuộc sống kéo dài hơn so với cuộc sống của một sản phẩm. Tuy nhiên, nếu một công ty sản xuất một sản phẩm duy nhất mà không có bất kỳ sự di chuyển và sửa đổi nào, thì vai trò của RAD không quá rõ ràng. Nhưng thông thường, các thế mạnh kinh doanh của Agile được kết hợp xuất sắc với các thế mạnh tổ chức kỹ thuật của RAD. Cuối cùng, một công ty không phải là một cộng đồng của những người làm việc tự do và có cuộc sống kéo dài hơn so với cuộc sống của một sản phẩm. Tuy nhiên, nếu một công ty sản xuất một sản phẩm duy nhất mà không có bất kỳ sự di chuyển và sửa đổi nào, thì vai trò của RAD không quá rõ ràng. Nhưng thông thường, các thế mạnh kinh doanh của Agile được kết hợp xuất sắc với các thế mạnh tổ chức kỹ thuật của RAD.