Czemu biznes analityk napisał takie zgrubne User Stories? Dlaczego ja jako developer mam się zastanawiać co tu się ma dziać? Czemu znowu QA ma pisać wszystkie scenariusze sam? Dlaczego nie możemy się domyśleć, co tam się dzieje …
Bardzo łatwo jest właśnie w taki sposób przerzucać odpowiedzialności. Ba, sama 2 Sprinty temu narzekałam na jakość opisów swoich zadań. Tester narzekał na mój kod, bo brakowało oczywistych funkcjonalności, a BA na koniec odkrywał, że coś jednak nie jest zaimplementowane jak trzeba. To nie jest jakieś ekstremum, wydaje się, że sytuacja może zdażyć się dość często. Co wtedy? My sięgneliśmy po Thee Amigos.
O co chodzi?
To podjeście, które mówi, że tak naprawdę User Stories powinny być opisane trójgłosem: testera, biznesu i programisty (ale tak naprawdę czasem może być potrzeba więszej liczby perspektyw, UX, UI, ktoś z wiedzą domenową /naukową). W wyniku współpracy Three Amigos mamy uzyskać kompletne i satyfakcjonujące User Stories zapisane za pomocą BDD (choć warto je postrzegać jako rezultat tego, że wszyscy rozumiemy funkcjonalność w ten sam sposób). Najlepiej, by doszło do niej przed implementacją, a w zasadzie przed backlog refilement (grooming) / sprint planning — żeby dobrze je wycenić ;) Choć można i o tym pomyśleć jako o nieustającym procesie, gdzie każdy bierze odpowiedzialność za zrozumienie i dostarczenie poszukiwanego rozwiązania.
To nie musi być spotkanie
Choć często właśnie spotkanie okaże się najlepszym rozwiązaniem. Czasami wystarczy zaangażowanie developerów w pisanie US, albo “obowiązek” zadawania pytań w narzędziu do ich przechowywania. Wydaje mi się, że spotkanie będzie działało fajnie jako pokazanie techniki, zwrócenie uwagi, na to co każda ze stron ma na myśli / jak rozumie poszczególne funkcjonalności. Gdy wspólnie będziecie rozumieli aplikacje tak samo, może okazać się, że spotkania same w sobie nie są już potrzebne, bo i bez nich dochodzicie do tego poziomu zrozumienia.
Jak można przeprowadzić takie spotkanie?
Przechodząc przez Aceptance Criteria, czy po prostu funkcjonalność, zastanowić się co to właściwie znaczy.
Coś co uwielbiam, czyli pytanie DLACZEGO jest chyba tym, na które BA powinien odpowiedzieć na samym początku. Dlaczego dana funkcjonalność jest potrzebna? Co za sobą niesie? Co z nią zrobi klient? Czy są jakieś inne funkcjonalności, które ją blokują? Jak wyglądają makiety?
Z mojego developerskiego punktu widzenia, warto więc przejść sobie w głowie po tym, co już jest zaimplementowane, po autoryzacji jaka może być wymagana. Warto pomyśleć o zasadach, które już są w aplikacji (np. walidacje, obsługa błędów itp.) i dopytywać. Przeklikać się przez makiety, popatrzeć, czy nie ma tam jakiś nowych elementów, których jeszcze w aplikacji nie mamy i nie wiemy jak je obsługiwać ;)
Tester zaś powinien pomyśleć o środowisku, użytkownikach, danych testowych, mokowaniu funkcjonalności. O ścieżkach, które użytkownik może dzięki tej funkcjonalności przejść.
Na koniec warto podzielić się pracą, bo ktoś to będzie musiał spisać ;) I znowu każdy z trzech przyjaciół powinien spisać również dodatkowe informacje, jakie wyniósł. Może pojawiły się jakieś dodatkowe pytania związane z funkcjonalnością (BA), implementacją czy testowaniem? Może zadanie wymaga jakiś dodatkowych mechanizmów czy bliliotek, a może mocków czy danych testowych? … Jak widzicie, oprócz scenariuszy BDD, zbieramy więc potencjalne zadania.
Na własnej skórze
No właśnie, jak sama wspomniałam, wdrożyliśmy takie podjeście w naszym zespole. I jak? Faktycznie przyśpieszyło to naszą pracę. Co więcej, myślę, że każde takie spotkanie wpyłwa też na wzajemne zrozumienie się w zespole. Uwspólniamy rozumienie problemów, zbieramy wspólny słownik, jaśniej komunikujemy, o co nam chodzi, czy śmielej zadajemy pytania. Z małej historyjki, powstało,jak się okazało sporo scenariuszy, a ja sama miałam w notesie 3 rzeczy, na które bym nie wpadła czytając poprzedni opis zadania. W rezultacie, faktycznie mieliśmy wszystkie scenariusze testowe przed, co powoduje, że przenoszenie ich na kod, czy testy jest po prostu o wiele bardziej pewne. Wiem, że w przypadku mojego zespołu jest to narzędzie, z którego będę chciała korzystać. I jak widzicie, również rekomendować go innym.
Więcej o Three Amigos poczytacie tutaj:
Thee Amigos in Agile Team
Introducing the Three Amigos
Three Amigos Meeting – Agree the tests before development starts
