Nie da się podzielić? Dzielenie wymagań w Scrum

Gdy „nie da” się podzielić

Jeśli pracujesz z zespołem wytwórczym, to na pewno słyszałeś takie zdanie. Czasem występuje w kilku formatach: „tego nie ma sensu dzielić”, „to zajmie zbyt dużo czasu, jak to podzielimy”, „tak będzie prościej”.

W szerokim spektrum problemów, z jakimi mierzą się zespoły, z pewnością są takie, w których te zdania są jak najbardziej prawdziwe. W wielu jednak nie. O tych przypadkach jest ten post.

Kilka lat temu mój bliski kolega przedstawił mi drobny słowny (choć nie do końca tylko słowny) trik. Zamiast „nie da się”, zaproponuj „nie umiemy tego jeszcze”. Drobna rzecz, prawda? Tworzy jednak zupełnie inne warunki do działania!

TL;DR

Podział zadań usprawnia pracę zespołu: szybciej dostarczacie wartość i zbieracie feedback, zmniejszacie ryzyko techniczne i lepiej organizujecie pracę.
Zamiast „nie da się” spróbujcie „nie umiemy jeszcze”.
Na start: wizualizacja, potem jedna z ośmiu technik podziału, przećwiczona na czymś, co już skończyliście.

Planowanie roboty

Planowanie pracy, dzielenie jej na mniejsze części, prowadzenie i zarządzanie pracą oraz jej monitorowanie, by potem ocenić, zgarnąć i przetworzyć feedback - to są skille. To umiejętności, których trzeba się nauczyć. Niby proste, ale życie pokazuje, że tak nie jest. Jak coś prosto wygląda, to pod spodem są ukryte nieraz miesiące czy lata praktyki, prawda? Co gorsza, to, że umiesz sam, nie znaczy, że umiesz z innymi... W piłkę umiem kopnąć, ale żeby wyszła z tego szybka kontra w meczu, to potrzeba jednak czegoś więcej.

A jak się uczyć tych skilli? Ćwiczyć, panie! Ćwiczyć! Zanim „jak?”, to najpierw „po co?”.

Po co te dzielenie? Po wiedzę!

1. Wartość biznesowa

Oszczędność kosztów. Dzieląc zadania, zespół realizuje tylko te wymagania, które dostarczają największą wartość, co redukuje czas i koszty związane z wdrażaniem zbędnych funkcji.
Zwiększona wartość dostarczana szybciej (ROI). Dzięki realizacji priorytetowych funkcji jako pierwszych organizacja szybciej osiąga zwrot z inwestycji.
Zwiększenie transparentności budżetowej. Dzielenie wymagań umożliwia bardziej szczegółowe śledzenie kosztów poszczególnych funkcji i łatwiejsze zarządzanie budżetem.

2. Feedback i dostosowanie kierunku

Szybszy feedback od użytkowników. Małe przyrosty funkcjonalności pozwalają użytkownikom na testowanie produktu wcześniej i częściej, co daje zespołowi cenne informacje zwrotne.
Odkrywanie właściwego kierunku rozwoju. Dzięki regularnemu feedbackowi zespół może lepiej dopasować funkcje do oczekiwań użytkowników i uniknąć inwestycji w niewłaściwe rozwiązania.
Zwinne dostosowanie wymagań. Dzięki małym przyrostom zespół może elastycznie reagować na zmiany w otoczeniu biznesowym i dostosowywać kierunek prac do nowych informacji.

3. Minimalizowanie ryzyka technicznego

Wczesna identyfikacja problemów technicznych. Dzieląc wymagania, zespół szybciej wykrywa i rozwiązuje potencjalne problemy, co minimalizuje ryzyko niepowodzenia na późniejszym etapie.
Rozwiązywanie problemów w małych, łatwych do zarządzania krokach. Małe przyrosty umożliwiają zespołowi testowanie i dostrajanie technologii oraz narzędzi bez ryzyka destabilizacji całego systemu.
Zwiększenie jakości poprzez testowanie. Dzielenie wymagań na mniejsze elementy pozwala na regularne testowanie każdej funkcji, co zwiększa ogólną jakość produktu.

4. Efektywna integracja i zarządzanie zależnościami

Częstsza i łatwiejsza integracja. Mniejsze, dobrze zdefiniowane elementy są łatwiejsze do zintegrowania z istniejącym systemem, co zmniejsza ryzyko błędów integracyjnych.
Redukcja złożoności. Dzielenie wymagań ogranicza ryzyko związane z zależnościami między funkcjami i ułatwia ich równoległe rozwijanie.
Lepsza współpraca zespołu. Dzielenie zadań na mniejsze części ułatwia delegowanie pracy i zwiększa efektywność współpracy w zespole.

5. Efektywność pracy zespołu i komfort pracy

Lepsze planowanie i przewidywalność. Dzięki mniejszym zadaniom zespół może lepiej oszacować czas realizacji i planować dostarczanie funkcji w krótszych, przewidywalnych iteracjach.
Redukcja przeciążenia zespołu. Małe, dobrze określone zadania ułatwiają zarządzanie pracą, co minimalizuje ryzyko przepracowania i zwiększa motywację.
Jasna odpowiedzialność za zadania. Mniejsze zadania są łatwiejsze do przypisania, co sprzyja odpowiedzialności i transparentności.

Sporo tych plusów, prawda? Wydaje się, że znaczna większość z nich uzasadnia samą próbę podzielenia wymagań?

OK. Wiedza? Spoko! To teraz - jak?

Ilustracja - lampa Scrumvival

Na początek coś, co nie do końca można nazwać zaawansowaną techniką: wizualizacja. Spiszcie, zrzućcie z głowy wszystko, co jest do zrobienia. A najlepiej narysujcie (Miro, tablica) schemat blokowy, zależności, strzałki - jak zobaczysz, to łatwiej rozmawiać.

Fascynujące, jak często widzę mega łebskich ludzi, którzy tworzą rozbudowane, wielowymiarowe struktury w głowie... Ale kartki do ręki nie wezmą... Jak zobaczysz swoje myśli na rysunku, to będziesz miał już co dzielić. Po to właśnie tworzy się szkice przy majsterkowaniu - by nie trzeba było sobie tego ciągle wyobrażać. Przy okazji można zobaczyć, że ławka jakaś taka nieforemna ;)

Kilka technik, od których warto zacząć

Podział na etapy przepływu pracy (Workflow Steps): rozbij wymaganie na mniejsze części na podstawie kroków, jakie użytkownik wykonuje, aby zrealizować cel (np. rozpoczęcie, przetwarzanie, zatwierdzenie).
Podział według operacji CRUD: jeśli wymaganie dotyczy danych, rozbij je na podstawowe operacje Create (tworzenie), Read (czytanie), Update (aktualizowanie) i Delete (usuwanie).
Podział według scenariuszy użytkownika: skup się na różnych scenariuszach użycia, np. początkujący użytkownik vs. zaawansowany użytkownik, aby ułatwić przyrostowe wdrażanie funkcji.
Podział na wersje Minimal Marketable Features (MMF): ustal, które funkcje mogą być dostarczone jako najmniejsza, wartościowa wersja produktu, którą użytkownik może używać od razu.
Podział według kryteriów akceptacji (Acceptance Criteria): rozbij wymaganie, używając kryteriów akceptacji jako mniejszych, samodzielnych zadań, które można realizować oddzielnie.
Podział interfejsu użytkownika (User Interface Segmentation): rozbij zadanie na mniejsze elementy interfejsu, np. ekran logowania, formularz wyszukiwania, aby przyrostowo dodawać funkcjonalności.
Podział według rodzaju danych (Data Types): jeśli zadanie operuje na różnych typach danych, rozbij je na mniejsze zadania dla każdego typu, np. dane podstawowe, historia transakcji.
Podział według wyjątków i przypadków krawędziowych: skup się na standardowym przepływie, a dopiero w następnych krokach dodawaj obsługę wyjątków i sytuacji niestandardowych.

Spoko, spoko. Jak zacząć?

Weźcie coś, co skończyliście, i ćwiczcie. Część z podziałów nie będzie mieć pewnie większego sensu. Chodzi tu jednak o doświadczenie i nauczenie się, jak to robić ;) Podzielcie się na grupy, niech każda weźmie inną technikę. Porównajcie rezultaty. Potem weźcie coś nowego i spróbujcie jeszcze raz.

Ale to przecież zajmie czas, a my nie mamy czasu! Pytanie, czy 15 minut to aż tak duża strata? Niepodzielone wymagania mają tendencję wybuchać, prawda? Może jednak lepiej te 15 minut zainwestować, stojąc przed takim wyborem.

Kiedy coś się wysypie - wymagania wzrosną, coś zawiedzie w planie - odpowiedzcie na pytanie: jak mogliśmy podzielić wymagania, żeby do tego wybuchu nie doszło?

Podsumowanie

Praca z dzieleniem pracy na mniejsze kawałki to wyzwanie. Poza umiejętnościami lub ich brakiem dochodzą dodatkowe czynniki, których tu nie omówiłem: stan oprogramowania, umiejętności deweloperskie, presja, chęci - czyli profesjonalne podejście do pracy itp.

Na koniec dnia zostaje „tego się nie da” czy „nie umiem tego zrobić jeszcze”. A Ty jak dzielisz wymagania? Podziel się praktykami i sposobem pracy z nimi.

ZESPÓŁ MÓWI "NIE DA SIĘ TEGO PODZIELIĆ": WYMAGANIA W SCRUM