728 x 90

Jak być zwinnym w programowaniu?

Jak być zwinnym w programowaniu?

Scrum jest jednym ze zwinnych podejść do wytwarzania oprogramowania, jednak może być również stosowany do innych produktów i usług. Cechuje się dużą elastycznością dotyczącą reagowania na zmiany wymagań i potrzeb klientów.

Historia opisywanej metodologii sięga 1986 roku. Został wtedy opublikowany artykuł The New New Product Development Game, w którym autorzy Hirotaka Takeuchi i Ikujiro Nonaka opisują w jaki sposób światowe firmy, takie jak Honda oraz Canon, zmaksymalizowały swoje zyski dzięki stosowaniu skalowalnych metod wytwarzania swoich produktów. Autorzy artykułu wskazywali na dużą wartość zespołów pracujących samodzielnie i zdolnych do organizacji swojej pracy w ramach zespołu. Jednak to w 1993 roku Jeff Sutherland wraz ze współpracownikami stworzyli podczas pracy w firmie Easel metodykę nazywaną Scrumem. Podczas opracowywania metodologii Sutherland wykorzystał pomysły przedstawione we wspomnianym artykule z 1986 roku i zastosował je do procesu wytwarzania oprogramowania. Dwa lata później, w 1995 roku Ken Schwaber przedstawił pierwszą pracę o Scrumie. Od tego czasu Jeff Sutherland oraz Ken Schwaber mają duży wpływ na rozwój metodologii, często ze sobą współpracując. Razem opracowali kilka publikacji, w tym bardzo popularny Przewodnik po Scrumie z 2011 roku.

Motywacją do stworzenia zwinnych metodyk wytwarzania oprogramowania była słaba skuteczność modelu kaskadowego stosowanego w ówczesnych projektach. Bardzo poważną wadą tego modelu była niewielka obecność klienta w całym procesie. Miejsce na współpracę z klientem występowało jedynie na początku, podczas projektowania rozwiązania oraz na końcu podczas odbioru przez klienta utworzonego produktu. Powodowało to sytuacje, w których ze względu na nieporozumienia klient otrzymywał niekoniecznie system, o jaki mu chodziło. Z uwagi na to, że niepoprawne rozwiązanie zostało już zaimplementowane, wprowadzanie zmian było bardzo kosztowne. Model kaskadowy cechuje się również tym, że wszystkie elementy systemu muszą zostać zaprojektowane na samym początku i dopiero wtedy zaimplementowane. Trudno jest jednak zastosować tę zasadę w dzisiejszych projektach informatycznych, ponieważ często przy rozpoczęciu prac nad projektem istnieje wiele niewiadomych. W modelu kaskadowym testowanie jest realizowane przez osobny zespół ludzi już po zaimplementowaniu projektu. Jeśli błąd zostanie wykryty dopiero w tym momencie jego naprawa, podobnie jak w przypadku zmiany wymagań, jest również bardzo kosztowna.

Metodologia Scrum w przeciwieństwie do modelu kaskadowego opiera się na modelu przyrostowym. Kolejne funkcjonalności projektu są dostarczane po krótkich iteracjach nazywanych sprintami. Po każdej z takich iteracji jej efekt tzw. przyrost produktu teoretycznie powinien być gotowy do wdrożenia produkcyjnie. Częściej jednak firmy wdrażają przyrost produktu pochodzący z większej ilości iteracji. Koniec iteracji jest również miejscem na współpracę z klientem, co pozwala zwiększyć jego udział w projekcie. Dzięki temu może on na bieżąco informować wykonawcę czy dostarczone funkcjonalności działają zgodnie z jego życzeniem. Oprócz tego praca nad produktem jest realizowana w zespołach, które są samodzielne i same organizują swoją pracę. W ramach projektu nie istnieje szczególny podział na następujące po sobie fazy projektowania, implementacji i testowania. Dopuszczalna jest sytuacja, w której część zespołu implementuje jedną funkcjonalność, a pozostali projektują inną część systemu. Wewnątrz zespołów nie istnieje również ścisły podział na testerów oraz programistów. Najczęściej osoby pracujące w zespole wykonują te zadania, w których są najbardziej kompetentne, ale nic nie stoi na przeszkodzie, by zgłosiły się do innych zadań.

Role w zespole

W omawianej metodyce w skład zespołu scrumowego wchodzą osoby, z których każda pełni określoną funkcję. Tymi rolami są: właściciel produktu, scrum master oraz członek zespołu deweloperskiego. Wszystkie z nich cechują się innymi odpowiedzialnościami, a osoby pełniące te role muszą ze sobą ściśle współpracować, by zrealizować produkt wysokiej jakości. Opisywane poniżej role zostały dodane do standardowego mechanizmu ról oferowanego przez narzędzie Redmine. Pozwala to na identyfikację funkcji pełnionej przez osobę z zespołu scrumowego.

Product Owner (właściciel produktu)

Product Owner (pol. właściciel produktu) jest osobą, która odpowiada za wyznaczanie celów rozwoju produktu w każdej z iteracji. To od niego zależy jakie funkcjonalności i w jakiej kolejności zostaną zaimplementowane. Obowiązkiem właściciela produktu jest przedstawienie zespołowi co ma realizować dana funkcjonalność oraz jakie warunki ma spełniać rozwiązanie. Po zakończeniu prac nad funkcjonalnością jego zadaniem jest sprawdzenie, czy spełnia definicję ukończenia, oraz czy jego realizacja jest odpowiednio wysokiej jakości. W trakcie prac zespołu deweloperskiego powinien być dostępny i odpowiadać na pytania związane ze szczegółami działania implementowanej części systemu.

Oprócz współpracy z pozostałą częścią zespołu scrumowego obowiązkiem właściciela produktu jest współpraca z klientem. Dlatego musi dokładnie poznać wymagania oraz potrzeby klienta. Właściciel produktu we współpracy z interesariuszami umieszcza wszystkie wymagania w rejestrze produktu, którym ma za zadanie się zajmować. Podczas planowania decyduje, które cechy mają zostać zrealizowane przez zespół deweloperski. Ich wybór musi być uzasadniony odpowiednimi warunkami ekonomicznymi. Musi brać pod uwagę koszt wytwarzanej funkcjonalności, potencjalny zysk z jej realizacji oraz ryzyko wystąpienia problemów podczas jej implementacji.

Osoba pełniąca funkcję właściciela produktu musi cechować się bardzo dobrą znajomością domeny produktu. Powinna wiedzieć w jakim celu realizowana jest dana funkcjonalność oraz znać jej biznesowe uzasadnienie. Z uwagi na to, że musi współpracować z deweloperami oraz interesariuszami, czyli osobami pomiędzy którymi występuje sprzeczność interesów, właściciel produktu powinien być osobą o wysokich zdolnościach komunikatywnych, pomagającą osiągnąć satysfakcjonujący kompromis. Z uwagi na podejmowanie decyzji, od których zależy budżet firmy, musi umieć radzić sobie z trudnymi wyborami i robić to odpowiedzialnie.

Scrum master (mistrz młyna)

Scrum master (pol. mistrz młyna) to osoba odpowiedzialna za przestrzeganie zasad metodologii Scrum przez zespół. Jego zadaniem jest przekazywanie zespołowi wiedzy o metodologii, a także ulepszanie implementacji procesów scrumowych w zespole. Na co dzień współpracuje nie tylko z zespołem deweloperskim, ale również z właścicielem produktu. Zajmuje się również usuwaniem wszelkich przeszkód, które mogą niekorzystnie wpłynąć na produktywność zespołu.

Osoba pełniąca funkcję scrum mastera pomaga zespołowi poprzez stawianie odpowiednich pytań. Ma to na celu skierowanie uwagi zespołu na dany problem i być przyczyną rozpoczęcia dyskusji. Scrum master samemu nie udziela odpowiedzi na te pytania, gdyż jego rolą jest nakierowanie zespołu w odpowiednim kierunku. W sytuacji, gdy zespół ze względu na trudne sytuacje omija stosowanie Scruma, zadaniem scrum mastera jest pomoc w usunięciu trudności i ponowne wdrożenie zwinnej metodyki.

Scrum master pełni ważną rolę podczas wszystkich procesów scrumowych. Pilnuje, by zespół przestrzegał wyznaczonych ram czasowych oraz by dyskusja prowadzona przez zespół dotyczyła właściwego tematu. Scrum master jest animatorem takich spotkań, pobudza innych do dyskusji oraz zachęca do działania. Powinien również poszukiwać rozwiązań, które pozwolą zwiększyć produktywność zespołu.

Scrum master powinien być osobą doskonale znającą metodykę Scrum i chętnie dzielić się z innymi tą wiedzą. Musi to być osoba zaradna, umiejąca komunikować się z innymi. Powinien mieć cechy przywódcze typowe dla liderów grupy ze względu na jego rolę podczas aktywności scrumowych. Powinien charakteryzować się dużą cierpliwością, gdyż nie powinien proponować zespołowi gotowych rozwiązań a jedynie zachęcić innych do dyskusji na ten temat. W niektórych firmach zdarza się, że scrum master pełni również inne role w zespole scrumowym. Jest to dopuszczalne, lecz nie zalecane ze względu na możliwe wystąpienie konfliktu interesów. Taki problem może wystąpić w przypadku zbliżania się ostatecznego terminu zakończenia prac, gdy scrum master jednocześnie pełni rolę dewelopera.

Członek zespołu deweloperskiego

W skład zespołu deweloperskiego wchodzą osoby, które są określane mianem dewelopera. W przeciwieństwie do metodologii, które nie cechują się podejściem zwinnym, nie ma ścisłego podziału na testerów, projektantów czy programistów. Zespół składa się z ludzi, którzy są w stanie dostarczyć wartość na koniec iteracji. Nie wyróżnia się też zespołów, których jedynym zadaniem jest projektowanie lub testowanie systemu. Z uwagi na to, że zespoły scrumowe w każdej z iteracji muszą dostarczyć przyrost produktu, który musi być zaprojektowany, zaimplementowany i przetestowany, muszą się tego zadania podjąć osoby będące w zespole. Członkowie zespołu często mają swoje specjalizacje, lecz muszą posiadać również podstawową wiedzę na temat pozostałych obszarów. Ilość osób w zespole deweloperskim wynosi najczęściej od pięciu do dziewięciu osób. Jeśli zespół zawiera więcej niż dziewięć osób, najlepiej jest go podzielić na dwa mniejsze zespoły.

Głównym obowiązkiem zespołu deweloperskiego jest dostarczenie na koniec iteracji przyrostu produktu. Zespół przeznacza na to najwięcej czasu i musi w tym celu samodzielnie zorganizować swoją pracę. Oprócz tego zespół ma również inne obowiązki. Członkowie zespołu muszą brać udział w aktywnościach scrumowych. Każdy z deweloperów na codziennym krótkim spotkaniu musi poinformować zespół, co udało mu się zrobić od ostatniego spotkania, a także jaki ma plan na najbliższy dzień. Wymagane jest również uczestnictwo w aktywnościach na początku i końcu każdej z iteracji takich jak planowanie sprintu, przegląd sprintu oraz retrospekcja sprintu. Oprócz tego muszą pielęgnować rejestr produktu oraz rejestr sprintu tak, by odzwierciedlały aktualny status prac nad produktem.

Wszyscy członkowie zespołu muszą ze sobą współpracować, nikt nie może pracować indywidualnie, w odosobnieniu. Jeśli jedna osoba nie dostarczyła swojej pracy, odpowiedzialność ponosi za to cały zespół. Kenneth Rubin w swojej książce nazywa tę cechę zespołu „postawą muszkieterów”. Wymaga to pełnego zaangażowania wszystkich osób z zespołu przez cały czas trwania iteracji. Zwiększa to także wymianę wiedzy w zespole, gdyż osoba, która nie jest w stanie ukończyć wyznaczonego zadania, będzie chciała uzyskać wiedzę od współpracowników, którzy specjalizują się w tego typu zadaniach. Pozwala to na wytworzenie prawdziwych zespołów, w których deweloperzy potrafią ze sobą współpracować i darzą się zaufaniem. W Scrumie dąży się do tego, by zespoły były długotrwałe, gdyż taki zespół osiąga większą produktywność.

Zespół powinien pracować nad jednym produktem w jednej iteracji. Pozwala to osiągnąć odpowiedni poziom skupienia i koncentracji co przekłada się na większą szansę zrealizowania celu iteracji.

Sprint

Praca z metodyką Scrum odbywa się w iteracjach (przebiegach), nazywanych tutaj sprintami. Sprinty powinny zamykać się w określonym, krótkim, stałej określonej długości czasie, najlepiej od tygodnia do maksymalnie miesiąca. Sprint powinien kończyć się dostarczeniem przez zespół tzw. przyrostu produktu, czyli działającego i przetestowanego fragmentu systemu. Ze sprintem związanych jest kilka aktywności scrumowych.

Planowanie odbywa się na początku sprintu. W trakcie tej aktywności zespół scrumowy ustala cel sprintu, który opisuje motywy biznesowe i wartość sprintu oraz decyduje, które funkcjonalności zostaną na jego koniec dostarczone. Sprecyzowanie celu jest dwustronnym zobowiązaniem, jakie zawierają zespół deweloperski i właściciel produktu. Programiści zobowiązują się do realizacji celu przed końcem sprintu a właściciel produktu do niemodyfikowania celu podczas trwania iteracji. Planowanie sprintu jest dobrym miejscem na estymację wielkości poszczególnych funkcjonalności z rejestru produktu, lecz może do tego służyć również osobne spotkanie. Z uwagi na krótki czas trwania sprintu planowanie jest dokładniejsze niż w przypadku planowania na długi okres.

Przegląd sprintu jest aktywnością, podczas której zespół może uzyskać informację zwrotną dotyczącą dostarczonego przyrostu produktu. Odbywa się ona na końcu iteracji tuż przed retrospekcją sprintu.

Uczestnikami przeglądu sprintu są nie tylko członkowie zespołu scrumowego. Oprócz nich w aktywności mogą brać udział wewnętrzni interesariusze, klienci oraz inne zespoły scrumowe. Każdy z uczestników może krytycznie spojrzeć na dostarczony przyrost produktu i udzielić informacji zwrotnej. Z uwagi na krótkie iteracje takie przeglądy odbywają się często i klient może zrezygnować z nietrafionych funkcjonalności wtedy, gdy koszt zmian będzie jak najmniejszy.

Retrospekcja sprintu to aktywność występująca na końcu sprintu po jego przeglądzie. W przeciwieństwie do przeglądu sprintu, który skupiał się na inspekcji samego produktu, podczas retrospekcji ocenie poddaje się sam proces jego wytwarzania. Jej ustalenia pozwalają na lepsze dostosowanie metodologii do warunków specyficznych dla zespołu scrumowego.

W retrospekcji udział bierze zespół scrumowy. Podczas tej aktywności członkowie zespołu mogą prześledzić, co wydarzyło się w sprincie. Daje to możliwość identyfikacji problemów występujących w procesie wytwórczym. Gdy problemy zostaną zidentyfikowane, zespół powinien przeprowadzić analizę potencjalnych rozwiązań, które pozwolą wyeliminować te problemy z następnych iteracji. Problemy mogą być wyszukiwane na wielu płaszczyznach, w tym wśród używanych narzędzi, komunikacji między zespołami oraz stosowanych praktyk. Zespoły powinny pamiętać o tym, by na retrospekcjach wdrażać niewielką ilość działań naprawczych. Wprowadzenia dużej ilości zmian w jednym sprincie nie pozwala na stwierdzenie, która z nich zwiększyła produktywność zespołu, a która ją obniżyła. Skuteczność wprowadzonych działań naprawczych powinna być przedmiotem dyskusji na kolejnej retrospekcji. Dzięki retrospekcji, która odbywa się w każdym sprincie, zespół ma możliwość na bieżąco poprawiać swoje środowisko pracy, co w realnym stopniu przekłada się na jakość tworzonego produktu.

Podsumowanie

Scrum nie jest metodyką, która odpowiada za eliminację wszystkich błędów podczas wytwarzania oprogramowania. Lepszym stwierdzeniem jest, że jest to środowisko, które pozwala na dobre zarządzanie i organizację pracy. Sama metodologia nie eliminuje błędów, ale pozwala je zidentyfikować w momencie, gdy koszt ich eliminacji będzie jak najmniejszy. Prowadzi to do szybszej i skuteczniejszej realizacji projektu, który będzie zgodny z oczekiwaniami klienta. Autorzy metodologii twierdzą, że Scrum jest lekki, łatwy do zrozumienia, ale trudny do opanowania. Niemniej jednak jest bardzo często używany w projektach IT. Można też znaleźć przykłady zastosowania tej metodyki poza światem programistów: https://www.linkedin.com/pulse/how-scrum-can-used-physical-construction-brian-dreyer

Źródło obrazu: opracowanie własne na podstawie materiałów z mat.umk.pl

Leave a Comment

Your email address will not be published. Required fields are marked with *

Cancel reply

Inne artykuły