Szybkie wprowadzenie do SCRUM

Opis na podstawie doświadczenia w projektach IT

Czym jest Scrum?
Zwinną (ang. agile) metodą do zarządzania projektami.

Role w SCRUM
Zespół : tworzy nową wartość dodaną
Właściciel produktu (PO; Project Owner) : określa cel i definiuje zadania
Scrum Master : usuwa przeszkody podczas tworzenia wartości, pomaga zespołowi skoncentrować się na pracy
Klient : definiuje produkt jako całość, jest inwestorem

Sprint (iteracje)
Projekt nie jest tworzony na zasadzie: dokumentacja, design, implementacja, test, …. porażka
gdyż jak pokazał czas nie ma to sensu. Komiczne wizja całości i próba jej opisu jest zadaniem heroicznym i niemożliwym.
Podczas tworzenia projektu wychodzą na światło dzienne informacje i fakty, które mają znaczący wpływ na dalszą realizację projektu. Normalnie stary, dobry menedżer projektu wpływ ten kalkuluje w ryzyku.
Problem w tym, że jest to gra losowa, a w najlepszym wypadku strata (ang. waste).

Znacznie lepiej jest implementować w krótkich iteracjach. Scrum określa je jako sprint.
Sprinty trwają od 1 do 3 tygodni. Im krócej tym lepiej, gdyż maleje ryzyko, że coś robimy niewłaściwie, a także oddajemy produkty szybciej klientowi.
Sprint jest takim mini projektem. Podczas sprintu zespół powinien wytworzyć produkty, które odpowiadają definicji zrobione (ang. done; definition of done).
Co to oznacza, że jest zrobione?
Oznacza to, iż ta część projektu jest wykonana, przetestowana oraz klient, któremu prezentujesz produkt(y), też rozumie to jako wykonane. Jest to bardzo ważne, aby na końcu sprintu pokazać produkt klientowi (lub jego przedstawicielowi, lub Właścicielowi Produktu w razie projektów wewnętrznych). To on, nie zespół, ocenia czy produkt jest wykonany.

Jeśli coś nie jest wykonane, oznacza to zazwyczaj iż było zbyt optymistycznie oszacowane.
Jeśli coś jest wykonane ale klient widzi to inaczej, oznacza to, że zespół źle zrozumiał wytyczne.
Obie sytuacje mają wpływ na dalszą fazę projektu i minimalizują ryzyko, gdyż reakcja na problem jest natychmiastowa.

Pokaz / przegląd / review
Po skończonym sprincie następuje zaprezentowanie wykonanych produktów.
Jest to krótka prezentacja, w której uczestniczą członkowie zespołu, właściciel produktu, klient oraz Scrum Master.
Scrum Master pełni rolę moderatora i dba aby spotkanie się nie przedłużało.
Wygląda to następująco: osoba z zespołu będąca właścicielem zadania (odpowiedzialna), omawia co powinno zostać wykonane i przedstawia krótko produkt. PO i/lub klient zatwierdzają lub odrzucają rozwiązanie.

Retrospektywa
Po review następuje retrospektywa, czyli omówienie co poszło dobrze a co źle.
Jest to konstruktywna rozmowa na zasadzie feedback – NIGDY nie jest krytyką osób.
Cel jest prosty: wyeliminować problemy z następnych iteracji oraz optymalizacja zespołu.

Planowanie nowego sprintu
Właściciel produktu przedstawia zespołowi nowe produkty do wykonania.
Zespół na wstępnie dokonuje szacunku każdego produktu / zadania.
Następnie zespół, bez żadnych nacisków, decyduje ile zadań decyduje się wykonać podczas następnego sprintu.
Jest to sprint commitment.

Przerwanie sprintu
Jeśli zaszły ważne fakty mające wpływ na bieżący sprint to można go przerwać.
Faktem takim może być zaniechanie jakiejś funkcjonalności, polityczne zmiana priorytetów, itp.
Należy ponownie dokonać planowania następnego sprintu.

Zadania wykonane … można iść do domu
Jak sprint idzie dobrze i wykonaliśmy wszystkie zadania przed czasem, to można poprosić Właściciela Produktu o następne zadanie.
On(a) się ucieszy, a zespół będzie miał lepszą prędkość (ang. velocity).
Prędkość, pokazuje ile zadań jest w stanie wykonać zespół podczas jednego sprintu.
Jest to wartość empiryczna i powinna rosnąć, jak nasz zespół będzie się optymalizował w czasie. Oczywiście nie będzie rosnąć w nieskończoność :)

Mam nadzieję iż przybliżyłem trochę jak działa scrum.
W następnych artykułach przedstawię jak mierzyć prędkość oraz wykres wypalania – czyli jak przewidywać najbliższą przyszłość.

Informacje o @albgorski

Od 1999 roku profesjonalnie zajmuję się rozwijaniem oprogramowania. Głównie Java, ale także Groovy, PHP, HTML, JavaScript oraz Adobe Flex. Fascynują mnie metody wymiany danych, ich przechowywania oraz dostępowania. Jestem WIELKIM zwolennikiem Clean Code, TDD oraz agilistą (może lepiej lean-istą). Ekosystem Java dostarcza WIELE świetnych frawework-ów i bibliotek, a społeczność miłośników języka Java jest najlepsza pod słońcem :)
Ten wpis został opublikowany w kategorii agile, inżynieria opogramowania, scrum i oznaczony tagami , , , , , . Dodaj zakładkę do bezpośredniego odnośnika.

Możliwość komentowania jest wyłączona.