Karierę robi ostatnio w świecie informatyki słowo agile, którego dosłowne tłumaczenie brzmi ''zwinny'', zaś w kontekście inżynierii oprogramowania oraz projektów częściej używa się określenia ''lekki'' albo ''adaptacyjny''. Kilka lat temu mówiło się jedynie o XP jako o alternatywie dla typowej inżynierii oprogramowania, obfitującej w standardy, dokumentacje, zapisy, kontrakty, kontrole i przeglądy. Potem przyszło do modelowania ''na lekko'', czyli analizy i projektowania ukierunkowanego na produkt i wartość dla klienta, bez dbałości o formalizm notacji czy szczegółowe definicje procesów lub interfejsów.

Wtedy też powstał słynny Agile Manifesto (http://www.agilemanifesto.org ). Warto przytoczyć jego treść w całości, bo mam nieodparte wrażenie, że wielu entuzjastów terminu agile nie przeczytało go dokładnie i do końca. Jego twórcy przedkładają "jednostki i interakcje ponad procesy i narzędzia; działające oprogramowanie ponad szczegółową dokumentację; współpracę z klientem ponad negocjację kontraktów; odpowiedź na zmianę ponad wypełnianiem planu". Potem zaś pojawia się najważniejsze zdanie autorów Agile Manifesto: "Nie negujemy wartości tego, co po prawej, natomiast bardziej cenimy to, co po lewej".

Powtórzmy jeszcze raz dokładnie; autorzy Agile Manifesto znają i cenią tzw. tradycyjne podejście do systemów informatycznych i zarządzania przedsięwzięciami. Na podstawie swoich licznych doświadczeń poznali nie tylko jego zalety, ale i wady - w szczególności brak wszystkich wartości po lewej, koncentrujących się wokół czynników "miękkich", takich jak współpraca, elastyczność, komunikacja itd. Tak właśnie rozumiem Agile Manifesto - jako niezgodę na skrajny technokratyzm, jako jedyną metodę w informatyce i zarządzaniu, jednakże przy pełnej świadomości i swobodzie posługiwania się narzędziami technokraty.

Jednak, niestety, wygląda na to, że idea "lekkości" jest ostatnio banalizowana do "lekkich obyczajów". W skrócie - nie warto bawić się w jakiś porządek, ważne, żeby posuwać się do przodu, pokazując za każdym razem system, który jest trochę lepszy od poprzedniego i pytać, czy to na pewno tak miało być. Że zacytuję dokument nt. tzw. agile project management (APM), czyli "lekkiego" podejścia do prowadzenia przedsięwzięć: "Integralnym elementem metodyki APM jest ciągłe dostarczanie klientowi wartości - co w przypadku projektów informatycznych oznacza działające elementy oprogramowania. (...) Powinniśmy przedłożyć kooperację z klientem nad sztywne trzymanie się kontraktu." Tylko jak, na Boga, określić, co to znaczy "działające", "wartość dla klienta" i "kooperacja"? Bo moja praktyka dowodzi, że jak przychodzi do szczegółów, to każda ze stron rozumie te terminy trochę inaczej i na koniec nie wiadomo, kto, ile i komu ma zapłacić. Ciekawe, że za szkolenie z APM trzeba zapłacić niemało i to z góry.

Chcę bardzo wyraźnie powiedzieć: "zwinność" jest dobra i potrzebna wszędzie tam, gdzie mimo poprawnego zastosowania narzędzi technokratycznych nie udaje się osiągnąć oczekiwanego efektu. W szczególności wiele wartości wnosi w wielkich, biurokratycznych organizacjach usztywnionych przez hierarchie i procedury. Natomiast zbanalizowana oznacza po prostu "lekkie obyczaje", czyli chaos w projekcie, bałagan w systemach, niemożność stwierdzenia celów, postępu i jakości efektu końcowego. W realiach polskich projektów takie "lekkie obyczaje" to niemal pewna porażka. Dowodzą tego liczne przedsięwzięcia informatyczne z sektora publicznego, gdzie mamy głównie "dobre relacje" i "inkrementalny rozwój", tylko jakoś efektów nie widać, a koszty rosną astronomicznie.