Czy są inne zalety zwinnych praktyk niż praca między sprintami?

Niedawno zainteresowałem się zwinnymi praktykami w tworzeniu oprogramowania i od tego czasu widziałem wiele artykułów wskazujących, że praktyki te pozwalają obniżyć ogólne koszty.

Logika tego zazwyczaj wygląda następująco: jeśli zmienią się twoje wymagania, możesz odzwierciedlić tę zmianę w kolejnym zaległym sprincie, co doprowadzi do obniżenia kosztów, ponieważ zaprojektowanie nowej funkcji i wdrożenie jej jest zbliżone pod względem czasu, więc koszty spadają, zgodnie ze znaną zasadą, że im później trzeba zmienić swoje wymagania, tym droższe będzie spełnienie tego wymagania.

Ale średnie i duże projekty oprogramowania są złożone. Nagła zmiana wymagań nie oznacza, że ​​nie będziesz musiał dotykać innych części systemu, aby spełnić to wymaganie. W wielu przypadkach architektura będzie musiała zostać znacznie zmodyfikowana, co oznacza również, że będziesz musiał ponownie wdrożyć wszystkie funkcje oparte na starszej architekturze. Cała kwestia obniżenia kosztów trochę tutaj odchodzi. Oczywiście, jeśli nowy wymóg wymaga nowej niezależnej części systemu, to nie jest problem, stara architektura po prostu rośnie, nie trzeba jej ponownie przemyślać i reimplementować.

I odwrotnie. Jeśli używasz wodospadu i nagle zdajesz sobie sprawę, że należy wprowadzić nowy wymóg, możesz zmienić projekt. Jeśli wymaga to zmiany istniejącej architektury, przeprojektuj ją. Jeśli tak naprawdę nie zadziera z tym, ale po prostu wprowadza nową część systemu, to idź i wykonaj całą pracę, nie ma problemu.

Biorąc to pod uwagę, wydaje mi się, że jedyną zaletą zwinnego rozwoju jest działająca funkcja kompletnych kompilacji między sprintami, a dla wielu ludzi i podejrzeń nie jest to krytyczne. Ponadto zwinne wydaje się, że powoduje to ogólną wadliwą architekturę oprogramowania, ponieważ funkcje są jakby klepane jedna na drugiej, zwinne zespoły dbają tylko o to, czy funkcja działa, a nie o to, jak działa. Wydaje się, że gdy systemy z czasem stają się coraz bardziej złożone, zwinne praktyki programistyczne faktycznie zwiększają chaos w ogólnej architekturze produktu, co ostatecznie skutkuje wyższymi kosztami, ponieważ wprowadzanie zmian będzie coraz trudniejsze, a wodospad pozwala na doskonalenie architektury zanim cokolwiek wypuścisz.

Czy ktoś może mi wskazać, gdzie popełniam błąd, ponieważ oczywiście wiele osób używa zwinnych w środowiskach produkcyjnych, więc gdzieś się mylę.

Po pierwsze, model „wodospadu” zawsze był słabym człowiekiem, który opisywał, jak NIE prowadzić projektu rozwoju oprogramowania. Sprawdź to.

W każdym razie większość projektów SDLC „wodospadowych” wiąże się z procesem „zarządzania zmianami”, gdy ludzie odkrywają, że założenia zapisane w specyfikacjach nie są już aktualne (i zawsze dzieje się tak w dużych złożonych projektach). Niestety proces zarządzania zmianami jest zbudowany jako środek obsługi wyjątków i jest głupio drogi, co oznacza, że ​​projekt skończy się późno lub będzie niskiej jakości.

Ideą metodologii Agile jest to, że zmiana jest dana - nastąpi. Dlatego należy wykonać standardowe operacje „zarządzania zmianami” zamiast obsługi wyjątków. Nie jest to łatwe, ale ludzie odkryli, że jeśli używasz wielu dobrych praktyk projektowych, możesz to zrobić.

Innym poważnym problemem związanym z projektowaniem od przodu jest to, że (najczęściej) tak dużo czasu spędza się na gromadzeniu wymagań, jak i na projektowaniu, rozwoju i testowaniu. Ponadto, jeśli testowanie jest ostatnią fazą i zostanie wykryty poważny problem, jest bardzo mało prawdopodobne, aby został naprawiony w twoim przedziale czasowym.

Być może jedną z najlepszych cech podejścia zwinnego jest to, że wymaga ciągłej interakcji (to znaczy prawdziwej komunikacji) między zespołem opracowującym rozwiązanie a klientem, który tego potrzebuje. Priorytety są tworzone, aby elementy o najwyższym priorytecie były wykonywane jako pierwsze (a jeśli skończy się czas, wycinane są elementy o niskim priorytecie). Informacje zwrotne przychodzą szybko.

Wracając do kwestii dramatycznych zmian - naprawdę musisz użyć metod łagodzących zmiany. Dobre zasady SOLID OO mogą odegrać dużą rolę w tym, podobnie jak budowanie solidnych zautomatyzowanych pakietów testowych, aby można było przetestować oprogramowanie regresji. Powinieneś robić te rzeczy bez względu na metodologię, ale stają się one naprawdę niezbędne, jeśli próbujesz być zwinny.

Cóż, jest kilka zalet. Po pierwsze, klienci nie czytają dokumentów specyfikacji. Zawsze. Waterfall zakłada, że ​​wszyscy na początku zgodzą się na specyfikację, a kiedy rok później oprogramowanie zostanie dostarczone klientowi odpowiadające specyfikacji, będą zadowoleni. W praktyce klienci odkrywają tylko te rzeczy, których naprawdę potrzebują, naprawdę nie potrzebują i naprawdę muszą być czymś innym, gdy aktywnie bawią się samym oprogramowaniem. Zwinny dostaje działający prototyp w ręce klientów, więc te rozłączenia są natychmiast wychwytywane. Zwinne to nie tylko reagowanie na zmieniające się wymagania. Chodzi również o to, by te zmieniające się wymagania pojawiały się wcześnie, gdy koszt zmiany jest niski, a nie na końcu, gdy koszt zmiany jest wysoki.

Drugą zaletą jest to, że ponieważ Agile ma często dobrze widoczne wyniki, projekty rzadziej wypadają z szyn. Dzięki dużemu projektowi Wodospad zbyt łatwo jest zostać daleko w tyle, nawet nie zdając sobie z tego sprawy. Waterfall produkuje wielomiesięczne marsze śmierci pod koniec projektu. Dzięki Agile, ponieważ dostarczasz klientom co kilka tygodni, wszyscy dokładnie wiedzą, gdzie jest projekt, a poślizgi są szybko łapane (i dostosowywane). Z mojego doświadczenia wynika, że ​​Waterfall produkuje tygodnie lub miesiące po 100 godzin tygodniowo. Zwinność oznacza, że ​​być może będziesz musiał poświęcić kilka 12 godzin na koniec sprintu.

Trzecią zaletą jest to, że projekty zwinne są bardziej motywujące. Bardzo trudno jest ludziom mieć poczucie prowadzenia w ciągu całego projektu. Termin wydaje się bardzo odległy, a ten brak bezpośredniości oznacza, że ​​ludzie mają tendencję do odkładania na później, nadmiernego polerowania wzorów, a poza tym po prostu nie działają zbyt produktywnie. Jest to szczególnie prawdziwe, ponieważ początkowe miesiące spędzane są na rzeczach, których ludzie nie lubią robić, takich jak specjalne dokumenty. Ponieważ Agile zawsze ma bardzo bezpośrednie, konkretne terminy w najbliższej przyszłości, ludzie są bardziej zmotywowani. O wiele trudniej jest zwlekać z konkretnym terminem na ustalony zestaw zadań, które mają się odbyć w przyszłym tygodniu.

W odpowiedzi na cytat z pytania, który jest fundamentalnym błędnym przekonaniem przeciwników zwinnych

„... podczas gdy wodospad pozwala dopracować architekturę przed wydaniem czegokolwiek.” jest błędem, pozwólcie mi to naprawić; „... podczas gdy wodospad pozwala dopracować architekturę , abyś nigdy niczego nie wypuszczał. ”

Implikacja, że ​​Waterfall w jakiś sposób zapewnia architekturę wyższej jakości, jest zasadniczo fałszywa i całkowicie obalona przez empiryczne dowody historyczne.

Gdyby Facebook został zaprojektowany w stylu wodospadu z 500 milionami użytkowników jako twarde i szybkie wymaganie i nie zostałby wydany, dopóki nie zostanie dopracowana architektura do obsługi, która zostanie dopracowana, nikt nigdy nie usłyszałby o tym dzisiaj.

To samo dotyczy YouTube, Twittera i wielu innych firm.

Dostali coś, co klient mógł dotknąć i zareagować na pracę, i wypuścili to tak szybko, jak to możliwe. Otrzymali informację zwrotną, dopracowali ją i wydali ponownie; powtarzać. W tych trzech przykładach odpowiadają tylko funkcjami, które klienci akceptują i chcą, i marnują tak mało czasu, jak to możliwe, na rzeczy, które klienci uważają za mało lub bez wartości.

Każdy, kto ma znaczące lata doświadczenia w tworzeniu oprogramowania, zgodzi się, że nie ma czegoś takiego jak doskonała architektura. Tylko jeden, który zaczyna się dalej od entropii i dużej kuli błota niż inne alternatywy. Zwinny to potwierdza i bierze to pod uwagę. Wbudowanie w proces, takie jak zadłużenie techniczne, szybka zmiana priorytetów i refaktoryzacja.

Scrum sam w sobie nie określa żadnych praktyk technicznych, ponieważ jest to ogólne ramy.

Zwinne tworzenie oprogramowania wymaga od zespołu doskonałości technicznej. Wynika to z następujących praktyk technicznych z XP (programowanie ekstremalne). Na przykład, musisz nauczyć się o refaktoryzacji, tdd, całym zespole, programowaniu par, projektowaniu przyrostowym, ci, współpracy itp.

Takie postępowanie pozwala szybko i bezpiecznie radzić sobie ze zmianami, co jest również głównym powodem stosowania zwinnego programowania.

Jedyną miarą zwinności, która ma znaczenie, jest to, że regularnie (co tydzień, co dwa tygodnie) wydajesz klientowi wartościowe, działające oprogramowanie. Możesz to zrobić? Jesteś zwinny w mojej książce.

Dla mnie główną zaletą zwinności jest zmniejszenie ryzyka w projekcie.

Dostarczając iteracyjnie i otrzymując wiele opinii od bazy użytkowników, zwiększasz szansę, że dostarczysz coś, czego naprawdę chcą, i zrobisz to, pragmatycznie dostarczając im najważniejsze funkcje tak wcześnie, jak to możliwe. Teoretycznie będzie to możliwe dzięki lepszym oszacowaniom i planowaniu. Jest to oczywiście bardzo atrakcyjne z punktu widzenia biznesu - znacznie więcej niż tylko wersja, którą można wydać.

Można argumentować, że ta ciągła zmiana zagraża systemowi i obniża jakość, ale powiedziałbym dwie rzeczy. 1) Ta zmiana i tak dzieje się w bardziej tradycyjnych projektach dostarczania oprogramowania - jest po prostu nieuwzględniona i pojawia się później w projekcie, kiedy to, jak wskazałeś, trudniej i drożej jest zmienić. 2) Agile ma wiele do powiedzenia na temat radzenia sobie z tą zmianą, jeśli chodzi o korzystanie z doświadczonych zmotywowanych osób i praktyk, takich jak TDD, parowanie i recenzje kodu. Bez zmiany nastawienia na jakość i ciągłe doskonalenie, akceptuję tę częstą zmianę, która pociąga za sobą sprawność, może powodować problemy.

W wielu przypadkach architektura będzie musiała zostać znacznie zmodyfikowana, co oznacza również, że będziesz musiał ponownie wdrożyć wszystkie funkcje oparte na starszej architekturze.

Jeśli twoja architektura wymaga znacznej modyfikacji w wyniku zmiany wymagań, masz złą architekturę lub złe wymagania. Dobra architektura pozwala odroczyć jak najwięcej decyzji i oddzielić elementy systemu. Dobre wymagania (użytkownika) nie są takie jak „użyj innej bazy danych”.

Więc działajmy przy założeniu, że mamy dobrą działającą architekturę. Jeśli tak jest, wówczas zwinne metodyki rozwoju tracą to „mycie” dzięki metodologiom projektowania z dużym wyprzedzeniem. W końcu podstawową cechą metodologii zwinnego programowania są praktyki takie jak TDD, które promują luźne sprzężenie w kodzie, umożliwiając kontynuowanie projektu z dużą prędkością, niezależnie od tego, czy jest na początku, czy bardzo dojrzały.

W wielu przypadkach architektura będzie musiała zostać znacznie zmodyfikowana, co oznacza również, że będziesz musiał ponownie wdrożyć wszystkie funkcje oparte na starszej architekturze. Cała kwestia obniżenia kosztów trochę tutaj odchodzi.

Po zwinnym procesie istnieje większa szansa na złapanie tego wymagania przed opracowaniem zbyt dużej ilości oprogramowania (i należy je zmienić). Kiedy spędzasz kilka miesięcy, nie pracując z klientem i nie dając mu czegoś do obejrzenia, te główne problemy architektoniczne wychwytujesz dopiero wtedy, gdy „pomyślisz”, że jesteś gotowy do dostarczenia.

Wolę raczej wdrożyć te zmiany w działającej aplikacji, która ma zasięg testowy, niż ogromną kupę kodu, który nawet się nie kompiluje. Będąc szefem pomocy technicznej, otrzymałem płytę CD z aplikacją, która była w fazie rozwoju i nawet się nie zainstalowała. Mogliśmy znaleźć ten problem w pierwszym tygodniu, ale zamiast tego nadszedł czas, aby zamówić kolację, ponieważ była to długa noc.