Product Owner nie pozwala testować? To może przynajmniej pozwala grać w piłkarzyki. Przyjrzyjmy się temu.

Jeżeli jesteś Product Ownerem, nie bierz tego personalnie. Jeżeli jesteś programistą/ką, testerem/ką lub masz inną rolę w zespole developerskim i Product Owner “zabrania” Ci czegoś, to możesz wziąć. W końcu nie będzie PO mówił jak żyć.

Jeżeli jako zespół dostarczacie odpowiedniej jakości oprogramowanie, z naciskiem na “dostarczacie” a Wasi końcowi użytkownicy wysyłają maile pochwalne ciesząc się z dostarczanej usługi czy softu, nie jest to prawdopodobnie post dla Ciebie.

Produktokierownik

Product Owner NIE jest kierownikiem projektu, przełożonym i nie musi się znać na software developmencie. Nazwa tej roli nie jest przypadkowa. Właściciel produktu. Nie właściciel kodu, nie właściciel jakości, nie architekt systemu, nie DevOps inżynier, nie analityk biznesowy, ani nie UX designer, a nawet nie Scrum Master (co nie znaczy, że osoba nie może pełnić różnych ról, jednak kiedy zakłada odpowiednią czapeczkę, ma być w odpowiedniej roli).

Oznacza to nie mniej, nie więcej, że osoba ta odpowiada za produkt, w szczególe zaś odpowiada za to, co mamy w jakiej kolejności robić, aby kolejne klocki produktu otrzymywać. Przychodzi z wymaganiami lub zarysami wymagań. Jeżeli jest to zarys wymagań to jest odpowiedzialny za to, by zgromadzić “team” i rozwałkować je do takiej postaci cienkiego ciasta naleśnikowego by zespół mógł napełnić go farszem a wraz ze wdrożeniem upiec i dostarczyć do klienta/użytkownika. W taki sposób, aby ci klienci chcieli za to zapłacić a soft zaspokajał ich najpotrzebniejsze potrzeby.

Wymagania – Definition of Ready

Gdy wymagania są rozwałkowane do postaci zabrania na sprint, jego rolą jest priorytetyzacja. Priorytetyzacja nie polega na ponapychaniu tego rozwałkowanego ciasta w kulę. Priorytetyzacja to poukładanie naleśników na tacy tak, aby się nie zlepiały i każdy mógł obrabiać swojego.

Wypada tu od razu wspomnieć INVEST, pomoże nam sprawdzić, czy story jest ok.

Independent – story są od siebie niezależne (a nawet jak są zależności to potrafimy sobie z nimi poradzić) – ogólnie chodzi w tym o to, aby nie robić zazębiających się kawałków jednocześnie, lub nie zbudować łańcucha na sprint A→ B→ C→ D (aby zrobić D, musimy zrobić ABC)

Negotiable – story podlega negocjacjom, w skrócie oznacza to, że na przykład, nie zawiera szczegółów implementacyjnych, że jest otwarte na podważanie i zadawanie pytań – tak właśnie rodzą się kryteria akceptacyjne, masa jest uformowana, ale wraz z zespołem nadajemy jej kształt końcowy. To ma też chronić przed featurami w stylu “chce zielony przycisk” – czyli twardo zdefiniowane coś bez celu. Zespół ma rozumieć cel, wtedy znajdzie rozwiązanie.

Valuable – klienci będą mogli zjeść naleśnika

Estimable – na tyle jasne story, żeby je móc wycenić w takiej jednostce według której stwierdzimy czy zmieści nam się w sprincie (niekoniecznie w mandaysach). Inaczej mówiąc, wiemy gdzie się zaczyna i gdzie kończy i wiemy kiedy skończymy. Zakres jest znany i nie pływa, więc przybliżony czas też jest znany. Czym wyższe punkty ciągu Fibonnaciego w estymatach tym rośnie ryzyko tego, że zakres jest nam bardziej nieznany, niż znany.

Small – czym mniejsze tym lepsze, łatwiej się estymuje, developuje i testuje, mieści się w sprincie

Testable – możemy spróbować naleśnika i jak dobry to wysłać do klienta, mamy testy na każdym poziomie i wiemy, że naleśnik się nie rozsypie przy pierwszym gryzie. Znamy też kryteria według których sprawdzimy ukończenie (testy akceptacyjne)

I to jest odpowiedzialność Product Ownera w materii wymagań. Dąży on do tego, aby story stało się story. Zespół ustala kontrakt z Product Ownerem jakie ma być story, co ma zawierać – nazywamy to Definition of Ready. INVEST wpisuje się w DoR. Zespół na przykład może wymagać gotowych makiet UX pod GUI, lub kryteriów akceptacyjnych itd. DoR ma zapewnić spokój i komfort pracy w zespole na sprint. Nie oznacza to, że podczas sprintu nie możemy rozmawiać 😅 Nie chcemy skrajności. Skrajności są na przykład wtedy gdy zespół ma rozpisane story dwuzdaniowo i “wydaje się” wszystkim, że wiadomo, o co chodzi, a później przez cały sprint trwają debaty o co chodziło w tych dwóch zdaniach, bo każdy rozumie je inaczej, a na końcu PO wraca do biznesu, bo sam się w tym pogubił. I to jest OK.

Ale jest OK jak dzieje się w takiej skali PRZED sprintem (refinment, warsztaty itp.)

Z racji tego, że jest to kontrakt (Definition of Ready) pomiędzy zespołem a Product Ownerem, szanujemy go obopólnie. Ważne jest jednak to, że współpracujemy, aby ten kontrakt był spełniony. Co oznacza, że rozmawiamy o alternatywach, zadajemy pytania i odkrywamy niewiadome. Pomagamy sobie.

Biznes Wie Lepiej

Ok. Jest tu jedna pułapka o której chcę wspomnieć. Zweryfikuj sobie u siebie czy możesz w nią wpaść. Czy ja jako Product Owner mogę faktycznie podejmować decyzje o kierunku biznesowym aplikacji? Nazywam to syndromem Product Ownera Proxy. Będąc w takiej roli, przynosi nam najmniejszą wartość, bo po każdą decyzję musi iść do góry i zdarza się, że kolor przycisku też musi zostać uchwalony przy udziale najwyżej zjednoczonej rady nadzorczej. Warto sobie uświadomić taką sytuację, jeżeli nas dotyczy. Nie jest to temat przegrany. Wskazując konkretne blokery od strony zespołu, możemy spróbować powalczyć wspierając Product Ownera o jego autonomię. W końcu jesteśmy jednym teamem. Czym bliżej biznesu tym lepiej. W zasadzie powinienem wspomnieć o możliwości bycia Product Ownerem przez osobę techniczną? Tj. Product Owner Software Developer? Jak to widzicie? 😉

Aha. I wcale biznes (ten taki samozwańczy, a nie użytkownik) zawsze nie wie lepiej (prezes naszego klubu w szczególności może nie wiedzieć lepiej). Bo gdy już rozmawiamy z prawdziwym biznesem, tj. omijamy wszystkie proxy to w końcu dowiemy się CO i DLACZEGO. I, że przyciski mają być duże i czerwone, bo na hali jest dużo pyłu jak zwalniana jest ręka robota na linii produkcyjnej (czy coś w tym stylu)

ProductOwnerDrivenDevelopment

Za nami ta łatwiejsza część. Czy podczas wyceny zadania spotkaliście się z pytaniem:

“Ok, z testami 13 story pointów, a ile bez testów”?

I teraz ważna jest tutaj reakcja zespołu. Najgorsza moim zdaniem jaka może być to faktyczne odpowiedzenie na to pytanie. To jest pytanie pułapka. Jak zaczynamy na nie odpowiadać, to w zasadzie sami dopuszczamy, że można bez. A skoro można BEZ to po co Z? Chirurg chyba też mógłby nie umyć rąk, nie ubrać fartucha i używać noża kuchennego do rozcinania nam brzucha. Później w sumie też mógłby nas zszyć na maszynie do szycia i obandażować taśmą klejącą (tą srebrną, bo ona jest najlepsza!). Feature dowieziony. Tylko czy pacjent żyje? A może należy zadać pytanie, jak długo pożyje?

Nie są mi niestety rzadkie usłyszane stwierdzenia “nie piszemy testów, bo nie ma czasu”. Komentuje to pytaniem, kto miałby dać zespołowi ten czas?

Smutniejsze jest, też tak bywa, że jest to taka cicha gra obu stron (a przecież to nie są strony!)

My nie umiemy pisać testów, albo nie wierzymy w nie, albo … (uzupełnij swoją wymówkę), a Product Owner w sumie ich nie potrzebuje. Win-Win! 😉

Ale żeby nie było. Można nie pisać testów i będzie szybciej, może nawet będzie działać. Tym samym nasz greenfield po dwóch sprintach, może trzech, będzie legacy i będziemy się bali wprowadzać tam zmiany (lub wyceny 1 punktowe staną się nagle 13sto punktowymi), ryzyko wystąpienia regresji będzie rosło, tak samo jak czas na jej ewentualne testowanie.

I my wiemy, że tak będzie. Wydaje się, że idziemy na małe skróty i jeszcze zarabiamy pieniążki, bo jest szybciej a przecież za rok to będziemy w innej firmie 😉 Dobrze nam się liczy koszt developmentu, ale trudniej koszt utrzymania czy błędów – czyli pracy która wraca. Może dlatego, że przychodzi ona pod płaszczykiem “zmiany”? Czyli jako feature?

DomainDrivenPoDevelopment

Czy programiści mogą myśleć jak Product Ownerzy? Oczywiście. Wręcz pożądane.

A czy Product Ownerzy mogą myśleć jak programiści? Pewnie mogą…. ALE

Spotkałem się z sytuacją w którym PO był w takiej roli kierownika i tak “czuł” bycie technicznym, że rozmawiał z zespołem jakiej bazy mają użyć, czy jakie mają być kolumny i relacje itp. etc. “Czuł”, nie znaczy, że miał kompetencje. W tym przypadku ich nie miał, ale chciał być tak blisko developmentu, że troszkę przesadził. Product Owner w roli kierownika sterujący architekturą (nie będąc technicznym) może narobić bigosu. Senior pewnie się obroni przed jego “autorytetem”, ale z racji statusu kierownika część zespołu może mieć z tym problem. Proponuję więc aby będąc w czapce PO skupić się na biznesie a zespołowi pozostawić szczegóły implementacyjne i rozwiązania. Nie skaczmy na główkę do pustego basenu.

Jak to zrobić?

Ok, więc odkryliśmy co się dzieje i chcemy to zmienić. Z mojego doświadczenia punktem podstawowym jest szczera rozmowa zespołu z Product Ownerem. W jednej z organizacji w której byłem zrobiliśmy prezentację dla “biznesu” aby pokazać, jak wygląda nasz cały proces. Czyli taki diagram z bloczków i strzałek (jak linia produkcyjna) od wymagania do wdrożenia poprzez wszystkie “dziwadła” których nietechniczne osoby nie rozumieją przed. Rozpuszczajmy mit, że nasz feature to tylko napisanie 30 linijek kodu. Pokażmy i wytłumaczmy jakie testy trzeba wykonać, na jakich warstwach, jaki proces nasz kod musi przejść, powiedzmy o CI/CD. Od początku do końca. Mówmy o zaletach tej automatyzacji, podkreślając jaką mamy pewność i komfort przy modyfikacji (zmianie) wymagań czy nowym featurze. Zróbmy ćwiczenie myślowe “a gdyby tutaj nie było testu … to, co mogłoby się stać w tej iteracji … za 20 sprintów”, “a gdyby teraz nie było automatycznego deploya …”

Pomijam tutaj wiele istotnych części jak Code Review, czy sam design architektury który jest bardzo ważny. Intencją moją jest transparencja i zwiększenie świadomości u Product Ownerów, że development to nie tylko kilka linijek kodu który robi funkcjonalność, tylko jeszcze kilkadziesiąt dookoła.

Mówmy o rzeczach ważnych, co nam pomaga, a co przeszkadza, takich jak: niezależne i małe zadania, jasne story, cel wymagania, potrzeba klienta, kryteria akceptacyjne, o tym, że czas spalony na dokładną estymację można by przeznaczyć na development.

Naszym kontraktem z Product Ownerem i zespołem (etyka?) jest Definition of Done w które możemy wpisać nasze procesowe aktywności, aby kod mógł znaleźć się na produkcji.

NotMVP

Z drugiej strony wielokrotnie czułem trud Product Ownerów gdzie zespół robił overengineering. Klient miał potrzebę pragnienia i zamiast podać mu szklankę wody, zespół wysłał go na all-inclusive wakacje pod palmami w wersji premium. Tylko że to nie karta kredytowa zespołu 😉

Waste w postaci przekombinowanych rozwiązań, zbyt wypieszczonych decyzji technicznych “na przyszłość”. Elastyczność i generyczność ponad dostarczenie? NIE.

Dlatego uważam, że dyskusja na poziomie dwóch “skrajności” ale jednak w pełnym zrozumieniu dwóch perspektyw, doprowadzi nas do odpowiedniego konsensusu. Biznes pilnuje biznesu, chce szybko na proda, ma nowe pomysły, zna domenę, my pilnujemy biznesu, ale poprzez kod i jego jakość. Oczywiście w idealnym świecie developerzy na tyle kumają biznes, że są w stanie nawet pracować bez Product Ownera za plecami klientów … ale to już na innym blogu poczytasz 😉

Nice to Have

Nie wiem jak wyglądają szkolenia dla Product Ownerów, ale jak mnie kiedyś jeden zapytał czego mógłby się nauczyć to poleciłem poczytać o BDD/ATDD np. “Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing”.

Na koniec

Nie jestem tu od pozwalania, ale podpowiem, że Product Owner w kod raczej nie patrzy więc pisać testy można, refactor raczej też. Co najwyżej to mogę pozwolić wydłużyć sprint, jak się nie mieścicie w czasie …

Mam na myśli to, że nie róbmy problemów tam, gdzie ich nie ma (lub łatwo można jerozpuścić). Jeden zespół, jeden cel.

Chcesz się podzielić swoją historią z Product Ownerem albo współpracy z zespołem jako Product Owner? Daj znać w komentarzu.