Jak zbudowany jest zespół Scrumowy?
W zespole deweloperskim, bo tak określa się zespół scrumowy, wyodrębnia się dwie dodatkowe role – Product Owner’a i Scrum Master’a. Product Owner to ktoś podejmujący kluczowe decyzje w projekcie co do kierunku, w którym podąża projekt. Scrum Master jest osobą wspierającą i dbającą o zespół, często określanym jako przywódca służebny (ang. Servant Leader). Początkowo jego rolę nieszczęśliwie tłumaczono po polsku jako Mistrz młyna, co wzbudza uśmiech na wielu twarzach. W Scrumie zespół deweloperski powinien być samoorganizujący się i interdyscyplinarny, a postępy swoich prac śledzi podczas codziennych spotkań zwanych Daily Stand-up, bądź Codziennym Scrumem.
Chciałbym zaznaczyć, że powyższy opis ma pozwolić jedynie na bardzo zgrubną orientację w podstawowych pojęciach i wydarzeniach, o których mówi Scrum. Należy przy tym pamiętać, że Scrum bez pracy zespołu nad Wartościami Scrumowymi (zaangażowanie, otwartość, szacunek odwaga i skupienie) oraz nad zrozumieniem celu ich wykonywania byłby tylko mechanicznym Scrumem, nie przynoszącym pożądanej wartości.
A więc od początku…
Wróćmy do przykładu, o którym pisałem na początku i zobaczmy, jak wykorzystując metodyki zwinne, w tym np. Scrum’a, mogłaby wyglądać jego historia. Rozpoczęlibyśmy od zidentyfikowania u naszego bohatera potrzeby dotarcia z domu do pracy. Zespół Scrumowy wie, że dobrze jest zaspokoić potrzebę klienta jak najszybciej, nawet kosztem pewnych wygód czy funkcjonalności. W odróżnieniu od podejścia kaskadowego, zespół Scrumowy mógłby postarać się dostarczyć klientowi np. hulajnogę. Pytając klienta o opinię i wrażenia z jazdy hulajnogą, dostalibyśmy bardzo cenne informacje co do kolejnej iteracji. Jej produktem mógłby być rower, którym przemieszczanie się w mieście mogłoby okazać się szybsze i wygodniejsze.
Czy mając rower i znając sytuację braku miejsc parkingowych pod biurowcem pracownik w dalszym ciągu zdecydowałby się na samochód? Doświadczenia jakie zebrał podczas dojazdów do pracy hulajnogą i rowerem, mogłyby poskutkować wybraniem jednak motocykla jako ostatecznego środka transportu. A może jednak już rower okazałby się wystarczający? Konstruując produkt przyrostowo, oprócz lepszego dopasowania rozwiązania do rzeczywistych potrzeb, byliśmy w stanie zaspokoić je już od samego początku.
Pracownik już pierwszego dnia, mimo pewnych niedogodności, mógł pojawić się w pracy. Podobnie w projektach informatycznych, szczególną uwagę zwraca się na to, aby produkt poddany zmianom, choć nadal pozbawiony pewnych funkcjonalności, był użyteczny na każdym etapie pracy nad projektem.
Zwinność i Scrum, choć wymagają zmiany naszych przyzwyczajeń, znacząco zmniejszają ryzyko niepowodzenia projektów, przez co zdobywają coraz większą popularność nie tylko w świecie IT. Warto się zastanowić, jak wiele przykładów bycia agile jesteś w stanie znaleźć wokół siebie.
Dlaczego nie każdy może zostać programistą?
Autor:
Sławomir Wołczkiewicz
Scrum Master i Senior Software Engineer
Zwinny od najmłodszych lat. Początkowo jedynie za sprawą sportów wszelakich, lecz zaraz po wejściu na rynek pracy odkrył to drugie oblicze zwinności. Scrum Master z doświadczeniem dewelopera, pomaga dogadać się programistom i ludziom biznesu. Inżynier, który stawia na wartościową komunikację z innymi. Miłośnik jedzenia w dużych ilościach, a jako taką formę trzyma dzięki dużym pokładom energii, która nie pozwala mu usiedzieć w domu.