Nie jest sie zwinnym z agile wodospadem
Wiele organizacji okresla siebie jako zwinne. Kto nie chcialbyz winnym? Jezeli nie jest sie zwinnym, to czy z definicji jest sie ociez alym, powolnym i niemrawym?
Niewiele organizacji opisywa loby siebie w ten sposob; jednak w swiecie tworzenia, ulepszania i utrzymywania oprogramowania Agile oznacza wiecej niz mozliwosc szybkiego i latwego dzialania. Agile oznacza, ze zespol lub organizacja przyjmuje pewne zasady, ktore ksztaltuja zachowania i prowadza do przyswajania okreslonych metod.
Jesli dzialania nie odpowiadaja temu, co sie twierdzi, kierownictwo czesto stoi na drodze zasadom, a praktycy metodom. Metody w organizacjach sa czesto bardzo zakorzenione i wymagaja znacznego nakladu na zmiany. Niektorc organizacje twierdza, ze stosuja mieszane podejscie i przechodza od bardziej klasycznego podejscia do kombinacji Scruma, Kanbanu i Extreme Programmingu. Jest to postrzegane jako bezpieczniejsze i bardziej konserwatywne podejscie, ktore pozwala organizacji na organiczna zmiane. Problem polega jednak na tym, ze ta taktyka rzadko dziala i organizacje szybko sie zagryzaja. Jesli nie wklada sie wystarczajaco duzo czasu i wysilku w zarzadzanie zmiana, prowadzi to szybko do hybrydowych ram, ktore nie sa ani jednym, ani drugim – a te sa tylko w bardzo rzadkich przypadkach zwinne.
Cechy zagryzajacych sie (lub potencjalnie zagryzajacych sie) organizacji
Iteracyjny Waterfall:
Klasyczny iteracyjny Waterfall ma swoje korzenie w modelu spiralnym Barry'ego W. Boehmema. W tej pseudo-wersji iteracyjnego tworzenia krotkie i ograniczone czasowo iteracje sa uzywane dla kazdej z klasycznych faz Waterfall. Po Sprincie wymagania nastepuje Sprint projektowy, potem Sprint programistyczny itd. Zarowno klasyczny model spiralny, jak i pseudo-wersja Agile sa mimo wszystko znacznie lepsze niz klasyczny model Waterfall do generowania informacji zwrotnych i szybszego dostarczania wartosci; jednak organizacje zatrzymuja sie przez to na drodze do Agile i zbieraja tylko czesc owocow.
Ustalanie wymagan z gory:
W tym hybrydowym podejsciu do Agile zespoly lub organizacje zbieraja wszystkie wymagania (czasem zwane funkcjami) na poczatku projektu i ustalaja je przed rozpoczeciem faktycznej pracy. Agile opiera sie na pewnych zalozeniach dotyczacych wymagan. Dwa z glownych zalozen sa takie, ze wymagania zawsze pojawiaja sie na nowo i ze – gdy sa juz znane – z czasem znow znikaja. Ustalanie Product Backlogow z gory stanowi sprzecznosc z tymi dwoma zalozeniami. Ponadto cofa to zespoly i organizacje do czasow, gdy opracowywano rozwiazania, ktore na koncu nie odpowiadaly aktualnym wymaganiom biznesowym. To podejscie istnieje zazwyczaj, gdy wdrazanie Agile odbywa sie stopniowo, zaczynajac od deweloperow, a potem wlaczajac Business Analystow itd. Miedzy grupami, ktore przyswajaja Agile, a tymi, ktore tego nie robia, moze czesto dochodzic do dodatkowych tarci, co czesto jest przypisywane zwinnym metodom i utrudnia dalsze zmiany.
Testowanie po zakonczeniu programowania:
Jedna z niebezpieczniejszych form hybrydowych Agile jest testowanie po zakonczonym programowaniu. Te hybrydowa forme poznalem juz pod nazwa „Programowanie + 1 Sprint". W tym scenariuszu zespol tworzy rozwiazanie (dzialajacy kod dla problemu programowego), demonstruje je klientom, twierdzi, ze jest „done", a NASTEPNIE przekazuje to testerom. Testerzy ZAWSZE cos znajda. Dlatego oprogramowanie jest ponownie zwracane, aby albo bezposrednio nad nim pracowac (co przerywa biezacy Sprint) lub przeniesc calosc do Backlogu, aby pozniej sie tym zajac. Zasady Agile popieraja zakonczenie oprogramowania nadajacego sie do wydania (lub przynajmniej potencjalnie nadajacego sie do wydania) do konca kazdego pojedynczego Sprintu. Nadajace sie do wydania oznacza PRZETESTOWANE. Dwie mniej dramatyczne warianty tego problemu to uzywanie Sprinterow hartowniczych i testowanie na samym koncu projektu. Przynajmniej w tych przypadkach nie twierdzi sie, ze jest sie zwinnym.
Podsumowanie na temat Agile i Waterfall
Sposob, w jaki ludzie pracuja, jest jedynym pewnym wskaznikiem tego, czy organizacja jest zwinna czy nie. Czasem sposob pracy tych osob odzwierciedla przejscie do Agile – jednak zakladam, ze wkrotce tam utkna, jesli ta zmiana nie bedzie przeprowadzona z wielkim zapalem. Jesli zespol lub organizacja chca przyjs Agile, wybiera sie projekt i pozwala sie wszystkim zaangazowanym w ten projekt pracowac z Agile jednoczesnie i przez caly czas trwania przepływu pracy. Jesli oznacza to, ze trzeba coachowac caly projekt lub caly zespol, to tak wlasnie nalezy postapic. Podejscie to mozna dobrze porownac do cebuli krojonej w plastry, przy ktorej przy kazdym cietu osiaga sie kazda pojedyncza warstwe cebuli, zamiast luskowac warstwe po warstwie.
Ostatnia uwaga: Nawet jesli przy tych hybrydowych podejsciach w koncu osiaga sie granice, sa one prawdopodobnie nadal lepsze niz metoda (metody), z ktorych korzystano poprzednio. Nie chodzi tu o oskarzenie ludzi, ktorzy maja problemy z przejsciem na Agile. Ma to byc raczej zacheta dla nich do kontynuowania.
Niniejszy tekst pochodzi z bloga SPamCAST i zostal przez nas przetlumaczony na jezyk polski.
