Teoretycznie proste rzeczy mają tendencję do bycia trudnymi w praktyce. Historyjki Użytkownika, a bardziej ogólnie – wymagania w podejściu zwinnym – są na tyle ogólne, że bardzo łatwo zacząć robić nieme założenia… i totalnie rozminąć się z potrzebami.
Praktyka w tyle za teorią
W prawdziwym życiu nic nie jest takie proste, jak byśmy chcieli. Nawet z pozoru łatwe rzeczy mogą zakończyć się niepowodzeniem. Podobnie sprawa ma się z naszą pracą, a dokładniej z przekuwaniem spisanego wymagania na działający kawałek Przyrostu. Powiedzmy sobie szczerze, nie zawsze się to udaje.
Nawet najlepiej napisane User Story nie gwarantuje, że powstający na koniec Sprintu produkt będzie dokładnie taki, jak opisał go analityk. Celowo piszę „opisał”, ponieważ nie wiedzieć dlaczego część osób nie wyobraża sobie Planowania Sprintu nie posiadając gotowej analizy.
O skutkach takiego podejścia nie będę nawet pisał. Sugestię tego co się może wydarzyć opisywał wczoraj Tomek w tekście „Mini-waterfall„.
Wróćmy do naszej analizy. Mając ją spisaną najlepiej jak się da, gdy zabieramy się do pracy często okazuje się, że świat nie jest taki piękny jak nam się wydawało. Napotykamy na bariery i „wyzwania”, które uniemożliwiają nam zrealizowanie wymagania w założony sposób.
Przyczyn powyższego stanu jest wiele. Często mają one podłoże w niezrozumieniu istoty wymagania czy też potrzeby. Nie ma kłopotu, jeśli Zespół Deweloperski sam spostrzeże, że obrany kierunek prowadzi donikąd. Gorzej, jeśli wyjdzie to dopiero na Sprint Review, a usłyszmy to z ust naszego interesariusza.
Pracując w iteracyjnym podejściu, mamy jednak możliwość szybkiej poprawy wytworzonego produktu dokładnie z wolą i wizją naszego klienta. Zastanawiające jest jednak, dlaczego w ogóle tak się dzieje.
Istota wymagania
Proces Scrum zaprojektowany został tak, aby osoby, które go wykorzystują miały możliwość dokonania inspekcji swojego rozumienia istoty wymagania. Począwszy od ciągłego Product Backlog Refinementu, poprzez szczegółowość wymagań, spełnianie kryteriów gotwości, aż do samego Sprint Planingu.
Na każdym etapie cyklu życia wymagania wszyscy członkowie Zespołu Deweloperskiego mają możliwość zaznajomienia się z wymaganiem. Powinni też je omawiać i wyjaśniać niejasności. Nikt nie zakłada, że po przejściu powyższej ścieżki wymaganie może być w dalszym ciągu niezrozumiałe.
Na pozór prosta i klarowana sytuacja mocno się jednak komplikuje, kiedy przychodzi czas na realizację. Nagle okazuje się, że nasze rozumienie celu wymagania jest inne, niż rozumienie biznesu. Powoduje to, że historyjka użytkownika staje się kulą u nogi, bo przecież „nie tak miało być”. A skoro tak, to chcemy jej się jak najszybciej pozbyć.
Pozbyć, czyli wykonać jak najszybciej i jak najmniejszym nakładem sił. Dzieje się wówczas rzecz charakterystyczna dla tego procesu, a mianowicie zaczynamy słyszeć słowa „wydaje mi się”.
Wypowiedzenie tych słów powinno włączyć wszystkie alarmy. Oznaczają one bowiem, że zaczynamy płynąć w zupełnie nieznanym kierunku.
„Wydaje mi się”
Nie ma nic złego w próbie wejścia w buty naszego interesariusza. Wczuwamy się potrzeby jego lub jego klientów. Taka postawa jest akceptowalna do momentu, w którym nie zaczynamy robić założeń.
Prowadząc szkolenia, często widzimy taką postawę na Lego Scrum. Zadziwiające, że dotyczy ona zarówno początkujących adeptów metodyki, jak i tych bardziej doświadczonych. Przyjęcie założenia pochodzącego z „wydaje mi się” jako potrzeb interesariuszy zwykle kończy się niepowodzeniem. Było tak blisko, a tu znowu trzeba krzyczeć „Tego nie było w wymaganiach!” A zapytaliście?
Przyczyn takiego zachowania może być wiele. Nieufność wobec interesariusza, strach czy wstyd przed zapytaniem o rzecz oczywistą. Przekonanie o słuszności swojego działania czy brak zaufania w zespole to kolejne cegiełki do bariery pomiędzy Historyjką Użytkownika, a wytworzonym produktem.
I tu nie chodzi o to, aby z każdą pierdołą biegać do Product Ownera, ale żeby ustalić jakiś poziom wzajemnego zrozumienia. Ale nie poprzez rozmijanie się z wymaganiami, tylko poprzez dopytywanie o wszystko, czego nie jesteśmy pewni. Przynajmniej na początku lepiej jest zadać dwadzieścia „niepotrzebnych” pytań, żeby dowiedzieć się jednej istotnej rzeczy wywracającej wszystko do góry nogami.
Każdy z opisanych powyżej czynników prowadzi w konsekwencji do wytworzenia czegoś, czego nasz klient nie chciał i nie zamawiał. Nie jest to więc kierunek, w którym powinniśmy podążać.
Rezultaty Historyjek Użytkownika
Rozbieżność pomiędzy produktem naszych prac, a oczekiwaniami opisanymi w Historyjce Użytkownika często jest argumentem podnoszonym przez przeciwników zwinnych metodyk. Osoby te zwracają uwagę, że wytwarzając przyrost „prawie” zgodny z wymaganiem tworzymy tak naprawdę coś na kształt „wydmuszki”. Nie mogę się z nimi nie zgodzić.
Jednak tak, jak w przypadku innych argumentów „przeciw”, tak i w tym przypadku należy jasno zauważyć, że nie jest to problem metodyki, a ludzi ją wykorzystujących. Łatwo można zepsuć prawidłowe stosowanie zwinnego podejścia, ale też równie łatwo możemy wykorzystać jego mechanizmy, żeby skorygować swoje działanie. W jaki sposób?
Uniknięcie tej sytuacji jest proste, żeby nie powiedzieć, trywialne. Po pierwsze, musimy zdać sobie sprawę z tego, że proces wytwórczy przebiega źle. Potrzebne są nam do tego jasna i konkretna informacja zwrotna.
Po drugie, posiadając feedback powinniśmy usiąść w gronie Zespołu Deweloperskiego i porozmawiać o przyczynach tego stanu rzeczy. Spotkaniem, które służy takiej analizie i wytworzeniu akcji naprawczych jest oczywiście tak często nielubiane Sprint Retrospective.
Pamiętajmy jednak, aby wnioski i akcje naprawcze płynące z tego spotkania wykonać z najwyższą starannością. Nie są one gwarantem sukcesu, ale na pewno przybliżą nas do rozwiązania problemu.
