Agile to ostatnimi czasy bardzo popularny termin. Jest odmieniamy przez wszystkie przypadki. Obecnie zdecydowana większość zespołów developerskich korzysta z Agile w swojej codziennej pracy. O „Agile” i „Zwinnym” podejściu do prowadzenia projektów słyszeli już chyba wszyscy. Okay, ale czym tak naprawdę jest ten tajemniczy Agile?
Agile (znaczy zwinny). Jest to zbiór wartości i zasad, czyli pewien sposób myślenia, działania i podejścia, który stawia nacisk na współprace, interakcje pomiędzy ludźmi i dostarczanie efektów pracy w jak najkrótszym czasie.

Dzięki opieraniu się na zwinnym podejściu możemy osiągać lepsze efekty mniejszym nakładem pracy. Na pewno nie są to tylko puste słowa, gdyż sukcesy minionych lat największych firm technologicznych, oparte są właśnie o zwinne podejście do wytwarzania oprogramowania. Myślę, że to wystarczający powód do tego, aby jeśli jeszcze nie wykorzystujemy zwinnych metodyk pracy, chociaż zwrócić na nie teraz swoją uwagę.

Agile oparty jest na dwóch fundamentach: na posługiwaniu się rozumem i nierobieniu rzeczy bez sensu.

Początkowo „Agile” odnosił się głównie do zespołów IT pracujących nad rozwojem oprogramowania, natomiast z czasem metodyka zwinna została wdrożona także w innych obszarach i branżach. W końcu nie tylko w IT posługujemy się rozumem i nie robimy rzeczy bez sensu!

Najlepszym podsumowaniem Agile, jest manifest myślenia zwinnego, który idealnie określa ramy tego podejścia:
W wyniku naszej pracy, zaczęliśmy bardziej cenić:

Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

Manifest Agile, https://agilemanifesto.org/iso/pl/manifesto.html

12 zasad Agile

Agile opiera się na się 12 kluczowych zasadach, które nadają kierunek całemu podejściu:

1. Zadowolenie klienta dzięki ciągłej dostawie produktu
2. Podziel duże fragmenty pracy na mniejsze i osiągalne zadania, aby szybciej zakończyć i łatwiej zintegrować zmiany
3. Przestrzegaj ustalonych ram czasowych na dostawę działającego produktu
4. Wszyscy interesariusze muszą często współpracować, aby zapewnić, że projekt idzie we właściwym kierunku
5. Stwórz wspierające środowisko, aby motywować członków zespołu i zachęcać ich do wykonywania pracy
6. Preferuj komunikację twarzą w twarz niż inne metody
7. Działające oprogramowanie jest podstawową miarą postępu
8. Staraj się utrzymywać stałe tempo rozwoju.
9. Utrzymuj jakość produktu, zwracając uwagę na szczegóły techniczne
10. Zachowaj prostotę
11. Promuj samoorganizację w zespole
12. Regularnie zastanawiaj się nad swoimi wynikami w celu ciągłego doskonalenia

A jak to działało do tej pory? Era sprzed Agile i SCRUM

Pod koniec lat 90. zarówno pracownicy, jak i klienci byli sfrustrowani istniejącymi metodologiami pracy. Najpopularniejszą wówczas i powszechnie stosowaną metodologią był Waterfall (metodologia kaskadowa). Rozbieżność pomiędzy dostarczonymi produktami a wymaganiami klienta była ogromna. Opóźnienia w projekcie były częste, a wiele projektów zostało odwołanych lub pozostawiło klientów niezadowolonych z efektu końcowego. Tradycyjne metody nie nadążały za ciągle zmieniającymi się wymaganiami klientów. Deweloperzy nie byli w stanie w pełni wykorzystać wszechstronności tworzenia oprogramowania. I właśnie w obliczu tychże problemów został wymyślony Agile.

Zalety Agile

• Zacieranie podziałów między zespołami biznesowymi i IT
Praktyki Agile eliminują podziały na zespoły techniczne i biznesowe. Wytwarzanie oprogramowania w krótkich sprintach, gdzie muszą zadziać się wszystkie etapy produkcji oprogramowania wymuszają stała integrację miedzy tymi dwiema grupami ludzi. Taka kooperacja tworzy tzw. „samoorganizujące się zespoły”, w których umiejętności muszą się przenikać i uzupełniać, aby zrealizować cel sprintu

• Lepsza komunikacja
Agile stawia wyżej komunikację od dokumentacji. Oczywiście nie oznacza, to, że w ogóle nie prowadzi się żadnej dokumentacji, a jedynie ograniczamy jej zastosowanie do absolutnego minimum. Zamiast tego kładziemy nacisk na zrozumienie potrzeb i wymagań produktowych w podejściu do ich realizacji (a nie bezrefleksyjne przechodzenie od punktu do punktu). Dodatkowo częstotliwość sprintów, po których dostarczone rozwiązanie jest prezentowane i omawiane, pozwala na szybsze otrzymywania feedbacku przez zespół, co dodatkowo zmniejsza ryzyko wystąpienia krytycznych problemów

• Ciągła nauka
Zwinne metodyki zakładają regularne uczestnictwo w spotkaniach (Retrospective meeting), których celem jest wyciąganie wniosków z zakończonych prac (sprintów). Dzięki temu, mamy czas na przemyślenia z tego, co było dobre, a co jest jeszcze do poprawy. Uczymy się więc na własnych doświadczeniach, aby kolejne sprinty były coraz lepsze

• Elastyczność
Planowanie prac odbywa się w każdym sprincie. Dzięki czemu otrzymujemy duża elastyczność w pracach całego projektu. Oczywiście istnieje całościowa perspektywa projektu, ale to właśnie każdy sprint jest nowym etapem prac i mamy możliwość wyboru tego, co robimy, jak robimy i w jakiej kolejności. Takie podejście pozwala znacznie szybciej reagować na wszelkie zmiany wymagań, przeszkody, problemy

• Zaangażowanie
W zespołach zwinnych nie ma jednego głównego kierownika zespołu. Za całość projektu i postęp prac odpowiada cały zespół, czyli wszyscy jego członkowie. Odpowiedzialność dotyka więc każdego z członków zespołu. Takie podejście wymusza większe zaangażowanie osób, gdyż każdy ma realny wpływ na decyzje, zastosowane rozwiązania i wiążące się z tym konsekwencje.

Role i ceremonie w Agile i SCRUM

Zespoły Agilowe oprócz standardowych ról takich jak: programista, tester, analityk (wszystkie te role w Agilu to po prostu developerzy), pojawiają się również dwie nowe, stricte dedykowane właśnie pod metodyki zwinne:

• Product Owner
Tę rolę najczęściej pełni przedstawiciel klienta (osoba oddelegowana do projektu przez klienta). Product Owner balansuje na granicy świata biznesu i świata technicznego. To właśnie on zbiera informacje od biznesowych przedstawicieli klienta i przekazuje je do realizacji zespołowi developerskiemu. To bardzo ważna rola, gdyż to Product Owner określa priorytety zadań, decyduje w trudnych sytuacjach o rozwiązanych i dalszych działaniach. Trzyma piecze nad backlogiem (dziennikiem zadań) i decyduje o zadaniach, które mają w danym czasie zostać zrealizowane bądź pominięte

• Scrum Master

(SCRUM – to najpopularniejsza metodyka spod znaku AGILE)

Kolejna ważna rola w zespołach Scrumowych. Osoba to dba o to, aby wszyscy członkowie zespołu poprawnie rozumieli założenia SCRUMA i właściwie go stosowali. Ma trzy główne zadania:
– wspieranie Product Ownera w jego pracy, w szczególności z zadania panowania nad backlogiem
– niesienie pomocy, każdemu z członków zespołu przy potencjalnych problemach, które stopują prace
– pilnowanie, aby ceremonie SCRUMA były zachowane i właściwie prowadzone.

Ceremonie SCRUM

Jak już wiemy w metodykach zwinnych prace organizowane są w sprinty (zwykle trwające 2 tygodnie), a sama praca jest zorganizowana w model iteracyjny (przyrostowy). Każdy taki sprint powinien dostarczyć kolejne zaplanowane funkcjonalności. Szumne sformułowanie „Ceremonie SCRUMOWE” to po prostu zwykle spotkania zespołu, które służą do różnych celów. I tak wyróżniamy kilka najważniejszych spotkań:

• Sprint Planning
Bardzo istotne spotkanie, które odbywa się na początku każdego sprintu. To właśnie na tym spotkaniu wypracowujemy plan – określamy zadania, które będziemy realizować w aktualnym sprincie. W tracie tego spotkania dobierane są historyjki użytkownika, które muszą zostać zaprogramowane oraz estymowany jest ich czas, czyli planuje się ich czasochłonność

• Refinement
Spotkanie, na którym zespół omawia historyjki użytkownika, aby poprawnie i jednoznacznie zrozumieć wymagania. Podczas omawiania historyjek – weryfikowane jest czy są one kompletne i dobrze rozumiane. Istotne jest to, że omawiane historyjki dotyczą kolejnego sprintu (nie aktualnego, w którym odbywa się spotkanie).

• Daily Meeting
Codzienne spotkanie, na którym każdy z uczestników w maksymalnie kilku krótkich zdaniach, przedstawia czym zajmował się dnia poprzedniego (co udało się zrobić) oraz czym będzie zajmował się dzisiaj. Zgłaszane są również wszystkie trudności, problemy, które wypływają na naszą pracę. Można więc w skrócie powiedzieć, że jest to typowe spotkanie statusowe.

• Sprint Review
Spotkanie, na którym zostają omówione wszystkie zadanie, które zostały zrealizowane w bieżącym sprincie (omawiane są również zadania, które nie zostały w jakichś powodów zrealizowane, a które były zaplanowane do wykonania)

• Retrospective Meeting
Spotkanie, na którym odbywa się ogólna dyskusja o wszystkim co odbyło się w bieżącym sprincie. Jest to swoiste podsumowanie sprintu. To najlepsze miejsce do tego, aby powiedzieć sobie co było pozytywne, jak i negatywne. Spotkanie to służy do tego, aby uczyć się i wyciągać nioski po to, aby doskonalić przyszłe sprinty.

• Demo Meeting
Na tym spotkaniu prezentowany jest (wizualnie) aktualny stan aplikacji – zwracając główną uwagę na iteracji prac, które zostały wykonane w bieżącym sprincie. Jest to spotkanie dedykowane dla klienta, który w ten sposób statusuje postęp prac i może na żywo przyglądać się rozwojowi zamówionego oprogramowania.

Autor: Tomasz Stelmach