Podejście Scrum

Scrum jest chyba najbardziej znanym i popularnym podejściem z rodziny metodyk zwinnych. Często mówiąc Agile mamy na myśli Scrum i odwrotnie. Nie do końca powinniśmy mówić, że jest to metodyka, bardziej struktura, szkielet, ramy postępowania (ang. framework). Dzięki temu Scrum nie narzuca konkretnych praktyk lub technik rozwoju oprogramowania czy prowadzenia projektów, ale pozwala dopasować się różnych przypadków użycia.

Ogólne założenia do podejścia zostały opracowane już w 1986 roku, natomiast definicja Scruma w zastosowaniu do produkcji oprogramowania została sformalizowana przez Kena Schwabera w 1995 roku. Istotą postępowania jest dzielenie produktu na mniejsze, trwające przeważnie maksymalnie jeden miesiąc iteracje, które nazywamy sprintami. Po każdym sprincie zespół powinien być w stanie dostarczyć działający fragment produktu, który można przedstawić klientowi. Scrum jest często stosowany przy tworzeniu i rozwijaniu oprogramowania, ale możemy go równie dobrze odnieść do każdej innej dziedziny. Mówi się, że jest lekki, łatwy do zrozumienia, ale trudny do opanowania. Dlaczego tak się dzieje? Głównie z powodu trudności w zmianie nastawienia organizacji, zespołów projektowych. Ale jeżeli już się przekonamy do Scruma, efekty są zauważalne bardzo szybko.

Zobaczmy jak to wygląda na schemacie:

 O sprincie już sobie powiedzieliśmy, są to przedziały czasu, na których opieramy poszczególne etapy, dające namacalne rezultaty. Pozostałe pojęcia: 

• Product Backlog - lista rzeczy do zrobienia dla produktu, miejsce w którym wyznaczane są zadania dla zespołu. Backlog powinien być zawsze aktualny i pokazywać jasno co jeszcze mamy zrobić,
• Sprint Backlog - lista rzeczy do zrobienia w danym sprincie,
• Daily Scrum - codzienne, krótkie spotkania zespołu w celu weryfikacji co robimy, z czym mamy problemy i jaki jest najbliższy plan. Wydaje się czasem trudne do zorganizowania, ale bieżący codzienny status pomaga bardzo często szybko zareagować na nieprzewidziane komplikacje,
• Sprint Review - pod koniec sprintu zespół powinien zweryfikować jak wyglądał przyrost oraz zebrać opinie od interesariuszy odnośnie ich wymagań i oczekiwań,
• Retrospective - weryfikacja tego co zrobiliśmy, jak procesy i narzędzia wpłynęły na dostarczenie produktu, oraz co możemy zrobić żeby usprawnić proces. Bardzo fajna sprawa, pomaga eliminować błędy przy następnych projektach, rozwija zespół, tylko często brakuje na nią czasu :)

A jak wygląda zespół Scruma? Mamy takie role:

• Product Owner - do niego należy podejmowanie decyzji co do rozwoju produktu i zarządzanie czasem zespołu. Nadzoruje również Backlog. Aby projekt osiągnął sukces product owner musi być właściwie umocowany w organizacji i wszyscy muszą respektować jego decyzje. 
• Development Team -  odpowiada za zaplanowanie, organizacje i wykonanie prac. Zespół jest samoorganizujący się, bez podzespołów, a za rezultat odpowiedzialność ponoszą wszyscy członkowie,
• Scrum Master - odpowiada za wprowadzenie Scrum w życie, zrozumienie i przestrzeganie zasad frameworka. Wspiera także zespół poprzez budowanie współpracy i usuwanie przeszkód pojawiających się przed projektem (np. organizacyjnych). 

Celowo użyłem tutaj wyłącznie angielskich nazw, ponieważ praktycznie nie ma polskich odpowiedników, a oryginały są powszechnie stosowane. Każdy wie co znaczy backlog, sprint czy daily scrum. 

W praktyce podejście Scrum może wyglądać następująco (przykład kick-offa stworzenia nowej aplikacji i propozycja dostawcy odnośnie inicjacji projektu):

1. Tryb współpracy
   • projekt realizowany w uproszczonej formule Scrum,
   • wspólny zespół projektowy,
   • utrzymanie backlogu produktu, przeglądy zrealizowanej funkcjonalności po każdym sprincie,
   • długość pojedynczego sprintu - 2 tygodnie,
   • prezentacja produktu po każdym sprincie,
   • codzienne zdalne spotkania statusowe (postępy prac, ryzyka, problemy)
2. Produkty prac
   • harmonogram prac i lista zadań,
   • analiza i uszczegółowienie wymagań oraz przygotowany backlog,
   • dokumentacja - projekt techniczny, instrukcje, 
   • testy developerskie i integracyjne oraz scenariusze testowe,
   • finalnym produktem przetestowana i działająca aplikacja
3. Zarządzanie jakością
   • uszczegółowienie wymagań w ramach każdego sprintu,
   • testy wewnętrzne dostawcy w ramach sprintu,
   • backlog produktu i weryfikacja produktów sprintu przez zamawiającego,
   • testy akceptacyjne przeprowadzone przez zamawiającego
4. Zarządzanie zakresem i zmianą 
   • backlog produktu,
   • nowe wymagania do zakresu trafiają na koniec listy backlog,
   • szeregowanie listy backlog w porozumieniu pomiędzy dostawcą a zamawiającym,
   • dodatkowe funkcjonalności wykraczające poza zakres - temat eskalowany i rozpatrywany jako CR

Codzienne spotkania statusowe bywają problematyczne przy rozrzuconych zespołach, jednak wprowadzają przejrzystość i eliminują przestoje.

Certyfikacja Scrum wg scrum.org wygląda następująco: 

• Professional Scrum Master I
• Professional Scrum Master II
• Professional Scrum Product Owner I
• Professional Scrum Product Owner II
• Professional Scrum Developer I

W zależności od pełnionej roli możemy wybrać którąś z powyższych ścieżek. Ja polecam podejście do pierwszego certyfikatu - scrum master.