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

By 21 March 2017Get Things Done, Praca

 

Czemu biznes anal­i­tyk napisał takie zgrub­ne User Sto­ries? Dlaczego ja jako devel­op­er mam się zas­tanaw­iać co tu się ma dzi­ać? Czemu znowu QA ma pisać wszys­tkie sce­nar­iusze sam? Dlaczego nie może­my się domyśleć, co tam się dzieje …

Bard­zo łat­wo jest właśnie w taki sposób prz­erzu­cać odpowiedzial­noś­ci. Ba, sama 2 Sprinty temu narzekałam na jakość opisów swoich zadań. Tester narzekał na mój kod, bo brakowało oczy­wistych funkcjon­al­noś­ci, a BA na koniec odkry­wał, że coś jed­nak nie jest zaim­ple­men­towane jak trze­ba. To nie jest jakieś ekstremum, wyda­je się, że sytu­ac­ja może zdażyć się dość częs­to. Co wtedy? My sięgneliśmy po Thee Ami­gos.

O co chodzi?

To pod­jeś­cie, które mówi, że tak naprawdę User Sto­ries powin­ny być opisane trójgłosem: testera, biz­ne­su i pro­gramisty (ale tak naprawdę cza­sem może być potrze­ba więszej licz­by per­spek­tyw, UX, UI, ktoś z wiedzą domenową /naukową). W wyniku współpra­cy Three Ami­gos mamy uzyskać kom­pletne i saty­fakcjonu­jące User Sto­ries zapisane za pomocą BDD (choć warto je postrze­gać jako rezul­tat tego, że wszyscy rozu­miemy funkcjon­al­ność w ten sam sposób). Najlepiej, by doszło do niej przed imple­men­tacją, a w zasadzie przed back­log refile­ment (groom­ing) / sprint plan­ning — żeby dobrze je wycenić ;) Choć moż­na i o tym pomyśleć jako o nieusta­ją­cym pro­ce­sie, gdzie każdy bierze odpowiedzial­ność za zrozu­mie­nie i dostar­cze­nie poszuki­wanego rozwiąza­nia.

To nie musi być spotkanie

Choć częs­to właśnie spotkanie okaże się najlep­szym rozwiązaniem. Cza­sa­mi wystar­czy zaan­gażowanie devel­op­erów w pisanie US, albo “obow­iązek” zadawa­nia pytań w narzędz­iu do ich prze­chowywa­nia. Wyda­je mi się, że spotkanie będzie dzi­ałało fajnie jako pokazanie tech­ni­ki, zwróce­nie uwa­gi, na to co każ­da ze stron ma na myśli / jak rozu­mie poszczególne funkcjon­al­noś­ci. Gdy wspól­nie będziecie rozu­mieli aplikac­je tak samo, może okazać się, że spotka­nia same w sobie nie są już potrzeb­ne, bo i bez nich dochodzi­cie do tego poziomu zrozu­mienia.

Jak moż­na przeprowadz­ić takie spotkanie?

Prze­chodząc przez Acep­tance Cri­te­ria, czy po pros­tu funkcjon­al­ność, zas­tanow­ić się co to właś­ci­wie znaczy.

Coś co uwiel­bi­am, czyli pytanie DLACZEGO jest chy­ba tym, na które BA powinien odpowiedzieć na samym początku. Dlaczego dana funkcjon­al­ność jest potrzeb­na? Co za sobą niesie? Co z nią zro­bi klient? Czy są jakieś inne funkcjon­al­noś­ci, które ją bloku­ją? Jak wyglą­da­ją maki­ety?

Z mojego devel­op­er­skiego punk­tu widzenia, warto więc prze­jść sobie w głowie po tym, co już jest zaim­ple­men­towane, po auto­ryza­cji jaka może być wyma­gana. Warto pomyśleć o zasadach, które już są w aplikacji (np. wal­i­dac­je, obsłu­ga błędów itp.) i dopy­ty­wać. Przek­likać się przez maki­ety, popa­trzeć, czy nie ma tam jak­iś nowych ele­men­tów, których jeszcze w aplikacji nie mamy i nie wiemy jak je obsługi­wać ;)

Tester zaś powinien pomyśleć o środowisku, użytkown­ikach, danych testowych, mokowa­niu funkcjon­al­noś­ci. O ścieżkach, które użytkown­ik może dzię­ki tej funkcjon­al­noś­ci prze­jść.

Na koniec warto podzielić się pracą, bo ktoś to będzie musi­ał spisać ;)  I znowu każdy z trzech przy­jaciół powinien spisać również dodatkowe infor­ma­c­je, jakie wyniósł. Może pojaw­iły się jakieś dodatkowe pyta­nia związane z funkcjon­al­noś­cią (BA), imple­men­tacją czy testowaniem? Może zadanie wyma­ga jak­iś dodatkowych mech­a­nizmów czy blil­iotek, a może mock­ów czy danych testowych? … Jak widzi­cie, oprócz sce­nar­iuszy BDD,  zbier­amy więc potenc­jalne zada­nia.

Na własnej skórze

No właśnie, jak sama wspom­ni­ałam, wdrożyliśmy takie pod­jeś­cie w naszym zes­pole. I jak? Fak­ty­cznie przyśpieszyło to naszą pracę. Co więcej, myślę, że każde takie spotkanie wpyłwa też na wza­jemne zrozu­mie­nie się w zes­pole. Uwspól­ni­amy rozu­mie­nie prob­lemów, zbier­amy wspól­ny słown­ik, jaśniej komu­niku­je­my, o co nam chodzi, czy śmielej zada­je­my pyta­nia. Z małej his­to­ryj­ki, powstało,jak się okaza­ło sporo sce­nar­iuszy, a ja sama miałam w note­sie 3 rzeczy, na które bym nie wpadła czy­ta­jąc poprzed­ni opis zada­nia. W rezulta­cie, fak­ty­cznie mieliśmy wszys­tkie sce­nar­iusze testowe przed, co powodu­je, że przenosze­nie ich na kod, czy testy jest po pros­tu o wiele bardziej pewne. Wiem, że w przy­pad­ku mojego zespołu jest to narzędzie, z którego będę chci­ała korzys­tać. I jak widzi­cie, również rekomen­dować go innym.

Więcej o Three Ami­gos poczyta­cie tutaj: 
Thee Ami­gos in Agile Team

Intro­duc­ing the Three Ami­gos

Three Ami­gos Meet­ing – Agree the tests before devel­op­ment starts

  •  
  •  
  •  
  •  
  •