Planowanie sprintu
Planowanie sprintu jest początkowym etapem sprintu Scrum. Określa zakres i sposoby wykonywania pracy w trakcie sprintu. W planowanie zaangażowany jest cały zespół Scrumowy.
Sprint to jasno określony okres czasu, w którym musi zostać wykonana określona praca. Sprint wymaga planowania przed rozpoczęciem. Przede wszystkim musisz określić czas trwania i cel sprintu.
Na warsztacie planowania uzgadniana jest lista zadań i cel sprintu. Ważne jest, aby naładować zespół odpowiednią motywacją do pracy, tak aby każdy członek był nastawiony na sukces.
Jeśli sprint jest źle zaplanowany, może to doprowadzić zespół do porażki. Deweloperzy nie będą w stanie sprostać pokładanym w nich oczekiwaniom, bo zadania okazały się nierealne.
Pytania do rozważenia podczas planowania sprintu:
- Klient lub właściciel oprogramowania ogłasza cel sprintu, po drodze wyjaśniając, jak go osiągnąć. Zespół Scrumowy dowiaduje się, jakie zadania można wykonać w przyszłym sprincie, aby osiągnąć ten cel.
- Deweloperzy rozpowszechniają między sobą plan pracy, który jest uzgadniany z klientem oprogramowania.
- Klient (właściciel) produktu zawsze bierze udział w opracowaniu planu sprintu. Wyznacza cel, a zespół programistów musi dowiedzieć się, czy da się go osiągnąć w sprincie.
- Plan powinien wykorzystywać rejestr produktu, z którego można dodawać informacje do planu.
- Członkowie zespołu powinni zakończyć spotkanie dotyczące planowania z jasnym zrozumieniem tego, czego potrzebują, aby osiągnąć wynik. Możesz wyświetlić kolejność przyszłych działań w rejestrze sprintu.
Planowanie nie powinno przekraczać dwóch godzin tygodniowo. Scrum Master musi wszystkim wyjaśnić, że istnieją ograniczenia czasowe. Jeśli wszystkie problemy w pracy zostaną szybko rozwiązane, spotkanie może zakończyć się wcześniej niż zwykle. Nie ma minimalnego czasu trwania takiego spotkania.
Ocena zadania
W ocenie złożoności pracy nie trzeba przesadzać. Proces planowania nie wymaga dokładnej, ale przynajmniej przybliżonej oceny złożoności zabudowy. Zespół musi nie tylko zrozumieć cel sprintu, ale także porównać go z możliwościami swojego zespołu.
Aby ocenić złożoność, możesz użyć zwykłych rozmiarów odzieży dla wszystkich (L, XL, XXL). Oczywiście nie daje to gwarancji dokładności, ale jednak.
Aby ocena złożoności była dokładniejsza, potrzebne jest wzajemne zrozumienie. Członkowie zespołu powinni otwarcie dzielić się swoimi opiniami i nie bać się zadawać pytań właścicielowi produktu.
Krytyka wobec zespołu po zakończeniu pracy może doprowadzić do tego, że przy planowaniu kolejnego sprintu prognozy będą mniej optymistyczne. Pomoże to zespołowi uniknąć powtórzenia błędu i uchroni go przed negatywną oceną w przyszłości.
Ocena trudności w punktach, punktach i godzinach
Zazwyczaj zespoły programistyczne szacują złożoność swojej pracy w czasie. Ale niektóre zespoły Agile decydują się na ocenę trudności w punktach lub punktach. Jest to lepsze wskazanie całkowitego kosztu wymaganego do wdrożenia pozycji zaległości lub innego przydzielonego zadania.
Punkty przyznawane są na podstawie złożoności i objętości pracy. Ponadto brane są pod uwagę możliwe zagrożenia. Punktacja tą metodą pomaga skutecznie rozłożyć pracę na małe etapy.
Dzięki regularnemu stosowaniu metody punktowej podczas planowania, zespoły lepiej i dokładniej rozumieją, ile czasu będą potrzebować na wykonanie pracy. Oprócz tego są też inne zalety.
- Szacunek czasowy nie uwzględnia prac, które nie są bezpośrednio związane z projektem, choć na pewno się pojawią. Omawianie spraw związanych z pracą przez komunikator, organizowanie spotkań – to wszystko również wymaga czasu dla członków zespołu.
- Emocje mogą wpływać na wybór dat. Punktacja przy ocenie pracy eliminuje ten czynnik.
- Ocena złożoności pracy, a co za tym idzie szybkość realizacji zadań, może być różna dla każdego z zespołów. Praca z wykonanymi punktami nie może być traktowana jako jakikolwiek wskaźnik szybkości. Oznacza to, że zespół nie wywiera presji psychologicznej.
- Dzięki odpowiedniemu rozłożeniu kosztów pracy i złożoności można szybko i bezkonfliktowo podzielić punkty za wykonaną pracę pomiędzy uczestników.
- Liczba punktów otrzymywanych za wykonanie zadania zależy od jego złożoności, a nie od poświęconego czasu. Dlatego programiści będą myśleć o poprawie swojej wydajności, a nie o tym, jak długo to potrwa.
Wadą szacowania złożoności jest to, że jest często nadużywane. Na przykład tej metody nie można stosować do oceny pracowników.
Zespoły powinny korzystać z systemu punktacji, aby lepiej zrozumieć ilość przydzielonej im pracy i właściwie ustalać priorytety.
Codzienne spotkanie Scrumowe
Ważną rolę odgrywają warsztaty: na nich członkowie zespołu wymieniają się opiniami, komunikują i uzgadniają dalsze działania. Codzienne spotkania scrumowe są również potrzebne, aby podnieść ducha zespołu i ogłosić aktualne wiadomości.
Stand-up to krótkie spotkanie kluczowych uczestników projektu: właściciela oprogramowania, programistów i scrum mastera. Struktura stand-upu składa się z trzech pytań.
- Co udało nam się wczoraj zrobić?
- Nad czym dzisiaj pracujemy?
- Co przeszkadza nam w osiąganiu wyników?
Zadawanie tych pytań stymuluje rozwój i pomaga zidentyfikować problemy w zespole. Kiedy każdy uczestnik komunikuje, w jaki sposób pomaga osiągnąć wspólny cel, poprawia to wzajemne zrozumienie w zespole.
Należy pamiętać, że nie ma jednego szablonu, jak prowadzić stand-upy. Każdy zespół odbywa spotkania według własnego modelu, opartego na charakterystyce zespołu.
A teraz omówmy, co jest potrzebne do idealnego stójki i zapoznajmy się z przykładami skutecznych stójek.
Najpierw musisz wybrać czas, który pasuje wszystkim. Zwykle stand-upy dla zespołów z tego samego biura odbywają się na początku dnia roboczego - między 9 a 10 rano. Daje to czas na lepsze zaplanowanie harmonogramu dnia. Jeśli członkowie zespołu pracują w różnych regionach, wybierany jest czas, który każdemu odpowiada. Na przykład, jeśli niektórzy członkowie zespołu mieszkają w Kalifornii i Sydney, stand-up zaczyna się o 15:30 czasu kalifornijskiego. Oczywiście stand-up po obiedzie nie dla każdego jest wygodny, ale pozwala na kontakt z kolegami po drugiej stronie oceanu.
Śledź produktywność na stojąco. Nie przetrzymuj spotkania zbyt długo – koncentracja uwagi powinna pozostać na najwyższym poziomie. Jeśli to możliwe, stój w pozycji stojącej nie dłużej niż 15 minut.
Użyj piłki. Można je rzucać do siebie po kolei. Więc wszyscy będą zaangażowani w dyskusję. Ta gra pomaga utrzymać uwagę w grupie. Użyj retrospekcji zespołu. Stand-upy są wykorzystywane w wielu metodykach Agile, co nie przeszkadza nam w omawianiu skuteczności stand-upów na retrospekcjach. Ktoś spotyka się codziennie, inne zespoły - kilka razy w tygodniu. Jeśli zespołowi trudno jest odnieść korzyści ze stójki, znajdź tego przyczyny i coś zmień.
Przegląd sprintu
Przegląd wiosenny przeprowadzany jest na ostatnim etapie sprintu. Konieczne jest sprawdzenie przyrostu produktu i dopasowanie backlogu. W przeglądzie wyników sprintu uczestniczy cały zespół scrumowy oraz wszyscy interesariusze. Spotkanie odbywa się w luźnej formie, aby poprawić interakcję uczestników projektu.
Przegląd wyników sprintu obejmuje następujące elementy:
- Właściciel oprogramowania pokazuje, co z backlogu zostało zrealizowane, a co nie.
- Programiści rozmawiają o tym, co poszło dobrze, gdzie pojawiły się trudności i jak zostały wyeliminowane.
- Zespół deweloperski pokazuje wyniki swojej pracy podczas sprintu oraz jaki przyrost produktowy otrzymał.
- Product Owner dzieli się swoimi przemyśleniami na temat aktualnego backlogu. Podaje również prognozę na kolejny cel i termin jego realizacji.
- Wszyscy dyskutują, co najlepiej zrobić dalej, w oparciu o ocenę rynku i zainteresowania użytkowników.
- Dochodzi do wymiany poglądów na temat harmonogramu, budżetu i perspektyw uzupełnienia zaległości.
Rezultatem jest zaktualizowany backlog z nowymi celami dla kolejnych sprintów. Backlog można zmienić, jeśli sytuacja tego wymaga.
Retrospektywa sprintu
Retrospektywa Sprintu to warsztat, który omawia, jak poprawić przepływ pracy. Tworzy również plan doskonalenia dla następnego sprintu. Spotkanie zwykle odbywa się po przeglądzie sprintu i trwa nie dłużej niż trzy godziny. Spotkanie prowadzi Scrum Master.
Główne cele Retrospektywy Sprintu to:
- Analiza sprintu (praca uczestników, wyniki i problemy).
- Omów możliwe rozwiązania usprawniające przepływ pracy w kolejnych sprintach.
- Stworzenie planu wdrożenia usprawnień przez członków zespołu w trakcie realizacji projektu.
Scrum Master zaprasza członków zespołu do zgłaszania sugestii, jak poprawić efektywność rozwoju. Zespół omawia propozycje i sugeruje określone sposoby i techniki ich realizacji.
Na koniec Retrospektywy Sprintu zespół powinien wskazać kilka sugestii ulepszeń do wdrożenia w następnym sprincie. Propozycje można wdrożyć w dowolnym momencie, ale Sprint Retrospective daje możliwość głębszego spojrzenia na ich ewentualną adaptację z punktu widzenia zespołu.
Na tym kończymy nasze omówienie metodologii Scrum. Możesz dowiedzieć się więcej na ten temat w dokumentacji tematycznej lub na swoim pierwszym miejscu pracy.