Jak wspominałem w pierwszym artykule, który znajdziesz tutaj. Scrum to metodyka zarządzania o charakterze iteracyjnym oraz przyrostowym. Iteracjami są poszczególne sprinty trwające w zależności od projektu od 1 do 6 tygodni. (Dla małych i średnich projektów są to najczęściej 2 tygodnie). Natomiast poszczególnymi przyrostami definiujemy release, czyli wydania pewnych elementów w projekcie. Zespół scrumowy nie powinien liczyć więcej niż 9 osób. W przypadku zespołu liczącego kilkadziesiąt osób np. 50. Osoby powinny zostać podzielone na mniejsze samo organizujące się jednostki / zespoły. Scrum przebieg to drugi z cyklu artykułów poświęconych scrumowi w IT.
Scrum przebieg – Sprint w Scrumie
Jest to podstawowa jednostka czasu, w której dostarczany jest gotowy pakiet rozwiązań, przetestowanych i możliwych do zweryfikowania przez właściciela produktu (Product Ownera). Sprint nie powinien być krótszy od tygodnia oraz dłuższy niż miesiąc. Sama długość sprintu zależy od:
- Dostępności klienta
- Wielkości zespołu
- Specyfiki zadań (niektórych zadań nie da się podzielić na mniejsze)
- Doświadczenia zespołu w prowadzeniu projektów wg. SCRUM
Czym jest DoD – Definition Of Done?
Oznacza moment, w którym uznajemy, że opowieść użytkownika User Story została zrealizowana. Kryteria akceptacyjne zostały spełnione, a wartość biznesowa osiągnięta. Definition of done określana jest przez organizację i powinna wynikać z wcześniej przygotowanej procedury. Na przykład przez senior developera, architekta oprogramowania lub kierownictwo działu. Definition of Done powinna uwzględnić w pierwszej kolejności wymagania biznesowe klienta.
Przykłady wykorzystania DoD:
Testy jednostkowe lub funkcjonalne kończą się sukcesem. Kryteria akceptacyjne zostały spełnione (wdrożenie zgadza się z założeniami). Kod został pozytywnie oceniony przez senior developera lub architekta oprogramowania. Wymagania biznesowe klienta zostały zrealizowane.
Niezbędne narzędzia do planowania sprintu
Sprint Backlog (Rejestr Sprintu)
Głównym narzędziem do planowania sprintu jest zbiór User Stories wybranych przez zespół do realizacji w danym sprincie. Backlog stanowi informację o tym, czym zespół zajmuje się podczas trwania sprintu. Umożliwia śledzenie postępu realizacji prac.
Planning Poker
Technika szacowania czasochłonności historii użytkownika podobna do gry w pokera. Każdy programista wykłada kartę reprezentującą jego szacunek. Jeżeli są rozbieżności – dyskutuje się o nich aż do uzyskania konsensusu.
Team velocity
Pojemność zespołu jest to ilość pracy, jaką zespół jest w stanie wykonać podczas sprintu. Często przejmowaną jednostką na standardowy dzień pracy jest 6 rbh / dziennie.
Estimation
Jest to oszacowane ilości godzin na wykonanie danego zadania.
Planowanie sprintu (Planning)
Celem sprintu jest określenie zadań do wykonania w określonym czasie. W tym wskazanie elementów projektu, które mają zostać ukończone DoD (Definition of Done). W przypadku Developmentu sklepu internetowego mogą być to elementy strony (header, stopka, cart, slider lub home page). Product Owner wraz z członkami zespołu wybierają w pierwszej kolejności funkcjonalności, które powinny zostać wykonane w danym sprincie. Rola Product Ownera podczas sprintu sprowadza się do określenia priorytetów na dany sprint z punktu widzenia biznesowego lub klienta.
Rozpoczęcie Sprintu (Przebieg)
Sprint rozpoczyna się po planningu, który nie powinien trwać więcej niż 4h dla sprintu 2 tygodniowego. Kolejnym etapem jest daily stand-up, trwający około 15 minut na stojąco. Wszyscy członkowie zespołu w tym czasie rozmawiają o przebiegu projektu, jego problemach, czy wyzwaniach. Podczas trwania stand-upu każdy z trzech członków stara się odpowiedzieć na 3 główne pytania:
– Co zrobiłeś?
– Co planujesz robić?
– Jakie masz blokady?
Podsumowanie Sprintu
Kolejnym etapem jest podsumowanie sprintu, które polega na prezentacji rzeczywistego, działającego produktu dla klienta. Zespół prezentuje ukończone moduły lub funkcjonalności. Natomiast prace niezaakceptowanie przez klienta wracają do backlogu. Po prezentacji rozwiązań dla klienta zespół przechodzi do retrospektywy.
Retrospektywa Sprintu
Retrospektywa Służy szczerej ocenie pracy podczas sprintu, Odpowiada na pytania: Co poszło nie tak? Co poszło dobrze? Uczestniczą w nim Product Owner Scrum Master oraz The Team, nie powinna trwać dłużej niż godzinę przy sprincie 2 tygodniowym. W przypadku retrospektywy w Scrum’ie chodzi przede wszystkim o wyciąganie wniosków. Retrospektywa jest okazją dla zespołu na zbadanie swoich działań i stworzenie planu zmian i rozwoju, które zostaną wdrożone w kolejnym Sprincie.
Cały zespół analizuje więc drogę, którą przeszedł, podsumowując, to co było dobre i co warto wdrażać w kolejne Sprinty, a także to, co poszło źle i co warto na przyszłość unikać. Każdy zespół pracujący w Scrumie dąży do tego, żeby szukać usprawnień, stąd też planuje się retrospektywy, które jasno pokazują, jak przebiegała praca i które jej elementy są do poprawy.
Podsumowanie
Najważniejszymi elementami w przebiegu scruma to planning, codzienne daily (stand-up), podsumowanie sprintu oraz retrospektywa. Warto pamiętać, że zespół powinien być samo organizujący się oraz że każdy z członków powinien być traktowany na równi (bez podziału na osoby lepsze, gorsze).
Zobacz inne artykuły w kategorii: Project Management
