Lean Software Development (LSD)

Výrobce automobilů Toyota vyvinul a nasadil na přelomu 70. a 80. let ve svých podnicích revoluční způsob řízení nazvaný Lean Manufacturing (‚Zeštíhlená výroba‘), který spočíval v eliminaci plýtvání, zjednodušení řetězce tvorby hodnot, v dodávkách dle aktuálních potřeb a na čas (dnes již dobře známý způsob zásobování ‚just-in-time‘) a zaměření na lidi a jejich hodnotu.

‚Zeštíhlené‘ uvažování zhodnocuje důvtip pracovníků v první linii. Věří, že právě oni mají kompetenci určovat a kontinuálně zlepšovat způsob, jakým vykonávají svou práci. Mary a Tom Poppendieckovi převedli tyto principy a zkušenosti z výrobního prostředí do prostředí softwarového vývoje, čímž vznikla metodika Lean Software Development.

Metodika LSD je postavena na 7 principech a 22 nástrojích. Vzhledem k omezenému rozsahu této úvahy si tyto principy osvětlíme pouze stručně a podrobněji se zmíníme pouze o jednom z nástrojů: Mapování hodnotového proudu.

Princip č. 1: Omezit plýtvání
Je třeba naučit se vidět plýtvání. To neznamená zanevřít na administrativu, formální úkony nebo dokumentaci, ale věnovat úsilí především těm aktivitám, které přispívají ktvorbě reálných hodnot pro zákazníka. Eliminace plýtvání je fundamentálním principem všech ‚Lean‘-konceptů. K tomu účelu je využíván nástroj nazvaný Value Stream Mapping (Mapování hodnotového proudu). Jde o hodnotovou analýzu výrobní linky s cílem identifikovat a omezit zbytné činnosti z pohledu požadavků/zadání zákazníka.

Princip č. 2: Rozvíjet znalost o díle
Je nutné udržovat zpětnou vazbu se zákazníkem a klíčovými podílníky projektu s cílem kontinuálně ověřovat, zda ‚děláme správný systém?‘, namísto zda ‚děláme systém správně?‘. K tomu slouží iterativní vývojový přístup a synchronizace jednotlivců (denně) a týmů (týdně).

Princip č. 3: Rozhodovat co nejpozději
Agilní metodiky se obecně snaží udržovat možnosti otevřené co nejdéle. Rychlé zabřednutí do příliš detailního řešení zvyšuje pravděpodobnost neshody. Někdy je výhodnější, necháme-li možnosti vymezit pouze omezeními. Čím později se totiž můžeme rozhodnout, tím spíše se přiblížíme představám zákazníka.

Princip č. 4: Dodávat co nejdříve
...než se stihne změnit zadání. Eliminujeme tak nejistotu/nedorozumění. Jde o účinný způsob řízení přítoku požadavků/práce, který jsem si osobně mnohokrát úspěšně vyzkoušel v praxi. Čím menší přírůstky totiž dáváme k akceptaci, tím menší pracovní balík z připomínek můžeme očekávat. Práci tak lze lépe a rovnoměrněji plánovat a reakční doba na zpracování připomínek může být kratší. To je zároveň i konkurenční výhoda, která nám umožní obsluhovat zákazníka rychleji a intenzivněji, což zpravidla nezůstává bez kladné odezvy.

Princip č. 5: Přenést pravomoci na tým
‚Zeštíhlující myšlení‘ zhodnocuje důvtip a invenci týmu. Důvěra v tým motivuje. Je proto dobré snažit se přesunout rozhodování na co nejnižší úroveň a rozvíjet schopnosti členů týmu tak, aby jejich rozhodnutí byla moudrá.

Princip č. 6: Budovat integritu
Budovat integritu znamená budovat rovnováhu mezi funkčností, použitelností, spolehlivostí a hospodárností. Takové řešení vždy racionálně uvažujícího zákazníka potěší. ‚Lean‘ přístup vede k takové integritě produktu. V této souvislosti je třeba zmínit pojem Refactoring: Jde o princip vycházející z předpokladu, že dobrý design se rozvíjí během života systému. Tvůrci se poučí ze slabin a design se vylepší. Proto je v metodice LSD podporována snaha nebát se dělat věci nově a lépe, kdykoliv k tomu máme příležitost. V softwarovém vývoji by testování mělo být co nejvíce automatizováno, aby mohlo probíhat jako součást denního sestavení produktu.

Princip č. 7: Vidět celek
Tento princip se na první pohled jeví jako konfliktní s tradičním principem Struktury rozpadu prací (Work Breakdown Structure - WBS), jehož smyslem je rozdělení celku na menší, snáze řiditelné části. LSD totiž vyžaduje nepodlehnout pokušení optimalizovat části na úkor celku, což se při dělbě práce dle WBS v tradičních projektových týmech může stát.
Metodika LSD si je tohoto rizika vědoma: Čím komplexnější systém – tím větší je pokušení dělit na části a řídit je lokálně. Výkonnost projektu by se však rozhodně neměla měřit lokálně, nýbrž vždy na celku, aby bylo možno vyhodnotit dopady.

Princip vnímání celku také vyžaduje přejít zfixní definice rozsahu na ‚vyjednatelnou‘, pružnou definici rozsahu, a to dle aktuálních potřeb zákazníka. Vlastnosti systému k implementaci by také měly získat priority tak, aby zákazník získal klíčové funkce produktu dávno před tím, než bude seznam požadavků zcela splněn. To je zároveň jedno z pravidel agilních metodik obecně.

Pokračování zde...