blog.testowka.pl

Agile? – tak znam – to taki iteracyjny waterfall.

opublikowany przez 12, Gru, 2011, w kategoriach Agile, Scrum

Zwinne podejście często oznacza zmiany sposobu myślenia, co okazuje się być niezmiernie trudne zwłaszcza w organizacjach, które od dłuższego czasu stosowały znacznie „cięższe” metodyki oparte na zarządzaniu i kontroli. Przyzwyczajenie chociażby do tego, że niektóre etapy wytwarzania oprogramowania następują w ściśle określonej kolejności jeden po drugim często jest przekładane na implementację Agile.

Częstym pomysłem na wdrożenie Agile jest rozbicie iteracji na poszczególne etapy: najpierw mamy kilka pierwszych dni na analizę, pisanie dokumentacji, planowanie i projektowanie, następnie kilka do kilkunastu dni na kodowanie i pod koniec jak starczy czasu tak zwany code freeze lub feature freeze oznaczający nie dodawanie w tym czasie nowych funkcjonalności kosztem skupiania się na testowaniu. W praktyce okazuje się, że jest to nierealne i niestety czasu na testy już nie ma albo jest mocno ograniczony.

Niejako rozwinięciem powyższego pomysłu jest tworzenie specjalistycznych iteracji poświęconych konkretnym etapom wytwarzania oprogramowania. Tak mamy po sobie kolejno: iteracje analizy, planowania i projektowania, kilka iteracji kodowania i jak starczy czasu to iteracje w całości poświęcone integracji, testowaniu i wdrażaniu. Oczywiście możemy wtedy stworzyć specjalistyczne zespoły zajmujące się każdy tylko jednym etapem. Niektórzy próbują nawet układać harmonogramy takich iteracji tak, by żaden zespół się nigdy nie nudził i żeby nie było przestojów produkcyjnych (pomocne bywają wykresy Gant’a) .

Powyższe pomysły z Agile nie mają zbyt wiele wspólnego o ile w ogóle coś mają. Na pierwszy rzut oka widać, że wygląda to jak Waterfall lub Mini-Waterfall w postaci inkrementalnej. Kiedyś spotkałem się nawet z określeniem „Wagile” będącym kombinacją słów Waterfall i Agile.

W Agile każda iteracja musi dostarczać działające, przetestowane i zintegrowane oprogramowanie wnoszące jakąś wartość biznesową. Spełnienie tego warunku nie jest proste – wiąże się z tym wdrożenie odpowiedniej organizacji pracy i zbudowanie silnie współpracującego ze sobą zespołu, co w efekcie daje jeszcze większe korzyści.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.


2 Comments for this entry

  • Krystian

    Spotkałem się też z taką kombinacją, że Team zrobił 4 ‚Sprinty 0’ nie dostarczjąc niczego oprócz dokumentacji wymagań w myśl zasady, że Sprint 0 może być użyty do setupu i podstawowego designu/architektury. Niestety Sprint 0 jest tylko jeden, potem jest kolejna numeracja i jak kazdy Sprint musi coś dostarczyć.

  • Krystian

    Jeszcze moge dodać, ze podstawowym błędem jaki tutaj występuje i z jakim Coach musi sobie poradzić, to założenie, że trzeba stare nawyki wpasować w nowe otoczenie, zamiast wypracować nowe nawyki.

Skomentuj