Czy istnieje realna alternatywa dla zwinnej metodologii rozwoju?

47

Dwie dominujące metodologie tworzenia oprogramowania to wodospad i zwinność. Omawiając te dwa elementy, często kładzie się duży nacisk na szczególne praktyki, które je odróżniają (programowanie par, TDD itp. Vs. specyfikacja funkcjonalna, duży projekt z góry itp.)

Ale prawdziwe różnice są znacznie głębsze, ponieważ praktyki te wynikają z filozofii.

Waterfall mówi: Zmiana jest kosztowna, dlatego należy ją zminimalizować.
Zwinny mówi: Zmiana jest nieunikniona, więc uczyń ją tanią.

Moje pytanie brzmi: niezależnie od tego, co myślisz o TDD lub specyfikacjach funkcjonalnych, czy metodologia rozwoju wodospadu jest naprawdę wykonalna?

Czy ktoś naprawdę myśli, że minimalizacja zmian w oprogramowaniu jest realną opcją dla tych, którzy chcą dostarczać cenne oprogramowanie? A może pytanie o to, jakie praktyki najlepiej sprawdzają się w naszych sytuacjach, aby poradzić sobie z nieuchronną zmianą?

Eric Wilson
źródło
1
interesujące pytanie. czekam na odpowiedzi.
DevSolo,
3
@FarmBoy - Dobre pytanie. Trochę inaczej patrzę na zwinną filozofię. Napisałbym to tak, jak mówi „Zwinny: zmiana jest nieunikniona, więc ustal jej koszt”. Zmiana może być wciąż bardzo kosztowna, ale w zwinności możesz to szybko i tanio ustalić, abyśmy zawsze znali jej koszt. Sformułowanie tego w inny sposób sprawia, że ​​ludzie myślą, że skoro robią zwinne zmiany, to będzie tanie. Niektóre zmiany kosztują dużo, bez względu na proces.
Mike Two
1
@Yannis Rizos: dlaczego zamykasz to interesujące pytanie sam, bez jednego głosowania w społeczności?
1
@ Pierre303 z powodu tego pytania, które tutaj pojawiła się w dyskusji .
Ryathal

Odpowiedzi:

59

Oczywiście wodospad jest opłacalny. Przywiodło nas na księżyc!

I to tutaj zwinny trener!

O ile nie możesz jednoznacznie zidentyfikować problemów związanych ze sposobem zarządzania projektami, nie ma ważnego powodu do zmiany.

Jako alternatywę metodologii Agile i Waterfall zasugeruję TWOJĄ metodologię . Dostosowany do Twojej konkretnej firmy, Twojego zespołu, Twoich produktów, Twojego sposobu pracy, kultury Twojej firmy ... Dlatego Scrum nazywa się prostym frameworkiem zamiast metodologii.

Chcąc wdrożyć metodologię, ponieważ ktoś na blogu, który lubisz, mówił o tym, jest tak głupi, jak pozwalanie na problemy bez robienia czegokolwiek.


źródło
10
+1 za TWOJĄ metodologię, kolejny trener Agile, który mówi mi, że SCRUM to jedyny sposób, aby dostać bagażnik z tyłu;)
Martijn Verburg
1
@karianna: Robię konkretnie SCRUM, ale czasami jest to po prostu nieodpowiednie. Z drugiej strony widziałem też zespół próbujący sprzedać SCRUM ich szefom, myśląc, że to rozwiąże ich problem. Nie udało im się, ponieważ problemem nie byli ich szefowie ani ich premier. Nie ma jednej reguły. Każdy przypadek jest rozwiązaniem. I tak, większość problemów organizacyjnych można rozwiązać za pomocą technik zwinnych, ale zwinność nie jest srebrną kulą.
5
Nie tylko księżyc. Prom kosmiczny miał w swoich wbudowanych systemach około 1 mln wierszy kodu C. Przez około 30 lat mieli tylko 2 błędy, które trafiły do ​​wersji produkcyjnych.
Dan Neely
2
Wodospad ZABIŁ także pierwszych trzech astronautów. Ten nacisk na używanie tego programu Apollo jako dziecka z plakatu dla Wodospadu jest w najlepszym razie nieświadomy. Wodospad jest również cytowany jako odpowiedzialny za to, że oba programy są kompletnymi bajerami finansowymi, a Shuttle jest nad-inżynierem, kruchym, drogim „kosmicznym ferrari”, gdy oryginalna specyfikacja dotyczyła „kosmicznej ciężarówki”. Jestem prawie pewien, że SpaceX nie zgodzi się z Waterfall.
4
@ Dan Tylko wysoki poziom jakości oprogramowania promu kosmicznego nie był tani. Najwyraźniej cena wynosiła 1000 USD za wiersz kodu.
21

Po pierwsze, nie zgadzam się z twoimi stwierdzeniami:

Waterfall mówi: Zmiana jest kosztowna, dlatego należy ją zminimalizować.
Zwinny mówi: Zmiana jest nieunikniona, więc uczyń ją tanią.

Moja interpretacja to:

Waterfall mówi: Klient wie, czego chce.
Zwinny mówi: klient nie wie, czego chce, więc będziemy musieli stworzyć kilka różnych wersji.

Najlepszym wdrożeniem „wodospadu”, jaki kiedykolwiek widziałem, był ogromny projekt integracji z bardzo dużym klientem finansowym, w który zaangażowanych było ponad 40 podprojektów. Dostarczony przez nas pakiet na komputery i strony internetowe był tylko jednym z ponad 40 podprojektów. Podczas gdy myślałem, że przesadzili z pieniędzmi innych ludzi raczej nadmiernie, zgromadzili swoje rzeczy i trzymali ponad 40 różnych statków poruszających się razem w formacji. Projekt poszedł na żywo w dniu docelowej (cel przeniesione raz w trakcie realizacji projektu) i gdy myślałem, że zrobili go bardziej oszczędnie i agily, ale odbywa się to na czasie i na spec. Harmonogram nocnego startu trwał około 100 stron, a około 40 z tych stron stanowiło dane kontaktowe w razie nagłej paniki wszystkich zaangażowanych osób. Byłem pod wrażeniem tego klienta.

Lub możesz zrobić to, co robimy, czyli biegać i robić to, co jest najnowsze zgłoszenie skargi / błędu, i nazwać to zwinnym.

Tangurena
źródło
8
Zgodnie z Agile Dilbert: is.gd/lDoQgb
Peter K.
11
To bardziej jak „Wodospad mówi: klient nie wie, czego chce, więc
usiądźmy, przedyskutujmy
+1: Bardzo dobra odpowiedź. Myślę, że społeczność zwinna ma jeden podstawowy problem: zwinność jest dobra w pewnych kontekstach dla niektórych klas projektów i klientów, ale nie dostrzegają, że istnieją projekty, w których wymagania nie zmieniają się, dlatego szybsze i bardziej uporządkowane podejście jest lepszym wyborem . Myślę, że zwinna społeczność powinna spróbować realistycznie określić obszary, w których ich podejście jest lepszym wyborem (myślę, że takie obszary istnieją), a nie próbować popchnąć go jako ogólne rozwiązanie, ponieważ tak nie jest.
Giorgio
6
@scrwtp - a Agile przypomina bardziej: „Mój klient nie wie, czego chce, i nie może / nie chce rozmawiać i myśleć o tym, a oni zmieniają zdanie co 5 minut. Muszę coś wcisnąć w twarz uzyskać sensowne odpowiedzi ”. Łał. To brzmi naprawdę niefortunnie, kiedy to zapisuję.
Michael Kohne
1
@scrwtp: Myślę, że pytanie za milion dolarów brzmi: czy to „przekonanie”, że możesz „usiąść i przedyskutować to i się zgodzić” jest realne? Odpowiedź brzmi: to zależy, prawda? To zależy od wielu zmiennych: jak duży jest projekt? Czy WIEMY jak duży jest? Ile czasu klienci mają z nami „usiąść”? Przez dziesięciolecia próbowaliśmy powiązać rozwój oprogramowania z budową, która jest prawie w 100% nakazowa. Rozwój oprogramowania znajduje się gdzieś pośrodku między „całkowicie reakcyjnym” a „w 100% nakazowym”. W większości sklepów jest bliżej „całkowicie reakcyjnej”, stąd adopcja zwinna.
Calphool
21

Zaczynasz od powiedzenia:

Dwie dominujące filozofie tworzenia oprogramowania to wodospad i zwinność.

To nieprawda. Ta dychotomia została skonstruowana przez zwinną społeczność, aby stworzyć przeciwnika, któremu można się zająć. Zanim agile stało się modne, ludzie mówili o niezliczonej liczbie różnych podejść do tworzenia oprogramowania. Wciąż istnieją do dziś, ale jakoś często są skupieni w wielkim bałaganie zwanym zwinnym zwolennikiem.

Używam OPEN / Metis i jego wariantów od ponad 10 lat z wielkim sukcesem. Na pewno nie jest zwinny, a na pewno nie wodospad. Tysiące programistów tworzy niezwykle złożone oprogramowanie dla samolotów, systemów o krytycznym znaczeniu dla życia, bankowości itp., Stosując metody niestabilne każdego dnia.

Tak, oczywiście, istnieje realna alternatywa dla zwinnych.

CesarGon
źródło
6
Nie jestem w stanie szybko zrozumieć, czym jest OPEN / Metis z tego linku. (Zwykle nie trzeba pobierać metodologii.) Moje pytanie brzmi: jaka jest jej filozofia, szczególnie w radzeniu sobie ze zmianami? Czy próbuje zminimalizować zmianę, czy też obniżyć koszty zmiany? Pamiętaj, że moje pytanie dotyczyło zwinnej filozofii, a nie zwinnych praktyk.
Eric Wilson,
OPEN / Metis ma iteracyjny cykl życia, w którym systemy są tworzone stopniowo. Zmiana jest uznawana za coś, co nie tylko się zdarza, ale także coś wspaniałego, gdy się dzieje, ponieważ celem rozwoju systemu informatycznego jest dokonanie pewnych zmian. Koszt zmian jest jednak kontrolowany i zarządzany przez odpowiedni cykl życia i powiązane praktyki.
CesarGon,
1
Jeśli chodzi o twoją uwagę na temat „metodologii pobierania”, cóż ... nie pobierasz metodologii, zgadzam się. Pobierasz dokumenty opisujące metodologie. W przeciwnym razie, jak się o nich dowiesz? Spójrz na miriady książek opisujących XP, Scrum itp.
CesarGon
10

Tak, różne techniki tworzenia oprogramowania są realne w zależności od domeny problemu. To „Konie na kursy”.

Na przykład piszesz oprogramowanie do sterowania elektrownią jądrową lub do sterowania promem kosmicznym NASA. Ten rodzaj problematycznej domeny prawdopodobnie lepiej nadaje się do wodospadu (lub nawet bardziej rygorystycznego) podejścia, jeśli chcesz, możesz rozwiązać wszystkie problemy z góry (lub BOOM!).

Budujesz najnowszy webowy interfejs użytkownika 2.0 / 3.0 / buzzy? Zwinność jest znacznie lepszym sposobem (potrzebujesz szybkiej informacji zwrotnej i zmian).

Istnieją zasady, które nazwałbym zasadami kunsztu oprogramowania, które można nadal stosować bez względu na metodologię:

  • Kontrola źródła
  • kompilacja i CI
  • programowanie par
  • TDD
  • Daję ^% $$ i

i więcej.

Cokolwiek robisz, nie słuchaj fanatyków po obu stronach równania, rób to, co jest odpowiednie dla ciebie, swojego zespołu i dziedziny problemów.

Martijn Verburg
źródło
Wodospad działa, jeśli możesz sobie na to pozwolić. Ktoś powyżej twierdził, że koszt oprogramowania księżycowego NASA wynosił około 1000 USD za wiersz kodu. Większość sklepów potrzebuje około 1–10 USD na linię kodu, a zwinność jest lepsza w takich sytuacjach. Nie udaję jednak, że zwinny zapewnia ogólnie lepszą jakość. Zasadniczo sprowadza się to do tego, że możesz sobie pozwolić na stronę dużo pieniędzy, aby mieć pewność, że oprogramowanie jest poprawne, lub znalezienie rozwiązania jest tańsze, gdy dowiesz się, że oprogramowanie jest nieprawidłowe.
Mikko Rantalainen,
2

Problem wynika ze złożoności oprogramowania. Wodospad świetnie sprawdza się w budowaniu mostów i brukowaniu dróg, ponieważ fizyka po prostu nigdy się nie zmienia. Jasne, w pewnym momencie opracujemy nowy asfalt, ale nie zrewolucjonizuje sposobu budowania dróg. Stal w zawieszeniu mostu ma albo odpowiedni rozmiar, albo nie. Nie można zatkać ani zepsuć prawdziwego projektu budowlanego, tak jak można to zrobić za pomocą oprogramowania.

Zmiany oprogramowania. Oprogramowanie zmienia się szybko. Prawo Moore'a stwierdza, że ​​liczba tranzystorów na chipie podwaja się co 18-24 miesięcy. W wyniku tego liczba wierszy kodu w programie również się podwaja. Złożoność między tymi wierszami kodu wzrasta zatem z bigO czegoś takiego jak 2 ^ (2t).

Oprogramowanie zmienia się szybko, a wraz z nim rośnie wykładniczo.

Kontrolując koszt oprogramowania, chcesz kontrolować czynniki wykładnicze , a nie tylko multiplikatywne lub addytywne. Zmiana kodu zwiększa złożoność (i staje się wykładniczo bardziej złożona w miarę postępu projektu) w sposób wykładniczy.

Zmiana jest nieunikniona. Sama natura programowania rozszerza język o klasy i metody niestandardowe, zmieniając w ten sposób sam język. Nie możesz tego zrobić w żadnej innej dyscyplinie inżynieryjnej (np. Budowaniu dróg. Nie wymyślasz nowej nawierzchni tylko po to, aby utorować drogę w Kansas nad Kalifornią).

Metoda zwinna zapewnia również platformę do obsługi przyszłych wydań i poprawek błędów. Masz już narzędzia do zarządzania, procesy, przeszkolonych pracowników do opracowywania wersji oprogramowania. Dzięki metodzie wodospadu musisz przekwalifikować swój zespół, aby obsługiwał nawet drobne poprawki błędów.

w każdym razie moje 2 centy.

Stephen Furlani
źródło
2
Istnieje wiele aspektów projektowania oprogramowania, które są tak absolutne, jak prawa fizyki. Zwinne to narzędzie podobne do wodospadu lub innych metodologii, a jak napisali inni ludzie, istnieje wiele przypadków biznesowych, w których nie ma to sensu. Byłbym zaskoczony, gdybym zobaczył cię w kolejce do samolotu, w którym Boeing powiedział, że jest w trakcie zwinnego procesu w oprogramowaniu do sterowania lotem i potrzebował klientów, aby sprawdzić, czy samolot nie odwraca się w powietrzu bez powodu powód.
Hounshell,
I tylko po to, by strzelać do kolejnych dziur w twoim argumencie, opracowywane są teraz projekty dróg, które byłyby odpowiednie dla drogi między Kansas i Kalifornią, ale nie między Nowym Jorkiem a Bostonem. I ciągle pojawiają się nowe techniki obchodzenia się z asfaltem.
Hounshell,
2
Na koniec mówisz: „Metodą wodospadu trzeba przekwalifikować swój zespół, aby poradził sobie nawet z drobnymi poprawkami”. To jest tak bardzo nieświadome, jak działa proces wodospadu. Powinieneś wypróbować dobry sklep z wodospadem, zanim zaczniesz zastanawiać się, w jaki sposób jest nieodpowiedni dla każdego scenariusza tworzenia oprogramowania.
Hounshell,
1
Cześć Stephan, nie wszystkie wymagania dotyczące oprogramowania ciągle się zmieniają.
Paul Nathan
1
Biznes zawsze się zmienia ; biznes, który się nie zmienia i nie dostosowuje, to biznes umiera. Czas jest stałą , która nie współdziała dobrze ze zmianą. System, który ma filozofię, która potwierdza, że oczekuje się zmiany, może zaakceptować zmianę, w przeciwnym razie czas będzie musiał zaakceptować zmianę i jest to niezmierzona stała!
2

Aby odpowiedzieć na pytanie, czy istnieje realna alternatywa dla oprogramowania, być może nie - lub jeszcze nie, przynajmniej w ogólnym przypadku. Myślę, że sprowadza się to do natury oprogramowania. Oprogramowanie, będące informacją, można powielać za darmo. W przeciwieństwie do mostu lub domu. Oznacza to, że dzięki praktyce mogę dobrze budować dom i działać w stosunkowo prostej dziedzinie. W którym momencie możesz zastosować podejście jednorazowe?

Ale ponieważ oprogramowanie ma zerowe koszty powielania, dlaczego miałbyś robić to samo dwa razy? Oprogramowanie zwykle odchodzi od produkcji. Jeśli więc całe oprogramowanie tworzy nowy produkt, zawsze działamy w złożonej domenie, w której do pewnego stopnia nie wiemy, co robimy. Lub to jest drogie wiedzieć z góry i taniej jest dowiedzieć się, robiąc. W złożonej, ryzykownej domenie chciałbym spróbować eksperymentów, zwiększania i iteracji.

Elektrownie jądrowe i przelotowe systemy drutowe są często podawane jako przykłady oprogramowania, które chcesz zrobić wodospad. Ale czy system awioniki wahadłowca nie został opracowany iteracyjnie? Jak były kanadyjskie i amerykańskie systemy kontroli ruchu lotniczego?

A jeśli OPEN / Metis jest iteracyjny i przyrostowy, to wydaje mi się, że ma zwinną filozofię, nawet jeśli nie kojarzy się z innymi powszechnymi zwinnymi praktykami.

AlanMJackson
źródło
2
Więc teraz zwinny próbuje przypisać iterację i przyrostowy? Nieważne, że iteracyjne i przyrostowe były CORE częściami rozwoju wodospadu, odkąd zacząłem je rozwijać w 1992 roku.
Dunk
1

Metoda Wodospad z pewnością jest wykonalna i jest równie uzasadniona filozoficznie, jak każde inne podejście. Pamiętaj, że Waterfall istnieje znacznie dłużej niż Agile, ale pamiętaj, że nie jest to argument, aby stwierdzić, czy jedna metodologia jest lepsza od innej.

Stosujesz metodę Waterfall, gdy masz bardzo jasne zrozumienie całej problematycznej dziedziny i tego, co klient chce osiągnąć w pakiecie oprogramowania. Prawdopodobnie podałeś stałą cenę przy zawieraniu umowy, a twój klient rozumie, że nie może odbiegać od jakichkolwiek uzgodnionych wymagań. Twój proces jest ściśle taki, który przepływa przez szereg podpisów między różnymi etapami rozwoju i często zdarza się, że każdy etap jest realizowany przez inny zespół - czasem nawet inną firmę - z których każdy niekoniecznie musi kontakt z innymi. Często widzisz Wodospad stosowany z dobrym skutkiem w projektach wojskowych i rządowych, gdy są one oferowane zewnętrznym wykonawcom. Tam, gdzie Waterfall i inne podobne podejścia zyskują złą reputację, pojawiają się problemy programistów, takie jak słabe oszacowanie, harmonogramy zaplanowane bez nieprzewidzianego czasu lub słabe lub niepełne zrozumienie problematycznej dziedziny. Kwestia ta nigdy nie jest tak naprawdę winą metodologii, ale jej zastosowania.

Porównanie zwinnej i dowolnej metodologii jest fałszywe. Agile nie jest metodologią, jest filozofią, a może lepiej byłoby powiedzieć, że jest to termin ogólny, który reprezentuje inny sposób patrzenia na to, jak się rozwija oprogramowanie. Metodologia jest jedynie narzędziem i jako taka, jej wartość zawsze będzie mniejsza niż jednostki i interakcje, które stanowią sedno tego, co oznacza bycie zwinnym .

Czy ktoś naprawdę myśli, że minimalizacja zmian w oprogramowaniu jest realną opcją dla tych, którzy chcą dostarczać cenne oprogramowanie?

Każda okazja do zminimalizowania zmian jest cenna zarówno dla programisty, jak i klienta. Zmiany mogą spowodować przesunięcie harmonogramu lub pominięcie funkcji w celu spełnienia harmonogramu. W ten sposób zarządzasz efektami zmian, które wpływają na wartość twoich projektów.

A może pytanie o to, jakie praktyki najlepiej sprawdzają się w naszych sytuacjach, aby poradzić sobie z nieuchronną zmianą?

Twoje praktyki mogą pomóc w zarządzaniu zmianami lub mogą całkowicie je zignorować. Liczy się połączenie twoich praktyk programistycznych i zarządzanie relacjami z klientami oraz to, czy te rzeczy działają skutecznie dla wszystkich zaangażowanych stron.

Ci z nas, którzy są do wszystkich celów i sprawnie, rozumieją, że wybierasz metodę, która działa dla Ciebie. Jeśli podoba Ci się określone podejście, zastosuj się do niego. Jeśli to nie pasuje do twoich potrzeb, zmień to. Sposób, w jaki zajmujesz się tworzeniem oprogramowania, sprowadza się do tego, aby jak najlepiej wykorzystać dostępne zasoby i zminimalizować praktyki, które mogą doprowadzić Twój projekt do niepowodzenia, i często okazuje się, że musisz zmienić metodę, aby dopasować konkretny projekt pod ręką.

Naprawdę jedną rzeczą jest powiedzieć „Ok, więc teraz jesteśmy Zwinni”, a zupełnie inną rzeczą jest żyć i pracować zgodnie z filozofią Agile. Bez względu na to, czy używasz Waterfall, Incremental, Spiral, SCRUM, XP, FDD, czy jakiejkolwiek innej metody, jesteś w zasadzie zwinny , gdy cenisz:

  • Osoby i interakcje dotyczące procesów i narzędzi
  • Działające oprogramowanie w obszernej dokumentacji
  • Współpraca z klientami w zakresie negocjacji umów
  • Reagowanie na zmianę po wykonaniu planu

i gdzie łączysz swoje narzędzia, metodę i swoje doświadczenie, aby skutecznie zastosować te wartości.

S.Robins
źródło
2
Łał. Jest tu tyle dziwnych rzeczy. Wodospad jest opłacalny, ponieważ jest w pobliżu dłużej? Wodospad jest uzasadniony na podstawie wykorzystania w umowach obronnych? Czy każda okazja, by zminimalizować zmianę, naprawdę leży w najlepszym interesie klienta, czy też prowadzi do dostarczenia tego, co według niego chciał, a nie tego, czego naprawdę chciał? Ponieważ wydaje ci się, że ci na tym zależy, próbowałem zrozumieć, skąd pochodzisz, ale czegoś mi brakuje.
Eric Wilson,
1
@EricWilson Waterfall istnieje już dłużej i jest z powodzeniem stosowany na długo przed omówieniem filozofii Agile. Jest opłacalny, ponieważ istnieje, a po prawidłowym zastosowaniu działa dla tych, którzy chcą go używać. Nie uzasadniłem jego użycia, a jedynie wskazałem przykład, w którym miałem osobiste doświadczenie, w którym widziałem, jak działa, i tak, widziałem też kilka spektakularnych niepowodzeń. Nie szukasz okazji do zminimalizowania zmian, chcesz okazji do wprowadzenia zmian, ale musisz to zrobić rozsądnie, w przeciwnym razie klient otrzyma mniej, niż chciał, lub opóźniony termin.
S.Robins
0

Tak, wodospad, spirala, iteracyjny i inne hybrydowe modele procesów są realne, ale zmiana jest nieunikniona. Proces to coś więcej niż tylko sposób radzenia sobie ze zmianami, a (twierdzę, że) największym wyznacznikiem jest to, jak dobrze znasz / rozumiesz problem i jak dokładnie możesz zaplanować i przewidzieć.

Stwierdzenie, że „dwie dominujące metodologie opracowywania oprogramowania to wodospad i sprawność” jest obrzydliwe, ponieważ istnieje wiele procesów opracowywania oprogramowania, a wiele firm syntetyzuje własną wersję modelu procesu, często zmieniając się dla danego projektu. Istnieją więcej niż dwa realne podejścia do tworzenia oprogramowania. Chociaż Waterfall i Agile mają tendencję do spadania na przeciwne końce spektrum „zmiany”, uzasadnione jest określenie tych konkurencyjnych metodologii jako:

Waterfall mówi: Zmiana jest kosztowna, dlatego należy ją zminimalizować.

Zwinny mówi: Zmiana jest nieunikniona, więc uczyń ją tanią.

Ale to nie jest cała historia. Biznes musi być w stanie planować i przewidywać, ale oprogramowanie to proces twórczy, a szacunki są często błędne. Pamiętasz dobry - szybki - tani trójkąt? Dodaj czwarty wymiar, proces, a przekonasz się, że zmniejszenie nakładu procesu może również kompresować harmonogram, gdy szacunki okażą się błędne, a projektowi grozi opóźnienie. Oprogramowanie jest procesem zamiennym (zmiennym), a zwinne, iteracyjne, spiralne oferują możliwość dostarczania funkcji przyrostowych w krótszych odstępach czasu.

Modele procesów oparte na wodospadzie i innych wymaganiach mają elementy sterujące do obsługi zmiany, więc niedokładne jest stwierdzenie, że wodospad minimalizuje zmianę, dokładniej jest powiedzieć, że wodospad rozpoznaje zmianę i zarządza nią oraz komunikuje wpływ tej zmiany (ponieważ zmiana powoduje wpływ harmonogramu, gdy mieć wymagania i projekt z góry). Podczas budowania produktu lub konieczności pełnego zdefiniowania wymagań (funkcjonalności) następuje przejście do jednego z modeli hybrydowych.

A gdy szacunki są błędne, często proces (czwarta odnoga żelaznego trójkąta) zostaje poświęcony w celu spełnienia harmonogramu.

ChuckCottrill
źródło
Nie byłam nieszczera. Po pięciu latach rozwoju w różnych firmach zetknąłem się tylko z dwiema, a jedna została nazwana tylko krzywoprzysięstwem. Spirala? Nigdy nie słyszałem o tym.
Eric Wilson
Miałem na myśli, że nie spotkałem ich w prawdziwym świecie. Na interwebach są różne rzeczy, ale nie zamierzam teraz ich ścigać tylko dlatego, że w 2010 roku zadałem pytanie.
Eric Wilson
-1

Dojrzałe podejścia zwinne i wodospadowe są nierozróżnialne. Twoje założenie dotyczące celu podejścia do wodospadu jest błędne. Oba mają na celu wytwarzanie wysokiej jakości oprogramowania. Jeśli nie masz solidnego podejścia do rozwoju dla firmy jako całości, musisz sprawdzić, które podejście zapewni najmniej tarcia do przyjęcia. W końcu krótkie cykle programowania, solidny zespół ds. Kontroli jakości oraz firma, która napędza rozwój, są najważniejsze w produkcji najwyższej jakości oprogramowania.

Charles Lambert
źródło
1
Zastrzegam sobie twój komentarz. Wodospad wymaga utalentowanych ludzi, inaczej upadnie na twarz. Nauka dobrego projektowania jest trudna. Nauka kodowania jest stosunkowo bardzo łatwa. IMO, to główny powód, dla którego większość programistów wydaje się preferować zwinność.
Dunk
4
Mogę powiedzieć to samo o zwinnym. Jr. programiści bez wskazówek mogą szybko i sprawnie zadziałać.
Charles Lambert