- Czym jest Refinement Backlogu Produktu? — 27/11/2024
- Czym jest burndown chart? — 22/11/2024
- Czym jest Retrospektywa Sprintu? — 18/11/2024
Product Owner, Product Backlog, Przyrost może być tylko jeden
Kto by pomyślał, że słynny cytat z filmu Nieśmiertelny (ang. Highlander) dotyczy Product Ownera w Scrum. Jest jeden Produkt, który dostarcza Zespół Developerski, lub kilka Zespołów Developerskich. Zarządza tym Produktem jedna osoba, która jest jego właścicielem, stąd nazwa Product Owner (Właściciel Produktu). Product Owner utrzymuje uporządkowaną listę rzeczy do zrobienia w tym Produkcie, Product Backlog. Przynajmniej raz w Sprincie powinien zostać dostarczony jeden, przetestowany, użyteczny, potencjalnie gotowy do wdrożenia (zgodny z Definition of Done) Przyrost Produktu.
Wszystkie te zasady mają bardzo konkretny sens i przeznaczenie.
Product Owner — może być tylko jeden
Product Owner jest jedną, jedyną osobą odpowiedzialną za maksymalizację wartości Produktu. Robi to poprzez odpowiednie uporzadkowanie Product Backlog, tak, żeby na górze tej listy zawsze znajdowały się rzeczy najważniejsze, chyba, że inne czynniki porządkowania mu na to nie pozwolą.
Właściciel Produktu to pojedyncza osoba, nie komitet. Właściciel Produktu może reprezentować interesy grupy osób, lecz osoby chcące zmienić priorytet elementu Backlogu Produktu, muszą zwrócić się do Właściciela Produktu. [Scrum Guide 2017]
Dlaczego to jest jedna konkretna osoba a nie komitet? W każdej organizacji jest tak, że wielu interesariuszy Produktu będzie miało swoje potrzeby i oczekiwania co do Produktu i ktoś musi arbitralnie podejmować decyzje. Zespół Developerski pracuje bardzo szybko i często może odkrywać w swojej pracy rzeczy, o które wcześniej nie pytali. Dlatego potrzebny jest jeden punkt kontaktu, żeby zdobyć informacje. Product Owner oczywiście nie musi znać wszystkich szczegółów, ale będzie potrafił wskazać właściwą osobę. Czekanie na decyzje płynące z komitetów sterujących powoduje przestoje albo pracę na mniej wartościowych elementach.
When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committee as large as possible — never less than five. [Simple Sabotage Field Manual, Office of Strategic Services (OSS), 1944]
Próba (a widziałem to w praktyce) posiadania więcej niż jednego Product Ownera kończy się zawsze konfliktami i walką o “zasoby”. Ciężko też jest utrzymać spójność Produktu. Może się okazać, że bardziej żółte ikony albo zaokrąglone rogi staną się tak samo ważne jak umożliwienie zawarcia umowy z klientem. Bo przecież ten drugi Product Owner też musi coś dostać. Planowanie takich Sprintów zwykle skutkuje kilkoma Celami Sprintów, a Sprint kończy się dostarczeniam niespójnych elementów Product Backlog. łatwo sobie wyobrazić, że Sprint review wygląda wtedy jak dziwny status i tak w sumie nie wiadomo co osiągnęliśmy. A do kogo iść jeśli okaże się, że trzeba renegocjować zakres Sprintu, bo wszystko się nie zmieści?
Jeden Product Owner łatwiej wyznaczy Cel Sprintu i spójny z nim zakres, dzięki czemu Zespół Developerski łatwiej skupi się na dostarczeniu konkretnych efektów.
Product Owner jest odpowiedzialny w sensie accountability, więc nie musi samodzielnie wykonywać swojej pracy w kontekście pracy z Product Backlog, ale nadal pozostaje odpowiedzialny za zawartość i porządek Product Backlog.
Żeby Product Owner mógł prawidłowo działać w Scrum musi być odpowiednio umocowany w organizacji, a dokładniej odpowiedzialność za produkt i budżet powinna być do niego/niej oddelegowana w pełni.
Podsumowując, jeden Product Owner daje nam szybsze podejmowanie decyzji co do zakresu, szybsze zdobywanie informacji. W sumie w ten sposób upraszczamy podejmowanie decyzji i komunikację.
Product Backlog — może być tylko jeden
Product Backlog to lista wszystkich rzeczy, które chcemy mieć w Produkcie, całej pracy do wykonania. Obojętnie czy jest to funkcjonalność, wymaganie, ulepszenie, defekt do naprawy, zadanie techniczne; dla nas jest to po prostu element Product Backlog i podlega porządkowi. Product Backlog to lista jednowymiarowa, więc elementy znajdują się jeden pod drugim i dwa elementy nie mogą mieć tego samego miejsca na liście. Zespół Developerski bierze pracę zawsze z góry Product Backlog. Odpowiedzialnością Product Ownera jest takie ułożenie Product Backlog, żeby na górze zawsze były rzeczy najbardziej wartościowe. Większa ilość zespołów nic tutaj nie zmienia. O technikach pracy z Product Backlog i określaniu porządku można napisać odrębny post, a właściwie całą serię.
Często nad jednym produktem pracuje wspólnie kilka Zespołów Scrumowych. Także w takiej sytuacji do opisywania przyszłej pracy nad produktem używany jest jeden Backlog Produktu. [Scrum Guide 2017]
Posiadanie jednej, jednowymiarowej listy upraszcza określanie co jest najbardziej wartościowe. Jeden Product Backlog to również wymuszenie podejmowania decyzji co do każdego elementu, ponieważ dwa elementy nie mogą być równie ważne, co często zdarza się kiedy rozmawiamy wyłącznie o priorytetach.
Jeden Product Backlog stanowi jedynie miejsce pobierania pracy. Zespół Developerski wie jakie są plany na przyszłość i co wymaga pielęgnacji. Wiadomo ile elementów zostało już zrobione i łatwo podsumować co jeszcze mamy do zrobienia. Szukanie informacji też jest proste, bo zawsze wystarczy poszukać w jednym miejscu.
Łatwo można podsumować sumę oszacowań i sprawdzić ile jeszcze Sprintów, a tym samym budżetu potrzebujemy, żeby zrealizować plany. Jeśli na Product Backlog odłożymy Velocity Zespołu, to w prosty sposób uzyskamy roadmapę rozwoju produktu.
Dowolne zmiany na jednym Product Backlog nie umkną osobom zainteresowanym.
Podsumowując, jeden Product Backlog zapewnia przejrzystość planów, przejrzystość informacji umożliwia sprawdzanie i dostosowywanie.
Przyrost Produktu — może być tylko jeden
Przynajmniej raz na koniec Sprintu Zespół Developerski dostarcza Przyrost Produktu zgodny z Definition of Done. Przyrost jest zintegrowany z poprzednimi Przyrostami, używalny i gotowy do wydania. Dlaczego to takie ważne? Jak wiadomo z Zasad Agile, tylko działające oprogramowanie jest podstawową miarą postępu. Wiele problemów i przyczyn porażek w budowaniu produktów informatycznych bierze się z późnej integracji oprogramowania. Kiedy nie mamy jednej, zintegrowanej wersji, trudno jest powiedzieć co jest naprawdę ukończone a co nie.
Jeden ukończony Przyrost Produktu umożliwia przejrzystość postępu i możliwość adaptacji na podstawie feedbacku.
Skalowanie Scrum
A co ze skalowaniem? Czy te same zasady obowiązują, kiedy Produkt dostarcza więcej Zespołów Deweloperskich?
Skalowanie Scrum nic nie zmienia, Scaled Scrum i still Scrum. Można nawet powiedzieć, że jeden Product Owner, jeden Product Backlog i jeden Przyrost są jeszcze bardziej ważne, żeby utrzymać przejrzystość podejmowanych decyzji i postępów pracy.
Działające oprogramowanie jest podstawową miarą postępu.[12 Zasad Agile Manifesto]
Trackbacks/Pingbacks