Obecnie wiele organizacji nadal pracuje w silosach, co oznacza, że każdy dział czy pracownik pracuje nad swoją specjalnością, jest odcięty od reszty firmy i nie ma świadomości tego, jak praca, którą wykonuje, wpływa na pracę innych działów.
Taka organizacja może generować poważne problemy dla produktu i zespołu, który nad nim pracuje. Przykłady: słabe zrozumienie makiet przez zespół techniczny, dodatkowa praca nad specyfikacją dla Product Ownera czy też późne odkrycie niezgodności UX/technicznych, które prowadzą do przerobienia całego projektu.
Przeczytaj artykuł i dowiedz się, jak krok po kroku dokonać rozbijania projektu i planowania w małych iteracjach, aby zawsze dostarczać niezawodnie.
Czym jest zwinne planowanie?
Zwinne planowanie jest metodą planowania projektu, która organizuje pracę przy użyciu niezależnych jednostek roboczych, zwanych iteracjami lub sprintami. Sprint to okres od 1 do 3 tygodni, w którym zespoły skupiają się na niewielkiej liczbie elementów pracy i wspólnie pracują nad ich wykonaniem. Zwinne planowanie obejmuje podejmowanie decyzji, który element wziąć na tapet w każdym sprincie, oraz tworzenie powtarzalnego procesu, który ułatwia zespołowi odkrycie, co można osiągnąć.
Zwinne planowanie dzieli rozwój oprogramowania na kilka mniejszych części, które można rozwijać w iteracjach, a klientowi zapewniają wartość dodaną. Zespoły nie próbują od razu planować „dużego produktu”. Planują, co mogą osiągnąć, aby zadowolić klienta w krótkim czasie.
Niezbędne komponenty zwinnego planowania
- Zwinny plan projektu podzielony jest na wersje i sprinty
Zwinni planiści definiują wydanie, które obejmuje tworzenie nowego produktu lub istotną aktualizację istniejącego produktu. Każde wydanie podzielone na kilka iteracji, zwanych także sprintami. Każdy sprint ma ustaloną długość, zwykle 1-2 tygodnie, a zespół ma wstępnie zdefiniowaną listę elementów pracy do wykonania w każdym sprincie. Elementy pracy nazywane są historiami użytkowników.
- Planowanie opiera się na historiach użytkowników
W zwinnym planowaniu zespół dokumentuje jedynie to, czego potrzebuje użytkownik. Podczas sprintu zespół wspólnie zastanawia się, jak najlepiej zaspokoić tę konkretną potrzebę.
- Planowanie jest iteracyjne i przyrostowe
Zwinny proces koncentruje się na koncepcji iteracji. Wszystkie sprinty mają równą długość, a zwinny zespół powtarza ten sam proces w każdym kroku. Każdy sprint powinien skutkować działaniem funkcji, które mogą zostać przedstawione użytkownikom końcowym.
Proces iteracyjny pozwala zespołowi dowiedzieć się, do czego jest zdolny; oszacować, ile historii może ukończyć w danym przedziale czasowym (prędkość zespołu) i dowiedzieć się o problemach, które utrudniają ich postęp. Problemy te można rozwiązać w kolejnych sprintach.
- Oszacowania dokonują sami członkowie zespołu
Podstawową zasadą zwinnego planowania jest to, że zespoły programistyczne powinny brać udział w planowaniu i szacowaniu, a zakres prac nie powinien być im „podyktowany” przez kierownictwo.
W tym duchu zwinne planowanie pozwala zespołom przypisywać punkty historii do historii użytkowników w planie wydania.
Czym jest Agile planning poker?
Agile planning poker to zwinna technika szacowania i planowania, oparta na konsensusie, aby pomóc zespołom oszacować ilość pracy wymaganej do wykonania zadań w obrębie danego produktu. Tej szacunkowej gry używa coraz więcej zwinnych zespołów. Na czym polega? Kilku członków zespołu jest proszonych o oszacowanie historii użytkownika poprzez wyciągnięcie karty do gry z wieloma punktami opowieści i umieszczenie jej zakrytej na stole. Następnie karty są odkryte, a jeśli występują rozbieżności – na przykład jeden członek zespołu przypisał historii 1 punkt, a pozostali przypisali 4 lub 5 – mogą dyskutować i osiągnąć porozumienie.
Celem tego etapu jest przedyskutowanie wszelkich różnic i osiągnięcie porozumienia co do punktacji danej pracy, która będzie reprezentować zbiorową ocenę wysiłku zespołu. Wymaganie konsensusu w zespole, zamiast dyktowania szacunków przez jedną osobę, może podnieść morale, dając głos wszystkim członkom zespołu.
Czym jest release planning?
To metoda zarządzania produktem, w ramach której planuje się kolejne wydania produktu. Różni się od tradycyjnego planowania oprogramowania, w którym zespoły produktowe koncentrują się na ich głównych wydaniach. Plany wydań pomagają zespołom podejmować decyzje dotyczące tego, ile funkcjonalności mogą dostarczyć i ile czasu zajmie opracowanie każdej z nich.
Release plan process – 8 kroków do efektywnego planu wydania
Product Owner musi wytyczyć cele wydania: jaki problem chcemy rozwiązać jako zespół lub jak poprawić komfort użytkowania? W oparciu o te cele należy wykonać następujące kroki, aby zaplanować wydanie.
- Omów potrzebne funkcje, aby osiągnąć cele.
- Omów szczegóły związane z każdą funkcją oraz czynniki, które mogą wpłynąć na dostarczenie. Obejmowałoby to wymaganą infrastrukturę, ryzyko i zależności zewnętrzne. Funkcje o najwyższym ryzyku i najwyższej wartości należy zaplanować na początku wydania.
- Zdecyduj, ile pracy może wykonać zespół, aby ukończyć każdy sprint. Jest to zwykle oparte na prędkości zespołu w poprzednich sprintach. Należy wziąć pod uwagę istniejące prace nad infrastrukturą lub narzędziami oraz znane przerwy, takie jak praca wsparcia.
- Wymień historie związane z wydaniem w kolejności według ich wielkości.
- Dodaj iterację do planu.
- Dodawaj historie do iteracji, aż osiągnie maksymalną pojemność.
- Dodaj więcej iteracji, aż wszystkie historie użytkowników zostaną uwzględnione, lub usuń historie użytkowników o niższym priorytecie, aby dostosować się do wymaganych ram czasowych dla wydania.
- Udostępnij plan, korzystając z wybranego oprogramowania do sprawnego zarządzania, i poproś o opinię, aby uzyskać zaangażowanie wszystkich członków zespołu, właściciela produktu i innych interesariuszy.
Praca zespołowa nie zawsze będzie prosta i łatwa. Najważniejsze w planowaniu zespołowym jest to, że każdy członek zespołu wnosi jakąś wartość do projektu i staje się jego częścią. Dzięki temu zespoły chętniej dążą do celu i lepiej rozumieją, co mają osiągnąć. Nie martw się, jeśli Twój pierwszy sprint nie pójdzie po Twojej myśli. Niepowodzenia należy zawsze traktować jako okazję do doskonalenia i wzmacniania zespołu, a nie jako źródło goryczy i wzajemnych oskarżeń.