Workshops vs grooming

• Poprawki błędów, drobne usprawnienia i modyfikacje, tworzenie niewielkich komponentów,
• Tworzenie dużych komponentów, grup funkcjonalności (czyt. coś w rodzaju projektu)

• 4 godziny to zdecydowanie za mało, aby dobrze „opracować” duży komponent. W związku z tym nastąpiło coś, co zespół nazwał „stosunkiem przerywanym”. Grooming jednego komponentu przeciągał się na wiele sprintów, co oczywiście miało fatalny efekt na jego skuteczność,
• Podczas analizy zespół często przeoczał pewne obszary funkcjonalne (jak i niefunkcjonalne). Powodowało to, że wielkość (czyt. pracochłonność) komponentu „puchła” wraz z postępem prac nad nim,
• Wielkość groomingów była „zdalna”, (czyli telekonferencja między zespołem a Product Ownerem) w związku, z czym zespół developerski miał spore trudności z zebraniem wszystkich istotnych informacji,
• Często pojawiały się problemy koncepcyjne wynikające z niezrozumienia przez developerów założeń biznesowych (modelu biznesowego).

• Dotyczy większej funkcjonalność/komponentu,
• Nie może odbywać się „zdalnie”,
• Ma określoną strukturę,
• Będzie trwał dłużej niż zwykle.

Struktura Workshopu

Część pierwsza

1. Wprowadzenie – ScrumMaster przypomina/informuje o tym jak zorganizowany jest Workshop, (czyli prezentuje niniejszą agendę)
2. Zidentyfikowanie obszaru prac - Określenie, nad którymi funkcjonalnościami/komponentami będziemy pracować podczas wokshopu. Przeważnie robi to Product Owner
3. Przedstawienie wizji funkcjonalności/komponentu
   a. Cel biznesowy funkcjonalności/komponentu,
   b. Długoterminowy plan biznesowy związany z funkcjonalnością/komponentem,
   c. Jakiej grupy klientów dotyczy funkcjonalność/komponent,
   d. Do jakiego rynku jest skierowany,
   e. Potencjalne problem/wyzwania.
   Podczas tego punktu agendy Product Owner nakreśla zespołowi wizję związaną ze stroną biznesową przedsięwzięcia.
4. Ustalenie celu/ów workshop’u – cele najlepiej wypisać na tablicy. Przykładowymi celami mogą być: ustalenie wysokopoziomowej estymaty dla komponentu XYZ, ustalenie architektury, rozbicie pracy na epic’i
5. Podział na zespoły wokrshopowe – z powodu wielkości zespołu dzielimy się nam mniejsze 4-5 osobowe pod-zespoły.

Część druga

1. Identyfikacja aktorów – burza mózgów, której celem jest stworzenie listy wszystkich potencjalnych aktorów (użytkowników, innych systemów itd.)
2. Identyfikacja obszarów funkcjonalnych I niefunkcjonalnych – burza mózgów w celu stworzenia listy wszystkich potencjalnych obszarów funkcjonalnych
3. Stworzenie macierzy epiców
   
   Zespół tworzy macierz, w której w rzędzie są zidentyfikowani aktorzy a w kolumnie obszary.
   
   

   Obszar/Aktor	Aktor 1	Aktor 2
   Obszar 1	Epic 1
   Obszar 2		Epic 2

4. Identyfikacja epiców/user story - dla każdej komórki macierzy (pary aktor/obszar) identyfikowany jest epic lub user story. Nie tworzymy ich na siłę. Jeśli dany epic nie ma sensu zostawiamy pole puste. Dzięki temu podejściu „patrzymy” na system z różnych perspektyw i minimalizujemy ryzyko, że jakiś obszar/element przegapimy.
5. Określenie priorytetów dla epic’ów/user stories (essential, important, nice to have) – priorytetyzujemy epicki. Mamy trzy kategorie: essential – totalnie niezbędne do startu produkcyjnego, important – musimy to zrobić, ale od biedy można zrobić start produkcyjny bez tego, nice to have – fajnie było by mieć tą funkcjonalność, ale przeżyjemy bez niej
6. Wprowadzić epici/user story do product backlogu
7. Opracowanie bazowej architektury – o tym w dalszej części posta
8. Estymacja epiców/user stories – bardzo zgrubnie (T-shirt size), ale o tym w dalszej części posta
9. Rozbić epic’ów na User Story – jak starczy czasu J

Część trzecia

1. Czy cel(e) workshopu osiągnięty?
2. Następne akcje? – Jakie powinny być następne akcje związane z groomowanymi elementami (wstępny plan działania lub dalszego groomingu),
3. Podsumowanie – kilka zdań komentarza od Product Ownera.