You are on page 1of 23

Adaptív menedzsment

A Scrum-tól a lean/kanban módszerig

2009. december

Adaptive Consulting Kft. | info@adaptiveconsulting.hu

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Szerző: Csutorás Zoltán

Szerzői jogok A dokumentum szabadon terjeszthető, bemutatható és előadható az alábbi feltételekkel.
Az Adaptive Consulting Kft-re mint szerzőre és a dokumentum címére történő hivatkozással A dokumentum nem használható fel kereskedelmi céllal A dokumentum részeiben vagy egészében kizárólag változtatás nélkül terjeszthető

A dokumentumban felhasznált fényképek forrása: iStockphoto

2

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

[Tartalom]
Bevezetés Az agilis kiáltvány félreértelmezve
Tévhit: az agilis projekt lazán kezeli a határidőket Tévhit: az agilis projekt tagjai nem viselnek felelősséget 5 6

4 5

Lean menedzsment
A tömegtermelés eszméje Az egydarabos áramlás 7 8

7

Agilis fejlesztés a lean menedzsment tükrében
A „tömegfejlesztés” jelensége A lean elvek szerinti fejlesztés 9 10

9

Termékfejlesztés
A Scrum háttere Scrum projekt bontás Vizuális menedzsment eszközök A Scrum vizuális eszközeinek korlátai 12 13 14 16

12

A „kész” definíciójának szerepe A lean/kanban fejlesztés
A folyamatos áramlás biztosítása Húzórendszer kialakítása Veszteségek felszámolása Problémák azonnali felszámolása A lean/kanban rendszer jellemzői 20 21 22 22 23

19 20

3

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Bevezetés
“A csatákra való felkészülés során készített tervek mindig haszontalannak bizonyultak, de a tervezés maga nélkülözhetetlen.” Eisenhower A szoftverfejlesztési projektek sikerességi mutatói az elmúlt évtizedekben meglehetősen kiábrándító képet mutattak. A vízesés modell szerint menedzselt fejlesztések résztvevői mind a felhasználói-megrendelői, mind a fejlesztői oldalon folyamatosan szembesülnek a “műfaj” nehézségeivel és kudarcaival. Ebben a környezetben mindkét fél könnyen okolhatja a másik oldalt a tervektől jelentősen elmaradó eredményekért. Az utóbbi néhány évben egyre többen kérdőjelezik meg azokat a módszereket, amelyek meghatározták az egyedi szoftverfejlesztési projektek menedzselésének módját. A tradicionális vízesés modell központi eleme a követelmények teljeskörű feltérképezése a projekt kezdetén, amit a rendszer részletes terveinek elkészítése követ. A fejlesztés csak azt követően kezdődhet el, hogy a projekt résztvevői pontosan meghatározták a jövőbeni rendszer minden paraméterét. Az előrejelzés ilyen szintű hangsúlyossága miatt szokás a vízesés módszertant prediktív modellnek is nevezni. A tervezhetőség a megrendelők és felhasználók megkérdőjelezhetetlen, jogos igénye. A prediktív megközelítés ugyanakkor rendkívüli hatékonyság-csökkenést eredményez az egyedi szoftverfejlesztésben. Ezt ismerték fel az egyre népszerűbb agilis fejlesztési módszertanok megalkotói. Az agilis fejlesztési megközelítés központi eleme az a felismerés, hogy az egyedi fejlesztési projektekben készítendő rendszerrel kapcsolatos minden elvárás és követelmény nem mérhető fel teljeskörűen a projekt legelső szakaszában. A fejlesztés során mind a felhasználók/megrendelők, mind pedig a fejlesztők egyre pontosabb képet kapnak a lehetőségekről és a valós igényekről, melyek legtöbbször felülírják az eredeti elképzeléseket. Ha ez így van, akkor a kezdeti részletes, mindenre kiterjedő követelmény-elemzésbe fektetett energia nagy része felesleges ráfordítás, a túl korán meghozott döntések és megkötések pedig gyakran hibás irányba terelik a projektet. Az igények folyamatos megismerésébe és a változó körülményekhez történő alkalmazkodási képességre fektetett hangsúly miatt az agilis módszereket gyakran nevezik adaptív megközelítésnek. Paradox módon sok sikeres projekt bizonyítja, hogy az adaptív módszertanokban alkalmazott eljárások megfelelő alkalmazása végül a prediktív modellekénél magasabb fokú előrejelezhetőséghez vezet. A vízesés modell gyökerei kiforrott, más iparágakban jól bevált projektmenedzsment módszerekre vezethetőek vissza, ezért követői jogosan várnak el hasonló megalapozottságot a minden eddigi konvenciót felrúgó adaptív módszerektől. Ez a dokumentum az adaptív módszerek mögött meghúzódó, bizonyítottan sikeres menedzsment megközelítések áttekintő ismertetését célozza meg.

4

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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. Az egyetlen probléma az agilis kiáltvánnyal, hogy a fázisolt termékfejlesztési módszertanokon (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 kerüljük a szerződéskötést. Ez alapján a logika alapján az utolsó pont sem meglepő: még a tervezést sem tartjuk fontosnak! Nyilván nem ez húzódik meg az irányzat mögött.

Tévhit: az agilis projekt lazán kezeli a határidőket
Ez a hiedelem még agilis fejlesztési módszertanokkal foglalkozó portálokon is megjelenik és jelentős projektmenedzsment fórumokon is elhangzik, mint végkö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 modellben vezényelt 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 kap!

5

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Tévhit: az agilis projekt tagjai nem viselnek felelősséget
A félreé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. (Az egy-személyi felelősség megjelenik az adaptív menedzsmentben is. A product owner a Scrum-ban, vagy a chief architekt a Toyotánál teljes körű felelősséget visel a projekt sikeréért, de a direkt irányítás helyett a mechanizmusok fenntartására és javítására, a jó csapat összeállítására helyezi a hangsúlyt.) 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.

6

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Lean menedzsment
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 sikeré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 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 nézzük meg 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.

7

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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 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.

8

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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.
Állandóan 7%

Soha 45%

Gyakran 13%

Néha 16% Ritkán 19%

A jelentésben azt vizsgálták, hogy az egyedi fejlesztésű Forrás: Standish Group Chaos Report v3 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.
Interjúk, követelmény gyűjtés

!
Specifikáció

Tervezés

Fejlesztés Tesztelés

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
9

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

elkészültek, továbbítják a specifikációt a tervező „folyamat-szigethez”, ahol elkészítik a rendszer logikai, esetleg fizikai rendszertervét. A következő lépésben a fejlesztés „folyamat-sziget” 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 tömegtermelés filozófiájával szemben a lean menedzsment a fenti problémák kiküszöbölésére fekteti a hangsúlyt.

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
10

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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 szövet 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 Módosítás a rendszer módosíthatóságának felel meg. Mivel költsége Vízesés fejlesztés 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 XP módosítható, kiegészíthető. Az agilis fejlesztést gyakorlatilag a szoftver-technoló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 Idő é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őrehaladtá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öbblet kö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égei általában lényegesen alacsonyabbak, mint a „tömegfejlesztés” módszeréből adódó túltermelési veszteségek költsége, nem is beszélve a funkciók folyamatos és korai bevezetéséből adódó „time-tomarket” idő csökkentéséből fakadó üzleti haszonról.

11

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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és mivolta. A legismertebb és mára leginkább elterjedt egyedi szoftverfejlesztésekhez alkalmazott menedzsment keretrendszer a Scrum. Kevésbé nyílt és 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: http://adaptiveproject.blogspot.com/search/label/Term%C3%A9kfejleszt%C3%A9s

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 tradícioná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 viszonylag 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
12

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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 végrehajtandó legfontosabb 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 alapvetően meghatározzák.
Napi stand -up Product backlog

Sprint backlog

Átadható funkció

Sprint tervezés

Sprint, megvalósítás

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 zárásakor a team kiértékeli a sprint tapasztalatait, az esetlegesen elkövetett hibákat és ennek ismeretében folyamatosan javítja munkamódszerét. 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ó, maximum 15 perc hosszúságú 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.

13

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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 mutatja.
Várakozik Folyamatban Kész
5

Feladat

20

Feladat

Feladat

2

Feladat

3

Feladat

13

Feladat

1

Feladat

2 Feladat 20

8

Feladat

5

Feladat

Feladat

5

Feladat

8

Team board

A feladatokat egy-egy „cetli”, más néven kanban jelöli. (A kanban japán szóból ered, körülbelüli jelentése: vizuális vezérlő jel.) 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.

14

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

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 adott sprintben elvégzendő összes feladatról. A sprint sikerességének méréséhez 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.
Tervezett összes feladat mennyisége

Burn-down chart

Sprint tervezett időtartama

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.

15

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

A Scrum vizuális eszközeinek korlátai
A Scrum egy szándékosan „nyitva hagyott” keretrendszer és rengeteg olyan részletet nem szabályoz, melyek gyakorlati megvalósítása nagyban befolyásolja a projekt sikerét. Ennek elsődleges oka talán az, hogy ezek a gyakorlati „részletkérdések” nagyban függnek a projekt környezetétől és adottságaitól. A Scrum-ban még járatlan csapatok első néhány sprintjét gyak ran jellemzik az itt látható burn-down chartok. De mi lehet ennek az oka? A burn-down chart sem mond el önmagában sokat arról, hogy a sprint sikeres volt-e vagy sem. Mindenesetre, ha visszanyúlunk a lean menedzsment alapelveihez érezni lehet, hogy a fenti ábra szerint lezajlott sprint igencsak „gyanús”, mivel nem követi az egyenletes termelés idálját. Ahhoz, hogy többet lehessen tudni arról, hogy mi is történhetett valójában, érdemes egy pillantást vetni a projekt jellemző időpontjaiban a team boardra is.
“Gyanús” sprint lefutás

Várakozik

Folyamatban
8 5

Kész

Feladat

Feladat
13 2

Feladat
1 20

Feladat

Feladat
3

Feladat
2

Feladat
2

Feladat
5

Feladat

Feladat

Sprint 2. napja

Látható, hogy a sprint 2. napján még látszólag minden rendben halad, a csapat három feladat végrehajtásával foglalkozik, egyet pedig már be is fejezett.

16

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Várakozik

Folyamatban
8

Kész
5

Feladat
13 2

Feladat

Feladat
1 20

Feladat

Feladat
2 3

Feladat

Feladat
2 5

Feladat

Feladat

Feladat

Sprint 6. napja

A sprint 6. napján látszódnak már a problémák. A vízszintes vonalat némileg magyarázhatja, hogy kettő darab „nagy” feladat is „folyamatban” státuszban van, ezek előrehaladásáról a tábla nem igazán ad felvilágosítást. Lehet, hogy már csak egy-két óra munka van mindkettővel, ezért bármelyik pillanatban „lezuhanhat” a grafikon.

Várakozik

Folyamatban
8

Kész
5

Feladat
2

Feladat
13

Feladat
1 20

Feladat

Feladat
3

Feladat
2

Feladat
2 5

Feladat

Feladat

Feladat

Sprint 7. napja

Az előző (6.) napon aggasztó jel volt, hogy összesen öt feladat volt fejlesztés alatt. Ezek után nem meglepő, a megosztott erőforrások miatt mindössze egyetlen feladattal sikerült végezni a 7. napon.

17

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Várakozik

Folyamatban
8

Kész
5

Feladat
2

Feladat
13

Feladat
1

Feladat
20

Feladat
3

Feladat
2

Feladat
2

Feladat
5

Feladat

Feladat

Sprint 9. napja

Mivel feltételezett csapatunk igen lelkiismeretes (és mert saját vállalása volt a sprintbe tervezett feladatok mindegyike) túlórázik és végülis legyűri az összes feladatot. A menedzsment tehát elégedett lehet. Vagy mégsem?

18

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

A „kész” definíciójának szerepe
A Scrum egyik nagy nyitva hagyott kérdése, hogy milyen fázisokon keresztül készítünk el egy szoftvert. Annak ellenére, hogy a grafikon lefutása ilyen „púpos” lett, elképzelhető hogy a csapat teljesítette a folyamatos termelés idálját? Mi történt a feladatokkal az alatt, amíg a „folyamatban” státuszban voltak? Egyáltalán bízhatunk abban, hogy a sprint utolsó harmadában elkészített funkciók ugyanolyan alapossággal készültek, mint az első harmadban lezárt feladatok? A válasz valószínűleg nem, de az mindenesetre biztos, hogy önmagában a burn-down chart és a team board alapján nem derül ki a válasz. Annak érdekében, hogy a fenti kérdéseket biztonsággal megválaszolhassuk, fontos tisztázni, hogy mikor tekintünk egy feladatot késznek. A „kész” egy jó definíciója lehet az alábbi: a kód elkészült, unit-tesztekkel lefedett, a manuális és automatikus regressziós tesztek sikeresen lefutottak, az elkészült funkciók dokumentálva vannak, a súgók készen vannak, inicializáló, telepítő szkriptek készen vannak. Ha a „kész” minden esetben ugyanazt jelenti, akkor már jó eséllyel bízhatunk benne, hogy a rendszer minőségi jellemzői az elvárásoknak megfelőlek és a sprint utolsó harmadában nem az történt, hogy a fejlesztői csapat „összecsapta” a feladatokat.

19

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

A lean/kanban fejlesztés
Míg a Scrum a fejlesztési projekt termékfejlesztési vonatkozásaira fekteti a hangsúlyt, addig a lean/kanban projektmenedzsment ezek mellett erősen koncentrál a fejlesztési folyamat „termelési” megközelítésére is. A lean/kanban fejlesztés az agilis módszertanok második nagy hullámát képviselik és jobban koncentrálnak a folyamatokra. A lean/kanban módszer nem jelenti a Scrum leváltását, inkább annak kiegészítésének érdemes tekinteni. A kanban rendszer bevezetésének első lépcsőfoka a Scrum, aminek az „átugrásával” kockázatos próbálkozni. A lean menedzsment néhány fontos célkitűzése az alábbi: a feladatok folyamatos áramlásának biztosítása annak érdekében, hogy a teremlés „természetes egyszerűséggel”, megszakításmentesen haladjon az igényeken alapuló húzórendszer kialakítása a túltermelés elkerülése érdekében a veszteség felszámolása a felesleges tevékenységek kiiktatásával és a túltermelés megszüntetésével minden probléma és akadály azonnali feltárása és megszüntetése A fenti elvek a Toyota lean termelési rendszeréből származnak és minden szervezetnek érdemes megfontolnia. Mit jelent ezek követése a szoftver projektmendzsment szempontjából?

A folyamatos áramlás biztosítása
A folyamatos áramlás szellemében a projekt sprintekbe szervezése nem optimális megoldás, mivel megszakítja a feladatok folyamatos végrehajtását. A lean szoftverfejlesztés alapelveinek megfelelő rendszerben pontosan azonosítva van minden olyan tevékenység, amely szükséges annak érdekében, hogy a terméket elkészítsük és használatra átadjuk az ügyfél számára. (A klasszikus Toyota módszer a folyamatot az áru ellenértékének beérkezésével zárja.)
Priorizálás Előkészítés Fejlesztés Tesztelés Dokumentálás Release előkészítés

Kanban tábla

Ha feltérképeztük a fejlesztési folyamat lépéseit, akkor ezeket ábrázolhatjuk is a vizuális menedzsment eszközünkön.

20

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

A kanban táblán tehát minden olyan tevékenységet szerepeltetünk, amelyek végrehajtása szükséges ahhoz, hogy a rendszert elkészítsük és leszállítsuk. Ezeknek a lépéseknek egy példáját tartalmazza a fenti ábra. A priorizálás jelenti azt a tevékenységet, amikor a menedzsment elemzi, hogy mely funkciók elkészítése jelenti a legnagyobb hozzáadott értéket a felhasználók számára, majd ennek megfelelően rendezi fontossági sorrendbe a feladatokat. Az előkészítés során a fejlesztők és elemzők/ szervezők, tesztelők elkészítik a fejlesztendő funkciók rövid leírását és meghatározzák a tesztelési eljárásokat, előkészítik a tesztadatokat. Ezt követően kezdődhet meg a fejlesztés, amit a tesztelés, dokumentálás, majd a telepítő csomag összeállítása követ.

Húzórendszer kialakítása
A húzórendszer lényege, hogy ne hajtsunk végre addig semilyen feladatot, amíg az azt felhasználó következő munkafázis nem készült fel annak feldolgozására. Ez a gyakorlatban például azt jelentheti, hogy a fejlesztői csapat addig nem lát neki újabb funkció fejlesztésének, amíg az előzőleg elkészített funkció tesztelése meg nem kezdődött, mert ez a tesztelés számára történő túltermelést jelentené.
Priorizálás 13 Előkészítés 13 Fejlesztés 13 Tesztelés 13 Dokumentálás 13 Release előkészítés

Feladat

Feladat

Feladat

Feladat

Feladat

Húzórendszer

A húzórendszerben tehát minden esetben a folyamat utolsó fázisának „felszabadulása” adja ki a jelet az őt megelőző fázisnak egy újabb feladat feldolgozásának megkezdésére, mely továbbgyűrűzik egészen a legelső fázisig. Ez a megközelítés kezdetben kissé furcsának tűnhet, de a gyakorlatban több csapat is nagy sikerrel alkalmazza. A húzórendszer megvalósításának feltétele, hogy az egyes fázisokon lévő munkaterhelés kiegyenlíthető legyen. Ez elméletben azt jelenti, hogy minden feladatnak megegyező méretűnek kell lennie és minden fázishoz úgy kell hozzárendelni az erőforrásokat, hogy az egyes feldolgozási fázisokban egy „munkadarab”/funkció ugyanannyi időt töltsön, különben kiegyenlítetlen, „lüktető” lesz a fejlesztés. A szoftverfejlesztési gyakorlatban ez nem igazán valósítható meg, kialakítható viszont olyan csapatösszetétel, amely képes a munkafázisok közötti erőforrásigények kiegyenlítésére. Más szóval ez azt jelenti, hogy több olyan ember is dolgozik a teamben, aki képes több fázisban is feladatokat ellátni pl. egy elemző/szervező elvileg minden szükséges kompetenciával rendelkezik ahhoz, hogy tesztelhesse az alkalmazást, vagy sok fejlesztő és tesztelő képes telepítő szkripteket készíteni, vagy dokumentálni. Ezzel megvalósítható a munkafázisok közötti kiegyenlített áramlás.

21

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

Veszteségek felszámolása
A veszteségek felszámolása a lean menedzsment központi eleme és mint ilyen, a téma jóval túlmutat ennek a dokumentumnak a keretein. A veszteségek nyolc forrása közül több összefüggésben áll a készletek felhalmozásával és a túltermeléssel. A lean szoftverfejlesztésben a készletek csökkentésének egyik eszköze a feldolgozási státuszban lévő feladatok számának korlátozása. (Work in progress limit/ WIP-limit).
Priorizálás Előkészítés Fejlesztés Tesztelés Dokumentálás Release előkészítés

WIP limit

Mivel a fejlesztési projektet vezérlő üzleti elvárások és prioritások folyamatosan változnak, az egyik leggyakoribb veszteség forrás a félbehagyott kód, vagy funkció. Azért, hogy a projekt veszteség nélkül, rugalmasan reagálhasson a változó üzleti igényekre, minimalizálni kell a feldolgozás alatt lévő feladatok számát. A gyakorlatban ez azt jelenti, hogy maximum annyi feladat lehet az egyes feldolgozási lépésekben, ahány üres hely áll rendelkezésre a kanban táblán az adott munkafázishoz. A feladat-limitek meghatározása a projekt és a fejlesztői team jellegzetességeinek figyelembe vételével történik. Az ábrán zöld színnel vannak jelölve a „felhasználható” helyek, azaz a tábla biztosítja, hogy például egyszerre maximum egyetlen feladat lehet fejlesztés alatt. A barack színű hely a tesztelésből hibával a fejlesztésre visszakerült feladatok számára van fenntartva, ide csak a tesztelők helyezhetnek el kanban kártyát.

Problémák azonnali felszámolása
A WIP-limit bevezetésével a folyamat érzékenyen reagál a hibákra, ezért azokat azonnal fel kell számolni. A lean/kanban rendszer nem alkalmazza a rendszeres kiértékelést, ehelyett minden egyes felmerülő hibát azonnal, késlekedés nélkül kiértékelnek, javítanak és módosítják az eljárásokat, hogy többé ne fordulhasson elő.

22

Adaptív menedzsment

http://adaptiveproject.blogspot.com/

A lean/kanban rendszer jellemzői
A lean/kanban talán a legszigorúbb és legnagyobb fegyelmet követelő menedzsment módszer, mely ugyanakkor a végtelen fejlődés előtt nyitja meg az utat az alkalmazói számára.

Ciklusidő
A kanban rendszerben nincs szükség burn-down chart alkalmazására, a csapat teljesítményének mérésére a ciklusidő szolgál. A ciklusidő azt mutatja meg, hogy egy egységnyi funkció elkészítése és élesbe állításra történő felkészítése mennyi ideig tart. Ha például minden fázisban 1 napot tölt egy funkció, akkor hat nap a csapat ciklusideje. A módszer feltételezi azt, hogy a csapat képes a funkcióat megközelítőleg egyenlő méretű feladatokra bontani. Elképzelhető az egységnyi story pontra számított ciklusidő mérése is, ekkor egy 3 story pontos feladat háromszor annyi idő alatt „fut végig” a rendszeren, mint egy 1 story pont méretű feladat. Ez a megoldás megnehizíti ugyanakkor a kiegyenlített termelés megvalósítását.

A lean/kanban rendszer kihívásai
Fontos tisztában lenni azzal, hogy a lean szoftverfejlesztési projektmenedzsment rendszer kialakítása rengeteg nehézséget tartogat az átállás elején, cserébe viszont kitűnő visszajelző rendszerként szolgál a fejlesztési módszerekben lévő hibák, vagy szabályozatlanságok felderítésére és kijavítására. A lean/kanban rendszer egyik legfontosabb jellemzője, hogy nagyon nagy fegyelmet követel a csapattól és nagyon pontos előkészítést igényel a folyamatlépések, valamint a wip-limitek jó meghatározása. A módszer rendkívül érzékeny a hibákra, mivel a feladatok méretének hibás becslése, vagy a gyakori hibajavítás a teljes fejlesztési folyamatot blokkolja, mivel nem szabadul fel kapacitás az egyes munkafázisokon.

A lean/kanban rendszerben rejlő lehetőségek
A módszer alkalmazásával nagyon jól szabályozottá, tervezhetővé és rugalmassá válik a csapat fejlesztési tevékenysége. Mivel a rendszer rendkívül érzékeny a hibákra, ezért a teljes csapatot rákényszeríti a hibák forrásának felkutatására és azonnali kijavítására, amivel a magas minőségi szint gyakorlatilag automatikusan együtt jár. A ciklusidő egy jól megfogható, egyszerű és lényeges mérőszám, aminek a javítására könnyen ösztönözhető egy csapat. A ciklusidő folyamatos csökkentése állandó teljesítmény-növekedést von maga után.

23