Środek sprintu. Na czacie zespołu wyskakuje wiadomość od developera: „A co ma się stać, kiedy użytkownik ma dwa aktywne zamówienia i anuluje to starsze?". Otwierasz historyjkę, przewijasz kryteria akceptacji i czujesz nieprzyjemny chłód. O dwóch zamówieniach nie ma tam ani słowa. Gorzej: odpowiedź na to pytanie unieważnia połowę tego, co napisałeś. Zadanie stoi, developer czeka, a ty ruszasz szukać kogoś z biznesu, kto podejmie decyzję, którą powinieneś był przynieść zespołowi razem z historyjką.
Znam ten moment i wiem, jak potrafi zaboleć. Cały ten tekst jest zbudowany wokół jednej myśli: przekazane nie znaczy zrozumiane. To, że historyjka wisi w backlogu, a specyfikacja w bazie wiedzy, nie oznacza jeszcze, że zespół wie, co zbudować i jak to sprawdzić. Handoff wymagań to proces, nie zdarzenie. I da się go poprawić na tyle, że historyjki przestaną wracać.
Handoff to nie wysyłka dokumentu
„Wysłałem specyfikację na Confluence" to nie jest przekazanie wymagań. To jest upload pliku. Różnica wydaje się oczywista, a jednak łatwo o niej zapomnieć, bo wysyłka daje przyjemne poczucie zamknięcia tematu. Odhaczone, poszło, można brać następny temat z listy.
Tylko że miarą handoffu nie jest to, co wyszło od ciebie. Miarą jest to, co zespół umie zrobić po drugiej stronie. Konkretnie: czy developer potrafi na podstawie historyjki podejmować decyzje bez zgadywania, a tester potrafi wyprowadzić z niej przypadki testowe bez ani jednego pytania do ciebie. Ten drugi warunek to mój ulubiony sprawdzian, bo jest bezlitosny. Jeśli tester musi dopytać, co znaczy „poprawnie obsłużone", wymaganie nie było gotowe, choćby nie wiem jak ładnie wyglądało w dokumencie. Zanim cokolwiek trafi do zespołu, samo wymaganie da się przetestować jak produkt - jak się za to zabrać, opisałem we wpisie o testowaniu i weryfikacji wymagań.
Zrób ten eksperyment przy najbliższej historyjce. Zanim ją przekażesz, usiądź z testerem i poproś, żeby na głos powiedział, jakie przypadki testowe z niej wynikają. Miejsca, w których się zawaha, to dokładnie te miejsca, w których developer za tydzień napisze do ciebie na czacie.
Co musi być gotowe, zanim historyjka wejdzie do sprintu
Zespoły, w których historyjki wracają, mają zwykle wspólny mianownik: do sprintu wchodzi wszystko, co ma tytuł i z grubsza opisany cel. Reszta „doprecyzuje się w trakcie". No i się doprecyzowuje - w połowie sprintu, w najgorszym możliwym momencie, kiedy połowa kodu już stoi na założeniach, których nikt nie potwierdził.
Lekarstwem jest umowa zespołowa o tym, co znaczy „gotowe do wzięcia". Jak spisać taką umowę i nie zamienić jej w biurokrację, pokazuję we wpisie o Definition of Ready i Definition of Done z przykładami. Tutaj zatrzymam się przy trzech elementach, które w moim doświadczeniu robią największą różnicę.
Pierwszy: testowalne kryteria akceptacji. Nie „system działa poprawnie", tylko warunki, które da się jednoznacznie sprawdzić i rozstrzygnąć. O tym, jak je formułować, żeby dały się wprost przełożyć na testy, przeczytasz we wpisie o pisaniu kryteriów akceptacji. Sama forma historyjki to osobna rzemieślnicza umiejętność - jeśli chcesz ją poukładać, zajrzyj do tekstu o pisaniu user stories.
Drugi: rozstrzygnięte zależności. Jeśli historyjka wymaga zgody działu prawnego, odpowiedzi od dostawcy zewnętrznego API albo decyzji, które z dwóch zachowań systemu jest ważniejsze - to musi być zamknięte przed planowaniem. Otwarta zależność nie wybucha nigdy przed sprintem. Wybucha w jego środku.
Trzeci: przygotowane dane i makiety. Developer, który ma zbudować formularz, potrzebuje makiety albo choćby szkicu, o który można się pospierać. Tester potrzebuje danych testowych, które odzwierciedlają realne przypadki, także te brzydkie: konta z niepełnymi danymi, rekordy z przeszłości, duplikaty. Jeśli tego nie ma, zespół wypełni luki własnymi założeniami. A założenia zespołu prawie nigdy nie pokrywają się z twoimi.
Refinement, który działa
Refinement to najtańsze miejsce na wyłapanie problemów z wymaganiami. Każde pytanie, które padnie tam, nie zatrzyma nikogo w sprincie. A mimo to wiele refinementów wygląda identycznie: analityk czyta historyjkę na głos, zespół kiwa głowami, ktoś rzuca estymatę i lecimy dalej.
Sam tak prowadziłem te spotkania. W jednym z zespołów, z którymi pracowałem, refinement trwał kwadrans, wszyscy wychodzili zadowoleni, a potem w sprincie dostawałem lawinę pytań na czacie. Zmieniłem jedną rzecz: przestałem czytać historyjki, a zacząłem opowiadać scenariusze. Zamiast „jako klient chcę anulować zamówienie" mówiłem: „Klientka złożyła zamówienie godzinę temu, kurier jeszcze go nie odebrał, ona klika anuluj. Co się dzieje? A jeśli kurier już je odebrał? A jeśli zapłaciła kodem rabatowym?". Te same osoby, które wcześniej kiwały głowami, zaczynały nagle mówić: „czekaj, w tym drugim przypadku mamy problem". Kwadrans zamienił się w pół godziny, a pytania w sprincie niemal zniknęły.
Dobre pytania na refinemencie mają swoje wzorce i możesz je świadomie wywoływać. Od developera powinno paść coś w rodzaju: „co system ma zrobić, kiedy ten krok się nie powiedzie?", „skąd bierzemy te dane i co robimy, kiedy ich brakuje?", „czy w aplikacji mobilnej to zachowanie ma być takie samo?". Od testera: „po czym poznam, że to działa?", „jakie są przypadki brzegowe?", „które z tych kryteriów da się sprawdzić automatycznie?". Jeśli takie pytania nie padają, to zwykle nie dlatego, że historyjka jest świetna. Raczej dlatego, że nikt jej jeszcze naprawdę nie przemyślał.
Pomaga mi prosta zasada trzech perspektyw: każdą historyjkę oglądamy oczami biznesu (po co to robimy i co jest wartością), oczami kodu (jak to zbudować i co nam to komplikuje w architekturze) oraz oczami testu (jak udowodnić, że działa). Jeśli któraś perspektywa milczy, wywołuję ją wprost: „a jak byś to przetestowała?". Gdzie analityk mieści się w całym rytmie scrumowym poza samym refinementem, opisałem we wpisie o Scrumie z perspektywy analityka.
Pytania od developerów to sygnał, nie atak
Łatwo brać pytania z zespołu do siebie. Skoro pytają, to coś zawaliłem, a każda wiadomość na czacie wygląda jak recenzja mojej pracy. Nie tędy droga. Zespół, który pyta, jest znacznie bezpieczniejszy od zespołu, który w ciszy zgaduje i buduje na tych domysłach. Pytanie to dane wejściowe. Trzeba je tylko poprawnie zaklasyfikować, bo różne typy pytań wymagają zupełnie różnych reakcji.
U mnie sprawdza się podział na trzy koszyki:
| Typ pytania | Przykład | Co robię |
|---|---|---|
| Luka w wymaganiu | „Co się dzieje z subskrypcją, kiedy płatność nie przejdzie trzeci raz z rzędu?" | To moja robota. Uzupełniam historyjkę albo kryteria akceptacji, w razie potrzeby potwierdzam z biznesem i wracam do zespołu z konkretem. Notuję też, jaki typ scenariusza przegapiłem. |
| Decyzja biznesowa | „Czy klient z zaległą fakturą może w ogóle złożyć nowe zamówienie?" | Nie zgaduję. Ustalam, kto jest właścicielem tej decyzji, przedstawiam mu opcje wraz z konsekwencjami, a odpowiedź zapisuję przy historyjce, żeby została na piśmie. |
| Szczegół implementacji | „Walidujemy to na froncie czy dopiero na backendzie?" | Oddaję zespołowi. Dorzucam kontekst biznesowy, jeśli ma znaczenie, ale decyzję techniczną podejmują ludzie, którzy będą ten kod utrzymywać. |
Luka w wymaganiu boli najbardziej, bo działa jak lustro. Jest też najcenniejsza: każda pokazuje całą klasę scenariuszy, którą systematycznie pomijasz. Częsty wzorzec to sytuacje rozciągnięte w czasie - co się dzieje, kiedy coś wygasa, kiedy dwa zdarzenia zajdą równocześnie, kiedy użytkownik wraca po długiej przerwie. Jeśli zaczniesz notować swoje luki, po kilku sprintach zobaczysz własny ślepy punkt i nauczysz się go sprawdzać z automatu.
Decyzja biznesowa kusi, żeby odpowiedzieć od ręki. Znasz produkt, masz intuicję, developer czeka. Ale zgadywanie za właściciela produktu to pożyczka na wysoki procent: jeśli traficie źle, poprawka kosztuje cały cykl, a zaufanie do twoich odpowiedzi topnieje. Moja reguła brzmi: mogę przygotować decyzję, opisać opcje i zarekomendować jedną z nich, ale podjąć ją musi osoba, u której mieszka odpowiedzialność za skutki.
Szczegół implementacji ma jedną pułapkę: granica bywa cienka. Kiedy decyzja techniczna zmienia zachowanie widoczne dla użytkownika, na przykład komunikat błędu pojawi się w innym momencie, pytanie wraca do koszyka decyzji biznesowych. Umówcie się w zespole, że w razie wątpliwości developer sygnalizuje takie przypadki, zamiast rozstrzygać je po cichu.
Kanały i artefakty: jedno źródło prawdy
Drugi wymiar handoffu to miejsce, w którym informacja mieszka. Nawet świetnie napisane wymaganie zginie, jeśli zespół nie wie, gdzie go szukać, albo znajdzie dwie sprzeczne wersje.
Mój podział jest prosty. W narzędziu do zarządzania backlogiem mieszka wszystko, czego zespół potrzebuje w trakcie sprintu: historyjka, kryteria akceptacji, linki do makiet i decyzje podjęte dla tej konkretnej zmiany. W bazie wiedzy mieszka to, co żyje dłużej niż sprint: reguły biznesowe, słownik pojęć domenowych i wszystko, co opisuje produkt, a nie pojedynczą zmianę. A na diagramie mieszka to, czego proza nie udźwignie: przepływy z rozgałęzieniami, cykle życia obiektów, zależności między systemami i inne rzeczy, które w tekście zamieniają się w ścianę akapitów. Kiedy sięgać po rysunek zamiast kolejnego opisu i jak przy tym nie utonąć w notacji, pokazuję we wpisie o diagramach UML w praktyce.
I zasada, której złamanie mści się zawsze: jedno źródło prawdy. Jeśli ta sama reguła biznesowa jest opisana w historyjce i w bazie wiedzy, te dwa opisy się rozjadą. Nie „mogą się rozjechać" - rozjadą się na pewno, bo ktoś zaktualizuje jedno miejsce i zapomni o drugim, a po kilku miesiącach nikt nie będzie umiał powiedzieć, która wersja obowiązuje. Dlatego reguła mieszka w jednym miejscu, a wszędzie indziej daję do niej link. Historyjka mówi: „obowiązuje standardowa polityka anulowań, opis pod linkiem", zamiast przeklejać tę politykę po raz czwarty. Mniej wygodne przy pisaniu, dużo tańsze w utrzymaniu.
Po czym poznasz, że handoff się poprawił
Nie potrzebujesz do tego żadnego dashboardu. Objawy widać gołym okiem, sprint po sprincie.
Historyjki przestają wracać do poprawy specyfikacji w trakcie sprintu. Nie wszystkie i nie od razu, ale przypadki z gatunku „to pytanie unieważnia połowę opisu" robią się rzadkie, a potem egzotyczne. Pytania nadal padają - i bardzo dobrze - tylko przenoszą się z czatu w środku sprintu na refinement, czyli tam, gdzie kosztują najmniej. Tester pisze przypadki testowe bez wizyty przy twoim biurku, a jeśli już przychodzi, to z pytaniem o priorytet, nie o znaczenie wymagania. Demo przestaje być loterią, bo zespół buduje to, co biznes miał na myśli, a nie to, co dało się wywnioskować z dwóch zdań opisu.
Jest jeszcze jeden objaw, mój ulubiony: zmienia się ton rozmów. Zespół przestaje traktować wymaganie jak dokument „od analityka" i zaczyna traktować je jak wspólny kontrakt. Kiedy developer sam z siebie mówi na refinemencie „tu brakuje scenariusza dla wygasłej sesji", wiesz, że przestałeś być jedynym strażnikiem jakości wymagań. Właśnie o to chodziło od początku.
Jeśli chcesz sprawdzić, na czym stoisz, zrób darmowy test wiedzy o wymaganiach. Rozwiążesz go bez zakładania konta, a wynik zobaczysz od razu. Potraktuj go jak szybki przegląd: pokaże ci, które obszary masz opanowane, a przy których historyjki mogą jeszcze do ciebie wracać.
Najczęstsze pytania
Kiedy historyjka jest gotowa do wzięcia na sprint?
Gdy ma testowalne kryteria akceptacji, zamknięte zależności zewnętrzne oraz przygotowane dane i makiety. Najlepszy sprawdzian jest bezlitosny: poproś testera, żeby na głos wyprowadził z niej przypadki testowe. Miejsca, w których się zawaha, to dokładnie te, o które developer dopyta w środku sprintu.
Co zrobić, gdy developer zadaje pytanie w trakcie sprintu?
Najpierw zaklasyfikuj pytanie, bo każdy typ wymaga innej reakcji. Luka w wymaganiu jest twoją robotą i uzupełniasz ją od razu, decyzja biznesowa wraca do właściciela decyzji z opisanymi opcjami, a szczegół implementacji zostaje przy zespole, który będzie ten kod utrzymywał. Granica bywa cienka: decyzja techniczna zmieniająca coś widocznego dla użytkownika wraca do koszyka decyzji biznesowych.
Gdzie trzymać wymagania: w narzędziu do backlogu czy w bazie wiedzy?
Podział jest trójdzielny. W backlogu mieszka to, czego zespół potrzebuje w trakcie sprintu, w bazie wiedzy to, co żyje dłużej niż sprint, a na diagramie to, czego proza nie udźwignie: rozgałęzienia, cykle życia i zależności między systemami. Ta sama reguła opisana w dwóch miejscach rozjedzie się na pewno, więc mieszka w jednym, a gdzie indziej stoi do niej odnośnik.
Jak prowadzić refinement, żeby faktycznie wyłapywał luki?
Nie czytaj historyjek, tylko opowiadaj konkretne sytuacje i dopytuj o przypadki brzegowe. Wywołuj trzy perspektywy - biznesu, kodu i testu - a jeśli któraś milczy, poproś tę osobę wprost o zdanie. Refinement, który trwa kwadrans i kończy się kiwaniem głowami, przenosi pytania na czat w środku sprintu, gdzie kosztują najwięcej.