Three amigos, czyli zamiast odbijać piłeczkę zagramy razem

By 21 marca 2017Get Things Done, Praca

 

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

  •  
  •  
  •  
  • 9
  •  
  • Paweł Domański

    Zawsze mówimy o współpracy między developerami, programistami i użytkownikiem.
    Dlaczego nie ma nic mowy o działach wspierających waszą pracę? Gdzie działy utrzymaniainfrastruktury, administratorzy czy zwykły HelpDesk, który ma znaczący wpływ na całosć, także na waszą pracę. Ja bym powiększył to o wszystkich w IT. Z punktu widzenia developera, który uczestniczy tylko w fazie budowania nie bardzo obchodzi albo nie myśli co będzie później z jego produktem. Czy produkt jest przydatny, czy działa w sposób optymalny. Ja na codzień borykam się z tą drugą częścią i muszę z przykrością powiedzieć, że w dużej części przypadków „developer” to taki ludek który jest oderwany od rzeczywistości. Wrzuca kod na kolejne środowisko i się zmywa (niekiedy na długi urlop) a ty człowieczku walcz na pierwszej liniii frontu z tym co CI zostało. Bez dokumentacji bez wsparcia, bez szans na wygraną.
    Tak zgadzam się, rozmawiajmy ze sobą komunikujmy się zadawajmy pytania ale wszyscy razem.

    • Temat jak najbardziej słuszny i zasługujący na kolejny wpis. Często wygląda to tak, że sama struktura organizacji buduje trochę ścianę między developerami i utrzymaniem. I potem piszemy do siebie te maile, i czekamy kilka dni na testową bazę danych, a feedback od użytkownika nie zawsze dociera do developera. Z drugiej strony są też organizacje, w których za Opsy odpowiada developer, nie ma do tego osobnego teamu, a pomiędzy użytkownikiem a product Ownerem jest tylko jedna osoba w postaci powiedzmy Key Accounta. Jest więc róznie, a pewnie są i sytuacje, gdzie Developerzy zwyczajnie nie dbają o to, co będzie potem. Dzięki za pomysł na wpis, dopisujemy do listy tematów.

      • Paweł Domański

        Chętnie też podzielę się własnym punktem widzenia jako utrzymanie.