Preanaliza i placki ziemniaczane 

Dzisiejszy tekst o preanalizie i refinemencie zawiera co najmniej dwie analogie i trzy różne koncepcje. Mam jednak nadzieję, że wszystko to składa się na całkiem strawną potrawę, bo preanaliza gości na naszym blogu po raz pierwszy.

Preanaliza kontra refinement

Do tej pory chyba więcej o Product Backlog Refinemencie nagraliśmy, niż napisaliśmy. Poza podlinkowanym w poprzednim zdaniu tekstem mamy jeszcze porównanie tego procesu do podejścia waterfallowego i… tyle. Za to na naszym kanale na YouTube mamy co najmniej trzy godne polecenia filmy: „wszystko o„, ten o tym czemu to proces, a nie wydarzenie oraz jeden który omawia wagę tego wydarzenia.

Nie będę więc się dzisiaj rozpisywał na temat refinementu. Dość nam wiedzieć, że jest to przygotowanie backlogu do Planowania Sprintu. „Grillowanie wymagań”, jak to czasami nazywam. Chociaż akurat dziś to porównanie nie jest specjalnie trafione. Tyle refinement, przejdźmy do preanalizy.

Pod pojęciem „preanaliza” różne osoby rozumieją różne procesy. Przeważnie jednak zdecydowanie nie jest to refinement (czyli przygotowanie do planowania), ale zrobienie jakiegoś kawałka analizy Sprint wcześniej. Zresztą, nie oszukujmy się, zwykle jest to po prostu wykonanie całej analizy wcześniej.

Dlaczego jest to złe? Przede wszystkim robi się nam z tego mini-waterfall, z wszystkimi tego konsekwencjami. Bardzo często taka preanaliza szybko się dezaktualizuje. Ponadto, jeżeli robią ją tylko analitycy, to tym samym odsuwamy deweloperów od zrozumienia potrzeb biznesowych. Ten problem nie występuje, gdy wszyscy razem pracujemy nad wymganiami w jednym Sprincie.

Najgorsze jest jednak niszczenie mozolnie budowanego agile mindsetu. Priorytety się zmieniają, nie zawsze wiemy co będzie najbardziej opłacalne do zrobienia w następnym Sprincie, nie do końca mamy też pewność, że nasza preanaliza „wytrzyma” odpowiednio długo… Po co więc to robić?

Skąd się bierze preanaliza?

Chęć do preanalizy bierze się z przyzwyczajeń. Skoro zawsze analitycy pracowali nad wymaganiami dla deweloperów, to teraz albo próbujemy to zmieścić w ramach jednej iteracji, albo wyciągamy analizę chwilę wcześniej.

Nie muszę chyba dodawać, że to zwykle sugeruje zbyt duże wymagania, które najzwyczajniej w świecie nie mieszczą nam się w Sprintach. Gdyby tylko udało je się podzielić na refinemencie i zajmować się nimi zgodnie z podejściem iteracyjnym…

I tu należy się słowo wyjaśnienia. Jeżeli mamy duży temat, wymagający zanurzenia się w dziesiątkach dokumentów, przeprowadzenia tuzina konsultacji i spędzenia mnóstwa czasu, żeby w ogóle móc spróbować go podzielić na mniejsze. Jednym wyjściem z tej sytuacji jest spike. Drugim – spędzenie odpowiedniej liczby godzin na refinementach i spotkaniach. Czyli taka preanaliza.

Nie mówię więc, że preanaliza jest z gruntu zła. Jest ona elementem refinementu i zdarza się, że faktycznie jest potrzebna. Natomiast kluczowe jest tu sformułowanie „zdarza się”. To wyjątek, a nie reguła. Zastanówmy się czy faktycznie temat jest zbyt duży, nadmiernie skomplikowany albo zupełnie nam nieznany i naprawdę, ale to naprawdę spróbujmy na jego rozpoznanie poświęcić jak najmniej sił i środków.

Nie wywracajmy całej koncepcji refinementu do góry nogami i nie róbmy „analizy Sprint wcześniej”.

Placki ziemniaczane, czyli co?

Usłyszałem ostatnio całkiem zgrabną analogię, która porównywała refinement i rozpoznawanie wymagań do obierania ziemniaków i cebuli. Etap wykonawczy to oczywiście tarcie ziemniaków, krojenie cebuli i smażenie placków ziemniaczanych. W tym przykładzie chodziło głównie o prędkość rzeczonego procesu. Chcemy mieć tyle obranych warzyw, żebyśmy cały czas mogli te placki smażyć. W podejściu Scrumowym wystarczą 2-3 Sprinty do przodu, liczone według velocity.

To znaczy, że nie wcale nie chcemy mieć ogromnego zapasu, bo wszyscy czują, że nasze składniki zaczną się po prostu psuć. Skupmy się na tym, żeby obierać ich tyle, ile faktycznie potrzeba. No, może z lekkim zapasem na wszelki wypadek. Dzięki temu będziemy mogli spokojnie się im przyglądać i nie wrzucimy do pojemnika zepsutego elementu.

Tę analogię można by poszerzać na przykład o krojenie warzyw na kawałki o podobnym rozmiarze i pewnie jeszcze wiele więcej. Natomiast w trakcie nagrywania jednego z naszych jeszcze nieopublikowanych filmów przyszła nam do głowy nieco lepsza metafora. W myśl niej Product Backlog to rzeczy znajdujące się w lodówce. Sprint Backlog to te składniki, które wyjęliśmy na blat i które posłużą nam do przygotowania potraw na najbliższy posiłek.

Czym w tym modelu będzie refinement? To nic innego jak działania typu rozmrażanie mięsa, marynowanie, a czasami nawet wcześniejsze pokrojenie czegoś na kawałki.

Natomiast na pewno refinement to nie jest przygotowanie całej potrawy, zapakowanie jej w plastikowe pojemniki i wstawienie z powrotem do lodówki z naklejką „wystarczy odgrzać”. To jest właśnie ta preanaliza, której chcemy uniknać.