Spotkania wytyczają drogę ludzkiego losu, niezależnie od tego, czy trwają kilka godzin, kilka dni, czy całe życie.
Cztery lata temu postanowiłem zmienić branżę. Na tą decyzję miało wpływ wiele czynników, ale z perspektywy czasu wydaje się ona słuszna. Czysty przypadek sprawił, że rozpocząłem swoją nową karierę zawodową w tak zwanej branży informatycznej. Wydawałoby się, że pisanie kodu wystarczy do stworzenia produktu, aplikacji lub systemu jaki zamówił sobie klient. Moim zaskoczeniem była liczba spotkań i rozmów jakie odbywają się w trakcie prac nad kodem. W trakcie zagłębiania się w nowym temacie poznałem również zwinne zarządzanie projektami - ang. agile. Twórcy takiego podejścia przedstawili główne założenia, które zawarli w 12 punktach tzw. agile manifesto. Jednym z założeń jest twierdzenie:
Najbardziej efektywnym i wydajnym sposobem przekazywania
informacji zespołowi deweloperskiemu i wewnątrz niego jest
rozmowa twarzą w twarz.
Przedstawione założenie spowodowało, że w trakcie tworzenia kodu, aby dostarczyć dobry produkt, zespół projektowy spotyka się wiele razy. Jak najbardziej się z tym zgadzam i osobiście jestem zwolennikiem organizowania nawet bardzo krótkich rozmów - video, abyśmy wszyscy się dobrze zrozumieli. Słowo pisane nie zawsze jest w stanie przekazać dokładnie to co chcemy uzyskać. Z drugiej jednak strony duża liczba spotkań, szczególnie ustalona w krótkich odstępach czasowych nie pozwala na “wgryzienie się” w temat lub zabiera czas na przełączanie się na inne tematy. Niemniej jednak pewne spotkania muszą się odbyć w trakcie trwania prac developerskich. I tak jedna z zwinnych metod - Scrum wprowadził pewne stałe spotkania, które są ograniczone czasowo przez tzw. time-box, dzięki czemu nie powinny one zabierać zbyt wiele czasu z ogólnego rozrachunku przeznaczonego na tworzenie produktu. Po zsumowaniu liczby czasu spędzonego na spotkaniach w trakcie tzw. sprintu czas ten nie powinien przekraczać 14% czasu wszystkich godzin w sprincie, i to niezależnie od długości sprintu.
No dobrze, wiemy już, że istnieją ściśle określone spotkania i mają swój limit czasowy. Teraz przejdźmy do najważniejszego, czyli celowości tych spotkań i kto musi w nich uczestniczyć.
Gotowi! Do startu!
Z racji tego, że Scrum jest najczęściej wybieranym frameworkiem do zarządzania projektami, będę opisywał kolejność spotkań w ramach Sprintu. Mamy już za sobą pracę nad zakresem projektu. Główne kierunki zostały ustalone i elementy o najwyższym priorytecie znajdują się na szczycie naszego backlogu. Rozpoczęcie prac zaczyna się od...planningu. Jest to pierwsze spotkanie w celu określenia zakresu prac w danym sprincie.
Sprint planning
Po co?
Jest to jedno z głównych spotkań na etapie tworzenia produktu. W trakcie tego spotkania ustalany jest zakres prac na najbliższy okres, czyli tzw. Sprint. Właściciel produktu - ang. Product Owner, określa swoje priorytety, jakie powinny zostać dostarczone. Jest to również ostatni moment na zrozumienie zakresu prac jaki ma być wykonany przez zespół deweloperski. Jest to spotkanie, na którym można uszczegóławiać zadania, zmienić kolejność wykonywania zadań lub też dokonać dekompozycji zadań na mniejsze, jeśli jest to konieczne. Zgodnie z prawidłowym podejściem, każda historyjka użytkownika - ang. User Story, aby była przejrzysta i łatwa do wdrożenia, powinna być opisana przy użyciu Definicji Gotowości -ang. Definition of Ready (DoR). Definicja Gotowości jest sumą czynników, które muszą zostać spełnione, aby cały zespół zgodził się, że User Story jest gotowy do wdrożenia, tj. jest odpowiednio zidentyfikowany i szczegółowo opisany. Istnieje również Definicja Ukończenia - ang. Definition of Done (DoD) wyjaśnia, kiedy User Story można uznać za ukończoną. W praktyce DoD działa jako lista kontrolna dla zespołu projektowego, szczególnie dla testerów i inżynierów jakości - ang. Quality Assurance, umożliwiając im sprawdzenie, czy konkretna historia użytkownika została poprawnie zaimplementowana.
W trakcie tego spotkania trwają negocjacje pomiędzy Product Ownerem a zespołem deweloperskim odnośnie liczby zadań. Ustalany jest również Cel Sprintu, czyli ustalane są priorytety zadań jakie mają być dostarczone
Kto uczestniczy?
Product Owner - określa priorytety oraz Cel Sprintu
Scrum Master - pilnuje czy wszyscy zgadzają się z zakresem prac
Dev Team - uszczegóławiają zadania w zakresie Sprintu, dekomponują zadania na mniejsze, informują o zależnościach i możliwościach dostarczenia proponowanych zadań.
Time box: do 4h dla dwutygodniowego Sprintu. Raz na Sprint
Daily Scrum
Po co?
to wydarzenie, zwane również Daily Standup, dotyczy zespołu deweloperskiego, którego celem jest uwspólnienie wiedzy na temat wykonywanej pracy, zaplanowanie jej na dalszy okres oraz zidentyfikowanie problemów, które uniemożliwiają wypełnienie Celu Sprintu. Spotkanie ma również na celu monitorowanie postępu prac, aby w przypadku problemów lub trudności można by było szybko reagować lub ostatecznie negocjować zakres pracy z Właścicielem produktu. Podczas codziennego spotkania Scrum każdy członek zespołu powinien odpowiedzieć na trzy pytania:
co zrobiłeś wczoraj
jakie są twoje zadania na dziś?
czy są jakieś blokery do wykonania zadań?
Kto uczestniczy?
Spotkanie jest głównie dla zespołu Scrumowego. Product Owner może również być obecny na tym spotkaniu, ale powinien się tylko przysłuchiwać temu co zespół ma do powiedzenia.
Time box: 15 min, codziennie
Backlog Refinement
Po co?
Dawniej znane było jako Grooming. Spotkanie odbywa się w środku każdego sprintu. Głównym celem tego wydarzenia jest:
Omawianie i uszczegółowienie zadań będących w Backlogu Produktu
Dekompozycja istniejących elementów
Dodawanie nowych elementów do Backlogu Produktu
Dodawanie kryteriów akceptacji do zadań
Dodawanie oszacowań przez Zespół Deweloperski
Porządkowanie elementów Rejestru Produktu, czyli ustalenie priorytetów na kolejne Sprinty
Jest to newralgiczne spotkanie, które ma wpływ na przebieg kolejnego sprintu, ponieważ na tym wydarzeniu powinny być omawiane zadania na najbliższą przyszłość - jeden/dwa sprinty do przodu. Dzięki regularnemu Backlog Refinementu zmniejszamy ryzyko niedomówien co do zakresu zadań i ograniczamy czas na omawianie zadań już w trakcie developmentu. Wynikiem dobrze przeprowadzonego Refinementu jest spriorytetyzowany Backlog, zdekomponowane zadania, oszacowane zadania i opisane zgodnie z DoR oraz DoD.
Kto uczestniczy?
Przede wszystkim na tym spotkaniu musi być Product Owner, który ma największą wiedzę na temat priorytetów i może odpowiedzieć na pytania zespołu co dane zadanie powinno dostarczyć. W drugiej kolejności, już wymieniony, to zespół deweloperski. To na ich barkach leży ustalenie jak dane zadanie zostanie dostarczone. Wykonują oni również dekompozycję zadań, szacują złożoność zadań, ustalają z Product Ownerem kryteria akceptacji. Nie zawsze, wszyscy członkowie zespołu deweloperskiego muszą uczestniczyć w tym spotkaniu. Takim przykładem jest np, spotkanie znane jako Three Amigos, na które zapraszamy jest:
Biznes - Jaki problem chcemy rozwiązać?
Development – Jakie rozwiązanie możemy zaproponować, aby rozwiązać problem?
Testing – Co może pójść nie tak?
Time box: nie powinien zajmować więcej niż 10% czasu sprintu, czyli ok 3,5 h na tygodniowy Sprint. Refinement charakteryzuje duża dowolność. Dobrą praktyką jest podzielenie tego spotkania na co najmniej dwie części. Osobiście, wprowadziliśmy Backlog Refinement jako codzienne 15 minutowe spotkanie po Daily Scrum, na którym omawiamy jedno wcześniej ustalone zadanie, a następnie spotykamy się na jednym dłuższym spotkaniu gdzie zadania są estymowane.
Sprint Review
Po co?
Jedno z dwóch spotkań odbywających się na końcu każdego sprintu. Podczas przeglądu sprintu zespół projektowy organizuje pokaz - w celu przedstawienia pracy wykonanej podczas sprintu i tego, czy zaplanowane zadania w zakresie planowania sprintu zostały dostarczone zgodnie z wymaganiami klienta. W trakcie tego spotkanie Product Owner akceptuje lub odrzuca elementy Backlogu wykonane przez zespół. Ma on również okazję aby dostarczyć informacje zwrotną Zespołowi.
Kto uczestniczy?
Przede wszystkim Product Owner oraz Zespół Deweloperski, ale mile widziani są wszyscy interesariusze zaangażowani w Projekt.
Time box: do 2 h w dwutygodniowym Sprincie. Raz na Sprint
Retrospektywa
Po co?
Jak możemy przeczytać w Scrum Guide “Retrospektywa Sprintu jest okazją dla Zespołu Scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wcielony w życie w najbliższym Sprincie”. Jego głównym celem jest usprawnienie procesu rozwoju podczas kolejnych Sprintu. Zawsze jest coś, co można poprawić, więc zespół projektowy analizuje całą współpracę podczas poprzedniego sprintu. Podczas tego spotkania każdy uczestnik powinien komentować rzeczy, które jego zdaniem poszły dobrze i które wymagają poprawy. Na koniec spotkania Zespół Projektowy powinien zdecydować, czy potrzebne są jakieś ulepszenia, i wybrać sposób na lepszą współpracę w następnym Sprincie.
Kto uczestniczy?
Na to spotkanie zapraszani są wszyscy biorący udział w projekcie, ponieważ na każdym etapie współpracy mogą istnieć elementy, które wymagają poprawy lub dopracowania. Pytanie jakie dosyć często się nasuwa, czy Product Owner powinien być również zaangażowany w ten proces. Z jednej strony możemy niechętnie opowiadać o problemach, tarciach wewnątrz zespołu przed klientem, ale z drugiej strony jak już wspomniałem być może ta współpraca na linii PO - Dev Team, też wymaga pewnych zmian i dobrze by było sobie o tym opowiedzieć. Z mojego doświadczenia robiliśmy tak, że PO był zapraszamy na co drugie spotkanie Retrospektywy lub na połowę czasu trwania tego spotkania. To pozwala na omówienie spraw związanych z Product Ownerem ale i spokojne przedyskutowanie sytuacji wewnątrz zespołowej.
Time box: do 1,5h w sprincie dwutygodniowym. Raz na Sprint
Retrospektywa zamyka nam cały cykl Sprintu. Kolejny Sprint rozpoczyna się na Sprint Planningu. Omówione powyżej spotkania są ważnymi elementami jakie wpływają na powodzenie projektu. Rezygnacja, z któregoś z nich może spowodować liczne problem z dostarczeniem produktu na czas lub w takiej formie jakiej sobie życzy Klient. W zwinnym zarządzaniu projektami podstawą udanej współpracy i dostarczenia odpowiedniego produktu jest rozmowa twarzą w twarz, aby w precyzyjny i jasny sposób omówić wszystkie zależności pomiędzy zadaniami, wyjaśnić sobie niejasności co do kryteriów akceptacji lub napotkanych problemów. Spotkania mają swoją chronologię występowania i dla płynności pracy zespołu należy ustalić stałe pory dnia oraz dni tygodnia w jakich one występują. Należy również pamiętać, że spotkania powinny być zorganizowane w odpowiedni sposób i należy trzymać się ram czasowych, dzięki czemu spotkania będę efektywne dla wszystkich i główne zadanie - czyli dostarczenie produktu, będzie szło sprawnie.
Komentarze
Prześlij komentarz