Programowanie zwinne

Odkąd w  2001 roku, został wydany Manifest Agile, zwinne programowanie z każdym kolejnym rokiem zyskuje coraz większą popularność. Metoda ta polega na organizacji programistów w nieduże, samodzielne zespoły, w których członkowie sami szukają rozwiązań problemów, które pojawiają się w trakcie pracy. Celem tej metody tworzenia oprogramowania jest stworzenie środowiska, sprzyjającego szybkiej adaptacji wytwarzanego produktu do stale zmieniających się warunków rynkowych oraz oczekiwań klientów. Wprowadzenie tego rozwiązania wymaga często gruntownych zmian w kulturze firmy.

Programowanie zwinne (ang. agile software development) – zespół metod wytwarzania oprogramowania opartego na iteracyjno-przyrostowym programowaniu, powstałe jako alternatywa do tradycyjnych metod typu waterfall. Kluczowym założeniem metodyk zwinnych jest obserwacja, że wymagania odbiorcy (klienta) często zmieniają się w trakcie trwania projektu. Oprogramowanie wytwarzane jest przy współpracy samoorganizujących się zespołów, które realizują proces wytwarzania oprogramowania.

Metodyki te opierają się na zdyscyplinowanym zarządzaniu procesem tworzenia oprogramowania. Zakłada się częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji. Dotyczy to zarówno specyfikacji wymagań jak i tworzonego oprogramowania. Często znajdują one zastosowanie w niewielkich zespołach programistycznych. Nie występuje tu problem komunikacji. Dzięki temu zbędne jest tworzenie rozbudowanej dokumentacji kodu. 

Na czym to polega?

Kolejne etapy tworzenia oprogramowania zamknięte są w iteracjach. W nich za każdym razem przeprowadza się zebranie wymagań, planowanie rozwiązań oraz testowanie wytworzonego kodu itd. Nastawione są one na szybkie tworzenie oprogramowania wysokiej jakości.

Zespoły są multidyscyplinarne oraz samoorganizujące się, bez jakiejkolwiek wewnętrznej hierarchii organizacyjnej. Członkowie zespołu biorą wspólną odpowiedzialność za realizację zadań wybranych do realizacji w każdej iteracji. Sami decydują jak osiągnąć postawione cele.

Metodyki zwinne opierają się na bezpośredniej komunikacji między członkami zespołu, ograniczając potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu zlokalizowani są w różnych miejscach, to planuje się codzienne kontakty. Najczęściej za pośrednictwem dostępnych kanałów komunikacji elektronicznej (wideokonferencja, komunikator, e-mail itp.).

Często spotykanym błędem występującym u zespołów i osób stosujących metodyki zwinne jest nadinterpretacja ich założeń. Bywa, że pomijane są ważne etapy projektu takich jak:

• zbieranie wymagań,
• analiza,
• planowanie.

Metodyki agile sprawdzają się dobrze gdy wykorzystują je zespoły radzące sobie dobrze z ustrukturyzowaniem pracy nad projektem. A także z podziałem oczekiwań na poszczególne zadaniami w oparciu o „etapy” programowania zwinnego. Wynika to z tego, iż jest ona mniej sformalizowana. Dzięki temu większy obowiązek dbania o systematykę i organizację pracy spoczywa na osobach realizujących poszczególne zadania. 

W przypadku zespołów o podejściu chaotycznym, nie potrafią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. Tym samym pozwalają zapewnić większą kontrolę nad spójną realizacją poszczególnych elementów projektu.

Etapy programowania zwinnego:

Przy realizacji zadań w projektach w oparciu o metodykę programowania zwinnego wyróżnia się następujące po sobie etapy:

• planowanie (ang. plan),
• projektowanie (ang. design),
• programowanie (ang. develop),
• testowanie (ang. test),
• implementacja (ang. release),
• informacja zwrotna (ang. feedback).

Powyższe etapy tworzą cykl powtarzany do czasu zakończenia danego projektu. 

Istotne jest zaznaczenie, iż kolejne cykle mają służyć skorygowaniu przygotowanego zadania na bazie informacji od klienta (użytkownika). Służą też 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 poprawiania błędów danego zadania w nieskończoność. Taka sytuacja wynika często 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. Analiza wymagań oraz zaplanowanie kroków koniecznych do jego realizacji w oparciu o pozyskane informacje. To niezwykle ważny etap, który ma kluczowe znaczenie dla czasu i jakości realizowanego zadania. Dlatego nigdy nie wolno go pomijać (podobnie jak wszystkich pozostałych etapów). Faza ta wymaga bezpośredniego kontaktu z klientem, a co za tym idzie umiejętności dobrej komunikacji i zrozumienia drugiej strony. 

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. Traktują je one jako wykonywanie dokumentacji powykonawczej. Przy takiej interpretacji uznają ją 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. Od strony klienta sprawdzane jest (User Acceptance Test), czy dany element jest tym czego klient oczekiwał.

Implementacja

Przekazanie danego elementu projektu na „produkcję” do finalnego użytkowania przez klienta. Oczywiście dopiero po pozytywnych wynikach testów zarówno technicznych jak i klienckich (akceptacji przez klienta)

Informacja zwrotna

Przekazanie informacji zwrotnej przez klienta do osoby lub zespołu realizującego dane zadanie w projekcie odnośnie 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ń. Zmiany wynikającej np. ze zmiany procesów lub potrzeb klienta. Nie chodzi tu o zmiany wynikające z pominięcia lub niedokładnego przeprowadzenia etapu Planowania. Tzn.:

• nie uzyskanie 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.

Fazy projektu

Programowanie zwinne minimalizuje czas poświęcony planowaniu, tak żeby pierwsza działająca wersja produktu (ang. Minimum Viable Product, MVP) gotowa była możliwie jak najwcześniej. Nie musi zawierać ona wszystkich docelowych funkcjonalności (a nawet nie powinna), nie musi również nadawać się do wypuszczenia na rynek. Ważne jest, żeby taki prototyp nadawał się do dalszego rozwijania.

Przewodnią ideą metody jest stawianie na adaptację w razie zaistnienia problemów niż próbowanie ich przewidywania zawczasu.

Tak kończy się pierwsza z wielu faz tworzenia produktu. Zwolennicy programowania agile zwracają szczególną uwagę na potrzebę dzielenia pracy na wiele mniejszych etapów. Po każdym następuje proces oceny powstałego oprogramowania pod względem spełniania oczekiwań klientów. 

Fazy te zwykle nie trwają dłużej niż parę tygodni. Zwykle dopiero po kilku etapach iteracji produkt gotowy jest do wypuszczenia na rynek.

Jak to działa?

Na początku dnia pracy każdy członek zespołu oznajmia reszcie co udało mu się osiągnąć poprzedniego. Informuje również czym zamierza zająć się w dniu bieżącym. Dzięki temu wszyscy lepiej rozumieją, w którym miejscu aktualnie znajdują się prace nad powstającą aplikacją. Wyznaczane są cele do realizacji na dany dzień. Członkowie zespołu posiadają dużą swobodę w wyborze sposobu, w jaki zamierzają sobie z nimi poradzić. Istotą jest tutaj skupienie się na ludziach i komunikacji, a nie na procesach i narzędziach. Z tego wynika też fakt, że klient obecny jest we wszystkich etapach powstawania produktu.

Zgodnie z założeniami metodologii agile aby uniknąć błędów, testowanie przeprowadza się na bieżąco. W metodologii tradycyjnej (Waterfall) na koniec procesu tworzenia. Aby zaoszczędzić czas, często stosuje się testy  automatyczne.

Programowanie agile bywa krytykowane, jako nieprzystające do realiów większych organizacji. Zbiera również krytykę za promowanie jednego rozwiązania do wszystkich problemów związanych z zarządzaniem. 

Manifest Agile można interpretować na wiele sposobów, przez co wiele firm stosujących tę metodę funkcjonuje często w zupełnie inny sposób.

Mimo tych problemów programowanie zwinne szybko zyskało popularność poza gronem twórców idei i ich wczesnych zwolenników. Tylko czas pokaże, czy metoda ta przejdzie próbę czasu. A może w przyszłości zastąpi ją przez nowa, modna wśród managerów metoda?

Założenia Manifestu Agile (ang. Agile Manifesto):

• 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,
• samoorganizacja zespołów,
• regularna adaptacja do zmieniających się wymagań.