A lean menedzsment alapvetően a gyártási folyamatok irányításának a filozófiája. Az egyedi szoftverfejlesztés azonban csak részben termelés, legalább ennyire hangsúlyos a termékfejlesztési irányultság. A legismertebb és mára leginkább elterjedt egyedi szoftverfejlesztésekhez alkalmazott menedzsment keretrendszer a Scrum. Kevésbé nyílt is ismert, de alapelveiben nagyon hasonló megközelítést képvisel a Toyota termékfejlesztési módszertana, a TPDS (Toyota Product Development System).
A két termékfejlesztési módszer háttereinek részletesebb ismertetése
ezekben a cikkekben található. A módszer gyakorlati alkalmazásáról
István bővebben is ír a blogján.
A Scrum háttere
A Scrum gyökereit két japán kutató, Ikujiro Nonaka és Hirotaka Takeuchi fektette le a „The new new product development game” c. publikációjában. A kutatásuk középpontjában az a kérdés állt, hogy hogyan képes néhány vállalat az iparági átlagot magasan meghaladó színvonalon végrehajtani termékfejlesztési projektjeit. A Scrum tehát nem egy elméleti menedzsment modell, hanem a termékfejlesztésben sikeres vállalatok gyakorlatát összegző kutatás eredménye.
A tanulmány egyik legfontosabb megállapítása, hogy a hatékony termékfejlesztést megvalósító vállalatok nem a vízesés – másnéven fázisolt PPP (Phased Product Planning) – menedzsment módszert követik, hanem egyfajta iteratív megközelítést alkalmaznak, melynek során a termék számos jellemzőjét nyitva hagyják egészen a fejlesztés végéig. Ez nagyban különbözik azoktól a tradicionális megközelítésektől, melyek során a lehető legpontosabb specifikációra törekednek már a tervezés megkezdése előtt. A Scrum modellben fejlesztő vállalatok a kialakítandó termék néhány legfontosabb jellemzőjét fektetik le, a részletekre vonatkozó döntéseket a fejlesztői csapatra bízzák.
Takeuchi és Nonaka felismerése szerint lényegesen hatékonyabb, ha a vízesés modellnél alkalmazott funkcionális csoportszervezés (pl. külön marketing, tervező és megvalósító csoport) helyett keresztfunkcionális, termékorientált csoportokat hoznak létre, melyben minden szakterület képviselteti magát. Egy Scrum csapatnak ugyanolyan szereplője a vevői elvárásokat kutató marketing szakember, mint a termék műszaki tervezéséért felelős mérnök, vagy a majdani gyártási folyamatot megtervező gyártásszervező. Ez a szemlélet teszi lehetővé, hogy a termékjellemzőket úgy alakítsák ki, hogy azok a termék teljes életciklusát figyelembe véve optimálisak legyenek. A termékjellemzők különböző szempontjait a fejlesztési időszakban ütköztetik és hozzák meg a szükséges kompromisszumokat, illetve egy-egy felfedezés vagy ötlet eredményét bármely szempontba képesek visszavezetni. A Toyota Prius fejlesztésénél például a fejlesztés nagyon késői szakaszában hozták meg azt a döntést, hogy az autó hibrid hajtásának akkumulátorait nem a motortérben, hanem hátul a csomagtér alatt helyezik el, mivel a motor melletti nagy hőmérsékletingadozást az akkumulátorok nem viselnék el. Ez a döntés az autó számos jellemzőjét (csomagtér, aerodinamika, hajtáslánc stb.) befolyásolta. A projekt elején nem volt még világos, hogy milyen akkumulátorok bizonyulnak majd optimálisnak, ezért a döntéssel számos kísérletet kellett megvárni. Egy ilyen horderejű döntés halogatása nem lett volna kivitelezhető, ha a csoport nem képes rövid idő alatt, saját hatáskörben elemzni annak következményeit (pl. a rövidebb motortérből adódó jobb városi manőverezési képességek, vagy a nagyobb csomagtér jelent több előnyt?). A Scrum jellemzője tehát a magas fokú döntési önállóságot élvező termékfejlesztési csoport.
Mivel a csoport nem előre meghatározott termékjellemzők és tervek szerint állítja elő a terméket, ezért szükség van olyan mechanizmusokra, melyek világosan megmutatják, hogy a projekt elfogadható mederben halad-e. Ennek megvalósításához a Scrum csapatok egyértelmű, vizuális mérési rendszereket alkalmaznak, melyeken bárki, első ránézésre láthatja a projekt előrehaladását, illetve segíti a csapattagokat abban, hogy könnyen felismerjék a projekt előmozdításához legfontosabb végrehajtandó feladatokat.
Scrum projekt bontás
A Scrum projektben megvalósítandó termék funkcióinak, valamint a projektben elvégzendő legfontosabb feladatoknak a listáját a product backlog tartalmazza. Fontos, hogy a product backlog elemeihez mindenképpen prioritások vannak rendelve, melyek egyben a feladatok elvégzésének sorrendjét is jelentik.
A projekt megvalósítását a team sprintekbe szervezve végzi, melyek azonos időtartamú végrehajtási egységek. A team minden sprint megkezdése előtt elvégzi a sprint-tervezést, melynek során a product backlog legmagasabb prioritású feladatai közül kiválasztja, illetve szükség esetén tovább bontja azokat a feladatokat, amelyeket a következő „nekifutásra” képes megvalósítani. Az adott sprintre vonatkozó feladatok listáját a sprint backlog tartalmazza. Minden sprint végeredménye egy tesztelt és elméletileg átadható funkció.
A sprintek során a team működése szempontjából kiemelkedő fontosságú az intenzív és hatékony kommunikáció. Ezt segíti a minden nap megtartandó stand-up meeting, ahol a team tagjai „szinkronizálják” feladataikat, valamint a korábban már említett vizuális menedzsment eszközök használata.
Vizuális menedzsment eszközök
A vizuális projektirányítási eszközökkel szembeni legfontosabb elvárás a gyors „leolvashatóság” és az egyértelműség. A Scrum napi tevékenységeiben a két legjelentősebb ilyen eszköz a team board és a burn-down chart.
Team board
A team board a csapat által az adott sprintben végrehajtandó feladatokat és azok aktuális státuszát tartalmazza.
A feladatokat egy-egy „cetli”, más néven kanban jelöli. (A kanban a japán „vezérlő-kártya” szóból származik.) A kanban kártyákon szereplő információk csapatról csapatra változhatnak, de minimálisan a feladat nevét és a feladat becsült méretét tartalmazzák. A feladatok méretének becsléséhez többféle módszer használatos, de a méret kifejezésére általában story-pont elnevezést használják. A lényeg, hogy a feladatok méretének meghatározásához használt skála nagyjából állandó legyen, azaz egy adott csapat minden egyes sprintben összesen közel azonos story-pont értékű feladat megvalósítására legyen képes.
A csapat minden nap megtartja a stand-up összejövetelt, ahol a csapattagok a kanban kártyák mozgatásával jelzik, ha egy feladat végrehajtását megkezdték vagy éppen befejezték. Ez a mechanizmus biztosítja, hogy mindenki lássa, hogy melyek azok a feladatok, melyek végrehajtásához erőforrásra van szükség. A team-board tehát a csapat kommunikációs felülete.
Burn-down chart
A team board biztosítja, hogy a csapat tagjai világosan lássák az egyes feladatok státuszát, illetve, hogy a csapat számára teljes listát adjon az összes elvégzendő feladatról.
A sprint sikerességének méréséhet viszont a team board nem rendelkezik az összes szükséges jellemzővel, mivel nem olvasható le róla azonnal, hogy a tervekhez képesti előrehaladás megfelelő-e.
A sprint tervhez viszonyított haldását mutatja a „burn-down chart”. A grafikon függőleges tengelye mutatja a sprintbe tervezett feladatok mennyiségét story-pontban. A vízszintes tengely az időt jelzi. A szaggatott vonal a sprint ideális, terv szerinti lefutását mutatja.
A csapat minden stand-up összejövetel végén behúzza az adott napon megvalósított feladatok összesített story-pont értékét a grafikonon. (Folytonos, piros vonal.) A piros vonal gyakorlatilag a sprint során még megvalósítandó feladatok összes értékét mutatja. A gyakorlatban a vonal fölfelé is mozdulhat, ha például kiderül, hogy egy feladat lényegesen komplexebb annál, mint ahogy a csapat a tervezéskor gondolta.
A 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ó.
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 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.
Sokkal izgalmasabb a megrendelői elvárásokat elemezni. 
Azok ugyanis a projekt hatókörén belül helyezkednek el. A megrendelő végsősoron dönthet arról, hogy ragaszkodik az adott elvárásához, vagy sem. Itt szándékosan az elvárás szót használom. A követelmények ugyanis az elvárásokból származnak. A követelmény kifejezés azt sugalja, hogy valami statikus dologról van szó, amit csak rögzíteni kell és onnantól ismerjük. Éppen ez a probléma vele! A megrendelőt ugyanis nem érdeklik a követelmények. A megrendelőnek elvárásai vannak, amiknek megfelelő rendszert akar látni. Az üzleti megrendelő szemében a követelmény csak egy szükséges rossz, amibe az előzetes követelményspecifikáción alapuló fejlesztési kultúra belekényszeríti a tervezhetőség látszatának fenntartása érdekében. A valós igények az elvárásokban bújnak meg. Az elvárások pedig a megismerés során folyamatosan változnak. Az elkészítendő rendszerrel kapcsolatos ismeretek bővülése pedig folyamatos. Az elemzési, tervezési szakaszban nemcsak a fejlesztők, de az üzleti megrendelők is folyamatosan formálják a fejlesztendő rendszerről kialakított képüket. A vízesés modellben alkalmazott követelménykezelési módszerek problémája tehát nem abban rejlik, hogy hibásan alkalmazzuk őket, hanem abban, hogy eredendően téves elképzelésből indulnak ki. Az elvárások ugyanis természetüknél fogva többnyire nem statikusak, tehát nem is rögzíthetők. A megoldás tehát nem az, hogy egyre komplexebb követelményelemzési és dokumentációs technikákat dolgozunk ki hanem az, hogy megtanuljuk követni a az elvárások változását. A hatékony elváráskezeléshez vezető legjobb út az, ha pontosan megértjük a fejlesztendő rendszer célját és üzleti környezetét. Ekkor az energiánkat nem a követelmények rögzítésére, hanem a problémák megoldására fókuszálhatjuk. A követelmények komplex rögzítésére és dokumentálására fordított energia nagy részét hasznosabb lenne olyan tevékenységekre fordítani, melyek során a fejlesztő csapat megértheti a megrendelői elvárásokat és az azok megött meghúzódó okokat. A jó rendszer elkészítéséhez a fejlesztő teamnek mindenképpen meg kell ismernie a megrendelő üzleti környezetét, ha rögzítjük a követelményeket, ha nem.
Szintén érdekes tanulsággal szolgál a Toyotánál alkalmazott követelménykezelési módszer. A Toyotánál alapszabály, hogy minden elvárásrendszernek el kell férnie egy A3-as oldalon. A Toyota Prius fejlesztésébe a Toyota hatalmas összegeket fektetett be úgy, hogy az autóval szembeni elvárásokat mindössze 5 pontban foglalták össze (relatív tágas belső tér; magas üléspozíció; jó aerodinamika; 20km/liter fogyasztás; kicsi, horizontálisan elhelyezett motor fokozatmentes automata váltóval). A követelmények gyűjtése helyett a prototípusok előállítására és tesztelésére helyezték a hangsúlyt. A gyakorlati megvalósítással szemben semmilyen megkötést nem alkalmaztak. A hybrid hajtás például a projekt során kialakított megvalósítási döntés volt, sehol nem szerepelt az eredeti elvárásokban. Érdemes elgondolkodni azon, hogy a világ legnagyobb és legnyereségesebb autógyára miért ezeket a módszereket alkalamzza? Ha jobban belegondolunk, egy új típus fejlesztése egy ugyanolyan kockázatos befektetés, mint egy új szoftver kifejlesztése. Ha a Toyota felismerte, hogy fölösleges előzetesen "agyonspecifikálni" a terméket, akkor miért ne tehetnénk mi is ugyanezt?
A scrum neve a rugby játékból jön. A rugbyben a különböző posztokon játszó játékosok egy csapatban szorosan együttműködve juttatják el a labdát a célig. Ennek a módszernek két jellemzője van: 1.) különböző szerepek dolgoznak szorosan együttműködve egyidőben 2.) a labda nem egyenesen a cél felé halad, hanem néha visszajátszák egymásnak a játékosok, új pozíciót keresnek, és innen indulnak meg újra a cél felé.
melynek során folyamatosan szűkítik a megvalósítható alternatívák körét. A szerzők kétirányú tanulási folyamatot azonosítottak: a többszintű (multi level) és a multifunkcionális (multifunctional) irányokat. A többszintű (multilevel) tanulási irány lényege, hogy egyéni és szervezeti szinten is elvárják a projektben résztvevőktól a fejlődést. A 3M-nél például a tervező mérnökök idejének 15%-át saját maguk által választott témákban történő tanulásra tartják fenn. A Honda City projektjének teljes termékfejlesztő csapatát Európába küldték 3 hétre, hogy gyűjtsenek ötleteket az Európai piacról. A multifunkcionális tanulási irány arra koncentrál, hogy a projektben résztvevő, különböző szakterületekről érkező szakemberek fejlesszék saját tudásukat a többi szakterületi irányba, hogy egy közös nyelvet és problémamegértést alakítsanak ki. Az Epson első minatűr nyomtatójának projekttagjai döntően mechanikai mérnökök voltak, és hiányzott az elektronikai tudás. A projekt vezető mérnöke 2 évig tanulta a villamosmérnöki területet, miközben a projekt futott. A projekt zárásakor az összes résztvevő mechanikai mérnök releváns villamosmérnöki ismeretekkel rendelkezett.
A személyes időmenedzsment módszerek közül talán a legsikeresebb a feladatok fontosság-sürgősség szerinti osztályozásán alapuló. A rendszer kialakításához az a felismerés vezetett, hogy bármilyen hatékonyan is végezzük el feladatainkat, előbb vagy utóbb bekövetkezik az a pont, ahol a feladatok száma meghaladja a rendelkezésünkre álló időkeretet. Ha hatékonyabban dolgozunk, akkor ez az állapot kicsit később következik be, ha kevésbé hatékonyan, akkor hamarabb. A feladatok elvégzésének gyorsasága másodlagos, a lényeg az, hogy megfelelően válasszuk ki, hogy mire fordítjuk az időnket. A feladatainkat egy fontosság és egy sürgősség tengely mentén kialakított mátrixban helyezzük el. A fontos dolgaink a mátrix felső sávjában kapnak helyet. A módszer központi eleme a világos célmeghatározás, és értékrend kialakítás. Azok a feladatok tekintendők fontosnak, amelyek közvetlenül hozzájárulnak ahhoz, hogy céljainkat elérjük. Miután egy ideje alkalmaztam ezt az időszervezési rendszert rájöttem, hogy a megközelítés ugyanúgy alkalmas egy projekt team erőforrásgazdálkodásának menedzselésére, mint a személyes időgazdálkodásra. Mi a célja egy fejlesztési projektnek? A valós igényeket kielégítő, működő szoftver! Nézzük meg ebből a szempontból, hogy mik jellemzik a mátrix egyes negyedeit:
Ebbe a kategóriába tartoznak azok a feladataink, amiket mindenképpen el kell végeznünk, viszont a rendelkezésünkre álló idő szűkös. Az ebben a negyedben eltöltött idő okozza a legtöbb stresszt, és vezet a legtöbb hibához. A fejlesztési projektben tipikusan ilyen a rendszer átadását megelőző időszak, ahol számos ismert hibát kell kijavítani, véglegesíteni kell a rendszerhez kapcsolódó üzemeltetési és felhasználói dokumentációkat stb. Világos, hogy a feladatok fontosak, viszont reménytelenül kevésnek látszik a rendelkezésre álló idő.
Ez a leghasznosabb időtöltés. Ebben a negyedben végezzük el azokat a feladatokat, melyek a projektet ténylegesen előremozdítják, javítanak a termék minőségén. Itt termelünk a leghatékonyabban valódi értéket. A fejlesztési projektben ez az az időszak, amikor hagyjuk a csapatot dolgozni, kreatívan gondolkodni, amikor lehetőséget adunk a fejlődésre és a kísérletezésre. Ide tartozik az az idő, amikor a fejlesztő csapat lehetőséget kap arra, hogy megértse a rendszer valós üzleti környezetét. Ebben a negyedben végezzük a tervezést és a feladatok priorizálását is.
Ez a legalattomosabb negyed. A személyes hatékonyságot vizsgáló felmérések azt mutatták ki, hogy a vezetők az idejük 30-50%-át ilyen tevékenységekkel töltik. Az alattomosságát az okozza, hogy a sürgető határidők a fontosság érzetét keltik. Az ebbe a negyedbe tartozó tevékenységek veszik el az időt a tényleges értékteremtésről, mivel állandóan nyomás alatt tartják az embereket. Tipikus képviselői a megszakításokból adódó feladatok. A fejlesztési projektekre vetítve ilyen az emberek projektek közötti mozgatása, a gyenge menedzsment által azonnali határidőre igényelt státusz jelentések és demók. 
Ezek azok a tevékenységek, melyek alig járulnak hozzá a projekt sikeréhez. Legtipikusabb képviselőjük a túlhízlalt dokumentációk és a soha le nem fejlesztett, de részletesen specifikált követelmények és rendszerfunkciók. Az operatív menedzsment területén ilyenek a túl nagy körben megrartott, nem előkészített megbeszélések, elhúzódó státusz egyeztetések, vagy a gyenge menedzsment bizonytalanságát enyhítendő időelszámoltatások. Szintén jellemző pazarlási forrás a nem kellően átgondolt módosítási igények átvezettetése a rendszerben. Amik később újra megváltoznak... végül soha senki nem használja... 
Egy fejlesztési projekt elindítása előtt a legfontosabb feladat a valós üzleti cél meghatározása. Ez meglehetősen triviálisnak hangzik, ugyanakkor igen ritkán lehet találkozni világos célmeghatározásokkal. A tapasztalatom az, hogy az üzleti megrendelők sokkal több időt fordítanak a követelmények definiálására, mint a projekt céljainak meghatározására. Ez a projekt elején nem tűnik túl nagy problémának, viszont a megvalósítás során, amikor az összegyűjtött követelmények kielégítéséhez szükséges ráfordítások láthatóan messze meghaladják a rendelkezésre álló kereteket, valami alapján priorizálni kell. Ekkor jönne jól világosan látni a célokat. A projekt indítását minden esetben egy világos víziónak kellene megelőznie. A vízió kialakításához nyújtanak segítséget a következő kérdések.
