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.

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

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.

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

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.

A fénykép forrása: http://mikeely.wordpress.com/2009/01/07/mike-ely-on-triumphs-sorrows-of-the-soviet-revolution/

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!

http://www.betterprojects.net/2009/06/kano-requirements-talk.html

Toyota Product Development System

A Toyota sikerének nem csak a TPS (Toyota Production System), vagy ismertebb nevén a Lean gyártástechnológia a titka. Kosaku Yamada a Lexus ES 300 vezető mérnöke úgy fogalmazta meg, hogy ha a Toyota sikerének igazi titkát akarjuk megfejteni, akkor azt a Toyota termékfejlesztési modelljében (Toyota Product Development System) kell keresni. A Toyota az elmúlt 20 évben két olyan bravúrt produkált, amit autógyár azóta sem tudott felmutatni. Ezek közül az egyik a Lexus márkanév bevezetése. Amikor a "tömegcikk-gyártóként" ismert Toyota luxusmárka tervezésébe kezdett, mindenki borítékolta a kudarcot. Abban az időben a japán autókat az olcsó, eldobható kategóriába sorolta a közvélemény. A Lexus nemcsak, hogy sikeres lett, de évek óta vezeti a luxus-autók piacán az újravásárlási statisztikákat, 90% feletti eredményével (azaz aki egyszer már vett Lexus-t, várhatóan újra azt fog venni). A másik sikertörénet a Toyota Prius nevéhez fűződik. A Toyota Prius az első hybrid-meghajtású (azaz elektromos és benzinmotorral egyaránt felszerelt) tömegtermelésbe vont autó volt. Az autó elképesztően bonyolultnak hatott abban az időben (és még most is) mégis rendkívül sikeres lett. Engem akkor nagyon érdekelt, hogy hogyan lesz képes egy ennyire új megoldás megbízhatóan működni hosszútávon. Nemrég olvastam egy cikket a Totalcar magazninban, ami választ adott a kérdésre: "Amerikában, Kanadában nem ritka a 300 ezer mérföld (480 ezer kilométer) fölött futott kocsi. A szokásos öregedőautós dolgok, futómű, kipufogó, kerékcsapágy előfordulnak, de a hibrid lánc komponenseivel még egyikben sem fordult elő olyan probléma, ami miatt cserélni kellett volna a főegységet. Pedig az eladások már 1,2 millió példányon túl vannak, van miből mintát venni, bőven."

A Toyota Product Development System alakövei

Az Észak-Amerikában működő National Center for Manufacturing Sciences egy több éven át tartó kutatást indított a Toyota termékfejelsztési módszerének megértésére. Az eredményt négy pontban foglalták össze.

Befektetői szemléletű veztő mérnök (System Design by an Entrepreneurial Leader)

A vezető mérnök (Chief Engineer) felel az új típus piaci sikeréért. A vezető mérnök minden esetben egy több évtizedes tapasztalattal bíró mérnök, aki képes mélyen átlátni az autó tervezésének minden fázisát. Ez az ember felel ugyanakkor azért is, hogy a termék piaci célközönségét megfelelően határolják be, és a piaci igényeket jól mérjék fel. A chief engineer olyan mérnökökből lehet, akik bizonyították mérnöki tehetségüket, majd onnan a kereskedelmi és marketing területeken képezték tovább magukat. A vezető mérnök készíti el az új típus vízióját és kommunikálja azt tervező csapat felé. Ezt a víziót folyamatosan életben tartja, kiértékeli a visszacsatolásokat és ha kell változtat rajta. A chief engineer készíti el az új típus fejlesztési ütemtervét és határozza meg a fejlesztési mérföldkövek időpontját, valamint az ezekhez a mérföldkövekhez tartozó döntési kérdéseket. (Pl. az x. mérföldkőnél az autó meghajtásával kapcsolatos tervekkel végezni kell.)

Kiemelkedő mérnöki csapat

A Toyota híres a munkaerőkiválasztási és munkaerőmegtartási kultúrájáról. A hetekben olvastam egy elemzést, amely arról számolt be, hogy egy-egy új mérnök végleges felvételéig akár 1 év is eltekik a Toyotánál. A Toyota tisztában van vele, hogy egy-egy szakmai területen hosszú éveket kell eltölteniük a mérnököknek, hogy valódi mestereivé váljanak a szakmájuknak. Nem számít, ki mennyire tehetséges vezető, egy meghatározott időt mindenképpen el kell töltenie az adott szakmai pozíciókban a vezetővé válás előtt. A mérnöki karrier csúcsa a chief engineer.

Felelősség alapú tervezés és irányítás

A chief enginner állapítja meg a termékfejlesztés ütemtervét és bízza meg az egyes mérnökcsapatok vezetőit a feladattal. A mérnöki csapatok a 2-3 havonta megtartott szinkronizációs időpontokban mutatják be az eredményeiket. Ezekre az időpontokra a konkrétan meghatározott termékjellemzőknek megfelelő megoldásokkal kell önállóan előállniuk. Ha egy-egy csapatnak információra van szüksége a többi csapattól, akkor azt saját hatáskörében kell beszereznie, nem várhat egy "felsőbb" koordináló személyre. A hiányos információk miatti rossz tervekre nincs kifogás...

Konkurens tervezés (Set-Based Concurrent Engineering)

A set-based (halmaz-alapú) megközelítés fogalma onnan ered, hogy nem egy (ponit-based) problémán dolgoznak egyszerre, hanem egymással összefüggő, komplex problémákra keresnek párhuzamosan megoldásokat és folyamatosan szűkítik a lehetséges alternatívák körét. Az egyes alternatívák közül a lehető legkésőbbi időpontban választják ki az alkalmazandó megoldást. Például egy új modell kifejlesztése során a formatervezők azt a feladatot kapják, hogy bizonyos paraméterek mentén készítsék el a lehető legkisebb légellenállású karosszériát. A motor-tervezők ezzel párhuzamosan dolgoznak egy alacsony-fogyasztású erőforrás előállításán. Mindkét csapat több alternatívával áll elő, majd folyamatos iterációkon kersztül összehangolják az előzetes terveiket. Nagy valószínűséggel az első szinkronizációs ponton kiderül, hogy a megálmodott motor nem fér el a kitalált karosszériában, ezért mindkét csapat a megállapodott irányvonalak mentén átdolgozza kezdeti terveit, míg végül ki nem alakul az egész szempontjából optimális megoldás. A set-based tervezés alapja a gyakori, hatékony és rövid kommunikáció az egyes csoportok között.

Lean menedzsment

A Lean szoftverprojekt-menedzsmentet tartom az egyik legizgalmasabb területnek és azt várom, hogy a jövőben ez fogja a legnagyobb hatást gyakorolni a szoftverfejlesztésekhez kapcsolódó menedzsment módszertanokra. A Lean fordítása "karcsú, hajlékony". A Lean menedzsment legismertebb képviselője és sokak szerint a feltalálója is a Toyota. Valójában a lean menedzsment alapjául szolgáló filozófiát W. Edwards Deming fektette le, akit az amerikai hadsereg küldött Japánba a népszámlálás módszertani támogatására. Deming Japánban maradt, ahol menedzsment módszerei sokkal nagyobb befogadókésszséggel találkoztak, mint az USA-ban. A Japán gazdaság eredményei igazolják zsenialitását.

A lean menedzsment hatása a minőségre

Dr Peter Middleton, 2009. Miami Lean & Kanban konferencián tartott "Lean software development:achieving better requirements" c. előadásában találtam egy rendkívül beszédes grafikont a lean termékfejlesztés minőségre és követelménymenedzsmentre gyakorolt hatásáról. A mellékelt grafikon azt mutatja, hogy mennyi változtatást kell bevezetni a Toyota, illetve az átlagos amerikai autógyárak egyes típusaiban a gyártásba állítást követően. Az eredmény meglehetősen jól mutatja, hogy a tradicionális PPP módszerek során alkalmazott előzetes követelményelemzési technikák mennyire elmaradnak a lean termékfejlesztésben alkalmazott konkurens tervezés eredményeitől. (A konkurens tervezés sok tekintetben hasonlít a "Scrum gyökerei" című bejegyzésemben írt módszerhez.)

A Lean adaptív filozófia

A Lean szoftverprojekt-menedzsmentet gyakran sorolják az agilis módszertanok közé, mások külön irányzatnak tartják, mivel a folyamatokra lényegesen nagyobb hangsúlyt fektet a hagyományosan agilisnak nevezett (XP, Scrum) módszereknél. Mindenesetre az nem megkérdőjelezhető, hogy a Lean filozófia is adaptív módszer, hiszen a tanulásra, a kommunikációra a fejlődésre és az emberekre fekteti a hangsúlyt. A téma egyik jelentős forrása Jim Womack és Daniel Jones "Lean Thinking" c. könyve. Womack és Jones a Lean gondolkodás alapelveiként a következőket fogalmazzák meg:

• Azonosítsd a termék valódi értékét (hasznát) a végfelhasználó szempontjából
• Azonosítsd azokat a lépéseket a tevékenységi láncban, melyek ezt az értéket szolgálják. Szabadítsd meg a folyamataidat minden olyan tevékenységtől és szabálytól, melyek nem szolgálják egyértelműen ennek az értéknek az előállítását. Más szóval: szűntesd meg a pazarlást!
• A megmaradt, értékteremtő folyamatokat szervezd egy integrált tevékenységi láncba, melyen keresztül a termékelőállítás folyamata gördülékenyen végighalad a végfelhasználó felé.
• A termelési folyamatot a végfelhasználói igények vezéreljék (pull system). A folyamat akkor induljon be, amikor valós vevői igény jelentkezik. Minden folyamatlépést az azt igénylő folyamat indítson.
• Törekedj a tökéletességre! A világos, igényvezérelt folyamatok legyenek átláthatóak minden résztvevő számára, akik ezáltal gyorsan felismerhetik a potenciális javítási lehetőségeket. Folyamatosan és állandóan javítsd a folyamatot!

Mivel a Lean menedzsment gyökerei a termelési folyamatokhoz kapcsolódnak el kellett telnie egy kis időnek, mire a lean alapelveket használható formában adaptálták egy teljesen más paradigmára, az egyedi szoftverfejlesztésre.

Lean Software Development

A Lean menedzsment nagyon világos, pragmatikus adaptációját tartalmazza a Mary és Tom Poppendieck által írt könyv, a Lean Software Development. A könyv alapját a szerzők azon tapasztalata szolgáltatja, amikor a 3M felvásárolta és Lean menedzsmentre állította át azt a gyárat, ahol Mary Poppendieck fejlesztőként dolgozott. A könyvben a fenti lean alapelveket némileg átstrukturálták és kiegészítették, de az alapfilozófia változatlan maradt. Az alábbiakban sorra veszem az általuk megfogalmazott alapszabályokat.

Szűntesd meg a pazarlást!

A Toyota gyártási rendszerének alapfilozófiája "a veszteség abszolút megszűntetése". Ennek módszere az értéktermelési lánc végletekig történő optimailzálása. A módszer lényege, hogy az értéktermelési láncban a vevői megrendeléstől a termék ellenértékének "begyűjtéséig" minden egyes lépést megvizsgálnak. Azokat a lépéseket, melyek nem adnak értéket ehhez a folyamathoz megszűntetik. A maradék lépések átfutási idejét pedig folyamatosan rövidítik újabb és újabb ötletek bevezetésével. Ennek a filozófiának az alappilére a valódi érték, a tevékenység valós céljának meghatározása. A veszteség két alapvető forrása: 1.) minden olyan tevékenység, ami a vevő számára nem hordoz valódi értéket; 2.) minden olyan lépés, ami a vevő számára az értékhez történő hozzájutást késlelteti.

A szoftverfejlesztés és a gyártás közötti analógiákat keresve a lean szoftverfejlesztés az alábbi tipikus veszteségforrásokat azonosította.

Gyártás	Szoftver fejlesztés
Gyártási raktárkészlet	Befejezetlen funkciók, kód : dokumentáció, ami nem kerül megvalósításra, kód ami nem kerül alkalmazásra, dokumentálátlan kód stb.
Túltermelés	Extra funkciók: minden olyan lefejlesztett, specifikált vagy megtervezet funkció, amit a felhasználók nem használnak a gyakorlatban)
Redundáns feldolgozási lépések (extra processing)	Újratanulás: minden olyan tevékenység, döntés amit már korábban elvégeztünk, de megfeledkeztünk róla.
Szállítás	Mesterséges tudásátadás (handoffs): a gyakorlatban ez a természetes (személyes) kommunikáció helyett készített felesleges dokumentációk gyártása. Az a tevékenység, amikor a fejlesztő csapatot elzárjuk a végfelhasználóktól és közvetítő dokumentációkon keresztül próbáljuk átadni az információkat a számukra.
Mozgatás (azok a tevékenységek, amik megszakítják a folyamatosságot)	Feladatváltás (task switching): a fejlesztői team mozgatása egyik projektről a másikra. A team folyamatos munkavégzésének megszakítása.
Várakozás	Késés, várakozás: a szoftverfejlesztésben a leggyakoribb várakoztatási tényező az üzleti elvárások pontosítása. Ha egy fejlesztő olyan kérdésbe ütközik, ami a rendszer üzleti funkcionalitását befolyásolja, a lehető leggyorsabban biztosítani kell számára a szükséges információt.
Hibák	Hibák: a kódban hagyott hibák továbbgyűrűznek a rendszerben feleslegesen növelve annak komplexitását. A hibalisták kezelése nagy számú hiba estén külön menedzsment eljárásokat igényel, amit össze kell hangolni a fejlesztés többi tevékenységével. Ez feleslegesen növeli a ráfordításokat.

A pazarlás megszűntetése a lean menedzsment talán legfontosabb alapelve.

Vágj bele gyorsan!

A rendszerrel szemben támasztott követelmények nem mérhetőek fel teljeskörűen a fejlesztés korai szakaszában. Bármilyen alapos is a követelményelemzési szakasz, a felhasználói elvárások folyamatosan változni fogak részben a környezet változásának eredményeként, részben a rendszer lehetőségeinek megismerése során. Igazán jó alkalmazás csak akkor készíthető, ha a rendszer fejlesztői átérzik a felhasználói igényeket. A részletes követelményspecifikáció nem alkalmas arra, hogy a rendszerrel kapcsolatos valós elvárásokkal megismertessék a fejlesztőket, ráadásul a külön követelményelemző csapat elzárja a direkt kommunikációtól a megvalósítást végző szakembereket. A jó rendszer végleges felépítése a megvalósítási lehetőségek vizsgálatával, a lehetséges alternatívák szűkítésével, kompromisszumokkal és folyamatos visszacsatolásokon keresztül alakul ki. Ahogy a szerzők írják: "A jó architektúra nem a ráfordított idő, vagy a követelményelemzés részletességének a függvénye, hanem a képzett embereké és a közöttük lévő információáramlásé. A jó rendszert befolyásoló tényezők a szakemberek felkészültsége és az információáramlás hatékonysága."

Tanulj folyamatosan!

A folyamatos tanulás jelentőségét mindenki elismeri és evidenciának tekinti. Kevésbé elfogadott ennek a szabálynak a következménye: a folyamatos tanulás elve ellentétes az előzetes, részletes követelményspecifikáció eszméjével. Miért? Két ok miatt. Először is, ha veszem magamnak a bátorságot, hogy kimondjam: mindent tudok ahhoz, hogy részletesen megtervezzem a jövőt, azzal azt mondom, hogy nincs szükségem tanulásra. Ha nem tudok mindent arról a rendszerről, amit fejleszteni akarok, akkor az erre vonatkozó terveim csak feltételezéseken alapulnak. Amint ezek a feltételezések megváltoznak, az erre alapozott terveim is feleslegesek lesznek. Másodszor, a környezet és az elvárások változnak. Ha ragaszkodni akarok a terveimhez, akkor a változást - és a tanulást - figyelmen kívül kell hagynom, vagy a terveim feleslegesek lesznek. Könnyű félréerteni ezeket a gondolatokat. A tervezés fontos, maguk a tervek viszont csak átmenetiek és ennek megfelelően kell kezelni őket. A tervezés nem más, mint a tanulási folyamat része. Újra és újra végre kell hajtani de csak olyan mélységben, amilyen mélységű információkkal rendelkezünk. Ez az alapelv általánosan igaz mindenre a projektben: azért mert valamit már elkészítettünk egy korábbi, azóta már megváltozott elképzelés alapján, ne féljünk megváltoztatni az új tudásunk birtokában. A tanulás változást jelent, a változás meg tanulást követel.

Várj az elköteleződéssel!

Az elkötelezettség felvállalásának a késleltetése azt jelenti, hogy nyitva hagyjuk magunk számára a választás lehetőségét a kritikus pillanatig. A kritikus pillanat (a szerzők "last responsible moment" kifejezést használják) az az utolsó időpont, ahol a döntés még a mi kezünkben van. A kritikus pillanat után a döntési alternatíváink száma szűkül, és egy számunkra kedvezőtlen alternatíva felé kényszeríthetnek a folyamatok. Ennél a pillanatnál későbbre a döntést nem szabad halogatni. A lean alapfilozófiája ebben a tekintetben az, hogy várjunk a döntéssel addig, amíg feltételezések helyett tények vagy események alapján hozhatjuk azt meg, de a folyamat irányítása még a kezünkben van. A lean gyártási elvek szerinti just-in-time rendszerben a gyártási folyamat akkor indul meg, amikor a megrendelés megérkezett, nem pedig egy bizonytalan keresleti előrejelzés alapján. A túl korai döntés legalább annyi kockázatot hordoz magában, mint a későn meghozott döntés. A döntéshozás késleltetése a lean filozófia "pull system" szabályának a betartása. Ha egy tevékenységet vagy döntést nem kell most elvégezni, akkor ne is tegyük meg, mert semmi nem garantálja, hogy holnap nem jutunk valami olyan információ birtokába, ami alapján egy másik alternatíva jobbnak bizonyulna. Ez egyben a veszteségtermelés elkerülésének egyik legjobb módja. Az adaptív módszertanok egyik kulcsfontosságú eleme éppen ezért a prioritási listák alkalmazása. Azzal foglalkozunk, ami ott és akkor a legfontosabb. (Ennek az elvnek a figyelmen kívül hagyása vezet a tradicionális módszertanok által produkált, több mint 60%-ot kitevő felesleges funkciók fejlesztéséhez.)

Szállítsd le gyorsan!

"A jó munkához idő kell!" így tartja a közmondás. A szoftverfejlesztésben ezzel szemben a rendszeresen gyors átadási képesség minden esetben a jó minőség legjobb jele is. A megbízható és gyors leszállítási képesség nem lehetséges kiemelkedő minőség nélkül. A just-in-time rendszerek kulcsa a vevői igény megjelenésétől a termék leszállításáig eltelt idő minimalizálása. Ha ezt a feltételt nem tudják teljesíteni, a vevők elpártolnak a vállalattól. A just-in-time rendszerben éppen ezért nem fogadhatóak el a hibák. Ha egy korai fázisban készült komponens hibás, az a teljes ráépülő termelési láncot blokkolja. A just-in-time rendszerben működő vállalatok és fejlesztői teamek hatalmas energiákat fordítanak arra, hogy a termelés hibamentes legyen. (Ezt megtehetik, hiszen a részletes tervezésre és előrejelzésre szánt idő jelentős részének megspórolásával bőven marad idejük a termelési lánc minőségének folyamatos javítására.) A szoftverfejlesztési projektben ezt a célt szolgálja a test driven development megközelítés, és a prioritási listák alapján történő inkrementális fejlesztés. A gyors szállítási képesség másik feltétele a pontos és jól szabályozott viselkedés. A gyors leszállításhoz kapcsolódó agilis elvekkel szemben gyakran hozzák fel ellenérvként a tervezetlenséget és az ad-hoc munkavégzést. A valóságban ugyanakkor a jól szervezett adaptív projekt számtalan szigorú normát tartalmaz, melyek az egyes tevékenységekkel szemben támasztott minőségi kritériumokat definiálják. Éppen ez teszi lehetővé, hogy team vezérlése "laza" legyen és a munkát ne fojtsák meg a szigorú irányításhoz szükséges nem értékteremtő tevékenységek. A gyorsan leszállított résztermékek lehetővé teszik az adott teamre és üzleti környezetre jellemző tényadatok gyűjtését, ami végsősoron megalapozott előrejelzések készítésének feltételeit teremti meg. Ez az előrejelzhetőség paradoxona: azáltal, hogy világos szabályok és minőségi elvek mentén hagyjuk a projektet adaptívan futni a hipotéziseken alapuló tervekhez történő ragaszkodás helyett, a gyakorlati tapasztalatok és az iteratív fejlesztés során gyűjtött tényadatok segítségével végülis az előrejelezhetőséget érjük el.

Építsd be a minőséget!

A just-in-time rendszerek jellegükből fakadóan rendkívül érzékenyek a hibákra. Hasonló a helyzet a lean szoftverfejlesztéssel is. Ha a csapat gyorsan akar eredményeket szállítáni, nincs idő hosszú hibajavító tesztelési eljárásokra. Az építsd be a minőséget alapelv lényege a hibák korai felismerése, kivizsgálása és megelőzése. A Toyota sikerét a századforduló környékén az "önleállító" szövőgépek alapozták meg. Ezek a gépek észlelni tudták, ha szövés folyamatába valamilyen hiba csúszott és automatikusan leálltak. Ez lehetővé tette, hogy az akkori japán munkaügyi szabályok mellett, - amely tiltotta a munkások éjszakai foglalkoztatást - a gépeket felügyelet nélkül éjjel is üzemeltethessék. Ezt a tulajdonságot "stop the line" névvel illették és később a Toyota teljes gyártási folyamatában alkalmazták. Bármilyen hiba a gyártósor bármely részén a teljes termelés leállítását eredményezi addig, amíg a hiba okát alaposan ki nem vizsgáltak és meg nem győződtek arról, hogy a későbbiekben nem fog előfordulni. Ez az elv elsőre nagyon kockázatosnak és megdöbbentőnek tűnik, de a konzekvens alkalmazása mellett a hibák száma minimálisra szorítható, a hibajavító eljárások gyakori alkalmazása pedig rutint biztosít, ami végsősoron a gyors hibaelhárításhoz vezet. Ennek az elvnek az alkalmazása szükségtelenné teszi az egyébként jelentős erőforrásokat lekötő "selejt-menedzsmentet". A szoftverfejlesztésben erre analógia a test driven devlopment. A lean szoftverfejlesztés szószólói ennek az elvnek a szélsőséges alkalmazását javasolják, melynek eredményeként akár a teljes issue-tracking rendszer is megszűntethető.

Értékeld az embereket!

A lean filozófia alapja, hogy a terelési folyamatot legjobban ismerő emberektől várhatóak a legjobb ötletek és a leginkább hasznos újítások. A lean menedzsment alapja a motivált és gondolkodó emberi viselkedés elősegítése. A Toyota alapelve, hogy jó terméket csak elkötelezett, felelősségteljes és a szakmájában kiváló szakemberek hozhatnak létre. A szervezet minden szintjén dolgozók megfelelő tiszteletet, autonómiát kapnak és lehetőségük van (mitöbb elvárják tőlük) a tevékenységi folyamataik folyamatos javítására, kísérletezésre. A lean szervezetben a hierarchia nem ugorható át, senki nem kerülhet egyszerűen a szervezet legmagasabb hierarchia szintjeire.

Optimalizáld az egészet!

A lean menedzsment alatt működő szervezetek felismerték, hogy a komplex rendszer nem írható le annak dekomponált részeinek együttesével, más szóval az egész nem ugyanaz, mint a részek összege, hanem valami annál több. Az egyes résztevékenységek önálló mérőszámok szerint történő mérése és ezek szerinti optimalizálása a teljes rendszer szuboptimális működéséhez vezetnek. A lean szervezetben minden tevékenységet a teljes "megrendeléstől a pénz begyűjtéséig" értéklánc egészére gyakorolt hatása szerint vizsgálnak. Mary Poppendieck egy érdekes ellenpéldát hozott fel könyvében: a gyártási láncban volt egy rendkívül drága berendezés, melynek az élettartama rövid volt. A dekompozíción alapuló optimalizáció alapján az tűnt logikusnak, hogy ezt a gépet a lehető legnagyobb kihasználtsággal kell üzemeltetni, hiszen a rövid élettartam alatt az egy termékre jutó költség akkor lesz alacsony, ha adott időszakban a legtöbb alkatrészt gyártja le. Ennek eredményeként hatalmas alapanyagkészleteket halmoztak fel (hogy véletlenül se hátráltassa a gyártást az alapanyaghiány), illetve a nagy kibocsátás miatt nagy kimeneti raktárra is szükség volt. Ennek eredményeként a lokális optimalizálás "ellenére" a teljes termelési láncban a gyártási költség magasra szökött.

Az egész folyamat optimalizációjára való törekvés a lean szervezetek partnerkapcsolataiban is megmutatkozik. Amikor a Fujitsu 2001-ben átvette a British Midland Airways (BMI) helpdesk rendszerének üzemeltetését, rövid időn belül felismerte, hogy a bejelentések 26%-át a check-in pultoknál lévő nyomtatók hibája okozta. A Fujitsu javaslatot tett új nyomtatók üzembe állítására, valamint további fejlesztési ötletekkel rukkolt elő. A fejlesztések eredményeként a hibabejelentések száma rövid időn belül 40%-kal csökkent. Ebben a történetben az az érdekes, hogy az eredeti help-desk szerződés alapján az üzemeltetőt a bejelentett és elhárított incidensek alapján fizették, tehát elvileg nem állt volna érdekében ez az optimalizálás. Az eredmények hatására a BMI és a Fujitsu módosította az üzemeltetési szerződést, aminek eredményeként mindkét cég a vártnál jobb feltételekhez jutott és ami a legfontosabb, sikerült fenntartaniuk a közös érdekeken alapuló optimalizációs folyamatot. Ennek az alapelvnek az ösztönzési rendszerre vonatkoztatva is messzemenő hatásai vannak. Az érdekeltségi rendszerek lehető legegyszerűbb elveken történő meghatározása szintés egy jellemző lean módszer.