Dzisiejszy
odcinek poświęcimy kwestii planowania, analizy i tworzenia architektury.
Workshops vs grooming
Zadania naszego
zespołu można zasadniczo podzielić na dwie kategorie:
- 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)
Jak pewnie część
z was wywnioskowała z mojego poprzedniego postu, poza Sprint Planningiem, w
ramach planowania prac, stosujemy również grooming (lub w nomenklaturze
najnowszego SCRUM guide: Product Backlog refinement). Poświęcamy na niego
przeważnie 4 godziny per 2 tygodniowy sprint. I w tym miejscu pojawił się
pewien problem… a właściwie kilka
problemów związanych z groomingiem dużych komponentów:
- 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).
W celu
rozwiązania tych problemów wprowadziliśmy tak zwany Workshop. Jest to tak
naprawdę ustrukturowana forma groomingu, która odbywa się zawsze face2face
(Product Owner z zespołem współpracują razem w jednej lokalizacji).
Wprowadzenie tej nowej nazwy jest bardzo istotne, ponieważ sygnalizuje zarówno
stronie biznesowej jak i developerskiej, że grooming:
- 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
Nasze Workshopy
trwają przeważnie cały dzień (8h) i podzielone są na 3 części.
Część pierwsza
Uczestniczy w
niej cały zespół (razem). Max. 1,5 h.
Agenda
- Wprowadzenie – ScrumMaster przypomina/informuje o tym jak zorganizowany jest Workshop, (czyli prezentuje niniejszą agendę)
- Zidentyfikowanie obszaru prac - Określenie, nad którymi funkcjonalnościami/komponentami będziemy pracować podczas wokshopu. Przeważnie robi to Product Owner
- 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. - 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
- Podział na zespoły wokrshopowe – z powodu wielkości zespołu dzielimy się nam mniejsze 4-5 osobowe pod-zespoły.
Część druga
Odbywa się w
podzespołach
- Identyfikacja aktorów – burza mózgów, której celem jest stworzenie listy wszystkich potencjalnych aktorów (użytkowników, innych systemów itd.)
- Identyfikacja obszarów funkcjonalnych I niefunkcjonalnych – burza mózgów w celu stworzenia listy wszystkich potencjalnych obszarów funkcjonalnych
- Stworzenie macierzy epicówZespół tworzy macierz, w której w rzędzie są zidentyfikowani aktorzy a w kolumnie obszary.
Obszar/AktorAktor 1Aktor 2Obszar 1Epic 1Obszar 2Epic 2 - 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.
- 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
- Wprowadzić epici/user story do product backlogu
- Opracowanie bazowej architektury – o tym w dalszej części posta
- Estymacja epiców/user stories – bardzo zgrubnie (T-shirt size), ale o tym w dalszej części posta
- Rozbić epic’ów na User Story – jak starczy czasu J
Część trzecia
Wszyscy razem.
Max 30 minut.
- Czy cel(e) workshopu osiągnięty?
- Następne akcje? – Jakie powinny być następne akcje związane z groomowanymi elementami (wstępny plan działania lub dalszego groomingu),
- Podsumowanie – kilka zdań komentarza od Product Ownera.
Estymacja
Aby sprostać
wymaganiom naszego Product Ownera oraz by poprawić klarowność informacji
przekazywanych do „biznesu” wprowadziliśmy 3 stopniową skalę estymacji.
- Shoot from the hip – mierzona w T-Shirt size’ach. Każdemu rozmiarowi przypisany jest jakiś przedział Story Pointów, a im większy rozmiar tym szerszy przedział (np. XL to 50 - 90 SP).Tego typu estymata z jednej strony pozwala Product Ownerowi określić czy jest sens zajmować się tą funkcjonalnością, z drugiej w pewien sposób daje komfort psychiczny zespołowi (pewne oderwanie od Story Pointów) dzięki czemu nie tracą czasu starając się wszystko dokładnie wyestymować.
- RAW – estymata w Story Pointach, wartość musi być z ciągu Fibonacciego (1,2,3,5,8,13,21,34,55)
- Rough but ready – w Story Pointach. Dokładność do 1 SP, maksymalna wielkość to 13 SP. Tylko User Stories z tym poziomem estymaty mogą być włączone do Sprint Backlogu. Zapobiega to „wciągania” do sprintu zbyt dużych (a przez to niejasnych) historyjek.
Architektura
Na koniec trudna
w agile’u sprawa architektury systemu. Nasłuchałem i naczytałem się sporo
komentarzy typu: „W agile NIGDY nie tworzymy architektury up-front.
Refaktorujemy.” BZDURA!!! Widać, że osoby szerzące tego typu teorie nie miały
styczności z dużymi projektami już działającymi produkcyjnie. Życzę im
powodzenia przy każdym wdrożeniu w modyfikacji kilkudziesięciu komponentów
rozproszonych na kilku klastrach serwerowych. W agile jak to w agile… robisz
tak, aby było optymalnie dla twojego projektu. Nie musicie robić architektury
up-front… to super. My niestety musimy. Staramy się natomiast utrzymać ją na
pewnym poziomie abstrakcji, nie zagłębiając się za bardzo w szczegóły. Robimy
to podczas workshopu lub groomingu, ponieważ bez ustalonej wysokopoziomowej
architektury ciężko wyestymować dany komponent.