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. Funkce navíc, jako je papírování a funkce, které zákazníci často nevyužívají, jsou plýtváním. Přepínání lidí mezi úkoly je plýtvání. Čekání na jiné činnosti, týmy, procesy je plýtvání. Opětovné učení nutné k dokončení práce je plýtvání. Vady a nižší kvalita jsou plýtváním. Manažerská režie, která nepřináší skutečnou hodnotu, je plýtvání.
K identifikaci plýtvání se používá technika mapování hodnotových toků. Druhým krokem je poukázání na zdroje plýtvání a jejich odstranění. Odstraňování plýtvání by mělo probíhat iterativně, dokud nebudou zlikvidovány i zdánlivě zásadní procesy a postupy.
Zesílení učeníEdit
Vývoj softwaru je neustálý proces učení založený na iteracích při psaní kódu. Návrh softwaru je proces řešení problémů, na kterém se podílejí vývojáři píšící kód a to, co se naučili. Hodnota softwaru se měří vhodností pro použití, nikoliv shodou s požadavky.
Místo přidávání další dokumentace nebo podrobného plánování by se mohly zkoušet různé nápady psaním kódu a stavbou. Proces shromažďování uživatelských požadavků by se mohl zjednodušit tím, že se koncovým uživatelům představí obrazovky a získají se jejich podněty. Hromadění chyb by se mělo předcházet spouštěním testů ihned po napsání kódu.
Proces učení se urychluje používáním krátkých iteračních cyklů – každý z nich je spojen s refaktoringem a integračním testováním. Zvýšení zpětné vazby prostřednictvím krátkých sezení se zákazníky pomáhá při určování aktuální fáze vývoje a úpravě úsilí pro budoucí zlepšení. Během těchto krátkých sezení se zástupci zákazníků i vývojový tým dozvídají více o problému domény a vymýšlejí možná řešení pro další vývoj. Zákazníci tak na základě dosavadního výsledku vývojového úsilí lépe chápou své potřeby a vývojáři se učí, jak tyto potřeby lépe uspokojit. Další myšlenkou v procesu komunikace a učení se se zákazníkem je vývoj založený na množině – ten se soustředí na sdělování omezení budoucího řešení, nikoliv možných řešení, čímž podporuje zrod řešení prostřednictvím dialogu se zákazníkem.
Rozhodujte co nejpozdějiRozhodování
Jelikož je vývoj softwaru vždy spojen s určitou nejistotou, lepších výsledků by mělo být dosaženo pomocí přístupu založeného na množině nebo možnostech, kdy se rozhodnutí co nejvíce odkládají, dokud je nelze učinit na základě faktů, a nikoliv na základě nejistých předpokladů a předpovědí. Čím je systém složitější, tím větší kapacita pro změny by v něm měla být zabudována, což umožní odložit důležité a zásadní závazky. Iterativní přístup podporuje tuto zásadu – schopnost přizpůsobovat se změnám a napravovat chyby, které by mohly být velmi nákladné, pokud by byly odhaleny až po vydání systému.
Při vývoji založeném na množinách: Pokud je například pro automobil potřeba nový brzdový systém, mohou řešení stejného problému navrhnout tři týmy. Každý tým se seznámí s prostorem problému a navrhne potenciální řešení. Jakmile je řešení považováno za nerozumné, je vyškrtnuto. Na konci období se porovnají přeživší návrhy a vybere se jeden, možná s určitými úpravami na základě poznatků od ostatních – skvělý příklad odložení závazku do poslední možné chvíle. Tento postup by se mohl hodit i při rozhodování o softwaru, aby se minimalizovalo riziko, které přináší velký předběžný návrh. Navíc by pak existovalo více implementací, které fungují správně, ale přesto se liší (implementačně, interně). Ty by mohly být využity k implementaci systémů odolných proti chybám, které kontrolují správnost všech vstupů a výstupů, a to ve více implementacích současně.
Agilní přístup k vývoji softwaru může u zákazníků posunout budování variant dříve, a tím odložit některá zásadní rozhodnutí, dokud si zákazníci lépe neuvědomí své potřeby. To také umožňuje pozdější přizpůsobení změnám a předcházení nákladným dřívějším technologicky omezeným rozhodnutím. To neznamená, že by se nemělo plánovat – naopak, plánovací činnosti by se měly soustředit na různé možnosti a přizpůsobení se aktuální situaci a také na vyjasnění nepřehledných situací stanovením vzorů pro rychlé jednání. Vyhodnocování různých možností je efektivní, jakmile si uvědomíme, že nejsou volné, ale poskytují potřebnou flexibilitu pro pozdní rozhodování.
Dodávejte co nejrychlejiUpravujte
V době rychlého vývoje technologií nepřežije ten největší, ale ten nejrychlejší. Čím dříve je konečný produkt dodán bez větších závad, tím dříve lze získat zpětnou vazbu a zapracovat ji do další iterace. Čím kratší jsou iterace, tím lepší je učení a komunikace v týmu. Díky rychlosti lze rozhodnutí odložit. Rychlost zajišťuje splnění aktuálních potřeb zákazníka, a ne to, co požadoval včera. To jim dává možnost odložit rozhodnutí o tom, co skutečně požadují, dokud nezískají lepší znalosti. Zákazníci si cení rychlého dodání kvalitního produktu.
Ideologii výroby just-in-time lze aplikovat na vývoj softwaru s ohledem na jeho specifické požadavky a prostředí. Toho se dosáhne tak, že se představí potřebný výsledek a tým se nechá zorganizovat a rozdělit úkoly pro dosažení potřebného výsledku pro konkrétní iteraci. Na začátku poskytne zákazník potřebné vstupní údaje. Ten může být jednoduše prezentován v malých kartičkách nebo příbězích – vývojáři odhadnou čas potřebný pro realizaci každé kartičky. Organizace práce se tak mění na samopohybový systém – každé ráno během stand-up meetingu každý člen týmu přezkoumá, co se udělalo včera, co se má udělat dnes a zítra, a vyžádá si případné vstupy od kolegů nebo zákazníka. To vyžaduje transparentnost procesu, což je prospěšné i pro komunikaci v týmu.
Mýtus, který se s touto zásadou pojí, zní: Spěch dělá ztráty. Zavedení štíhlé výroby však poskytlo, že je dobré dodávat rychle, aby bylo možné výstupy vidět a analyzovat co nejdříve.
Posílení týmuRozhodování
Ve většině podniků panuje tradiční přesvědčení o rozhodování v organizaci – manažeři říkají pracovníkům, jak mají sami dělat svou práci. V technice work-out se role obracejí – manažeři se učí, jak naslouchat vývojářům, aby mohli lépe vysvětlit, jaká opatření by se mohla přijmout, a také poskytovat návrhy na zlepšení. Štíhlý přístup se řídí agilní zásadou „budujte projekty kolem motivovaných jednotlivců a důvěřujte jim, že práci zvládnou“, podporuje pokrok, vychytává chyby a odstraňuje překážky, ale neprovádí mikromanagement.
Dalším mylným přesvědčením bylo považování lidí za zdroje. Lidé mohou být zdroji z pohledu statistické tabulky, ale při vývoji softwaru, stejně jako v jakékoli organizační činnosti, lidé potřebují něco víc než jen seznam úkolů a jistotu, že nebudou při plnění úkolů rušeni. Lidé potřebují motivaci a vyšší cíl, pro který by mohli pracovat – cíl v rámci dosažitelné reality s jistotou, že si tým může vybrat své vlastní závazky. Vývojáři by měli mít přístup k zákazníkovi; vedoucí týmu by měl poskytnout podporu a pomoc v obtížných situacích a také zajistit, aby skepse neničila ducha týmu. Respektování lidí a uznání jejich práce je jedním ze způsobů, jak posílit tým.
Budování integrity vEdit
Zákazník musí mít ze systému celkový dojem. Jedná se o tzv. vnímanou integritu: jak je inzerován, dodáván, nasazován, přístupný, jak intuitivní je jeho používání, jeho cena a jak dobře řeší problémy.
Vnímaná integrita znamená, že jednotlivé součásti systému dobře spolupracují jako celek s rovnováhou mezi flexibilitou, udržovatelností, efektivitou a rychlostí odezvy. Toho lze dosáhnout pochopením problémové oblasti a jejím řešením současně, nikoliv postupně. Potřebné informace jsou získávány po malých dávkách – nikoliv v jednom obrovském celku – nejlépe osobní komunikací a ne žádnou písemnou dokumentací. Tok informací by měl být konstantní v obou směrech – od zákazníka k vývojářům a zpět, čímž se zamezí velkému stresujícímu množství informací po dlouhém vývoji v izolaci.
Jednou ze zdravých cest k integrální architektuře je refaktoring. Čím více funkcí se do původní kódové základny přidává, tím obtížnější je přidávat další vylepšení. Refaktoring spočívá v zachování jednoduchosti, přehlednosti a minimálního počtu funkcí v kódu. Opakování v kódu jsou známkou špatného návrhu kódu a je třeba se jim vyhnout. Kompletní a automatizovaný proces sestavování by měl být doprovázen kompletní a automatizovanou sadou vývojářských a zákaznických testů, které mají stejné verzování, synchronizaci a sémantiku jako aktuální stav systému. Na konci by měla být důkladným testováním ověřena integrita, čímž bude zajištěno, že systém dělá to, co od něj zákazník očekává. Automatizované testy jsou rovněž považovány za součást výrobního procesu, a proto pokud nepřinášejí přidanou hodnotu, měly by být považovány za odpad. Automatizované testování by nemělo být cílem, ale spíše prostředkem k dosažení cíle, konkrétně ke snížení počtu defektů.
Optimalizujte celekEdit
Moderní softwarové systémy nejsou pouhým součtem svých částí, ale také výsledkem jejich interakcí. Vady v softwaru mají tendenci se hromadit během procesu vývoje – dekompozicí velkých úkolů na menší a standardizací různých fází vývoje by měly být nalezeny a odstraněny hlavní příčiny vad. Čím větší je systém, čím více organizací se podílí na jeho vývoji a čím více částí vyvíjejí různé týmy, tím větší význam má mít dobře definované vztahy mezi jednotlivými dodavateli, aby vznikl systém s hladce spolupracujícími komponentami. Během delšího období vývoje je silnější síť subdodavatelů mnohem výhodnější než krátkodobá optimalizace zisku, která neumožňuje oboustranně výhodné vztahy.
Šetrné myšlení musí všichni členové projektu dobře pochopit, než jej zavedou do konkrétní reálné situace. „Mysli ve velkém, jednej v malém, selhávej rychle; uč se rychle“ – tato hesla shrnují důležitost pochopení této oblasti a vhodnost implementace principů štíhlosti v celém procesu vývoje softwaru. Pouze v případě, že jsou všechny principy štíhlosti implementovány společně, v kombinaci se silným „zdravým rozumem“ s ohledem na pracovní prostředí, je základem úspěchu při vývoji softwaru.