[Trochę teorii – cz.2] Charakterystyka adaptacyjnych metod wytwarzania oprogramowania

Dziś będziemy kontynuować teoretyczne dywagacje nt metod wytwarzania oprogramowania, tym razem słów kilka o adaptacyjnych metodach wytwarzania oprogramowania –  znów trochę książkowej teorii i “historii powstania świata” 😉 

Z uwagi na trudności wynikające ze stosowania metody kaskadowej, ciągle poszukiwano innego sposobu tworzenia systemów. W latach 80 i 90 XX. wieku starano się zastosować alternatywne metody, które eliminować miały błędy wynikające ze stosowania „metody linii produkcyjnej” do tworzenia projektów(13). Praktycy w wyniku poszukiwań starali się stworzyć inne podejścia do budowy systemów.

W dniach 11-13 lutego 2001 r., w ośrodku wypoczynkowym Snowbird w USA (stan Utah) spotkało się siedemnastu zwolenników nowego podejścia do tworzenia systemów, mimo to promujących trochę inne metody i podejścia do ich budowania. Celem spotkania było nazwanie tego, co naprawę charakteryzuje powstające metody(14).

W wyniku spotkania zostało opracowane Manifesto for Agile Software Development (w skrócie Agile Manifesto), stanowiący opis najważniejszych wartości stojących za sposobem budowania oprogramowania. Wraz z Manifestem Agile zostało spisanych 12 zasad adaptacyjnego programowania. Oryginalnymi sygnatariuszami byli Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fow- ler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Ma- rick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland oraz Dave Tho- mas, z których część tworzyła też własne metody, takie jak programowanie ekstremal- ne, SCRUM, Dynamic Systems Development Method, Adaptive Software Deve- lopment, Crystal Clear, Feature Driven Development, Pragmatic Programming. Od nazwy manifestu metodyki te zaczęto określać mianem metodyk adaptacyjnych(15).

Manifest Agile, w swojej prostocie, zwraca uwagę na 4 podstawowe punkty:

• Ludzie i interakcje ponad procedury i narzędzia – oznacza zwiększenie nacisku na bezpośredni kontakt współpracowników i bieżącą wymianę informacji.
• Działające oprogramowanie ponad złożoną dokumentację – odejście od złożonej, trudnej do zmiany dokumentacji na rzecz pracy nad wysokiej jakości, przetesto- wanym oprogramowaniem.
• Współpraca z klientami nad negocjacje kontaktu – silny nacisk na współpracę sfery IT ze sferą biznesu, umożliwiające współtworzenie przez biznes wytwarza- nego oprogramowania.
• Reagowanie na zmiany nad realizowanie planu – wytwarzanie produktu zgodne- go ze zmieniającymi się wymaganiami klientów, bez kurczowego trzymania się pierwotnych ustaleń.Agile, wg definicji podanej przez Davida Rico(16), oznacza:
  • zdolność do tworzenia zmian i reagowania na nie, aby odnieść korzyści w burz-liwym globalnym środowisku biznesowym;
  • zdolność do szybkiej zmiany priorytetów wykorzystania zasobów, gdy zmienia-ją się wymagania, technologie lub wiedza;
  • szybka reakcja na nagłe zmiany rynkowe oraz pojawiające się zagrożenia dziękiintensywnej współpracy z klientem;
  • wykorzystanie ewolucyjnych, przyrostowych i iteracyjnych metod dostarczaniaproduktu, aby dojść do rozwiązania optymalnego z punktu widzenia klienta;

• maksymalizacja wartości biznesowej za pomocą procesów i dokumentacji realizowanych w odpowiedniej wielkości, tyle ile potrzeba oraz dokładnie na czas.

Wiąże się to przede wszystkim z uznaniem zmienności wymagań („oswojenie zmiany”) i zaakcentowaniem zalet pracy w krótkich iteracjach, które pozwalają na bieżące monitorowanie kierunku projektu oraz umożliwiają szybsze reakcje na pojawiające się zaburzenia. Zmienił się także nacisk prowadzenia projektu z obszernej, szczegółowej dokumentacji na bieżącą, efektywną komunikację z klientem. Wraz z popularyzacją „nowych” metod agile, obserwowane były niekorzystne zachowania związane minimalizacją lub całkowitym odrzuceniem dokumentacji, rozpoznawania procesów, metodologii itp. Dodatkowo wiele firm, chcąc podążać za trendami, na siłę wdrażało wszystkie zasady Agile bez zastanowienia, czy w ich przypadku bezkrytyczne przyjęcie agile jest zasadne i czy na pewno wpłynie pozytywnie na projekty. Chaos powodowany takim zastosowaniem metod zwinnych, był przyczyną przypisywania im cechy niezdyscyplinowanego procesu rozwoju(17). Z drugiej strony wiele przedsiębiorstw, ogromnie przywiązanych do metod tradycyjnych, kurczowo trzymało się harmonogramów i szacowa- nia kosztów, uniemożliwiając wprowadzenie jakiejkolwiek zwinności do procesu.

Aktualnie, po pierwszej fazie zachłyśnięcia się rynku „nowymi zasadami”, metody agile już dojrzały, rozwinęły się i są nie tylko procesem tworzenia, ale mają za sobą silną bazę wiedzy i doświadczenia(18). Należy podkreślić, iż zarówno metody tradycyjne jak i metody zwinne mogą znaleźć wspólne płaszczyzny i wspaniale się uzupełniać, gdyż czerpanie z obu obszarów i korzystanie z wiedzy wielu metodologii daje szerokie możliwości i umożliwia podejmowane właściwych decyzji w zakresie prowadzenia danego projektu. Cechy modelu tradycyjnego często nie są słabościami, a ich zastosowanie może dawać bardzo solidne podstawy do realizacji projektu(19). Zastosowanie metod agile będzie zasadne przy prowadzeniu projektu o nie do końca zidentyfikowanych wymaganiach, ale w tradycyjnych środowiskach, gdzie wymagania projektowe, plany itd. powinny być dobrze udokumentowane by zadowolić wymagania regulacyjne mogą znacznie lepiej sprawdzić się metody tradycyjne (20).