W świecie złożonych systemów IT i zwinnego zarządzania projektami, jednym z najczęstszych wyzwań, z jakim spotykam się od 15 lat, jest paraliż decyzyjny wywołany zbyt dużym rozmiarem zadań. Zespoły deweloperskie często stają przed „ścianą” wymagań, które wydają się niemożliwe do zrealizowania w jednej iteracji. Efekt? Zaburzony przepływ (ang. flow), niska przewidywalność i frustracja interesariuszy.
Ponadto, przenoszenie pracy na kolejne iteracje to problemy w planowaniu, estymacji pozostałej pracy, generowania raportów ze sprintu, czy – co najważniejsze – możliwości zademonstrowania postępu i otrzymania potwierdzenia o właściwym kierunku prac.
Kluczem do rozwiązania tego problemu jest umiejętna dekompozycja. W tym artykule przyjrzymy się nie tylko technikom podziału, ale także fundamentalnym różnicom między typami zadań oraz ryzykom, jakie niesie ze sobą niewłaściwe podejście do tego procesu.
Fundamenty: Feature, User Story a Enabler
Zanim przejdziemy do dzielenia, musimy zdefiniować, co właściwie dzielimy. W metodologii SAFe (Scaled Agile Framework) i zaawansowanym Agile, rozróżnienie typów pracy jest krytyczne dla utrzymania równowagi między dostarczaniem wartości biznesowej a dbałością o kondycję techniczną systemu.
Feature (Funkcjonalność)
Feature to funkcjonalność rozwiązania, która dostarcza wymierną wartość biznesową i zaspokaja potrzebę interesariuszy. Jest on zwymiarowany tak, aby mógł zostać dostarczony przez jeden Agile Release Train (ART) w ramach jednego Przyrostu Programu\Interwału Planowania (PI). Każdy feature powinien zawierać hipotezę korzyści (ang. benefit hypothesis) oraz kryteria akceptacji.
Biorąc pod uwagę dodatkową niepewność każdej implementacji, błędem jest planowanie optymistyczne bez zapasu czasu na niespodziewane opóźnienia (które, bądźmy szczerzy, zaskakują nas zawsze jak przysłowiowa zima wprawiająca w zdziwienie służby drogowe).
Jedna dobra rada dotycząca planowania dużych elementów takich jak Feature’y :
Szykuj się na najgorsze, miej nadzieję na najlepsze.
Takie podejście zmniejszy może oryginalne zobowiązanie zespołu, ale zdecydowanie zwiększy jego poziom dostarczania, w przypadku, kiedy „najgorsze” się nie wydarzy, możemy dobrać dodatkową pracę. Warto zauważyć jak mocno zmienia to komunikację:
Planowaliśmy ostrożnie, dostarczyliśmy wszystko i dodatkowo rozpoczęliśmy pracę na kolejny PI” vs. „Prawie dowieźliśmy, ale skończymy za 3 tygodnie.
Rozbijanie pracy na mniejsze elementy powinniśmy już więc zacząć na tym etapie w ramach przygotowania do kolejnego planowania PI.
User Story (Historyjka Użytkownika)
To opis zmiany w zachowaniu systemu z perspektywy użytkownika. User Story jest podstawową jednostką pracy zespołu w iteracji. Dobre User Story musi być „wertykalnym wycinkiem” (ang. vertical slice) – oznacza to, że dotyka wielu warstw architektury (UI, logika, baza danych), aby dostarczyć obserwowalną wartość.
Enabler (Wspomagacz)
Tu często pojawia się konfuzja. Enablery to zadania, które wspierają eksplorację, architekturę lub infrastrukturę. Mogą nie dotykać bezpośrednio użytkownika końcowego, ale są niezbędne do budowania tzw. Pasma Startowego Architektury (ang. Architectural Runway). Enablery torują drogę dla przyszłych funkcjonalności biznesowych.
Przykłady Enablerów to:
- faktoryzacja,
- badania (Spike),
- budowa infrastruktury CI/CD,
- weryfikacja jakości systemu (np. testy wydajności).
Ważne jest, aby w Backlogu utrzymywać zdrowy balans między User Stories (wartość dla klienta) a Enablerami (inwestycja w technologię). Co istotne – Enablery pojawiają się na każdym etapie abstrakcji – od Epików aż do poziomu pojedynczych zadań. Należy pamiętać, że w przeciwieństwie do Features\User Stories, inaczej się je estymuje (często time-boxuje), inaczej definiuje (często większy nacisk na NFR, techniczne wymagania) i inaczej demonstruje (bo trudno pokazać, że nasza zmiana jest niewidoczna i po prostu nic nie popsuliśmy).
Próby opisanie Enablers jak User Story często kończą się dosyć zabawnie:
Jako silnik, nie chcę wybuchnąć po przekroczeniu maksymalnego doładowania.
Tak, właśnie personifikacja elementów systemu jest pierwszym objawem tego, że mamy do czynienia z Enablerem, a nie Feature\User Story.
Zaawansowane techniki dzielenia pracy
Dekompozycja to nie magia, to rzemiosło. Nie ma jednego idealnego sposobu na podział każdego Feature’a , ale istnieje zestaw sprawdzonych wzorców, które pomagają zespołom „zjeść słonia po kawałku”. Poniżej znajdziecie rozwinięcie najważniejszych technik.
Kroki w procesie (ang. Workflow Steps)
Wiele funkcjonalności biznesowych opisuje pewien przepływ pracy. Zamiast budować cały proces od początku do końca w jednej iteracji, możemy go podzielić na poszczególne kroki.
Przykład: Publikacja zdjęcia w social mediach. Proces składa się z: wyboru zdjęcia, edycji, tagowania, dodania lokalizacji, publikacji. Możemy stworzyć osobne User Stories dla samego wyboru i publikacji (MVP), a edycję czy tagowanie dodać jako kolejne historie w następnych iteracjach.
Wariacje reguł biznesowych (ang. Business Rule Variations)
Często złożoność zadania wynika z mnogości reguł biznesowych, które musi obsłużyć system.
Technika: Zidentyfikuj podstawową regułę i stwórz dla niej historię. Pozostałe, bardziej skomplikowane warianty, wydziel do osobnych zadań.
Przykład: System rezerwacji biletów. Pierwsza historia obsługuje standardowy zakup. Kolejne historie dodają obsługę zniżek studenckich, voucherów promocyjnych czy zwrotów.
Proste vs. Złożone (ang. Simple/Complex)
Kiedy podczas planowania dyskusja grzęźnie w przypadkach brzegowych („a co jeśli…”), należy zadać pytanie: „Jaka jest najprostsza wersja tego rozwiązania?”.
Technika: Zdefiniuj wersję podstawową („szkielet”) i zrealizuj ją jako pierwszą. Wszystkie komplikacje i udoskonalenia przenieś do kolejnych historii. Pozwala to na szybkie dostarczenie rdzenia funkcjonalności.
Operacje na danych (ang. CRUD)
Operacje CRUD (Create, Read, Update, Delete) to klasyczny wzorzec podziału. Często historia typu „Zarządzanie kontem” jest zbyt duża.
Podział:
- Story 1: Tworzenie (ang. Create) – użytkownik może założyć konto.
- Story 2: Odczyt (ang. Read) – użytkownik widzi swoje dane.
- Story 3: Aktualizacja/Usuwanie (ang. Update/Delete) – realizowane w późniejszym czasie.
Odroczenie wymagań niefunkcjonalnych (ang. Defer System Qualities/Performance)
Czasami implementacja funkcjonalności jest prosta, ale spełnienie wyśrubowanych norm wydajnościowych (np. czas odpowiedzi <100ms przy milionie rekordów) czyni zadanie ogromnym.
Technika: Podziel pracę na „spraw, by działało” oraz „spraw, by działało szybko/bezpiecznie”.
- Story 1: Implementacja funkcjonalna (nawet jeśli wolna) – pozwala użytkownikowi wykonać akcję.
- Story 2 (Enabler/Feature): Optymalizacja wydajności lub dodanie zaawansowanych zabezpieczeń.
Spike (Badania)
Często zespół estymuje nowe funkcjonalności bardzo wysoko ze względu na brak pewności, wiedzy czy doświadczenia w danej dziedzinie. Najczęściej odpowiedź jest wtedy jedna – nie estymuj, dowiedz się więcej.
Tak samo, gdy historia jest duża nie z powodu złożoności biznesowej, ale przez niewiedzę techniczną – żadna dyskusja biznesowa jej nie podzieli.
Rozwiązanie: Wydziel Spike – ograniczone czasowo zadanie badawcze (ang. time-boxed), którego celem jest zdobycie wiedzy lub stworzenie prototypu (ang. proof of concept). Wynikiem Spike’a jest wiedza, jak zaimplementować lub podzielić właściwą funkcjonalność.
„Pro-tip” – nie czekaj z wykonanie Spike na początek iteracji czy PI – zrób to najwcześniej jak się da, przed dowolnym planowaniem, kiedy tylko niepewność zostanie zidentyfikowana.
Role Użytkownika (ang. User Roles)
To jedna z najbardziej naturalnych metod podziału. To samo oprogramowanie jest wykorzystywane w zupełnie inny sposób przez różne grupy użytkowników.
Technika: Zamiast budować uniwersalną funkcję dla „każdego”, skup się na konkretnej roli.
Przykład: Portal rekrutacyjny.
- Story 1 (Kandydat): Jako kandydat chcę zaaplikować na ofertę (prosty formularz).
- Story 2 (HR Manager): Jako HR Manager chcę przeglądać aplikacje i zmieniać ich statusy. Dzięki temu szybciej dostarczysz wartość dla jednej grupy, nie czekając na ukończenie funkcji dla drugiej.
Persony Użytkownika (ang. User Personas)
Nawet w obrębie tej samej roli użytkownicy różnią się potrzebami i zachowaniem. To subtelniejszy podział niż Role, ale bardzo potężny.
Technika: Podziel funkcjonalność ze względu na poziom zaawansowania lub specyficzne cechy użytkownika.
Przykład:
- Story 1 (Ekspert): Użytkownik, który doskonale zna system, potrzebuje skrótów klawiszowych, aby pracować szybciej.
- Story 2 (Nowicjusz): Nowy użytkownik potrzebuje „samouczków”, dymków z podpowiedziami i kreatorów (ang. wizards), które poprowadzą go za rękę.
- Story 3 (Osoba z niepełnosprawnością): Dostosowanie interfejsu do czytników ekranowych lub specyficznych metod interakcji.
Typy Danych (ang. Data Types)
Rzadko zdarza się, by wszyscy wprowadzali dane w ten sam sposób. Złożoność obsługi różnych formatów potrafi zabić Sprint.
Technika: Zidentyfikuj lokalne lub specyficzne formaty danych i obsłuż je osobno.
Przykład: Aplikacja fitness śledząca dystans.
- Story 1: Obsługa danych w kilometrach (dla rynku europejskiego).
- Story 2: Obsługa danych w milach (dla rynku USA). Zamiast budować skomplikowany mechanizm konwersji i detekcji lokalizacji od razu, zacznij od jednego typu danych, aby uzyskać szybką informację zwrotną.
Platformy i Urządzenia (ang. Devices/Platforms)
Nie możesz zakładać, że wszyscy użytkownicy korzystają z tego samego systemu czy sprzętu. Próba obsłużenia wszystkiego naraz, to prosty przepis na porażkę.
Technika: Podziel User Stories w oparciu o różnice w urządzeniach lub systemach operacyjnych.
Przykład:
- Story 1: Implementacja funkcjonalności na Desktop (Chrome/Firefox).
- Story 2: Dostosowanie widoku do urządzeń mobilnych (RWD).
- Story 3: Obsługa specyficznych gestów na tabletach (iOS/Android).
Możliwości (ang. Capabilities) – Podział przez spójniki
To technika lingwistyczna. Często User Story jest zbyt duże, ponieważ zawiera w sobie spójniki takie jak „i”, „lub”, „oraz”.
Technika: Przeanalizuj treść historii. Jeśli zdanie brzmi „Jako użytkownik chcę wyszukiwać i sortować wyniki”, to masz gotowy podział.
Przykład:
- Story 1: Wyszukiwanie wyników.
- Story 2: Sortowanie wyników (możesz to dalej podzielić na sortowanie po cenie, dacie itd.). Wyjątkiem jest sytuacja, gdy spójnik służy tylko do wyliczenia elementów, a nie łączenia odrębnych logik biznesowych.
Technika SPIDR
Jeśli potrzebujesz prostej ściągi, zapamiętaj akronim SPIDR:
- Spikes (Badania)
- Paths (Ścieżki/Procesy)
- Interface (Interfejs – np. różne wersje lub urządzenia)
- Data (Dane)
- Rules (Reguły biznesowe)
Potencjalne korzyści
- Szybszy feedback: Mniejsze historie pozwalają na częstsze dostarczanie działającego oprogramowania i zbieranie opinii od użytkowników.
- Lepsza estymacja: Zgodnie z prawem wielkich liczb, suma oszacowań mniejszych zadań jest zazwyczaj bardziej precyzyjna niż oszacowanie jednego, wielkiego bloku pracy. Błędy w małych zadaniach mają tendencję do znoszenia się.
- Lepszy flow i morale: Zespół regularnie zamyka zadania („Done”), co buduje poczucie postępu i zapobiega zjawisku „wiecznego sprintu”, gdzie zadania przechodzą z iteracji do iteracji. Zawsze lepiej jest zaraportować, że wykonaliśmy 7/9 zaplanowanych zadań, niż 0/3 – pomimo, że ilość pracy była identyczna, zarówno odbiór pracy, transparentność zaangażowania zespołu i jego morale drastycznie rosną, kiedy operujemy na mniejszych zadaniach.
Ryzyka i zagrożenia
- Utrata kontekstu biznesowego (ang. Over-splitting): Istnieje ryzyko podzielenia historii na tak drobne elementy, że przestają one spełniać kryterium Invest (Valuable). Jeśli historia staje się tylko zadaniem technicznym (np. „Stwórz tabelę w bazie danych”), traci wartość dla użytkownika końcowego i staje się zadaniem (ang. Task), a nie User Story .
- Naruszenie NFR (ang. Non-Functional Requirements): Technika „Defer Performance” jest potężna, ale ryzykowna. Jeśli zbyt długo będziemy odkładać jakość, bezpieczeństwo czy wydajność na później, zbudujemy dług techniczny, który może być trudny do spłacenia.
- Horyzontalne cięcie (ang. Horizontal Slicing): Niedoświadczone zespoły mają tendencję do dzielenia pracy warstwami (osobno frontend, osobno backend) zamiast wertykalnie. To prowadzi do sytuacji, gdzie mamy „ukończone” zadania, ale system jako całość nie oferuje żadnej nowej funkcjonalności dla użytkownika.
Podsumowanie
Celem dekompozycji nie jest samo posiadanie małych zadań, ale częstsze dostarczanie wartości, a co za tym idzie – szybszy „feedback”, lepsza transparentność i satysfakcja zespołu z ukończonej pracy.
Dzielcie mądrze, dbajcie o wertykalność i nie bójcie się używać Enablerów, gdy technologia tego wymaga.
Kluczem do osiągnięcia zmniejszonego rozmiaru zadań jest świadoma ich definicja, skrupulatny proces optymalizacji backlogu, ścisła współpraca z PO i biznesem w celu dostarczania tylko niezbędnych elementów zwiększających naszą wartość biznesową. Na podstawie otrzymanych opinii zawsze możemy dodać dodatkową funkcjonalność, a źle zainwestowanego czasu przez niepotrzebną komplikację nie odzyskamy już nigdy.
Warto zapamiętać:
„Prostota to sztuka maksymalizacji pracy, której się nie wykonuje.”
I nie chodzi tu wcale o lenistwo, lecz o to, aby osiągnąć cel, wykonując jak najmniej zbędnych czynności (np. nie pisząc funkcji, których nikt nie będzie używał, lub nie tworząc dokumentacji, której nikt nie przeczyta). Tylko optymalizacja wielkości zadań pozwoli nam właśnie ten cel osiągnąć.
Powodzenia w dzieleniu zadań!
Zostaw komentarz