Historia Agile sięga publikacji “Manifestu dla Zwinnego Rozwoju Oprogramowania”, który zawiera 12 zasad z 2001 roku. Bez wątpienia pewne zastosowania podejścia Agile pojawiły się wcześniej, ale to właśnie ten dokument usystematyzował i przedstawił je w takim zakresie, który był wystarczający do użycia. Z roku na rok nowe firmy, specjaliści IT i kierownicy projektów przywiązują się do Manifestu. Pojawiają się nowe metody i wersje systemu rozwoju zwinnego.
Co to jest metodologia Agile (zwinna)?
Agile to interaktywny model rozwoju, w którym oprogramowanie tworzone jest stopniowo od początku projektu, w przeciwieństwie do modeli kaskadowych, w których kod dostarczany jest na końcu cyklu pracy.
Metodologia zwinna opiera się na podziale projektów na małe operacyjne elementy zwane historie użytkowników. W zależności od priorytetów, zadania są rozwiązywane w krótkich, dwutygodniowych cyklach (iteracjach).
12 zasad, które stanowią Metodologię Agile, można uprościć do 4 głównych idei:
- 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 przestrzeganiem początkowego planu.
Metody charakterystyczne dla Agile:
Scrum
Termin Scrum został zapożyczony z rugby, gdzie oznacza metodę gry zespołowej w postaci trzech linii budowanych przez każdego przeciwnika, który próbuje zdobyć piłkę. Do skutecznego przejęcia piłki niezbędna jest nie tylko dobra kondycja fizyczna – każdy gracz scrumowy powinien działać wspólnie z innymi, z wyraźnym zrozumieniem celu.
Metoda ta jest z powodzeniem stosowana przez takie firmy jak Microsoft, Yahoo, Siemens Healthcare. Menedżer projektu z Amazona opisał nawet przypadek wprowadzenia Scruma, opierając się na zdobytym doświadczeniu.
Ponieważ Scrum jest ramą do rozwoju, każdy z kolejnych przykładów może różnić się od poprzedniego.
Jeff Sutherland, autor książki “Scrum. Sztuka robienia dwukrotnie więcej pracy w połowie czasu”, wyróżnił 8 kroków stosowania tej metodologii:
- Wybierz właściciela produktu, który zna cel projektu i oczekiwane rezultaty.
- Zorganizuj zespół — do 10 osób z umiejętnościami niezbędnymi do stworzenia operacyjnego produktu.
- Wyznacz Scrum mastera, który będzie nadzorował przebieg projektu i wspierał zespół projektowy w rozwiązywaniu problemów.
- Stwórz produkt backlog — dla każdego wymagania produktu ustal priorytety na tablicy Agile. W tym procesie kluczowa jest rola właściciela produktu, ponieważ zbiera on prośby dotyczące produktu, aby zespół backlogu mógł je ocenić.
- Zaplanować sprinty (iteracje) — fragmenty czasu do ukończenia określonych zadań.
- Zorganizuj codzienne piętnastominutowe spotkania — zadaj każdemu członkowi 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.
- Przeprowadź retrospektywy — omówienie problemów w poszukiwaniu rozwiązań po każdym sprincie. Wdrożenie powstałego planu modyfikacji w następnym sprincie.
Retrospektywa w Agile
Scrum ma 4 kluczowe elementy:
- Product Backlog — lista wymagań dla projektu
- Sprint Backlog — lista wymagań do zrealizowania w nadchodzącym sprincie
- Sprint Goal — cel sprintu
- Sprint Burndown Chart — diagram, który jest aktualizowany w miarę postępów w realizacji zadań. Ułatwia on zrozumienie dynamiki oraz poziomu zaawansowania zespołu w projekcie.
eXtreme Programming (XP)
Kent Beck, twórca tej metodologii, stworzył metodę ekstremalnego programowania, mającą na celu reagowanie na zmienne wymagania produktów oprogramowania oraz poprawę jakości rozwoju.
Jest stosowana tylko w zakresie rozwoju oprogramowania i opiera się na 4 procesach:
- kodowanie — według wspólnych standardów układu zespołu;
- testowanie — testy są zasadniczo tworzone przez programistów przed napisaniem kodu, który zostanie przetestowany;
- planowanie — zarówno dla ostatecznego builda, jak i dla pojedynczych iteracji. Te ostatnie odbywają się średnio co dwa tygodnie.
- weryfikacja — zarówno deweloperó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 słabo znana w niektórych lokalnych domenach zarządzania projektami. Cockburn proponuje klasyfikację według kolorów, opartą na takim kryterium jak liczba osób w zespole: 2 (Crystal Clear) do 100 (Crystal Red). Kolory Maroon, Blue i Violet przypisane są większym projektom.
Projekty Crystal powinny spełniać 3 podstawowe cechy:
- szybkie dostarczenie operacyjnego kodu — ewoluująca idea dla modelu iteracyjnego w zwinnej metodzie rozwoju.
- poprawa przez refleksję — nowa wersja oprogramowania jest poprawiana na podstawie informacji dotyczących poprzedniej wersji.
- “osmotyczna” interakcja — innowacja Alistaira, metafora komunikacji i wymiany informacji między programistami oprogramowania w jednej sali.
Rodzina tych metodologii została szczegółowo opisana w książce “Crystal Clear: A Human-Powered Methodology for Small Teams” autorstwa Alistaira.
Dynamiczna Metoda 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 głównie do tworzenia oprogramowania.
Końcowy użytkownik otrzymuje specjalną rolę w procesie rozwoju. Ten podstawowy zasada jest uzupełniana przez następujące zasady:
- częste wydania operacyjnych wersji produktu
- autonomia deweloperów w podejmowaniu decyzji
- testowanie na każdym etapie cyklu pracy.
DSDM dzieli się na wersje, które są aktualizowane w miarę postępu technologii oraz pojawiania się nowych wymagań w rozwoju oprogramowania. Aktualnie ostatnia z nich to DSDM Atern wydana w 2007 roku, chociaż wcześniejsza (z 2003 roku) wciąż jest w użyciu.
Na początku zespół ocenia wykonalność rozwinięcia aplikacji i jej zakres użycia. Następnie prace są dzielone na trzy współzależne cykle:
- cykl modelu funkcjonalnego — tworzenie dokumentów analitycznych i prototypów.
- cykl projektowania i inżynierii — wprowadzenie systemu do użytku.
- cykl wdrożenia — wdrażanie systemu.
Rozwój Zorientowany na Funkcje (FDD)
Ta metodologia pojawiła się jeszcze przed “Manifestem dla Zwinnego Rozwoju Oprogramowania”.
Chociaż FDD stosuje model iteracyjny rozwoju, różni się od Agile w następujących cechach:
- więcej uwagi poświęca wstępnemu modelowaniu
- zwiększona (w porównaniu z Agile) znaczenie tworzenia raportów i wykresów
- metodologia jest zaprojektowana do rozwoju korporacyjnego.
Rozwój Zorientowany na Funkcje składa się z następujących cyklicznych faz:
- Tworzenie ogólnego modelu — wizja projektu oparta na wstępnych danych.
- Opracowywanie listy właściwości — podobne do backlogu produktowego w metodologii Scrum.
- Planowanie według właściwości — trudność właściwości oceniana jest przez każdego członka zespołu.
- Dla każdej właściwości — projekt techniczny i wdrożenie – ostatnia faza, po zakończeniu której właściwość łączy się z produktem, a cykl się powtarza.
Rozwój Oprogramowania Lean
Rozwój Oprogramowania Lean to zestaw zasad lean management (a nie metodologia), które mają na celu zwiększenie efektywności procesu rozwoju i minimalizację kosztów.
Ten zestaw zawiera następujące 7 zasad:
- eliminacja strat — wszystko, co nie dodaje wartości produktowi dla końcowego użytkownika.
- ciągłe kształcenie — bieżący rozwój zespołu zwiększa możliwości efektywnego realizowania zadań.
- podejmowanie decyzji tak późno, jak to możliwe — priorytet mają świadome rozwiązania, które są dobrze rozwinięte i oparte na zdobytej wiedzy, a nie spontaniczne.
- szybkie dostarczenie — to zasadniczo kluczowa zasada modelu iteracyjnego.
- wzmacnianie zespołu — jedna z zasad “Manifestu…” stwierdza, że ludzie i ich interakcje są ważniejsze niż procesy i narzędzia. Zespół projektowy jest najlepszą gwarancją pomyślnego zakończenia zadań.
- spójność i jakość —niezbędne jest, aby produkt był od początku wysokiej jakości, aby nie marnować czasu i zasobów na dalsze testowanie i eliminację błędów.
- wizja całości — projekt nie może być rozpatrywany jako osobne części bez zrozumienia aktualnego statusu rozwoju, a także celów, koncepcji i strategii opracowywanego oprogramowania.
Wersje metodologii rozwoju Agile
Modelowanie Zwinięte (AM)
Modelowanie Agile to zestaw wartości, zasad i praktyk związanych z modelowaniem oprogramowania.
AM jest używane jako element w pełnoprawnych metodologiach 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łe otrzymywanie informacji zwrotnej;
- odwaga do podejmowania decyzji oraz brania za nie odpowiedzialności;
- uświadomienie sobie, że wiesz absolutnie wszystko.
Agile Unified Process (AUP)
AUP to uproszczona wersja innej metodologii rozwoju oprogramowania — Rational Unified Process (RUP). Od 2012 roku został zastąpiony przez Disciplined Agile Delivery (DAD), ale AUP wciąż jest stosowany tu i tam.
Scott Ambler, autor metodologii, wyróżnił następujące kluczowe punkty w Agile Unified Process:
- Twój zespół wie, co robi;
- Prostota jest na pierwszym miejscu.
- Zgodność z zasadami elastycznej metodologii rozwoju.
- Skupienie na działaniach wartościowych dla projektu.
- Niepodległość w wyborze narzędzi.
- Spersonalizowana konfiguracja AUP dla wymagań konkretnego projektu.
Agile Data Method (ADM)
ADM to zestaw iteracyjnych metod rozwoju oprogramowania, które podkreślają formowanie 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 sześć zasad:
- Dane — podstawa dla tworzenia jakiejkolwiek aplikacji.
- Problemy w projekcie — mogą być wykryte tylko, gdy cel i koncepcja projektu są wyraźnie zrozumiane.
- Grupy robocze — oprócz podstawowego zespołu deweloperów, są grupy przedsiębiorstwa, które wspierają inne grupy robocze.
- Unikalność — nie istnieje doskonała metodologia, dlatego każdy projekt wymaga łączenia narzędzi z różnych metodologii.
- Praca zespołowa — współpraca jest znacznie efektywniejsza niż działalność indywidualna.
- “Sweet spot” — poszukiwanie optymalnego rozwiązania problemu (“sweet spot”) poprzez unikanie ekstremów.
Essential Unified Process (EssUP)
Został opracowany przez Ivara Jacobsona, szwedzkiego naukowca, aby poprawić Rational Unified Process.
EssUP wykorzystuje koncepcję praktyki, która obejmuje:
- scenariusz użycia — opis zachowania systemu.
- rozwój iteracyjny — tworzenie operacyjnych fragmentów kodu w krótkich cyklach, trwających kilka tygodni.
- praktyki zespołowe — skierowane na zgrupowanie zespołu i zwiększenie jego efektywności.
- praktyki proceduralne — na przykład, “Myśl globalnie, zacznij mało” lub “Zaangażuj interesariuszy w procesy biznesowe”.
W takiej czy innej formie wszystkie praktyki są obecne w metodologii RUP i CMMI, a także w elastycznej metodologii rozwoju.
Getting Real (GR)
To metodologia skuteczna dla startupów i zespołów początkowych, która sugeruje maksymalne wykorzystanie specyficznych cech, które charakteryzują małe projekty i firmy, takich jak mobilność, elastyczność, poszukiwanie nowych rozwiązań, brak ścisłej i złożonej hierarchii itp.
Jason Fried i David Hansson, założyciele firmy 37signals (obecnie Basecamp), zdefiniowali Getting Real jako system rozwiązywania wykonalnych zadań, który jest ostatecznie prosty, zrozumiały i funkcjonalny.
GR to mix dziesięciu narzędzi rozwoju Agile, które są używane do minimalizowania następujących:
- alternatyw
- opcji i ustawień
- struktury firmy
- spotkań
- obietnic.
Tak niezwykła koncepcja nie stała się mainstreamem, chociaż niektóre jej elementy wchłonęły inne metodologie.
OpenUP (OUP)
To metodologia rozwoju oprogramowania niezależna od narzędzi i pozbawiona sztywnej struktury, która zapewnia następujące praktyki:
- pomiar szybkości działania zespołu;
- organizowanie codziennych spotkań i retrospektyw po zakończeniu iteracji;
- koncept mikro-kroków i wczesne testowanie za pomocą list kontrolnych;
- metodologia Agile Model Driven Development (AMDD).
Te praktyki są realizowane na podstawie czterech zasad:
- uzgadnianie interesów i osiąganie wspólnej wizji w pracy zespołowej;
- ciągłe doskonalenie poprzez bieżącą informację zwrotną;
- skupienie na architekturze aplikacji we wczesnych fazach, aby zminimalizować ryzyko;
- maksymalizacja wartości dla końcowego użytkownika.
Wskaźniki Agile
Ze względu na różnorodność narzędzi, praktyk, metod i metodologii Agile, musimy wybrać instrument, który pomoże określić, jak skuteczne są poszczególne z nich.
Metriki służą jako taki instrument.
W przypadku większości projektów wystarczą te 4 kategorie metryk:
- Produktywność — łączy się z metrykami Velocity i WIP. Pierwsza może nie pasować do wszystkich projektów, ponieważ mierzy liczbę zadań realizowanych w iteracji, ale iteracje nie są równe. Metryka Work-in-Progress definiuje limit zadań w różnych fazach: im wyższy, tym gorzej;
- Prognozowanie — metryka Capacity, polegająca na określeniu liczby idealnych 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 oblicza się 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 przerabianiu 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 poprawnych zdjęć wgranych jako metryka określająca końcową wartość produktu dla użytkowników. W miarę wzrostu tej liczby rosła liczba użytkowników proporcjonalnie.
Zasady mające zastosowanie do metryk są takie same jak te dotyczące innych narzędzi Agile.
Nie ma jednej metryki, która byłaby unikalnie poprawna i odpowiednia dla Twojego projektu.
Metryki powinny być regularnie rewizjonowane, przestarzałe powinny być usuwane, a nowe dodawane w razie potrzeby. Powinny być zrozumiałe i dostępne dla całego zespołu, nie stając się celem samym w sobie. Metryki dla samej metryki to złe rozwiązanie.
Obalanie mitów: Agile
Popularność elastycznej metodologii rozwoju spłatała jej figla, a mity dotyczące pewnych aspektów Agile można zobaczyć nawet na portalach specjalistycznych. Rozwiążmy je!
Mit nr 1: Agile nadaje się do wszystkich projektów.
To najbardziej stanowcze nieporozumienie. Sama jedna metoda Agile nie doda wartości do produktu, ani nie zmotywuje zespołu.
Mit nr 2: Agile nie sprzyja dokumentacji.
Metodologia zwinnego rozwoju nie sprzyja dokumentacji, ale neguje dokumentację jako cel sam w sobie. Mówiąc o wyborze dokumentacji jako środka komunikacji, Agile naprawdę sprzyja osobistej komunikacji.
Mit nr 3: Agile i planowanie są niezgodne.
Ten mit jest obalany przez codzienne wydarzenia planistyczne z 10-minutowymi staniem, a także przez planowanie iteracji odbywające się co dwa tygodnie, spotkania sprintowe itp.
Mit nr 4: Agile wymaga dużo przerabiania.
Metodologia zwinnego rozwoju oprogramowania przewiduje przeróbki w dwóch formach: przeróbki wymagań (użytkownicy ustalają, czego tak naprawdę potrzebują) i przeróbki oprogramowania (zespoły deweloperów znajdują ulepszone sposoby pisania i projektowania aplikacji). Ale to także jest spotykane w innych metodologiach! Co więcej, taka nowość Agile, jak model iteracyjny, służy do zmniejszenia negatywnego wpływu przeróbek.
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 dostawy oprogramowania zwiększają zaufanie interesariuszy do zespołu projektowego i czynią zaangażowanie w projekt głębszym.
- wczesne i przewidywalne dostawy — model rozwoju oparty na iteracjach (w krótkich okresach trwających od 1 do 6 tygodni) zapewnia elastyczność i pobudza wydanie produktu.
- skupienie 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 każdej iteracji z podziałem ostatniego builda na oddzielne 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 projektowym a użytkownikami niemożliwe jest zapewnienie wydania wysokiej jakości produktu o wysokiej wartości. Co więcej, liczne narzędzia i metody Agile predestynują, że zespół powinien być doświadczony dla ich właściwego wprowadzenia.
- nieodpowiedni dla zewnętrznego wsparcia i 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 zaskakujące, ta wada wynika z takich zalet Agile, jak rozwój iteracyjny i ciągła poprawa produktu.
- nie udaje się bez wyraźnej wizji celów biznesowych projektu — ponieważ zespół Agile kieruje się interesariuszami, niemożliwe jest rozwinięcie produktu bez jasno określonego celu i koncepcji.
Zastosowania
Nie wszystkie usługi zarządzania projektami lub programy będą odpowiednie do zarządzania projektami opartymi na Agile, ponieważ każda z nich ma swoje specyficzne cechy.
Jeśli Twoja firma to agencja marketingowa i reklamowa, projektowa, seo lub cyfrowa, możesz korzystać z usługi saas od Worksection, aby cały zespół mógł na niej pracować. Jak dotąd, jesteśmy polecani przez COXO Digital, Royal ® Advertising i Prozorro.
Oto kilka życiowych 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, ukończone, potrzebne przeróbki, krytyczne, cechy, płatność zaległa. Tagi często brzmią jak: układ, testowanie, produkcja, koncepcja, kod.
- stwórz backlog projektu i projekt wytrzymałości.
- stwórz zadania i wstępne listy kontrolne, szkice itp. w backlogu.
- w trakcie spotkań ustal zadania sprintu i przenieś je z backlogu do sprintu.
- użyj dostępu gościa klientów do zadań, aby zawsze mieć skoordynowaną i aktualną opinię na temat projektu.
- otaguj odpowiedzialne osoby w zadaniach, aby każdy kolega znał swoją odpowiedzialność i czuł się zaangażowany w wynik sprintu.
Wyrok
Dzięki zwinnej metodologii rozwoju oprogramowania, małe zespoły projektowe osiągają maksymalną efektywność. Agile realizuje się poprzez takie inne elastyczne metody jak Scrum, XP, Lean itp.
Nie można go wprowadzać pochopnie, przez nieświadomy zespół, w krótkim czasie,
ale po wprowadzeniu Agile poprawi interakcję między IT a biznesem, przyspieszy wydanie produktu na rynek i zwiększy wartość produktu dla końcowego użytkownika.