Czy Agile jest dla Ciebie-min

Czy Agile jest dla Ciebie?

Podsumowanie: 

Czy Agile to tylko modne hasło? Czy Scrum sprawdzi się najlepiej w każdym projekcie? Od czego zależy wybór metody pracy, której użyjesz w swoim zespole? Jaką metodę pracy najlepiej wybrać do wdrażania oprogramowania?

Jeżeli otoczenie biznesowe lub potrzeby interesariuszy ulegają zmianie w trakcie cyklu życia projektu/produktu, wówczas pojawia się istotny sygnał dla organizacji, że nie może działać w sposób tradycyjny. Potrzebuje praktyk, które pozwalają jej działać zwinnie (Agile), czyli patrzeć z perspektywy dostarczanej wartości, szybko reagować na zmiany i informację zwrotną, szybko porównywać osiągane korzyści z planem. Powodem, dla którego dyrektorzy stosują Agile, jest to, że chcą wprowadzać zmiany w organizacjach, aby mogły konkurować i prosperować w coraz szybciej zmieniających się środowiskach,  dostarczać lepsze wyniki dla swoich klientów i interesariuszy, działać bardziej wydajnie i konsekwentnie. Metody zwinne nie dotyczą tylko produkcji oprogramowania, ale mogą dotyczyć marketingu, produkcji czy NPD (New Product Development).

Na poniższym wykresie pokazałem najczęstsze przyczyny wdrożenia Agile w organizacji wg 15 rocznego raportu o stanie Agile.

Wyniki tego samego badania pokazują, na jakie aspekty pozytywnie wpłynęło wdrożenie Agile. Może zaskakuje niski wynik redukcji kosztów – 23%, jednak nie to jest celem wdrożenia Agile. Celem jest szybsze dostarczanie rozwiązań. W związku z tym koszt jest stały (koszt zespołu), ale tym samym zespołem dostarczamy więcej wartości. Pozostałe wyniki nie są raczej zaskoczeniem – cała masa korzyści.

 

Jakie metody pracy możesz wdrożyć?

Manifest Agile zainspirował do stworzenia wielu interpretacji tego, co to znaczy być zwinnym – znane jako frameworki. Cechą wspólną wszystkich zwinnych frameworków jest to, że powtarzają ten sam proces pracy i mają na celu szybkie i częste dostarczanie wartości klientom. Jednak każdy z nich oferuje swój własny smak zwinności.

Mówiąc o Agile należy pamiętać, że mamy do wyboru poniższe metody pracy:

  • SCRUM
  • Kanban
  • Scrumban
  • Extreme Programming (XP)
  • Agile DevOps

15 roczny raport o stanie Agile, publikowany przez digital.ai  po raz kolejny wyróżnił Scrum jako najpopularniejsze podejście Agile, 66% badanych używa tej metody. To samo badanie 15 lat temu wskazywało, że Scrum’a używa 40% badanych. 15% badanych stosuje Scrum najściślej z dodatkami, pochodnymi Scrum (ScrumBan 9% i Scrum/XP 6%).

Najszerzej stosowane i znane podejścia Agile skupiają się na działaniach małych pojedynczych zespołów. Ich celem jest tworzenie większej wartości dla klientów i stworzenie najbardziej produktywnego i zrównoważonego środowiska pracy dla małych zespołów liczących do około 10 osób.

 

Od czego zależy dobór metody pracy zespołu?

Często słyszę pytanie „Czy Scrum jest najlepszy do każdego typu projektu?” Moja odpowiedź brzmi nie. Metody pracy trzeba dobrać do poziomu znajomości problemów oraz poziomu znajomości rozwiązań problemów.

Dobór metod pracy zespołu został przedstawiony na poniższym diagramie. Oś pozioma przedstawia poziom wiedzy o problemie. Oś pionowa reprezentuje poziom wiedzy o rozwiązaniu problemu. W każdym kwadracie wpisałem metody najlepiej dopasowanie zadań.

 

W lewym dolnym kwadrancie problem do rozwiązania jest dobrze znany, a jego rozwiązania również są dobrze znane. Przykładem może być budowa serwerowni wg wykonanego projektu. W tym miejscu tradycyjny model Kaskadowy sprawdza się dobrze. Ale projekty w tej ćwiartce można też realizować w Scrum, bo przecież nikt nie powiedział, że w trakcie budowy nic nas nie zaskoczy i nie trzeba będzie dostosowywać planu do zmian.

Lewa górna ćwiartka reprezentuje znany problem, ale nieznane rozwiązanie. Pamiętaj, że w tych kwadrantach są gradacje, więc możemy nie do końca znać problem i możemy znać kilka możliwych rozwiązań do wypróbowania. Dlatego ten kwadrant reprezentuje eksperymentowanie w przestrzeni rozwiązań. Przykładem takiego projektu jest stworzenie mapy Polski na bazie map Open Source. Problem jest zdefiniowany, a rozwiązań jest kilka. To idealne miejsce dla Scruma i pracy iteracyjnej, testowania rozwiązania z klientem małymi krokami i korygowania, gdy dowiadujemy się więcej o problemie.

Prawy górny kwadrant to miejsce, w którym nie wiemy na pewno, na czym polega problem i dlatego nie możemy zaproponować dobrego rozwiązania. Przykładem jest identyfikacja zachowań konsumentów, które potraktujemy jako szansa. Żeby zaproponować jakieś rozwiązania musisz zidentyfikować problem. W tym kwadrancie sprawdzi się Lean Startup, czyli eksperymentowanie w przestrzeni problemowej.

Prawy dolny kwadrant to sytuacja w której nie znamy problemu, ale znamy rozwiązanie. W zasadzie nie wiemy jakie problemy się pojawią, ale jesteśmy na nie gotowi. W tym kwadracie sprawdzi się Kanban stosowany w działach, które mają ciągły strumień wejściowy nieplanowanej pracy, na którą należy zareagować. Mogą obejmować one obsługę klienta, konserwację oprogramowania połączoną z tworzeniem oprogramowania.

Przyjrzyjmy się teraz na czym te metody polegają.

 

SCRUM

Scrum nadaje strukturę procesowi pracy. W Scrumie zespoły pracują w cyklach zwanych Sprintami, które tworzą kadencję regularnego tworzenia małych przyrostów pracy (wartość dla klienta). Scrum pozostawia również miejsce na wyciągnięcie wniosków i adaptację do zmieniających się warunków  w trakcie retrospekcji Sprintu, które odbywają się pod koniec każdego Sprintu i pomagają zespołom w ciągłym doskonaleniu ich współpracy. Zespoły Scrumowe dzielą swoich członków na trzy różne role – ekspertów, którzy tworzą produkt, właściciela produktu, który jest odpowiedzialny za zadania i nadaje im priorytet oraz Scrum Mastera, który pomaga zespołowi działać zgodnie z zasadami Scrum. Zespół ma charakter wielofunkcyjny co oznacza, że wszystkie potrzebne do wykonywania pracy dostępne są w zespole. W Scrumie z góry decydujesz, jakie funkcje zostaną ukończone w następnym sprincie. Zadania są wtedy blokowane, praca jest wykonywana w ciągu Sprintu, a kolejka zadań jest opróżniana na koniec sprintu.

Scrum to świetny sposób na rozpoczęcie pracy z Agile, zwłaszcza dla mniejszych organizacji. Ponieważ jest to jeden z najpopularniejszych frameworków zwinnych, dlatego dostępnych jest dużo zasobów, które mogą Ci w tym pomóc. Scrum doskonale sprawdza się w projektach wymagających głębokiej współpracy i innowacji. Scrum najlepiej sprawdza się w małych wielofunkcyjnych zespołach (7+/-2). Scrum świetnie nadaje się do dostarczania wspólnych celów. Scrum sprawdza się również dobrze w zespołach wykraczających poza tworzenie oprogramowania, takich jak marketing czy zespoły projektowe.

Agile Advice wymienia 23 obowiązkowe i 12 opcjonalnych zasad wdrażania Scrum, co tworzy sztywne ramy. Niewiele organizacji faktycznie przestrzega wszystkich reguł, co prowadzi do tego, co nazywa się ScrumBut (wdrażamy Scrum, ale). ScrumBut oznacza, że firma ignoruje określone reguły Scrum z powodów wewnętrznych, co prowadzi do nieoptymalnego wykorzystania frameworka.

 

Kanban

Kanban jest mniej restrykcyjny niż SCRUM. Jego zasady są następujące:

  • Wizualizuj przepływ pracy
  • Ogranicz prace w toku

Dzięki tylko dwóm zasadom Kanban jest otwartą i elastyczną metodą, którą można łatwo dostosować do każdego środowiska. Niektóre firmy używają go w całej organizacji – od produkcji po marketing. Możesz dodawać reguły według potrzeb, zapożyczając je od Scrum, jeśli sobie tego życzysz.

Kanban używa centralnej tablicy z kolumnami do wizualizacji przepływu pracy zespołu. W najbardziej podstawowej implementacji tablica zawiera co najmniej trzy kolumny:

  • lista zadań do wykonania – „Backlog”
  • praca w toku – „Work In Progress (WIP)”
  • wykonane – „Done”

Zespoły mogą dodawać inne kolumnę, odpowiadające kolejnym etapom pracy. Kolumny reprezentują kolejne etapy wykonania pracy, a zadania przechodzą przez te kolumny. Celem jest przesunięcie zadań w prawą stronę – wykonano.

W Kanbanie nie masz ograniczeń czasowych związanych ze sprintem, a nacisk kładziony jest na upewnienie się, że praca płynie bez żadnych znanych defektów. Cechą Kanbana jest nałożenie limitów pracy na kolumny w celu ograniczenia kolejek.  Oznacza to, że w danym momencie można pracować nad maksymalną liczbą funkcji lub problemów, co pozwala zespołowi skoncentrować się na dostarczaniu tych elementów pracy o wysokiej jakości. Widoczność przepływu stwarza poczucie pilności.

Kanban jest odpowiedni dla zespołów, które muszą szybko reagować na przychodzące żądania lub mają szybko zmieniające się wymagania dotyczące produktów. Kanban doskonale sprawdza się w powtarzalnej pracy, takiej jak linia produkcyjna. Kanban działa dobrze dla grup większych niż 7+/-2, ponieważ koszty komunikacji i planowania są niższe

. Metoda wspiera również wyspecjalizowane role z różnymi zestawami kompetencji. Te osoby pracują w różnych kolumnach tablicy.

 

ScrumBan

Jak sama nazwa wskazuje, ScrumBan łączy Scrum i Kanban. Ponieważ nie ma żadnego oficjalnego przewodniaka po ScrumBan, więc to zespoły muszą wybrać te części z każdej metody, które najlepiej im służą. W ScrumBanie prawie wszystkie zespoły mają tendencję do utrzymywania tablicy Kanban i ograniczania liczby elementów w każdej kolumnie w dowolnym momencie. Większość praktyków ScrumBan wprowadza cykl pracy podobny do Sprintów Scruma, aby stworzyć rytm. Wprowadzają również retrospektywy. W części wdrożeń wprowadza się również role dla członków zespołu ze SCRUM. Jednak, gdy proces jest bardziej skomplikowany (więcej kolumn na tablicy) to może pojawić się więcej ról eksperckich. Często również wprowadza się codzienne spotkanie standup lub sesję planowania na początku każdego sprintu.

ScrumBan doskonale pasuje do zespołów z doświadczeniem Agile, które uważają, że Scrum jest zbyt sztywny lub Kanban zbyt luźny. ScrumBan pozwala ci znaleźć własny kompromis. Moja praktyka pokazuje, że Scrum często ewaluuje do ScrumBan, ponieważ procesy są bardziej złożone niż zakłada to Scrum (To Do, Doing, Done). Kolejnym powodem jest możliwość wprowadzania zmian w trakcie trwania cyklu, które w Kanbanie nie są problemem. Stosowanie ScrumBan jest również podyktowane brakiem możliwości zaplanowania projektu na 2 tygodnie, ponieważ kolejne zadania są zależne od efektów wykonania poprzednich. Projekty, które prowadziłem w obszarze odkrywania rozwiązań doprowadziły mnie do stosowania tej metody.

 

Extreme Programming (XP)

Jest to metoda pracy specjalnie dostosowana do zespołów programistów. Usprawnia projekty rozwoju oprogramowania poprzez zestaw określonych wartości i praktyk technicznych. Podobnie jak Scrum, kładzie nacisk na włączenie klientów w cały proces, obejmuje pracę w cyklach od jednego do dwóch tygodni z częstymi wydaniami i sesjami planowania oraz obejmuje spotkania stand-up na początku każdego dnia. Najbardziej wyróżniającymi się wartościami i praktykami technicznymi, które odróżniają XP od Scrum są:

  • Programowanie w parach: dwie osoby wspólnie kodują na tym samym komputerze. Zwolennicy XP twierdzą, że ta praktyka prowadzi do wyższej jakości rozwiązań i zmniejsza liczbę błędów, ponieważ dwa umysły myślą o problemach zamiast jednego. Moja praktyka pokazuje, że XP może być również stosowana na początkowym etapie pracy zespołu, gdy kompetencje w rozwiązywania problemów są mniejsze lub gdy zadania są bardzo skomplikowane.
  • Programowanie napędzane testami (TDD – Test Driven Development): Każde wymaganie projektowe jest napisane jako test, który określa, czy funkcja została ukończona, czy nie. Kodowanie rozpoczyna się od napisania testu.
  • Ciągła integracja: wszyscy członkowie zespołu udostępniają swój kod do wspólnego repozytorium zespołu kilka razy dziennie, aby jak najszybciej ujawnić problemy z integracją.

XP nadaje się dla zespołów programistów, którzy chcą zwiększyć wydajność i jakość swojej pracy lub rozwiązywać złożone problemy, trudne do rozwiązania przez jedną osobę. Ponieważ jedną z kluczowych części XP jest programowanie w parach, zespoły mogą się składać z młodszych i starszych członków.

 

Lean Startup

Metoda wykorzystywana w sytuacji, w której nie wiemy na pewno, na czym polega problem i dlatego nie znamy dobrego rozwiązania. Sytuacja zazwyczaj dotyczy problemów złożonych, w których istnieje wiele możliwych rozwiązań i wiele ścieżek dojścia do rozwiązania. W rozwiązaniach tego typu problemów nie chodzi o rozwiązania uniwersalne, ale rozwiązania wydajne/innowacyjne.

W takich przypadkach najlepiej sprawdzi się Lean Startup. Ta metoda to zasadniczo eksperymentowanie w przestrzeni problemowej. Składa się z czterech etapów:

  • Zdefiniowanie problemu klienta i postawienie hipotezy. Efektem jest pomysł na coś nowego lub hipotetyczna okazja do przetestowania.
  • Następnie planowane są krótkie eksperymenty, które mają za zadanie zweryfikowanie postawionej hipotezy. Najczęściej planuje się minimalny produkt (MVP).
  • Korzystając z krótkich iteracji szukamy opłacalnego uzasadnienia biznesowego. Rozwiązanie jest testowane na klientach i zbierana jest informacja zwrotna.
  • Każda iteracja prowadzi do wniosków: pozostanie na kursie, zmiany/usprawnienia/ratowanie, zanim stracimy zbyt dużo pieniędzy.

W praktyce Lean Startup może poprzedzać wdrożenie Scrum.

Gdy rozwiązanie zostanie wypracowane i przyjęte na rynku, może być dalej rozwijane w Scrum.

 

DevOps

Kultura DevOps wyrosła z Agile i pomaga przyspieszyć czas wprowadzania produktów na rynek. Jeśli Twój zespół i projekt korzystają z Agile, powinieneś rozważyć praktyki DevOps.

DevOps to kultura inżynierska, której celem jest ujednolicenie rozwoju i operacji w sposób, który prowadzi do bardziej wydajnego rozwoju. Skutecznie wykonane praktyki DevOps skutkują szybszymi i bardziej niezawodnymi wersjami oprogramowania, które są dostosowane do operacji biznesowych. Nie jest to standard ani ramy, ale współpraca organizacyjna, która dała początek zestawowi najlepszych praktyk poprzez ciągłą integrację, ciągłe dostarczanie i ciągłe testowanie.

Helen Beal z DevOps Institute  powiedziała „Myślę, że bez Agile i DevOps trudno byłoby Ci stać się cyfrowym przedsiębiorstwem”.

Cechy charakterystyczne DevOps:

  • Dzięki DevOps wdrażasz kod w środowisku produkcyjnym pod koniec każdej iteracji (sprintu), podczas gdy w przypadku Scrum, celem jest przygotowanie tylko kodu nadającego się do wysyłki na końcu każdej iteracji.
  • Automatyzacja testów i ciągła integracja oprogramowania, które są warunkiem ciągłego dostarczania oprogramowania, są częścią DNA praktyk tworzenia oprogramowania. W Scrum dostarczanie oprogramowania jest planowane i może być realizowane przez inne zespoły.
  • Dzięki DevOps zespoły są zorientowane na produkty i usługi, które tworzą wartość biznesową dla organizacji od razu po wgraniu na środowisko produkcyjne.
  • W przypadku DevOps wszyscy w zespole troszczą się o jakość usług (przez jakość oprogramowania i doskonałość operacji), gdyż celem jest oddanie działającego oprogramowania.
  • DevOps troszczy się o architekturę rozwiązania, aby zapewnić jakość i ciągłe dostarczanie. W Scrum nie jest wbudowane dbanie o architekturę rozwiązania.
  • DevOps koncentruje się na kompleksowej organizacji produkcji oprogramowania (ciągła integracja kodu wszystkich programistów i ciągłe dostarczanie), aby umożliwić jak najlepsze wyniki biznesowe. Scrum skupia się tylko na realizacji zadań przez zespół ekspertów.

DevOps wykorzystuje metody Agile:

  • Gdy skoncentrujesz się na przepływie zamiast na ramach czasowych to Kanban będzie atrakcyjnym wyborem do użycia z DevOps. Wdrażanie produktu/usługi staje się kolejnym krokiem w procesie. Jeśli Twój zespół jest odpowiedzialny za utrzymanie, rozważ Kanban. Nie ma potrzeby blokowania zadań na czas trwania sprintu i masz większą elastyczność, aby reagować na uwagi klientów.
  • Jeśli Twój zespół jest odpowiedzialny za rozwój funkcji, a programiści muszą się skoncentrować, Scrum jest prawdopodobnie lepszym rozwiązaniem. Nieocenione może być blokowania zadań na czas trwania sprintu i demonstracje przed interesariuszami na koniec sprintu.

Ostatecznie każdy zespół jest inny. Jeśli wiesz co go wyróżnia możesz podjąć właściwe decyzje. Moje doświadczenia potwierdzają bardzo wysoką efektywność zespołów DevOps, gdy zależy Ci na szybkim oddawaniu produktu. Gdy szybciej oddajesz produkt na rynek, to szybciej zaczynasz czerpać z niego korzyści. Moje doświadczenia pokazują, że co 2 tygodnie zwiększasz przychody. Chyba warto?

 

Różnice między DevOps, Agile i podejściem kaskadowym

Trudno dzisiaj wyobrazić sobie firmy, które nie wdrażają oprogramowania. Praktycznie każda firma, która chce konkurować jest firmą informatyczną. Istnieją różne metody i podejścia do tworzenia oprogramowania, jednak nie wszystkie są stosowane w każdej organizacji. Przyjęcie strategii w dużej mierze zależy od rodzaju projektów, jakie firma prowadzi, rodzaju odbiorców, do których jest przeznaczona. Porównajmy trzy popularne podejścia tworzenia oprogramowania.

 

Agile:

  • dotyczy tworzenia oprogramowania iteracyjnie
  • działa w sprintach i iteracyjnie dostarcza wartość
  • celem jest ciągła integracja i wdrażanie wersji oprogramowania
  • plany testów są przeglądane w każdym sprincie
  • nie jest nakierowane na automatyzację
  • zwykle składa się z mniejszych zespołów (6-9 osób)
  • wymagania można modyfikować zgodnie ze zmieniającymi się wymaganiami
  • fazy Agile składają się z planowania sprintu, codziennego Scrum, demo, retrospekcji

 

DevOps:

  • dotyczy tworzenia oprogramowania i zarządzania jego rozwojem
  • kładzie nacisk na współpracę między zespołami programistycznymi i operacyjnymi
  • kładzie większy nacisk na terminy i testy
  • automatyzacja jest rdzeniem
  • często obejmuje bardzo duży zespół
  • DevOps obejmuje planowanie, budowanie, ciągłe dostarczanie, testowanie i informacje zwrotne
  • dotyczy dostarczania rozwiązań typu end-to-end
  • DevOps musi być Agile, aby szybciej i lepiej uzyskiwać pożądane rezultaty
  • pozwala zrezygnować z prowadzenia projektów i zorganizować pracę wokół dostarczania produktu/usługi w trybie ciągłym

 

Metoda kaskadowa:

  • jest podejściem krok po kroku
  • nie ma możliwości cofnięcia się do poprzedniego kroku po przejściu do kolejnego kroku
  • plany testów są rzadko przeglądane
  • nie jest nakierowane na automatyzację
  • nie pozwala na częste zmiany
  • jest odpowiednia do jednorazowych projektów na mniejszą skalę, które mają łatwe do zdefiniowania rezultaty
  • wartość jest konsumowana na koniec projektu

 

Co firmom utrudnia wdrożenie Agile w zespołach?

Musimy zdać sobie sprawę, że wszyscy działamy w ramach ograniczeń, które mogą być uwarunkowane finansami, regulacjami, kwestiami technicznymi, procesowymi lub klientami. Praktyki Agile na początku ograniczały się do tworzenia oprogramowania, jednak organizacje zaczęły stosować je do zarządzania tradycyjnymi funkcjami biznesowymi jak HR, marketing,….  O ile w mniejszych organizacjach realizujących projekty (np. IT lub marketingowe) można sobie poradzić wdrażając prosty framework Agile, o tyle w większych firmach usługowych, czy produkcyjnych nie jest to już takie proste. W niniejszym artykule omówiłem tylko metody stosowane do osiągnięcia zwinności zespołów. Na temat zwinności całej organizacji napiszę w kolejnym artykule.

Wg 15 rocznego raportu o stanie Agile, najważniejsze bariery we wdrożeniu Agile to:

  • Niespójności w procesach i praktykach 46%
  • Starcia kulturowe 43%
  • Ogólny opór organizacyjny wobec zmian 42%
  • Brak kompetencji i doświadczenia 42%
  • Brak udziału liderów 41%
  • Niewystarczające wsparcie zarządu i sponsora 40%
  • Niewystarczające szkolenie 35%
  • Powszechność tradycyjnych metod rozwoju 35%
  • Brak myślenia w kategoriach biznes/klient/produkt 31%
  • Niechęć do przyznania się do błędów i uczenia się na niepowodzeniach 22%

Badania te wskazują, że bez silnego umocowania zwinności w zarządzie, trudno jest takie projekty prowadzić. Oznacza to, że projekt się nie uda, jeśli nie dokonasz zmian w kulturze organizacyjnej. Zmiany kulturowe spowodują wyeliminowanie oporu organizacji i skoncentrują działania pracowników na realizacji nowych celów.

Nawet jeśli firma chce wdrożyć praktyki Agile, to przy niespójnych procesach, procesach spaghetti trudno jej to będzie zrobić. Wdrożenie praktyk Agile w zespołach podczas, gdy te zespoły mają wiele interakcji z innymi zespołami niewiele zmieni. Dlatego podstawowym krokiem przed wdrożeniem praktyk Agile jest uporządkowanie organizacji wokół dostarczania wartości do klientów. Opracowanie architektury (optymalizacja operacji) skoncentruje firmę na tworzeniu wartości i zmniejszy liczbę interakcji między zespołami.

Obecność w organizacji osób znające praktyki Agile (czy to Scrum, czy Kanban) lub DevOps znacznie ułatwia wdrożenie. Jednak takie osoby najczęściej nie mają doświadczenia we wdrożeniu Agile w całej organizacji (od zarządu do zespołu, jak również ułożenie współpracy między zespołami). W procesie takim dobrze jest zdać się na specjalistów z doświadczeniem. Nie tylko zaproponują oni najlepsze metody, ale zaplanują proces dostarczania wartości, uruchomią procesy Agile na wszystkich poziomach organizacji, zaplanują synchronizację i współpracę między zespołami przy dostarczaniu wartości.

Jeśli planujesz wdrażać systemy informatyczne to możesz wziąć pod uwagę cztery metody w zależności od zadania, które masz do wykonania: Scrum, Lean Startup, DevOps, ScramBan. Gdy chcesz osiągnąć wysoki poziom dojrzałości produkcji oprogramowania i szybko wprowadzać produkt na rynek, to najlepiej postawić na DevOps. Do wdrażania zewnętrznych systemów zastosuj Scrum lub ScramBan.

Tagi: Brak tagów

Możliwość komentowania została wyłączona.