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

By 21 marca 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

  •  
  •  
  •  
  •  
  •  
  • Paweł Domańs­ki

    Zawsze mówimy o współpra­cy między devel­op­era­mi, pro­gramis­ta­mi i użytkown­ikiem.
    Dlaczego nie ma nic mowy o dzi­ałach wspier­a­ją­cych waszą pracę? Gdzie dzi­ały utrzy­ma­ni­ain­fra­struk­tu­ry, admin­is­tra­torzy czy zwykły HelpDesk, który ma znaczą­cy wpływ na całosć, także na waszą pracę. Ja bym pow­ięk­szył to o wszys­t­kich w IT. Z punk­tu widzenia devel­opera, który uczest­niczy tylko w fazie budowa­nia nie bard­zo obchodzi albo nie myśli co będzie później z jego pro­duk­tem. Czy pro­dukt jest przy­dat­ny, czy dzi­ała w sposób opty­mal­ny. Ja na codzień borykam się z tą drugą częś­cią i muszę z przykroś­cią powiedzieć, że w dużej częś­ci przy­pad­ków “devel­op­er” to taki ludek który jest oder­wany od rzeczy­wis­toś­ci. Wrzu­ca kod na kole­jne środowisko i się zmy­wa (niekiedy na dłu­gi urlop) a ty człowieczku wal­cz na pier­wszej lini­ii fron­tu z tym co CI zostało. Bez doku­men­tacji bez wspar­cia, bez szans na wygraną.
    Tak zgadzam się, roz­maw­ia­jmy ze sobą komu­niku­jmy się zadawa­jmy pyta­nia ale wszyscy razem.

    • Tem­at jak najbardziej słuszny i zasługu­ją­cy na kole­jny wpis. Częs­to wyglą­da to tak, że sama struk­tu­ra orga­ni­za­cji budu­je trochę ścianę między devel­op­era­mi i utrzy­maniem. I potem pisze­my do siebie te maile, i czekamy kil­ka dni na testową bazę danych, a feed­back od użytkown­i­ka nie zawsze dociera do devel­opera. Z drugiej strony są też orga­ni­za­c­je, w których za Opsy odpowia­da devel­op­er, nie ma do tego osob­ne­go tea­mu, a pomiędzy użytkown­ikiem a prod­uct Ownerem jest tylko jed­na oso­ba w postaci powiedzmy Key Accoun­ta. Jest więc róznie, a pewnie są i sytu­acje, gdzie Devel­op­erzy zwycza­jnie nie dba­ją o to, co będzie potem. Dzię­ki za pomysł na wpis, dopisu­je­my do listy tem­atów.

      • Paweł Domańs­ki

        Chęt­nie też podzielę się włas­nym punk­tem widzenia jako utrzy­manie.

  • paw

    Literówka we wpisie “blil­iotek”