Iteracyjny wodospad to nie jest zwinność
W ciągu ostatnich dwóch lat zauważyłem niepokojący trend — w zespołach z różnych części świata.
Jest to tendencja do tworzenia iteracyjnego procesu kaskadowego i nazywania go „zwinnym".
Iteracyjny wodospad
W Sprincie ktoś (być może Business Analyst razem z Product Ownerem) próbuje ustalić, co ma zostać zbudowane.
Ponieważ chce się być zwinnym, pracuje się z User Stories. Ale zamiast traktować User Stories jako placeholdery dla późniejszych rozmów, każda User Story staje się małym dokumentem specyfikacji o trzech do pięciu stronach treści — a widziałem i dłuższe.
Te mini-specyfikacje/User Stories dokumentują prawie wszystko, co przyjdzie do głowy.
Ponieważ cały Sprint potrzebny jest, żeby to wszystko ustalić i udokumentować, drugi Sprint poświęcony jest projektowaniu interfejsu użytkownika danej User Story. Czasami zespół stara się być nieco bardziej zwinny (przynajmniej w myślach) i rozpoczyna pracę projektową chwilę przed ukończeniem mini-specyfikacji dla danej User Story.
Wielu członków zespołu uważa to za ryzykowne, bo specyfikacje nie są jeszcze kompletne. Ale co tam, w tym momencie wkracza właśnie zwinność.
Programiści otrzymują wtedy do ręki dwa dokumenty. Jeden wyraźnie pokazuje, jak User Story ma wyglądać na końcu, a drugi dostarcza wszystkich istotnych szczegółów dotyczących zachowania Story.
Można zacząć programować dopiero, gdy oba artefakty są gotowe. W niektórych firmach to sami programiści wymuszają ten sposób pracy. Mają podejście, że zbudują wszystko, czego chce się — ale należy im dokładnie powiedzieć na początku Sprinta, czego się potrzebuje.
Niektóre organizacje idą nawet o krok dalej i każą testerom pracować iterację za programistami. Dzieje się tak najwyraźniej dlatego, że User Stories w zespole stają się coraz większe, gdy każda Story musi mieć mini-specyfikację i kompletny projekt UI, zanim można napisać kod.
Na szczęście większość zespołów rozumie, że programiści i testerzy muszą współpracować w tej samej iteracji, jednak nie rozszerzają tej teorii na cały współpracujący zespół.
Prowadzi to do następującego procesu
Pierwsza iteracja poświęcona jest analizie. Druga iteracja (która ewentualnie lekko nakłada się na pierwszą) poświęcona jest projektowaniu User Experience, a trzecia iteracja przeznaczona jest na kodowanie i testowanie. To nie jest zwinność. Może być pierwszym krokiem organizacji w stronę bycia zwinną. Ale to nie jest zwinność.
To jest iteracyjny wodospad.
W tradycyjnym rozwoju kaskadowym zespół wykonuje całą analizę dla całego projektu na samym początku. Następnie zajmuje się całym projektem dla projektu. Potem piszany jest kod dla całego projektu. Następnie przeprowadzane są wszystkie testy dla projektu.
W opisanym powyżej iteracyjnym procesie kaskadowym zespół robi zasadniczo to samo, tyle że każda Story traktowana jest jak własny mały projekt. Najpierw kończy się całą analizę dla Story, następnie projekt tej Story, potem piszany jest cały kod i wszystko jest testowane. To jest iteracyjny proces kaskadowy, nie zwinny proces.
W zwinnym procesie idealnie wszystkie prace byłyby ukończone dokładnie w tym samym momencie. Zespół kończyłby więc analizę problemu i projektowanie rozwiązania w tym samym czasie, co pisanie kodu i testowanie tego rozwiązania. Wszystkie cztery dyscypliny (i inne, których nie uwzględniłem w tym przykładzie) byłyby zakończone dokładnie w tym samym czasie.
Naiwne jest myślenie, że można to osiągnąć w 100%. (Czasem się udaje.) Może jednak być celem, do którego zespół dąży.
Zespół powinien zawsze starać się wykonywać jak najwięcej pracy jednocześnie. Wszystkie rozważania prowadzone z góry (analiza, projekt itp.) powinny być prowadzone jak najpóźniej, nie być zbyt szczegółowe i jednocześnie umożliwiać ukończenie pracy podczas iteracji.
Jeśli traktujesz swoje User Stories jak małe dokumenty specyfikacji, przestań to robić. Zamiast tego zacznij traktować każdą Story jako placeholder dla rozmowy. Możesz opatrzyć Stories kilkoma notatkami o rzeczach, których nie chcesz zapomnieć na kolejnym spotkaniu. Ale te notatki powinny być opcjonalne, a nie koniecznym krokiem w sekwencyjnym procesie. To zachowuje zwinność i zapobiega przekształceniu się procesu w wodospad.
Tekst pochodzi z bloga Mike'a Cohna i został przez nas przetłumaczony.
Zarządzanie interesariuszami
=> Poznaj najważniejsze wskazówki i triki Romana Pichlera dotyczące zarządzania interesariuszami
Definition of Done: proste, a jednak złożone
=> Dowiedz się, jak Definition of Done pomaga w pracy zwinnej.
Jak przebiega Sprint Review?
=> Tutaj znajdziesz przykładową agendę dla Sprint Review
