W jednym z moich poprzednich artykułów pisałam o tym, że:

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

Pisałam też o tym że dobry Produkt Backlog, delikatnie mówiąc, ułatwia sprawę. W interesie zespołu jest więc wspomagać PO jak tylko może w utrzymaniu porządnego Product Backlogu. Nie dotyczy to tylko osób wykonujących zadania związane z biznesem. Programistom też się przyda dobre źródło informacji o produkcie.

Do czego?

Będę to powtarzać do znudzenia.

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i jego priorytety lub… coś całkiem innego.

Co? Na przykład chęć szybkiego wyjścia z pracy, chęć zaimponowania kolegom bardziej skomplikowanym rozwiązaniem, chęć powiedzenia następnego dnia że już jest zrobione. Każdy z nas chce być bohaterem. Nie ma w tym nic złego. Sztuka polega na tym aby razem z Product Ownerem doprowadzić do takiej motywacji, aby koncentracja na produkcie była czymś zupełnie oczywistym, a inne rzeczy nie zaprzątały nam głowy.

Product Owner jest ekspertem od wizji. Deweloperzy są ekspertami od jakości. Jakość kodu jest ściśle związana z jego czytelnością. Zarówno dobrzy programiści jak testerzy i analitycy biznesowi są w kwestii czytelności absolutnymi ekspertami. Jak więc mogą pomóc Product Ownerowi osiągnąć przejrzystość w Backlogu? Otóż okazuje się, że zgrabnie ujęte zasady związane z czytelnością, które ułatwiają utrzymanie czystego kodu programistom z powodzeniem można zastosować do Backlogu. Mówię tu o trzech zasadach.

 dry

DRY czyli z angielskiego “Don’t reapet yourself”

a po polsku “Nie powtarzaj się”.

“Czekaj, tam jest ten opis, skopiuje się…” – to jest ten moment w którym należy ingerować, bo inaczej Doktor Copy-Paste zamieni Product Backlog w niekończącą się litanię powtarzających się fragmentów dokumentacji. Oczywiście nie dokładnie takich samych, bo świat się zmienia. Klient zmienia zdanie. Rynek się zmienia. Dokumentacja też się zmienia, ale przeważnie tylko jedna kopia, czasem dwie, jeśli o nich pamiętamy. Rzadko wszystkie. Więc jeśli chcesz mieć dostęp do rzetelnych informacji, trzymajmy każdą z nich dokładnie raz. A kopiować można jakiś odnośnik do niej.

pablo (2)

KISS czyli “Keep it simple stupid”,

czyli “Niech będzie tak proste, że aż głupie”.

Czy warto poświęcać czas na wygładzanie opisów w Product Backlogu. Na szlifowaniu ich tak, żeby każdy klient użytkownik i deweloper je zrozumiał. Na ślęczeniu przy nich tak długo, że zrozumiemy je nawet jak siądziemy do nich za rok czasu.

Odpowiedź brzmi TAK.

Z dwóch powodów. Służy to użytkownikom i autorowi:

  1. Użytkownikom bo Product Backlog stanowi plan – do planu zagląda się często. Aby go doszlifowywać, weryfikować i wreszcie realizować. Zagląda tam sporo osób. Użytkownicy, klienci, deweloperzy, zarząd a przede wszystkim autor. Powinien być więc tak prosty i przejrzysty jak tylko się da. Aby nie marnować czasu odbiorców i zachęcać do korzystania. Jeśli będzie się kojarzył z kodeksem, to nikt tam nie zajrzy i będzie mnóstwo niespodzianek. Product Owner będzie miał niespodziankę jeśli nie dostanie tego co chciał, bo deweloper nie zajrzał. Klient będzie miał niespodziankę jak nie dostanie tego co chciał, bo nie zajrzał i nie zauważył, że go nie zrozumiano i tak dalej. Jeżeli do planu nie zagląda się często i nie jest potrzebny wielu osobom, to coś jest nie tak. Planujemy na zbyt długie okresy czasu? A może nie mamy kontaktu z odbiorcami? Nie zbieramy od nich informacji zwrotnej? Możliwości jest wiele. Optymalny Product Backlog jest krótki, zwięzły, aktualny, zmienia się często i jest używany.
  2. Przydaje się też autorowi bo proces klaryfikacji opisu klaryfikuje wizję autora. Czy zdarzyło wam się skasować przypadkiem wyniki swojej pracy, przez co byliście zmuszeni do wykonania jej jeszcze raz? Mi się zdarzało. Bardzo często efekt pracy był dużo lepszy niż pierwotna wersja. Co więcej moje zrozumienie tematu staje się o niebo lepsze. Tak samo jest z kodem i tak samo jest z Produck Backlogiem. Praca nad nim sprawia że, wizja staje się coraz wyraźniejsza i dokładniejsza. Czasem sprawia też, że wizja zmienia się bo autor odkrywa coś czego wcześniej nie wiedział, lub wpada na lepszy pomysł. Konieczność wyrażenia czegoś w prosty sposób, doprowadza do zrozumienia tego lepiej. Warto poświęcić na to czas. Jeżeli wasz Product Owner nie spędza mnóstwa czasu wpatrując się w Product Backlog, to wiedzcie, że coś niedobrego się dzieje z produktem.

4315444

YAGNI czyli “You aren’t gonna need it”,

po polsku “Nie, nie będziesz tego potrzebował”.

Product Backlog jest centralnym punktem informacji o produkcie. Wydaje się więc, że powinien być duży. To nie prawda. Powinno być tam wszystko co ważne, krótko i zwięźle, a nie wszystko co kiedykolwiek ktoś wymyślił. Nadmiar informacji jest świetnym sposobem na ukrycie tego co jest ważne, tyle, że w przypadku Product Backlogu intencja jest odwrotna. Chcemy to przejrzyście pokazać. Tak jak dobry deweloper uczy się w pewnym momencie kasować kod, który napisał bo okazuje się, że nie jest używany, tak i Product Owner uczy się kasować rzeczy, których jednak nie będzie realizował. Niezależnie od tego jak dużo czasu poświęcił na ich zaplanowanie. Wiem to trudne, ale warto. Przy okazji uczymy się, że nie warto planować szczegółów tego, co będziemy robić za pół roku i nie warto trzymać tego planu jeżeli już go mamy, bo i tak za pół roku zrobimy to inaczej. Za pół roku będziemy innymi ludźmi dosłownie lub w przenośni.

Oczywiście nie tylko te zasady czystego kodu z powodzeniem można stosować do Product Backlogu. Czytelność w obu przypadkach jest kluczowa, programiści wykorzystajcie więc swojej doświadczenie w utrzymaniu czystego i czytelnego kodu i pokażcie jak to robić waszym Product Ownerom. Nie z altruizmy. Zróbcie to bo jest to w waszym interesie.

Agent do zadań specjalnych. Pierwszy w Polsce Trener Professional Scrum Developer oraz pierwsza kobieta na świecie z takimi kompetencjami!