Czy istnieje realna alternatywa dla zwinnej metodologii rozwoju?

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ą?

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.

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.

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.

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.

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.

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.

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.

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.

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.