Lean metody ve vývoji softwaru

Je to takový pěkný buzzword. Lean firma. Spousty velkých firem Lean principy implementuje, obvykle bez většího porozumění jejími zaměstnanci. Často to končí tím, že si udělají nějaké lístečky a jsou dostatečně Lean, tedy štíhlí. Jenže na to aby to přineslo nějaké výsledky, je stejně jako u agilních metod třeba porozumět filozofii. A ne jen slepě vykonávat nějaké rituály. O co tedy jde? Jednoduše řečeno o omezení práce na tom, co by nemuselo přinášet hodnotu a tedy v konečném důsledku mohlo přijít nazmar.

Nejznámější Lean firma je určitě Toyota. Tam vyvinuli proces řízení výroby, odlišný od běžných procesů kdy vyrábíme kdykoli a cokoli na sklad. Řídí výrobu systémem tahu, kde vyrábíme příslušný díl, až když je potřeba.

Jak takový princip použít ve firmách kdy žádné fyzické díly nevyrábíme? Tak se třeba podívejme na standardní vývojový proces – waterfall. Nejprve uděláme na sklad analýzu, pak kód, a pak testy. A čekáme, že to je tak v pořádku a že všechny díly jsou kvalitní (tedy že design už se nezmění, v kódu se nenajde chyba, a že zákazník to tak opravdu chce). A stejně jako ve výrobě se nám děje, že jednotlivé věci musíme předělat, opravit, zahodit. Někdy i celou krabici dílů se stejnou chybou (někdy i celou rozsáhlou funkcionalitu).

Jak na to? V kostce, omezte ‘work in progress‘ a soustřeďte se na to, abyste jednotlivé požadavky protlačili systémem co nejrychleji. Implementujte systém tahu a nezačínejte s analýzou, dokud nemáte prioritní požadavek od zákazníka. A dokud nemáte zpětnou vazbu, že předchozí požadavek byl akceptován.

A aby to bylo více uchopitelné, Lean Software Development je založen na následujících principech:

Odstraňte vše, co nepřináší hodnotu – tedy zbavte se odpadu. Pracovat na něčem co se ve finále vyhodí je škoda času, když se vám podaří tento čas investovat do věcí, co mají smysl, budete jistě efektivnější.

Zlepšujte se a učte se již v průběhu – když jen slepě vykonáváte předpisy a sledujete procesy, může se stát, že stejnou chybu opakujete pořád dokola a ‘odpad’ se vám tedy na konci projektu nahromadí víc, než byste si přáli. Pravidelná zpětná vazba vám pomůže se soustředit jen na to, na čem záleží.

Rozhodujte se co nejpozději – čím později rozhodnutí padne, tím více máte informací. Takže jsme zase zpět u myšlenky, že nemá smysl vyrábět zásoby na sklad jen proto, že zrovna máte volnou linku nebo programátory.

Dodávejte práci, jak nejrychleji to jde – čím dříve něco dokončíte, tím dříve dostanete zpětnou vazbu, kterou můžete hned v další iteraci zohlednit.

Dejte týmu důvěru a zodpovědnost – a budete mít mnohem motivovanější tým, než když se budete držet tradičních top-down struktur.

Zaměřte se na celkový dojem – produkt není jen software. Dbejte na kvalitu a celkovou udržitelnost systému, nevytvářejte technický dluh.

Zaměřte se na celkový výsledek – jednotlivé chyby a selhání nejsou podstatné, pakliže se z nich poučíte. “Think big, act small, fail fast; learn rapidly” – tedy Přemýšlejte dopředu, začněte u malých věcí, ty vyhodnoťte a rychle se z nich poučte. Jen tak zajistíte, že výsledný produkt bude úspěšný.

Metoda, která vám radí jak na to je Kanban. Ale o tom zase příště.