Skip to content

Iteratív fejlesztés

Miért?
Von Clausewitz után szabadon: Nincs olyan terv, nincs olyan implementáció, ami túlélné az érintkezést a megrendelővel. A szoftverfejlesztés tehát jobban teszi, ha változtat a menetirányán.

A szoftverfejlesztés természetesen mindig a tervezéstől az implementáláson át a megrendelő által végrehajtott tesztekig halad. Téves azonban az a feltételezés, hogy egy projektnek elegendő lenne egy tervezési, egy implementációs és egy megrendelői teszt fázis. Ez csak – ha egyáltalán – triviális helyzetekben működik, amikor a tervezési fázisban minden követelmény ismert. Valós projektekben azonban minden fázisnak vannak felismerései az előző fázisból. Főképpen a megrendelő tesztjeiből származnak konzekvenciák a tervezés és a implementáció számára.

Az ilyen felismerésekn azonban csak akkor tudnak befolyással lenni egy projektre, ha az eljárás nem lineáris. Ha egy későbbi fázisból nincsen visszaút egy korábbi fázisba, akkor a visszacsatolás haszontalan.

A fejlesztési folyamatnak ciklikusnak kell lennie, hogy a visszacsatolás a szoftver termékre befolyással lehessen. Főképp az a ciklus szükséges, amelyik a megrendelői tesztfázistól vissza a tervezéshez vezet. Ez azt jelenti, hogy a szoftverfejlesztésnek iteratívnak, tehát több ciklusúnak kell lennie, ami a megrendelő követelményfüzetén átível. Aki megpróbál „egyszerre” (big bang) kiszállítani, az ez ellen a felismerés ellen vét. A szoftverfejlesztési folyamatot sokkal inkább úgy kell megtervezni, hogy a követelményeken keresztül „kis falatokban, katonákban” fogyasztható legyen. Minden ilyen katonának olyan kicsinek kell lennie, hogy a tervezéstől a megrendelői tesztig az átfutás ne legyen hosszabb 2-4 hétnél. Csak akkor kapunk elég gyakran visszajelzést a megrendelőtől, hogy a megvalósítás közben ne kelljen túl hosszú ideig tévelyegnünk.

Ezáltal a szoftverfejlesztés egy tanulási folyamattá válik. A lefolyása alatta a projektteam a megrendelő követelményeiről tanul. A projektteam meghallgatja a megrendelőt, tervez, implementál és a kiad egy szoftververziót, amely a meghallgatottak megértését tükrözi. Utána a team újra meghallgatja a megrendelőt, tovább/ismét tervez az aktuális ismeretek alapján és így tovább, mindig körbe. Iterációról iterációra. Néha valamit továbbfinomítunk egy korábbi iterációból, néha újat teszünk hozzá.

De nem csak egy szoftver fejlesztése egy tanulási folyamat. A tanulásnak a szervezési szinten is végbe kellene mennie. A teamnek nem csak a megrendelőről kellene tanulnia, hanem saját magáról is. Ezért újra és újra szükség van arra, hogy megálljunk, amikor a team a saját eljárására reflektál. Az ilyen retrospektívek felismerései belefolynak a fejlesztésszervezés a következő iterációjába. Itt kapcsolódik a kék fokozat a piros fokozathoz, amihez a mindennapi reflektálás tartozik.

Természetesen minden iterációnak vége kell legyen valamikor. És ahhoz, hogy az ember tudja, hogy készen van-e, előtte meg kellet határozni, hogy mit akarunk elérni az iterációban. A célok elérhetőségét mindig csak megbecsülni lehet, ebben is segít a reflektálás, hogy a becsléseket lépésről lépésre annyira javítsuk, hogy a tervezéshez elegendők legyenek. De mikor is értük el az előre meghatározott célt? ‘What is done?‘ A legfelsőbb cél a működőképes szoftver kiszállítása a megrendelőnek. Ebből következően a cél csak akkor lehet elérve, ha kiszállításra kész szoftvert állítottunk elő. Ez különösen azt jelenti, hogy a szoftver le van tesztelve, és a setup segítségével telepíthető. A Continuous Integration segítségével folyamatosan biztosítjuk ezt. Semmiképpen sem dönthetünk kevéssel egy iteráció vége előtt úgy, hogy az egyik cél el van érve, pedig még nincs lezárva az összes teszt.

Lásd még az eszközök alatt.

Published inPraktikák