Daily
Codzienne spotkania zespołu, by umożliwić właściwy przepływ informacji (w szczególności tych, dotyczących zadań wykonanych i do wykonania) a także wymienić się doświadczeniami czy najlepszymi praktykami.
Przy czym, spotkanie nie ma na celu dyskusji o wyzwaniach projektowych. Stanowi platformę do sygnalizowania przeszkód czy wyzwań, by zostały przeanalizowane, a następnie rozwiązane przez odpowiednie osoby w zespole.
Planowanie
To cykliczne, jednorazowe w każdej iteracji, spotkanie zespołu z Product Ownerem w celu:
- omówienia zaplanowanych zadań do realizacji w najbliższym czasie, z zachowaniem priorytetów oraz obecnych możliwości zespołu,
- potwierdzenia zadań i sposobu ich realizacji,
- zaplanowania zadań w sposób uwzględniający poziom ich złożoności oraz kompetencje zespołu,
- zagwarantowania, że przyjęte do realizacji zadania zostaną zrealizowane w terminie.
Ważną rolę pełni spotkanie, które przed planowaniem doprecyzuje kwestie backlogu (refinement), pozwoli przedyskutować wymagania, wyjaśnić wątpliwości, a także potwierdzić pełne zrozumienie zakresu i celów wdrażanych funkcjonalności.
Przegląd produktu (sprintu)
Umożliwia cykliczną prezentację produktu interesariuszom, a następnie przyjęcie uwag i wymianę spostrzeżeń między zespołem a biznesem. W efekcie, spotkanie stanowi źródło nowych wymagań oraz oczekiwań, które pozostaną do decyzji Product Ownera.
Przegląd produktu zwiększa poczucie odpowiedzialności w zespole, a wśród interesariuszy zwiększa poczucie świadomości w zakresie realizacji wymagań, a także – poprzez opinie i sugestie – odzwierciedla ich realny wpływ na końcowy produkt.
Retrospektywa
Podczas wewnętrznego spotkania zespołu oceniane są powodzenia oraz błędy w trakcie realizacji każdego etapu projektu, by w efekcie wypracować najlepsze metody pracy wspierające produktywność i przynoszące satysfakcję z pracy poszczególnych członków zespołu.
3. Backlog oraz narzędzia do jego utrzymania i wizualizacji
Ostatnie, ale nie najmniej ważne narzędzie Agile to backlog, czyli zbiór zgłoszonych przez interesariuszy oczekiwań w stosunku do funkcjonalności będących przedmiotem prac w hierarchicznym podziale na:
- Epiki – wysokopoziomowe wymagania, mogące obejmować wiele wersji projektu/ produktu;
- Cechy funkcjonalności (Features) – bardziej szczegółowe wymagania, które tworzą Epikę podczas jednego wydania,
- User Stories, czyli historyjki – dokładne wymagania realizowane w ramach jednej iteracji, których zbiór stanowi cechę funkcjonalności.
Dla lepszego zobrazowania struktury backlogu, poniżej przykład:
- Epika: Sprzedaż nowego produktu
- Cecha funkcjonalności: Ofertowanie produktu w portalu
- Historyjka: Kalkukacja ceny bazowego produktu
W trakcie prac backlog powinien podlegać stałej zmianie priorytetów. Elementy o najwyższym priorytecie zostaną opisane z uwzględnieniem szczegółów. Im mniejszy priorytet, tym mniej detali danego elementu. Często zdarza się sytuacja, w której elementy o najniższym priorytecie nie są podejmowane do realizacji. W Agile, backlog jest żywym organizmem – wymagania nie są sztywne i mogą podlegać zmianom w zależności od aktualnych potrzeb. W efekcie, warto wykorzystać istniejące na rynku narzędzia, które umożliwią utrzymywanie tego ekosystemu w prosty oraz dostępny dla wszystkich zainteresowanych sposób.
W celu określenia priorytetów elementów backlogu, najprostszą drogą będzie wykorzystanie skali MoSCoW do opisania, a następnie ustalenia kolejności ich realizacji:
- MUST HAVE, czyli – wymaganie, którego realizacja jest niezbędna w finalnym rozwiązaniu.
lub (ang. or)
- SHOULD HAVE, czyli pozycja o wysokim priorytecie, która w miarę możliwości powinna zostać uwzględniona.
- COULD HAVE – wymaganie postrzegane jako pożądane, lecz niekonieczne. Jego realizacja jest uzależniona od czasu i dostępnych zasobów.
or
- WON’T HAVE oznacza zadanie, które za zgodą interesariuszy, nie zostanie zaimplementowane w obecnym wydaniu, ale może być rozpatrzone w przyszłości.
Kolejnym krokiem na drodze usprawnień i śledzenia zadań jest sprawdzenie możliwości wykorzystania tablic kanban, które prezentują status zadań, ich liczbę w realizacji i wskazują utrudnienia (tzw. wąskie gardła) w procesie wytwórczym.
Agile, czyli co warto wiedzieć o metodyce zwinnej?
Wdrożenie Agile dla samego faktu bycia organizacją zwinną lub zrobienie tego szybko i bez właściwego przygotowania, może przynieść więcej szkody, niż korzyści. Od czego zacząć wdrażanie Agile? W pierwszym etapie należy dokładnie przyjrzeć się organizacji, jej obecnym metodom działania oraz przeanalizować wdrożenie z perspektywy czasu oraz obszaru.
Warto wykorzystać doświadczenia ekspertów i praktyków specjalizujących się w projektach transformacyjnych Agile. Będą w stanie łatwo ocenić, w jaki sposób zwinnie dostosować narzędzia oraz reguły do indywidualnych potrzeb organizacji.