A tömegtermelés analógiájára menedzselt fejlesztési módszertanokra szoktam
használni a „tömegfejlesztés” kifejezést. Ez a módszer gyakorlatilag vízesés modell néven ismertté vált megközelítés. A Standish Group minden évben elkészíti a szoftverfejlesztési projekteket vizsgáló jelentését, a Chaos Report-ot. Az egyik ilyen felmérésnek az eredménye jól rámutat a vízesés modellben megbújó veszteségekre.A jelentésben azt vizsgálták, hogy az egyedi fejlesztésű rendszerekben megvalósított funkciókat milyen arányban használják a felhasználók. Az eredmény önmagáért beszél: a fejlesztett funkcióknak mindössze 20%-át használják állandóan, vagy gyakran, míg 64%-át soha, vagy nagyon ritkán veszik igénybe. Ha gyártási analógiával akarunk élni, akkor ez a túltermelés tökéletes megnyilvánulása. Mi az oka ennek a túltermelési jelenségnek?
A „tömegfejlesztés” jelensége
A vízesés modellben történő fejlesztést ábrázolva a tömegtermelés mechanizmusához nagyon hasonló folyamatot fedezhetünk fel.
A vízesés modell szerint a különböző „megmunkálási fázisok” nagy tömegben állítják elő a szoftver különböző elemeihez tartozó „alkatrészeket”. Első lépésben a felmérésre, követelményelemzésre specializálódott elemzői csoportok elkészítik a teljes rendszert lefedő követelményelemzést, majd ebből a követelményspecifikációt. Miután ezzel elkészültek, továbbítják a specifikációt a tervező „folyamatszigethez”, ahol elkészítik a rendszer logikai, esetleg fizikai rendszertervét. A következő lépésben a fejlesztés „folyamatsziget” elkészíti a működő rendszert, amit végül a tesztelésre specializálódott tesztelői csoport ellenőriz. Jól látható, hogy az egyes fázisok között hatalmas méretű és értékű „készletek” mozognak, hiszen minden egyes fázisban óriási mennyiségű szellemi termék keletkezett.
Itt érdemes visszatérni a Standish Group eredményeire. Ha elfogadjuk a kutatás következtetését, akkor a fejlesztésre fordított energia minimum 45%-a teles pazarlás volt, hiszen olyan funkciók elkészítésével töltötte a csapat az idejét, amire lényegében nincsen szükség. A valóságban ennél lényegesen több pazarlás jelentkezett a rendszerben, ha figyelembe vesszük az alábbiakat:
- a felhasználók az állandóan, vagy gyakran használt 20%-nyi funkciót csak akkor tudják alkalmazásba venni, amikor elkészült a 80%-nyi ritkán vagy, egyáltalán nem használt funkció is
- a valóságban a projekt különböző fázisaiban sok funkció kihagyásáról döntenek, melyek az előző fázisok feldolgozási folyamatain már végigmentek (pl. a fejlesztési szakaszban kihagyott funkció specifikálásába és tervezésébe fektetett munka ugyanúgy veszteség)
- a felmért és megtervezett funkciók nagyon nagy arányban változnak a fejlesztés során, amely változások visszavezetése a korábbi fázisok dokumentációiba hatalmas energiákat emészt fel.
A lean elvek szerinti fejlesztés
Az agilis szoftverfejlesztési módszerek lényegében felfoghatók a lean gyártás analógiájaként.
Ebben az esetben a rendszerben megvalósított funkciókat ideális esetben egyenként valósítjuk meg a felméréstől egészen a tesztelésig. Minden folyamat eredménye egy potenciálisan átadható és használatba vehető funkció.
Az agilis fejlesztés, hasonlóan a lean gyártásban bemutatott számítógép összeszereléshez lehetővé teszi, hogy a felhasználók lényegesen hamarabb jussanak hozzá a valóban hasznos funkciókhoz. A felmérési, specifikációs szakaszban elkövetett hibák gyakorlatilag azonnal felismerhetők, hiszen a koncepciót rendkívül gyorsan kipróbálható kód követi.
A rugalmasság
A lean gyártás akkor valósítható meg hatékonyan, ha a „gyártósor” magas fokú rugalmassággal rendelkezik. Ez a rugalmasság teszi lehetővé, hogy ugyanazokkal a termelőberendezésekkel kielégíthetőek legyenek a változó igények. Ez például az autógyártásnál azt jelentheti, hogy ugyanazt a típust bőr üléssel és különböző színű kárpitokkal is folyamatosan tudják gyártani, az igényeknek megfelelően.
Szemben a tömegtermelési modellel, ahol például a piackutatási előrejelzések alapján első körben legyártanak 100 fekete kárpittal szerelt autót, majd 50 bőr üléssel szerelt autót, a lean gyártásban minden bőr kárpittal szerelt autót két fekete szövet kárpittal szerelt autó követ. Ez teszi lehetővé, hogy a megrendelői igények változása esetén ne halmozódjanak fel eladhatatlan készletek, ha például az derül ki, hogy mégis nagyobb igény mutatkozik a bőr kárpittal szerelt autók iránt.A gyártósor rugalmassága a szoftverfejlesztésben a rendszer módosíthatóságának felel meg. Mivel az agilis fejlesztés során nem készítünk átfogó, a rendszer teljes funkcionalitásának ismeretén alapuló rendszertervet, ezért a módszer akkor működik, ha az elkészült kód a a projekt során szerzett új ismereteknek megfelelően könnyen módosítható, kiegészíthető. Az agilis fejlesztést gyakorlatilag a szoftvertechnológia olyan újításai teszik lehetővé, melyek éppen a fejlesztés rugalmasságát támogatják. Ezek az újítások többek között a modern fejlesztői környezetek és nyelvek, vagy az olyan fejlesztési technikák, mint az automatikus tesztek, a teszt vezérelt fejlesztés, vagy a gyakori refaktoring. Ezeket a fejlesztési technikákat gyűjtötte egységes, működő rendszerré az eXtreme Programming.
A klasszikus, vízesés modell abból a feltevésből indul ki, hogy egy fejlesztési projektben a rendszeren végzett módosítások költsége exponenciálisan nő az idő előrehladtával. Ez a feltételezés a korai időkben igaz is volt és indokolta, hogy minél korábbi időpontban rendelkezzünk az összes olyan információval, ami a rendszer funkcionalitását befolyásolhatja.
A modern fejlesztési módszerek bevezetésével ez a feltételezés már nem állja meg a helyét. Egy jól szervezett, automatikus tesztekkel alaposan lefedett kód módosítása ma már korántsem jelent akkora többletköltséget, mint a régi időkben. Ma már a kód módosításának, az esetleges újratervezéseknek a költsége általában lényegesen alacsonyabb, mint a „tömegfejlesztés” módszeréből adódó veszteségek költsége, nem is beszélve a funkciók folyamatos és korai bevezetéséből adódó „time-to-market” idő csökkentéséből fakadó üzleti haszonról.
0 megjegyzés:
Megjegyzés küldése