Zarządzanie projektami w SCRUM

Jak to działa?

W praktyce oznacza to, że cały proces jest stale optymalizowany i dostosowywany do potrzeb klienta. zespół i produkt przez cały okres pracy nad projekt. Odpowiedzialność za zarządzanie rozwój produktu jest rozłożona pomiędzy właściciela produktu (PO) i zespół projektowy. PO jest osobą odpowiedzialną za podejmowanie decyzji związanych z kierunkiem rozwoju produktu i ma holistyczną "wizję" tego, czym produkt ma się stać. Zarządzanie zadaniami opiera się na tablicy Kanban (w połączeniu z tablicą sprint funkcjonalność zwana tablicą SCRUM). Każdy uczestnik procesu może dodawać zadania do zaległości, ale PO jest odpowiedzialny za ustalanie priorytetów. Zespół projektowy jest odpowiedzialny za "przekształcenie" pomysłów PO w konkretne zadania i zaplanowanie ich realizacji.

Przebieg cyklu

Proces podzielony jest na iteracje (sprinty). W ramach jednego sprintu trwającego około 2 tygodni, zespół projektowy wdraża i testuje wcześniej zaplanowaną część funkcjonalności.

Sprint rozpoczyna się od "planowania", podczas którego zespół omawia i przygotowuje zadania, które zostały wcześniej przygotowane i ustawione przez PO na szczycie backlogu. Następnie szacowana jest trudność tych zadań i przyznawane są im punkty w zależności od trudności. Przy względnie stałym składzie zespołu i warunkach pracy, liczba punktów wykonywanych w każdym sprincie jest powtarzalna i pozwala na planowanie przyszłych prac. Pod koniec spotkania planistycznego wybierane są zadania o łącznej liczbie punktów do wykonania w ramach jednego sprintu i rozpoczyna się nowy sprint.

W połowie sprintu następuje grooming. Jest to spotkanie, na którym OP przedstawia zespołowi dalsze oczekiwania i pomysły, a zespół projektowy analizuje je, dzieli na mniejsze zadania i przedstawia OP możliwe sugestie. Planując przyszłe zadania, OP konsultuje się z analitykami, użytkownikami, UX i grafikami. Dodatkowe analizy (rynek badania i nauka o danych) są często potrzebne na tym etapie. Dopiero po przeanalizowaniu i sformułowaniu tzw. User Story, PO publikuje je w backlogu. Historyjka użytkownika powinna zawierać informacje na temat tego, czego OP oczekuje od danego zadania lub grupy zadań oraz jakie kryteria należy zastosować, aby rozpoznać, czy zadanie zostało ukończone.

Podczas sprintu codziennie odbywają się tak zwane "Daily standup meeting". Na spotkaniach tych każdy deweloper opowiada reszcie zespołu o tym, co robił przez ostatni dzień i ewentualnie informuje o ewentualnych problemach czy blokadach, które utrudniają mu dalszą pracę. Dzięki takiej wymianie aktualnego statusu możliwe jest znacznie szybsze wychwycenie potencjalnych konfliktów pomiędzy poszczególnymi zadaniami i uniknięcie sytuacji, w której deweloper utknie na jakimś problemie i nie będzie mógł poczynić postępów w jego realizacji. Codzienny standup z założenia ma być jak najkrótszy, ale jednocześnie spełniający swoją rolę. Stała formuła spotkania zachęca zespół do jego skracania.

Podczas sprintu zadania są przesuwane na tablicy SCRUM zgodnie z ich aktualnym statusem. Wybór kolumn zazwyczaj odpowiada systemowi pracy firmy lub zespołu i jest powiązany z systemem kontroli wersji i częstotliwością wydań. Dla nas wygląda to następująco:

• Do zrobienia - zadania czekające na wykonanie
• W toku - zadania w toku
• Kod review - zadania oczekujące na sprawdzenie przez innego dewelopera
• Przygotowane - zadania sprawdzone i zaakceptowane przez deweloperów
• Etapowe - zadania znajdujące się w instancji przejściowej i oczekujące na zatwierdzenie PO.
• Zaakceptowane - zadania zaakceptowane przez PO
• Gotowe - gotowe zadania znajdujące się na instancji produkcyjnej

Po zakończeniu sprintu odbywa się retrospektywa. Jest to spotkanie poświęcone optymalizacji pracy. Cały zespół omawia, co poszło dobrze w ostatnim sprincie, a co wymaga poprawy. Często odnosimy się również do poprzedniej retrospektywy i sprawdzamy, czy udało nam się wdrożyć wszystkie pomysły na usprawnienie pracy. Problemy omawiane podczas retrospektywy mogą być różne - od narzędzi deweloperskich, przez presję, trudności z zadaniami, po problemy z komunikacją (zarówno między deweloperami i zespołem, jak i PO).

Obowiązki SCRUM Mastera

Osobą odpowiedzialną za prawidłowy przebieg procesu SCRUM jest SCRUM Master. Jest to często najbardziej niezrozumiała rola w zespole. SCRUM master nie ma mocy decyzyjnej. Decyzje podejmowane są wspólnie przez zespół i PO, natomiast rolą SCRUM mastera jest usuwanie przeszkód w prawidłowym przebiegu procesu.

Obowiązki mistrza SCRUM obejmują następujące elementy:

• Prowadzenie spotkań SCRUM, w tym planowanie, przygotowanie, codzienne spotkania standup i retrospektywy.
• Zapewnienie, że zadania na tablicy SCRUM są regularnie przygotowywane przez zespół i ustalane przez PO.
• Funkcjonowanie jako łącznik między zespołem a PO; dlatego często to SCRUM master ma trudną rolę w tłumaczeniu języka programistów na język biznesowy i odwrotnie. Wynika to z faktu, że w naszej firmie SCRUM master jest programistą, a więc osobą techniczną. Ogólne ramy pracy SCRUM mastera tego nie wymagają.
• Powstrzymywanie zespołu przed zbaczaniem z tematu i pilnowanie porządku obrad podczas spotkań
• Dbanie o atmosferę w zespole - głównie podczas spotkań.
• Rozwiązywanie konfliktów w przypadku ich wystąpienia.

Czytaj także:

• Dobre praktyki Codest dotyczące tworzenia oprogramowania. Nasze podejście do customer journey
• Dobre praktyki Codest dotyczące tworzenia oprogramowania: GitFlow
• Dobre praktyki Codest dotyczące tworzenia oprogramowania. Jak wdrożyć analizę wymagań?