Scrum
Rozpoczynając projekt, zawsze naszym podstawowym celem jest zapewnienie rozwiązania:
- Spójnego z założeniami i realizującego wymagane funkcjonalności
- Spełniającego wysokie kryteria jakościowe
- Realizowanego w założonym czasie i budżecie
Z drugiej strony, bazując na naszym wieloletnim doświadczeniu, wiemy, że w każdym projekcie w czasie pracy pojawiają się nieprzewidziane elementy, które zmuszają do zmiany pierwotnych założeń i harmonogramów. W takich sytuacjach tradycyjne systemy zarządzania przedsięwzięciami nie sprawdzają się. Z tego powodu w naszych projektach zaczęliśmy stosować metodykę SCRUM (www.scrumalliance.org), znacznie lepiej dostosowaną do realizacji tak specyficznych prac jak tworzenie aplikacji. SCRUM zakłada, że sukces projektu zależy od:
- Ciągłej współpracy z Klientem w celu zrozumienia i zaspokojenia jego potrzeb
- Elastycznej reakcji na zmiany w czasie realizacji projektu
- Wykorzystania potencjału zespołu realizującego projekt i jego orientacji na cel
Jak działa SCRUM?
SCRUM stanowi tzw. lekką, iteracyjną metodykę realizacji projektów w IT. Realizacja projektu odbywa się w 2-4-tygodniowych iteracjach, tzw. Sprintach, których rezultatem jest stworzenie oprogramowania wysokiej jakości, spełniającego indywidualne potrzeby Klienta.
SCRUM określa trzy istotne role w projekcie informatycznym:
- Product owner – tworzy na podstawie wizji i rozwija wraz z Klientem wymagania biznesowe zawarte w product backlogu
- Scrum master – animator metodyki scrum w zespole, prowadzi codzienne spotkania z zespołem, dba o przestrzeganie reguł metodyki, zapewnia harmonijną współpracę, komunikację i usuwa przeszkody w otoczeniu projektu, maksymalizując produktywność zespołu
- Zespół – interdyscyplinarny, realizujący zadania w Sprincie
Żadna z tych ról nie ma przełożenia na tradycyjnego project managera. Wynika to z mechaniki procesu oraz wartości scrumu, który stawia na samoorganizację zespołu projektowego w celu stworzenia najlepszych rozwiązań technicznych dla realizowanych funkcjonalności.
Product backlog oraz Sprint backlog
Wybór realizowanych funkcjonalności opiera się o tzw. product backlog stanowiący uszeregowany zbiór wymagań funkcjonalnych opisanych jako tzw. historie użytkownika. Przy planowaniu kolejnej iteracji zespół wybiera wraz z product ownerem zbiór najwyżej sprioretyzowanych historii i przekształca je w listę odpowiednio zgranularyzowanych zadań technicznych potrzebnych do realizacji tych celów, tzw. sprint backlog.
Wybór historii użytkownika oraz przekształcenie ich w sprint backlog odbywają się na tzw. spotkaniu sprint planning. W ciągu sprintu zespół spotyka się na dziennym scrumie (daily scrum meeting), gdzie każdy członek zespołu mówi zwięźle o realizowanych przez siebie zadaniach. Duży nacisk kładzie się na przejrzystość informacji. Codzienne spotkania odbywają się przy sprint backlogu, na którym odnotowywane są codziennie postępy sprint teamu. Na podstawie aktualizacji tego dokumentu widoczne są postępy prac. Zespół ma także dostęp do product backlogu, co wspomaga lepsze zrozumienie zapisanych w nim wymagań.
Odpowiedzialności ról
Za prowadzenie prac w sprincie odpowiedzialny jest zespół i to właśnie na nim spoczywa odpowiedzialność dekompozycji celów sprintu na zadania techniczne oraz późniejsza ich realizacja.
W czasie iteracji zespół jest izolowany w zakresie realizowanych prac. Sprint backlog nie powinien być zmieniany przez zewnętrzną instrumentację, np. pod wpływem udziałowców projektu. Zmiany w sprint backlogu mogą być jedynie rezultatem analizy członków zespołu. Scrum master pomaga zespołowi w wykorzystaniu jego zbiorowego potencjału, nie pełniąc jednocześnie roli kierownika.
W czasie realizacji projektu kluczową kwestią jest rozwój product backlogu przez product ownera. Musi on stanowić aktualne odzwierciedlenie potrzeb klienta – odbiorcy projektu. Stopień realizacji zawartych w nim pozycji stanowi metrykę postępu prac. Product owner jest odpowiedzialny za ustalanie i zrozumienie historii użytkownika ze strony klienta oraz właściwe ustalenie priorytetów.
Jakość
Ważnym aspektem scrumu jest jakość oprogramowania. Podczas realizacji prac zadanie uważane jest za skończone jedynie w przypadku spełnienia ściśle określonych kryteriów, tzw. definition of done, które muszą być jasno określone przed rozpoczęciem sprintu.
Typowymi wymaganiami kodu są np.: zakodowany, zintegrowany, właściwie udokumentowany, inspektowany, pokryty testami jednostkowymi i integracyjnymi. Ponieważ celem sprintu jest dostarczenie kompletnej funkcjonalności, integralnym elementem prac zespołu jest testowanie tworzonej funkcjonalności.
Scrum jest również naturalnym środowiskiem do stosowania najlepszych praktyk w projektach software’owych: continuous integration, automatyzacji testów, TDD i refaktoryzacji kodu.
Koniec wieńczy dzieło
Sprint ma ściśle określoną długość (nie można zmieniać daty zakończenia sprintu w czasie jego trwania) i jest zwieńczony spotkaniem, tzw. sprint review, składającym się z dwóch części.
Pierwszą z nich stanowi demo. Na tym spotkaniu zespół pokazuje na żywo stworzone funkcjonalności i oczekuje reakcji product ownera i udziałowców (klienta). Spotkanie to pozwala na obserwację postępów zespołu przez klienta i służy wzajemnemu porozumieniu zespołu, udziałowców i product ownera ich reprezentującego.
