Po co nam dobry Product Backlog?

W Scrumie za jakość odpowiada zespół deweloperski.

Dobre i złe strony równouprawnienia.

Własnie tak. Dobrze czytacie. Zespół. Nie manager. Nie Produkt Owner. Nie Scrum Master.Zespół deweloperski. Czas zdjąć koronę niewiniątek z tych na dnie łańcucha pokarmowego i przyjąć zarówno dobre i złe strony równouprawnienia.

Dobre?

• Decyzyjność. To zespół decyduje jak wykonane zostanie rozwiązanie i nikt nie ma prawa się w te decyzje wtrącać. Dzięki pracom Dana Pinka opisanym w jednym z moich poprzednich artykułów (klik) wiemy że jest to coś krytycznego dla naszej motywacji.
• Profesjonalizm. Zespół już nie jest tylko wykonawcą czyiś poleceń, tworzy autonomiczną samo-zarządzającą jednostkę. Mini firmę, która jako jedyna jest w stanie stworzyć inkrement.
• Szacunek. Jeżeli oba powyższe udało się osiągnąć szacunek pojawi się jako konsekwencja.

Złe?

• Za te wszystkie decyzje które od teraz podejmuje zespół trzeba wziąć odpowiedzialność. Co to znaczy? To znaczy że zespół chyli głowy jeżeli coś z jakością jest nie tak. To zespół mówi w jakim czasie da się to naprawić. To zespół dba o to żeby mieć możliwość zadbania o jakość i domaga się od Product Ownera i Scrum Mastera aby wypełniali swoje odpowiedzialności.

Jeżeli zespół nie podźwignie z ziemi tej odpowiedzialności innym trudno będzie pozostawić mu decyzyjność.

Warto więc Product Ownerowi ułatwić przekazanie decyzyjności pokazując się z jak najbardziej odpowiedzialnej strony i zadbać o dobry Product Backlog. Product Owner potrzebuje od zespołu informacji zwrotnej aby taki stworzyć. Zespół bez dobrego Product Backlogu nie stworzy właściwego inkrementu. Dzięki tej współpracy redukujemy złożoność i tak już skomplikowanego problemu tworzenia oprogramowania.

Product Backlog for Dummies

Co więc na temat Product Backlogu wiedzieć należy:

1. Jest to JEDYNE źródło

   informacji na temat tego co będzie robił zespół deweloperski. Trzymamy w nim WSZYSTKIE rzeczy do zrobienia. Tak, aby każdy mógł sprawdzić co będzie robione i co jest od czego ważniejsze (wiem wiem, nie wszystko interesuje wszystkich, dlatego dobry mechanizm filtrowania może się przydać).  

2. Trzymamy w nim porządek!

   To znaczy:

3. Jest SPRIORETYZOWANY

   Czyli elementy mają określoną kolejność, mam tu na myśli porządek zupełny: nie ma dwóch elementów na tym samym poziomie. Czemu tak? Bo tak jest prościej. Niewielkim wysiłkiem Product Ownera skracamy dyskusje, które mogłyby wybuchnąć pod jego nieobecność.  To w jakiej kolejności spod rąk zespołu będą wychodzić gotowe funkcje jest tak kluczowe, że warto aby było tak jasne i przejrzyste jak tylko się da.

4. Jest KRÓTKI

   Wydaje się sprzeczne, mamy tam trzymać tam wszystko co jest ważne i jednocześnie dbać o to żeby był krótki? Ta dyscyplina się opłaca. Zmusza nas do realnego planowania na rozsądny(tzn. rozsądnie krótki) okres czasu. Tak, żeby plan nam służył, a nie siedział w Backlogu i się kurzył. Na górze rzeczy drobne i dobrze rozpisane. Na dole duże i niedopracowane, ale te które chcemy nieustannie rewidować i uzupełniać bo są ważne. Na trzymanie mglistych planów, które może zrealizujemy a może o nich zapomnimy też warto mieć jakiś sposób. Jeden z fajniejszych, które widziałam to trzymanie ich wszystkich w ostatnim elemencie Product Backloga. W ten sposób nie przeszkadzają i jednocześnie o nich nie zapominimy.

5. Jest CZYTELNY

   Kolejny banał, nad którym naprawdę warto się pochylić. Z Backloga ma korzystać każdy zainteresowany produktem, szkoda marnować czas tych wszystkich osób. Szczególnie swój własny, zdarzyło wam się ślęczeć nad własnymi notatkami próbując je zrozumieć? A co dopiero osoby które ich nie tworzyły. Backlog jest dokumentem publicznym, służy wszystkim osobom zaangażowanym w tworzenie produktu. Jest narzędziem nieustannej komunikacji Product Ownera z resztą świata. Nieczytelny nie będzie używany. Drogi Product Ownerze, jeżeli nie dostajesz od zespołu tego o co prosisz, sprawdź czy jasno wyrażasz swoją prośbę (zanim zdążysz jasno wyrazić swoją opinię o produktywności zespołu…). Czytelny Backlog skoncentruje uwagę osób zaangażowanych w tworzenie produktu na kluczowych dla niego rzeczach. Każdy z deweloperów podejmuje dziesiątki decyzji w ciągu dnia: Jak podzielić funkcjonalności? Gdzie umieścić przycisk? Jak zoorganizować informacje? Jak nazwać zbiór testów? Do kogo dzisiaj zadzwonić itd. Każda z tych decyzji może wspierać obecny plan rozwoju produktu lub się z nim mijać. Znajomość i zrozumienie planu jest podstawą tego aby mu służyła.

6. Jest DOSTĘPNY

   Najgorsza wersja nieczytelności to niedostępność. Backlog ma być tam gdzie większość osób się go spodziewa. Tam gdzie się przyzwyczaili że jest. A jeżeli się jeszcze nie przyzwyczaili, to tam gdzie się o niego będą potykać (jak trzeba to dosłownie). Ludzie nie pytają gdzie jest? To albo jest tam gdzie trzeba, albo z niego nie korzystają. Jak nie korzystają to produkt się nie rozwinie. Bo każda z dziesiątek małych decyzji jakie deweloperzy podejmują każdego dnia będzie podjęta na podstawie złych przesłanek.  

7. Jest WYESTYMOWANY 

   Podobnie jak z priorytetyzacją. Łatwe do osiągnięcia, np. za pomocą białych słoni (klik: http:/nas/content/live/brasswillow/tastycupcakes.org/2009/09/sizing-game/). A dając z kolei Product Ownerowi lepszy obraz sytuacji i skracająca mnóstwo niepotrzebnych dyskusji.

8. Jest AKTUALNY i UŻYWANY

   przez wszystkich zainteresowanych projektem. To jest nagroda za powyższe.

Tak jest po prostu łatwiej!

Wygoda i zwinność jaką osiągamy za zachowanie powyższych jest nieoceniona.

Szczególnie dla zespołu deweloperskiego. Niestety wymaga mnóstwo pracy od Product Ownera. A to co wymaga pracy wymaga i motywacji. Na niespełnieniu tych kryteriów cierpi odpowiedzialny za jakość zespół. Bo bez dobrego Backloga nie ma dobrego jakościowo produktu.

Dlatego namawiam was zespoły. Zadbajcie o siebie i otwarcie informujcie swoich Product Ownerów o tym jak wam się korzysta z Produkt Backloga!