O Scrumie słów kilka...

Jak kiedyś tworzyło się oprogramowanie? Firma dostała dokument z wymaganiami klienta, wyceniała, po akceptacji zabierała się do pracy, po np. roku dostarczała gotowe rozwiązanie które rzadko było tym czego oczekiwał klient. Można temu jakoś zapobiec? Tak, można wytwarzać oprogramowanie przy pomocy technik zwinnych, np Scruma.

Na czym to wszystko polega?

Praca w Scrumie polega na powtarzających się sprintach (iteracjach) podczas których zespół skupia się na zadaniach, które zostały zaplanowany na dany okres. Sprint kończy demo podczas którego klientowi przedstawiamy nowe funkcjonalności. Na spotkaniu ustala się priorytety na następny sprint i wszystko się powtarza.

Występujące role

Podczas wytwarzania oprogramowania najliczniejszą grupą stanowią programiści, testerzy i inni członkowie zespołu pracujący nad projektem. W Scrumie można znaleźć osoby z dodatkowymi obowiązkami.

Właściciel Produktu (Product Owner) - przedstawiciel klienta, który odpowiada za kontakt z całym zespołem, ustala priorytety zadań, odpowiada na pytania, tłumaczy niejasności, podejmuje decyzje wpływające na projekty lub kieruje do osób (ze strony klienta) które pomogą w danym problemie.

Pracą całego zespołu kieruje Scrum Master, który odpowiada za organizację całego procesu, umawianie spotkań, dba o “rytuały Scruma” oraz rozwiązuje problemy zespołu.

Rytułały w Scrumie

Planowanie

To spotkanie z product ownerem i wybranie funkcjonalności systemu, które chcemy dostarczyć klientowi w najbliższej iteracji. Historyjki (jak często nazywa się kolejne elementy systemu) spisane są w backlogu i stamtąd według priorytetów wybierane są elementy na najbliższy sprint. Zespół skupia się tylko na tych wyborach lecz jest świadomy odległego celu jaki chce osiągnąć klient, np zbudowanie nowego Facebooka.

Daily standup / daily meeting

Codzienne spotkania o ustalonej przez zespół zawsze tej samej godzinie. Podczas nich każdy członek odpowiada na trzy pytania: -co robił od poprzedniego standupu? -co zamierza robić w najbliższych godzinach? -czy coś blokuje jego pracę? Spotkania te pozwalają codziennie każdemu członkowi być na bieżąco z informacjami co dzieje się w projekcie. Umożliwia to bardzo dobry przepływ informacji, unikanie powtarzania czynności oraz znalezienie szybko pomocy w rozwiązaniu danego problemu.

Demo wewnętrzne

Często przed demem z klientem zespół podsumowuje swoją pracę w danym sprincie i sprawdza czy wszystkie funkcjonalności działają poprawnie. Umożliwia to wychwycenie elementów, które wymagają jeszcze poprawy i ostatnie poprawki.

Demo

Spotkanie z klientem, podczas którego demonstrujemy pracę wykonaną w danym sprincie.

Retrospekcja

Podsumowanie pracy zespołu i jej analiza. Na spotkaniu próbuje się znaleźć przyczynę niepowodzeń, elementy, które sprawdziły się podczas sprintu lub wskazanie zachowań, których brakowało. Podsumowaniem retrospekcji powinny być cele na następny sprint. Cele mogą być bardzo różne, np: -zwiększenie pokrycie kodu testami, -częstsza rozmowa z klientem umożliwiająca doprecyzowanie funkcjonalności. -aktualizacja komponentów projektu, -pilnowanie elementów Scruma.

Warto aby cele zostały spisane i omówione na następnej retrospekcji, czy zostały osiągnięte jeśli nie dlaczego itp.

Długość sprintu

Długość interacji ustalana jest przez zespół wraz z klientem. Moim zdaniem dwa tygodnie to optymalny wybór na organizację wszystkich rytuałów oraz dostarczenie nowych funkcjonalności.

W przypadku tygodnia, gdy planujemy pracę np. w poniedziałek pozostają nam trzy pełne dni pracy i demo w ostatnim dniu. Jest to krótki okres i często bardzo nerwowy.

Natomiast 3 i 4 tygodnie zbyt rozwleka cały proces. “Mamy przecież jeszcze 3 tygodnie…”. Informację zwrotną od klienta dostajemy o wiele rzadziej co uniemożliwia tak szybkie reagowanie na zmianę priorytetów. Tak samo jeśli w czasie sprintu klient będzie chciał prowadzić nową rzecz, trzymając się reguł Scruma gdzie nie dorzucamy nowych elementów podczas trwania sprintu możemy ją zaplanować dopiero na najbliższym planowaniu i pokazać gotową za np miesiąc.

Task Board

Całym sprintem zarządza się na tak zwanym Task Boardzie. Widać na nim wszystkie historyjki wraz z podziałem na zadania. Na poniższym screenie widać przykład. Każda historyjka (w dolnym rogu) posiada Story Pointy, jest to abstrakcyjna liczba świadcząca o trudności zadania. Jeśli zadanie jest podobne do wcześniej już wykonywanych lub zespół ma doświadczenie w tej dziedzinie zadanie będzie raczej proste czyli np 1, 2 lub 3. Jeśli zadanie wymaga użycia nowej biblioteki do integracji z portem kosmicznym może wymagać to więcej pracy i być dużym wyzwaniem.

Przy każdym zadaniu widać wartość liczbową. Jest to oszacowany przez zespół czas, który zajmie wykonanie danego zadania. Na planowaniu po rozpisaniu historyjek na zadanie następuje głosowanie nad wyceną zadań. Każdy z zespołu podaje swoją liczbę i następuje krótka dyskusja na ten temat. Może stać się tak że ktoś zaproponuje gotową bibliotekę które skróci czas pracy do 2 godzin gdy reszta zespołu szacowała cały dzień. W innym przypadku bardziej doświadczony programista może wskazać problemy na które można się natknąć w danym zadaniu i przekonać zespół aby zarezerwować więcej czasu na dany problem.

Inne zastosowania Scruma

Scruma można stosować nie tylko podczas budowania nowego systemu. Sprawdza się on bardzo dobrze przy już wdrożonym i działającym projekcie gdzie podczas sprintów dodajemy nowe funkcjonalności lub rozbudowujemy już gotowe.

Można go także stosować w takich obszarach jak sprzedaż gdzie są ustalane cele i codziennie zespół sprzedawców omawia co robił w celu np pozyskania nowego klienta.

Podsumowanie

Pracuję w Scrumie od prawie roku i bardzo go sobie chwalę. Problem stanowią czasem osoby nieprzestrzegające reguł gry i próbujące przepchać swoje wymagania podczas rozpoczętego trwającego już sprintu.

Moje doświadczenie może nie jest olbrzymie ale jeśli coś Was zaintersowało lub macie pytania piszcie. Powyższy tekst to tylko zajawka całego Scruma, można o nim na pewno napisać o wiele więcej

Linki, które warto odwiedzić:

• http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
• http://agilemanifesto.org
• http://agilemanifesto.org/principles.html
• http://agilemanifesto.org/iso/pl
• http://agilemanifesto.org/iso/pl/principles.html