Praca w Sprincie. Jak zwinnie określić cel i zaplanować działania, aby dowieźć produkt, jakiego potrzebuje Twój klient?

Szukasz efektywnego sposobu na stworzenie nowego produktu? Istnieje wiele metod prowadzenia i realizowania projektów metodyką pracy Agile. Jedną z nich jest metodyka Scrum, czyli zwinne podejście przy tworzeniu usług czy też produktów. Opiera się na dostarczaniu produktu w niewielkich przyrostach, dzięki czemu wiemy, w którym cyklu życia produktu się znajdujemy. Umożliwia to zespołowi elastyczną pracę, a w razie potrzeby szybkie reagowanie i dostosowanie się do zaistniałej sytuacji. 

Scrum i jego składowe

Scrum bazuje na trzech filarach empiryzmu (z języka greckiego ἐμπειρία, empeiría – doświadczenie). Pierwszym z nich jest przejrzystość, transparentność, która umożliwia wgląd do tego, co aktualnie się dzieje. Za przejrzystością stoi inspekcja. Analiza działań zespołu, produktu czy organizacji umożliwia na wczesnym etapie dostrzec ewentualne problemy. Adaptacja, czyli trzeci filar, pozwala na zmianę planów i ukierunkowanie produktu do realnych warunków. 

Na Scrum składają się między innymi zespoły scrumowe, jak również związane z nimi role, wydarzenia, artefakty oraz reguły. Praca w Scrumie opiera się na stałych cyklach, tak zwanych Sprintach. Aby praktykować Scrum, konieczny jest do tego zespół scrumowy, w którego skład wchodzą m.in. Product Owner, zespół deweloperski, Scrum Master. Role w zespole są wymienne, a każdy jego członek otrzymuje niezbędne wsparcie. Celem zespołów zwinnych jest przede wszystkim zrozumienie potrzeb klienta, a dopiero wówczas podejmowanie prób, które umożliwią sprostanie im. 

Product Owner jest właściciel produktu to osoba czuwająca nad rozwojem produktu.

Określa wizje i kształt, za którą podąża zespół deweloperski, nadając kierunek i kształt działań, uwzględniając ich priorytetowość. Osoba ta rozumie potrzeby klienta i zna specyfikę zespołu oraz posiadanych przez niego kompetencji. Product Owner odpowiada za Backlog Produktu, czyli zbiór wszystkich zadań, jakie powinny być wykonane, aby otrzymać w pełni funkcjonalny produkt, odpowiadający na potrzeby klientów.

Zespół developerski to odpowiednio dobrani pod kątem kompetencji członkowie, co ma ogromny wpływ na sprawne funkcjonowanie tej grupy. Zespół powinien być interdyscyplinarny, pracownicy muszą uzupełniać się wzajemnie, zatem powinien składać się z analityków biznesowych, programistów, testerów oprogramowania, a także z innych niezbędnych osób. Członkowie zespołu sami planują swoją pracę. Bardzo ważne będą tutaj kompetencje miękkie, takie jak empatia czy umiejętność komunikacji. 

Scrum Master to natomiast osoba wspierająca zespół w realizacji pracy zwinnej. Pomaga zrozumieć i stosować wartości, praktyki, reguły oraz teorię Scruma. Jest to osoba, która wspiera zespół i pomaga w poszukiwaniu rozwiązań. 

Czym właściwie jest Sprint? Praca w cyklu Sprint

Sprint jest pewnym zapisem w naszym kalendarzu, to pojedyncza iteracja w metodykach zwinnych. Prościej rzecz ujmując: to pewien okres, podczasu którego wykonujemy pracę i w którym cały czas uczymy się planować, aby pracować lepiej i efektywniej. Według The Scrum GuideTM, The Definitive Guide to Scrum: The Rules of the Game Sprinty to kilka składowych: planowanie, codzienne Scrumy, praca wytwórcza, przegląd Sprintu, a także retrospektywy.

Scrum guide głosi, że jego długość nie powinna trwać dłużej niż cztery tygodnie. Jaki jest optymalny czas jego trwania? Wszystko w zależności od funkcjonowania firmy, złożoności produktu i projektów. Ciężko mówić o planowaniu na prawie miesiąc do przodu. Szczególnie teraz, gdy nadal trwa pandemia i ciężko cokolwiek przewidzieć czy zaplanować w dłuższej perspektywie. Najczęstszą jednak praktyką pośród zespołów są Sprinty w cyklu czternastodniowym – co dwa tygodnie zespoły startują z nowym, bez względu na fakt, co się z nim dzieje. Najlepiej jednak, gdy długość Sprintów jest identyczna przez cały czas trwania prac, a nowy zaczyna się natomiast bezpośrednio po ukończeniu poprzedniego. 

Zdarzają się sytuacje, gdy zespoły korzystają ze Sprintów jednotygodniowych. Scrum events (wydarzenia scrumowe) są wprawdzie krótsze, dynamika pracy jest bardziej odczuwana, ale ma to swoje plusy z uwagi na regularność. Wszystko to kwestia praktyki i zauważenia dobrych stron takiego rozwiązania. Zespół musi odszukać optymalną dla siebie długość trwania Sprintu, aby ten przyniósł jak najwięcej korzyści. 

Nie powinno się wydłużać czy skracać czasu ich trwania, a także wprowadzać zmian, które mogłyby stanowić potencjalne zagrożenie w osiągnięciu zamierzonego celu. Przy Sprintach bardzo ważnym aspektem jest planowanie – elastyczny plan wykonania prac, które będą tworzone na drodze do powstania oczekiwanego produktu. Powinniśmy się starać, aby właśnie w jego ramach czasowych dostarczyć pewną wartość. Przy określaniu długości trwania Sprintu warto wziąć pod uwagę kilka czynników, a mianowicie: rolę dla klientów oraz organizacji, możliwości, jakie posiada zespół, a także ich dynamikę. Na początek możecie poeksperymentować i spróbować znaleźć swój rytm. Istotne, aby potem rytm pracy był stały. 

To dzięki stałej długości Sprintów uczymy się coraz lepiej je planować. Zmieniając czas ich trwania, nie osiągniemy tego efektu. Skrócenie ich czasu trwania nie powinno mieć miejsca, ale… Może się zdarzyć, że Sprint zostanie przerwany przed upływem ograniczenia czasowego, jednak wyłączne prawo do przerwania ma Product Owner (choć taka decyzja może być podyktowana opinią interesariuszy, zespołu deweloperskiego czy też  Scrum Mastera). Jaka może być tego przyczyna? Sprint może zostać przerwany w sytuacji, gdy jego cel przestał być aktualny. Może się to zdarzyć w chwili, gdy biznes zmieni swój kierunek rozwoju lub gdy ma miejsce zmiana warunków rynkowych czy technologicznych. Może mieć swoje konsekwencje. 

Planowanie Sprintu 

Każdy Sprint rozpoczyna się od spotkania zwanego Sprint Planning (Planowanie Sprintu). Jest to spotkanie, w którym bierze udział cały zespół scrumowy. Jest to jednocześnie pierwsze wydarzenie w Sprincie. Podczas spotkania zespół wykonuje prognozę działań oraz wymagań oraz ocenia, jaką korzyść przyniesie to interesariuszom. Skutkiem planowania jest Backlog Sprintu (ang. Sprint Backlog), a także cel Sprintu (ang. Sprint Goal). Planowanie miesięcznego Sprintu trwa zazwyczaj około ośmiu godzin. Jak podaje Scrum Guide 2017: zanim planowanie Sprintu dobiegnie końca, zespół deweloperski powinien być w stanie wytłumaczyć właścicielowi produktu i Scrum Masterowi, w jaki sposób ma zamiar pracować, organizując się samodzielnie, by osiągnąć cel Sprintu i wytworzyć oczekiwany przyrost.

Realny cel Sprintu 

Cel Sprintu (Product Goal) to założenia zespołu deweloperskiego określane w trakcie planowania Sprintu. Stanowi on wsparcie w podejmowaniu decyzji w trakcie trwania prac. Cel może obejmować wiele aspektów: dostarczenia funkcjonalności, testowania, jak również badanie ryzyka związanego z produktem. W każdym Sprincie jest tylko jeden cel. Jasno określony cel to mocny cel, cenna pomoc w zrozumieniu kontekstu biznesowego, swoboda działania i współpraca zespołu. Jeśli chcesz wiedzieć, czy cel jest dobry, polecam metodę SMART. Reguła SMART w oryginale wygląda tak:

Specific = Specyficzny

Measurable = Mierzalny

Attainable/Ambitious = Ambitny

Realistic = Realny

Timely = Terminowy

Według niej cel musi być konkretny, mierzalny, ambitny, rzeczywisty i określony w czasie. T w metodzie SMART w Scrum sugeruje nam timebox Sprintu. Umiejętne podejście do celu ma wiele korzyści. Pomaga zrozumieć, jaką wartość wnosi dany przyrost produktu. Jasno określony cel to także współpraca zespołu na najwyższym poziomie. Dzięki temu, gdy pojawią się jakiekolwiek wątpliwości, zespół deweloperski ma szansę szybko zareagować. Mocny cel pomaga w budowaniu wspólnego zrozumienia, wspiera komunikację z interesariuszami. 

Zastanawiając się nad nim, warto używać czasowników, które mają za zadanie określić konkretne działania jako efekt realizacji. Warto również zadać sobie kilka pytań, np.:

  • na co wydajemy pieniądze,
  • na czym najbardziej nam zależy,
  • czy jest to odpowiednia wartość dla klienta,
  • czy to jest przyrost produktu,
  • jakie kłopoty mogą spotkać nas po drodze?

Codzienny Scrum 

Daily to spotkanie, które wspiera pracę zespołową. Podczas takiego spotkania, które powinno trwać do 15 minut, omawiane i synchronizowane są bieżące działania. Daily są również używane do oceny postępów prac. Taka metodologia buduje relacje w zespole dzięki regularnym spotkaniom, przybliżamy się również do osiągnięcia celu Jak podaje M. Trocki w Metodyki i standardy zarządzania projektami, podczas zebrania każdy uczestnik zespołu deweloperskiego odpowiada na pytania:

  • co zostało zrobione wczoraj, co pomogło zespołowi deweloperskiemu przybliżyć się do osiągnięcia celu,
  • co zostanie zrobione dzisiaj, co pomoże zespołowi deweloperskiemu przybliżyć się do osiągnięcia celu,
  • czy zidentyfikowane zostały jakieś przeszkody, mogące uniemożliwić zespołowi deweloperskiemu osiągnięcie celu?

Przegląd Sprintu

Każdy Sprint kończy się spotkaniem przeglądowym, tak zwanym Sprint Review. Na spotkaniu zespół przeprowadza inspekcję przyrostu. Przegląd Sprintu trwa nie dłużej niż 4 godziny. Uczestnikami są zazwyczaj: Product Owner, zespół scrumowy, Scrum Master, klienci oraz inżynierowie z innych projektów. Podczas tego spotkania projekt oceniany jest pod względem ustalonego podczas planowania celu Sprintu. Wynikiem przeglądu jest nowy Backlog Produktu. Jak pisze Roman Pichler w książce Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci: Przegląd Sprintu pomaga w tworzeniu udanego produktu. Daje zespołowi scrumowemu szansę na współpracę z interesariuszami, okazję do sprawdzenia stopnia rozwoju produktu oraz możliwość podjęcia decyzji o jego dalszych losach. Nie trzeba zdawać się jedynie na przypuszczenia, że wszystko idzie zgodnie z planem.

Retrospekcja Sprintu 

Sprint Retrospective to spotkanie, które kończy dany Sprint. Omawiany jest sposób pracy członków zespołu przez okres trwania jego ostatniego etapu. Retrospektywa powinna trwać do trzech godzin. Opracowany w tym czasie zostaje plan usprawnień, który zostanie wcielony w życie w następnym Sprincie. Retrospektywa ma na celu sprawdzenie ostatnich działań, z uwzględnieniem relacji, procesów oraz narzędzi. Co więcej – dzięki niej możliwe jest zidentyfikowanie i uporządkowanie istotnych momentów, mających na celu usprawnienie procesu. Na koniec tworzy się plan dla udoskonalenia sposobu wykonywania pracy przez zespół scrumowy. Dzięki retrospekcji wyciągnięte zostają wnioski, a dalsza praca staje się o wiele przyjemniejsza i łatwiejsza.

Korzyści wynikające z pracy w Sprintach

Jedną z nich jest otrzymanie feedbacku na temat produktu. W doświadczonym zespole deweloperskim członkowie nie czekają do momentu przeglądu Sprintu, aby otrzymać od interesariuszy feedback. Oni działają, a po zrealizowaniu elementu artefaktu, pokazują swoje efekty, dzięki czemu – jeśli wszystko jest poprawne – otrzymują zielone światło na wcześniejsze wdrożenie zmian. Podział pracy nad produktem na mniejsze części dostarcza wielu korzyści. Stabilność i przejrzystość pozwalają na planowanie dodatkowych aktywności związanych z produktem, na przykład kampanii reklamowych. 

Pewne elementy realizowane przez zespół są dla wielu uczestników oczywiste, inne zaś skomplikowane i wymagają dodatkowych analiz. Wtedy korzystna staje się przestrzeń, w której się znajdujemy, możemy eksperymentować, uczyć się, wyciągać wnioski. Praca na Sprintach okazuje się przydatnym narzędziem, gdy natrafiamy na kolejne złożone problemy. Zespoły decydują się wtedy na eksplorację potencjalnych rozwiązań, przeznaczając na to dodatkowy czas. Sprint określa konkretne ramy – wiemy, gdzie jest jego początek i koniec. Rytm pracy umożliwia zespołowi skupienie się na tym, co należy zrobić. Małe sukcesy, jak na przykład zrealizowanie jednego z zadań czy też pozytywny feedback od użytkownika produktu dają ogromną motywację do dalszych działań. Z reguły Sprint powinien dawać poczucie małego zwycięstwa na koniec iteracji, jeżeli uda się zrealizować cel lub gdy nauczymy się czegoś ważnego z korzyścią dla zespołu.