Nem régen a következő levelet kaptam a blog.hu-n keresztül:

Ha lehet, egy érdekes szakmai kérdést szeretnék feltenni:
Van-e összefüggés a szoftver minősége és az alkalmazott fejlesztési módszertan között?

A saját megfigyelésem az, hogy az agilis módszerekkel fejlesztett szoftverekkel az ügyfelek elégedettebbek, de ugyanakkor ezen szoftverekkel rengeteg probléma van. Tipikusan olyan hibák, amik teszteletlen szoftver esetén bukkannak fel: regressziós hibák, összeomlások, a rendszer nem elérhető. Az üzemeltetés is egy rémálom

Az érdekelne, hogy ez a módszertan sajátossága, vagy csak az adott fejlesztők/menedzserek bénasága?

A válasz az, hogy igen. Ez a módszerek sajátossága, és fejlesztők, menedzserek bénasága. Azt is mondhatnám, hogy bénák választják az agilis módszertant, és az agilis módszertannal a profik is bénává lesznek, és sokszor a gyakorlatban ez így is van. De nem mindig. És ennek nem kellene így lennie.

A dolog nyitja, hogy mindig azt az eszközt kell használni, amelyik az adott feladatra és az adott ügyfélhez a legjobb. A módszertan csak egy eszköz, és semmi több. Egy olyan eszköz, amelyik arra szolgál, hogy emberek közötti együttműködést segítsen elő.

A vízesés módszernél a projekt elején hosszan tervezés van, és csak a projekt második felében kezdődik a fejlesztés. Türelmetlen, és tapasztalatlan ügyfél ettől nem boldog, nem elégedett. Sok idő elment, talán még fizetnie is kellett a tervekért és még nincs „semmi”.

Agilis fejlesztés esetén nem kell tervezni (?). Egyszerűen nekiállunk kódolni, elkezd működni a szoftver, legfeljebb újraírjuk. Ezzel elégedett az ügyfél, hiszen mindjárt van valami amit lát, hogy működik, mozog.

A vízesés projektek akkor szoktak megbukni, ha az ügyfél türelmetlen, nincs bizalma a fejlesztő csapatban, és leállítja a projektet. Na ilyenkor szív a fejlesztő csapat, ha nem fizettette ki előre a tervezési munkákat, és kezdődhet a pereskedés.

A vízesés projektek azonban úgy is megbukhatnak, ha a fejlesztő csapat ellógja a tervezést, és nincsenek rendes, jó tervek mire el kell kezdeni fejleszteni, és akkor nekiállnak agilisan kódolni. Ez persze nem csak úgy történhet, hogy ellógják a tervezést. Hasonló eset úgy is előfordul, hogy a tervezés során nem sikerül az ügyfélből „kiszedni” a megfelelő információt.

Az agilis projektek viszont lehetnek sikeresek is. Néha előfordul.

A személyes tapasztalatom az, hogy az agilis módszertant használók legnagyobb tévedése az a mondás, hogy agilis módszertan esetén nem kell tervezni. Kell. És minden olyan agilis projektnél amelyik sikeres volt is tervezés. Meglepő módon még akkor is, amikor a résztvevők szerint sem volt. Volt, csak nem vették észre, vagy nem tudtak róla.

Kiválóan lehet agilis módszertant alkalmazni olyan esetekben, amikor a feladat eléggé körülhatárolt, nem túl egyedi és olyan kertrendszerek állnak rendelkezésre, amelyek megadják az alap architektúrát, az alap szolgáltatásokat, és csak ezekhez kell valami kiegészítést készíteni. Ilyenkor valóban nem kell tervezni, mert a tervezés már megvolt akkor, amikor a kertrendszert elkészítették.

Ha például Groowiki-ben implementálok egy munkafolyamatot, akkor elég a munkafolyamatot leírnom XML-ben, megterveznem az egyes dokumentumok, és munkafolyamat lépések meta adatait (képernyőket) és le kell esetleg programozni a munkafolyamat elemi lépéseit. Nem kell architektúrát tervezni: neki lehet kezdeni, és egy nap alatt már mozog a kód, adatot lehet rögzíteni, lekérdezni, munkafolyamatot indítani. Két hetes sprintekkel ki lehet fejleszteni az összes folyamatot ami kell a cégnél, és minden sprintben lehet egy kicsit finomítani az előző sprintekben elkészült munkafolyamatokat. A projektben nem kellett tervezni.

De előtte, amikor a Groowiki workflow implementációja készült, akkor kellett.

A tesztelés megint egy külön téma, de ott meg aztán végképp nagyon rossz a tapasztalatom. Akár waterfall, akár agilis: tesztelés az nem nagyon szokott lenni. De, ahogy a levélíró is érzékeli: waterfall fejlesztésnél azért inkább. Ahhoz a habitushoz közelebb áll a fegyelem, a teszteléshez pedig fegyelem kell.

Összefoglalva: lehet egyik, és lehet másik módszertant alkalmazni, és egyik sem az ördögtől való. Vannak helyzetek, amikor még választani is lehet, hogy melyiket akarjuk. Van amikor a feladat, vagy az ügyfél miatt kell agilis, vagy éppen waterfall módszert választani, és van amikor keverni lehet vagy éppen kell a két módszertant: józan paraszti ésszel. És végül van olyan helyzet, amikor a probléma csak waterfall megközelítéssel és hozzáállással oldható meg, de az ügyfél viszont csak agilis módszertant visel el. Ilyenkor kell menekülni, különben vagy így, vagy úgy de bukik a projekt, és sem a fejlesztő csapat nem lesz boldog sem a felhasználó.