Współpraca Product Ownera z Testerami

Na pierwszy rzut oka wydawałoby się, że Product Owner może się skupić na roadmapie, pielęgnowaniu backlogu produktu i pracy z interesariuszami mając obok siebie zespół wytwórczy, który cyklicznie dostarcza wartości biznesowe.

I teraz, żeby PO mógł się skupić na „produktowych” obszarach, dobrze by było, aby „maszyna dostarczająca wartość” była odpowiednio naoliwiona. Dzisiaj przyjrzymy się kilku niuansom, o których istnieniu każdy produktowiec powinien wiedzieć.

1. Scrum a rola testera (wprowadzenie)
2. Zacznijmy od początku…
3. Backlog Refinement a Testerzy
4. Swarming
5. Definition of Done
6. Ścieżka informacji zwrotnej
7. Automatyzujmy co się da
8. Współpraca w praktyce
9. Ale… po co mi to wszystko?

Scrum a rola testera (wprowadzenie)

Prowadząc warsztaty otwarte lub dedykowane dla firm, w zespołach, które zaczynają przygodę ze zwinnością często pojawia się wątpliwość, że przecież w Scrumie jest Product Owner, jest Scrum Master i jest zespół developerski. A gdzie miejsce dla Analityka, Testera lub (UX/UI) Designera?

Autorom Scruma przyświecała niegłupia idea, żeby nie wyróżniać w zespole ról – każda osoba niezbędna w procesie dostarczania wartości jest tak samo ważna. Intencja była dobra, choć w życiu jak to w życiu często jest inaczej i każdy w zespole wie, że Piotrek zajmuje się testami, Paulina tworzy design, a Marta pisze scenariusze testowe.

W Scrum Guide znajdziemy:

Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy.

A zatem jest tam miejsce dla: Testera, Designera, Analityka – o ile te kompetencje są niezbędne do dostarczenia biznesowej wartości.

Zacznijmy od początku…

Gdy przyjrzymy się z jakich elementów składa się proces wytwarzania oprogramowania, to mamy (w kolejności):

• Analiza
• Projektowanie
• Wytwarzanie
• Testowanie
• Wdrożenie
• Utrzymanie

Wydawałoby się, że testerów wystarczy zaangażować w późniejszym etapie tworzenia produktu, że nie są potrzebni od samego początku.

Nic bardziej mylnego. Testerzy powinni być zaangażowani od pierwszego dnia i już za moment zobaczymy jak to wszystko zorganizować, żeby to miało sens.

Backlog Refinement a Testerzy

Czasami pojawia się pokusa, żeby przy pielęgnowaniu backlogu produktu poza Product Ownerem pojawił się tylko lider techniczny lub najbardziej doświadczony programista. No bo jak to całym zespołem rozmawiać o wymaganiach. Załóżmy, że spotkanie trwa godzinę, pomnóżmy to przez 10 osób w zespole, stawki godzinowe i wyjdzie nam, że to spotkanie jest całkiem drogie. I bardzo łatwo wpadamy tutaj w pułapkę „pozornych oszczędności” (podobnie jak to często bywa w przypadku pair-programming’u).

Sytuacja jest trochę lepsza, gdy w pielęgnowaniu backlogu produktu biorą udział wszyscy programiści z danego zespołu. Dlaczego? Z perspektywy osoby zarządzającej produktem chcielibyśmy móc skonfrontować pomysły i potrzeby biznesowe z realnością wykonania, czasochłonnością, potencjalnymi konsekwencjami. Z drugiej strony, zespół musi mieć czas, żeby przyswoić wymagania biznesowe i móc je przemyśleć. Czasem do pewnych zagadnień wraca się po kilku dniach z nowymi wnioskami albo wiedzą. Lepiej, żeby te pytania i wątpliwości pojawiły się podczas Backlog Refinementu, niż później, gdy dana osoba pracuje już przed komputerem i Product Ownera nie ma w pobliżu.

Patrząc z perspektywy procesu poznawania kontekstu biznesowego i wymagań, dlaczego podczas Backlog Refinementu mielibyśmy pominąć testerów? Tak samo jak programiści muszą przyswoić wymagania, tak samo testerzy muszą się zastanowić na czym dokładnie będzie polegała ich praca, co da się zautomatyzować i na jakie „typowe błędy” się przygotować. A przecież warto by było przy okazji oszacować pracochłonność potrzebną przy testach.

Tip #1: Angażuj cały zespół (wraz testerami) już na etapie definiowania wymagań i rozwiązań

Swarming

Ile osób jest w stanie pracować nad jedną funkcjonalnością w tym samym czasie? Albo, pytając inaczej: gdyby cały zespół miał pracować tylko i wyłącznie nad jedną funkcjonalnością – to jak rozdzielić „pracę”, aby każda osoba w zespole mogła pomóc? W project managemencie znane jest pojęcie War room, czyli po prostu wszystkie ręce na stół. Gdyby się bliżej przyjrzeć temu co jest do zrobienia, to może okazać się, że nawet i 10-12 osób jest w stanie pracować nad jedną funkcjonalnością, np.:

• Programowanie
• Programowanie w parach (pair programming)
• Przygotowanie scenariuszy testowych (albo ich weryfikacja)
• Może jest potrzebna upewnić się lub zweryfikować pewne niejasności z Product Ownerem?
• A co z przygotowaniem środowiska testowego?
• Może można już napisać jakieś testy automatycznie?
• Warto na pewno by przejrzeć (z)realizowane zadanie z perspektywy Review i pokazywania danej funkcjonalności interesariuszom.

Zachęcam do przeprowadzenia takiego eksperymentu w zespole, bo to prowadzi nas to kolejnego aspektu (który zostanie poruszony w oddzielnym artykule), czyli T-shaped people. Pomysłem samego eksperymentu jest zakiełkowanie w zespole świadomości jak ważne jest wspieranie siebie nawzajem w codziennej pracy vs. postawa: „robię swoje i cała reszta mnie nie interesuje”. Ważne, żeby po eksperymencie był czas na chwilę refleksji dla całego zespołu lub żeby ten temat został omówiony podczas Retrospektywy.

Tip #2: Przeprowadź eksperyment ze „swarmingiem”, zwłaszcza gdy widzisz w zespole postawy: „robię swoje i cała reszta mnie nie interesuje”.

Definition of Done

Temat „Definition of Done” pojawia się (lub powinien się pojawić) wszędzie tam, gdzie widać kłopoty z jakością: cofane wdrożenia, błędy regresji, stres związany z nadchodzącym wdrożeniem. Pojawia się też tam, gdzie występuje rozdźwięk między „prawie skończonymi zadaniami”, a tym co tak naprawdę nadaje się do wdrożenia i do pokazania użytkownikom końcowym.

Czym jest Definition of Done? Najprościej mówiąc, jest to checklista określająca, kiedy dokładnie realizowane zadanie można uznać za wykonane.

Kilka przykładowych kryteriów:

• Wszystkie kryteria akceptacji zostały spełnione.
• Kod jest przejrzysty, odpowiednio sformatowany, napisany zgodnie ze standardami programowania.
• Kod przetestowany jednostkowo.
• Kod poddano analizie statycznej.

Kiedy ten temat już się pojawia i zespół rozważa wprowadzenie lub zmianę DoD, dlaczego by nie zaangażować tutaj także testerów, którzy stanowią ważny element układanki dbania o jakość.

Tip #3: Włącz testerów w rozmowy na temat Definition of Done

Ścieżka informacji zwrotnej

O tym jak kluczowa jest szybka ścieżka informacji zwrotnej można przeczytać w artykule: Potęga szybkiego feedbacku. Podstawowym pytaniem, który musi zadać sobie zespół, jest: Ile czasu mija od momentu, gdy programista skończył swoją pracę do momentu aż dowie się, czy to co zrobił jest zrobione poprawnie? Czy są to godziny, dni, tygodnie czy miesiące? Tak, w niektórych firmach nawet zdarzają się miesiące. Jeśli development i testy mamy mocno rozdzielone procesowo – trudno o skrócenie feedbacku, jakże ważnego w tej całej układance.

Tip #4: Dbaj o jak najkrótszą ścieżkę informacji zwrotnej.  (Więcej: Potęga szybkiego feedbacku)

Automatyzujmy co się da

Przychodząc do biura lub po prostu zaczynając dzień pracy, chcielibyśmy mieć jak najwięcej świętego spokoju, aby móc skupić się najważniejszych obszarach związanych z produktem. Bardzo łatwo popsuć sobie ten święty spokój poprzez:

• Brak informacji co robi zespół (muszę trzymać kciuki czy jestem pewny, że na koniec sprintu będzie oczekiwany efekt);
• Duży poziom stresu podczas wdrożeń;
• Błędy regresji stają się zauważalnym problemem.

Jednym ze sposobów na zwiększenie poziomu komfortu jest automatyzacja i wprowadzenie Continuous integration – częsta i regularna integracja bieżących zmian w kodzie do głównego repozytorium produktu, skutkująca każdorazową weryfikacją zmian, sprawdzeniem testów automatycznych i “zbudowaniem” aplikacji.

W jednym z projektów, który mogłem obserwować w jednej z organizacji, podwykonawca tak przygotował środowisko testowe, że:

• Aktualizacja trwała 1-2 dni,
• Na 6 stanowisk do testowania, każde miało inną konfigurację i do końca nie było wiadomo co można testować,
• Środowisko testowe się resetowało co jakiś czas i potrzebne było ok 30 minut, aby od nowa można było zacząć testować.

Dla kontrprzykładu, gdy jako Product Owner prowadziłem tworzenie pewnego produktu R&D, już na samym początku poukładaliśmy sobie następujące elementy:

• Pushowane zmiany w kodzie były automatycznie weryfikowanie podstawowymi testami;
• Gdy wszystko było ok, nowa wersja wdrażana była automatycznie na środowisku testowym;
• Gdy i ten etap zakończył się sukcesem, na komunikator Slack szła informacja, że środowisko testowe zostało zaktualizowane;
• Dodatkowo, codziennie o 5 rano odpalane były testy wydajnościowe i integracyjne a ich wynik również lądował na Slacku.

W ten prosty sposób przychodząc rano do biura miałem pewność, że mogę spokojnie iść na warsztaty z interesariuszami oraz kluczowymi użytkownikami i po prostu skupić się na „produktowej” pracy.

Tip #5: Nie bójmy się Continuous Integration, unit testów czy jakichkolwiek automatycznych form dbania o jakość. I nawet jeśli nie mamy dużego budżetu, zdecydowanie nie powinniśmy wykreślać tej pozycji z listy „must-have”. W takiej sytuacji lepiej się zastanowić: co można zautomatyzować i co będzie najbardziej wartościowe poświęcając np. tydzień (lub dowolną inną jednostkę czasu).

Współpraca w praktyce

Na koniec prześledźmy jeszcze kluczowe punkty styku współpracy testerów i Product Ownera:

1. Sprint Planning

Testerzy aktywnie uczestniczą w spotkaniu planując swoją prace i to jak mogą wesprzeć zespół w pracach wytwórczych. (Patrz: krótka ścieżka informacji zwrotnej, swarming).

2. Daily Standup

Product Ownera na tym spotkaniu nie ma, ale dobrze by było, gdyby testerzy przynajmniej biernie uczestniczyli w Daily Standupie. Cel jest taki, aby byli oni na bieżąco ze wszystkimi ważnymi bieżącymi pracami po to, aby móc jeszcze lepiej wesprzeć cały zespół w dostarczeniu wartości biznesowej na koniec sprintu.

3. Backlog Refinement

Aktywne uczestnictwo testerów w spotkaniu, gdzie z jednej strony mogą zapoznać się z wymaganiami, z drugiej, mogą być ważnym głosem challangującym wymagania biznesowe.

4. Sprint Review

• Testerzy prezentują raport z wynikami testów wykonanych podczas sprintu (zarówno testów manualnych jak i automatycznych). Może to być spis wykonanych testów wraz z wynikami.
• Testerzy mogą zaprezentować rekomendacje lub obawy co do
  obecnego procesu jakości.

5. Proces jakości

Dobrze by było, aby testerzy wsparli zespół oraz PO w zakresie Definition of Done, monitorowali proces jakości w zespole, monitorowali poziom błędów powdrożeniowych (nowych i błędów regresji), stanowili ważny głos w rozmowie czy proces utrzymania jakości nie powinien być bardziej dojrzały.

6. Zespół

Testerzy jako część zespołu znacznie lepiej się sprawdzi niż gdybyśmy mieli oddzielne zespoły: developerski i QA.

Ale… po co mi to wszystko?

Czy nie powinno być tak, że to Scrum Master „pilnuje” jak działa proces zwinny w zespole?

Teoretycznie tak, ale…

• nie zawsze będziemy mieli do dyspozycji Scrum Mastera,
• nie zawsze Scrum Master jest wystarczająco doświadczony, żeby zaobserwować, że w danym obszarze jest problem,
• czasem Scrum Master skupia się na innych elementach procesu Scrumowego.

Uważam, że z perspektywy Product Ownera warto po prostu znać niuanse współpracy z zespołem wytwórczym, a w szczególności testerami. Jest to niezwykle istotne, żeby świadomie patrzeć na otaczającą nas rzeczywistość i móc trafnie ocenić na ile dojrzale poukładane są wszystkie elementy dookoła.

Czasem te drobiazgi potrafią przynieść nam korzyści bez wprowadzania „rewolucji”, a powyższe przykłady to po prostu dobre praktyki, o które warto zadbać.