Podsumowanie: Plan rozwoju produktu określa, w jaki sposób produkt lub rozwiązanie będzie ewoluować z czasem. Product ownerzy wykorzystują plany rozwoju, aby nakreślić przyszłe funkcje produktu i terminy wprowadzenia nowych funkcji. W przypadku tworzenia oprogramowania z wykorzystaniem metodyki Agile plan rozwoju nadaje kluczowy kontekst codziennej pracy zespołu i powinien uwzględniać działania konkurentów.
To, że metodyka Agile odrzuca długoterminowe planowanie, to być może największy mit od czasów potwora z Loch Ness. Plan rozwoju jest tak samo ważny w zespole Agile, jak i w korzystającym z metodyki kaskadowej — zapewnia on bowiem kontekst dotyczący codziennej pracy zespołu i uwzględnia zmiany rynkowe. Ale w przeciwieństwie do pewnego legendarnego szkockiego potwora plan rozwoju zgodny z metodyką Agile można bez trudu znaleźć i łatwo zrozumieć.
Czym jest plan rozwoju produktu zgodny z metodyką Agile?
Plan rozwoju produktu określa, w jaki sposób produkt lub rozwiązanie będzie ewoluować z czasem. Product ownerzy wykorzystują plany rozwoju, aby nakreślić przyszłe funkcje produktu i terminy wprowadzenia nowych funkcji. W przypadku tworzenia oprogramowania z wykorzystaniem metodyki Agile plan rozwoju nadaje kluczowy kontekst codziennej pracy zespołu i powinien uwzględniać działania konkurentów. Wiele zespołów Agile może korzystać ze wspólnego planu rozwoju produktu.
Tworzenie planu rozwoju
Aby stworzyć plan rozwoju, product ownerzy uwzględniają trendy rynkowe, propozycje wartości i ograniczenia techniczne. Gdy czynniki te zostaną odpowiednio dobrze poznane, są one wyrażone w planie rozwoju jako inicjatywy i osie czasu. Poniżej przedstawiamy bardzo prosty plan rozwoju dla zespołu produktowego. Inicjatywy są oznaczone kolorem niebieskim, a osie czasu — czerwonymi znacznikami kamieni milowych.
Udostępnianie planu rozwoju
Po zbudowaniu planu rozwoju należy go udostępnić całemu zespołowi produktowemu, aby każdy jego członek mógł zrozumieć wizję i kierunek. W wielu organizacjach product ownerzy tworzą swoje plany rozwoju w programie PowerPoint i arkuszach kalkulacyjnych, a następnie wysyłają slajdy i arkusze do zespołu. Mimo dobrych intencji strategia ta jest wadliwa u samych podstaw. Każdy członek zespołu ma własną kopię planu rozwoju, przez co informowanie wszystkich na bieżąco o ewentualnych zmianach jest (co najmniej) uciążliwe.
Jak więc product owner może skuteczniej informować zespół? To proste.
Większość narzędzi do współpracy przeznaczonych do tego typu zadań automatycznie powiadomi wszystkich uczestników projektu o zmianie w planie rozwoju. (Jeśli Twoje narzędzie nie ma takiej funkcji, to może nadszedł czas, aby udać się na zakupy).
Dodając inicjatywę do planu rozwoju, należy wziąć pod uwagę następujące pytania:
Zanim porozmawiamy o dynamicznych rozwiązaniach z zakresu prognozowania, przyjrzyjmy się krokom pozwalającym na zbudowanie długoterminowego planu Agile, zgodnie z metaforą budowy domu:
- Jakie są względne priorytety każdej inicjatywy?
- Kiedy zamierzamy pracować nad każdą inicjatywą?
- Czy istnieją konkretne terminy, których zespół musi przestrzegać?
- Jakie zależności występują w programie — zarówno wewnętrzne, jak i dotyczące innych zespołów?
- Które zespoły pracują nad każdą z inicjatyw?
- Czy obecne zespoły mają dostępność w swoich harmonogramach i wystarczające zdolności przerobowe?
- Czy jesteśmy w stanie zapewnić stabilność obecnych zespołów Agile?
- Jeśli nie...
- W jaki sposób zespoły zostaną przeorganizowane?
- Czy na osi czasu projektu uwzględniamy wdrażanie nowo utworzonych zespołów?
- W jaki sposób zespoły zostaną przeorganizowane?
- Jeśli nie...
Korzystanie z planu rozwoju
Warto powiązać pracę zespołu z planem rozwoju, aby uzyskać wspomniany wcześniej kontekst. Wypróbowany sposób polega na rozbiciu inicjatyw na epiki w backlogu produktu, a następnie dalszy ich podział na wymagania i historyjki użytkowników. Powiązanie wszystkich tych informacji ułatwia product ownerom i zespołowi programistów podejmowanie krótkoterminowych decyzji, które nie zaburzają przyszłych prac. Przyjrzyjmy się przykładowi, aby przekonać się, jak to może wyglądać.
Załóżmy na przykład, że na naszej stronie internetowej wprowadzamy obszerną funkcję profilu użytkownika. Jeśli okaże się, że nasi klienci nie korzystają z tej funkcji, czy powinniśmy nadal w nią inwestować? Może tak, może nie. Zanim podejmiemy tę decyzję, musimy zrozumieć, dlaczego funkcja nie cieszy się popularnością. Zamiast przeć do przodu, możemy zdecydować się na przeprowadzenie paru testów A/B w nadziei na uzyskanie wglądu w przyczyny niskiego wskaźnika zaangażowania, co może nam pomóc w wyborze odpowiednich działań. Podjęcie tej decyzji byłoby znacznie trudniejsze (lub niemożliwe), gdybyśmy postanowili po prostu dodawać kolejne funkcje.
Zdolność do zrobienia kroku w tył i przeanalizowania sprawy przed podjęciem zasadniczej decyzji jest istotą planu rozwoju zgodnego z Agile. Umożliwia ona zespołowi modyfikowanie funkcji w miarę dowiadywania się więcej o produkcie i rynku.
- Układanie planów na przyszłość jest całkowicie ignorowane — idziemy na żywioł!
- Reszta firmy jest utrzymywana w niewiedzy co do planowanych działań zespołu.
- Plan rozwoju jest ciągle aktualizowany (lub nigdy nie jest aktualizowany).
- Szczegółowe wymagania obciążają plan rozwoju.
Ewolucja planu rozwoju
Projekty kaskadowe wymagają ogromnej inwestycji z góry. W rezultacie członkowie zespołu przywiązują się emocjonalnie do planu rozwoju i unikają podjęcia właściwej decyzji, ponieważ wycofanie się z poczynionych kroków jest zbyt trudne — to ludzka przypadłość.
W przypadku programowania Agile występują z kolei trzy różne zagrożenia:
- Zespół może stracić zaufanie do zdolności kierownictwa do podejmowania strategicznych decyzji, jeśli plan rozwoju będzie aktualizowany zbyt często.
- Produkt może trafić na rynek zbyt późno i przegapić popyt, jeśli plan rozwoju nie będzie aktualizowany wystarczająco często.
- Długoterminowe działania mogą wydawać się „zbyt duże i zbyt trudne” dla krótszych iteracji. Zespół nadmiernie kompensuje to sobie, rozbijając pracę na drobne cząstki i w ostatecznie zbyt mocno skupia się na krótkoterminowych rezultatach.
W celu uniknięcia „miotania się”, marazmu i krótkowzroczności, plan rozwoju powinien być równomiernie skoncentrowany na krótkoterminowych taktykach i strategicznych, długoterminowych celach. Świetnym sposobem jest przeprowadzanie kwartalnych przeglądów planów rozwoju, modyfikowanie ich w razie potrzeby i udostępnianie. Działa to dobrze w organizacji dowolnej wielkości, ale pamiętaj: pojedynczy plan rozwoju może obejmować wiele zespołów Agile, dlatego odpowiednio sprawdzaj, dostosowuj i przekazuj informacje.
W dalszej części szkolenia Trener z zakresu metodyki Agile dowiesz się więcej o szczególnych kwestiach dla większych zespołów, które zarządzają portfolio Agile z planami rozwoju w kilku zespołach. Możesz też dowiedzieć się więcej o planach rozwoju w systemie Jira Software.
