To określenie już kilkukrotnie pojawiło się na blogu, a także przewija się w codziennych rozmowach na temat projektów IT i - coraz częściej - nie tylko IT. Niektórzy przedstawiają to jako rozwiązanie wszystkich problemów świata zarządzania, inni wskazują, że nie zawsze tak jest, a jeszcze inni... nie wiedzą, o co w tym wszystkim chodzi. I właśnie do tych ostatnich kierowany jest ten artykuł. A o czym mowa? O agile, czyli tzw. zwinnym podejściu do zarządzania projektem.

Nie będzie to jednak rozbudowane wyjaśnienie rodem z czasopism naukowych - zainspirowany filmem od Artura Guły z bloga IT Project Makers, postaram się to zrobić dość szybko, aby osoby, które do tej pory nie były zorientowane w temacie, mogły przynajmniej poznać zarys znaczenia tego terminu. Co prawda, na pewno nie uda mi się w minutę, ale mam nadzieję, że nie zajmę Wam tym tekstem bardzo dużo czasu.

Jak tradycyjnie robi się projekty?

Z pewnością kojarzycie takie rady, które sugerują dobrze przygotować się i opracować plan, zanim zacznie się cokolwiek realizować. Z tego założenia bardzo wcześnie zaczęto wychodzić właśnie przy okazji projektów IT, w których były wyraźnie zaznaczone następujące etapy:

• planowanie
• analiza
• projekt
• implementacja
• testowanie
• wdrożenie

To, co istotne, to fakt, że dany etap mógł się rozpocząć dopiero po zakończeniu (lub podczas kończenia) poprzedniego. Jest to tzw. model kaskakowy, zwany też wodospadowym (ang. waterfall model). Jego główną zaletą jest utrzymywanie porządku i pewność, że znaleziono problemy oraz błędy na danym etapie, zanim zespół przeszedł do następnego (zgodnie z badaniami inżynierii oprogramowania i obserwacjami z praktyki, im wcześniej błąd został znaleziony, tym jest tańszy w naprawieniu). Jednak czy to jest zawsze prawda?

Wyobraźcie sobie sytuację, w której zespół IT dowiaduje się, na czym polega projekt, następnie określa wymagania, planuje całą strukturę kodu, harmonogram oraz zakres obowiązków poszczególnych osób. Trwa to przez kilka tygodni, wszystko układa się dobrze, po czym przez następne miesiące następuje realizacja i w końcu projekt oddawany jest klientowi. Wtedy okazuje się, że nie o to mu chodziło i źle go zrozumieliśmy.

Z czego to wynika? Na pewno błędy mogą wystąpić podczas rozmów z klientem o założeniach projektu - pamiętajcie, że nie zawsze klient i wykonawca tak samo rozumieją pewne kwestie, a nie wszystko da się wprost omówić. Następnie, te błędy w zrozumieniu mogą przełożyć się na implementację, gdzie wycofanie się z pewnych założeń może być niezwykle kosztowne, zwłaszcza, jeśli niezgodności zostaną wykryte na późnym etapie. To samo dotyczy testowania tworzonego oprogramowania - czasami jeden test odkrywa błąd w wielu miejscach systemu, co przy złym designie (a oto nie jest trudno, gdy próbuje się zaplanować wszystko naraz, w dodatku szybko) może oznaczać zduplikowaną poprawkę. I wreszcie - taki model zupełnie nie uwzględnia zmian w potrzebach klienta (które na pewno wystąpią), a także problemów w obrębie samego zespołu (rotacja w zespole, choroby, wpływ innych projektów).

Jak się robi je zwinnie?

Teraz wyobraźcie sobie nieco inny cykl produkcyjny. Nadal musimy na początku dowiedzieć się od klienta, na czym polega projekt, zidentyfikować cel biznesowy, aktorów itd. Jednak realizacja przedsięwzięcia rozpoczyna się szybciej i to znacznie szybciej. Może nawet nie jest do tego potrzebna pełna dokumentacja ani dokładny plan, w jaki sposób skonstruowane będą wszystkie fragmenty aplikacji. Zamiast tego:

1. Ustalamy sobie pewien okres.
2. Wyznaczamy stosunkowo mały zespół i nie przydzielamy im konkretnych zadań z góry.
3. Klient z wykonawcą wspólnie decydują, jaki zakres prac jest priorytetowy i może być zrealizowany w wyznaczonym okresie.

Jedną z idei agile (gdyż właśnie o tej metodyce, a raczej zbiorze metodyk, mówimy) jest to, że wydzielamy z projektu określony zestaw funkcji i tworzymy z niego etap (w niektórych metodykach zwany też sprintem). Planujemy tylko ten jeden etap, który kończy się dostarczeniem klientowi działającego fragmentu oprogramowania i niesie ze sobą jakąś wartość dla jego biznesu. Dopiero po ukończeniu tej części możemy wziąć się za planowanie następnego. To oznacza, że etapy implementacji, testowania i wdrożenia są mniejsze i występują dla każdego fragmentu oprogramowania, a planowanie kolejnej iteracji odbywa się dopiero po poprzedniej takiej iteracji. Dlaczego to takie istotne? Ponieważ:

• łatwiej jest zarządzać częścią projektu niż całością,
• szybciej reagujemy na zmiany - klient, testując gotowy fragment produktu, może nagle sobie coś uświadomić i dalsze etapy są realizowane zgodnie z jego nowymi oczekiwaniami,
• dokumentacja istnieje, ale jest zwykle mniej obszerna i łatwiejsza w utrzymaniu,
• zespół IT po każdym wydaniu ma okazję wymienić doświadczenia i poprawić pracę w następnych etapach (tzw. retrospektywa),
• programiści sami się organizują i biorą zadania z puli zgodnie ze swoimi możliwościami czasowymi,
• klient ma możliwość "przeklikania" się przez system, co nie tylko ułatwia mu ocenę przedsięwzięcia, ale też podnosi morale jego, a przy tym całego zespołu zaangażowanego w projekt,
• taki proces ułatwia rozliczenia.

A to tylko część zalet. Kluczowe są trzy rzeczy. Po pierwsze, w metodykach zwinnych przyspieszamy oddawanie projektu poprzez dostarczanie kolejnych części. Po drugie, nie planujemy wszystkiego od początku, tylko na bieżąco, dostosowując pracę i jej zakres do warunków i zmian. I wreszcie po trzecie, udział klienta jest kluczowy i nierzadko staje się kimś w rodzaju pełnoprawnego członka zespołu. Komunikacja w agile to niezbędna sprawa, niepozwalająca projektowi odpłynąć w nieznane rejony.

Metodyki zwinne faktycznie są zwinne. To oznacza, że każdy zespół może dostosować je pod swoje możliwości i warunki panujące w danym projekcie. I tak zdarza się, że etapy nie są jednak planowane tylko po jednym, ale już po kilka naprzód, jeśli wymaga tego sytuacja i klient jednak chce mieć pełny harmonogram. Zawsze jednak trzeba wziąć pod uwagę, że rozpiska nie jest stała i może ulec roszadom w zależności od aktualnych potrzeb biznesowych.

Czy agile jest odpowiedzią na wszystko?

Byłoby świetnie, ponieważ agile jest rzeczywistą odpowiedzią na niektóre trudności, które trapiły (i nadal trochę trapią) branże IT. Jednak odpowiedź na pytanie zadane w tym rozdziale to, niestety, nie - metodykę należy dobierać mądrze i tak, jak często waterfall nie jest odpowiedzią, tak agile też nie jest remedium na wszystko. Przede wszystkim, nie każdy projekt jest wystarczająco duży, aby był sens dzielić go na etapy. Czasami wręcz składa się z jednej ogromnej funkcji, którą trudno jest rozczłonkować. Oczywiście, można tutaj dyskutować, czy to nie wynik złego projektu kodu lub wymagań, jednak czasami projekty IT są typowo do wykonania przez jedną osobę w całości. W takiej sytuacji próbujemy zwykle tę ogromną funkcję upraszczać, aby móc stopniowo dodawać kolejne "klocki", wzbogacające możliwości aż do docelowego kształtu - to można już podzielić na etapy, a nawet w którymś momencie uznać, że praca spełnia cel biznesowy zleceniodawcy, mimo że nie dotarliśmy do końca pierwotnych założeń.

Ponadto, agile zakłada ciągły kontakt z klientem i jego czynne uczestnictwo w projekcie. Niestety, nie zawsze jest to możliwe - zleceniodawca czasem zwyczajnie nie ma czasu, aby angażować się w projekt regularnie. Oczywiście, często udaje się wygospodarować spotkanie raz na dwa tygodnie lub miesiąc, jednak nie ukrywajmy, że klienci też są zajętymi ludźmi. Tym niemniej, brak informacji zwrotnej od nich po każdym etapie (a to nieraz się zdarzało) tak naprawdę prowadzi do metodyk bardziej stałych i związanych z nimi problemów.

Metodyki zwinne wymagają też samoorganizującego się zespołu, zdolnego do patrzenia na swoją pracę z perspektywy i wyciągającego prawidłowe wnioski. Jednak nie tylko sami programiści tacy musza być - bardzo duża odpowiedzialność leży na kadrze zarządzającej, która musi dbać o to, aby proces przebiegał prawidłowo. Mimo że podejście wydaje się łatwe w zrozumieniu, to nie zawsze jest łatwe w zastosowaniu i tutaj jest duża rola kierowników, a właściwie bardziej opiekunów.

Agile jest niezastąpiony w projektach, które z natury są innowacyjne, składają się z wielu modułów i funkcji, bądź są startupami. Taki system z założenia nie może być zaplanowany od początku do końca "pod klucz" i wszyscy w niego zaangażowani muszą reagować na to, jak zachowują się użytkownicy, rynek, jak wypadną pierwsze testy itd. Tak samo zastosowanie metodyk zwinnych jest często doskonałym wyborem w oprogramowaniu wewnętrznym dla firm usługowych lub produkcyjnych, gdzie pracownicy muszą powoli przyzwyczaić się do systemu, który będą używać i do którego na początku będą mieli naturalne wątpliwości (co jest dużym tematem na osobny wpis).

Na końcu jestem winny Wam jeszcze jedno wyjaśnienie - dlaczego piszę, że agile to metodyki zwinne, a nie metodyka? Albowiem agile to koncepcja zawarta w słynnym Manifeście Agile, ale sama w sobie nie jest konkretną metodyką pracy - to raczej zbiór zasad, którymi należy się kierować. Przykładem metodyki z kolei jest Scrum (którego pewne elementy tutaj przemyciłem).

Podsumowanie

Mam nadzieję, że udało mi się pokrótce wyjaśnić, czym jest agile i osoby, które do tej pory nie umiały powiązać tego terminu z niczym konkretnym, będą teraz bardziej rozumiały to zagadnienie. Zdaję sobie też sprawę, że być może niektórzy zinterpretują ten tekst tak, że krytykuję metodyki zwinne - nic bardziej mylnego. Uważam, że są dobrą odpowiedzią na problemy, które pojawiały się w branży IT (i nie tylko) na przestrzeni lat i obecnie ich zastosowanie jest wręcz naturalne. Natomiast nie są odpowiedzą na wszystko i co więcej - ich "czyste" zastosowanie wiąże się ze spełnieniem kilku warunków, które nie zawsze są osiągalne, przez co czasami wychodzi coś pomiędzy modelem kaskadowym a zwinnym. Krótko mówiąc - jest to świetna technika, ale nie może być stosowana bezmyślnie.