Scrum od kuchni

Tak, jak dynamicznie rozwija się branża e-commerce, tak szybko zadomowiło się na polskim rynku zwinne tworzenie oprogramowania, ze szczególnym naciskiem na SCRUM. Można nawet powiedzieć, że mamy do czynienia z pewnego rodzaju modą na „zwinne” prowadzenie projektu. Firmy zaś reagują w dwojaki sposób na ów modę; albo ją ignorują bojąc się zmian i reorganizacji całej pracy nad projektem, albo z zapałem, choć czasami nieudolnie próbują zaimplementować ramy procesu SCRUMowego we własnym środowisku. Wszystko bierze się z niewiedzy. A ponieważ ślepe uleganie modzie może odnieść odwrotny skutek, warto poznać SCRUM od kuchni.

W branży e-commerce dominują dwa podejścia prowadzenia projektu: klasyczny Waterfall i zwinny Agile. W Waterfallu mamy zdefiniowany model procesu. Najpierw jest etap planowania, potem analizy, projektowania, programowania, testów i na końcu wdrożenia. W metodykach Agile bazujemy na empiryzmie, prace są wykonywane iteracyjnie. W każdej iteracji mamy fazę planowania, projektowania, kodowania oraz testów. Na końcu przeprowadzany jest przegląd wykonanych prac i następuje decyzja o wdrożeniu.

W Waterfallu, przed rozpoczęciem pracy nad wdrożeniem e-commercu, praca i jej wynik są rozumiane, mamy dobrze zdefiniowane oczekiwania. Rezultat prac programistycznych pokazywany jest na samym końcu. Zdarza się, że klient widząc końcowy produkt stwierdza,że w większym bądź w mniejszym stopniu to, co zostało wykonane, nie jest zgodne z jego wizją. Zmieniają się więc wymagania, zdarza się, że pojawiają się nowe lepsze pomysły. W takich sytuacjach specyfikacja wymagań oraz specyfikacja techniczna ulega zmianie a my ponownie wracamy do etapu planowania.

W większości przypadków proces ten powtórzy się kilkukrotnie, powodując, że pierwotne dokumenty zostaną całkowicie zmienione. W międzyczasie może powstać kilka kryzysowych sytuacji we współpracy klient – wykonawca, ponieważ każda ze stron stara się przeforsować swoje stanowisko. Projekt zostaje zazwyczaj poważnie opóźniony, nie posiada wszystkich funkcjonalności lub posiada wszystkie, ale niektóre o niskiej jakości. Jest niemal pewne, że w takiej postaci wdrożony projekt będzie przez kolejne miesiące poprawiany.

W metodykach zwinnych prowadzone są częste inspekcje i adaptacje, dzięki czemu zespół realizujący projekt jest elastyczny w stosunku do zmieniających się wymagań klienta, czy do szybko rozwijających się nowych technologii. Wszystkie funkcjonalności nie muszą być od razu perfekcyjnie zdefiniowane. W Agile ważna jest bezpośrednia komunikacja, która minimalizuje potrzebę tworzenia obszernych dokumentacji. Zwinne metodyki umożliwiają nam szybkie dostosowanie się do potrzeb klienta, opóźnienie może trwać maksymalnie tyle ile trwa jedna iteracja. Wyniki pracy są często nieprzewidywalne i niepowtarzalne.

Zwinność

W tym artykule skupimy się na zwinności, a dokładniej na wytwarzaniu oprogramowania w Scrumie. Czym on jest? Jakie występują role i zdarzenia? Czy praca w Scrumie jest prosta, łatwa i przyjemna?

Scrum nie jest procesem. Nie jest techniką wytwórczą. Ken Schwaber powiedział „Scrum nie jest metodologią – jest drogą”. Scrum jest to framework, są to ramy postępowania, dzięki którym możemy z powodzeniem rozwiązywać złożone problemy adaptacyjne, tak by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości. Sposób pracy w Scrumie jest zgodny z wartościami opisanymi 15 lat temu przez siedemnastu reprezentantów nowych metodyk tworzenia oprogramowania, będących alternatywą dla klasycznego Waterfalla. W Manifeście Agile czytamy: Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy, zaczęliśmy bardziej cenić:

  • Ludzi i interakcje od procesów i narzędzi
  • Działające oprogramowanie od szczegółowej dokumentacji
  • Współpracę z klientem od negocjacji umów
  • Reagowanie na zmiany od realizacji założonego planu.

Elementy wypisane po lewej stornie mają dla nas większą wartość niż te po prawej. Manifest Agile przedstawia bardzo ogólne zasady jakich należy się trzymać tworząc oprogramowanie. W Scrumie występuje kilka elementów, które służą konkretnym celom i bez nich nie osiągniemy sukcesu w jego stosowaniu. Są to: Zespoły Scrumowe oraz związane z nimi role, zdarzenia, artefakty oraz wartości. Ale co to wszystko tak naprawdę oznacza?

Role

Zespół Deweloperski + Właściciel Produktu + Scrum Master = Zespół Scrumowy

W Scrumie rozróżniamy trzy role: Właściciel Produktu (ang. Product Owner), Scrum Master oraz Zespół Deweloperski (ang. Development Team).

Właściciel Produktu zarządza Back logiem Produktu (ułożona według priorytetów lista zadań potrzebnych do rozwoju produktu) i stara się, aby był on przejrzysty i dostępny dla wszystkich. Ustala kolejność realizacji elementów w celu osiągnięcia założonych celów. Zapewnia, że Zespół Deweloperski rozumie elementy Backlogu Produktu w wymaganym stopniu.

Właściciel Produktu powinien być wystarczająco dostępny, aby móc wyjaśnić ewentualne niejasności podczas trwania Sprintu. Cała organizacja musi respektować jego decyzje. Właściciel produktu to pojedyncza osoba.

Scrum Master zapewnia, że Scrum jest rozumiany i stosowany. Przybliża jego teorię i praktyki. Pomaga w organizacji spotkań scrumowych. Powoduje zmiany, które poprawiają jakość i produktywność pracy Zespołu Deweloperskiego. Scrum Master nie jest osobą, która narzuca. Wręcz przeciwnie – Zespół Deweloperski jest jednostką decydującą. Scrum Master pomaga Właścicielowi Produktu w zarządzaniu Backlogiem Produktu oraz Zespołowi Deweloperskiemu w rozumieniu i rozszerzaniu Definicji Ukończenia (ang. Definition of Done). Definicja Ukończenia określa nam standardy pracy nad Produktem. Dzięki niej możemy ocenić, czy praca nad Przyrostem produktu została zakończona. W Definicji ukończenia mogą być takie punkty jak: każde zadanie pomyślnie przeszło testy, każde zadanie ma uzupełnione pole z nazwą brancha na którym było realizowane. W celu zapewnienia przejrzystości wszyscy członkowie Zespołu Scrumowego muszą ją tak samo rozumieć i jej przestrzegać.

Zespół Deweloperski stanowi główny trzon Zespołu Scrumowego. Jego zadaniem jest dostarczenie na koniec każdego Sprintu (iteracja trwająca maksymalnie 1 miesiąc), gotowego do potencjalnego wydania Przyrostu produktu (czyli gotowych do wdrożenia zadań zrealizowanych zgodnie z Definicją Ukończenia). Zespół ten powinien być na tyle mały, by pozostał zwinnym i jednocześnie wystarczająco duży, żeby mógł wykonać znaczącą pracę w ramach Sprintu. Przyjmuje się zatem, że powinien liczyć od 3 do 9 członków (jeżeli mamy więcej członków to dzielimy je wtedy na dwa (lub więcej) Zespoły Deweloperskie). Właściciel Produktu oraz Scrum Master nie są wliczani w podane wartości, chyba, że wykonują pracę wynikającą z Backlogu Sprintu (lista zadań realizowana w danym Sprincie).

Zespół Deweloperski jest między funkcjonalny – czyli posiada wszystkie umiejętności, aby wytworzyć Przyrost oraz samoorganizujący się – czyli nikt nie może mu mówić jak wykonać dane zadanie. Odpowiedzialność za wykonywaną pracę w ramach sprintu ponosi cały Zespół Deweloperski. Deweloperzy mogą specjalizować się w określonych pracach (tester, analityk, front-end developer itd.), ale w zespole wszyscy powinni być równi i dlatego zawsze nazywamy ich tylko i aż deweloperami.

Wszyscy razem – Właściciel Produktu, Scrum Master i Zespół Deweloperski – tworzą Zespół Scrumowy (ang. Scrum Team). Model zespołu proponowany w Scrumie został zaprojektowany tak, aby zoptymalizować elastyczność, kreatywność i produktywność. Warty podkreślenia jest fakt, iż w Scrumie nie istnieje taka rola jak Project Manager, Team Leader ani żadna inna.

Zdarzenia

Planowanie Sprintu + Codzienny Scrum (Daily Scrum) + Przegląd Sprintu + Retrospektywa = Sprint

Sercem Scruma jest Sprint – ograniczenie czasowe trwające jeden miesiąc lub krócej (najczęściej 2 tygodnie), podczas którego wytwarzany jest gotowy do użycia i potencjalnego wydania Przyrost. W każdym Sprincie realizowane są konkretne zadania, dzięki czemu klient wie jaką realną korzyść otrzyma na jego zakończenie (np. mechanizm rejestracji i logowania użytkowników, lista życzeń lub schowek, mapa sklepów, newsletter). Najlepiej, jeśli Sprinty mają stałą długość przez cały okres trwania prac. Długość Sprintu jest zależna od Zespołu Scrumowego. Nowy Sprint rozpoczyna się bezpośrednio po zakończeniu poprzedniego.

Sprinty nie powinny być przerywane w trakcie ich trwania. Jest to „traumatyczne” przeżycie dla Zespołu Deweloperskiego. Sytuacja taka ma miejsce bardzo rzadko. Często związana jest z nieoczekiwaną zmianą priorytetów, wartości biznesowej, czy też uwarunkowaniami technologicznymi i rynkowymi. Sprint może zostać przerwany tylko przez Właściciela Produktu. Po przerwaniu Sprintu należy zorganizować nowe spotkanie Planowania Sprintu. W skład Sprintu wchodzą cztery spotkania, które służą określonym celom. Każde z nich jest ograniczone czasowo w zależności od długości trwania Sprintu.

Planowanie Sprintu

Planowanie sprintu (ang. Sprint Planning) daje odpowiedź na dwa pytania:

  • Co może zostać zrobione w Sprincie?
  • W jaki sposób wybrany zakres prac zostanie zrealizowany?

Na spotkaniu Właściciel Produktu omawia założenia Sprintu i przedstawia te elementy Backlogu Produktu, których realizacja w trakcie Sprintu pozwoli na osiągnięcie zamierzonego celu. Właściciel Produktu, jeżeli jest taka konieczność wyjaśnia Zespołowi Deweloperskiemu wybrane elementy Backlogu Produktu. Po określeniu przez Zespół Deweloperski, które elementy Backlogu Produktu będą dostarczone,
Zespół Scrumowy tworzy Cel Sprintu (ang. Sprint Goal). Określenie Celu Sprintu pomaga Zespołowi Deweloperskiemu zrozumieć sens realizowanych zmian. Celem Sprintu może być np. optymalizacja serwisu lub poprawa dokładności wyszukiwania o 30%. Po ok reśleniu Celu Sprintu oraz wybraniu elementów Backlogu Produktu do Sprintu Zespół Dewelopersk i decyduje, w jaki sposób zostaną one przekształcone w „Ukończony” Przyrost, innymi słowy zrealizowane. Zadania nie są odgórnie przy pisywane do konkretnej osoby. Zespół Deweloperski dokonuje tego we własnym zakresie biorąc pod uwagę aktualne obłożenie i możliwości. Planując prace na najbliższy Sprint warto też uwzględnić usprawnienia zaplanowane na ostatniej retrospektywie. Wybrane elementy Backlogu Produktu wraz z planem ich dostarczenia nazywane są Backlogiem Sprintu.

Podczas Sprintu bardzo często pojawiają się dodatkowe, niezaplanowane zadania. Według współtwórcy Scruma Kena Schwabera może być to aż do 40% wszystkich zadań. Warto zatem zabezpieczyć się na takie ewentualności. Bierzemy również pod uwagę urlopy członków Zespołu Deweloperskiego czy też dni ustawowo wolne od pracy. 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 będzie pracować by osiągnąć Cel Sprintu i wytworzyć oczekiwany Przyrost.

Planowanie Spirntu daje klientow i komfort posiadania wiedzy co przez te np. 2 tygodnie zostanie wykonane. Jest świadomy tego, jakie funkcjonalności zostaną zrealizowane (np. integracja z ERP, wdrożenie strony głównej strefy marek, implementacja systemu płatności, wdrożenie narzędzia analitycznego). Klient może wtedy zaplanować dalsze prace, zmienić priorytety lub też dołożyć nowe zadania mając na uwadze swoje wartości biznesowe.

Codzienny Scrum

Codzienny Scrum (ang. Daily Scrum) jest ograniczony czasowo do 15 minut. Scrum Master musi mieć pewność, że spotkanie sie odbyło, choć sam nie ma obowiązku w nim uczestniczyć. Na spotkaniu bieżące działania są synchronizowane i powstaje plan na najbliższe 24h. Jest to osiągane poprzez inspekcję prac, które zostały wykonane od ostatniego Codziennego Scruma i prognozowanie prac, które mogą zostać wykonane przed kolejnym spotkaniem. Jest to kluczowe spotkanie dla procesu inspekcji i adaptacji.

Przegląd Sprintu

Przegląd Sprintu (ang. Sprint Review) to spotkanie organizowane na zakończenie Sprintu w celu przeprowadzenia inspekcji Przyrostu i, jeśli zajdzie taka potrzeba, wprowadzenia zmian do Backlogu Produktu. Podczas Przeglądu Sprintu Zespół Scrumowy i interesariusze (zaproszeni przez Właściciela Produktu przedstawiciele klienta, inne firmy współpracujące przy projekcie np. firma zajmująca się SEO czy UX) współpracują w zakresie tego, co zostało ukończone w Sprincie. Rezultatem Przeglądu Sprintu jest zaktualizowany Backlog Produktu, pokazujący, które elementy prawdopodobnie zostaną zaplanowane na kolejny Sprint.

Retrospektywa

Na retrospektywie (ang. Sprint Retrospective) Zespół Scrumowy weryfikuje sposób pracy w Sprincie. Weryfikuje co poszło dobrze i co należy kontynuować, z czym były trudności oraz czy są inne kwestie, które mogą być problematyczne w kolejnym Sprincie. Przeprowadzana jest inspekcja działań i opracowywany jest plan usprawnień, który zostanie wcielony w życie w najbliższym Sprincie.

Artefakty

Backlog Produktu + Backlog Sprintu + Przyrost

Artefakty, (ang. Scrum Artifacts) innymi słowy zobrazowanie pracy i wartości Zespołu Scrumowego tak, aby uzyskać przejrzystość i okazję do dokonania inspekcji i adaptacji. Backlog Produktu (ang. Product Backlog) to ułożona według priorytetów lista wszystkich zadań potrzebnych do rozwoju produktu. Jest jedynym źródłem wymaganych zamian. Product Owner jest odpowiedzialny za zawartość, dostępność i kolejność elementów w Product Backlogu. Product Backlog nigdy nie jest kompletny. Zmienia się dynamicznie z dnia na dzień, ewoluuje wraz z produktem i środowiskiem, w którym ten produkt będzie używany. W Sprincie może zostać przeprowadzone doskonalenie Product Backlogu (ang. Product Backlog Refinement) polegające na dodawaniu szczegółów, oszacowań i porządkowaniu elementów. Backlog Sprintu (ang. Sprint Backlog) to zbiór elementów Backlogu Produktu wybranych do Sprintu przez Zespół Deweloperski. Obrazuje pracę niezbędną do osiągnięcia Celu Sprintu. Przez cały czas trwania Sprintu jest aktualizowany przez Zespół Deweloperski.

Przyrost (ang. Increment) to suma wszystkich ukończonych elementów Product Backlogu zgodnie z Definicją Ukończenia na koniec Sprintu oraz wszystkich Sprintów poprzednich. Każdy przyrost musi być gotow y do potencjalnego wdrożenia produkcyjnego.

Reguły

Przejrzystość + Inspekcja + Adaptacja

Scrum wykorzystuje podejście iteracyjne (Sprinty) i przyrostowe w celu zwiększenia przewidywalności i lepszej kontroli ryzyka. Każda realizacja empirycznej kontroli procesu opiera się na trzech filarach, które mają zapewnić poprawne działanie Scruma w duchu Agile. Są to:
Przejrzystość – wszystkie istotne aspekty procesu muszą być widoczne dla osób odpowiedzialnych za osiągane rezultaty. Ważne jest, aby wszyscy obserwatorzy tak samo rozumieli to, co obserwują.

Inspekcja – osoby wykorzystujące Scruma muszą poddawać częstej inspekcji artefakty scrumowe oraz postępy w realizacji Celu Sprintu.

Ma to na celu wykrycie niepożądanych rozbieżności.
Adaptacja – jeżeli podczas inspekcji okaże się, że wytwarzany produkt nie będzie akceptowalny – proces musi zostać skorygowany. Korekty należy dokonać jak najszybciej, by ograniczyć dalsze błędne działania. W Scrumie to właśnie Zdarzenia Scrumowe służą do przeprowadzania inspekcji i są okazją do dokonania adaptacji (korekty).

Dzięki tym trzem filarom klient zna rzeczywisty stan projektu. Jeżeli praca nad jakąś funkcjonalnością została zakończona przez zespół to oznacza, że jest ona gotowa do potencjalnego wdrożenia i można z niej korzystać. Wszelkie opóźnienia, problemy na poziomie komunikacyjnym, czy też wspólnej pracy,są natychmiast widoczne. Scrum pozwala szybko dostrzec nieprawidłowości (np. wolno działający sklep internetowy, błędy w procesie zakupowym), ale również nowe możliwości (nowa funkcjonalność otwierająca przed nami nowy rynek), które mogą zostać zaadaptowane poprzez zmianę priorytetów, zmianę zakresu, technologii czy sposobu działania zespołu.

Przejrzystość Artefaktów

Brak pełnej przejrzystości Artefaktów może prowadzić do błędnych decyzji, obniżenia wartości i wzrostu ryzyka. Obserwowanie stanu Artefaktów umożliwia podejmowanie prawidłowych decyzji.

Zadaniem Scrum Mastera jest powodowanie zmian, dzięki którym zostaje zwiększona przejrzystość Artefaktów przy współpracy z Zespołem Scrumowym i całą organizacją. Ważne jest, aby wszyscy członkowie danego Zespołu Scrumowego tak samo rozumieli czym jest „Ukończony“element Backlogu Sprintu lub Przyrost (w celu zapewnienia przejrzystości). Służy temu Definicja Ukończenia.

Wartość Scruma

6 lipca 2016r twórcy Scruma – Jeff Sutherland i Ken Schwaber ogłosili kolejne odświeżenie zasad Scruma zawartych w Scrum Guide’a. Odświeżenie to zdaje się być niewielkie niemniej nie można go bagatelizować. Dodanie Wartości Scruma do Scrum Guida jest odpowiedzią na otrzymane sugestie od użytkowników Scruma przez twórców Scruma.

5 Wartości Scrumowych to: Zaangażowanie, Skupienie, Otwartość, Szacunek oraz Odwaga. Współpraca Zespołu Scrumowego, który respektuje i wciela w życie te wartości prowadzi do osiągnięcia sukcesu. Sprawia, że trzy filary: przejrzystości, inspekcji i adaptacji urzeczywistniają się, a Zespół Scrumowy ma do siebie zaufanie.

Podsumowanie

Metodyki zwinne są otwarte na zmiany. Są odpowiedzią na wymagania klienta, które często zmieniają się w trakcie trwania projektu. Projektowanie i wdrażanie e-commercu w ramach tego co proponuje Scrum przynosi realne korzyści w kontekście czasu, jakości i wydajności pracy oraz otrzymanego końcowego produktu. Ważne jest, aby klient, dla którego tworzymy e-commerce wiedział czym jest Scrum ponieważ jest on partnerem zespołu. Kooperacja klient – wykonawca umożliwia uzyskanie najlepszych efektów końcowych. W Scrum Guide czytamy, że Scrum jest: lekki, łatwy do zrozumienia, trudny do opanowania. Całkowicie się z tym zgadzam. „Wdrożenie” Scruma pociąga za sobą daleko idące zmiany w sposobie funkcjonowania nie tylko samego działu deweloperskiego, ale i całej organizacji. Scrum nie jest panaceum na wszystkie problemy i bolączki. „Wdrażając” jego praktyki należy zastanowić się jak to przełoży się na sukces projektu, w jaki sposób mu pomoże. W przeciwnym razie może mu tylko zaszkodzić.