Bruce Lee w serialu „The Way of the Intercepting Fist” radzi uczniowi, by był jak woda. „Opróżnij umysł, bądź bezforemny, bezkształtny jak woda. Wlewasz wodę do filiżanki, staje się filiżanką, wlewasz ją do butelki, staje się butelką […]”. Słowa mistrza kung-fu mają nie tylko odniesienie do sztuk walki, ale także do życia, w tym do… zarządzania projektami. Dowiedz się więcej o tym co to jest Scrum!
Trzymanie się sztywnych ram projektu jest ograniczające – tak samo jak niedostosowywanie się do przeciwnika czy zmieniających się sytuacji życiowych.
Sprint – trwający maksymalnie cztery tygodnie etap prac nad projektem. Planujemy go z uwzględnieniem budżetu, a najważniejsze są dla nas potrzeby zawarte w backlogu produktu, za który odpowiada product owner.
Backlog produktu – uszeregowana lista potrzeb, czyli wymagań, funkcjonalności, jak np. przypadki użycia.
Pamiętajmy, że początkowy pomysł może nie spełniać oczekiwań interesariuszy, dlatego warto o rozważenie scruma, czyli zwinnego zarządzania projektem, na który składają się sprinty.
Scrum, czyli poprawki na bieżąco
– W wypadku scruma każdy sprint kończy się sukcesem. Gdy pod koniec sprintu otrzymamy informacje zwrotne od interesariuszy na temat funkcjonalności, która nie jest zgodna z ich oczekiwaniami, nie stanowi to problemu – przybliża w rozmowie z The Story Journal Paweł Lasek, scrum master i agile coach w Link4.
Ekspert twierdzi, że można bardzo szybko zastąpić daną funkcjonalność inną lub zaoszczędzić pieniądze poprzez porzucenie pomysłu. Dzięki temu złe decyzje widoczne są już na początku procesu. Tymczasem w modelu kaskadowym (waterfall model) musimy poczekać dłuższy okres, zanim dostaniemy opinię z rynku.
Szukasz software house?
Na czym polega kaskada?
W kaskadzie potrzebne jest dokładne udokumentowanie i ukończenie poprzedniej fazy, by móc przejść do kolejnej, podczas gdy w scrumie analiza, development i testy mogą odbywać się w tym samym czasie.
Model kaskadowy składa się z kilku etapów (faz) prac:
1. Określania wymagań – określamy szczegółowe wymagania wobec tworzonego systemu.
2. Projektowania – tworzymy dokładny projekt systemu, który spełni ustalone wcześniej wymagania.
3. Implementacji – implementujemy projekt w konkretnym środowisku programistycznym, pamiętając o testach poszczególnych modułów.
4. Testowania – integrujemy moduły, testujemy podsystemy i oprogramowanie.
5. Konserwacji – pozwalamy, by z oprogramowania skorzystali użytkownicy, a następnie usuwamy błędy, dokonujemy zmian i rozszerzamy funkcje systemu.
Elastyczne scrumowe podejście
Otwartość na ciągłe zmiany daje nam większe szanse na udany projekt. Jake Knapp, twórca design sprintu, jednej z pochodnych metodyki agile, w książce „Pięciodniowy sprint” przytacza historię powstania strony internetowej Blue Bottle Coffee.
Witryna doczekała się 15 szkiców. Pracownicy za najlepszy uznali szkic, który upodobnił wygląd e-sklepu do kawiarni Blue Bottle Coffee.
Rozwiązanie było oryginalne. Co więcej, przemawiało za nim to, że wygląd Blue Bottle Coffee był powszechnie chwalony. Stworzono więc prosty prototyp. Okazało się jednak, że klienci uznali projekt za „tandetny” i „niegodny zaufania”, a do gustu przypadły im dwa bardziej konwencjonalne prototypy.
Postawienie wyłącznie na projekt, który najbardziej podobał się zespołowi, byłoby dużym błędem. To elastyczność zapewniła sukces: uruchomienie nowej witryny Blue Bottle Coffee spowodowało dwukrotny wzrost sprzedaży.
Pamiętajmy jednak, że scrum czyli zwinne zarządzanie projektami, podczas którego projekty ulegają ciągłym zmianom, nie sprawdzi się w każdej firmie (sprawdź więcej we wcześniejszym wpisie: Lean Management). Przedsiębiorstwo, które korzysta z dobrodziejstw metodyki agile, potrzebuje pracowników, którzy nie boją się ponoszenia odpowiedzialności, a wychodzenie z nowymi pomysłami jest dla nich naturalne.
– Pracownik, który trafia do zespołu scrumowego, powinien lubić pracę w grupie. Z jednej strony jest to po części praca indywidualna, ale towarzyszy nam cel zespołowy. Jest to wówczas na pewno większa odpowiedzialność niż w wypadku kaskady, gdzie dana osoba odpowiada tylko za swoją część prac – mówi Paweł Lasek.
Inaczej niż w kaskadzie, scrum zakłada, że analiza, development oraz testy mogą odbywać się równolegle. Osoby przyzwyczajone do kaskady powinny wykazać się więc większą elastycznością.
– Tacy pracownicy muszą czasem wyjść ze strefy komfortu, niekoniecznie zajmując się tym, czym zajmowali się jeszcze do niedawna. Załóżmy, że jestem testerem lub analitykiem – dotychczas moje zadania polegały na testowaniu albo na analizowaniu. Tymczasem teraz, kiedy staję przed projektem scrumowym, moje kompetencje niekoniecznie są potrzebne do osiągnięcia celu zespołu – twierdzi scrum master.
Ważną rolę w tworzeniu zwinnego zarządzania odegrał m.in. Jeff Sutherland, współautor „Scrum Guide” („Przewodnik po Scrumie: Reguły gry”), który powstał w latach 90., aby opisać i przybliżyć zasady dotyczące scruma, czyli zwinnego zarządzania projektami. | Fot. commons.wikimedia.org
Czym jest agile?
Metodyka agile narodziła się w latach 90. w Dolinie Krzemowej, podczas gdy sama nazwa pojawiła się oficjalnie dopiero w 2001 roku, kiedy opublikowano „Manifest Agile”. Manifest powstał dzięki spotkaniu 17 przedstawicieli amerykańskich firm programistycznych, którzy ustalili, jak miałby wyglądać opis, który składałby się na metodyki zwinności – zasady usprawniające prace nad projektami.
„Manifest Agile” wskazuje, że od procesów i narzędzi bardziej ceni się ludzi i interakcje, a od szczegółowej dokumentacji ważniejsze jest działające oprogramowanie. Od negocjacji umów ważniejsza jest zaś współpraca z klientem, a od realizacji założonego planu reagowanie na zmiany.
Agile to przeciwieństwo modelu kaskadowego, który opiera się na sztywnych schematach i nie dostosowuje się do zmieniających się potrzeb klienta. Agile jest w pewnym sensie odpowiedzią na dysfunkcje, które utrudniają pracę i powodują, że pracownicy nie wykorzystują w pełni swego potencjału, na czym cierpią same projekty.
W scrumie nadążamy za klientem
Podstawowym elementem metodyki agile jest scrum. Pod pojęciem scruma rozumiemy zwinne tworzenie produktu. Jego przygotowywanie podzielone jest na niewielkie etapy (sprinty), dzięki czemu zmiany są wprowadzane na bieżąco.
Sprint zaczyna się od pomysłu, następnie mamy gotowy do użycia produkt, konsultacje z klientem, przegląd i retrospektywę. Przegląd oznacza podjęcie decyzji dotyczącej tego, na co położyć nacisk w kolejnym sprincie, a retrospektywa polega na ocenie zespołu, tak żeby usprawnić jego pracę.
Klient rezygnuje z początkowego rozwiązania na rzecz innego? Nie ma problemu. Cechą charakterystyczną scruma są także prototypy, które można testować na użytkownikach i w razie potrzeby modyfikować.
– „Manifest Agile” opisuje sposób myślenia związany z zwinnym wytwarzaniem oprogramowania. Wytwarzanie oprogramowania jest złożonym procesem, tj. takim, w którym dużo rzeczy stanowi niewiadomą. Lecz w agile bazujemy na podejściu empirycznym, a nie przewidywaniu, które jest charakterystyczne dla kaskady – ocenia Paweł Lasek.
W scrumie ogromną rolę odgrywa zespół, który posiada różne, wzajemnie uzupełniające się kompetencje. Członkowie zespołu to jednak nie wszystko, ponieważ do stworzenia produktu potrzebujemy jeszcze product ownera i scrum mastera, który niczym kapitan na statku dąży do tego, by załoga dopłynęła do wytyczonego punktu.
– W kaskadzie często spędzamy dużo czasu nad analizą, bo zależy nam, by wynik końcowy był jak najlepszy. Wszystko odbywa się poprzez próbę przewidzenia, czy produkt będzie chodliwy – opisuje Paweł Lasek.
– Z kolei w podejściu zwinnym sprawdzamy, czy dany element działa, czy też nie. Robimy to, wypuszczając go na rynek, dzięki czemu otrzymujemy feedback. Informację zwrotną traktujemy jako jedyny wartościowy wskaźnik pod kątem danych. Jest to podstawowa różnica między agilem a kaskadą, gdzie zanim cokolwiek doczeka się premiery, na analizach spędza się zwykle wiele tygodni, miesięcy czy nawet lat – dodaje scrum master z Link4.
Pracownicy nie dostarczają produktu na sam koniec prac, tylko prezentują jego kolejne – działające – wersje w niewielkich odstępach czasu, czyli sprintach.
Paweł Lasek tłumaczy, że podejście zwinne wymusza na nas jak najszybsze wypuszczenie MVP (Minimum Viable Product), czyli początkowego, uproszczonego zarysu produktu.
Wszystko po to, by szybko zebrać feedback i na jego podstawie dostosować się do rynku. Paweł Lasek sądzi, że jest to właśnie największa przewaga podejścia scrumowego nad kaskadowym.
– Kolejną przewagą jest efektywność w środowisku złożonym. Pamiętajmy, że mamy bardzo wiele rzeczy, których nie wiemy. Nie jesteśmy w stanie przewidzieć procesu wytwarzania danego produktu od A do Z. Są to aplikacje lub inne produkty cyfrowe, które okazują się skomplikowane od strony technicznej. Przy pracach nad tego typu produktami najlepsze jest właśnie podejście empiryczne i zrównoleglanie pracy – przekonuje Paweł Lasek.
Zrównoleglanie fazy analizy, testów, developmentu czy też wdrożenia pozwala nam na bieżąco wychwytywać wiele ryzyk i od razu sobie z nimi radzić. W podejściu kaskadowym często zaś czekamy na ostatnią fazę, by dowiedzieć się, że coś nie działa, toteż w scrumie oszczędzamy czas.
Pod koniec sprintu otrzymujemy gotowy produkt, choć „gotowy produkt” to pojęcie umowne – może to być np. działający uproszczony prototyp. Dzięki temu klient będzie wiedział, czy kierunek, w którym zmierza projekt, pokrywa się z jego oczekiwaniami. Co innego, gdy stawiamy na kaskadę, nie wiedząc, jak wyglądają prace nad projektem, by po roku otrzymać jego finalną wersję, która nie spełnia naszych oczekiwań.
To wszystko sprawia, że scrum sprawdza się idealnie, kiedy chcemy nadążyć za zmieniającymi się wymaganiami klienta. Wymagania doczekały się dotychczas wielu definicji, ale przytoczmy jedną z najtrafniejszych, która pochodzi z książki „Specyfikacja oprogramowania. Inżynieria wymagań” Karla Wiegersa i Joy Beatty:
„Wymagania stanowią specyfikację tego, co powinno zostać zaimplementowane. Opisują, jak powinien zachowywać się system albo określają jego właściwości lub atrybuty. Mogą nakładać ograniczenia na proces tworzenia systemu”.
Przyrost produktu – to, co zespół powinien dostarczyć na koniec sprintu, tj. działający produkt rozszerzony o nowe możliwości (funkcjonalności) w stosunku do wersji z poprzedniego sprintu.
Product owner tworzy listę potrzeb na dany sprint, a pod jego koniec prezentuje efekty prac klientom i użytkownikom w celu otrzymania informacji zwrotnej. To wszystko poprzedza planowanie sprintu, które ograniczamy do maksymalnie ośmiu godzin – o ile sprint trwa miesiąc. Podczas takiego planowania odpowiadamy na dwa pytania:
- Co może zostać dostarczone w ramach przyrostu, będącego rezultatem nadchodzącego sprintu?
- W jaki sposób dla uzyskania przyrostu wykonamy pracę?
12 zasad programowania zwinnego:
1. Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
2. Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
3. Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
4. Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
5. Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
6. Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
7. Działające oprogramowanie jest podstawową miarą postępu.
8. Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
9. Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
10. Prostota – sztuka minimalizowania ilości koniecznej pracy – jest kluczowa.
11. Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
12. W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
Nieoczywista rola scrum mastera
Rola product ownera okazuje się całkiem jasna, lecz to, czym zajmuje się scrum master, nie jest wcale takie oczywiste. Bywa, że jego zadania są mylone z zadaniami projekt menadżera, tymczasem wyzwania, których się podejmuje, mają zupełnie inny charakter.
– Rola scrum mastera jest bardzo niezrozumiała w organizacjach. I to mimo różnych szkoleń i dość dużej wiedzy, którą można znaleźć w internecie. Rozumiemy, czym zajmuje się zespół deweloperski, który wie, jak ma wyprodukować produkt. Znamy także rolę product ownera, którego zadaniem jest wskazanie tego, co należy wyprodukować i jak miałby wyglądać produkt – objaśnia Paweł Lasek.
Specjalista uważa, że gdy mowa o roli scrum mastera, natrafiamy na mity i znaki zapytania. Dezorientację powoduje to, że w projektach kaskadowych występuje rola projekt menadżera, który odpowiada za cały projekt i jest „spinaczem” do wszystkiego.
Z jednej strony scrum master pomaga planować prace w zespole, a z drugiej odpowiada za to, jak pracownicy wykonają swoje zadania. W podejściu scrumowym taka rola nie występuje, bo zespół scrumowy dzięki samoorganizacji nie wymaga koordynacji.
– Dbanie o proces scrumowy to jeden z najważniejszych obowiązków scrum mastera, tak by scrum był stosowany według tego, co opisuje „Scrum Guide”. I choć ten przewodnik jest łatwy do zrozumienia, to okazuje się bardzo trudny do zaimplementowania. Do tego stopnia, że potrzeba scrum mastera. Inaczej zespoły nie poradziłyby sobie same. Jestem scrum masterem już od wielu lat i często widzę, jak wiele zmian pod kątem ról i obowiązków trzeba wdrożyć w organizacji, żeby scrum miał w ogóle szansę przynieść efekty – stwierdza Paweł Lasek.
Co robi scrum master, podczas gdy nie jest to rolą projekt menadżera
Paweł Lasek omawia dla The Story Journal to, za co jego zdaniem odpowiada scrum master:
1. Facylituje spotkania i wydarzenia scrumowe.
2. Wspiera samoorganizację.
3. Jest coachem zespołu i strażnikiem procesu scrumowego. Jeśli mamy ramy scruma (scrum to nie metodyka czy metoda, tylko ramy), zespoły mogą używać technik, które uważają za słuszne.
Inspekcja – regularna kontrola postępów prac.
I choć scrum master nie narzuca technik, dba o to, by takie ramy, jak inspekcja, adaptacja i transparentność były stosowane. Wspaniale, gdy pod tym wszystkim kryje się zaufanie.
Adaptacja – kiedy dostrzegamy rozbieżności w stosunku do oczekiwanych rezultatów projektu, dokonujemy zmian.
Rolą scrum mastera jest właśnie to, by w firmie można było przekazywać transparentnie różnego rodzaju informacje, które z jakichś powodów dotychczas były nietransparentne. Jedną z najtrudniejszych rzeczy jest sprawienie, żeby ludzie zaczęli sobie ufać.
4. Scrum master nie jest też menadżerem. Częstym mitem jest to, że scrum master jest menadżerem (tak jak projekt menadżer czy menadżer liniowy) albo że zarządza zespołem. Ale tak nie jest. Scrum master to lider służebny. Stara się usuwać przeszkody, jakie zgłasza mu zespół, który widzi, że pojawiły się jakieś problemy podczas wytwarzania oprogramowania na liniach ludzie-interakcje oraz procesy-narzędzia.
5. Pracuje z organizacją nad uczynieniem jej bardziej „zwinną”. Innymi słowy, nad wszystkimi procesami, które występowały do tej pory. Ważne, by scrum master miał ciągle w głowie „Manifest Agile” – to, że ludzie i interakcje są ponad procesami i narzędziami, a działające oprogramowanie ponad szczegółową dokumentacją.
6. Mimo że „Manifest Agile” zawiera tylko cztery sentencje, a „Scrum Guide” 17 stron, na scrum mastera spada ogrom pracy, którą trzeba wykonać, aby organizacje przechodziły transformację z podejścia kaskadowego na zwinne.
Oznacza to zmianę całej masy różnych rzeczy: od struktur w organizacji i zespole, po hierarchiczne podejmowanie decyzji, które występowało wcześniej. Decyzje podejmuje zespół, gdzie wszyscy są na równym poziomie w hierarchii.
Nie ma nikogo, kto rządziłby innymi, każdy ma swój zakres obowiązków i wszystkim towarzyszy wspólny cel.
7. Scrum master pracuje także z product ownerem. Pomaga mu w przygotowywaniu backlogu, zarówno pod kątem wyznaczania celów, jak i hipotez do zwalidowania, na które naprowadza MVP.
Początkujący product ownerzy często wymagają bardzo dużego wsparcia w wypadku pracy w scrumie i komunikacji z zespołem scrumowym. Wymaga to od scrum mastera wręcz shadowingu (uczenia się pracy innych poprzez obserwację), co daje wsparcie nie tylko product ownerowi, ale także zespołowi deweloperskiemu i samej organizacji.
