2015. március 24-én jelent meg egy cikk a quora.com oldalon arról, hogy miért gondolják prominens cégek fejlesztői az Agilis fejlesztési módszertanokat nonszensznek. A cikk konklúziója szerint az agilis modell csak rövid, pár hetes projekteknél használható, amikor nagyon gyorsan kell szállítani. A cikk egységes, és a benne lévő következtetések logikus eredményei a benne felsorolt jelenségeknek; a helytelenségét az adja, hogy rengeteg félreértés van benne az agilitással kapcsolatban. Ezeket a félreértéseket szeretnénk a következő bejegyzésekben sorra venni.

Már a bevezetésben van egy félmondat, amit érdemes jobban kielemezni: “changing requirements and other potential bad behavior from the client”, azaz “változó körülmények, és egyéb, potenciálisan helytelen ügyfélviselkedés”.

A “potenciális” kifejezés gyengíti a mondat erejét; szerencsére nem sugallja azt a szerző, hogy minden követelményváltozás helytelen viselkedés lenne. De vajon mit tekinthetünk mégis annak?

Változás és változás között is van különbség. A döntő szempont sohasem a változás ténye, hanem annak forrása.

Ha a változás oka félreértés, kapkodás, meggondolatlanság, figyelmetlenség, akkor feltétlen “rossz” változásról beszélhetünk. Ennek leggyakoribb tünetei az üzlet részéről a “nem így értettem” / “nem így gondoltam”, a fejlesztés részéről pedig a “nem volt leírva” mondatok.
Amennyiben azonban a változás oka például új, korábban elérhetetlen üzleti információk megszerzése, üzleti vagy technikai fejlődés, vagy új megoldások felfedezése az ügyfelek jobb kiszolgálása érdekében, ez tekinthető “jó” változásnak.

Az agilis módszertanok célja minden esetben az előbbiek kiküszöbölése és az utóbbiak előfeltételeinek megteremtése. Nézzünk ezekre néhány példát!

Az átfogó, a fejlesztés előtt teljesen elvégzett követelményelemzés elhagyásával elengedjük azt az illúziót is, hogy az ügyfél előre képes megmondani, mit szeretne és mire van szüksége. Ahogy egy nadrágot is felpróbálunk vásárlás előtt és ha hosszú, felvarratjuk a “kész termék” szárát, ugyanúgy érdemes egy szoftverterméket is időnként “felpróbálni” és szükség esetén alakítani rajta. Ezt teszi lehetővé a korai, rendszeres és sűrű, értékközpontú szállítás és a visszajelzések gyűjtése.