AGILE development jest iteracyjną metodologią tworzenia oprogramowania, z której korzystają zespoły developerskie oraz projektowe.
Tak oto można w sposób lapidarny i stosunkowo poglądowy zdefiniować, czym AGILE jest. Można zdefiniować AGILE także nieco inaczej.
Podejście AGILE jest przyrostową metodologią, wykorzystywaną do zarządzania projektami oraz tworzenia oprogramowania, która pomaga zespołom szybciej dostarczać wartość swoim klientom… przy mniejszym bólu głowy.
Trzeba przyznać, że ta definicja jest bodaj najbardziej ujmującą i zabawną, jaką przeczytacie w literaturze poświęconej tej metodologii.
Humorystyczny akcent w powyższej definicji może wydawać się zaskakujący, ale jest jednocześnie bardzo trafny, bowiem rzeczywiście jedną z cech metodologii AGILE jest redukcja stresu, bardziej harmonijne podejście do prac programistycznych oraz projektowych.
Antystresowy efekt AGILE jest uzyskiwany także przez specyficzne dla tej metodologii podejście do celów, rezultatów, działań, wydajności, ewaluacji.
W AGILE, nie chodzi o „efekt wow”, o „big bang launch”, ale o małe, sukcesywnie osiągane sukcesy.
Podejście AGILE jest bardziej skoncentrowane na procesie, rozwoju ewolucyjnym, na przyrostach. Nie chodzi w nim o efektowność, ale o efektywność.
W AGILE wymagania, plany i wyniki są stale oceniane, co pozwala zespołom programistycznym (developerskim), projektowym, badawczym w bardziej naturalny, szybki, elastyczny sposób reagować na zmiany.
Jak 11 września wpłynął na popularyzację i zastosowanie AGILE
Opowieść o AGILE warto zacząć od wydarzenia, które przyczyniło się do popularyzacji podejścia AGILE jako metody zarządzania projektami.
Historię opowiedział mi mój wykładowca AGILE na Uniwersytecie Oxford, który pracował jako SCRUM Master w zbrojeniowej korporacji Lockheed Martin.
Otóż okazało się, że wydarzeniom z 11 września 2001 roku można było zapobiec. Do takiego wniosku doszło FBI, które przeprowadziło śledztwo w sprawie własnych zaniedbań.
Wyszło na jaw, że dane o terrorystach i ich zachowaniach znajdowały się w systemach informatycznych amerykańskich służb specjalnych, które niestety były rozproszone i nie miały swojego Data Hub’a.
Z powodu braku możliwości łączenia danych i wyciągania z nich wniosków doszło do skutecznego ataku na WTC.
Aby zapobiec powtórce, amerykańskie władze podjęły decyzję o stworzeniu super oprogramowania, które będzie łączyło dane pochodzące z różnych systemów oraz od różnych służb państwowych.
Jak postanowili, tak zrobili. Napisali specyfikację projektu IT. Wyestymowali projekt i otrzymali finansowanie od amerykańskiego Kongresu w wysokości 400 mln dolarów.
Ważnym szczegółem tego procesu był fakt, że projekt super oprogramowania był realizowany metodą kaskadową.
Oprogramowanie powstało, 400 mln wydano, ale podczas testów oprogramowania okazało się, że program nie działa.
Zaprogramowany jest zgodnie ze specyfikacją, ale nie wykonuje nawet najbardziej podstawowych scenariuszy użycia.
Analizując porażkę decydenci, którzy zlecali wykonanie oprogramowania, doszli do wniosku, że problemem była metoda prowadzenia projektu.
Metoda kaskadowa, brak możliwości iterowania i wprowadzania do projektu zmian, sztywne trzymanie się specyfikacji, która nie była doskonała, spowodowało w dużym projekcie IT całkowity rozjazd pomiędzy członkami zespołu. Stworzono oprogramowanie, które nie działało.
Jako remedium zaproponowano skorzystanie z metody AGILE, której manifest powstał w połowie lutego 2001 roku.
Oba wydarzenia połączył rok 2001, który zmienił świat nie tylko politycznie, społecznie, ale również „projektowo”.
Manifest AGILE - czym jest AGILE?
Czas: rok 2001, luty. Do zamachu 11 września pozostało kilka miesięcy.
Miejsce: ośrodek narciarski w amerykańskim stanie Utah, w którym spotkało się kilkunastu programistów bez deadlinów.
Cel: zmiana wszystkiego, co w projektach IT nie działa.
Siedemnastu programistów spotkało się, by podzielić się swoimi doświadczeniami. A te nie były tylko pozytywne. Dominowało poczucie nieefektywności, marnotrawstwa, nieadekwatności, niezrozumienia oraz dużej sztywności.
Tworzenie oprogramowania domagało się wypracowania metodologii bardziej adekwatnej do ówczesnych potrzeb.
Odpowiedzią na nią było i nadal jest podejście AGILE. Mimo upływu czasu, metodologia AGILE nadal jest bardzo aktualna i pomocna. Jej ponadczasowy charakter jest jej wielką siłą.
Celem sygnatariuszy, pomysłodawców, twórców manifestu (AGILE Manifesto) było przede wszystkim uczynienie procesu tworzenia oprogramowania bardziej:
- efektywnym
- elastycznym
- sprawnym
- harmonijnym
- oraz głębokim - ufundowanym na wartościach, które wnosiły pewną głębię do procesu tworzenia oprogramowania.
Jednocześnie chciano wyeliminować z tego procesu problemy, które rzutowały na jakość, efektywność oraz atmosferę pracy.
Twórcom manifestu AGILE chodziło o wykluczenie z procesu nieefektywnych praktyk, uwolnienie procesu od działań, które niewiele wnosząc, powodowały utratę efektywności, entuzjazmu, zaangażowania.
Winowajcami były choćby sztywne zasady lub konieczność tworzenia zbytecznej dokumentacji.
Manifest Agile na ich miejsce wprowadził cztery podstawowe wartości, które w lapidarnyt sposób streszczały stosunek do kluczowych obszarów i problemów.
Zgodnie z manifestem AGILE osoby i interakcje między nimi zachodzące powinny być zawsze ważniejsze niż procesy i narzędzia.
Metodyka AGILE przedkłada działające oprogramowanie nad nawet najbardziej dokładną dokumentację.
Współpracę z klientem nad sztywne trzymanie się postanowień umowy.
Elastyczną, szybką reakcję na zmianę przedkłada nad wywiązywanie się z przyjętych z góry, na sztywno planów.
Metodyka AGILE powstała jako metodologia, która miała zespołom developerskim pozwolić na osiągnięcie zwinności, miała poprawić ich zdolność do skutecznego reagowania na zmiany.
Świadomość ogromu zmarnowanego czasu, energii, pracy koniecznej do zarządzania zmianami (oczekiwań, potrzeb, celów, wymagań, uwarunkowań) stała się podstawą potrzeby wypracowania lepszych zasad.
Dlatego, metodyka AGILE, zdaniem Page Laubheimera, jest nastawiona na radykalną przejrzystość oraz szczere przyznanie, że żaden zespół programistyczny nie zna wszystkich problemów, rozwiązań, odpowiedzi na początku projektu.
O co chodzi w metodyce AGILE? Zwinne zarządzanie projektami
Popularność AGILE software development to wypadkowa jego efektywności oraz pozostałych zalet, wśród których należy wymienić także:
- elastyczność, wyrażająca się w o wiele łatwiejszym przekierowaniu celów
- krótsze horyzonty czasowe
- koncentracja na szybkim tworzeniu działającego oprogramowania
- przeciwdziałanie błędom i/lub szybsze wykrywanie i naprawianie błędów
- wyjście poza ograniczenia „żelaznego trójkąta zarządzania projektami” - zakres, harmonogram i jakość.
AGILE jest metodologią iteracyjną, w której przyrost oznacza ciągłe wydania w oparciu o feedback zbierany od klientów, użytkowników, interesariuszy (także z szeroko rozumianego rynku, uwarunkowań branżowych, gospodarczych, czy prawnych).
Podejście zwinne poprawia zdolność adaptacyjną organizacji, jest wytwarzaniem oprogramowania w oparciu o metody o wiele bardziej adekwatne do współczesnych kontekstów oraz warunków.
Kaskadowe podejście, które bardzo często jest porównywane, zestawiane z AGILE, oparte na liniowym, sztywnym rozwoju, wiąże się z wieloma ograniczeniami. Choćby związanymi z szybkością, timingiem reakcji.
Tam, gdzie kaskadowe podejście działa w oparciu o sztywne kryteria postępu, rozwoju, zmiany, AGILE wprowadza filozofię małych kroków, małych sukcesów oraz małych kosztów zmiany reguł, celów, sposobów, narzędzi. AGILE jest oparte na logice pętli sprzężenia zwrotnego.
Podejście kaskadowe sprawdza się dobrze w przypadku pracy, w której występują przewidywalne, powtarzające się procesy.
W przypadku branż, w których zmiana jest normą i zasadą staje się jednak mocno problematyczne jako metoda.
Metodologie stosowane do wdrożenia AGILE
As soon as possible - tak szybko, jak tylko to możliwe - oto naczelna zasada, jaką można dostrzec w AGILE.
Zespoły developerskie, które działają w zgodzie z metodologią AGILE, właśnie w taki sposób są w stanie sprostać nowym wymaganiom klientów.
A te, dzięki częstym spotkaniom twarzą w twarz (face to face), możliwe są do zakomunikowania, priorytetyzowania.
W ramach AGILE wypracowano wiele podejść, rozwiązań, narzędzi, wśród których najbardziej popularnymi są:
- Dynamic Systems Development Method (DSDM), którego celem jest wsparcie tworzenia oprogramowania. DSDM koncentruje się na potrzebach biznesowych, terminowości, współpracy, jakości, przyrostach opartych na solidnych fundamentach, iteracyjnym rozwoju, ciągłej i przejrzystej komunikacji oraz demonstrowaniu kontroli
- Scrum, którego celem jest nadanie projektowi struktury w postaci niezmiennych ról, obowiązków i spotkań oraz dla którego priorytetem jest wytwarzanie oprogramowania w formule Sprintów, które pozwalają zespołowi na regularne dostarczanie oprogramowania
- Feature-Driven Development (FDD), którego celem jest opracowanie ogólnego modelu, budowanie listy funkcji, planowanie według funkcji, projektowanie według funkcji i tworzenie według funkcji
- Kanban, którego celem jest promocja małych, ciągłych zmiany w bieżącym systemie. Kanban oparty jest na wizualizacji przepływu i sposobu pracy, ograniczeniu pracy w toku, zarządzaniu przepływem, konkretyzacji zasad, ustawicznym doskonaleniu
- Adaptive Software Development (ASD), którego celem jest zachęcanie zespołów pracujących do rozwoju zgodnie z trójfazowym procesem: spekulowania, współpracy oraz uczenia się
- Extreme Programming (XP), którego celem jest poprawa jakości i szybkości reakcji na zmieniające się wymagania klientów
- Lean Software Development (LSD), którego celem jest wspieranie tworzenia oprogramowania w oparciu o zasadę eliminacji marnotrawstwa, wzmacniania ustawicznej nauki, opóźnienia decyzji oraz przyspieszania dostarczania, wzmacniania zespołu, budowania integralności.
Scrum vs AGILE - różnice
Jedno z najpopularniejszych podejść w AGILE - Scrum - bardzo często jest traktowany jako synonim tej metodologii, co oczywiście nie jest zgodne z prawdą.
Scrum jest podejściem, pojęciem węższym niż AGILE. Choć metodyka AGILE i Scrum mają części wspólne, to jednak różnice występujące między nimi są zasadnicze.
Scrum oraz AGILE łączy przede wszystkim czas cyklu rozwoju produktu cyfrowego, który jest krótki (zazwyczaj pojedynczy Sprint nie trwa dłużej niż miesiąc).
AGILE i Scrum są skoncentrowane na ludziach, specjalistach, zespole, współpracy, komunikacji.
Zarówno w AGILE, jak i w Scrumie najważniejszą kwestią jest elastyczność oraz możliwość szybkiej reakcji na pozyskaną face to face informację zwrotną.
Agile jest metodologią zapewniającą rozwój produktu poprzez iterację. Jako metodologia jest najbardziej odpowiednia dla małych zespołów, w których przywództwo odgrywa znaczącą rolę.
W Scrumie najistotniejsza jest zdolność zespołu do samoorganizacji.
Czym jest AGILE? AGILE w porównaniu do Scruma jest o wiele bardziej sztywną metodą. Komunikacja w AGILE często odbywa się między zespołami.
Scrum polega na codziennych spotkaniach stand-up, w których każdy członek zespołu odgrywa przypisaną mu rolę.
Wymagania, analiza, projekty AGILE są stale monitorowane. W Scrumie funkcjonalności są prezentowane oraz oceniane na koniec każdego Sprintu.
AGILE sprawdza się bardziej w przypadku projektów prostych, a Scrum jest rekomendowany do prowadzenia projektów innowacyjnych, nietypowych.
Zwinne zarządzanie projektami i User Experience
Szersze omówienie związków łączących AGILE oraz User Experience znajdziemy w artykule pt. „What is Agile Development?”, który został opublikowany na blogu Interaction Design Foundation.
Największą wartością tego artykułu jest porównanie AGILE i UX z perspektywy zespołów developerskich oraz projektowych - ich podejść, oczekiwań, wyobrażeń, metod pracy, ale także stosunku do użytkowników i interesariuszy.
Pogodzenie tych różnic wymaga stworzenia odpowiedniego środowiska pracy, w którym współpraca oparta jest na dobrej komunikacji, otwartości, zrozumieniu, wymianie oraz dialogu.
W pogodzeniu potrzeb i celów AGILE i User Experience ważne jest także, by mieć na uwadze definicje ról, jakie pełnią dani specjaliści oraz zespoły przez nich tworzone.
Przy tej okazji warto mieć w pamięci zasady, jakie organizacje powinny wykorzystywać, jeśli chcą w pełni połączyć potencjał AGILE oraz UX.
Hoa Loranger - badaczka związana z Nielsen Norman Group - w artykule pt. „Doing UX in an Agile World: Case Study Findings” pisze wprost, że wykorzystywanie AGILE nie może oznaczać zmniejszania roli User Experience.
Ponadto postuluje, by specjaliści UX aktywnie włączali się w proces AGILE, co w praktyce oznacza, że powinni planować działania (np. testowanie Agile, założeń) przed Sprintem.
Ponadto, specjaliści UX powinni wykazać się przywództwem i poświęcić czas na dotarcie do współpracowników.
Zwinne przepływy pracy powinny być wystarczająco elastyczne, by mogły uwzględnić potrzeby zespołu UX. A ten ostatni powinien być uznawany za integralną część zespołów produktowych.
Przy czym dla jakości tej współpracy i efektów pracy niezwykle ważne jest, by proces AGILE nie był całkowicie kontrolowany i rygorystyczny.
Page Laubheimer bardzo przytomnie zauważa, że typowe procesy AGILE niestety nie uwzględniają takich zmiennych jak czas, zasoby, zakres, które są niezwykle istotne dla projektantów UX, badaczy UX.
Stąd też obustronnie korzystny mariaż User Experience i AGILE jest możliwy o ile:
- kierownictwo organizacji rozumie i wspiera pracę UX
- przepływy pracy AGILE są wystarczająco elastyczne, aby dostosować potrzeby UX
- specjaliści UX stanowią istotną część zespołów produktowych, w których traktowani są jako równie ważni, niezbędni i pożądani.
Metodyki AGILE. Metodyki zwinne. Podejście AGILE. Podsumowanie
- Porządny AGILE development jest iteracyjną metodologią tworzenia oprogramowania, którą zespoły developerskie oraz projektowe wykorzystują podczas tworzenia produktów cyfrowych.
- System AGILE jest przyrostowym podejściem wykorzystywanym do zarządzania projektami (AGILE roadmap).
- Zasady AGILE są właściwie bardzo proste. Team jest skupiony na realizacji założonego planu, jest nastawiony na ciągłe doskonalenie, działające oprogramowanie jest podstawową miarą postępu i sukcesu. To jest clue metodyk zwinnych.
- AGILE jest używane do tworzenia oprogramowania (np. aplikacji webowych, aplikacji mobilnych). Jest metodologią, która pomaga zespołom szybciej dostarczać wartość swoim klientom… przy mniejszym bólu głowy.
- Podejscie AGILE umożliwia redukcję stresu, bardziej harmonijne podejście do prac developerskich oraz projektowych.
- Zarządzanie projektami AGILE, AGILE metodyki, temat AGILE ufundowane są na wartościach oraz konkretnej filozofii.
- Metodyka zwinna nie jest skoncentrowana na „efekcie wow”, w podejściu zwinnym nie chodzi o „big bang launch”, ale o małe, sukcesywnie osiągane sukcesy, które zapewniają zadowolenie klienta, możliwość skorzystania z wyciągniętych wniosków w poprzednim Sprincie, co jest o wiele bardziej efektywne niż tradycyjne podejście.
- W AGILE nie chodzi o efektowność, ale o efektywność.
- Celem sygnatariuszy, pomysłodawców, twórców manifestu (AGILE Manifesto) było przede wszystkim uczynienie procesu tworzenia oprogramowania bardziej efektywnym oraz elastycznym.
- Celem programistów, którzy podpisali manifest AGILE chodziło także o wykluczenie z procesu nieefektywnych praktyk, uwolnienie procesu od działań, które niewiele wnosząc, powodowały utratę efektywności, entuzjazmu, zaangażowania.
- Zgodnie z manifestem AGILE osoby i interakcje między nimi zachodzące powinny być zawsze ważniejsze niż procesy i narzędzia.
- AGILE przedkłada działające oprogramowanie nad nawet najbardziej dokładną dokumentację.
- AGILE przedkłada współpracę z klientem nad sztywne trzymanie się postanowień umowy.
- AGILE elastyczną, szybką reakcję na zmianę przedkłada nad wywiązywanie się z przyjętych z góry, na sztywno planów.
- AGILE powstała jako metodologia, która miała zespołom developerskim pozwolić na osiągnięcie zwinności, miała poprawić ich zdolność do skutecznego reagowania na zmiany.
- AGILE jest metodologią iteracyjną, w której przyrost oznacza ciągłe wydania w oparciu o feedback zbierany od klientów, użytkowników, interesariuszy.
- Kaskadowe podejście, oparte na liniowym, sztywnym rozwoju, wiąże się z wieloma ograniczeniami.
- Tam, gdzie kaskadowe podejście działa w oparciu o sztywne kryteria postępu, rozwoju, zmiany, AGILE wprowadza filozofię małych kroków, małych sukcesów oraz małych kosztów zmiany reguł, celów, sposobów, narzędzi.
- W ramach AGILE wypracowano wiele podejść, rozwiązań, narzędzi.
- Scrum bardzo często błędnie jest traktowany jako synonim metodologii AGILE.
- AGILE i Scrum są skoncentrowane na ludziach, specjalistach, zespole, współpracy, komunikacji.
- Zarówno w AGILE, jak i w Scrumie najważniejszą kwestią jest elastyczność oraz możliwość szybkiej reakcji na pozyskaną face to face informację zwrotną.
- W Scrumie najistotniejsza jest zdolność zespołu do samoorganizacji.
- AGILE w porównaniu do Scruma jest o wiele bardziej sztywną metodą.
- Metoda AGILE, strategia AGILE, AGILE projekt management, metodologie AGILE zakłada/ją, że komunikacja często odbywa się między zespołami.
- Scrumie polega na codziennych spotkaniach stand-up, w których każdy członek zespołu odgrywa przypisaną mu rolę.
- Wykorzystywanie podejścia AGILE nie może oznaczać zmniejszania roli User Experience.
- Project management AGILE zakłada, że zwinne przepływy pracy powinny być wystarczająco elastyczne, by mogły uwzględnić potrzeby zespołu UX.
- Zespół UX powinien być uznawany za integralną część zespołów produktowych.
- W AGILE Project Management niezwykle ważne jest, by proces nie był całkowicie kontrolowany i rygorystyczny.
- Typowe procesy AGILE nie uwzględniają takich zmiennych jak czas, zasoby, zakres, które są istotne dla projektantów, badaczy UX.
- Obustronnie korzystny mariaż User Experience i AGILE jest możliwy, o ile kierownictwo organizacji rozumie i wspiera pracę UX.
- Przepływy pracy AGILE powinny być wystarczająco elastyczne, by uwzględnić także potrzeby specjalistów i projektantów UX.