Czy Agile jest odmianą RAD?

Wikipedia mówi, że Agile jest rodzajem „RAD”, które, jak sądzę, jest nieprawidłowe. Z tego, co wiem, Agile został opracowany, ponieważ sam RAD nie był tak skuteczny w latach 90-tych (zbyt sztywny dla zmian). A może się mylę?

(Uwaga: najwyraźniej artykuł Wikipedii na temat rozwoju oprogramowania Agile został ulepszony pomiędzy nimi, po prostu wymienia RAD jako poprzednika Agile, a nie superset).

Odsyłacz z książki Radical Project Management (Thomsett)

„..nowa moda na rozwój, taka jak RAD, Agile, Object object ...”

Audytor certyfikowanego systemu informacyjnego CISA:

.. widzę dwa alternatywne oprogramowanie. metody: zwinne i szybkie tworzenie aplikacji

Zwinne zarządzanie oprogramowaniem:

Metody zwinne wywodzą się głównie z lekkiego podejścia do RAD.

Sprawdzone metody szacowania oprogramowania:

Główne metody sw. dev. można streścić w następujący sposób:
1. Wodospad ..
4. RAD
5. Zwinny

Pytanie to brzmi:
czy zwinne podejście RAD lub autonomiczne podejście programistyczne?

RAD jako termin poprzedza Agile jako termin o około dziesięć lat, ale tak naprawdę nie jest on „rodzicem” Agile. Oba powstały jako reakcje na dostrzeżone wady tradycyjnych technik zarządzania programowaniem. Jednak RAD jest zalecaną metodą pisania oprogramowania, wykorzystującą kolejne prototypy w celu uzyskania wymagań i udoskonalenia aplikacji. Agile, w pierwotnie wprowadzonej formie, jest filozoficznym stanowiskiem opisującym różnicę między tradycyjnym podejściem a wartościami, na które koncentrują się zwinni praktycy.

Zatem nie, zwinne tworzenie oprogramowania nie jest rodzajem RAD; rozwiązują problemy na różnych poziomach abstrakcji.

Nie sądzę, aby kategoryzowanie metodologii programowania w hierarchiach było poprawne. Zatem żadna metodologia nie jest „pod” ani „nad” żadną inną. O wiele bardziej logiczne jest myślenie o wspólnych punktach metodologii. Dość często zastosowanie metodologii w świecie rzeczywistym obejmuje połączenie wielu podobnych metod i od menedżerów zależy wypracowanie działającego modelu rozwoju.

W przypadku RAD (z którymi nie mam doświadczenia) vs. Agile wydaje się, że jedynie pospolitość to rozwój iteracyjny. RAD wydaje się preferować sztywne fazy z określonymi celami i wynikami. Zwinność polega bardziej na pojedynczej fazie rozwoju, w której wszystko się dzieje. Również Agile rozwija oprogramowanie bezpośrednio z możliwością wcześniejszego usunięcia funkcji zamiast prototypowania. (co może skończyć się tym, co zwinne, ponieważ dość często prototypy są natychmiast integrowane z działającym oprogramowaniem, zamiast robić to ponownie poprawnie)

Metodologia zwinna ma bardziej brzytwa, ponieważ jest zorientowana na budowanie aplikacji w modelu iteracyjnym z szybką iteracyjną demonstracją dla interesariuszy. Nie zwalnia to deweloperów od zachowania paradygmatów projektowych (szczególnie modułowości), ale nie podkreśla tego bezpośrednio, koncentrując się na ciągłym dostarczaniu iteracji i szybkiej reakcji na szybką zmianę wymagań biznesowych. Jest on de facto zorientowany na rozwój izolowanego produktu i działa w ramach produktu, ale nie wymaga wyraźnego ponownego wykorzystywania komponentów rozwiązań, a ponadto - do budowy dowolnej wspólnej platformy dla rodziny produktów na poziomie firmy. Żaden kierownik techniczny nie będzie opowiadał się za powtórzeniem tej samej pracy N razy. Na szczęście RAD rozdziela programowanie według domen, modułów i ich integracji oraz z technicznego punktu widzenia, ma większe zastosowanie do technicznej organizacji modelu rozwoju, co jest uzasadnione z punktu widzenia technicznego zarządzania firmą. To sprawia, że ​​model jest bardziej elastyczny i nadaje się do wielokrotnego użytku i można go dostosować do innych produktów. Wreszcie - firma nie jest wspólnotą freelancerów i ma dłuższe życie niż życie jednego produktu. Jeśli jednak firma produkuje pojedynczy produkt bez migracji i modyfikacji, rola RAD nie jest tak ekspresyjna. Ale zwykle mocne strony Agile są doskonale połączone z mocnymi stronami technicznymi RAD. Wreszcie - firma nie jest wspólnotą freelancerów i ma dłuższe życie niż życie jednego produktu. Jeśli jednak firma produkuje pojedynczy produkt bez migracji i modyfikacji, rola RAD nie jest tak ekspresyjna. Ale zwykle mocne strony Agile są doskonale połączone z mocnymi stronami technicznymi RAD. Wreszcie - firma nie jest wspólnotą freelancerów i ma dłuższe życie niż życie jednego produktu. Jeśli jednak firma produkuje pojedynczy produkt bez migracji i modyfikacji, rola RAD nie jest tak ekspresyjna. Ale zwykle mocne strony Agile są doskonale połączone z mocnymi stronami technicznymi RAD.