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

WSTĘP

Jeśi 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. I to o tych przypadkach 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ń to klucz do efektywnej pracy zespołu, pozwala szybciej dostarczać wartość, zbierać feedback, redukować ryzyko techniczne i poprawiać organizację pracy.

Warto wyjść poza „nie da się” i spróbować „nie umiemy jeszcze”.

Co daje tak naprawdę podział pracy na mniejsze kawałki?

Techniki dzielenia wymagań oraz praktyczne tipy jak zacząć.

PLANOWANIE ROBOTY

Planowanie pracy, dzielenie jej na mniejsze części, prowadzenie/ zarządzanie pracą i jej monitorowanie by potem ocenić i zgarnąć oraz przetworzyć feedback – to są skille. Umiejetności, których trzeba się nauczyć. Niby proste, ale życie pokazuje że jak coś prosto wygląda to pod spodem nieraz miesiące czy lata praktyki są ukryte, 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?

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ł wg 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ł wg 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 przećwiczćie. Cześc z podziałów nie będzie mieć pewnie większego sensu, chodzi 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 15min to aż tak duża strata biorąc pod uwagę, że nie podzielone wymagania mają tendencję wybuchać? Ja to jednak wolę te 15min zainwestować stojąc przed takim porównaniem.

Kiedy coś się wysypie – wymagania wzrosną, coś zawiedzie w planie – odpowiedzcie na pytanie – jak mogliśmy podzielić wymagania by dojść do tego wybuchu?

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.