Programowanie zwinne (ang. agile software development) – grupa metod zarządzania procesem produkcji oprogramowania opartego na programowaniu iteracyjno-przyrostowym. Najważniejszym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często ewoluują podczas trwania procesu produkcyjnego[1]. Oprogramowanie wytwarzane jest przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Manifeście agile.
Generalnie grupa metodyk oparta jest na zdyscyplinowanym zarządzaniu procesem produkcji oprogramowania, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji (zarówno specyfikacji, jak i oprogramowania). Najczęściej znajdują zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Nastawione są na szybkie wytwarzanie oprogramowania wysokiej jakości.
Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii organizacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują, jak osiągnąć postawione cele.
Metodyki zwinne dużą wagę przywiązują do bezpośredniej komunikacji między członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji (wideokonferencja, e-mail itp.).
Częstym błędem występującym u osób i zespołów stosujących metodykę agile jest nadinterpretacja jej założeń i całkowicie błędne pomijanie bardzo ważnych etapów procesu tj. fazy zbierania wymagań, a następnie na ich podstawie faz analizy oraz planowania.
Metodyki zwinne sprawdzają się bardzo dobrze, gdy wykorzystują je osoby oraz zespoły potrafiące dobrze ustrukturyzować swoją pracę nad danym procesem produkcyjnym oraz jego poszczególnymi zadaniami w oparciu o „etapy” programowania zwinnego. Wynika to z faktu, iż jest ona mniej sformalizowana, przez co większy ciężar dbania o organizację i systematykę pracy spoczywa na osobach bezpośrednio realizujących poszczególne zadania. W przypadku osób i zespołów o „chaotycznym/niezorganizowanym” podejściu niepotrafiących ustrukturyzować swojej pracy, zalecane jest korzystanie ze sformalizowanych metod programowania. Metodyki te przejmują na siebie większy ciężar szczegółowego strukturyzowania zadań w projekcie i tym samym pozwalają zapewnić większą kontrolę nad spójną realizacją poszczególnych elementów procesu produkcji oprogramowania.
Wyzwania metodyk zwinnych obejmują trudności z adaptacją w dużych organizacjach, gdzie istnieją silnie zakorzenione struktury hierarchiczne i procesy, które mogą ograniczać elastyczność i szybkość reakcji. Ponadto, brak odpowiedniego wsparcia ze strony kierownictwa, brak zaangażowania zespołów lub brak zrozumienia filozofii metodyk zwinnych mogą prowadzić do niepowodzeń w implementacji. Krytyka metodyk zwinnych dotyczy nadmiernego skupiania się na szybkim dostarczaniu produktu kosztem jakości, braku wystarczającej dokumentacji oraz trudnościach w przewidywaniu czasu i kosztów projektu. Niektórzy krytycy argumentują także, że takie podejście może być mniej odpowiednie dla projektów o wysokim stopniu złożoności lub o dużym zakresie, gdzie konieczne jest szczegółowe zaplanowanie i analiza wymagań przed rozpoczęciem prac[2].
Etapy
Przy realizacji zadań w procesie produkcji oprogramowania w oparciu o metodykę programowania zwinnego wyróżnia się następujące po sobie etapy:
- plan (planowanie)
- design (projektowanie)
- develop (programowanie)
- test (testowanie)
- release (wdrożenie systemu)
- feedback (informacja zwrotna)
Powyższe etapy tworzą cykl powtarzany do czasu zakończenia danego zadania. Bardzo ważne jest zaznaczenie, iż kolejne cykle mają służyć ewentualnemu skorygowaniu przygotowanego zadania na bazie informacji klienta lub elastycznemu wprowadzaniu ewentualnych zmian wymagań ze strony klienta, jeżeli takie się pojawiły w formie informacji zwrotnej (feedback). Kolejne cykle nie mają natomiast na celu – jak błędnie przyjmuje część „chaotycznych / niezorganizowanych” osób lub zespołów – nieskończone poprawianie błędów danego zadania wynikających z pominięcia lub niedokładnego przeprowadzenia etapu Planowania w tym zbierania i analizy wymagań od klienta.
Poszczególne etapy można opisać następująco:
- Planowanie – zbieranie dokładnych wymagań od klienta dotyczących danego zadania, ich analiza oraz zaplanowanie kroków koniecznych do realizacji danego zadania w oparciu o pozyskane informacje. To bardzo ważny etap mający kluczowe znaczenie dla czasu i jakości realizowanego zadania, dlatego nigdy nie powinien być pomijany (jak zresztą wszystkie pozostałe etapy). Etap ten wymaga bezpośredniego kontaktu z klientem, a co za tym idzie umiejętności dobrej komunikacji i zrozumienia drugiej osoby. Etap ten jest czasem pomijany przez osoby i zespoły nie posiadające umiejętności komunikacji, odczuwające niechęć do komunikacji lub obawiające się komunikacji z klientem. Takie osoby lub zespoły nie powinny korzystać z metodyki agile, lecz skorzystać z bardziej sformalizowanych metod i/lub z dedykowanych do tego etapu analityków, którzy będą odpowiedzialni za dokładne zebranie wymagań i ich analizę.
- Projektowanie – projektowanie wykonania danego elementu będącego celem zadania na bazie informacji zebranych na etapie planowania. Można to porównać do wykonania projektu elementu domu przez architekta przed przystąpieniem do prac nad nim przez ekipę budowlaną. Ten etap jest również czasem pomijany przez osoby lub zespoły, które mylnie rozumieją fazę projektowania jako wykonywanie dokumentacji powykonawczej, uznając ją w związku z tym za zbędną.
- Programowanie – właściwy etap prac nad danym zadaniem na bazie przygotowanego projektu zadania.
- Testowanie – testowanie danego elementu będącego podmiotem zadania od strony technicznej przez osobę lub zespół wykonujący dane zadanie oraz od strony klienta (User Acceptance Test), czy dany element jest tym, czego klient oczekiwał.
- Wdrożenie systemu – po pozytywnych wynikach testów zarówno technicznych, jak i klienckich (akceptacji przez klienta), przekazanie danego elementu projektu na „produkcję” do finalnego użytkowania przez klienta.
- Informacja zwrotna – przekazanie informacji zwrotnej przez klienta do osoby lub zespołu realizującego dane zadanie w projekcie odnośnie do ewentualnych mniejszych błędów, których nie wykryto podczas testów, zgłaszanie potencjalnych usprawnień do realizacji w kolejnych cyklach lub zgłoszenie zmiany wymagań klienta. Mając na myśli zmianę wymagań, mówimy o rzeczywistej zmianie wymagań – wynikłej np. ze zmiany procesów lub potrzeb klienta – nie natomiast jak zaznaczono wcześniej o zmianie wynikającej z pominięcia lub niedokładnego przeprowadzenia etapu Planowania (niepozyskanie od klienta dokładnej specyfikacji, brak zrozumienia oczekiwań klienta, praca na niepełnej informacji, brak kontaktu z klientem, budowanie zadania w oparciu o własne domysły i uznanie bez kontaktu z klientem).
Podstawowe zasady
Osobny artykuł: Manifest Agile.
Manifest agile (ang. Agile Manifesto) – założenia:
- osiągnięcie satysfakcji klienta poprzez szybkość wytwarzania oprogramowania,
- działające oprogramowanie jest dostarczane okresowo (raczej tygodniowo niż miesięcznie),
- podstawową miarą postępu jest działające oprogramowanie,
- późne zmiany w specyfikacji nie mają destrukcyjnego wpływu na proces wytwarzania oprogramowania,
- bliska, codzienna współpraca pomiędzy biznesem a deweloperem,
- bezpośredni kontakt jako najlepsza forma komunikacji w zespole i poza nim,
- ciągła uwaga nastawiona na aspekty techniczne oraz dobry projekt (design),
- prostota,
- samozarządzalność zespołów,
- regularna adaptacja do zmieniających się wymagań.