Vývoj softwaru Lean - Lean software development

Vývoj softwaru
Hlavní činnosti
Paradigmata a modely
Metodiky a rámce
Podpůrné disciplíny
Praxe
Nástroje
Standardy a subjekty znalostí
Glosáře
Obrysy

Vývoj softwaru Lean je překladem principů a postupů štíhlé výroby do oblasti vývoje softwaru . Převzato z produkčního systému Toyota a vzniká s podporou pro-lean subkultury v agilní komunitě. Lean nabízí solidní koncepční rámec, hodnoty a principy i osvědčené postupy odvozené ze zkušeností, které podporují agilní organizace.

Původ

Termín lean lean development vznikl v knize se stejným názvem, kterou napsali Mary Poppendieck a Tom Poppendieck v roce 2003. Kniha přeformuluje tradiční principy lean , stejně jako soubor 22 nástrojů a srovnává nástroje s odpovídajícími agilními postupy. Angažovanost Poppendiecks v agilní komunitě pro vývoj softwaru , včetně rozhovorů na několika agilních konferencích, vyústila v to, že tyto koncepty jsou v agilní komunitě více přijímány.

Štíhlé principy

Štíhlý vývoj lze shrnout do sedmi principů, jejichž koncepce je velmi blízká principům štíhlé výroby:

  1. Eliminujte odpad
  2. Zvyšte učení
  3. Rozhodněte se co nejpozději
  4. Doručte co nejrychleji
  5. Posilte tým
  6. Budujte integritu
  7. Optimalizujte celek

Eliminujte odpad

Filozofie Lean považuje všechno, co pro zákazníka nepřináší hodnotu, za odpad ( muda ). Takový odpad může zahrnovat:

  1. Částečně odvedená práce
  2. Extra funkce
  3. Přeučení
  4. Přepínání úkolů
  5. Čekání
  6. Předání
  7. Vady
  8. Činnosti managementu


Za účelem vyloučení odpadu by měl být člověk schopen ho rozpoznat. Pokud by bylo možné obejít nějakou činnost nebo by bylo možné dosáhnout výsledku bez ní, je to odpad. Částečně hotové kódování, které bylo nakonec opuštěno během procesu vývoje, je odpad. Další funkce, jako jsou papírování a funkce, které zákazníci často nepoužívají, jsou odpad. Přepínání lidí mezi úkoly je plýtvání. Čekání na další aktivity, týmy, procesy je plýtvání. Znovuzískání potřebné k dokončení práce je odpad. Vady a nižší kvalita jsou odpad. Manažerská režie, která neprodukuje skutečnou hodnotu, je plýtvání.

K identifikaci odpadu se používá technika mapování hodnotového toku . Druhým krokem je poukázat na zdroje odpadu a eliminovat je. Odvoz odpadu by měl probíhat iterativně, dokud nebudou zlikvidovány i zdánlivě zásadní procesy a postupy.

Zvyšte učení

Vývoj softwaru je nepřetržitý proces učení založený na iteracích při psaní kódu. Softwarový design je proces řešení problémů, který zahrnuje vývojáře, kteří píší kód a to, co se naučili. Hodnota softwaru se měří ve vhodnosti pro použití a není v souladu s požadavky.

Místo přidávání další dokumentace nebo podrobného plánování je možné vyzkoušet různé nápady napsáním kódu a sestavením. Proces shromažďování požadavků uživatelů lze zjednodušit tím, že se obrazovky budou zobrazovat koncovým uživatelům a získávat jejich vstupy. Hromadění vad by mělo být zabráněno spuštěním testů, jakmile bude kód napsán.

Proces učení je urychlen využitím krátkých iteračních cyklů - každý je spojen s refaktoringem a integračním testováním . Zvyšování zpětné vazby prostřednictvím krátkých relací zpětné vazby se zákazníky pomáhá při určování aktuální fáze vývoje a přizpůsobování úsilí pro budoucí vylepšení. Během těchto krátkých setkání se zástupci zákazníků i vývojový tým dozvěděli více o problému domény a vymysleli možná řešení pro další vývoj. Zákazníci tak lépe porozumí jejich potřebám na základě stávajících výsledků vývojových snah a vývojáři se učí, jak tyto potřeby lépe uspokojit. Další myšlenkou v procesu komunikace a učení se zákazníkem je vývoj založený na sadě - soustředí se na komunikaci omezení budoucího řešení, nikoli možných řešení, čímž podporuje zrod řešení prostřednictvím dialogu se zákazníkem.

Rozhodněte se co nejpozději

Jako vývoj software je vždy spojena s určitou nejistotou, je třeba lepších výsledků dosáhnout pomocí set-založené nebo možnosti založené na přístupu, oddálit rozhodnutí v co největší míře, dokud mohou být založena na faktech a ne na nejistých předpokladů a prognóz. Čím složitější je systém, tím větší kapacita pro změnu by do něj měla být zabudována, což by umožnilo oddálit důležité a zásadní závazky. Iterativní přístup podporuje tento princip - schopnost přizpůsobit se změnám a opravit chyby, které by mohly být velmi nákladné, pokud by byly objeveny po vydání systému.

S vývojem založeným na sadách: Je-li například pro vůz potřeba nový brzdový systém, mohou tři týmy navrhnout řešení stejného problému. Každý tým se dozví o problémovém prostoru a navrhne potenciální řešení. Protože je řešení považováno za nepřiměřené, je přerušeno. Na konci období jsou přežívající návrhy porovnány a je vybrán jeden, možná s některými úpravami založenými na poučení od ostatních - skvělý příklad odložení závazku na poslední možnou chvíli. Softwarová rozhodnutí by také mohla těžit z této praxe, aby se minimalizovalo riziko, které přináší velký up-front design. Dále by pak existovalo několik implementací, které fungují správně, přesto se liší (implementačně, interně). Ty by mohly být použity k implementaci systémů odolných proti chybám, které současně kontrolují správnost všech vstupů a výstupů napříč několika implementacemi.

Agilní vývoj software přístup může posunout budovu možností dříve pro zákazníky, tak zdržovat některá zásadní rozhodnutí, dokud zákazníci si uvědomili jejich potřebám lépe. To také umožňuje pozdější přizpůsobení se změnám a prevenci nákladných dřívějších rozhodnutí vázaných na technologii. To neznamená, že by nemělo být zahrnuto žádné plánování - naopak, plánovací činnosti by se měly soustředit na různé možnosti a přizpůsobení se současné situaci, stejně jako vyjasnění nejasných situací vytvořením vzorů pro rychlou akci. Hodnocení různých možností je účinné, jakmile se zjistí, že nejsou bezplatné, ale poskytují potřebnou flexibilitu pro pozdní rozhodování.

Doručte co nejrychleji

V době rychlého technologického vývoje není přežívající největší, ale nejrychlejší. Čím dříve je konečný produkt dodán bez větších vad, tím dříve lze obdržet zpětnou vazbu a začlenit ji do další iterace . Čím kratší iterace, tím lepší učení a komunikace v týmu. S rychlostí mohou být rozhodnutí odložena. Rychlost zajišťuje splnění současných potřeb zákazníka, a nikoli toho, co včera požadovali. To jim dává příležitost odložit rozhodnutí o tom, co skutečně vyžadují, dokud nezískají lepší znalosti. Zákazníci oceňují rychlé dodání kvalitního produktu.

Just-in-time produkci ideologie by mohla být použita na vývoj softwaru , rozpoznávat své specifické požadavky a životní prostředí. Toho je dosaženo prezentací potřebného výsledku a tím, že se tým nechá zorganizovat a rozdělit úkoly pro dosažení potřebného výsledku pro konkrétní iteraci . Na začátku zákazník poskytne potřebný vstup. To by mohlo být jednoduše prezentováno na malých kartách nebo příbězích - vývojáři odhadují čas potřebný pro implementaci každé karty. Organizace práce se tak mění v systém samouku - každé ráno během stand-up schůzky každý člen týmu kontroluje, co se stalo včera, co se má udělat dnes a zítra, a vyzve k jakýmkoli vstupům potřebným od kolegů nebo zákazník. To vyžaduje transparentnost procesu, což je také výhodné pro týmovou komunikaci.

Mýtus, který je základem tohoto principu, je spěch, který dělá odpad . Štíhlá implementace však stanovila, že je dobrým zvykem dodávat rychle, aby bylo možné výstup vidět a analyzovat nejdříve.

Posilte tým

Ve většině podniků tradičně existuje víra v rozhodování v organizaci - manažeři říkají pracovníkům, jak mají vykonávat svou vlastní práci. V metodě cvičení se role obracejí - manažeři se učí, jak naslouchat vývojářům , aby mohli lépe vysvětlit, jaké akce lze podniknout, a také poskytnout návrhy na vylepšení. Štíhlý přístup se řídí agilním principem „stavět projekty na motivovaných jednotlivcích [...] a důvěřovat jim, že práci zvládnou“, podporovat pokrok, chytat chyby a odstraňovat překážky, ale nikoliv mikrosprávu.

Další mylnou vírou bylo považování lidí za zdroje . Lidé mohou být zdroji z pohledu statistického datového listu, ale při vývoji softwaru , stejně jako v jakémkoli organizačním podnikání, lidé potřebují něco víc než jen seznam úkolů a ujištění, že nebudou rušeni během dokončení úkolů. Lidé potřebují motivaci a vyšší účel, aby mohli pracovat za účelem v dosažitelné realitě s jistotou, že si tým může zvolit své vlastní závazky. Vývojářům by měl být umožněn přístup k zákazníkovi; vedoucí týmu by měl poskytovat podporu a pomoc v obtížných situacích a zajistit, aby skepse nezničila ducha týmu. Respektování lidí a uznání jejich práce je jedním ze způsobů, jak posílit tým.

Budujte integritu

Zákazník musí mít celkovou zkušenost se systémem. Jedná se o takzvanou vnímanou integritu: jak je inzerována, doručována, nasazována, zpřístupňována, jak intuitivní je její použití, její cena a jak dobře řeší problémy.

Konceptuální integrita znamená, že jednotlivé komponenty systému fungují dobře společně jako celek s rovnováhou mezi flexibilitou, udržovatelností, účinností a odezvou. Toho lze dosáhnout porozuměním problémové oblasti a jejím řešením současně, nikoli postupně. Potřebné informace jsou přijímány v malých dávkách - ne v jednom obrovském bloku - nejlépe prostřednictvím osobní komunikace a nikoli v žádné písemné dokumentaci. Tok informací by měl být konstantní v obou směrech - od zákazníka k vývojářům a zpět, aby se zabránilo velkému stresujícímu množství informací po dlouhém vývoji izolovaně.

Jednou ze zdravých cest k integrální architektuře je refaktoring . Jak se do původní kódové základny přidávají další funkce, tím těžší je přidat další vylepšení. Refaktoring je o zachování jednoduchosti, přehlednosti a minimálního počtu funkcí v kódu. Opakování v kódu jsou příznaky špatných návrhů kódu a je třeba se jim vyhnout. Kompletní a automatizovaný proces vytváření by měl být doprovázen kompletní a automatizovanou sadou vývojářských a zákaznických testů se stejnými verzemi, synchronizací a sémantikou jako aktuální stav systému. Na konci by měla být integrita ověřena důkladným testováním, čímž se zajistí, že systém bude dělat to, co od něj zákazník očekává. Automatizované testy jsou také 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ě omezením vad.

Optimalizujte celek

Moderní softwarové systémy nejsou jen součtem jejich částí, ale také produktem jejich interakcí. Vady v softwaru mají tendenci se hromadit během procesu vývoje - rozložením velkých úkolů na menší úkoly a standardizací různých fází vývoje by měly být nalezeny a odstraněny hlavní příčiny defektů. Čím větší je systém, čím více organizací se podílí na jeho vývoji a čím více částí vyvíjí různé týmy, tím větší je důležitost dobře definovaných vztahů mezi různými dodavateli, aby bylo možné vytvořit systém s hladce interagují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 vztahy win-win.

Štíhlá myšlenka musí být dobře pochopena všemi členy projektu, než se uskuteční v konkrétní konkrétní situaci. „Myslete ve velkém, jednejte v malém, rychle selhávejte; rychle se učte“ - tyto slogany shrnují důležitost porozumění oboru a vhodnost implementace štíhlých principů v celém procesu vývoje softwaru. Pouze tehdy, když jsou všechny štíhlé principy implementovány společně v kombinaci se silným „zdravým rozumem“ s ohledem na pracovní prostředí, existuje základ pro úspěch ve vývoji softwaru .

Štíhlé softwarové postupy

Postupy štíhlého vývoje softwaru nebo to, co Poppendiecks nazývají „nástroje“, jsou mírně přepracovány od původních ekvivalentů agilního vývoje softwaru . Mezi příklady takových postupů patří:

Vzhledem k tomu, že agilní vývoj softwaru je zastřešujícím pojmem pro soubor metod a postupů založených na hodnotách a principech vyjádřených v agilním manifestu, je štíhlý vývoj softwaru považován za metodu agilního vývoje softwaru.

Viz také

Reference

Další čtení