Kedves olgi, sajnos nem
1 napja
2010. október 8., péntek
Adaptive Consulting
Elkészült a cégem honlapja. A továbbiakban a www.adaptiveconsulting.hu honlapon fogok cikkeket és előadásokat publikálni. Az adaptív menedzsmentről szóló pdf dokumentum itt tölthető le: http://www.adaptiveconsulting.hu/dokumentumok
2009. december 10., csütörtök
Adaptív menedzsment
Elkészítettem az adaptív/agilis módszertanok mögött lévő menedzsment modellek hátteréről szóló ismertetőt. A dokumentum a Java User Meetings rendezvényen tartott előadásom tematikáját követi. Minden visszajelzést örömmel fogadok...
A dokumentum letölthető és olvasható itt.
Adaptív menedzsment
A dokumentum letölthető és olvasható itt.
Adaptív menedzsment
2009. december 7., hétfő
Szoftverfejlesztés, termékfejlesztés
A lean menedzsment alapvetően a gyártási folyamatok irányításának a filozófiája. Az egyedi szoftverfejlesztés azonban csak részben termelés, legalább ennyire hangsúlyos a termékfejlesztési irányultság. A legismertebb és mára leginkább elterjedt egyedi szoftverfejlesztésekhez alkalmazott menedzsment keretrendszer a Scrum. Kevésbé nyílt is ismert, de alapelveiben nagyon hasonló megközelítést képvisel a Toyota termékfejlesztési módszertana, a TPDS (Toyota Product Development System).
A két termékfejlesztési módszer háttereinek részletesebb ismertetése ezekben a cikkekben található. A módszer gyakorlati alkalmazásáról István bővebben is ír a blogján.
A Scrum háttere
A Scrum gyökereit két japán kutató, Ikujiro Nonaka és Hirotaka Takeuchi fektette le a „The new new product development game” c. publikációjában. A kutatásuk középpontjában az a kérdés állt, hogy hogyan képes néhány vállalat az iparági átlagot magasan meghaladó színvonalon végrehajtani termékfejlesztési projektjeit. A Scrum tehát nem egy elméleti menedzsment modell, hanem a termékfejlesztésben sikeres vállalatok gyakorlatát összegző kutatás eredménye.
A tanulmány egyik legfontosabb megállapítása, hogy a hatékony termékfejlesztést megvalósító vállalatok nem a vízesés – másnéven fázisolt PPP (Phased Product Planning) – menedzsment módszert követik, hanem egyfajta iteratív megközelítést alkalmaznak, melynek során a termék számos jellemzőjét nyitva hagyják egészen a fejlesztés végéig. Ez nagyban különbözik azoktól a tradicionális megközelítésektől, melyek során a lehető legpontosabb specifikációra törekednek már a tervezés megkezdése előtt. A Scrum modellben fejlesztő vállalatok a kialakítandó termék néhány legfontosabb jellemzőjét fektetik le, a részletekre vonatkozó döntéseket a fejlesztői csapatra bízzák.
Takeuchi és Nonaka felismerése szerint lényegesen hatékonyabb, ha a vízesés modellnél alkalmazott funkcionális csoportszervezés (pl. külön marketing, tervező és megvalósító csoport) helyett keresztfunkcionális, termékorientált csoportokat hoznak létre, melyben minden szakterület képviselteti magát. Egy Scrum csapatnak ugyanolyan szereplője a vevői elvárásokat kutató marketing szakember, mint a termék műszaki tervezéséért felelős mérnök, vagy a majdani gyártási folyamatot megtervező gyártásszervező. Ez a szemlélet teszi lehetővé, hogy a termékjellemzőket úgy alakítsák ki, hogy azok a termék teljes életciklusát figyelembe véve optimálisak legyenek. A termékjellemzők különböző szempontjait a fejlesztési időszakban ütköztetik és hozzák meg a szükséges kompromisszumokat, illetve egy-egy felfedezés vagy ötlet eredményét bármely szempontba képesek visszavezetni. A Toyota Prius fejlesztésénél például a fejlesztés nagyon késői szakaszában hozták meg azt a döntést, hogy az autó hibrid hajtásának akkumulátorait nem a motortérben, hanem hátul a csomagtér alatt helyezik el, mivel a motor melletti nagy hőmérsékletingadozást az akkumulátorok nem viselnék el. Ez a döntés az autó számos jellemzőjét (csomagtér, aerodinamika, hajtáslánc stb.) befolyásolta. A projekt elején nem volt még világos, hogy milyen akkumulátorok bizonyulnak majd optimálisnak, ezért a döntéssel számos kísérletet kellett megvárni. Egy ilyen horderejű döntés halogatása nem lett volna kivitelezhető, ha a csoport nem képes rövid idő alatt, saját hatáskörben elemzni annak következményeit (pl. a rövidebb motortérből adódó jobb városi manőverezési képességek, vagy a nagyobb csomagtér jelent több előnyt?). A Scrum jellemzője tehát a magas fokú döntési önállóságot élvező termékfejlesztési csoport.
Mivel a csoport nem előre meghatározott termékjellemzők és tervek szerint állítja elő a terméket, ezért szükség van olyan mechanizmusokra, melyek világosan megmutatják, hogy a projekt elfogadható mederben halad-e. Ennek megvalósításához a Scrum csapatok egyértelmű, vizuális mérési rendszereket alkalmaznak, melyeken bárki, első ránézésre láthatja a projekt előrehaladását, illetve segíti a csapattagokat abban, hogy könnyen felismerjék a projekt előmozdításához legfontosabb végrehajtandó feladatokat.
Scrum projekt bontás
A Scrum projektben megvalósítandó termék funkcióinak, valamint a projektben elvégzendő legfontosabb feladatoknak a listáját a product backlog tartalmazza. Fontos, hogy a product backlog elemeihez mindenképpen prioritások vannak rendelve, melyek egyben a feladatok elvégzésének sorrendjét is jelentik.
A projekt megvalósítását a team sprintekbe szervezve végzi, melyek azonos időtartamú végrehajtási egységek. A team minden sprint megkezdése előtt elvégzi a sprint-tervezést, melynek során a product backlog legmagasabb prioritású feladatai közül kiválasztja, illetve szükség esetén tovább bontja azokat a feladatokat, amelyeket a következő „nekifutásra” képes megvalósítani. Az adott sprintre vonatkozó feladatok listáját a sprint backlog tartalmazza. Minden sprint végeredménye egy tesztelt és elméletileg átadható funkció.
A sprintek során a team működése szempontjából kiemelkedő fontosságú az intenzív és hatékony kommunikáció. Ezt segíti a minden nap megtartandó stand-up meeting, ahol a team tagjai „szinkronizálják” feladataikat, valamint a korábban már említett vizuális menedzsment eszközök használata.
Vizuális menedzsment eszközök
A vizuális projektirányítási eszközökkel szembeni legfontosabb elvárás a gyors „leolvashatóság” és az egyértelműség. A Scrum napi tevékenységeiben a két legjelentősebb ilyen eszköz a team board és a burn-down chart.
Team board
A team board a csapat által az adott sprintben végrehajtandó feladatokat és azok aktuális státuszát tartalmazza.
A feladatokat egy-egy „cetli”, más néven kanban jelöli. (A kanban a japán „vezérlő-kártya” szóból származik.) A kanban kártyákon szereplő információk csapatról csapatra változhatnak, de minimálisan a feladat nevét és a feladat becsült méretét tartalmazzák. A feladatok méretének becsléséhez többféle módszer használatos, de a méret kifejezésére általában story-pont elnevezést használják. A lényeg, hogy a feladatok méretének meghatározásához használt skála nagyjából állandó legyen, azaz egy adott csapat minden egyes sprintben összesen közel azonos story-pont értékű feladat megvalósítására legyen képes.
A csapat minden nap megtartja a stand-up összejövetelt, ahol a csapattagok a kanban kártyák mozgatásával jelzik, ha egy feladat végrehajtását megkezdték vagy éppen befejezték. Ez a mechanizmus biztosítja, hogy mindenki lássa, hogy melyek azok a feladatok, melyek végrehajtásához erőforrásra van szükség. A team-board tehát a csapat kommunikációs felülete.
Burn-down chart
A team board biztosítja, hogy a csapat tagjai világosan lássák az egyes feladatok státuszát, illetve, hogy a csapat számára teljes listát adjon az összes elvégzendő feladatról.
A sprint sikerességének méréséhet viszont a team board nem rendelkezik az összes szükséges jellemzővel, mivel nem olvasható le róla azonnal, hogy a tervekhez képesti előrehaladás megfelelő-e.
A sprint tervhez viszonyított haldását mutatja a „burn-down chart”. A grafikon függőleges tengelye mutatja a sprintbe tervezett feladatok mennyiségét story-pontban. A vízszintes tengely az időt jelzi. A szaggatott vonal a sprint ideális, terv szerinti lefutását mutatja.
A csapat minden stand-up összejövetel végén behúzza az adott napon megvalósított feladatok összesített story-pont értékét a grafikonon. (Folytonos, piros vonal.) A piros vonal gyakorlatilag a sprint során még megvalósítandó feladatok összes értékét mutatja. A gyakorlatban a vonal fölfelé is mozdulhat, ha például kiderül, hogy egy feladat lényegesen komplexebb annál, mint ahogy a csapat a tervezéskor gondolta.
A két termékfejlesztési módszer háttereinek részletesebb ismertetése ezekben a cikkekben található. A módszer gyakorlati alkalmazásáról István bővebben is ír a blogján.
A Scrum háttere
A Scrum gyökereit két japán kutató, Ikujiro Nonaka és Hirotaka Takeuchi fektette le a „The new new product development game” c. publikációjában. A kutatásuk középpontjában az a kérdés állt, hogy hogyan képes néhány vállalat az iparági átlagot magasan meghaladó színvonalon végrehajtani termékfejlesztési projektjeit. A Scrum tehát nem egy elméleti menedzsment modell, hanem a termékfejlesztésben sikeres vállalatok gyakorlatát összegző kutatás eredménye.
A tanulmány egyik legfontosabb megállapítása, hogy a hatékony termékfejlesztést megvalósító vállalatok nem a vízesés – másnéven fázisolt PPP (Phased Product Planning) – menedzsment módszert követik, hanem egyfajta iteratív megközelítést alkalmaznak, melynek során a termék számos jellemzőjét nyitva hagyják egészen a fejlesztés végéig. Ez nagyban különbözik azoktól a tradicionális megközelítésektől, melyek során a lehető legpontosabb specifikációra törekednek már a tervezés megkezdése előtt. A Scrum modellben fejlesztő vállalatok a kialakítandó termék néhány legfontosabb jellemzőjét fektetik le, a részletekre vonatkozó döntéseket a fejlesztői csapatra bízzák.
Takeuchi és Nonaka felismerése szerint lényegesen hatékonyabb, ha a vízesés modellnél alkalmazott funkcionális csoportszervezés (pl. külön marketing, tervező és megvalósító csoport) helyett keresztfunkcionális, termékorientált csoportokat hoznak létre, melyben minden szakterület képviselteti magát. Egy Scrum csapatnak ugyanolyan szereplője a vevői elvárásokat kutató marketing szakember, mint a termék műszaki tervezéséért felelős mérnök, vagy a majdani gyártási folyamatot megtervező gyártásszervező. Ez a szemlélet teszi lehetővé, hogy a termékjellemzőket úgy alakítsák ki, hogy azok a termék teljes életciklusát figyelembe véve optimálisak legyenek. A termékjellemzők különböző szempontjait a fejlesztési időszakban ütköztetik és hozzák meg a szükséges kompromisszumokat, illetve egy-egy felfedezés vagy ötlet eredményét bármely szempontba képesek visszavezetni. A Toyota Prius fejlesztésénél például a fejlesztés nagyon késői szakaszában hozták meg azt a döntést, hogy az autó hibrid hajtásának akkumulátorait nem a motortérben, hanem hátul a csomagtér alatt helyezik el, mivel a motor melletti nagy hőmérsékletingadozást az akkumulátorok nem viselnék el. Ez a döntés az autó számos jellemzőjét (csomagtér, aerodinamika, hajtáslánc stb.) befolyásolta. A projekt elején nem volt még világos, hogy milyen akkumulátorok bizonyulnak majd optimálisnak, ezért a döntéssel számos kísérletet kellett megvárni. Egy ilyen horderejű döntés halogatása nem lett volna kivitelezhető, ha a csoport nem képes rövid idő alatt, saját hatáskörben elemzni annak következményeit (pl. a rövidebb motortérből adódó jobb városi manőverezési képességek, vagy a nagyobb csomagtér jelent több előnyt?). A Scrum jellemzője tehát a magas fokú döntési önállóságot élvező termékfejlesztési csoport.
Mivel a csoport nem előre meghatározott termékjellemzők és tervek szerint állítja elő a terméket, ezért szükség van olyan mechanizmusokra, melyek világosan megmutatják, hogy a projekt elfogadható mederben halad-e. Ennek megvalósításához a Scrum csapatok egyértelmű, vizuális mérési rendszereket alkalmaznak, melyeken bárki, első ránézésre láthatja a projekt előrehaladását, illetve segíti a csapattagokat abban, hogy könnyen felismerjék a projekt előmozdításához legfontosabb végrehajtandó feladatokat.
Scrum projekt bontás
A Scrum projektben megvalósítandó termék funkcióinak, valamint a projektben elvégzendő legfontosabb feladatoknak a listáját a product backlog tartalmazza. Fontos, hogy a product backlog elemeihez mindenképpen prioritások vannak rendelve, melyek egyben a feladatok elvégzésének sorrendjét is jelentik.
A projekt megvalósítását a team sprintekbe szervezve végzi, melyek azonos időtartamú végrehajtási egységek. A team minden sprint megkezdése előtt elvégzi a sprint-tervezést, melynek során a product backlog legmagasabb prioritású feladatai közül kiválasztja, illetve szükség esetén tovább bontja azokat a feladatokat, amelyeket a következő „nekifutásra” képes megvalósítani. Az adott sprintre vonatkozó feladatok listáját a sprint backlog tartalmazza. Minden sprint végeredménye egy tesztelt és elméletileg átadható funkció.A sprintek során a team működése szempontjából kiemelkedő fontosságú az intenzív és hatékony kommunikáció. Ezt segíti a minden nap megtartandó stand-up meeting, ahol a team tagjai „szinkronizálják” feladataikat, valamint a korábban már említett vizuális menedzsment eszközök használata.
Vizuális menedzsment eszközök
A vizuális projektirányítási eszközökkel szembeni legfontosabb elvárás a gyors „leolvashatóság” és az egyértelműség. A Scrum napi tevékenységeiben a két legjelentősebb ilyen eszköz a team board és a burn-down chart.
Team board
A team board a csapat által az adott sprintben végrehajtandó feladatokat és azok aktuális státuszát tartalmazza.
A feladatokat egy-egy „cetli”, más néven kanban jelöli. (A kanban a japán „vezérlő-kártya” szóból származik.) A kanban kártyákon szereplő információk csapatról csapatra változhatnak, de minimálisan a feladat nevét és a feladat becsült méretét tartalmazzák. A feladatok méretének becsléséhez többféle módszer használatos, de a méret kifejezésére általában story-pont elnevezést használják. A lényeg, hogy a feladatok méretének meghatározásához használt skála nagyjából állandó legyen, azaz egy adott csapat minden egyes sprintben összesen közel azonos story-pont értékű feladat megvalósítására legyen képes.
A csapat minden nap megtartja a stand-up összejövetelt, ahol a csapattagok a kanban kártyák mozgatásával jelzik, ha egy feladat végrehajtását megkezdték vagy éppen befejezték. Ez a mechanizmus biztosítja, hogy mindenki lássa, hogy melyek azok a feladatok, melyek végrehajtásához erőforrásra van szükség. A team-board tehát a csapat kommunikációs felülete.
Burn-down chart
A team board biztosítja, hogy a csapat tagjai világosan lássák az egyes feladatok státuszát, illetve, hogy a csapat számára teljes listát adjon az összes elvégzendő feladatról.
A sprint sikerességének méréséhet viszont a team board nem rendelkezik az összes szükséges jellemzővel, mivel nem olvasható le róla azonnal, hogy a tervekhez képesti előrehaladás megfelelő-e.
A sprint tervhez viszonyított haldását mutatja a „burn-down chart”. A grafikon függőleges tengelye mutatja a sprintbe tervezett feladatok mennyiségét story-pontban. A vízszintes tengely az időt jelzi. A szaggatott vonal a sprint ideális, terv szerinti lefutását mutatja.
A csapat minden stand-up összejövetel végén behúzza az adott napon megvalósított feladatok összesített story-pont értékét a grafikonon. (Folytonos, piros vonal.) A piros vonal gyakorlatilag a sprint során még megvalósítandó feladatok összes értékét mutatja. A gyakorlatban a vonal fölfelé is mozdulhat, ha például kiderül, hogy egy feladat lényegesen komplexebb annál, mint ahogy a csapat a tervezéskor gondolta.
2009. november 30., hétfő
Agilis fejlesztés a lean menedzsment tükrében
Az agilis fejlesztési módszertanok mögött rejlő filozófia megértésében sokat segítenek az előző fejezetekben leírtak. De nézzük, hogy mi köze van a gyártásnak a szoftverfejlesztéshez?
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 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.
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.
2009. november 24., kedd
Lean gyártás
A lean (jelentése: karcsú, vékony) menedzsment az egyik legjobb kiindulópont az agilis filozófia megértéséhez. A lean menedzsment gyökerei a Toyota gyártási rendszeréhez nyúlnak vissza. A Toyota bebizonyította, hogy ezzel a gyökeresen új menedzsment megközelítéssel óriási piaci előnyre lehet szert tenni. A lean menedzsment siekrérét nem kell különösebben bizonygatni. Mára gyakorlatilag az összes autógyár átvette a Toyota gyártási módszer elemeit.
A lean menedzsment gyakorlatilag a klasszikus tömegtermelési módszerek hibáinak felismerésével jött létre. A tömegtermelés alapelve a nagy mennyiségben, alacsony egységáron történő gyártásban rejlik. Ezt úgy lehet elérni, ha nagy sorozatszámban gyártunk és a drága berendezések kihasználtságát maximalizáljuk, azaz folyamatosan termelünk. Ennek érdekében a tömeggyártás során hatalmas nyersanyag és gyártási készleteket halmoznak fel, hogy semmiféle fennakadás ne hátráltassa a folyamatos termelést. A következőkben Jeffrey K. Liker, A Toyota módszer c. könyvéből vett példáján keresztül mutatom be a tömegtermelés és a lean elvek szerinti gyártás közötti különbségeket. Az alábbi ábra a tömegtermelésben készülő termékek gyártási folyamatának leegyszerűsített modelljét mutatja.
Az egydarabos áramlás
A lean menedzsment ezzel szemben az egydarabos áramlás eszméjét próbálja megközelíteni. Ugyanennek a terméknek az egydarabos áramlás szerint történő gyártása úgy valósulna meg, hogy a folyamat szigetek helyett úgynevezett termelő szigeteket alakítanak ki, melyek a egy termék teljes legyártását végzik. A gyártási lépéseket egymáshoz közel helyezik el, hogy ne legyen szükség a készletek gyűjtésére és szállítására.
"A Toyota 2007. évi profitja nagyobb volt, mint a 3 legnagyobb amerikai autógyáré együttvéve. A Toyota nettó profithányada az iparági átlag 8,3-szorosa." Forrás: Jeffrey K. Liker, A Toyota módszer
A tömegtermelés eszméje
A lean menedzsment gyakorlatilag a klasszikus tömegtermelési módszerek hibáinak felismerésével jött létre. A tömegtermelés alapelve a nagy mennyiségben, alacsony egységáron történő gyártásban rejlik. Ezt úgy lehet elérni, ha nagy sorozatszámban gyártunk és a drága berendezések kihasználtságát maximalizáljuk, azaz folyamatosan termelünk. Ennek érdekében a tömeggyártás során hatalmas nyersanyag és gyártási készleteket halmoznak fel, hogy semmiféle fennakadás ne hátráltassa a folyamatos termelést. A következőkben Jeffrey K. Liker, A Toyota módszer c. könyvéből vett példáján keresztül mutatom be a tömegtermelés és a lean elvek szerinti gyártás közötti különbségeket. Az alábbi ábra a tömegtermelésben készülő termékek gyártási folyamatának leegyszerűsített modelljét mutatja.
Képzeljünk el egy számítógép-gyártó sort, ahol az első lépésben legyártják a gépházat és a gép „belsejét”. A második lépésben legyártják a monitort és a gépházra szerelik. A harmadik lépésben tesztelik az összeállított gép helyes működését. Az egyszerűség kedvéért minden gép, minden egyes fázisa egy percig tart. A gyártósorról 10 darabos egységekben szállítják át a készletet a következő feldolgozási folyamathoz. Az egyes műveleteket specializált folyamat-szigetek végzik. Ebben a modellben az első gépet 21 perc múlva állítják elő, az összes gép legyártásának ideje pedig 30 perc. Ha a tesztelés során kiderül, hogy az egyik gép gépháza hibás – és az például az egyik gyártási egység meghibásodásából adódott – az akár az összes gyártósoron lévő gépet érintheti.
Az egydarabos áramlás
A lean menedzsment ezzel szemben az egydarabos áramlás eszméjét próbálja megközelíteni. Ugyanennek a terméknek az egydarabos áramlás szerint történő gyártása úgy valósulna meg, hogy a folyamat szigetek helyett úgynevezett termelő szigeteket alakítanak ki, melyek a egy termék teljes legyártását végzik. A gyártási lépéseket egymáshoz közel helyezik el, hogy ne legyen szükség a készletek gyűjtésére és szállítására.
A termelő szigeten elsőként legyártják a gépházat, amely azonnal a következő feldolgozási egységhez kerül, ahol összeszerelik a monitorral, majd az elkészült gépet azonnal tesztelik. A megoldás eredményeként az első gép 3 perc alatt elkészül, majd percenként legyártanak egy-egy újabb terméket. Az összes gép legyártásának ideje így mindössze 12 percre csökken úgy, hogy mindössze 3 gép van egyszerre feldolgozás alatt. Ez a megközelítés lényegesen nagyobb rugalmasságot biztosít, arra az esetre, ha például a megrendelői igények hirtelen változnának. A hibás darabokat a gyártás során azonnal felismerik, a hiba maximum 3 gépet érinthet.
2009. november 20., péntek
Az agilis félresiklás
Sokat beszélgettem mostanában tapasztalt, és általam tisztelt tanárokkal és vezetőkkel az agilis fejlesztési módszerekről. Ezek hatására egyértelműen az a kép alakult ki bennem, hogy az agilis "mozgalom" valahol félresiklott. A napokban tartottam egy előadást a JUM-on (http://jum.javaforum.hu) amit ezzel a jelenséggel indítottam. Arra gondoltam, hogy az előadás mondanivalóját a következő néhány bejegyzésben felelevenítem.
Az agilis kiáltvány félreértelmezve...
Az agilis kiáltvány indította útjára az agilis fejlesztési mozgalmat. Az üzenetei egyrészről egyértelműek és világosak: koncentráljunk azokra a tevékenységekre a fejlesztés során, amik a majdani rendszer felhasználói számára közvetlenül valódi értéket teremtenek és helyezzük ezeket a másodlagos, közvetett tevékenységek elé.
Ezek szerint fontosabb:
Az egyetlen probléma az agilis kiáltvánnyal, hogy a fázisolt termékfejlesztési módszertanokban (vízesés modell) nevelkedett vezetők és mérnökök egy részében azt az érzetet kelti, hogy az agilis fejlesztés egyfajta fejlesztői "munkásforradalom", akik előrébb helyezik a hobby szerű fejlesztést a professzionális, minőségorientált munkával szemben. Értelmezhetjük így is az agilis kiáltványt: nem igazán fontosak a módszertanok, nem akarjuk dokumentálással tölteni az időt, nem vállalunk felelősséget a tevékenységünkért ezért nem kötünk szerződést, sőt még a tervezést sem tartjuk fontosnak! Nyilván nem ez húzódik meg az irányzat mögött.Az agilis kiáltvány félreértelmezve...
Az agilis kiáltvány indította útjára az agilis fejlesztési mozgalmat. Az üzenetei egyrészről egyértelműek és világosak: koncentráljunk azokra a tevékenységekre a fejlesztés során, amik a majdani rendszer felhasználói számára közvetlenül valódi értéket teremtenek és helyezzük ezeket a másodlagos, közvetett tevékenységek elé.
Ezek szerint fontosabb:
- az egyén és a személyes kommunikáció, a módszertanoknál és az eszközöknél
- a működő szoftver, az átfogó dokumentációnál
- a megrendelővel való együttműködés, a szerződéshez való ragaszkodásnál
- a változásra való reagálás, a tervek rigorózus követésénél.
Tévhit: az agilis fejlesztés csak véget nem érő projektekben, dobozos termékek fejlesztése esetén alkalmazható
Ezt a hiedelmet még agilis fejlesztési módszertanokkal foglalkozó portálon is olvastam és jelentős projektmenedzsment fórumokon is elhangzik, mint következtetés. Ha az agilis kiáltvány félreértelmezéséből indulunk ki, akkor ez logikus következmény. Az is igaz, hogy főként azok a vállalatok alkalmazzák az agilis módszereket, akik dobozos termékeket fejlesztenek (pl. Google, Apple, Microsoft stb.) Másrészt viszont ha megvizsgáljuk ezeknek a módszereknek a gyökereit, akkor észrevehetjük, hogy a Scrum vagy a Toyota Product Development System olyan közegben alakult ki, ahol a szigorú véghatáridőre leszállított eredmény alapvető követelmény! Nehéz elképzelni a Toyotáról, hogy egy autókiállításra beharangozott típussal nem készül el határidőre... Igaz, hogy az agilis fejlesztési projektek más megközelítést igényelnek, mint a vízesés projektek, ugyanakkor a meghatározott időpontra, meghatározott célokat kielégítő, magas minőségű eredmény talán még sokkal nagyobb hangsúlyt is kap!
Tévhit: az agilis fejlesztői teamek felelősségmentes, laza közösségek
A féleértés másik hibás következtetése. Az agilis pl. Scrum teamek felelőssége lényegesen nagyobb, mint az erős projektmenedzser által irányított fejlesztési projekteken, ahol a felelősséget végsősoron egy személyben a projektvezető viseli. (Hasonló szerepet vállal a product owner a Scrum-ban, vagy a chief architekt a Toyotánál.) A különbség abban áll, hogy az agilis módszertanok belátják, hogy a szoftverfejlesztés nem más, mint ezernyi kisebb-nagyobb döntés együttese. Minden fejlesztő, minden órában döntéseket hoz, amiket nem lehet előre megtervezni, sem irányítani. A komplex rendszereknek (mint amilyen a szoftverfejlesztői team is) bizonyos fokú önállóságot kell biztosítani, a folyamatos vezetői kontrollt pedig egyértelmű, transzparens, a valós előrehaladást mindenki számára világosan megjelenítő visszajelző mechanizmusokkal kell helyettesíteni. A tervektől való eltérést pedig azonnal ki kell értékelni és a team tudását felhasználva, közösen kell kitalálni a lehetséges megoldásokat. Az agilis módszereknek ez a mechanizmusa könnyen keltheti azt az érzetet, hogy az irányítást a menedzsment kiadta a kezéből. Az eredeti agilis környezetekben az elkövetett hibákért a team tényleges felelősséget vállal, a folyamatosan rosszul teljesítő csapatokat pedig megszüntetik vagy átszervezik. A csapatoknak ennek tudatában kell teljesíteniük. A valóságban tehát a menedzsment a felelősséget nem megszünteti, hanem kiterjeszti azokra, akik valóban hatással vannak a projekt sikerére: a projekt teamre.
2009. július 6., hétfő
Kano elemzés
A felhasználói és megrendelői követelmények megértése talán a legkritikusabb pontja egy egyedi rendszerek fejlesztésének. Egy korábbi bejegyzésemben írtam arról, hogy a követelmények gyakorlatilag az emberi elvárások rögzített másai. Annak ellenére, hogy léteznek rögzíthető és megismerhető követelmények, a projekt sikerének szempontjából lényegesen fontosabb a követelmények mögött meghúzódó elvárások és méginkább azok változásának megértése. A témában talán Noriaki Kano munkássága az egyik legérdekesebb tudásanyag. Noriaki Kano egy Deming-díjas kutató, aki elsősorban minőségmenedzsmenttel foglalkozott. A Kano által kidolgozott modell a termékek jellemzőit négy kategóriába sorolta a felhasználók szemszögéből.
Alapvető, szükséges (basic, mandatory)
Ezek azok a jellemzők, amiket a terméknek mindenképpen ki kell elégíteni. Az alapvető termékjellemzők tipikus tulajdonsága, hogy nem képesek a megrendelő kielégítésére, viszont hiányuk bármikor előidézheti a megrendelő teljes kiábrándultságát. Vegyük például a mobiltelefonok tulajdonságait. A mobiltelefonba épített antenna minősége egy tipikus alapvető követelmény. Ha az antenna gyenge, és a hálózati lefedettség gyengülésével azonnal megszakad a beszélgetés, az a használóját rendkívül elégetlenné teszi. Ezzel szemben hiába építenek a gyártók akármilyen érzékenységű antennát a készülékbe, attól nem fogjuk lényegesen jobban szeretni a telefont.
Értékarányos vagy teljesítményarányos (value for money proposition, performance)
Ezek azok a funkciók, amikből minél több van, annál jobb. A megrendelő értékeli ennek a jellemzőnek a javulását és egy bizonyos küszöb felett elégedetté teszi, az alatt viszont elégedetlenné. Ennek a minőségi faktornak van egy semleges zónája, aminél a megrendelő nagyjából semlegesen viszonyul a termékhez, azaz ez a jellemző nem befolyásolja az elégedettségét. A mobiltelefon példánál maradva ilyen az akkumulátor élettartama, vagy a telefon beépített memóriájának mérete.
Örömforrások (delighters)
Ezek a jellemzők azok, amikre a megrendelő nem igazán számít, viszont ha megismeri őket ragaszkodni fog hozzájuk és viszonylag kis mértékű megjelenésük is nagyon pozitív irányba befolyásolja a vevői elégedettséget. A telefon példánál maradva az iPhone multimédiás jellemzői, valamint a különleges touch-screen képességei képviselik a legjobban ezt a kategóriát. Az örömforrásoknak megvan az a tulajdonsága, hogy rendkívüli mértékben képesek felülírni a felhasználók kezdeti elvárásrendszerét. Egy Kano analízisről szóló előadáson hallottam egy példát, ahol az előadó felesége autóvásárlás előtt állt. Rengeteg szempont alapján kiválasztotta azt a három típust, amik közül választani akart. Végül egy negyediket vett meg, mégpedig egy meglepő ok miatt: az autó rendelkezett hűtő és fűtő funkcióval felszerelt pohártartóval. Ez nagyon jól példázza az örömforrás kategóriába eső jellemzők jelentőségét.
Semleges, érdektelen (indifferent)
Ezek a jellemzők nem számítanak. Teljesen mindegy, hogy megjelennek a rendszerben vagy sem. A telefonokál maradva számomra ilyen a beépített rádió. Egyáltalán nem érdekel, hogy van-e benne ilyen funkció, az meg pláne nem, hogy hány csatornát tudok felprogramozni rá. Ezeknek a jellemzőknek az a legnagyobb csapdája, hogy a megrendelők egy direkt kérdésre válaszolva természetes módon igényelni fogják. Ha egyszer egy elemző a felmérés során feltette a kérdést, hogy: "fontos, hogy a rendszer Excel 2007 formátumban is tudja exportálni az ügyféltörzset?" a válasz természetesen igen lesz. Ha ez ráadásul bekerült a követelményspecifikációba, onnantól a megrendelő "alapvető" követelményként fog tekinteni rá...
A termékjellemzők megítéléséhez kapcsolódó jelenségek
A fenti kategorizálás rendkívül sokat segít annak eldöntésében, hogy milyen termékjellemzőkre milyen mértékben koncentráljon a megvalósító csapat. Nem mindegy ugyanakkor, hogy ezeket a jellemzőket a projekt mely szakaszában vizsgáljuk. Az elvárásoknak van egy olyan tulajdonságuk, hogy a megismerés során folyamatosan egyre alacsonyabb kategóriába csúsznak. Az örömforrások idővel értékarányos elvárások lesznek (örülök neki, hogy tudok mpeg4 formátumú videót nézni a telefonomon, de miért nem tudom ezt az avi videót is megnézni? Miért csak ezt a 3 formátumot ismeri, miért nem ismer 10-et?). Később az elvárások alapvető fontosságúak lesznek: "nekem ne hozz ide olyan telefont, amiben nincs videólejátszó funkció".
A jellemzők besorolása
Az egyes jellemzők besorolása a megfelelő kategóriákba csak rendkívül alapos és óvatos munkával lehetséges. A leginkább elterjedt módja az egyes jellemzők két eset alapján történő értékelése: 1) Hogyan érintene az, ha a termék rendelkezne ezzel a jellemzővel? 2) Hogyan érintene az, ha a termék nem rendelkezne ezzel a jellemzővel? Mindkét esethez előre definiált értékeket kell rendelni, melyek például az alábbiak lehetnek:
- Nagyon örülnék neki!
- Feltétlenül legyen így!
- Nem bánom, ha így van...
- Inkább ne!
- Eszedbe ne jusson!
Feliratkozás:
Bejegyzések (Atom)