Sprintem (iteracją) określa się przedział czasu, w którym zespół programistów pracuje w metodyce scrumowej nad konkretnymi zadaniami, prowadzącymi do osiągnięcia precyzyjnie określonego celu.
Czym jest Sprint? Co to jest Sprint? Jaki jest średni czas trwania Sprintu? Jakie zadania są delegowane do zespołu Scrumowego?
Termin ten należy kojarzyć z metodykami zwinnymi. Sprint stanowi jeden z ich kluczowych, podstawowych elementów.
Sprinty w praktyce nie trwają dłużej niż dwa tygodnie. Istotą Sprintów jest dostarczenie konkretnego, działającego oprogramowania (np. konkretnej funkcjonalności).
Pamiętajmy jednak, że w tym podejściu nie chodzi o stworzenie aplikacji webowej, czy aplikacji mobilnej od podstaw (w szczególności w tak krótkim czasie), ale o ukończenie prac o mniejszym zakresie, złożoności, istotności.
Warto od razu zaznaczyć, że Agile, Scrum, Sprint to nie są synonimy, ani terminy, które można używać z dużą dowolnością.
Uporządkujmy zatem.
Agile to metodologia, a więc zestaw zasad, reguł postępowania, których przestrzeganie pozwala urzeczywistniać cele.
Scrum to z kolei framework, a więc pewien rodzaj struktury, modelu, w ramach której zasady sformułowane na gruncie Agile są stosowane.
Sprint stanowi ramę czasową, zadaniową, która pozwala zespołowi deweloperskiemu uporządkować, podzielić projekt na mniejsze, autonomiczne części.
Jest strukturą powtarzalną, stałą, której celem jest dostarczenie produktu o możliwie najwyższej wartości.
Sprint stanowi ważną podstawę metodologii zwinnej i jest traktowany jako wydarzenie, które obejmuje pozostałe wydarzenia, takie jak Codzienny Scrum, Przegląd Scrumowy i Retrospektywę Sprintu.
Tyle tytułem wstępu. Jeśli pozyskaliśmy Waszą uwagę, to serdecznie zapraszamy do przeczytania całości artykułu, w którym bliżej opowiemy o specyfice Sprintu oraz sposobach jego planowania.
Zatem, wszystko, czego chcieliście się dowiedzieć o Sprincie, ale baliście się zapytać znajdziecie właśnie w tym artykule.
Zapraszamy, miłego czytania!
Szukasz software house?
Cel Sprintu, czyli dlaczego Sprinty są istotne, gdy tworzymy produkt cyfrowy?
Wszyscy znamy zjawisko aktualizacji aplikacji mobilnych, webowych, oprogramowania, którego używamy na komputerach stacjonarnych, laptopach.
Z dużym prawdopodobieństwem można założyć, że niemal wszystkie produkty cyfrowe, które są stale rozwijane, są po prostu produktami tworzonymi w formule „work in progress”.
Czy każda aktualizacja z punktu widzenia użytkownika oznacza radykalną zmianę?
Oczywiście nie, ale zmiany następują, tyle że przyrostowo, w sposób mniej lub bardziej zauważalny dla użytkownika końcowego.
W większości przypadków, co również można śmiało założyć, aktualizacje oprogramowania są wynikiem zastosowania metodyk zwinnych i korzystania przez zespół deweloperski ze Sprintów.
Po co w ogóle tworzyć oprogramowanie w Sprintach?
Do najważniejszych powodów należy zaliczyć:
- brak pełnej, jednoznacznej wizji projektu, produktu cyfrowego
- brak zdefiniowanego zakresu prac, projektu
- brak dokładnej, wyczerpującej specyfikacji wymagań oprogramowania
- zmieniające się realia biznesowe, rynkowe
- relatywnie niskie koszty niepowodzenia - krótki czas Sprintu pozwala podejmować ryzyko niepowodzenia.
Najlepszą, najbardziej aktualną i obrazową ilustracją powyższego może być projekt aplikacji księgowej, która jest tworzona w realiach Polskiego Ładu.
Zmieniająca się sytuacja prawna (liczne nowelizacje ustawy), brak klarownej wykładni istniejących przepisów przekłada się na dużą niepewność projektową, konieczność szybkiego, elastycznego dostosowania zakresu prac do nowych realiów.
Innym przykładem może być chęć przetestowania pomysłu na daną funkcjonalność, sprawdzenia, w jaki sposób użytkownicy końcowi będą na nią reagować, jakie oceny, reakcje, problemy, emocje z jej oferowanie się wiążą.
Sprinty w takich sytuacjach są metodą idealną, bowiem pozwalają minimalizować straty, jeśli sytuacja ulegnie zmianie i wyjściowe założenia projektu będzie trzeba adaptować.
Kluczową zasadą Agile jest „Do Fast, Fail Quick”, dzięki czemu koszty finansowe, czasowe, organizacyjne, biznesowe są o wiele mniejsze.
Wszystkie te kwestie mają ogromne znaczenie dla:
- jakości tworzonego oprogramowania
- konkurencyjności tworzonego oprogramowania
- terminowości wykonania projektu
- elastyczności projektu
- motywacji, zaangażowania
- optymalizacji, usprawnień wydajności pracy.
Ponadto, Sprinty pozwalają utrzymać stałe tempo pracy. Przeciwdziałają poczuciu przytłoczenia wynikającego ze skali projektu, odpowiedzialności.
Zapewniają także, konieczną przy projektach złożonych, wymagających, informację zwrotną.
Feedback zapewniany w sposób regularny, stosunkowo częsty, odnoszący się do mniejszych elementów jest niezbędny. Pozwala wyłapywać błędy, generować pomysły, rozwiązania oraz dostrzegać problemy, które były niewidoczne lub trudne do przewidzenia przed przeprowadzeniem danego Sprintu.
Bardzo istotną zaletą Sprintów jest także:
- skrócony czas debugowania - debugowanie zazwyczaj jest jednym z najbardziej czasochłonnych zadań w ramach dowolnego projektu
- ewolucyjne, miarowe, bardziej optymalne wprowadzanie zmian
- oferowanie oprogramowanie bardziej przyjaznego dla użytkowników końcowych, w szczególności, gdy oprogramowanie funkcjonuje już na rynku, jest używane przez użytkowników
- możliwość sprawdzenia porozumienia, komunikacji w zespole scrumowym.
Generalnie, zaletą krótkich ram czasowych Sprintów jest większe skupienie uwagi na małych zmianach przyrostowych.
Mniejsza skala oznacza większą kontrolę nad zakresem, przebiegiem pracy, jej rezultatami. Służy także uzyskaniu większej płynności w przebiegu projektu.
Podsumowując, w ramach określonych czasowo iteracji zespół scrumowy pracuje nad konkretnie zdefiniowanym celem, najczęściej nad fragmentem kodu przyrostowego, który stanowi tylko fragment całego projektu i który może być testowany i używany.
W trakcie trwania Sprintu należy przestrzegać kilku zasad, mianowicie:
- nie jest wskazane zmienianie, modyfikowanie przyjętych celów
- nie jest wskazane wydłużanie Sprintu ponad konwencjonalny czas dwóch tygodni.
Jak zaplanować Sprint?
Przebieg oraz efektywność każdego Sprintu jest zależna od jego starannego zaplanowania, od ustanowionego celu Sprintu.
Do najważniejszych elementów należy:
- zdefiniowanie celów (krótko- i długoterminowych), jakie powinny być osiągnięte, realizowane w ramach danego Sprintu, powiązane z produktem
- określenie czasu trwania - wraz z datami rozpoczęcia oraz zakończenia Sprintu
- priorytetyzowanie, określanie problemów (technologicznych, biznesowych), jakie powinny być rozwiązane w czasie Sprintu
- dopasowanie Sprintu do kontekstu biznesowego, rynkowego, czynników zewnętrznych, pozwalającego ominąć przeszkody, osiągnąć płynność realizacji (np. czynników prawnych)
- określenie wielkości oraz kompetencji zespołu (np. czy zespół ma się składać z developerów front-end, backend, czy full-stack).
Planowanie Sprintu, ustanowienie celu Sprintu powinno odbywać się w sposób proporcjonalny do długości Sprintu i w przypadku iteracji dwutygodniowych nie powinno zajmować więcej niż jeden dzień roboczy.
Planowanie Sprintu jest także planowaniem ilości pracy, której co do zasady nie powinno być ani za dużo, ani za mało. Zbyt mała ilość pracy będzie niekorzystnie wpływać na budżet projektu, z kolei nadmierne obłożenie pracą może skutkować wypaleniem zespołu, problemem z terminowością, czy jakością oprogramowania
Warto pamiętać, że czynnik ludzki jest niezwykle ważny w planowaniu Sprintów - ustanawiany cel Sprintu powinien brać pod uwagę tę kwestię.
Stąd też w szczególności Scrum Master, który jest odpowiedzialny za planowanie Sprintu, musi zwracać uwagę na:
- liczebną, kompetencyjną adekwatność, jaką reprezentuje zespół programistyczny
- zaangażowanie członków zespołu w inne projekty
- odpowiednie priorytetyzowanie zadań oraz występujących między nimi zależności oraz ich konsekwencje
- fortunność czasową rozpoczęcia Sprintu.
Odpowiednie skonfigurowanie członków zespołu, ich aktualne zadania wraz z płynnym przebiegiem prac wpływa na atmosferę pracy, poczucie jej sensowności, celowości oraz klarowności.
Wszystkie te elementy tworzą kontekst, który wpływa na to, jak członkowie zespołu Scrumowego postrzegają swoją rolę, funkcję, zadania, skuteczność, wpływ w ramach zespołu oraz w ramach projektu.
Im lepiej Sprint jest zaplanowany, tym lepsza jest także atmosfera w czasie jego trwania.
Planowanie wpływa także na komunikację, sposób współpracy, interakcje, poczucie odpowiedzialności, przepływ informacji.
Ponieważ Sprint jest działaniem cyklicznym, ale jednocześnie skupionym tylko na wybranym fragmencie, konieczne jest wylistowanie wszystkich działań, które są niezbędne do zakończenia projektu w pożądanym kształcie i terminie.
Narzędziem służącym do ich planowania jest Backlog Sprintu, który pozwala:
- szacować pracę
- priorytetyzować działania
- planować wykonanie działań w czasie
- przenosić nieukończone działania do kolejnych iteracji (np. dzięki retrospektywie Sprintu można ustalić, co powinno się wykonać w następnym Sprincie, a czego nie udało się w ostatnim Sprincie).
Backlog Sprintu, backlog produktu służy również do wprowadzania nowych zadań, koncepcji, które pojawiły się w trakcie tworzenia produktu cyfrowego.
Backlog Sprintu (Sprint Backlog) pozwala także:
- określać produktywność oraz wydajność zespołu
- optymalizować zadania
- określać tempo przyrostu
- poszukiwać oszczędności czasowych
- zarządzać projektami (np. poprzez szkolenie, odpowiednie stosowanie metodyki).
Bardzo przydatnym narzędziem do planowania Sprintów, które wykorzystuje większość zespołów w Sprintach, jest lista kontrolna, która powinna uwzględnić między innymi:
- konieczność sprawdzenia długów: jakościowego oraz technologicznego
- konieczność sprawdzenia zgodności perspektyw wszystkich członków zespołu (kierunek działań powinien być dla wszystkich jasny i zdefiniowany w taki sam sposób)
- konieczność poświęcenia uwagi zadaniom nieznanym lub obarczonym wyższym ryzykiem
- konieczność poświęcenia uwagi poszczególnym członkom zespołu, w szczególności feedbackowi w kwestii obciążenia pracą
- konieczność odpowiedniego uporządkowania zaległości oraz prac priorytetowych
- konieczność uwzględnienia zmian w postępie prac wynikających z urlopów, świąt, dni wolnych od pracy, spotkań zespołu
- konieczności zapewnienia wszystkim członkom zespołu dostępu do Backlogu.
Role w Sprincie oraz jego struktura
Zespół Scrumowy składa się z trzech kluczowych ról:
- Scrum Mastera
- Product Ownera (właściciel produktu)
- Scrum Teamu.
Scrum Master pełni kluczową rolę w Sprincie, bowiem jest:
- facylitatorem dla zespołu programistycznego (zarządza sposobem interakcji, prowadzi spotkania Daily Stand-up)
- osobą wspierającą członków zespołu w czasie Sprintu (w wymiarze technologicznym, w wymiarze relacji interpersonalnych, w wymiarze barier organizacyjnych)
- odpowiedzialny za ułatwienie współpracy między wszystkimi rolami i funkcjami
- odpowiedzialny za rozwiązywanie problemów zasobów.
Zespół Scrumowy obejmuje najczęściej programistów, projektantów, testerów, których zadaniem jest:
- rozwój produktu cyfrowego
- testowanie produktu.
Zadaniem Product Ownerów jest:
- reprezentowanie użytkowników produktu
- stworzenie pomostu między zespołem deweloperskim a interesariuszami
- stworzenie i przekazanie wizji produktu
- dopilnowanie spełnienia wszystkich wymagań - biznesowych, funkcjonalnych, rynkowych
- akceptacja lub odrzucenie wykonanych prac w ramach danego Sprintu.
Scrum należy także kojarzyć w powtarzalnymi rytuałami, ceremoniami które pełnią ważną rolę w Sprincie.
Codzienne Scrumy (Daily Stand-up, Daily Scrum) to codzienne (zazwyczaj nie przekraczające kwadransa) spotkania członków zespołu, które służą:
- lepszej synchronizacji prac, timingu, przypisanych zadań
- kontroli postępu, sprawdzenie, czy przebieg prac jest zgodny z przyjętym harmonogramem
- omówieniu postępów, problemów, przeszkód, sukcesów
- orientacji członków zespołu
Kolejnym stałym elementem jest Przegląd Sprintu (Sprint Review), który ma miejsce po zakończeniu danej iteracji.
Jego głównym celem jest prezentacja interesariuszom rezultatów Sprintu (skończonych, przetestowanych fragmentów kodu), w szczególności tego, co udało się osiągnąć, jak również tego, co należy uzyskać dopiero w przyszłości.
Retrospektywa Sprintu odbywa się po Przeglądzie Sprintu a poprzedza kolejny Sprint.
Jej głównym celem jest omówienie osiągnięć, wyzwań, kolejnych celów, przeszkód - ustalenie wspólnego kierunku działania oraz sprawdzenia na ile wymagania (np. klientów) zostały spełnione.
Usprawnienie procesu, rozumiane wielowymiarowo, ma nie tylko usprawnić procesy, ale także pozwolić na lepsze planowanie kolejnego Sprintu (Sprint Planning).
Przy okazji, polecamy doskonały artykuł Anny Kaley, związanej z Norman Nielsen Group, która poruszyła związki Ceremoniałów Scrumowych z User Experience.
Koniecznie zajrzyjcie do jej artykułu pod tytułem „UX Responsibilities in Scrum Ceremonies”. Relacje zespołów programistycznych oraz specjalistów UX rzadko są opisywane w kontekście metodyk zwinnych, stąd też lektura tego artykułu jest dodatkowo cenna.
Co to jest Sprint? Podsumowanie artykułu
- Sprint (także Sprint Design), iterację definiuje się jako określony (zazwyczaj nie dłuższy niż dwa tygodnie) przedział czasu w czasie którego zespół programistów, developerów, projektantów pracuje nad konkretnymi zdaniami, które mają na celu stworzenie działającego oprogramowania.
- W ramach Sprintów można na przykład stworzyć konkretną funkcjonalność.
- Terminy Sprint, Agile, Scrum nie stanowią dla siebie synonimów.
- Agile to metodologia, Scrum to framework, a Sprint stanowi ramę czasowo-zadaniową, która pozwala podzielić projekt na mniejsze, samodzielne części.
- Budowanie, przyrost oprogramowania złożonego pod względem technologicznym, organizacyjnym, testowym, optymalizacyjnym, badawczym ma swoje specyficzne wymagania. Na przykład dotyczące długiego czasu, co niesie szereg ryzyk (np. praca staje się mniej efektywną), których Sprint pozwalają uniknąć.
- Przede wszystkim, w dużych projektach postępy w pracy są trudniej dostrzegalne, co czasami wpływa na motywację zespołów programistycznych, projektowych, badawczych, testowych. I ma duży wpływ na jakość realizacji zadań i ich efekty.
- Sprinty pozwalają także znacząco ograniczyć ryzyko budżetowe, czasowe, organizacyjne, biznesowe.
- Sprinty przeciwdziałają także poczuciu przytłoczenia, nadmiernej odpowiedzialności, zapewniają bardzo istotną przy dużych, złożonych projektach feedback, który jest niezwykle istotny.
- Główną zaletą Sprintów jest skrócony czas debugowania, ewolucyjne, bardziej optymalne wprowadzanie zmian w oprogramowaniu.
- Dzięki Sprintom lepsza jest także komunikacja w zespole programistycznym, większa kontrola nad zakresem, przebiegiem pracy, jej rezultatami.
- Sprint wykorzystywany jest również do uzyskania większej płynności w przebiegu projektu - płynność jest zależna od od skutecznego planowania Sprintu, zdefiniowania odpowiedzialności oraz uprawnień.
- Od odpowiedniego planowania Sprintu wpływa pozytywnie na atmosferę pracy, komunikację oraz ostatecznie na ile doskonały jest produkt cyfrowy.
- Od wlaściwego planowania Sprintu zależy również sposób współpracy, bieg pracy, interakcje, poczucie odpowiedzialności, przepływ informacji oraz - koniec końców - także na jakość oprogramowania.
- Zespół Scrumowy składa się z trzech kluczowych ról - Scrum Mastera, Product Ownera (właściciela produktu), Scrum Teamu.
