Słowo „zwinny” samo w sobie brzmi obiecująco, więc z łatwością zostało porwane przez marketing do roli usłużnego słowa oznaczającego coś dobrego. Nadużywane jest do granic wytrzymałości, przylepiane do czegokolwiek, co chce się promować. Sam tego doświadczyłem niedawno, kiedy prowadzony przez siebie warsztat nazwałem nie warsztatem o testowaniu, tylko o testowaniu agile. Sprzedawał się znakomicie, a ja mam zupełnie czyste sumienie, bo uczestników ani trochę nie interesowała specyfika testowania w projektach agile Scrum, lecz ogólne tematy testowania, niezmienne od 50 lat. Ale przyznawali, że szkolenie zainteresowało ich ze względu na atrakcyjną nazwę.

Żeby było jasne – jestem gorącym zwolennikiem paradygmatu (zrębu – ang. framework) agile, zwłaszcza agile Scrum. Ten sposób realizowania projektów jako pierwszy i jedyny dotąd na świecie zdołał – przynajmniej częściowo – zlikwidować szereg chronicznych od lat słabości projektów IT, takich jak: projektowanie testów w ostatniej chwili, lekceważenie wymagań, brane z sufitu szacunki pracochłonności, jak chaos niekontrolowanych zmian, zwanych czule „wrzutkami”. Przez dziesiątki lat zmianom opierali się skutecznie tak programiści, dający sobie chętnie przywilej na pełną dowolność działań, jak i biznes uważający, że mętne i nieprecyzyjne wizje biznesowe powinny się w cudowny sposób szybko zamieniać w działające oprogramowanie. Agile udało się w jakiś sposób ukrócić te praktyki, narzucić mądrą dyscyplinę tam, gdzie wcześniej – pod płaszczykiem rzekomo zdyscyplinowanych projektów tradycyjnych, sekwencyjnych, planowanych z góry – tę dyscyplinę tylko symulowano i łamano na wszelkie sposoby.

To, czym agile mnie razi, co krytykuję, to udawanie, że jest czymś więcej niż znakomitym sposobem realizacji projektów IT, że jest jakąś nową, lepszą filozofią, która na głowie rzekomo stawia to wszystko, co inżynieria oprogramowania dotąd stworzyła. Szczególnie jaskrawym wyrazem tego szaleństwa jest zupełnie niepotrzebna własna terminologia, dziwaczne nazewnictwo, utrudniające porozumienie i tworzące fałszywe wrażenie istotnej odmienności. Ten stan rzeczy ma dwie wady i jedną zasadniczą zaletę. Wady to, po pierwsze, utrudnienie korzystania przez agile z dorobku inżynierii oprogramowania oraz, po drugie, utrudnienie dostrzeżenia przez klasyczną inżynierię oprogramowania znakomitych zalet agile. Zaleta to możliwość stworzenia i sprzedaży tych samych książek, tych samych szkoleń, tych samych metod po raz drugi, z dodatkiem magicznego słowa „agile”. Testowanie agile to w 85% testowanie takie samo jak każde inne, plus 15% specyfiki procesów agile, ale książka pod tym tytułem liczy sobie nie 50, a 350 stron i omawia wszystkie zagadnienia od początku, udając, że opisuje coś zupełniej nowego. Niezły biznes…

Kult eksploracji

Podobnie rzecz ma się z testowaniem eksploracyjnym. Dobry pomysł, dobra metoda, którą niektórzy zwolennicy przerobili na niemal religię, mimochodem – chcę wierzyć, że nieświadomie – stwarzając zapotrzebowanie na swoje niezbyt tanie usługi doradcze i szkoleniowe, rzekomo dramatycznie lepsze od innych, „tradycyjnych”.

Wprawdzie opisane przeze mnie zjawiska podważają inżyniersko-informatyczny racjonalizm, ale jeśli ulegniemy jakiejś chwilowej fascynacji modnymi bzdurami, pocieszmy się: konkurencja popełni identyczne błędy.

Natomiast jeśli chcemy być od konkurencji dużo lepsi, trzeba pamiętać o zagrożeniu błędem Arystotelesa, nie szukać tanich pocieszeń i kierować się własnym rozumem, a nie modą ani połyskliwym marketingiem idei.