W dawnych, prehistorycznych czasach gdy jeszcze dinozaury chodziły po ziemi, firmy IT zbierały wymagania od klienta a później w zależności od stopnia skomplikowania, po kilku czy po kilkudziesięciu miesiącach wypluwały gotowy produkt. Proces produkcji oprogramowania składał się z jasno określonych, sztywnych faz takich jak planowanie oraz analiza systemu, implementacja, testowanie oraz wdrożenie i pielęgnacja. I to było dobre, ale dla programistów, architektów i wszelkiej maści specjalistów. Nie było to jednak dobre dla klienta. Klient bardzo rzadko wie czego tak naprawdę chce, często ma również problemy z przekazaniem swojej wizji w jasny, klarowny sposób więc zdarzały się sytuacje gdy otrzymana aplikacja rozmijała się z jego oczekiwaniami. Słabo.

Agile czyli panaceum na głupotę klienta

A co gdyby wciągnąć klienta do procesu wytwarzania oprogramowania, pokazywać mu regularnie efekty swojej pracy a on decydowałby czy to co robimy odpowiada jego wymaganiom czy nie, i na podstawie tego dynamicznie kształtować produkt? Brzmi to naprawdę dobrze i pozwala zminimalizować ryzyko nietrafionych wymagań oraz żwawiej reagować na zmiany rynku. Taki styl produkcji oprogramowania nazwano zwinnym. Manifest brzmi następująco;

Bardziej cenić:
Ludzi i interakcje od procesów i narzędzi
Działające oprogramowanie od szczegółowej dokumentacji
Współpracę z klientem od negocjacji umów
Reagowanie na zmiany od realizacji założonego planu.
http://agilemanifesto.org/iso/pl/manifesto.html

Upierdliwy klient

Agile nie rozwiązuje jednak w żaden sposób problemu z komunikacją z klientem. Sprawia jedynie, że programiści są zmuszani do wiecznego protypowania funkcjonalności by odbiorca mógł je "wymacać" a później na tym kruchym fundamencie rozwijać dalej aplikacje. Nie ma mowy o zaoraniu prototypu i przepisaniu go poprawnie od zera bo to dla klienta "niepotrzebny" koszt.

Ciągłe zmiany wymagań oczywiście bardzo negatywnie odbijają się na samym oprogramowaniu. Gdyby jakiś klient podszedł do inżyniera budownictwa i powiedział mu "Przerób mi ten dom jednorodzinny na wieżowiec a i chce by jeszcze w środku było centrum handlowe" to inżynier popukałby się w czoło i delikatnie zasugerowałby mu, że albo niech zmieni wymagania albo niech spierdala. W świecie IT takie żądania to norma i klasyk.

Płaska struktura

Firmy IT pracujące w Agile'u lubią się przechwalać płaską strukturą i elastycznością. Co to oznacza w praktyce dla programisty? Odbieranie telefonów i komunikacja mailowa z klientem, prowadzenie dla niego szkoleń, dyżury po pracy (czyli bycie pod telefonem i reagowanie na pożary), zajmowanie się architekturą systemu oraz na samym końcu nareszcie programowanie. Programista w tym modelu jest wołem na który zakłada się homąto i orze nim pole. Wszyscy są zadowoleni poza nim; klient bo otrzymuje support i może w każdej chwili wymusić zmianę, management bo zamiast 4-5 ekspertów, których trzeba było opłacać mamy powiedzmy dwóch, którzy robią wszystko. Programista jako najniższe ogniwo w firmie jest zasobem, który jak się wypali to wymienia się go na kolejnego zapaleńca, pasjonate bez życia.

Mikrozarządzanie

Agile'a bardzo często sprowadza się również do mikrozarządzania programistami. Codzienne standupy, raporty, wieczne zmieniające się nierealistyczne deadline'y, przerywanie pracy bo wpadło coś ważniejszego to klasyk. A no i openspace'y czyli pokoje wypełnione gadającymi ludźmi tak głośno, że bez słuchawek nie da się normalnie pracować. W takich warunkach nie ma miejsca na kreatywność, na dobrą architekturę, na dobrze otestowany kod. Klientowi i managmentowi nigdy nie będzie zależało na jakości oprogramowania bo zawsze jest coś do zrealizowania na wczoraj.

Wypalony programista

Programiści wpadają w pułapkę dobrych zarobków. Dobra, zarabiam 10 tysięcy ale nienawidzę swojej firmy i programowanie nie sprawia mi już frajdy. Co mam zrobić skoro mam kredyt, rodzinę przyzwyczają do życia na dobrym poziomie? Przecież nie mogę pozwolić sobie na przebranżowienie i zarabanie przez długi czas słabych pieniędzy. I tak właśnie łańcuch u nogi kolejnego kuca się zacisnął.

Ostateczne konsekwencje

Najbardziej cierpią jednak nie programiści a zwykli użytkownicy oprogramowania. Użytkownicy którzy muszą mierzyć się z słabo napisanym, gównianym oprogramowaniem, wiecznym prototypem, który często nie jest przyzwoicie zabezpieczony. Stali się beta testerami i nie zapowiada się na to by ten stan rzeczy się zmienił. Może dopiero gdy ludzie zaczną umierać przez źle napisane oprogramowanie zrobione w Agile'u? Zobaczymy.