Harmonogramy Agile: tworzenie, udostępnianie, korzystanie, dostosowywanie

Podsumowanie: Plan rozwoju produktu określa, w jaki sposób produkt lub rozwiązanie będzie ewoluować z czasem. Zespoły produktowe 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.

Twierdzenie, że metodyka Agile odrzuca długoterminowe planowanie, to być może największy mit od czasów potwora z Loch Ness. W zespole Agile Plan rozwoju jest równie ważny jak w zespole korzystającym z metodyki kaskadowej — zapewnia on bowiem kontekst dotyczący codziennej pracy zespołu i długoterminowej wizji oraz uwzględnia zmiany rynkowe. Jednak w przeciwieństwie do pewnego legendarnego szkockiego potwora plan rozwoju zgodny z metodyką Agile można bez trudu znaleźć i łatwo zrozumieć.

Plan rozwoju produktu określa, w jaki sposób produkt lub rozwiązanie będzie ewoluować z czasem. Zespoły produktowe wykorzystują plany rozwoju, aby nakreślić przyszłe funkcje produktu i terminy wprowadzenia tych funkcji. W przypadku tworzenia oprogramowania z wykorzystaniem metodyki Agile plan rozwoju nadaje kluczowy kontekst codziennej pracy zespołu i wizji oraz powinien uwzględniać działania konkurentów. Wiele zwinnych zespołów może dzielić pojedynczy plan rozwoju produktu lub każdy zespół może mieć własny plan.

Aby stworzyć plan rozwoju, zespoły produktowe uwzględniają trendy rynkowe, cele firmy, opinie i wnioski klienta oraz ograniczenia techniczne. Czynniki te, odpowiednio dobrze poznane, są wyrażone w planie rozwoju jako inicjatywy i osie czasu. Poniżej przedstawiamy bardzo prosty plan rozwoju dla zespołu produktowego. Ogólnie rzecz biorąc, plany rozwoju produktów powinny obejmować dłuższe okresy, takie jak miesiące lub kwartały, zamiast zawierać konkretne daty. Aby rozmowy dotyczące ustalania priorytetów skupiały się na celach i strategii, a nie na ramach czasowych, możesz nawet spróbować określić, które inicjatywy należy wykonać teraz, następnie i później.

Po zbudowaniu planu rozwoju należy go udostępnić całemu zespołowi produktowemu, kierownictwu i zespołom realizacyjnym, aby wszystkie osoby mogły 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 czasochłonne i (co najmniej) uciążliwe.

W jaki sposób zespoły produktowe mogą lepiej przekazywać informacje organizacji? To proste.

Większość narzędzi do współpracy automatycznie powiadomi wszystkich uczestników projektu o zmianie w planie rozwoju.

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?
  • Jaki wpływ będzie miała dana inicjatywa na cele produktowe i firmowe?
  • Ile wysiłku wymaga każda inicjatywa?
  • Czy masz wystarczająco dużo informacji i danych, aby wesprzeć realizację 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?

Warto powiązać efekty pracy zespołu z wcześniejszym planem rozwoju produktu, aby uzyskać wspomniany wcześniej kontekst. Wypróbowanym sposobem jest określenie pomysłów na produkty, którym nadano priorytet na mapie produktów, a następnie podzielenie tych pomysłów na epiki, wymagania i historyjki użytkowników w planie dostawy. Zazwyczaj każda inicjatywa ma odpowiadający jej epik, który należy podzielić na mniejsze zadania do wykonania. Dzięki łączeniu pomysłów w planie rozwoju produktu z epikami w planie realizacji inżynierowie mają na wyciągnięcie ręki kontekst związany z priorytetowymi inicjatywami, takimi jak opinie użytkowników i badania. Ponadto ułatwia to zespołom ds. produktów i rozwoju wspólne podejmowanie krótkoterminowych decyzji, które nie zagrażają przyszłej pracy.

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. W idealnym przypadku pierwszym krokiem, który podejmuje się przed wdrożeniem jakiejkolwiek decyzji, jest proces odkrywania gromadzenia spostrzeżeń i danych. Umożliwia on zespołowi modyfikowanie funkcji w miarę dowiadywania się więcej o produkcie i rynku.

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 kwestiach do uwzględnienia przez większe zespoły, które zarządzają portfolio Agile z planami rozwoju w kilku zespołach. Możesz także spróbować stworzyć własny plan za darmo w narzędziu Jira Product Discovery, stworzonym dla zespołów produktowych.