Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles:
- Eliminate waste
- Amplify learning
- Decide as late as possible
- Deliver as fast as possible
- Empower the team
- Build integrity in
- Optimize the whole
Eliminate wasteEdit
Lean philosophy regards everything not adding value to the customer as waste (muda). Such waste may include:
- Partially done work
- Extra features
- Relearning
- Task switching
- Waiting
- Handoffs
- Defects
- Management activities
In order to eliminate waste, one should be able to recognize it. If some activity could be bypassed or the result could be achieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Az olyan extra funkciók, mint a papírmunka és az ügyfelek által nem gyakran használt funkciók pazarlásnak számítanak. Az emberek váltogatása a feladatok között pazarlás. Más tevékenységekre, csapatokra, folyamatokra való várakozás pazarlás. A munka elvégzéséhez szükséges újratanulás pazarlás. A hibák és az alacsonyabb minőség pazarlás. A valódi értéket nem termelő menedzseri rezsi pazarlás.
A pazarlás azonosítására értékáram-térképezési technikát használnak. A második lépés a pazarlás forrásainak kiemelése és megszüntetése. A pazarlás megszüntetésének iteratív módon kell történnie, amíg még a látszólag lényeges folyamatok és eljárások is felszámolásra kerülnek.
A tanulás felerősítéseSzerkesztés
A szoftverfejlesztés egy folyamatos tanulási folyamat, amely a kódírás során iterációkon alapul. A szoftvertervezés egy problémamegoldó folyamat, amelyben a kódot író fejlesztők és az általuk tanultak is részt vesznek. A szoftver értékét a használatra való alkalmasságban és nem a követelményeknek való megfelelésben mérik.
Ahelyett, hogy több dokumentációt vagy részletesebb tervezést kellene hozzáadni, különböző ötleteket lehetne kipróbálni a kód írásával és az építéssel. A felhasználói követelmények összegyűjtésének folyamata egyszerűsíthető lenne a képernyők végfelhasználóknak való bemutatásával és az ő hozzájárulásuk megszerzésével. A hibák felhalmozódását a tesztek futtatásával kell megelőzni, amint a kód megírásra került.
A tanulási folyamatot rövid iterációs ciklusok alkalmazása gyorsítja fel – mindegyik refaktorálással és integrációs teszteléssel párosul. A visszajelzések növelése az ügyfelekkel folytatott rövid visszajelző üléseken keresztül segít a fejlesztés jelenlegi fázisának meghatározásában és a jövőbeli fejlesztésekre irányuló erőfeszítések kiigazításában. E rövid ülések során mind az ügyfelek képviselői, mind a fejlesztőcsapat többet tudnak meg a domain-problémáról, és kitalálják a további fejlesztés lehetséges megoldásait. Így az ügyfelek a fejlesztési erőfeszítések eddigi eredménye alapján jobban megértik igényeiket, a fejlesztők pedig megtanulják, hogyan lehet ezeket az igényeket jobban kielégíteni. Az ügyféllel folytatott kommunikációs és tanulási folyamat egy másik ötlete a halmazalapú fejlesztés – ez a jövőbeli megoldás korlátainak és nem a lehetséges megoldásoknak a közlésére összpontosít, így az ügyféllel folytatott párbeszéd révén elősegíti a megoldás megszületését.
Döntsünk minél később Szerkesztés
Mivel a szoftverfejlesztés mindig bizonyos bizonytalansággal jár, jobb eredményeket kell elérni a halmazalapú vagy opcióalapú megközelítéssel, minél későbbre halasztva a döntéseket, amíg azokat tények, és nem bizonytalan feltételezések és előrejelzések alapján lehet meghozni. Minél összetettebb egy rendszer, annál több változtatási kapacitást kell beépíteni, ami lehetővé teszi a fontos és döntő fontosságú kötelezettségvállalások késleltetését. Az iteratív megközelítés elősegíti ezt az elvet – a változásokhoz való alkalmazkodás és a hibák kijavításának képességét, amelyek nagyon költségesek lehetnek, ha a rendszer kiadása után derülnek ki.
A halmazalapú fejlesztéssel: Ha például egy autóhoz új fékrendszerre van szükség, három csapat is tervezhet megoldást ugyanarra a problémára. Minden csapat megismeri a problématérséget, és megtervez egy lehetséges megoldást. Ha egy megoldást ésszerűtlennek ítélnek, azt kivágják. Egy időszak végén a megmaradt terveket összehasonlítják, és kiválasztanak egyet, esetleg némi módosítással a többiektől szerzett tapasztalatok alapján – ez remek példa arra, hogy az elkötelezettséget az utolsó pillanatig elhalasztják. A szoftverdöntéseknél is hasznát vehetnénk ennek a gyakorlatnak, hogy minimalizáljuk a nagy előzetes tervezésből adódó kockázatot. Ráadásul ekkor több olyan megvalósítás is létezne, amelyek megfelelően működnek, de mégis különböznek egymástól (megvalósítás szempontjából, belsőleg). Ezeket olyan hibatűrő rendszerek megvalósítására lehetne használni, amelyek a többféle megvalósításban egyszerre ellenőrzik az összes bemenet és kimenet helyességét.
Az agilis szoftverfejlesztési megközelítés előbbre hozhatja az ügyfelek számára a lehetőségek kiépítését, és így bizonyos döntő fontosságú döntéseket addig késleltethet, amíg az ügyfelek jobban fel nem ismerik igényeiket. Ez lehetővé teszi a változásokhoz való későbbi alkalmazkodást is, és a költséges, korábbi, technológiához kötött döntések megelőzését. Ez nem jelenti azt, hogy nem szabad tervezni – éppen ellenkezőleg, a tervezési tevékenységeknek a különböző lehetőségekre és az aktuális helyzethez való alkalmazkodásra, valamint a zavaros helyzetek tisztázására kell összpontosítaniuk a gyors cselekvés mintáinak kialakításával. A különböző lehetőségek kiértékelése akkor hatékony, ha felismerjük, hogy azok nem ingyenesek, de biztosítják a késői döntéshozatalhoz szükséges rugalmasságot.
A lehető leggyorsabban szállítsuk le a terméket
A gyors technológiai fejlődés korában nem a legnagyobb, hanem a leggyorsabb marad életben. Minél hamarabb leszállítják a végterméket nagyobb hibák nélkül, annál hamarabb lehet visszajelzést kapni, és beépíteni a következő iterációba. Minél rövidebbek az iterációk, annál jobb a tanulás és a kommunikáció a csapaton belül. A gyorsasággal a döntések késleltethetők. A gyorsaság biztosítja az ügyfél jelenlegi igényeinek kielégítését, és nem azt, amit tegnap kért. Ez lehetőséget ad arra, hogy elhalasszák a döntést arról, hogy valójában mire van szükségük, amíg jobb ismeretekre tesznek szert. Az ügyfelek értékelik a minőségi termék gyors szállítását.
A just-in-time termelés ideológiája alkalmazható a szoftverfejlesztésre, felismerve annak sajátos követelményeit és környezetét. Ez úgy érhető el, hogy bemutatjuk a szükséges eredményt, és hagyjuk, hogy a csapat megszervezze magát és felossza a feladatokat a szükséges eredmény eléréséhez egy adott iterációra. Az elején az ügyfél biztosítja a szükséges inputot. Ezt egyszerűen kis kártyákban vagy történetekben lehet bemutatni – a fejlesztők megbecsülik az egyes kártyák megvalósításához szükséges időt. Így a munkaszervezés önhúzó rendszerré alakul át – minden reggel egy stand-up megbeszélés során a csapat minden tagja áttekinti, hogy mit végeztek tegnap, mit kell ma és holnap elvégezni, és megkérdezi a kollégáktól vagy az ügyféltől a szükséges inputokat. Ez megköveteli a folyamat átláthatóságát, ami a csapatkommunikáció szempontjából is előnyös.
Az alapelv mögött meghúzódó mítosz: a sietség pazarlással jár. A lean bevezetése azonban biztosította, hogy jó gyakorlat a gyors teljesítés, hogy a kimenetet a lehető legkorábban láthassuk és elemezhessük.
Felhatalmazza a csapatotSzerkesztés
A legtöbb vállalkozásban hagyományos hiedelem a szervezeten belüli döntéshozatalról – a vezetők mondják meg a dolgozóknak, hogyan végezzék a saját munkájukat. A kidolgozási technikában a szerepek megfordulnak – a vezetőket megtanítják arra, hogyan hallgassák meg a fejlesztőket, hogy jobban el tudják magyarázni, milyen intézkedéseket lehetne tenni, valamint javaslatokat tudjanak tenni a fejlesztésekre. A lean megközelítés az agilis alapelvet követi: “építsd a projekteket motivált egyének köré, és bízz bennük, hogy elvégzik a munkát”, ösztönözve a fejlődést, elkapva a hibákat és eltávolítva az akadályokat, de nem mikro-menedzselve.
A másik tévhit az volt, hogy az embereket erőforrásnak tekintik. Lehet, hogy az emberek egy statisztikai adatlap szempontjából erőforrások, de a szoftverfejlesztésben, valamint bármely szervezeti vállalkozásban az embereknek többre van szükségük, mint a feladatok listájára és arra a biztosítékra, hogy a feladatok elvégzése közben nem zavarják őket. Az embereknek motivációra és egy magasabb célra van szükségük, amiért dolgozhatnak – egy elérhető valóságon belüli célra, azzal a biztosítékkal, hogy a csapat maga választhatja meg a vállalásait. A fejlesztőknek hozzáférést kell biztosítani a megrendelőhöz; a csapatvezetőnek támogatást és segítséget kell nyújtania a nehéz helyzetekben, valamint gondoskodnia kell arról, hogy a szkepticizmus ne tegye tönkre a csapat szellemét. Az emberek tisztelete és munkájuk elismerése a csapat felhatalmazásának egyik módja.
Építsünk integritást azEditben
Az ügyfélnek átfogó élményt kell szereznie a rendszerről. Ez az úgynevezett érzékelt integritás: hogyan hirdetik, szállítják, telepítik, hozzáférhetővé teszik, mennyire intuitív a használata, az ára és mennyire jól oldja meg a problémákat.
Az érzékelt integritás azt jelenti, hogy a rendszer különálló összetevői jól működnek együtt, a rugalmasság, a karbantarthatóság, a hatékonyság és a válaszkészség egyensúlyával. Ezt úgy lehet elérni, ha a problématerületet egyszerre értjük meg és oldjuk meg, nem pedig egymás után. A szükséges információkat kis tételes darabokban kapjuk meg – nem pedig egy hatalmas csomóban – lehetőleg személyes kommunikációval és nem írásos dokumentációval. Az információáramlásnak állandónak kell lennie mindkét irányban – az ügyféltől a fejlesztőkhöz és vissza -, így elkerülhető a hosszú elszigetelt fejlesztés utáni nagy, stresszes információmennyiség.
Az integrális architektúra felé vezető egyik egészséges út a refaktorálás. Minél több funkciót adunk hozzá az eredeti kódbázishoz, annál nehezebbé válik a további fejlesztések hozzáadása. A refaktorálás az egyszerűség, az áttekinthetőség, a funkciók minimális számának megtartásáról szól a kódban. A kódban lévő ismétlődések a rossz kódtervezés jelei, és el kell kerülni őket. A teljes és automatizált építési folyamatot a fejlesztői és ügyféltesztek teljes és automatizált csomagjának kell kísérnie, amely a rendszer jelenlegi állapotával azonos verziószámmal, szinkronizációval és szemantikával rendelkezik. A végén az integritást alapos teszteléssel kell ellenőrizni, így biztosítva, hogy a rendszer azt csinálja, amit az ügyfél elvár tőle. Az automatizált tesztek is a gyártási folyamat részének tekintendők, ezért ha nem teremtenek hozzáadott értéket, akkor hulladéknak tekintendők. Az automatizált tesztelésnek nem célnak, hanem inkább eszköznek kell lennie egy cél eléréséhez, konkrétan a hibák csökkentéséhez.
Optimalizálja az egészet
A modern szoftverrendszerek nem egyszerűen részeik összege, hanem kölcsönhatásaik termékei is. A szoftverekben a hibák a fejlesztési folyamat során hajlamosak felhalmozódni – a nagy feladatok kisebb feladatokra bontásával és a fejlesztés különböző szakaszainak szabványosításával a hibák kiváltó okait meg kell találni és meg kell szüntetni. Minél nagyobb a rendszer, minél több szervezet vesz részt a fejlesztésében, és minél több részegységet fejlesztenek különböző csapatok, annál fontosabb, hogy a különböző szállítók között jól meghatározott kapcsolatok legyenek, hogy zökkenőmentesen együttműködő komponensekből álló rendszer jöjjön létre. A fejlesztés hosszabb időtartama alatt egy erősebb alvállalkozói hálózat sokkal előnyösebb, mint a rövid távú profitoptimalizálás, amely nem teszi lehetővé a win-win kapcsolatokat.”
A lean gondolkodást a projekt minden tagjának jól meg kell értenie, mielőtt konkrét, valós helyzetben megvalósítaná. “Think big, act small, fail fast; learn rapidly” – ezek a szlogenek összefoglalják a terület megértésének fontosságát és a lean elvek megvalósításának alkalmasságát a teljes szoftverfejlesztési folyamat mentén. Csak akkor van alapja a szoftverfejlesztés sikerének, ha az összes lean elv együttesen, a munkakörnyezetre vonatkozó erős “józan ésszel” kombinálva valósul meg.