Tuesday, April 9, 2019

Specyfika pracy w metodyce Agile Scrum

Metody tradycyjne i zwinne

Warto może zacząć od krótkiego przypomnienia ogólnej charakterystyki metod tradycyjnych i zwinnych zarządzania projektami. Blisko 50 lat temu dr Winston Royce wymyślił, bardzo sformalizowany, tzw. model kaskadowy, który składa się z wielu kolejno następujących po sobie faz, zwykle podzielonych na dwa etapy: analizę i realizację. Metodologie zwinne są znacznie młodsze, początki ich popularności sięgają 2011 r. i są związane z tzw. Manifestem Agile. Ogólnymi wytycznymi zawartymi w manifeście jest przede wszystkim duża elastyczność mająca na celu szybkie dostarczenie klientowi działającego produktu, a następnie stopniowe wprowadzanie dodatkowych funkcjonalności i usprawnień.

Agile = Scrum?

Wiele osób używa pojęcia Scrum zamiennie z terminem Agile i trudno jednoznacznie stwierdzić, czy jest to właściwe, czy nie. Sam Scrum, wbrew popularnym opiniom, nie jest sensu stricte metodą zwinną, jest to raczej rodzaj frameworka, szkieletu. Co więcej, stosowanie Scrum’a, podobnie jak Lean’a lub Kanban’a, implikuje zastosowanie podstawowych założeń podejścia zwinnego Agile.
Założenia te, zgodnie z treścią Agile Manifesto, brzmią następująco:

  • Individuals and Interactions over processes and tools
    (Ludzie i interakcje ponad procesy i narzędzia),
  • Working Software over comprehensive documentation
    (Działające oprogramowanie ponad obszerną dokumentację),
  • Customer Collaboration over contract negotiation
    (Współpracę z klientem ponad formalne ustalenia),
  • Responding to Change
    (Reagowanie na zmiany ponad podążanie za planem.

Na pewno nie jest więc błędem, może raczej pewnym uogólnieniem, utożsamianie najpopularniejszego podejścia jako swoistego symbolu całej gamy możliwości. Osobiście optowałbym jednak za określeniem: metodyka Agile Scrum.

Wykorzystanie Scrum’a w praktyce

Nastawienie na szybkie dostarczenie działającego oprogramowania i późniejszą rozbudowę warunkuje iteracyjny charakter procesu programowania, etapy te są zwane sprintami. Szczegółowy schemat obrazujący sposób realizacji projektu przedstawia załączony schemat. Uogólniając, tworzenie oprogramowania w oparciu o Agile Scrum przedstawia się następująco:

  • W porozumieniu z klientem zostaje utworzony product backlog, czyli następuje nakreślenie ogólnych wymagań klienta względem aplikacji,
  • W czasie zebrania zespołu następuje sformułowanie sprint backlog’a, czyli listy zadań do wykonania w danym przebiegu – sprincie,
  • Sprint, inaczej pojedyncza iteracja, trwa najczęściej od 7 do 30 dni. Polega on na realizacji zaplanowanych zadań, jest to tak zwany przyrost - product increment. Każdy ze sprintów kończy się podsumowaniem i retrospektywą, później zaś następuje powrót do etapu planowania zadań dla następnego przebiegu,
  • Ostatnim etapem, efektem wielu następujących po sobie iteracji, jest zakończenie projektu i przekazanie finalnej wersji oprogramowania kontrahentowi.

Oczywiste, że codzienna praca również ma charakter iteracyjny, ustanawia się krótkoterminowe cele do realizacji, a następnie przeprowadza się ich podsumowanie.

Trzy role w zespole

W ramach zespołu pracującego metodologią Agile Scrum można wyróżnić trzy podstawowe role:

  • Właściciel produktu (product owner), który jest reprezentantem klienta, to właśnie on przekazuje zespołowi wymagania oraz wyznacza kierunek prac,
  • Scrum Master jest de facto przywódcą zespołu projektowego, odpowiada on za przestrzeganie przyjętych zasad oraz maksymalizację efektów pracy,
  • Scrum Master jest de facto przywódcą zespołu projektowego, odpowiada on za przestrzeganie przyjętych zasad oraz maksymalizację efektów pracy,
  • Zespół Deweloperski – składa się programistów posiadających niezbędne umiejętności, aby profesjonalnie zrealizować powierzone im zadanie. Cechami charakterystycznymi zespołu są: samoorganizacja, interdyscyplinarność, brak tytułowania – każdy członek zespołu jest deweloperem, cały zespół odpowiada za finalne efekty – choć poszczególni członkowie mogą się specjalizować w różnych obszarach.

Wady i zalety stosowania metody Agile Scrum

Decyzja o wdrożeniu oprogramowania w oparciu o metodykę zwinną niesie za sobą wiele korzyści dla klienta, które pozostają w sferze marzeń w przypadku realizacji projektu metodami bardziej tradycyjnymi. Przede wszystkim kontrahent ma możliwość naniesienia zmian w projekcie oraz bieżącej regulacji jego zakresu. Po każdym sprincie zleceniodawca otrzymuje do przetestowania aktualną wersję oprogramowania, pozwala mu to zgłosić np. konieczność dokonania korekty lub modyfikacji funkcjonalności. Natomiast ograniczenie do minimum dokumentacji pozwala zaoszczędzić czas zespołu projektowego i tym samym ograniczyć koszty tworzenia oprogramowania. Wspomniana elastyczność niesie również ze sobą pewne zagrożenie, to jest trudność w oszacowaniu początkowych kosztów i nadmierny rozrost projektu, a to niekiedy może doprowadzić do przekroczenia budżetu. Pomiędzy sympatykami metod tradycyjnych i metodyki zwinnej często dochodzi do sprzeczek i wzajemnego przekonywania się o wyższości danej metodologii. Prawda, jak to często się mówi, leży jednak po środku: to dany projekt i jego parametry powinny być głównym argumentem przy wyborze konkretnego sposobu realizacji.