Czy kiedykolwiek zdarzyło się Ci się podczas prezentacji stworzonego rozwiązania zobaczyć zaskoczoną minę Product Ownera i usłyszeć “ale nie o to mi chodziło…”? Takie sytuacje mogą wynikać z błędnych opisów wymagań, ich złego zrozumienia, pomyłki podczas implementacji. Jak zminimalizować szansę na takie problemy?
Zgodnie z zasadą 3C, jaką Ron Jeffries opisał w Extreme Programming Installed, User Story jest połączeniem trzech elementów:
- Card (karta) – Historyjka Użytkownika powinna być spisana na karcie. Dziś najczęściej robimy to w elektronicznym narzędziu, istnieje jednak wiele technik, wspierających tę klasyczną formę.
- Conversation (konwersacja) – dyskusja osób zaangażowanych w realizację User Story.
- Confirmation (potwierdzenie) – zgoda na temat rozwiązania, jakie zespół chce zastosować.
Niestety, konwersacja jest często pomijana w procesie wytwarzania oprogramowania, co powoduje potencjalne problemy. Podczas refinementu wystarczy przecież przeczytać zadanie, może zadać jedno lub dwa pytania i je wyestymować. Po co poświęcać czas na rozmawianie o nim? Poniżej przedstawiam pięć w mojej opinii najważniejszych powodów.
Rozumiecie, o co mi chodzi?
Takie pytanie zadane przez Product Ownera podczas Refinementu jest skazane na porażkę. Jeśli zada je po przeczytaniu wymagań i usłyszy odpowiedź twierdzącą znaczy to tyle, że ktoś jest przeświadczony o poprawności swojego toku rozumowania. No właśnie, ale czy zrozumiał wszystko tak samo jak osoba, która je spisała?
Jeff Patton podsumował taką sytuację zdaniem Shared documents aren’t shared understanding (Wspólne dokumenty to nie wspólne zrozumienie). Spisywanie wymagań i oczekiwanie, że ktoś inny zrozumie je tak samo, jest dość ryzykowne.
Wstępnym definiowaniem wymagań zajmuje się często kilka różnych osób: klient, Product Owner, designer. Treść jest uzupełniana, poprawiana, dołączane są schematy, mockupy, itd. Jeśli pominiemy rozmowę, to gdy wymaganie dociera do zespołu deweloperskiego, może być trochę zmienione. Albo być zupełnie innym pomysłem? Może to przypominać dziecięcą zabawę w głuchy telefon. Każda kolejna osoba biorąca udział w procesie może coś nieświadomie zmienić.
A co zrobić, aby uzyskać prawdziwe potwierdzenie wspólnego zrozumienia? Znacznie bardziej wartościowe może być poproszenie jednego z deweloperów o opowiedzenie własnymi słowami na czym polega to zadanie. Może to być prośba o podsumowanie wspólnej dyskusji.
Więcej ludzi to lepsze rozwiązanie
W mojej opinii grupa ludzi ma większe szanse na znalezienie lepszego rozwiązania, niż jeden wybraniec. O ile będą na ten temat dyskutować i powstrzymają się od poruszania pobocznych tematów takich jak pomysły na spędzenie nadchodzącego weekendu.
Dlaczego więc Product Owner ma przychodzić ze wszystkim szczegółami? Czy nie lepiej, gdy przyniesie ogólne założenia i popracuje nad nimi wspólnie z zespołem deweloperskim?
Być może zespół od razu powie, że takie rozwiązanie z technicznego punktu widzenia jest nienajlepsze, zbyt czasochłonne lub nawet niebezpieczne. Szersza perspektywa osób z różnym doświadczeniem lub specjalizacjami może przynieść zaskakujące pomysły, które lepiej spodobają się użytkownikom.
Znajdowanie pomyłek
Wspólna dyskusja, lub nawet tylko przedstawienie zadania przez Product Ownera, może pomóc w znalezieniu błędów w opisie lub niejasności. Każdy jest tylko człowiekiem (nawet PO!) i ma prawo do błędu. Gdy deweloperzy otrzymają spisane wymagania i bez rozmowy będą je implementować, to szanse na odkrycie pomyłek maleją.
Comprehensive documentation over working software
Tak, pamiętam jak poprawnie brzmi ta zasada z Agile Manifesto. Warto jednak zwrócić uwagę, że dokumentacja jest jedną z ostatnich rzeczy, jakie chce tworzyć deweloper. Bardzo często sytuacja odwraca się diametralnie, jeśli chodzi wymagania. Tu im więcej szczegółów, tym lepiej. Oczywiście spisane, bo punkt po punkcie będzie można wszystko zaimplementować, tester ma natomiast gotowe scenariusze.
Product Ownerzy tworzą więc w pocie czoła długie opisy z ogromną liczbą szczegółów, bo w ten sposób najłatwiej upewnić się, że wszystko poprawnie przekazali. Niestety, może to być strzał w stopę. Deweloper przytłoczony ilością tekstu może źle zrozumieć wymagania lub pominąć jakiś istotny szczegół, zaszyty w jednym z wielu akapitów.
Znacznie prościej w skrócie opisać tło, wypunktować kryteria akceptacji i porozmawiać o szczegółach podczas refinementu. Jeśli jakieś istotne szczegóły wymagają zapisania, można to zrobić. Z drugiej strony spisywanie na początku wszystkiego, co tylko przyjdzie do głowy, powoduje zaciemnienie obrazu.
Coś wreszcie od nas zależy!
To argument dla bardziej doświadczonych zespołów. Takich, którzy chcą współtworzyć produkt, a nie stosować wymaganiowe TDD, czyli Ticket Driven Development. Innymi słowy jak najszybciej i bez zbędnego zastanowienia przesunąć zadanie z kolumny “ToDo” do “Done”. Następny proszę!
Takie podejście ma swoje plusy – w końcu zespół dowozi kolejne rozwiązania. Jednak większe zainteresowanie zadaniami i ich współtworzenie z Product Ownerem może przynieść jeszcze jedną ważną rzecz.
Deweloperzy zwrócą uwagę, że nie są tylko małymi trybikami w wielkiej maszynie, które w pocie czoła mają kończyć kolejne zadania. Dzięki wspólnej dyskusji mają wpływ na ich kształt, zastosowane rozwiązania, mogą proponować zmiany w podejściu. Dla Product Ownera zaangażowanie deweloperów w tworzenie wymagań jest ogromną pomocą, której na pewno nie zapomni. Takimi małymi krokami można polepszyć relacje oraz zaufanie w zespole scrumowym. Dzięki temu współpraca może układać się znacznie przyjemniej i wydajniej.
Podsumowanie
Jak widać, wspólna dyskusja zespołu scrumowego na temat wymagań może pomóc w wielu aspektach. Właściwe zrozumienie wymagań, wspólne szukanie najlepszych rozwiązań oraz weryfikacja historyjek użytkownika wpływa nie tylko na zwiększenie jakości. Powoduje także większe zaufanie pomiędzy zespołem deweloperskim a Product Ownerem. Programiści mogą poczuć, że faktycznie współtworzą produkt, a nie tylko zamykają kolejne zadania.
Be First to Comment