Workflow czy subtask? 

Dzisiaj zaglądamy pod maskę Jiry i zastanawiamy się czy wybrać workflow, czy subtask. Przy okazji porozmawiamy sobie o tym, w jaki sposób ułożyć sobie nasz proces zarządzania zadaniami i jakie są dobre praktyki. Gotowi?

Domyślna konfiguracja Jira

Nie da się ukryć, że Jira jest wszechobecna. W prawie każdej dużej firmie znajdziemy odpowiednio dużo licencji, żeby każdy Scrum Team obdzielić nimi kilka razy. Dlatego też dzisiejsze rozważania oparte będą o pewne standardy i praktyki z tego popularnego narzędzia. Ale bez obaw, tematyka jest bardziej uniwersalna.

Na samym początku naszej przygody z dowolnym narzędziem wspierającym zwinną pracę stajemy przed wyborem sposobu obsługi naszych zadań. W większości przypadków przyjmiemy domyślną konfigurację wraz z dobrodziejstwem inwentarza. Pewnie nawet nie będziemy się zastanawiali, jakie są inne możliwości.

Zwykle więc utworzymy sobie spriorytetyzowany backlog, w którym zapiszemy wymagania (a nie zadania do wykonania). A skoro już myślimy o wymaganiach, to pewnie opiszemy je zgodnie z formatem User Story oraz oszacujemy je w Story Points. Na to pozwala nam zasadniczo każda aplikacja – od Excela po CA Agile Central. Bo przecież nasz backlog to nic innego, jak tabela z listą wymagań.

Wybrane prze nas narzędzie do zwykle udostępni nam jeszcze jakiś przepływ pracy, czyli z angielska workflow. Tenże workflow opisywał będzie statusy, w jakich mogą się znajdować poszczególne wymagania. I znów, tradycyjnie otrzymamy trzy możliwości: „To Do, In Progress, Done”. Czasami autorzy oprogramowania zaszaleją i dadzą nam jeszcze możliwość odbioru wymagań i przestawienia ich w status „Accepted”.

I tu dochodzimy do punktu spornego. Szczególnie w przypadku Jiry pojawia się pytanie: zostawić wszystko tak jak jest czy customizować?

Workflow vs. Subtask

Zarówno plusem, jak i minusem Jiry jest jej ogromna konfigurowalność. Jeżeli tylko wymyślimy sobie jakieś fantazyjne przepływy, to zwykle uda nam się je jakoś do tego narzędzia wcisnąć. Podobnie rzecz się ma z typami zadań, dodatkowymi polami, i tak dalej. Niektórzy żartują, że przy odpowiednim nakładzie pracy można zrobić z Jiry nawet system księgowy.

Tylko po co? Trzeba pamiętać, że możliwość dostosowywania narzędzia pod siebie nie oznacza, że absolutnie musimy z niej skorzystać. Po drugie, nasz „rzeczywisty” sposób pracy możemy w każdym narzędziu odwzorować na co najmniej dwa sposoby. W Jirze jednym z nich będą statusy workflow, a drugim – subtaski.

Jeżeli chcemy, żeby nasze wymaganie trafiło z dewelopmentu do testów, code review, a następnie został zrobiony merge, to możemy wyobrazić sobie sekwencję dostępnych statusów „To Do, In Development, In Test, In Code Review, To Merge, To Deploy”. Problemów z tym podejściem jest niestety wiele.

Po pierwsze, im bardziej skomplikowany workflow, tym większa plątanina przejść. Bo czy możemy przestawić zadanie ze statusu „In Code Review” z powrotem na „In Development”? A na „In Test”? A po drugie, nigdy nie zunifikujemy takiego flow dla wszystkich typów zadań, wszystkich zespołów i projektów.

Ale im dalej, tym gorzej. Co w sytuacji, w której dane wymaganie jest jednocześnie testowane i robiony jest code review? W jakim ma być statusie? Do kogo ma być przypisane?

I już w ogóle pomijamy tu fakt, że wymuszanie sekwencji działań „analiza, dewelopment, testy” czyni z naszego Sprintu mini-waterfall. A przecież nie o to chodzi!

Subtaski, czyli podzadania

Jeżeli chcemy być w zgodzie ze Scrum Guidem, to po Planowaniu Sprintu przynajmniej część pracy powinna zostać zdekomponowana na fragmenty mniejsze niż jeden dzień. A to znaczy, że sam workflow nam nie wystarczy do opisu wymagań. Musimy jakoś je rozbić na konkretne czynności do wykonania.

„Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.” – Scrum Guide

Praktycznie każde narzędzie umożliwia nam taką dekompozycję w postaci Tasków, Subtasków bądź Zadań. A te to nic innego jak konkretne czynności do wykonania – „zaktualizować strukturę bazy danych”, „przygotować webservice według specyfikacji”, „przeprowadzić code review”, „napisać scenariusze testowe”, „zmerge’ować kod”, itd.

Pamiętajmy też, że Backlog Sprintu cały czas żyje i w miarę postępów prac napotykać będziemy się na nowe rzeczy do zrobienia. Dla nich od razu tworzymy nowe Subtaski. Nie chcemy o nich zapomnieć, a przy okazji transparentnie pokazujemy ile jeszcze zostało nam roboty.

Dzięki takiemu podejściu mamy tak naprawdę nieograniczoną liczbę „statusów” workflow, bo wystarczy dodać zadanie pod tytułem „Code Review” i przestawić je w status „In Progress”, żeby jasno pokazać, jaki jest stan nadrzędnego wymagania.

Co więcej, każdy Subtask można przypisać do innej osoby, co zwykle bardziej odpowiada rzeczywistości. Jednocześnie możemy też mieć dowolną liczbę tasków w statusie „In Progress” czy „Done”. A to znaczy, że mamy bardziej szczegółowy obraz stanu, w jakim znajduje się realizacja danego wymagania. I owszem, często będzie tak, że jedna jego część jeszcze jest w dewelopmencie, a inna już dawno jest po testach.

Rozdzielczość tego spojrzenia zależy od samoorganizującego się Zespołu Deweloperskiego, który sam decyduje, jak bardzo szczegółowo rozpisuje wymagania na zadania. I owszem, niektórzy poprzestaną na nieśmiertelnym „analiza, dewelopment, testy”. Ale przynajmniej w tym podejściu wszystkie te rzeczy będą mogły toczyć się na raz.

Inni z kolei rozpiszą każde User Story na kilkadziesiąt wymagań i też będzie im z tym dobrze. A na pewno lepiej niż ze skomplikowanym workflow.

Siła prostoty

Im prostsze rozwiązanie, tym ma więcej jego zastosowań. Scyzorykiem odkręcimy śrubkę, pokroimy kiełbasę na grilla, użyjemy go jako widelca oraz przetniemy co tylko chcemy. Zaparzacz do herbaty służy raczej do tylko jednej czynności.

Popularność post-itów w agile’owym środowisku nie bierze się z żadnego sponsoringu, tylko z uniwersalności tego narzędzia. Na żółtej (i nie tylko) karteczce możemy zapisać co tylko chcemy, bez ograniczeń na formatowanie czy długość pola tekstowego. Ba, nie musimy ograniczać się tylko do tekstu, możemy coś narysować.

Podobnie rzecz się ma ze Scrum Boardem, na którym owe karteczki mogą wylądować. Sami sobie tworzymy statusy, podziały, możemy przyczepić zdjęcia członków zespołu, użyć kolorowych magnesów i co tylko. I to bardzo szybko, bez klikania, bez potrzeby logowania się, wyświetlania formularza i edycji treści. Bierzemy długopis, zapisujemy, przyklejamy – działa.

Idealnie by było, gdyby nasze narzędzie elektroniczne było równie łatwe w obsłudze. Bo to przecież ono ma być dla nas, a nie my dla niego. A skomplikowany workflow, ograniczenia w przełączaniu pomiędzy statusami, uprawnienia i dziesiątki pól o skomplikowanym znaczeniu tylko nam to utrudniają.

Wróćmy więc do starego, dobrego „To Do, In Progress, Done”, pozwólmy przełączać zadania z każdego statusu w każdy i zachęćmy zespoły do dekompozycji zadań przez subtaski (czy jakkolwiek się ten poziom nie nazywa w narzędziu, z którego korzystacie).

Możecie się zdziwić, jak kreatywnie można wykorzystać najprostsze rozwiązania.