Historia Agile sięga publikacji “Manifestu dla Zwinnego Rozwoju Oprogramowania”, składającego się z 12 fundamentów w 2001 roku. Niewątpliwie, pewne formy podejścia Agile pojawiły się wcześniej, ale tylko ten dokument usystematyzował i przedstawił je w takim zakresie, który był wystarczający do użycia. Rok po roku nowe firmy, specjaliści IT i menedżerowie projektów przyłączają się do Manifestu. Pojawiają się nowe metody i wersje systemu zwinnego rozwoju.
Czym jest metodologia Agile (zwinna)?
Agile to interaktywny model rozwoju, w którym oprogramowanie jest tworzone w sposób przyrostowy od początku projektu, w przeciwieństwie do modeli kaskadowych, gdzie kod jest dostarczany na końcu cyklu pracy.
Zwinna metodologia opiera się na podziale projektów na małe operacyjne kawałki zwane historie użytkowników. Zgodnie z priorytetami, zadania są realizowane w krótkich dwuletnich cyklach (iteracjach).
12 zasad, które stanowią Metodologię Agile można streścić w 4 głównych ideach:
- Priorytet ludzi i komunikacji nad narzędziami i procesami;
- Priorytet funkcjonalnego produktu nad obszerną dokumentacją;
- Priorytet współpracy z klientami nad potwierdzeniem umowy;
- Priorytet gotowości do zmian nad podążaniem za początkowym planem.
Metody inherentne Agile:
Scrum
Termin Scrum został zapożyczony z rugby, gdzie oznacza metodę gry zespołowej w formie trzech linii ułożonych przez każdego z rywali próbującego uchwycić piłkę. Aby skutecznie uchwycić piłkę ponownie, nie tylko dobra kondycja fizyczna jest niezbędna – każdy grający w scruma powinien działać wspólnie z innymi, mając jasne zrozumienie celu.
Ta metoda jest z powodzeniem stosowana przez takie firmy jak Microsoft, Yahoo, Siemens Healthcare. Menedżer projektu z Amazon opisał nawet przypadek wprowadzenia Scruma na podstawie zdobytego doświadczenia.
Ponieważ Scrum jest ramą do rozwoju, każdy przykład, który następuje, może różnić się od poprzedniego.
Jeff Sutherland, autor książki “Scrum. Sztuka robienia dwa razy więcej pracy w połowie czasu”, wyróżnił 8 kroków do stosowania metodologii:
- Wybierz właściciela produktu, który zna cel projektu i oczekiwany rezultat.
- Zorganizuj zespół — do 10 osób z umiejętnościami niezbędnymi do stworzenia operacyjnego produktu.
- Wyznacz Scrum mastera, który będzie nadzorował proces pracy projektu i wspierał zespół projektu w rozwiązywaniu wyzwań.
- Stwórz produkt backlog — dla każdego wymagania produktu ustal priorytety na tablicy Agile. W tym procesie rola właściciela produktu jest kluczowa, ponieważ zbiera on prośby dotyczące produktu, aby zespół backlogu mógł je ocenić.
- Zaplanować sprinty (iteracje) — fragmenty czasu na zakończenie określonych łańcuchów zadań.
- Zorganizuj codzienne piętnastominutowe spotkania — zadawaj każdemu członkom zespołu 3 pytania: co zrobił wczoraj, co zrobi dzisiaj, co utrudnia realizację zadania.
- Przeprowadź przeglądy operacyjnych części produktu — angażując interesariuszy w te przeglądy.
- Organizuj retrospektywy — dyskusja o problemach z poszukiwaniem rozwiązań po każdym sprincie. Wprowadź plan modyfikacji w następnym sprincie.
Retrospektywa w Agile
Scrum ma 4 kluczowe elementy:
- Produkt Backlog — lista wymagań dla projektu
- Sprint Backlog — lista wymagań do zrealizowania w nadchodzącym sprincie
- Cel Sprintu — cel sprintu
- Wykres Burndown Sprintu — diagram, który jest aktualizowany w miarę postępu zadań w realizacji. Ułatwia to zrozumienie dynamiki i poziomu zaawansowania zespołu w projekcie.
eXtreme Programming (XP)
Kent Beck, twórca tej metodologii, stworzył metodę ekstremalnego programowania ukierunkowaną na zaspokajanie zmiennych wymagań dotyczących produktów oprogramowania oraz poprawę jakości rozwoju.
Jest stosowana tylko w dziedzinie tworzenia oprogramowania i opiera się na 4 procesach:
- kodowanie — zgodnie z ogólnymi standardami szeregowania zespołu;
- testowanie — testy są zasadniczo tworzone przez programistów przed napisaniem kodu, który będzie testowany;
- planowanie — zarówno dla końcowej wersji jak i dla oddzielnych iteracji. Te ostatnie odbywają się co dwa tygodnie w przeciętnym czasie.
- audyt — zarówno programistów, jak i klienta, aby wyeliminować niejasne punkty oraz określić wymagania i wartości.
Metodologie Crystal
Rodzina tych metodologii opracowana przez Alistaira Cockburna, jednego z autorów „Manifestu dla Zwinnego Rozwoju Oprogramowania”, jest mało znana w niektórych lokalnych dziedzinach zarządzania projektami. Cockburn proponuje klasyfikację według kolorów, opartą na takim kryterium jak liczba osób w zespole: od 2 (Crystal Clear) do 100 (Crystal Red). Kolory Maroon, Niebieski i Fioletowy są przypisane do większych projektów.
Projekty Crystal powinny spełniać 3 podstawowe cechy:
- szybka dostawa operacyjnego kodu — rozwijająca się idea dla iteracyjnego modelu w zwinnym rozwoju.
- poprawa przez refleksję — nowa wersja oprogramowania jest poprawiana na podstawie informacji o poprzedniej.
- „osmoticzna” interakcja — innowacja Alistaira, metafora komunikacji i wymiany informacji między programistami oprogramowania w jednym pomieszczeniu.
Rodzina tych metodologii jest szczegółowo opisana w książce “Crystal Clear: Ludzki model dla małych zespołów” autorstwa Alistaira.
Metoda Dynamicznego Rozwoju Oprogramowania (DSDM)
Nie tylko jedna osoba, a nawet nie zespół, ale konsorcjum 17 brytyjskich firm pracowało nad rozwojem DSDM. Podobnie jak ekstremalne programowanie, DSDM jest stosowane przede wszystkim do tworzenia oprogramowania.
Końcowy użytkownik (klient) odgrywa specjalną rolę w procesie rozwoju. Ta podstawowa zasada jest uzupełniana o następujące podstawowe zasady:
- częste wydania operacyjnych wersji produktu
- autonomia programistów w podejmowaniu decyzji
- testowanie przez cały cykl pracy.
DSDM jest podzielone na wersje, które są aktualizowane w miarę rozwoju technologii i pojawiania się nowych wymagań dotyczących rozwoju oprogramowania. Obecnie ostatnia to DSDM Atern wydana w 2007 roku, chociaż poprzednia (z 2003 roku) wciąż jest w użyciu.
Na początku zespół rozważa wykonalność rozwijania aplikacji i jej zakres użycia. Następnie praca jest podzielona na trzy ze sobą powiązane cykle:
- cykl modelu funkcjonalnego — tworzenie dokumentów analitycznych i prototypów.
- cykl projektowania i inżynierii — uruchomienie systemu.
- cykl wdrożenia — wdrożenie systemu.
Rozwój napędzany funkcjonalnościami (FDD)
Taka metodologia powstała jeszcze przed “Manifestem dla Zwinnego Rozwoju Oprogramowania”.
Chociaż FDD również stosuje iteracyjny model rozwoju, różni się od Agile w następujących cechach:
- więcej uwagi na wstępnym modelowaniu
- zwiększone (w porównaniu do Agile) znaczenie sporządzania raportów i wykresów
- metodologia jest przeznaczona do rozwoju korporacyjnego.
Rozwój napędzany funkcjonalnościami składa się z następujących cyklicznych faz:
- Tworzenie ogólnego modelu — wizja projektu oparta na wstępnych danych.
- Tworzenie listy właściwości — podobnej do backlogu produktu w metodologii Scrum.
- Planowanie według właściwości — złożoność właściwości jest oceniana przez każdego członka zespołu.
- Dla każdej właściwości — projekt techniczny i wdrożenie – ostatnia faza po zakończeniu, po której właściwość łączy się z produktem, a cykl powtarza się.
Rozwój Lean Software
Lean Software Development to zestaw zasad lean management (a nie metodologia), które mają na celu zwiększenie efektywności procesu rozwoju i minimalizowanie kosztów.
Ten zestaw obejmuje następujące 7 fundamentów:
- eliminowanie strat — wszystko, co nie dodaje wartości produktowi dla końcowego konsumenta.
- ciągłe szkolenie — ciągły rozwój zespołu zwiększa możliwości efektywnego wypełniania zadań.
- podejmowanie decyzji tak późno, jak to możliwe — priorytet ma wnikliwe rozwiązania, które są dobrze rozwinięte i oparte na zdobytej wiedzy, a nie spontaniczne.
- szybka dostawa — to w zasadzie podstawowa zasada modelu iteracyjnego.
- wzmocnienie zespołu — jedna z zasad “Manifestu…” głosi, że ludzie i ich interakcje są ważniejsze niż procesy i narzędzia. Zespół projektowy jest najlepszą gwarancją pomyślnego wykonania zadań.
- integralność i jakość —musisz zrobić pierwotnie produkt wysokiej jakości, aby nie marnować czasu i zasobów na dalsze testowanie i eliminację błędów.
- wizja całości obrazu — projekt nie może być rozbity na osobne części bez zrozumienia aktualnego statusu rozwoju, jak również celów, koncepcji i strategii rozwijanego oprogramowania.
Wersje metodologii rozwoju Agile
Modelowanie Agile (AM)
Modelowanie Agile to zestaw wartości, fundamentów i praktyk dla modelowania oprogramowania.
AM jest używane jako element w pełnoprawnych metodologii rozwoju oprogramowania — na przykład w ekstremalnym programowaniu lub szybkim rozwoju aplikacji.
Modelowanie Agile ma następujące fundamentalne cechy:
- efektywna interakcja między interesariuszami projektu;
- dążenie do opracowania ostatecznie prostego rozwiązania ze wszystkich możliwych, które spełni wszystkie wymagania;
- ciągły odbiór informacji zwrotnej;
- odwaga do podejmowania decyzji i ponoszenia za nie odpowiedzialności;
- uświadamianie sobie, że wie się absolutnie wszystko.
Agile Unified Process (AUP)
AUP to uproszczona wersja innej metodologii rozwoju oprogramowania — Rational Unified Process (RUP). Od 2012 roku została zastąpiona przez Disciplined Agile Delivery (DAD), ale AUP wciąż jest stosowana tu i ówdzie.
Scott Ambler, autor metodologii, wyróżnił następujące kluczowe punkty w Agile Unified Process:
- Twój zespół wie, co robi;
- Prostota jest najważniejsza.
- Zgodność z fundamentami elastycznej metodologii rozwoju.
- Skoncentrowanie na działaniach wartościowych dla projektu.
- Niezależność w wyborze narzędzi.
- Dostosowana konfiguracja AUP do wymagań konkretnego projektu.
Agile Data Method (ADM)
ADM to zestaw iteracyjnych metodologii rozwoju oprogramowania, które kładą nacisk na formułowanie wymagań i rozwiązań w projekcie poprzez współpracę różnych zespołów. Podobnie jak AUP, ta metodologia nie jest samodzielna.
Zasada Agile Data Method definiuje się przez sześć fundamentów:
- Dane — podstawa do stworzenia każdej aplikacji.
- Problemy w projekcie — mogą być wykryte tylko, jeśli cel i koncepcja projektu są jasno zrozumiane.
- Grupy robocze — oprócz podstawowego zespołu programistów, są grupy przedsiębiorstw, które wspierają inne grupy robocze.
- Unikalność — nie ma idealnej metodologii, więc każdy projekt wymaga narzędzi z różnych metodologii do połączenia.
- Praca zespołowa — wspólna praca jest znacznie bardziej efektywna niż indywidualna.
- „Słodki punkt” — poszukiwanie optymalnego rozwiązania problemu („słodki punkt”) poprzez unikanie ekstremów.
Essential Unified Process (EssUP)
Został rozwinięty przez Ivara Jacobsona, szwedzkiego naukowca, w celu poprawy Rational Unified Process.
EssUP używa koncepcji praktyki, która obejmuje:
- scenariusz użycia — opis zachowania systemu.
- rozwój iteracyjny — tworzenie operacyjnych kawałków kodu w krótkich cyklach, w ciągu kilku tygodni.
- praktyki zespołowe — ukierunkowane na zjednoczenie zespołu i zwiększenie jego efektywności.
- praktyki proceduralne — na przykład “Myśl globalnie, zaczynaj od małych kroków” lub “Zaangażuj interesariuszy w procesy biznesowe”.
W jednej formie lub innej wszystkie praktyki są obecne w metodologiach RUP i CMMI, a także w elastycznej metodologii rozwoju.
Getting Real (GR)
To metodologia efektywna dla startupów i początkujących zespołów, która sugeruje maksymalne wykorzystanie specyficznych cech charakterystycznych dla małych projektów i firm, takich jak mobilność, elastyczność, poszukiwanie nowych rozwiązań, brak sztywnej i skomplikowanej hierarchii itp.
Jason Fried i David Hansson, założyciele firmy 37signals (obecnie Basecamp), określili Getting Real jako system rozwiązywania wykonalnych zadań, który jest ostatecznie prosty, zrozumiały i funkcjonalny.
GR to mieszanka kilkunastu narzędzi zwinnego rozwoju, które są używane do minimalizacji następujących:
- alternatywy
- opcje i ustawienia
- struktura firmy
- spotkania
- obietnice.
Tak niezwykła koncepcja nie stała się powszechna, chociaż niektóre jej elementy połączyły się z innymi metodologiami.
OpenUP (OUP)
To metodologia rozwoju oprogramowania niezależna od narzędzi i wolna od sztywnej struktury, która zapewnia takie praktyki:
- pomiar szybkości pracy zespołu;
- organizowanie codziennych spotkań i retrospektyw po zakończeniu iteracji;
- koncept mikrokroków i wczesne testowanie za pomocą checklist;
- metodologia Agile Model Driven Development (AMDD).
Te praktyki są realizowane na podstawie czterech zasad:
- zgodność interesów i osiąganie wspólnej wizji we wspólnej pracy;
- ciągłe doskonalenie poprzez stałą feedback’;
- skupienie na architekturze aplikacji na wczesnych etapach, aby zminimalizować ryzyko;
- maksymalizacja wartości dla końcowego konsumenta.
Wskaźniki Agile
Biorąc pod uwagę różnorodność narzędzi Agile, praktyk, metod i metodologii, musimy wybrać instrument, który pomoże nam określić, jak skuteczne jest każde z nich.
Metryki są używane jako taki instrument.
Dla większości projektów, te 4 kategorie metryczne będą wystarczające:
- Produktywność — przylega do metryk Velocity i WIP. Pierwsza nie będzie pasować do wszystkich projektów, ponieważ liczba zadań wykonanych na iterację jest mierzona, ale iteracje nie są równe. Metryka Pracy w toku określa limit zadań w różnych fazach: im wyższy, tym gorzej;
- Prognozowanie — metryka Capacity, która polega na określeniu liczby wolnych godzin dostępnych w następnym sprincie. Odpowiednio można zrozumieć ilość czasu dostępnego do pracy, stopień efektywności w realizacji zadań, a także zaplanować liczbę zadań na sprint;
- Jakość — na przykład wskaźnik stabilności wymagań, który jest obliczany według wzoru = (Całkowita liczba oryginalnych wymagań biznesowych + Liczba wymagań zmienionych w danym czasie + Liczba dodanych wymagań + Liczba usuniętych wymagań) / (całkowita liczba oryginalnych wymagań). Ta metryka jest używana do określenia ilości czasu spędzonego na poprawie zadań;
- Wartości — ta metryka jest obliczana indywidualnie w każdym przypadku, w zależności od formatu projektu. Na przykład, w startupie AirBnb, liczba pobranych zdjęć wysokiej jakości została wybrana jako metryka określająca końcową wartość produktu dla użytkowników. W miarę wzrostu tej liczby, liczba użytkowników rosła proporcjonalnie.
Reguły dotyczące metryk są takie same jak dla innych narzędzi Agile.
Nie ma jedynej metryki, która byłaby jednoznacznie poprawna i odpowiednia dla Twojego projektu.
Metryki powinny być na bieżąco rewidowane, przestarzałe muszą być usuwane, a nowe muszą być dodawane w miarę potrzeby. Powinny być zrozumiałe i dostępne dla całego zespołu, nie stając się celem samym w sobie. Metryki dla samych metryk są złym rozwiązaniem.
Mitubustery: Agile
Popularność zwinnej metodologii rozwoju zagrała jej na złego kawałka, a mity o niektórych aspektach Agile można zobaczyć nawet na specjalistycznych portalach. Rozwiążmy je!
Mit nr 1: Agile pasuje do wszystkich projektów.
To najbardziej stanowcze błędne przekonanie. Tylko jedna metoda Agile sama w sobie nie doda wartości produktowi, ani nie zmotywuje zespołu.
Mit nr 2: Agile jest przeciw dokumentacji.
Metodologia zwinnego rozwoju nie jest przeciw dokumentacji, neguje dokumentację jako cel sam w sobie. Gdy chodzi o wybór dokumentacji jako środka komunikacji, Agile naprawdę preferuje komunikację osobistą.
Mit nr 3: Agile i planowanie są niekompatybilne.
Tego mitu zaprzeczają codzienne wydarzenia planowe z 10-minutowymi standupami, a także planowanie iteracji mające miejsce co dwa tygodnie, spotkania sprintowe itp.
Mit nr 4: Agile wymaga wielu poprawek.
Metodologia rozwoju oprogramowania Agile przewiduje poprawki w dwóch formach: poprawki wymagań (użytkownicy rozumieją, czego naprawdę potrzebują) i poprawki oprogramowania (zespoły programistów znajdują lepsze sposoby na pisanie i projektowanie aplikacji). Ale to też zdarza się w innych metodologiach! Co więcej, taka nowość Agile jak model iteracyjny służy do zredukowania negatywnego wpływu poprawek.
Zalety i wady Agile w użyciu
Zalety:
- angażowanie interesariuszy — zespół staje się bardziej zdolny do zrozumienia wymagań klienta. Co więcej, wczesne i częste dostarczanie oprogramowania zwiększa zaufanie interesariuszy do zespołu projektu i czyni zaangażowanie w projekt głębszym.
- wczesne i przewidywalne dostarczanie — model rozwoju oparty na iteracjach (w krótkich okresach trwających od 1 do 6 tygodni) zapewnia elastyczność i przyspiesza wydanie produktu.
- koncentracja na wartości biznesowej — współpraca z klientem zapewnia, że zespół rozumie, jak uczynić produkt ostatecznie wartościowym dla konsumenta.
- ciągłe doskonalenie jakości — testowanie w trakcie każdej iteracji z podziałem na finalną wersję na osobne części operacyjnego kodu ułatwia poprawę i eliminację błędów oprogramowania przed wydaniem ostatecznego produktu.
Wady:
- ścisłe wymagania dla zespołu i klientów — bez bliskiej interakcji między zespołem projektu a użytkownikami, niemożliwe jest zapewnienie wydania wysokiej jakości produktu o wysokiej wartości. Co więcej, obfite narzędzia i metody Agile predestynują, że zespół powinien mieć doświadczenie dla ich właściwego wprowadzenia.
- nieodpowiednie do outsourcowania oraz dla projektów, w których uczestnicy współdziałają ze sobą tylko w trybie online.
- ryzyko, że ostateczna wersja oprogramowania nigdy nie zostanie wydana — co dziwne, ta wada pojawia się przez takie zalety Agile jak iteracyjny rozwój i ciągłe doskonalenie produktu.
- nie powiódł się bez jasnej wizji celów biznesowych projektu — ponieważ zespół Agile kieruje się interesariuszami, niemożliwe jest opracowanie produktu bez celu i koncepcji jasno sformułowanej.
Zastosowania
Nie wszystkie usługi zarządzania projektami lub programy będą odpowiednie do zwinnego zarządzania projektami, ponieważ każda z nich ma swoje specyficzne cechy.
Jeśli Twoja firma jest agencją marketingową i reklamową, projektową, seo lub cyfrową, możesz skorzystać z usługi saas od Worksection, aby cały zespół mógł na niej pracować. Jak dotąd zostaliśmy poleceni przez COXO Digital, Royal ® Advertising i Prozorro.
Oto kilka wskazówek, jak skonfigurować Agile w Worksection:
- skonfiguruj tagi i statusy, które są niezbędne do pracy w Twojej firmie. Statusy mogą być: w toku, weryfikacja, zakończone, wymagana poprawka, krytyczne, funkcje, płatność wymagana. Tagi często brzmą w ten sposób: układ, testowanie, produkcja, koncepcja, kod.
- stwórz backlog projektu i projekt wiosenny.
- stwórz zadania i wstępne listy kontrolne, szkice itp. w backlogu.
- podczas spotkań określ zadania sprintu i przetransferuj je z backlogu do sprintu.
- wykorzystaj dostęp gości klientów do zadań, aby zawsze mieć skoordynowaną i aktualną informację zwrotną na temat projektu.
- oznacz odpowiedzialne osoby w zadaniach, aby każdy kolega wiedział o swoim obszarze odpowiedzialności i czuł się zaangażowany w wynik sprintu.
Werdykt
Dzięki zwinnej metodologii rozwoju oprogramowania, małe zespoły projektowe zyskują maksymalną efektywność. Agile realizuje się poprzez takie inne elastyczne metody jak Scrum, XP, Lean itp.
Nie może być wprowadzony w pośpiechu, przez niedoświadczony zespół, w krótkim okresie,
ale gdy zostanie wprowadzony, Agile poprawi interakcję między IT a biznesem, przyspieszy wydanie produktu na rynek i zwiększy wartość produktu dla końcowego konsumenta.