Zwinne programowanie, czyli o metodologii Agile

Zwinne metodologie podchodzą do projektowania i dokumentowania w nieco inny sposób, nie negując przy tym ich wartości. Projektowanie jest rozłożone w czasie trwania projektu, a dokumentacja zawiera tylko elementy uznane za istotne i warte dokumentacji. Oznacza to, że system jest projektowany i implementowany moduł po module, a dokumentowane są tylko jego najważniejsze elementy: bardzo złożone algorytmy, podstawowy model danych, interfejsy publiczne mające wpływ na inne części oprogramowania... W ten sposób zmniejszamy ryzyko związane z jeszcze jedną nie wspominaną cechą klasycznego procesu, a mianowicie podejściem do integracji kodu. W klasycznym modelu zazwyczaj integracja jest dokonywana na końcu cyklu wytwarzania oprogramowania, a do tego czasu każdy moduł jest implementowany i testowany osobno. Podejście takie zwiększa prawdopodobieństwo niespójności modułów oraz znalezienia znacznej ilości błędów związanych z ich integracją pod koniec cyklu. Natomiast w metodzie zwinnej kod jest projektowany, implementowany i integrowany cześć po części, co powoduje, ze każda nowa funkcja jest projektowana z uwzględnieniem już zaimplementowanych modułów.

Współpraca z klientem ponad negocjowanie kontraktów

W klasycznym podejściu kontakt z klientem docelowym następuje na początku i na końcu cyklu wytwarzania oprogramowania. Zakłada się, że na początku zbiera się wymagania klienta, które pozostają niezmienne aż do samego końca. Natomiast na końcu projektu następuje walidacja wytworzonego oprogramowania. Niestety świat, a tym bardziej świat oprogramowania nie jest statyczny i w ciągu trwania projektu klient często zmienia swoje wymagania. Źródłem zmiany wymagań klienta jest potrzeba adaptacji do zmian w jego środowisko, np.: wejście w życie nowej ustawy, wdrożenie nowego systemu lub procesu... W efekcie końcowym okazuje się, że wytworzone oprogramowanie nie spełnia, częściowo lub w całości "nowych" wymagań klienta. Ponadto okazuje się, że część funkcjonalności, która na początku wydawała się ważna przestała być potrzebna. Wszystko to prowadzi do renegocjacji kontraktu lub dodatkowych zobowiązań ze strony wytwórcy oprogramowania celem utrzymania dobrych stosunków z klientem, co z kolei odbija się na budżetach wytwórcy oprogramowania jak i klienta.

Zwinne metodologie bazują na zaangażowaniu i ciągłej współpracy z klientem oraz walidacji jego wymagań w czasie trwania projektu. Ma to na celu wyeliminowanie nieaktualnych, bądź mało istotnych wymagań przy jednoczesnym utrzymaniu budżetu projektu. Ciągła współpraca z klientem realizowana jest poprzez dostarczanie klientowi w regularnych odstępach czasu działającego oprogramowania zawierającego najbardziej wymagane funkcjonalności, a następnie analizowaniu informacji zwrotnej w celu aktualizacji priorytetów na liście pozostałych wymagań. Jednym ze sposobów dostarczenia oprogramowania klientowi jest przeprowadzenie dema najnowszej funkcjonalności lub wdrożenie jej bezpośrednio u klienta. Aby dostarczać działające oprogramowanie zawierające najbardziej wymagane funkcjonalności w regularnych odstępach czasu, zwinne metodologie zalecają implementowanie nowych funkcjonalności w stałych odstępach czasowych trwających od 1 do 4 tygodni (iteracje) oraz integrowanie ich z funkcjonalnościami poprzednio stworzonymi (inkrementacje).

Reakcja na zmianę ponad realizację planu

Wodospadowa metodologia zakłada, ze planowanie występuje tylko na początku projektu a po nim następuje wykonanie wszystkich przewidzianych w tym planie zadań. Na planowanie poświecą się bardzo dużą cześć czasu przeznaczonego na realizacje projektu w celu stworzenia jak najbardziej szczegółowego planu. Takie podejście do planowania zakłada niezmienność wymagań klienta, nieomylność estymat podanych przez zespól lub eksperta, stabilność środowiska, pełną dostępność zespołu...Bardzo często jedno lub kilka z tych założeń nie wytrzymuje konfrontacji z rzeczywistością dezaktualizując plan: klient zmienia wymaganie, najbardziej doświadczony programista odchodzi do innej firmy... Ponadto zmiany w tak szczegółowym planie są bardzo trudne do wprowadzenia ze względu na liczbę zadań oraz złożoność zależności miedzy nimi.

Więcej o narzędziach IBM i programowaniu na serwisie My Developer Works.


TOP 200