A Scrum-tól a lean/kanban módszerig 009. december Adaptive Consulting Kft.
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
[Tartalom] Bevezetés 4 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 6 Lean menedzsment 7 A tömegtermelés eszméje 7 Az egydarabos áramlás Agilis fejlesztés a lean menedzsment tükrében 9 A tömegfejlesztés jelensége 9 A lean elvek szerinti fejlesztés 10 Termékfejlesztés 1 A Scrum háttere 1 Scrum projekt bontás 13 Vizuális menedzsment eszközök 14 A Scrum vizuális eszközeinek korlátai 16 A kész definíciójának szerepe 19 A lean/kanban fejlesztés 0 A folyamatos áramlás biztosítása 0 Húzórendszer kialakítása 1 Veszteségek felszámolása 3 Problémák azonnali felszámolása 3 A lean/kanban rendszer jellemzői 4 3
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
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!
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. (A személyi felelősség megjelenik az adaptív menedzsmentben is. A product owner és Scrum master 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
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 007. évi profitja nagyobb volt, mint a 3 legnagyobb amerikai autógyáré együttvéve. A Toyota nettó profithányada az iparági átlag,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
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 1 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 1 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.
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 0%-á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 Állandóan 7% Ritkán 19% Gyakran 13% A vízesés modellben történő fejlesztést ábrázolva a tömegtermelés mechanizmusához nagyon hasonló folyamatot fedezhetünk fel. Soha 4% Néha 16% Forrás: Standish Group Chaos Report v3 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
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 4%-a teljes 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 0%-nyi funkciót csak akkor tudják alkalmazásba venni, amikor elkészült a 0%-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
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 0 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 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 és nyelvek, vagy az olyan fejlesztési technikák, mint az Módosítás költsége Vízesés fejlesztés 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. XP Idő 11
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 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 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 1
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 elemezni 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. Product backlog Napi stand -up 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 1 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
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 0 3 13 1 0 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
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 haladá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. 1
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 gyakran jellemzik az itt látható burn-down chartok. De mi lehet ennek az oka? Gyanús sprint lefutás A burn-down chart sem mond el önmagában sokat arról, hogy a sprint sikeres volt-e vagy sem. M i n d e n e s e t r e, h a v i s s z a ny ú l u n k a l e a n menedzsment alapelveihez érezni lehet, hogy a fenti ábra szerint lezajlott sprint igencsak gyanús, mivel nem követi az egyenletes termelés ideá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. Várakozik Folyamatban Kész 13 1 3 0 Sprint. napja Látható, hogy a sprint. 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
Várakozik Folyamatban Kész 13 1 0 3 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 Kész 13 1 3 0 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
Várakozik Folyamatban Kész 1 3 13 0 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? 1
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 ideá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 megfelelőek és a sprint utolsó harmadában nem az történt, hogy a fejlesztői csapat összecsapta a feladatokat. 19
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 termelé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 projektmenedzsment 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ított 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.) 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. 0
Backlog Kiválasztva Előkészítés Megvalósítás Tesztelés, Folyamatban Kész Folyamatban Kész javítás Kész 13 13 13 Kanban board 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 Backlog oszlopban szerepelnek azok a feladatok, melyek megvalósítását a Product Owner a közeli jövőben szükségesnek tartja. A Kiválasztva oszlopba kerülnek azok a feladatok, melyek megoldása a legnagyobb prioritással bír. A fejlesztő csapat tagjai ezek közül választhatnak, ha szabad kapacitásuk van. Az Előkészítés fázisban lévő feladatok azok, amelyek tervezését, előkészítését a csapat éppen végzi. Általában az előkészítés legfontosabb kimenete a kész feladat ellenőrzési módjának meghatározása, azaz: a csapat pontosan határozza meg, hogy milyen kritériumok, tesztek megvalósulása esetén tekinti a feladatot késznek. A Megvalósítás státuszban lévő feladatok azok, melyek fejlesztését a csapat éppen végzi. Az oszlopok egy részét szokás további kettő státuszra bontani: folyamatban, kész. Ezek a státuszok egyrészt jelzik a tesztelő csapat tagjainak, hogy a Fejlesztés/kész státuszban álló feladatok tesztelését megkezdhetik, másrészt jól mutatják a fejlesztési folyamat gördülékenységét. Ha sok feladat áll valamelyik oszlop Kész státuszában az azt jelenti, hogy a fejlesztés lüktet, nem kiegyenlített. Húzórendszer kialakítása A húzórendszer lényege, hogy addig semmilyen feladatot ne hajtsunk végre, 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é. 1
Backlog Kiválasztva Előkészítés Megvalósítás Tesztelés, Folyamatban Kész Folyamatban Kész javítás Kész! Húzó rendszer 1 Az oszlopok tetején lévő piros számok az adott fázis elemszám korlátját jelölik 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.
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). Kiválasztva Előkészítés, tervezés Fejlesztés Tesztelés, javítás Dokumentálás Release előkészítés WIP limitek 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 kettő 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. 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ő. 3
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ókat 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 megnehezí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. 4