Zwinne programowanie, czyli o metodologii Agile

Termin Agile Software Development jest używany w odniesieniu do metodologii wytwarzania oprogramowania umożliwiających jak najszybszą odpowiedź na zmienne potrzeby rynku. Termin ten upowszechnił się po 2001 r.

Wówczas to powstał http:// agilemanifesto.org/" target="_blank" class="link" title="Manifest Agile Software Development">Manifest Agile Software Development wyrażający cztery podstawowe wartości, na których bazują metodologie Agile. Te wartości to:

• ludzie i ich wzajemne oddziaływania ponad procesy i narzędzia,
• działające oprogramowanie ponad obszerną dokumentację,
• współpraca z klientem ponad negocjowanie kontraktów,
• reakcja na zmianę ponad realizację planu.

Czytając manifest możemy odnieść wrażenie, że zdecydowanie marginalizuje on znaczenie procesów i narzędzi, dokumentacji, twardych negocjacji z klientem oraz postępowania zgodnie z planem. Wrażenie to jest dodatkowo wzmocnione sposobem, w jaki zapisano każde z tych zdań. Odczucie to jest jak najbardziej słuszne. Należy jednak pamiętać, że manifest nie neguje zasadności istnienia tych elementów, lecz kładzie nacisk na te aspekty wytwarzania oprogramowania, którym dotychczas nie poświęcano wystarczającej uwagi lub pomijano w klasycznej metodzie wodospadowej (waterfall).

Każdy z czterech punktów zostanie rozwinięty poniżej w celu przedstawienia ogólnej charakterystyki metodologii wytwarzania oprogramowania typu Agile.

Ludzie i ich wzajemne oddziaływania ponad procesy i narzędzia

W klasycznym podejściu zgodność z procesem lub narzędziem jest często celem samym w sobie i jest postrzegana jako kryterium sukcesu projektu. Proces zwykle jest bardzo sztywny i trudny do zmiany. Zauważalną tendencją jest również bezkrytyczne wdrażanie procesu w danym projekcie, nawet jeżeli nie adresuje on jego potrzeb. Dodatkowo, w klasycznym podejściu do wytwarzania oprogramowania, komunikacja jest bardzo sformalizowana i odbywa się poprzez dokumenty lub systemy.

Zwinne metodologie traktują procesy i narzędzia jako wsparcie dla ludzi w podejmowaniu decyzji, zapewnianiu jakości, czy utrzymaniu kontroli nad projektem, które, jeżeli zachodzi taka potrzeba, mogą w części lub całości zostać zmodyfikowane, lub w skrajnych przypadkach pominięte. Zwinne metodologie kładą nacisk na bezpośredni kontakt miedzy ludźmi jako najefektywniejszą formę przekazywania informacji. Ponadto promują wspólne, zespołowe podejmowanie decyzji w przeciwieństwie do eksperckich decyzji w klasycznym podejściu. Np.: szacowanie rozmiaru wymagań, czasu realizacji danego wymagania, wyboru technologii lub zewnętrznego komponentu są dokonywane gremialnie, w oparciu o rzeczową dyskusję. Zaletą takiego podejścia jest podejmowanie lepszych decyzji, nie bazujących na jednej, ale na wielu różnych perspektywach, a także poprawa integracji w zespole i identyfikacji z projektem.

Działające oprogramowanie ponad obszerną dokumentację

Na wstępie pragnę zaznaczyć, że nie chodzi tu o dokumentację końcową produktu dostarczaną klientowi w postaci przewodnika dla użytkownika.

Wodospadowy model wytwarzania oprogramowania zakłada długą fazę analizy wymagań oraz projektowania całości systemu, która owocuje dużą ilością dokumentacji opisującą implementację w bardzo szczegółowy sposób. Niestety, na etapie planowania bardzo często umysł ludzki nie jest w stanie ogarnąć wszystkich aspektów złożoności oprogramowania jak i ograniczeń wybranej technologii. Kiedy przychodzi do fazy wytwarzania oprogramowania okazuje się, że cześć udokumentowanego projektu jest niemożliwa, bądź bardzo trudna do implementacji, co wymusza zmiany zarówno w projekcie, jak i w istniejącej już dokumentacji, co z kolei powoduje dodatkowy narzut czasowy. Dodatkowo, zazwyczaj zmiany architektury projektu w jednym miejscu pociągają za sobą zmiany w innej, zależnej części. To z kolei sprawia, że czas potrzebny na aktualizację dokumentacji znacząco się wydłuża. Ostatecznie okazuje się, że nie jesteśmy w stanie odzwierciedlić w dokumentacji wszystkich zmian architektonicznych, co czyni ją nieaktualną, a czas poświęcony na szczegółowe projektowanie jest czasem zmarnowanym (nie mamy ani aktualnej dokumentacji ani działającego kodu).

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