Jak porządkować Product Backlog? — część II

utwor­zone przez | Sty 21, 2018 | Scrum­pe­dia | 0 komen­tarzy

Kon­tynu­u­je­my rozważa­nia na trud­ną tech­niką porząd­kowa­nia  Prod­uct Back­log (Rejestr Pro­duk­tu jeśli wolisz po pol­sku). Szereg czyn­ników jakie Prod­uct Own­er musi wziąć pod uwagę omówiliśmy w pier­wszej częś­ci artykułu.

Spójność Dewelopmentu

Najwięk­szą wartoś­cią domu jest dach, ale jed­nak budu­je­my domy zaczy­na­jąc od fun­da­men­tów. Budowanie sys­temów infor­maty­cznych różni się od budynków. Dzię­ki różnym tech­nolo­giom i frame­workom nie musimy kłaść fun­da­men­tów. Jed­nak są pewne ograniczenia. Cza­sem łat­wo jest zbu­dować funkcjon­al­ność przy okazji budowa­nia innej. Zatem warto prze­jrzeć Prod­uct Back­log i uporząd­kować funkcjon­al­noś­ci wzglę­dem spójnoś­ci i łat­woś­ci imple­men­tacji.

Z drugiej strony trze­ba uważać, żeby nie wpaść w pułap­ki scrum-waterf-fail. Bard­zo łat­wo jest popaść w patrze­nie na pro­dukt tylko i wyłącznie od strony tech­nicznej. Devel­oper­om zazwyczaj najłatwiej jest budować sys­tem od najniższych warstw, architek­tu­ry albo swo­je osob­ne kloc­ki. Może też dojść do podzie­le­nia sys­te­mu ze wzglę­du na poziome warst­wy rozwiąza­nia zami­ast obszary funkcjon­alne. Ale takie pode­jś­cie nie daje wartoś­ci z punk­tu widzenia klien­ta czy użytkown­i­ka i powodu­je prob­le­my z inte­gracją. Pamię­taj, że celem każdego Sprintu jest zbu­dowanie dzi­ała­jącego, użytecznego, zin­te­growanego Przy­ros­tu Pro­duk­tu w stanie gotowym do wdroże­nia. Nie zawsze warto się wdrożyć po danym Sprin­cie.

Spójność Biznesowa

Najwięk­szą wartoś­cią w plat­formie e-com­merce są płat­noś­ci, ale nieste­ty potrze­bu­je­my wyświ­et­lanie towarów i koszyk zan­im ktoś nam zapłaci. Musimy być jakaś kole­jność dzi­ałań, skońc­zona ścież­ka w work­flow. Pro­dukt, z którego nie moż­na w pełni korzys­tać lub posi­a­da ślepe zauł­ki spowodu­je frus­trację użytkown­i­ka. Kiep­skim pomysłem też tworze­nie fałszy­wego wraże­nia. Kiedyś pra­cow­ałem z Prod­uct Ownerem, który postanow­ił umieś­cić zaśle­pi­one ekrany dla planowanych dopiero funkcjon­al­noś­ci. Nie skończyło to się dobrze dla niego ani dla pro­duk­tu. Przy takim pode­jś­ciu łat­wo też się zgu­bić w tym co jest zro­bione a co nie jest i jak nam idzie.

Zależności Zewnętrzne

Zespoły Scrum pracu­ją najlepiej kiedy nikt im nie przeszkadza, czyli nie mają wrzutek, bieżącz­ki. Zespoły Scrum pracu­ją najlepiej również kiedy nie mają zależnoś­ci zewnętrznych. A cza­sem zdarza się, że mamy zewnętrznego dostaw­cę w ramach sys­te­mu. Nie jest powiedziane, że ten dostaw­ca, a nawet inny zespół pracu­je w Agile. Pow­sta­ją zależnoś­ci. Na przykład nasz zespół może dostar­czyć funkcjon­al­ność dopiero kiedy inny dostar­czy swo­ją część albo udostęp­ni API. Oczy­wiś­cie trze­ba się dogadać kiedy ten dru­gi zespół prog­nozu­je dostar­czyć swo­ją część. Nie rozsąd­nym jest zakładać, że tak napewno będzie. To tylko prog­noza. Jeśli prog­noza mówi, że dru­gi zespól dostar­czy w Sprin­cie pią­tym, to planu­je­my, że my zaczniemy w Sprin­cie siód­mym. Taka zależność oczy­wiś­cie wpły­wa nam na porządek ele­men­tów związanych z tą funkcjon­al­noś­cią na Prod­uct Back­log.

Spójność Wdrożenia

Nic tak nie wkurza użytkown­i­ka jak nowa wer­s­ja sys­te­mu, która zaw­iera bug-fix­ing i różne zmi­any. Dużo lep­iej jest odbier­ana nowa wer­s­ja, która ma sens, wprowadza coś konkret­nego. Może pojawi się też konieczność przeszkole­nia użytkown­ików. Możli­we, że wdroże­nie nowej wer­sji wyma­ga dużo pra­cy i ofic­jal­nego pro­ce­su. Prod­uct Own­er powinien mieć wiz­ję kole­jnych wydań. Z wiz­ji wydań powin­ny w prosty sposób wynikać Cele Sprint­ów. Zespół, który wie jaki jest sens jego pra­cy jest bardziej zmo­ty­wowany. Roadma­pa pro­duk­tu powin­na być jas­no odzwier­cied­lona w kole­jnoś­ci ele­men­tów Back­logu Pro­duk­tu.

Inne Czynniki

Jest jeszcze całe mnóst­wo czyn­ników, które Prod­uct Own­er powinien wziąć pod uwagę, żeby właś­ci­wie ułożyć Prod­uct Back­log. Niek­tórzy zbudu­ją sobie w tym celu “mag­iczny” wzór w arkuszu kalku­la­cyjnym, a inni będą robić to na wyczu­cie. Zdarza się, że pomi­mo ułożonego porząd­ku trze­ba zro­bić wyjątek. Właś­ci­ciel Pro­duk­tu zarządza oczeki­wa­ni­a­mi intere­sar­iuszy i obo­jęt­nie jakie decyz­je pode­jmie, zawsze będzie ktoś niezad­owolony.

Mówienie Nie

Prod­uct Own­er ma w swoich rękach bard­zo potężne narzędzie, z którego rzad­ko zda­je sobie sprawę, a jeszcze rzadziej korzysta.Każdy może umieszczać ele­men­ty na liś­cie Prod­uct Back­log, ale Prod­uct Own­er może je bard­zo szy­bko usunąć. Właś­ci­ciel Pro­duk­tu może odmówić wyko­na­nia PBI jeśli nie widzi w tym sen­su.

Kiedyś miałem man­agera, który po powro­cie z urlopu usuwał wszys­tkie nieprzeczy­tane maile. Jeśli to coś ważnego, to prze­cież nadaw­ca sam się przy­pom­ni ponown­ie. Dobrą prak­tyką jest także okre­sowe przeglą­danie Back­logu i usuwanie stary ele­men­tów. Zasa­da przy­dat­noś­ci do spoży­cia 6 miesię­cy sprawdza się tutaj bard­zo dobrze. Jeden z Prod­uct Own­er usunął hur­towo wszys­tkie ele­men­ty z ID poniżej 1000. Byliśmy w Sprin­cie w okol­i­cy ID 1500, więc to co jest poniżej tysią­ca na pewno jest stare.  Jeśli przez sześć miesię­cy czegoś nie zre­al­i­zowal­iśmy i cią­gle dosta­je nis­ki pri­o­ry­tet, to praw­dopodob­nie nigdy tego nie zro­bimy. A co jeśli ktoś sobie przy­pom­ni o tym ele­men­cie i będzie chci­ał, żeby Zespół Devel­op­er­s­ki go zre­al­i­zował? Jeśli to jest takie ważne, to taka oso­ba może utworzyć go ponown­ie.

Czy to wszys­tkie zmi­enne, które Prod­uct Own­er musi brać pod uwagę? Na pewno nie. Więcej w poprzed­niej częś­ci artykułu.