Mini-waterfall w ramach dwutygodniowego Sprintu to „3 dni analizy, 4 dni dewelopmentu, 3 dni testów”. Niestety, samo przejście na Scrum nie oznacza jeszcze, że zaczniemy pracować w zwinny sposób…
Skąd się bierze mini-waterfall?
Bardzo często podejście zwinne, a Scrum w szczególności, służy jako pretekst do przemycania waterfalla. Najczęściej jest to związane z wielką transformacją agile, przy której założenia zwinnej filozofii (agile mindset) mają mniejszą wagę niż wdrażane metody i narzędzia.
W naszej karierze wielokrotnie widzieliśmy próby wprowadzenia podejścia zwinnego w bardzo ograniczonym zakresie („Ograniczony agile„). Dużo pisaliśmy też o pułapkach związanych z wprowadzaniem samego Scruma („Scrum nie działa!„). Myśl przewodnią tych tekstów, a jednocześnie główny problem mini-waterfalli, zawrzeć można w jednym zdaniu:
„Najgorszym i najczęstszym błędem przy wprowadzaniu jakichkolwiek zmian, jest pozostawienie wszystkiego po staremu.” – #białko
Skoro zawsze najpierw zbieraliśmy wymagania, podpisywaliśmy umowę, robiliśmy analizę, dewelopment, testy i wdrożenie, to dlaczego teraz ma to wyglądać inaczej? Przecież zawsze tak robiliśmy! Ok, mamy „jakiś tam agile” i wiemy tyle, że pracę mamy wykonywać w iteracjach. A skoro tak, to w każdym etapie zrobić analizę, dewelopment i testy jakiegoś fragmentu. Czyli mini-waterfall.
I niestety wielu osobom wydaje się, że tak to właśnie powinno wyglądać.
Mini-waterfall w ramach Sprintu
Sprint to nie jest byle etap! Nie chcemy w ramach poszczególnych iteracji robić tego samego, co do tej pory, tylko w mniejszej skali. To właśnie byłby mini-waterfall. Zamiast tego pracujmy zwinnie! Czyli jak?
Rozpoczynając nasz Sprint, niech programiści już wykonują prace, które są dobrze zdefiniowane (albo te, które i tak muszą zrobić). Prace analityczne to głównie uszczegółowienie rzeczy mniej istotnych, które może odbywać się równolegle z programowaniem. Przecież grube tematy rozpoznaliśmy już na Product Backlog Refinemencie. Kolejną dobrą praktyką jest też pisanie scenariuszy testowych i testów automatycznych zanim powstanie gotowe rozwiązanie.
W świetle powyższego nie ma mowy o mini-watefallu. Nie ma też miejsca na narzekanie, że „na początku Sprintu nie ma pracy dla wszystkich”. Do tego wszystkiego mamy jeszcze prace wykonywane na spadach z poprzednich Sprintów i powoli możemy zapominać o podejściu analiza-dewelopment-testy.
Dysonans może powodować definicja Przyrostu jako „gotowego, potencjalnie wdrażalnego oprogramowania”. Skoro coś ma być „potencjalnie wdrażalne”, to wypadałoby zrobić to od A do Z. Skoro tak, to wracamy do punktu wyjścia – analiza, dewelopment, testy. A jeszcze najlepiej na koniec „dojrzewanie wersji” na UAT-ach.
I znów wracamy tutaj do źródła problemu, czyli totalnego niedopasowania „starego” sposobu pracy do zwinnego podejścia. Zamiast robić gigantyczne zmiany, które musimy dogłębnie przetestować, korzystamy z dobrodziejstw Continuous Integration i Continuous Delivery. To znaczy – w krótkich Sprintach wytwarzajmy technicznie doskonałe drobne zmiany.
Spójrzmy na dwa krańce tego samego spektrum. Z jednej strony, jeżeli mieliśmy dwa lata prac deweloperskich, to musimy dogłębnie sprawdzić i przetestować wytworzone rozwiązanie. Jeżeli jednak wdrażamy pojedynczą zmianę, np. poprawkę prostego błędu, to automatyczne testy regresji plus weryfikacja przypadków brzegowych powinny wystarczyć.
A to właśnie jest w stanie zrobić Zespół Deweloperski w Sprincie.
Jak naprawić mini-waterfall?
Problemy powodujące mini-waterfall nie są trywialne. Tak jak jesteśmy w stanie podać np. „3 sposoby na naprawę Daily Scrum„, tak tutaj już nie ma prostego przepisu. Wszystko bierze się z tego, jak pracujemy z wymaganiami i jak myślimy o wdrożeniach.
Przede wszystkim zadbajmy o to, aby do backlogu trafiały wymagania, a nie zadania. Chcemy mieć możliwość decydowanie o sposobie realizowania rozwiązań w trakcie trwania Sprintu. Oczywiście, niech założenia rozwiązania są już ustalone – to da nam możliwość wystartowania z pracami od pierwszego dnia. Ale nie przesadzajmy ze szczegółami!
Będziemy z tego mieli też dużą oszczędność czasu. Jeżeli mniej istotne ustalenia odsuniemy tak daleko, jak się tylko da (do momentu realizacji), to mamy większą pewność, że się one nie zdezaktualizują.
Zastanówmy się też nad wielkością wymagań i długością Sprintu. Te dwa powiązane ze sobą elementy mogą powodować, że próbujemy mierzyć się ze zbyt dużymi problemami, które „trzeba przeanalizować”. Nie tędy droga, zamiast tego – podzielmy wymagania na mniejsze. Pamiętajmy też, że im dłuższy Sprint, tym łatwiej o mini-waterfall.
A gdy już przejdziemy na robienie „wielu drobnych zmian, w wielu krótkich iteracjach”, to spróbujmy też właściwe zorganizować testy naszych rozwiązań. Jeżeli potrzebujemy długich faz UAT to prawdopodobnie jakość naszego produktu jest niska, albo po prostu wdrażamy się zbyt rzadko.
Na koniec warto też dodać, że niektórzy próbują przemycić mini-waterfall w jeszcze innej postaci. W jednym Sprincie robią analizę, w drugim dewelopment, a w trzecim – testy. Mamy jednak nadzieję, że naszym stałym czytelnikom takie pomysły nie przychodzą w ogóle do głowy. Pominiemy więc to milczeniem.
