2009. június 29., hétfő

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ásSzoftver fejlesztés
Gyártási raktárkészletBefejezetlen 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ésExtra 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ásKé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ákHibá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.

Nincsenek megjegyzések: