_Agile. Wszystko co musisz wiedzieć o metodyce zwinnej

Czym właściwie jest agile? Jak to się wszystko zaczęło? Jakie zasady charakteryzują tę metodykę działania, czym różni się ona od podejścia tradycyjnego i w jaki sposób efektywnie (i zwinnie) prowadzić projekty? Przedstawiamy zbiór informacji, który każda osoba związana w jakikolwiek sposób z technologiami, powinna poznać. Mamy nadzieję, że uznacie je za wartościowe oraz godne polecenia. Zapraszamy do komentowania, a w przypadku pytać szczegółowych – do kontaktu

Agile – zwinne podejście do pracy. Skąd się to wzięło?

O „agile” i „zwinnym” podejściu do prowadzenia projektów słyszeli już chyba wszyscy. Ale czy wszyscy mają świadomość historii jaka stoi za sformułowaniem zasad z tym związanych? Prawdopodobnie nie – dla tych osób krótko opiszemy, jak to wszystko wyglądało.

Idea „agile” została stworzona w 2001 roku przez grupę programistów, którzy spotkali się w kurorcie narciarskim, w górach Utah. Ich celem, oprócz rozrywki i dobrze spędzonego czasu, było przeprowadzenie dyskusji na temat zmiany podejścia do procesu tworzenia oprogramowania. Potrzeba była podyktowana tym, że biznes miał trudności z dogadaniem się ze specjalistami rzeźbiącymi w kodzie; czas tworzenia aplikacji był mocno rozciągnięty w czasie, zmiany w technologiach następowały bardzo szybko, frustracja rosła a projekty często nie dochodziły do skutku lub kończyły się dostarczeniem rozwiązania, które już było przestarzałe w porównaniu z produktami konkurencji. Konieczne stało się znalezienie sposobu na tworzenie oprogramowania, uwzględniającego wiele zmiennych oraz takiego, które pozwoliłoby na szybsze wyprowadzenie aplikacji na rynek.

Problem zdiagnozowano jako złe podejście do samego prowadzenia projektu – zmiany należało zacząć „od podstaw” czyli już na etapie planowania pracy. Do tej pory (czyli do pamiętnego wyjazdu w góry) tworzenie oprogramowania rozpisywano i prowadzono tak, jak np. budowanie domu czy wprowadzanie nowego jogurtu na rynek. Odgórnie rozpisywano harmonogram prac, dzieląc projekt na następujące po sobie etapy – bez realizacji jednego, nie można było przejść do kolejnego; od razu także szacowano koszty i przydzielano konkretny budżet do wykorzystania; klient musiał zatem przekazać wszystkie wymagania licząc się z tym, że dodatkowe zmiany wprowadzą chaos i będą trudne do zrealizowania. Takie podejście (nazywane kaskadowym, ang. Waterfall) w przypadku projektów o wielu zmiennych, które trudno przewidzieć po prostu się nie sprawdziło.

Luty 2001r. okazał się krokiem milowym prowadzącym do zmiany sposobu pracy zespołów developerskich. Po burzliwych rozmowach, 17stu programistów doszło do porozumienia, w wyniku którego powstał: Manifesto for Agile Software Development, czyli spis 12 zasad i ogólnej idei zwinnego podejścia do prowadzenia projektów programistycznych.

Od tamtej pory minęło już prawie 20 lat, w czasie których powstało mnóstwo publikacji na temat agile, aplikacje ułatwiające prowadzenie projektów tą metodyką, vlogi, podcasty, kursy, szkolenia, certyfikaty –  idea została z powodzeniem wdrożona w wielu firmach ułatwiając realizację projektów; jej skuteczność i rosnącą popularność dobrze prezentują m.in dane z raportu z 2019 roku:

*Początkowo „agile” odnosił się głównie do zespołów pracujących nad tworzeniem oraz rozwojem oprogramowania natomiast z czasem metodyka zwinna została wdrożona także w innych obszarach gospodarki. Ciekawym przykładem może być proces rozwoju myśliwca Gripen przez Szwedzki SAAB prowadzony zgodnie z założeniami agile:
https://www.scruminc.com/wp-content/uploads/2015/09/Release-version_Owning-the-Sky-with-Agile.pdf
Zobacz także: 6 błędnych przekonań na temat metodologii Scrum

Nowe vs Stare. Agile vs Waterfall

 Nowe podejście różni się od „tradycyjnego” tym, że umożliwia pracę w modelu rozproszonego działania – planowanie i realizowanie wymagań opiera się o kompletne funkcjonalności i realizowane są przez małe, stosunkowo niezależne zespoły; wszystko po to aby móc jak najszybciej przekazać do użytkowania część aplikacji, a następnie systematycznie ją testować oraz poprawiać, a także rozbudowywać o kolejne fragmenty.  Dzięki temu czas od zebrania wymagań do wprowadzenia produktu na rynek uległ znacznemu skróceniu, chociaż nie jest równoznaczny z zakończeniem projektu. Działania są prowadzone nielinearnie, co daje większą swobodę zespołom programistów – pracują zgodnie z cyklami (sprintami) skupionymi na dostarczeniu kolejnego fragmentu aplikacji; ważną zmianą w stosunku do podejścia kaskadowego jest to, że właściciel może decydować o kierunku rozwoju w trakcie prowadzenia prac, na podstawie obserwowania postępów oraz zgodnie z czynnikami, które dochodzą lub zmieniają się w trakcie; planowane działania otrzymują priorytety, dzięki czemu zespół wie, które z nich są najważniejsze i pierwsze w kolejności do zrealizowania.

12 zasad metodyki zwinne

Twórcy idei agile wyróżnili 12 głównych zasad, które określają podstawowe założenia tego sposobu pracy. Poniżej umieszczamy najważniejsze założenia każdej z nich wraz z krótkim rozwinięciem:

1. Najważniejsze jest zadowolenie klienta, który otrzymuje szybkie wdrożenie systematycznie udoskonalanego oprogramowania – zwinne podejście musi iść w parze z dostarczaniem wysokiej jakości usług i realizacją wymagań klienta; zmiana podejścia do prowadzenia projektu miała na celu lepsze porozumienie ze zleceniodawcą, sprawniejszą współpracę i jaśniejszą komunikację oraz możliwość szybkiego pokazania efektów pracy.
2. Bądź otwarty na zmiany, nawet na późnym etapie projektu – branża technologiczna zmienia się bardzo dynamicznie, dlatego zmiany są konieczne do pozostania „up-to-date” jeśli chodzi o wymagania rynkowe; drugą kwestią jest to, że  klient często dopiero po zobaczeniu pierwszych efektów jest w stanie doprecyzować swoje oczekiwania. Metodyka agile została stworzona w opozycji do sztywnych ram podejścia kaskadowego (waterfall).
3. Systematycznie dostarczaj kolejne części systemu; im częściej to robisz tym lepiej  – dzięki temu klient może szybko przekazać informacje, które posłużą do udoskonalenia aplikacji i usprawnią prace nad projektem.
4. Biznes i zespoły programistów muszą ze sobą współpracować – i nie chodzi o sporadyczny kontakt, a o regularną, ścisłą współpracę dzięki czemu każda ze stron jest zaangażowana w projekt i wie o bieżących działaniach. Konieczne jest zniesienie podziałów między zespołami, ponieważ blokują one kreatywną współpracę specjalistów różnych dziedzin.
5. Twórz projekty wokół zmotywowanych jednostek, wspieraj je, ufaj im i dostarczaj tego, czego potrzebują do realizacji projektu – każdy projekt, zwłaszcza długotrwały i wymagający dużego nakładu pracy (a właśnie takimi cechami charakteryzują się projekty deweloperskie), potrzebuje zaangażowanego kierownika; ktoś kto nie będzie „czuł” projektu, być może poprowadzi go poprawnie ale z pewnością nie wykorzysta w pełni możliwości i potencjału zespołu.
6. Najlepszym sposobem na przekazywanie informacji jest rozmowa twarzą w twarz – trudno się nie zgodzić! Maile i komunikatory są wspaniałym udogodnieniem, jednak kontakt osobisty zawsze pozostawia najlepsze wrażenie i jest najbardziej owocny.
7. Działające oprogramowanie to podstawowa miara postępu prac – efekty zawsze wyznaczają rezultaty, a nie sam proces. Metodyka agile, choć wyróżnia się elastycznym podejściem, kładzie równie duży nacisk na realizację zadań, co tradycyjne podejście.
8. Procesy zwinne wspierają zrównoważony, trwały rozwój. Sponsorzy, programiści i użytkownicy powinni wypracować stałe tempo działania – ta zasada odnosi się do zespołów zaangażowanych w projekt; dzięki działaniu iteracyjnemu (iteracja to jeden cykl pracy obejmujący wprowadzenie, testowanie i ulepszanie jakiegoś fragmentu programu), zespół bardzo szybko i na wczesnych etapach uczy się na swoich błędach, wyciąga odpowiednie wnioski i sprawnie przechodzi do kolejnych elementów; nie jest zalecana zmiana obowiązków poszczególnych osób czy podzespołów, ponieważ wprowadza to dezorganizację i spowolnienie postępów.
9. Nieustanne skupianie się na doskonałości rozwiązań pod kątem technicznym oraz na dobrym projekcie, wzmacnia zwinność – metodyka zwinna kładzie mocny nacisk na rozwój zespołu pracującego nad projektem, wymaga zaangażowania, poszukiwania nowych metod rozwiązywania problemów i udoskonalania oprogramowania; każda iteracja to kolejna, cenna lekcja i dążenie do dobrze działającego rezultatu końcowego.
10. Prostota to sztuka minimalizowania koniecznej pracy, (po angielsku brzmi to znacznie lepiej) Chodzi o to, aby nie komplikować rozwiązań i nie kombinować za bardzo tam, gdzie nie jest to potrzebne; dana funkcjonalność ma działać – im prościej możemy ją wdrożyć, tym lepiej, szybciej i sprawniej.
11. Najlepsze rozwiązania pochodzą od samoorganizujących się zespołów – ta zasada zwraca uwagę na sposób komunikacji z zespołami odpowiedzialnymi za poszczególne elementy; to zespoły mają być zaangażowanie w swoje zadania; mają samodzielnie szukać rozwiązań, wprowadzać zmiany konieczne do efektywniejszej pracy – kierownik projektu czuwa nad całością ale nie narzuca zespołom jak mają pracować.
12. Dzięki regularności pracy, zespół stale się rozwija, staje się bardziej efektywny, dostosowuje się do zmieniających się wymagań; wyciąga wnioski i odpowiednio zmienia swoje podejście – rozwój, rozwój, rozwój!

Podstawy metodyki zwinnej wcale nie są tak łatwe, proste i przyjemne jak mogą się wydawać; mimo prostych założeń ich wdrożenie bywa bardzo trudne. Kluczową rolę odgrywa tu tzw. czynnik ludzki. Przypominanie sobie tych 12 wyznaczników będzie pomocne nie tylko na początku organizowania zespołów i pracy w podejściu zwinnym, ale także w każdym trudniejszym momencie współpracy.

(Oryginalnie brzmiące zasady znajdziecie tutaj: http://agilemanifesto.org/principles.html)

Jira Software czyli jak prowadzić projekty metodyką agile

Przeszliśmy od historii związanej z początkami metodyki agile, przez różnice między metodyką zwinną, a kaskadową, aż do 12 zasad tego podejścia. Pora przybliżyć kolejną, ważną kwestię – w jaki sposób okiełznać projekt prowadzony w tak (z pozoru!!) niestrukturyzowany sposób? Jak monitorować co dzieje się w poszczególnych zespołach, pracujących nad pojedynczymi elementami całości? Jak przejrzyście określić priorytety zadań tak, żeby każdy potrafił się odnaleźć w mnogości działań? Z pomocą przychodzą w tej kwestii systemy dedykowane do prowadzenia projektów metodyką zwinną. Jednym z najbardziej cenionych jest oprogramowanie Jira Software, które  zawiera zestaw funkcjonalności, umożliwiających organizowanie zwinnych zespołów.

*Ze względu na mnogość podejść do Agile, w dalszej części artykułu skupimy się na SCRUMie, zgodnym ze SCRUM Guidem (https://www.scrumguides.org/).

*W mniejszym stopniu nawiążemy również do SAFe (Scaled Agile Framework – https://www.scaledagileframework.com/), które powstało aby zaadresować niektóre z problemów SCRUMa (głównie problemy skalowalności do dużych organizacji), a mimo zwinności w nazwie, przez wiele osób jest uważane za metodykę hybrydową.

Najważniejsze funkcjonalności Jira Software w kontekście metodyk zwinnych:

Sprinty

 są w SCRUMie głównym elementem, wokół którego przeprowadzane jest planowanie prac. Jira umożliwia stworzenie sprintów o wybranej długości i przypisanie do nich zadań. Możliwe jest stworzenie jednego sprintu per Backlog lub wielu równoległych sprintów korzystających z tego samego bakclogu – w przypadku konieczności posiadania wielu zespołów pracujących nad jednym zestawem wymagań.

W niektórych organizacjach może istnieć konieczność planowania prac w dłuższej perspektywie (np. ze względu na zależności z innymi obszarami nie pracującymi w metodyce Agile), lub lepszej wizualizacji zależności między zadaniami. Zaadresowanie tej potrzeby opisane będzie dalej w tym artykule przy okazji omawiania dodatków do Jira.

Zadania

(taski) są podstawowym elementem systemu Jira, który jest wykorzystywany do organizacji działań; zadanie w Jirze jest elementem pracy do wykonania dowolnego typu lub rozmiaru; ułatwia identyfikację oraz podział pracy na konkretne czynności oraz pokazanie kontekstu, w jakim są osadzone.Jira Software umożliwia definiowanie różnych typów zadań, o dowolnych rozmiarach, co znacząco ułatwia zarządzanie pracą. Na przykład: w danym projekcie mogą istnieć zadania typu Epic – będące najbardziej ogólnymi i największymi zadaniami. Każdy Epic będzie składał się z wielu scenariuszy użycia, a te będą składały się z sub-tasków.

Sub-taski są  najmniejszymi elementami w projekcie, które z łatwością mogą być wykonane przez jedną osobę. Każdy typ zadań może zawierać szereg pól, które będą dostosowane do wymagań użytkowników i będą zawierały wszystkie informacje niezbędne do dostarczenia prac związanych z tym zadaniem.

Istnieje możliwość m.in. przypisania każdego zadania do odpowiedzialnej osoby, powiązania ich z innymi zadaniami (np. określając jego zależność od innego zadania), komentowania czy śledzenia historii zadań. Tworzenie zadań może być dozwolone zarówno dla każdego użytkownika, jak i tylko dla wybranej grupy – zależnie od projektu, typu zadania etc.

Każde zadanie może mieć określone ile czasu jest przewidziane na jego wykonanie (w postaci czasu lub Story Pointów), a użytkownicy mogą rejestrować ile czasu spędzili pracując nad nimi.

Każdy z typów zadań może mieć zdefiniowany indywidualny przepływ pracy.
Przepływy prac to sekwencja stanów w jakim każde zadanie może znajdować się od jego utworzenia, aż po zamknięcie. Prosty przepływ pracy może wyglądać następująco:

W tym przypadku etykiety OPEN i DONE i wszystkie między nimi określają status w jakim może się znaleźć zadanie . Strzałki reprezentują natomiast możliwe przejścia z jednego statusu, w kolejny. Przepływy pracy rozciągają się od bardzo prostych, aż po bardzo skomplikowane – z zawierającymi warunki, triggery, walidatory i funkcje post. Umożliwia to nie tylko dostosowanie każdego z przepływów do indywidualnych potrzeb, ale również automatyzację dużej części powtarzalnych czynności. Dzięki temu można usunąć obowiązki związane z zarządzaniem zadaniami, które zabierają dużo czasu, i nie przynoszą zbyt wiele wartości dodanej.

Tablice zadań
Jira umożliwia tworzenie ekranów pozwalających spojrzeć na sytuacje z różnych perspektyw poprzez wyświetlenie zadań odfiltrowanych po ustawionych kryteriach (takich jak osoba przypisana, status, planowana data zakończenia, sprint, komponent lub właściwie dowolnej inna informacji) i wyświetlonych w określonym formacie (np. Kanban board). Pozwala to na szybki dostęp do często używanych widoków jak np. Zadania przypisane do danego użytkownika, danego zespołu etc.

Widok zadań
Każdy użytkownik ma wgląd do swojej własnej tablicy wyłącznie ze swoimi zadaniami, tablicę swojego zespołu oraz tablicę całego projektu, dzięki czemu może szybko zorientować się jak wyglądają całościowe prace.

Backlog
Każdy z projektów może mieć osobną listę zadań do realizacji. W zależności od metodyki w jakiej prowadzony jest projekt, może być to m.in. backlog, kanban board,  lub inny rodzaj listy zadań. Każde z zadań z takiej listy może być skategoryzowane za pomocą np. etykiet lub spersonalizowanych pól, przypisane do danego wdrożenia, etc.

Baza wiedzy i Dokumentacja

W świecie w którym się poruszamy, gdzie skomplikowanie usług, produktów i środowiska wciąż rośnie, koniczne jest dobre zarządzanie zgromadzoną wiedzą. Confluence jest najlepszym sposobem do uchwycenia i zorganizowania wiedzy, a także zarządzania nią i jej komunikowania. Confluence umożliwia tworzenie dowolnej ilości stron i podstron z informacjami i grupowanie ich w strukturze drzewa. Dzięki głęboko idącej integracji każda ze stron może być połączona z zadaniem z Jiry, co umożliwia realizację zadań z łatwym dostępem po niezbędnych informacji.

Confluence umożliwia tworzenie szablonów dokumentów, współpracę na dokumentach poprzez komentarze, powiadomienia, możliwość edycji każdej strony przez wielu użytkowników, śledzenia historii zmian etc. Dzięki możliwości wgrywania na strony Confluence grafik, multimediów i różnego rodzaju plików, zapewniona jest duża elastyczność przy tworzeniu i edycji dokumentacji oraz baz wiedzy. Dodatkowo połącznie Jiry i Confluence oferuje kilka ułatwień takich jak linkowanie Zadań w Jirze ze stronami w Confluence, lub otwieranie zadań bezpośrednio z poziomu Confluence:

Raporty i wyszukiwanie

Posiadanie wiedzy na temat postępu prac i możliwość szybkiego wyszukania i zaprezentowania potrzebnych informacji, są koniecznością praktycznie w każdej organizacji. Jira umożliwia zaadresowanie tej potrzeby w środowiskach zwinnych poprzez takie funkcjonalności, jak:

• Wyszukiwarka Zadań w dużych projektach ilość tworzonych zadań często sprawia, że pojedyncza osoba nie jest w stanie ich wszystkich śledzić i traci kontrolę nad tym co się dzieje. Atlassian zaadresował ten problem poprzez zaawansowany system wyszukiwania, pozwalający  na filtrowanie zadań przez pryzmat każdego pola dostępnego w zadaniu, zadań z nim powiązanych, projektów w których się znajdują etc. Wyszukiwanie może odbywać się za pomocą uproszczonego interfejsu, jak i zaawansowanej wyszukiwarki wykorzystującej kwerendy pisane w języku JQL.
• Raporty 
  Graficzne zaprezentowanie wybranych metryk zapewnione jest poprzez dedykowane dla metodyk zwinnych raporty, takie jak m.in. Velocity chart, Sprint chart, Release Burndown czy wreszczie Burndown chart:

Dodatkowe możliwości

Oprócz standardowych funkcjonalności Jiry dedykowanych pod metodologie zwinne, środowisko Atlassian oferuje również możliwość dalszego dostosowania Jiry do potrzeb organizacji, zarówno w kontekście Agile, jak i szerzej pojętego rozwoju produktów. Realizowane jest to dzięki możliwości instalacji innych systemów integrujących się z Jirą, jak i dodatków do samej Jiry z Atlassian Marketplace (polecamy nasze aplikacje). Kilka z ciekawszych opcji opisanych jest poniżej.

Bitbucket

– narzędzie oparte o Git czyli repozytorium kodu, integrujące się z Jirą. Ułatwia współpracę nad kodem, efektywniejsze buildowanie, testowanie i deployowanie (wydawanie).

BigPicture

– dodatek rozwijający funkcjonalności Jiry o zarządzanie portfelem projektów, zarządzanie projektami w metodologiach kasakadowych, a także bardziej zaawansowanie planowanie dla metodologii zwinnych. W kontekście tego artykułu, szczególnie interesujący jest ten ostatni element. BigPicture dodaje do Jiry moduły pozwalające na planowanie prac zgodnie z SAFe (Scaled Agile Framework). W wielkim skrócie – z punktu widzenia planowania – oznacza to, że możemy planować nie tylko sprinty, ale także Inkrementacje Prograu (PI – Program Increment), która to może składać się z kilku sprintów na mniejszym poziomie szczegółowości. Dodatkowo planowane zadania mogą zostać przypisane do danego zespołu na podstawie dostępności zasobów w danym sprincie lub PI. Co więcej, możliwe jest planowanie i przypisanie zadań na podstawie zestawu umiejętności jakie wymagane są do ich realizacji.

Zwinność (nie) zawsze w cenie?

Dzięki jasno określonym zasadom oraz narzędziom takim jak Jira Software, metodyka agile zadomowiła się w biznesie i jest coraz częściej wykorzystywana do prowadzenia rozbudowanych projektów, o różnym charakterze.  Obecnie nawet największe i najbardziej ociężałe organizacje pełnymi garściami czerpią z założeń metodyki zwinnej, często modyfikując je i dostosowując do swoich potrzeb i specyfiki pracy. Czy zatem agile jest lepsze od innych sposobów prowadzenia projektów? Nie zawsze i nie dla wszystkich.

Zespoły pracujące zwinnie często są niezadowolone z tego, jaką formę przyjmuje ich praca, niesłuszne byłoby więc pisanie pieśni pochwalnych pod adresem agile wiedząc, że ta metodyka ma wady. Poniżej przedstawiam najważniejsze korzyści oraz problemy specyficzne dla zespołów zwinnych – pragnę podkreślić, że odnoszą się do działania według framework’a Scrum (mnogość form, jakie może przyjmować agile w tym także podejścia hybrydowe, które łączą agile oraz waterfall mogą posłużyć jako materiał na odrębne artykuły; jest ich tak wiele i tak różnych).

Patrząc na popularność metodyk zwinnych, można popaść w przekonanie, że są one najlepszym możliwym podejściem do pracy. Spróbujmy jednak podsumować, jakie są ich zalety i wady.

Zalety prowadzenia projektów metodyką agile:

Zacieranie podziałów między zespołami biznesowymi a IT

Jedną z największych zmian jakie wymuszają metodyki zwinne jest rozbijanie 'silosów’ w organizacjach. Podziały na Biznes, IT, etc. tracą na znaczeniu. Zamiast tego tworzone są samoorganizujące się zespoły, skupiające się nad rozwojem danego produktu. Podejście to ułatwia planowanie rozwoju projektu, umożliwia większą specjalizację w kontekście rozwijanego produktu a także ułatwia komunikację.

Położenie nacisku na komunikację

Element wymieniony już w poprzednim punkcie, ale na tyle istotny, że warto go wyróżnić i rozwinąć. Metodyki zwinne stawiają na „komunikację ponad dokumentację”. Nie oznacza to, że można zaniechać dokumentowania produktu, natomiast nacisk jest położony na zrozumienie potrzeb i wymagań oraz wnikliwość w podejściu do ich realizacji (a nie bezrefleksyjne przechodzenie od punktu do punktu). Dzięki temu problemy mogą zostać zidentyfikowanie szybciej, zanim staną się trudne do usunięcia.
Dodatkowo częstotliwość sprintów, po których dostarczone rozwiązanie jest prezentowane i omawiane, pozwala na szybsze otrzymywania feedbacku przez zespół, co dodatkowo zmniejsza ryzyko wystąpienia krytycznych problemów.

Ciągłe doskonalenie się

SCRUM ma wbudowane mechanizmy wyciągania wniosków z zakończonych sprintów i implementowania zmian mających poprawić efektywność pracy (Retrospektywa). Porównując to do wielu podejść kaskadowych, gdzie 'lessens learned’ tworzone są dopiero na koniec projektu (jeśli w ogóle), a później i tak są odkładane na półkę, zamiast być wykorzystywane w innych projektach, znacząco zwiększa to efektywność pracy.

Elastyczność
Planowanie w SCRUMie odbywa się ze sprintu na sprint. Oczywiście Product Owner ma wizję na rozwój produktu w dłuższej perspektywie, jednak decyzja o tym, które zadania będą realizowane dalej jest podejmowana podczas kolejnych sprintów na podstawie wykonanych działań i wyciągniętych wniosków. Oznacza to,  że co sprint można dokonać zmiany 'kierunku’ rozwoju. Porównując to z metodykami kaskadowymi, gdzie wiele zmian wymaga ponownego planowania dalszych pracy (a często również serii akceptacji…), wyraźnie widać, że SCRUM pozwala szybciej reagować na zmiany.

Zaangażowanie
W zespole SCRUMowym nie ma kierownika zespołu, odpowiedzialnego za dostarczane funkcjonalności – odpowiedzialny jest cały zespół. Umożliwia to większe zaangażowanie członków zespołu, gdyż nie są oni tylko wykonawcami woli 'tych nad nimi’, ale osobami mającymi realny wpływ na decyzje, zastosowanie rozwiązania i odpowiadającymi za ich konsekwencje.

Sprecyzowanie spotkań
SCRUM ogranicza ilość spotkań członków zespołu do dokładnie zdefiniowanej listy. Co więcej, dla każdego spotkania narzucone są ograniczenia czasowe. Dzięki temu specjaliści nie tracą czasu na spotkaniach, z których nic nie wyniosą, lub które 'powinny być mailem”. Powtarzalność spotkań narzuconych przez SCRUM powala lepiej zaplanować czas członkom zespołu.

Wady metodyki zwinnej:

Niedostosowanie do niektórych typów projektów

Wielu propagatorów agile może się z tym nie zgodzić, ale SCRUM  nie zawsze jest dobrym wyborem. Istnieje kilka czynników, które mogą zdecydować o niedopasowaniu SCRUMa do projektu:

• Projekty ze sztywno określonymi wymaganiami i datą zakończenia. Przykładem mogą być projekty związane z realizacją wymogów prawnych – zarówno zakres jak i 'deadline’ jest sztywno określony przez regulatora. SCRUM nie sprawdza się tutaj, gdyż po pierwsze – tracimy jedną z dużych zalet jaką była elastyczność i możliwość zmiany 'kierunku’ rozwoju produktu (zakres jest narzucony). Po drugie – mając zakres i datę zakończenia, musimy określić jakie zasoby są wymagane do zrealizowania projektu. Wymaga to planowania od początku całości prac (przynajmniej na wysokim poziomie), gdyż planowanie ze sprintu na sprint nie zapewnia, że zakończymy projekt zgodnie z wymogami. Oczywiście można najpierw przeprowadzić analizę całości, i na jej podstawie stworzyć zespoły i określić ilość sprintów, ale to już nie jest czysty SCRUM.
• Rozwijanie produktu, który ma wiele zależności od 'niezwinnych’ produktów lub części organizacji. Praca w zespołach, które do realizacji wielu zadań musi czekać na Release (który ma miejsce np. raz na 3 miesiące) w innej aplikacji, zaczyna niepokojąco przypominać pracę w metodyce kaskadowej. W takich sytuacjach SCRUM traci wiele ze swoich zalet i często jest to frustrujące doświadczenie dla członków zespołu.

Zmienność zespołów

Dla zachowania efektywności pracy zespołu SCRUMowego istotna jest jego względna niezmienność. Wynika to z faktu, że członkowie zespołu, którzy są w nim już od dłuższego czasu pamiętają problemy, z jakimi zmagał się zespół i jakie działania zostały podjęte, aby te problemy rozwiązać. Przy częstej zmianie członków zespołu, wiedza ta z czasem zanika  i ponownie pojawiają się zaadresowane już raz problemy. Co więcej, każda zmiana w zespole ma wpływ na 'prędkość’ zespołu, co utrudnia planowanie.

Niedopasowani członkowie zespołu

Tak jak zwiększenie odpowiedzialności i zaangażowania znalazło się na liście jako jedna z zalet – dla niektórych typów osobowości będzie to wada. Aby zespół scrumowy pracował efektywnie, wszyscy jego członkowie muszą być zaangażowani. Znalezienie takich osób może być jednak trudne, jako, że nie jest to cecha, którą łatwo zweryfikować np. podczas rozmowy kwalifikacyjnej. Oczywiście to samo można powiedzieć o zaangażowaniu w metodologiach kaskadowych, jednak w tym przypadku 'łańcuch dowodzenia’ i sposób w jaki przydzielane są zadania,ułatwia zidentyfikowanie problemu, określa, kto powinien go rozwiązać i daje mu do tego narzędzia.

Patrząc na powyższy opis, można wnioskować, że Agile ma więcej zalet, niż wad. Pamiętać jednak należy, że zawsze trzeba spojrzeć na szerszy kontekst, ograniczenia i zależności jakie występują w organizacji (w tym opinie i nastawienie członków zespołu – temat często traktowany po macoszemu).Powyższe wady i ograniczenia, mimo małej ich liczby, mogą być ‘zabójcze’ przy ślepym forsowaniu metodyk zwinnych.

Jeśli chcesz dowiedzieć się więcej o prowadzeniu projektów metodyką zwinną w kontekście Jira Software oraz innych narzędzi Atlassian, zapraszamy do kontaktu!