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ą regularne małe przyrosty pracy (wartość dla klienta wewnętrznego lub zewnętrznego). 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