Libového vývoj softwaru

Od Davida J.Anderson.David J.Anderson je autorem tří knih, Lekce agilní řízení: na silnici Kanban, který byl publikován v roce 2012, Kanban: úspěšné změně evolučním firemních technologií, [1] který byl publikován v roce 2010 a agilní řízení pro Software Engineering: použití teorie omezení obchodních výsledků, [2] který byl publikován v 2003.Byl členem týmu, který vytvořil Metodu agilního vývoje softwaru; Funkcemi řízený vývoj, v Singapuru mezi roky 1997 a 1999.Vytvořil MSF pro zlepšení procesu CMMI a mu co-authored technické poznámky z Software Engineering Institute "CMMI a agilní: Proč není funkcí oba!" Mu bylo zakládajících libového systémy společnosti (http://www.leansystemssociety.org).Je výkonný ředitel libového Kanban University Inc., akreditovaných školení a kvality normalizační organizace nabízející Kanban vzdělávání prostřednictvím sítě partnerů po celém světě a mu vede mezinárodní Řízení školení a konzultační firmy, David J.Anderson & Associates Inc.(http://www.agilemanagement.net), který pomáhá podnikům z oblasti technologií zvýšit efektivitu zavedením lepších zásad pro správu a lepšího rozhodování.

Listopadu 2011, aktualizováno dne 2012.

Anderson popisuje vývoj štíhlého softwaru.

Platí pro

Lean, vývoj softwaru, řízení projektu, Team Foundation Server

• Introduction

• Lean a Agile

• Lean za Agile

• Definování vývoje štíhlého softwaru

• Hodnoty

• Zásady

• Postupy

Termín, který byl vývojem softwaru Lean nejprve určen jako název konference, uspořádané iniciativou ESPRIT Evropské unie v říjnu 1992, ve Stuttgartu, v Německu.Nezávisle na tom navrhl Robert "Bob" Charette v roce 1993, tedy v následujícím roce, pojem „Vývoj softwaru LEAN“ jako součást své práce, při které zkoumal lepší způsoby řízení rizik v softwarových projektech.Termín „Lean“ popsali roku 1991 James Womack, Daniel Jones a Daniel Roos ve své knize The Machine That Changed the World: The Story of Lean Production (Stroj, který změnil svět: Příběh produkce metodikou Lean)[3] jako termín anglického jazyka pro popis manažerské přístupu používaného ve společnosti Toyota.Myšlenka, že metodika Lean může být použitelná ve vývoji softwaru, vznikla velmi brzy, pouze 1 až 2 roky poté co byl termín prvně použit ve spojení s trendy ve výrobních procesech a inženýrství.

Ve své druhé knize publikované v roce 1995 Womack a Jones[4] definovali pět základních pilířů myšlení Lean.Jednalo se o tyto:

• Value

• Hodnotový proud

• Tok

• Vyžádat

• Dokonalost

To se stalo výchozí pracovní definicí metodiky Lean pro většinu příštího desetiletí.Vždy bylo při hledání dokonalosti doporučováno dosažení omezení odpadů.Zatímco se jednalo o pět pilířů, oslovil pátý, který byl doveden k dokonalosti prostřednictvím systémové identifikace nehospodárných činností a jejich odstraněním, širokou veřejnost.Koncepce Lean se v průběhu devadesátých let 20. století a počátku 21. století téměř výhradně propojila s praxí omezování plýtvání.

Definice Womacka a Jonese metodiky Lean není sdílena všeobecně.Zásady řízení ve společnosti Toyota jsou mnohem jemnější.Jediné slovo „odpad“ je v angličtině popsáno košatěji třemi japonskými termíny:

• Muda – doslova znamená „plýtvání“, ale vedoucí k aktivitě bez přidané hodnoty

• Mura – znamená „nerovnost“ a je interpretován jako „proměnlivost toku“.

• Muri – znamená „nadměrné zatížení“ nebo „nepřiměřenost“

Dokonalost hledáme snížením aktivity bez přidaných hodnot, ale také prostřednictvím vyhlazování toku a vyloučením nadměrného zatížení.Kromě toho byl přístup společnosti Toyota založen na respektování zaměstnanců a byl významně ovlivněn přístupy kontroly kvality 20. století a experty na řízení procesů prostřednictvím statistik, jakými byl například W.Edwards Deming.

Bohužel existuje téměř tolik definic metodiky Lean jako autorů tohoto předmětu.

Lean a Agile

Bob Charette byl pozván, ale nemohl se zúčastnit zasedání v roce 2001 ve Snowbird v Utahu, kde byl Manifest pro agilní vývoj softwaru[5] vytvořen.Navzdory nepřítomnosti na této historické schůzi byl vývoj štíhlého softwaru považován za jeden z několika agilních přístupů k vývoji softwaru.Jim Highsmith věnoval kapitolu své knihy z roku 2002[6] rozhovoru s Bobem o tomto tématu.Později Mary a Tom Poppendieckovi pokračovali sérií 3 knih[7, 8, 9].Během prvních několika let 21. století byly štíhlé zásady používány k vysvětlení, proč byly agilní metody lepší.Koncepce Lean vysvětlila, že metody Agile zahrnovaly nízkou úroveň „plýtvání“, a proto dosahovaly lepších ekonomických výsledků.Zásady koncepce Lean poskytly oprávnění pro přijetí metod Agile.

Lean za Agile

V posledních letech se z vývoje softwaru LEAN stala samostatná disciplína týkající se mimo jiné podmnožiny agilního hnutí.Tento vývoj začíná sloučením nápadů z vývoje produktu metodikou Lean a prací Donalda G.Reinertsen[10,11] a nápady vznikající z neagilního světa inženýrství ve velkém měřítku a zápisky od Jamese Suttona a Petera Middletona[12].Také jsem syntetizoval práce Eli Goldratt a W.Edwards Deming a rozvíjel fokus na průběh, nikoli na snížení plýtvání[13].Na podnět Reinertsena jsem kolem roku 2005 zavedl používání systémů kanban, které omezují probíhající práci a „nabírají“ novou práci pouze v případě, že je systém připraven ji zpracovat.Alan Shalloway připojil své postřehy k vývoji štíhlého softwaru ve své knize z roku 2009 na toto téma[14].Od roku 2007 byl při vzniku metodiky Lean coby nového výkonného postupu při vývoji softwaru kladen důraz na zlepšení toku, řízení rizik a zlepšení (řízení) rozhodování.Kanban se stal hlavním prvkem umožňujícím iniciativy LEAN při práci související s informačními technologiemi.Zdá se, že zaměření na tok, nikoli na odstranění plýtvání, prokazuje lepší katalytické vlastnosti pro trvalé zlepšování v rámci znalostních pracovních činností, například vývoj softwaru.

Definování vývoje štíhlého softwaru

Definování vývoje štíhlého softwaru je náročné, protože neexistuje konkrétní metoda či proces vývoje štíhlého softwaru.Koncepce Lean není ekvivalentem pro Personal Software Process, V-Model, Spiral Model, EVO, Feature-Driven Development, Extreme Programming, Scrum ani Test-Driven Development.Životní cyklus vývoje softwaru nebo správa projektu mohou být označeny za dodržování metodiky Lean, pokud vyhovují hodnotám a zásadám vývoje softwaru Lean.Takže předvídání jednoduchého receptu, který můžete postupovat a pojmenovat vývoj softwaru Lean bude vést ke zklamání.Je třeba navrhnout nebo uzpůsobit vlastní softwarové řešení pochopením principů metodiky Lean a přijetím základních hodnot metodiky Lean.

Existuje několik škol postojů v rámci vývoje softwaru Lean.Největší a považovat vedoucí školy je systémy společnosti libového, která zahrnuje Donald Reinertsen, Jan Sutton, Alan Shalloway, Bob Charette, Mary Poppendeick a David J.Anderson.Marie a Petr Poppendieck práce rozvinuté před založení společnosti a jeho credo stojí samostatně, stejně jako práce Larman Craiga, Bas Vodde[15,16]a jako poslední, Jan Coplien[17].Tento článek se snaží veřejně reprezentativní z hlediska libového systémy společnosti vyjádřené v jeho credo a poskytnout syntézy a souhrnné informace o své nápady.

Hodnoty

Systémy společnosti libového publikovány jeho credo[18] na Software libového 2012 & Konference systémy[19].To bylo založeno na sadu hodnot, které jsou publikovány rok dříve.Tyto hodnoty:

• Pochopení lidských podmínek

• Pochopení, že složitost a nejistota jsou pro znalostní práci přirozené

• Usilujte o lepší hospodářský výsledek

• Během zajišťování lepších sociologických výsledků

• Hledání, podpora a rozebírání nápadů z široké řady oborů

• Komunita založená na hodnotách zvyšuje rychlost a hloubku pozitivních změn.

Pochopení lidských podmínek

Práce s poznatky, například vývoj softwaru, je prováděna lidmi.Lidé jsou ve své podstatě složití a kromě používání logiky jsou také naváděni emocemi a vrozenými pudy, které nelze přiměřeným způsobem překonat.Při navrhování systémů nebo procesů, ve kterých pracujeme, je třeba brát ohled na naši psychologii a neuropsychologii.Naše sociální chování musí také být ukotveno.Lidi jsou ze své podstaty emocionální, sociální a kmenoví a naše chování se únavou a stresem mění.Úspěšné procesy budou ty, které podpoří a pojmou lidské podmínky spíše než ty, které se pokusí odepřít přístup a předpokládají logické, strojové chování.

Pochopení, že složitost a nejistota jsou pro znalostní práci přirozené

Chování zákazníků a trhů je nepředvídatelné.Tok práce prostřednictvím procesu a kolekce pracovníků je nepředvídatelný.Vady a nutná přepracování nelze předvídat.Během vývoje softwaru je na různých úrovních možnost zdánlivě náhodného chování na mnoha úrovních.Účel, cíle a rozsah projektů lze změnit při jejich dodání.Některé tyto nejistoty a variabilita, ač zpočátku neznámé, lze poznat v tom smyslu, že mohou být zkoumány a kvantifikovány a spravovány jejich rizika, ale některá variabilitě je předem nerozpoznatelná a nelze ji přiměřeně očekávat.V důsledku toho musí být systémy vývoje štíhlého softwaru schopny reagovat na vznikající události a systém musí být schopen se přizpůsobit měnícím se okolnostem.Z tohoto důvodu musí jakýkoli proces štíhlého vývoje softwaru existovat v rámci, který umožňuje adaptaci (procesu) na sdělovací události.

Usilujte o lepší hospodářský výsledek

Lidské činnosti, jako je štíhlý vývoj softwaru by měly být zaměřeny na dosahování lepšího hospodářského výsledku.Kapitalismus je přijatelný, pokud přispívá jak k hodnotě podniku, tak ke prospěchu zákazníka.Investoři a vlastníci podniků si zaslouží návratnost svých investic.Zaměstnanci a pracovníci si zaslouží přiměřenou odměnu za přiměřené úsilí při provádění práce.Zákazníci si zaslouží dobrý produkt nebo službu, která dodává přislíbený přínos za zaplacené spravedlivé ceny.Lepší hospodářské výsledky budou zahrnovat další hodnotu pro zákazníka za nižší cenu při správě kapitálu nasazeného investory nebo vlastníky tím nejúčinnějším způsobem.

Zajištění lepších sociologických výsledků

Lepší hospodářské výsledky by neměly být dosaženy na úkor těch, kteří práci vykonávají.Vytvoření pracoviště, které respektuje osoby zohledněním lidského faktoru a poskytuje systémy práce, které respektují psychologickou a sociologickou povahu lidí, je zásadní.Vytvoření vhodného místa pro provedení skvělé práce je základní hodnotou komunity pro vývoj štíhlého softwaru.

Zásady

Zdá se, že Software Lean a společenství systému se shoduje na několika zásadách procesu vývoje softwaru metodikou Lean.

• Řiďte se systémovým myšlením a přístupem k produktu

• Vznikající výsledky mohou být ovlivněny architekturou kontextu komplexního adaptivního systému

• Respektujte ostatní (jako součást systému)

• Použijte vědecké metody (na zlepšení)

• Podpora vedení

• Generovat viditelnost (do práce, pracovní postup a systémové operace)

• Zkrátit dobu toku

• Snížení odpadu ke zlepšení účinnosti

Řiďte se systémovým myšlením a přístupem k produktu

To je často označováno v literatuře metodiky Lean jako „optimalizace celku“, což znamená, že je řeč o výstupu na celý systém (nebo proces), který chceme optimalizovat. Neměli bychom chybně optimalizovat části v naději, že celek se zázračně optimalizuje sám od sebe.Většina praktiků věří ve správnost logického úsudku, kdy optimalizace částí (lokální optimalizace) povede k méně optimálním výsledkům.

Přístup uvažování a návrhu ve stylu systémů využívajících metodiku Lean vyžaduje zvážení požadavků na systém od externích zúčastněných stran, jako např. zákazníků, a požadovaného výsledku, který tyto zúčastněné strany vyžadují.Musíme zkoumat povahu poptávky a porovnat ji s možnostmi našeho systému, který chceme dodávat.Poptávka bude obsahovat tzv. „hodnotovou poptávku“, za kterou jsou zákazníci ochotni zaplatit, a „poptávku selhání“, která obvykle představuje přepracování nebo další poptávku způsobenou selháním dodání hodnotové poptávky.Poptávka způsobená selháním má obvykle dvě formy: poptávku po opakované práci na dříve dodané hodnotě a poptávku po dalších službách nebo podpoře z důvodu selhání při dodání hodnoty.Ve vývoji softwaru jsou požadavky selhání obvykle požadavky na odstranění chyb a požadavky na funkci péče o zákazníka nebo oddělení podpory.

Přístup návrhu systému vyžaduje, abychom použili také přístup PDSA (Plan-Do-Study-Act) ke zpracování návrhu a zlepšení.W.Edwards Deming používal slova „studie“ a „schopnost“ k vyjádření, že studujeme fyziku chování našeho systému.Tento systém se skládá z procesu vývoje softwaru a všech osob, které ho ovládají.Bude mít pozorovatelné chování, co se týká předstihu, jakosti, množství funkcí nebo dodaných funkcí (uváděné v literatuře o Agile jako „rychlost“) atd.Tyto metriky budou vykazovat variabilitu a zkoumat význam a šíření varianty, takže můžeme vyvíjet a poznávat své schopnosti.Pokud se neshoduje s poptávkou a očekáváními zákazníka, bude nutné systém přestavět a uzavřít tak mezeru.

Deming rovněž učil, že schopnost je z 95 % ovlivňována návrhem systému a pouze z 5 % k ní přispívá výkon jednotlivců.Jinými slovy, můžeme respektovat lidi tím, že je nebudeme obviňovat kvůli nedostatečným schopnostem v porovnání s požadavky a změníme návrh systému, abychom jim umožnili dosažení úspěchu.

Pokud chcete pochopit návrh systému, je třeba chápat vědeckou stránku schopností dynamiky systému a její tvorby.Modely jsou vyvíjeny pro předpovídání dynamiky systému.Existuje mnoho možných modelů, některé oblíbené se používají podobně: pochopení ekonomických nákladů; takzvané transakce a koordinace nákladů, které se vztahují k výrobě produktů a služeb s hodnotou pro zákazníka; Teorie omezení – porozumění kritických bodů; a teorie hluboké znalosti – studie a rozpoznání variability jako společného návrhu systému nebo zvláštního a externího návrhu systému.

Vznikající výsledky mohou být ovlivněny architekturou kontextu pro komplexní adaptivní systém

Komplexní systémy mají počáteční podmínky a jednoduchá pravidla, které při iterativním spuštění dosahují postupně vznikajícího výsledku.Vznikající výstupy je obtížné či nemožné předpovědět při daných počátečních podmínkách.Počítačový vědecký experiment „The Game of Life“ (Hra života) je příkladem komplexního systému.Komplexní adaptivní systém nabízí určitou úroveň uvědomění, díky kterému dokáže zvážit, jak dobře jeho aktuální sada pravidel umožňuje dosáhnout požadovaného výsledku.Komplexní adaptivní systém se může rozhodnout přizpůsobit se sám – změnou svých jednoduchých pravidel – k uzavření mezery mezi aktuálním výsledkem a požadovaným výsledkem.Hra života je upravena tak, že pravidla, která by mohla být přepsána během hraní by mohla být komplexní adaptivní systém.

"Jednoduchá pravidla" komplexních adaptivních systémů v procesech vývoje softwaru jsou zásady, které tvoří definici procesu.Základní princip zde vychází z víry, že vývoj softwarových produktů a služeb není deterministickou činností a tudíž definovaný proces, který přizpůsobuje sám sebe neposkytne odpovídající reakce na nepředvídatelné události.Proto je třeba, aby proces navržený jako součást našeho systému myšlení a přístupu k navrhování byl přizpůsobivý.Přizpůsobí se prostřednictvím úpravy zásad, ze kterých je vytvořen.

Přístup Kanban k vývoji softwaru Lean využívá tento pojem zpracováním zásad pull systému kanban jako „jednoduchá pravidla“ a počáteční podmínky vizualizací práce a pracovního postupu, aby byl tok spravován pomocí systému dynamics a organizace používala vědecký přístup k pochopení, navrhování a provádění procesu vylepšení.

Respektujte ostatní

Společenství Lean přijala definici znalosti práce Petera Druckera, která uvádí, že zaměstnanci jsou dobrými zaměstnanci, pokud jsou zkušenější v oblasti své práce než jejich nadřízení.Tím se vytvoří dojem, že zaměstnanci jsou nejlépe nasazeni k přijímání rozhodování o provedení práce a postupu úpravě procesů ke zlepšení, jak je práce prováděna.Tak by měl být respektován hlas pracovníka.Zaměstnanci by měly být oprávněni sami organizovat dokončení práce a dosažení požadovaných výsledků.Mělo by jim být také umožněno navrhnout a zavést proces zlepšování příležitostí nebo „událostí kaizen“, jak jsou uvedeny v literatuře k metodice Lean.Nastavení zásad procesů jako explicitních, aby pracovníci byli informováni o pravidlech, která je omezují, je další způsob, jak je dodržovat.Jasně definovaná pravidla podporují vlastní organizaci odstraněním obav a potřebou odvahy.Respektování ostatních tím, že jim dodáte pravomoci a sadu výslovných zásad, odpovídá zásadním hodnotám respektování lidského faktoru.

Použijte vědeckou metodu

Snaží se používat modely k pochopení dynamiky dokončování práce a způsobu fungování systému v rámci vývoje softwaru Lean.Sledujte a studujte systém a jeho schopnosti a rozvíjejte a aplikujte modely pro odhad jeho chování.Sběr kvantitativních dat ve studii a použití těchto dat k pochopení, jak systém pracuje, a předpovídání, k jaké změně může dojít při změně procesu.

Software Lean a Společenství systémů používá statistické metody, jako je statistické zpracování kontrolních grafů a spektrálních analýz histogramů nezpracovaných dat pro dobu realizace a rychlost pochopení možností systému.Mohou také používat modely jako: Teorie omezení k pochopení kritických bodů; Systém důkladnějšího porozumění varianty vnitřního návrhu systému oproti té, která je ovlivněna externě; a analýza hospodářských nákladů ve formě úkolů prováděných pouze koordinací, nastavením, dodávkami nebo vyčištění po vytvoření produktu s hodnotou produktu nebo služby pro zákazníka.Některé jiné modely se začínají používat, například teorie skutečných možností usilující o používání skutečné rozhodování použijte možnost finanční teorie z řízení finančních rizik.

Navrhne vědecké metody: studium; postulace výsledku na základě modelu; narušení systému založené na předpovědi; a pozorování znovu k zobrazení rozrušení výsledků předpokládaných modelem.Pokud tomu tak není, zkontrolujeme naše data a zvážíme, zda je náš model přesný.Pomocí modelů na zlepšení procesu dojde k přesunu z aktivity založené na intuici k vědecké činnosti.

Podpora vedení

Vedení a řízení nejsou to samé.Správa je aktivita procesů navrhování, vytváření, úprav a odstranění zásad, strategické a operativní rozhodování, shromažďování zdrojů, poskytování financování a zařízení a sdělování informací o kontextu, například strategii, cílech a požadovaných výsledcích.Vedení znamená vizi, strategii, taktiku, odvahu, inovace, úsudek, hájení a mnoho dalších atributů.Vedení může a mělo by být realizováno kýmkoli v rámci organizace.Malé projevy vedení ze strany pracovníků budou mít za následek lavinu vylepšení, která dají vzniknout změnám potřebným k vytvoření procesu vývoje softwaru metodikou Lean.

Generovat viditelnost

Práce s poznatky je neviditelná.Pokud nějakou část nevidíte, je (téměř) nemožné ji spravovat.Je nutné zajistit přehled o prováděné práci a toku práce prostřednictvím sítě jednotlivců, dovedností a oddělení, dokud nebude dokončena.Je nezbytné umožnit pohled do návrhu procesu zjištěním způsobů zobrazení toku procesu a dosažením explicitnosti zásad procesu, aby je každý mohl poznat a zhodnotit.Pokud jsou všechny tyto věci jsou viditelné, pak je možné použít vědeckou metodu a konverzace o potenciálních zlepšeních přináší spolupráci a objektivitu.Zlepšení procesu spolupráce je téměř nemožné, pokud jsou práce a pracovní postup neviditelné a zásady procesu nejsou explicitní.

Zkrátit dobu toku

Povolání vývoje softwaru a vzdělání těch, kteří studii software engineering, se tradičně zaměřuje na měření času stráveného pracovní činností.Společenství vývoje softwaru Lean zjistilo, že může být užitečné měřit skutečný kalendářní čas uplynulý potřebný k dokončení jistých operací.To je obvykle označováno jako čas cyklu a obvykle kvalifikováno hranicí prováděných činností.Například, Čas cyklu analýzy připravenosti pro nasazení by měřil celkový čas analýzy, návrhu, vývoje, testování několika způsoby a zařazení pro nasazení pracovní položky, jakou je uživatelský příběh, ve výrobním prostředí.

Zaměřením na doby trvání pracovního toku fází procesu je důležité několika způsoby.Byla zobrazena korelace delších časů cyklu a nelineárním růstem počtu chyb.Proto kratší dobu cyklu vede k vyšší kvalitě.Toto je nelogické, protože se zdá směsné, aby mohly být chyby vkládány do kódu během jeho řazení do fronty, aniž by se ho kdokoli dotkl.Obvykle povolání softwarového inženýrství a vzdělání těch, kteří studují, nebere ohled na dobu nečinnosti.Empirické důkazy však ukazují, že doba cyklu je důležitá pro kvalitu.

Alan Shalloway rovněž zmínil koncepci „indukované práce“. Vypozoroval, že zpoždění v provádění úkolu může vést k tomu, že úkol vyžaduje mnohem větší úsilí, než by bylo nutné.Například, pokud je chyba nalezena a opravena okamžitě, může její oprava trvat 20 minut, ale pokud je chyba zatříděna a na vyřešení čeká několik dní nebo týdnů, může její oprava trvat mnoho hodin.Proto opoždění doby cyklu „vyvolalo“ další práci.Jelikož se lze této práci vyhnout, musí být považována za „plýtvání“.

Třetím důvodem zaměření na čas cyklu je důvod související s obchodem.Všechny prvky, funkce či články uživatele mají hodnotu.Tato hodnota může být nejistá, ale přesto je to hodnota.Hodnota se může časem lišit.Pojem hodnoty v průběhu času lze vyjádřit jako funkci hospodářské návratnosti trhu.Při pochopení funkce návratnost trhu práce položky i v případě, že funkce projevuje šíření hodnoty nejistoty model, je možné vyhodnotit „náklady na zpoždění“. Náklady na zpoždění umožňují vložit hodnotu na zkrácení doby cyklu.

Některé pracovní položky funkce návratnosti trhu nebudou spuštěny do známého data v budoucnosti.Například funkce určená k použití během svátku 4. července v USA nemá hodnotu před tímto datem.Zkrácení doby cyklu a schopnost předpovědi času cyklu s určitou jistotou je v tomto případě stále užitečné.V ideálním případě chceme zahájit práci tak, aby funkce byla doručena „přesně včas“, když je potřeba, nikoliv výrazně před požadovaným datem ani pozdě, jelikož pozdní dodání znamená náklady za zpoždění doručení.Dodání „just-in-time“ zajišťuje optimální využití dostupných zdrojů.Včasné dodání znamená, že jsme mohli pracovat na něčem jiném, přišli jsme tak o příležitost v důsledku zpoždění.

Z těchto tří důvodů vývoj štíhlého softwaru usiluje o minimalizaci doby zpracování a o zaznamenání dat, která umožňují předpovězení doby zpracování.Cílem je minimalizovat selhání z chyby, odpad z přetížení z důvodu zpoždění při opravě chyb, selhání poptávky a maximalizaci hodnoty dodané při vyhýbání se zpoždění a příležitosti nákladů na zpoždění.

Snížení odpadu ke zlepšení účinnosti

Pro každou aktivitu přidané hodnoty jsou nutné operace nastavení, vyčištění a doručení, které samy však hodnotu nepřidávají.Například, iterace projektu, která znamená zvýšení objemu pracovního softwaru, vyžaduje plánování (instalační činnost), větve prostředí a případně kódu v řízení verze (souhrnně označované jako správa konfigurace a instalační činnost), plán vydání a provedení skutečného vydání (činnost doručení), demonstrace pro zákazníka (činnost doručení) a případně demontáž nebo změna konfigurace prostředí (činnost vyčištění.) Když budeme hovořit v ekonomických termínech, činnosti okolo instalace, čištění a dodání jsou výdaje za transakce při provádění práce s přidanou hodnotou.Tyto náklady (nebo režijní náklady) jsou metodikou Lean považovány za plýtvání.

Jakoukoli formu komunikační režie lze považovat za plýtvání.Schůzky pro určení stavu projektu a naplánování nebo přidělení práce členům týmu by z hlediska ekonomiky byly považovány za náklady na koordinaci.Všechny náklady na koordinaci jsou ve štíhlém myšlení plýtvání.Metody vývoje softwaru Lean se snaží eliminovat nebo snížit náklady na koordinaci prostřednictvím umístění členů týmu do stejného místa, krátkých osobních schůzek, například sólových výstupů, a vizuální kontroly, například zdí s kartami.

Třetí společný formulář odpadů ve vývoji softwaru Lean je selhání poptávky.Poptávka způsobená selháním je zátěž pro systém vývoje softwaru.Poptávka způsobená selháním obvykle představuje opakovanou práci nebo nové formy práce, které jsou generovány jako vedlejší účinek nedostatečné kvality.Nejtypičtějšími formami selhání poptávky ve vývoji softwaru jsou chyby, výrobní vady a podpůrné činnosti zákazníka, při nedodržení zamýšleného používání softwaru.Procento průběhu práce, jež je selháním poptávky, je často označováno jako selhání zatížení.Procentuální hodnota přidané práce proti selhání poptávky je měřítkem účinnosti systému.

Procento zhodnocené práce proti celkové práci, včetně všech přidaných transakcí bez přidané hodnoty a koordinace nákladů, určující úroveň efektivity.Systém s žádnými náklady na transakci a koordinaci a bez zatížení při selhání bude považován za 100 % účinný.

Obvykle správa západní vědy předpokládá, že zvýšit efektivitu vyučovaných lze zvýšením velikosti dávky práce.Obvykle jsou opraveny náklady transakce a koordinace, nebo jen mírně vzrostly se zvýšením velikosti dávky.V důsledku toho jsou velké dávky práce efektivnější.Tento koncept se nazývá „úspory z měřítka“. V případě znalosti pracovních problémů mají koordinační náklady tendenci nelineárně stoupat s velikostí dávky, zatímco náklady na transakce často vykazují lineární nárůst.Proto není tradiční přístup 20. století k efektivitě vhodný pro problémy kvalifikované práce, jako je vývoj softwaru.

Pro zlepšení efektivity je lepší se zaměřit na snížení režijních nákladů při zachování malých šarží.Proto je štíhlou cestou k efektivitě snížení množství odpadu.Metody vývoje softwaru Lean se soustředí na rychlé, levné a rychlé metody plánování; komunikaci s nízkou režií; a efektivní mechanismy koordinace s nízkou režií, například vizuální kontrolu v systémech kanban.Mohou také podporovat automatické testování a nasazení, aby snížili náklady na transakce dodávek.Moderní nástroje pro minimalizaci nákladů na nastavení a zrušení prostředí, například moderní systémy řízení verze a využití virtualizace, také pomáhají zlepšit účinnost malých dávek vývoje softwaru.

Postupy

Vývoj softwaru Lean nepředepisuje postupy.Je důležitější ukázat, že aktuální definice procesů jsou v souladu se zásadami a hodnotami.Nicméně, běžně se přejímá velký počet postupů.Tato část obsahuje stručný přehled některých z nich.

Kumulativní vývojové diagramy

Kumulativní vývojové diagramy jsou standardní součástí vykazování v systému Team Foundation Server od roku 2005.Kumulativní vývojové diagramy vykreslují plošný graf kumulativní pracovních položek v každém stavu pracovního postupu.Jsou bohaté na informace a lze je použít k odvození cyklu střední doby mezi kroky v procesu a také propustnost (nebo „rychlost“).Různé procesy životního cyklu vývoje softwaru vedou k jiným vizuálním podpisům na kumulativních vývojových diagramech.Lékaři se mohou naučit rozpoznávat vzorky dysfunkcí v procesu zobrazeném v oblasti grafu.Skutečně štíhlý proces zobrazí rovnoměrně rozdělené oblasti barvy plynule stoupající rovnoměrným tempem.Obrázek se zobrazí hladký bez viditelných ostrých hran nebo barevných bloků.

Ve své nejzákladnější formě slouží kumulativní vývojové diagramy k vizualizaci množství probíhající práce v kterémkoli kroku cyklu pracovní položky.Lze rozpoznat problémová místa a sledovat účinky "mura" (variability toku).

Vizuální prvky

Kromě použití kumulativních diagramů vývoje používají týmy štíhlého vývoje softwaru i fyzické tabule nebo projekce promítacích systémů, aby si znázornily práci a sledovaly její tok.Tyto vizualizace pomáhají členům týmu pozorovat hromadění pokroku a umožnit jim problémové místa a účinky „mura“. Vizuální prvky také umožňují členům týmu organizovat se k práci a spolupráci bez plánování nebo zvláštního řízení směru nebo intervencí.Tyto vizuální prvky jsou často označovány jako „karty zdí“ nebo někdy (nesprávně) jako „desky kanban“.

Virtuální systémy Kanban

Systém kanban představuje postup převzatý z výroby metodikou Lean.Používá systém fyzických karet pro omezení množství prováděné práce v jakékoli fázi pracovního postupu.Tyto systémy průběhu práce vytvoří „pull“ kde nová práce je spuštěna pouze tehdy, je-li volný kanban označující, že nové práce může být „protlačena“ do určitého stavu a práce na něm pokračuje.

Při vývoji softwaru koncepce Lean jsou kanban virtuální a často jsou sledovány nastavením maximálního počtu pro daný krok pracovního postupu typu pracovní položky.V některých implementacích elektronické systémy sledují virtuální kanban a poskytují signál, pokud lze zahájit novou práci.Signál může být vizuální nebo ve formě výstrahy, například e-mailu.

Virtuální systémy kanban jsou často kombinovány s vizuální prvky, aby vytvořily virtuální vizuální systém kanban představující pracovní postup jedné nebo několika typů pracovních položek.Tyto systémy jsou často označovány jako „tabule kanban“ nebo „elektronické systémy kanban“. Vizuální virtuální systém kanban je k dispozici jako modul plug-in pro server Team Foundation Server nazvaný Visual WIP[20].Tento projekt byl vyvinut jako open source společností Hakan Forss ve Švédsku.

Dávky malé velikosti / tok jednoho kusu

Vývoj softwaru Lean vyžaduje, aby byla práce prováděna buďto v malých dávkách, často označovaných jako „iterace“ nebo „přírůstky“, nebo aby pracovní položky proudily nezávisle, což je označováno jako „jednokusový tok (single-piece flow)." Jednokusový tok vyžaduje složitou konfiguraci strategie řízení, která umožňuje dodání dokončené práce, když nedokončená práce není nešťastnou náhodou uvolněna.Toho je obvykle dosaženo pomocí větvení strategie v systému kontroly verzí.Malé množství práce se obvykle považuje za dávky, které mohou provádět malé týmy 8 nebo méně lidí za méně než 2 týdny.

Malé dávky a tok jednoho kusu vyžadují častou interakci s podnikovými vlastníky a tím doplnění rezervních položek, fronty nebo práce.Také požadují schopnost uvolňovat často.Pokud chcete povolit častou interakci s obchodní osobami a častým doručení, je nutné snížit náklady na transakce a koordinaci obou činností.Běžným způsobem k dosažení tohoto cíle je použití automatizace.

Automatizace

Vývoj softwaru Lean očekává vysokou úroveň automatizace, která ekonomicky umožní jednokusový tok (single-piece flow) a podpoří vysokou kvalitu a omezení selhání.Použití automatického testování, automatizované nasazení a produkce softwaru pro automatizaci zavedení vzorů návrhu a vytváření opakujících se sekcí s nízkou proměnlivostí částí zdrojového kódu bude běžné v procesech vývoje softwaru metodikou Lean.

Události kaizen

V literatuře týkající se koncepce Lean znamená termín kaizen "neustálé zlepšování" a událost kaizen je změna procesu nebo nástroj, který by měl vést ke zlepšení.

Procesy vývoje softwaru Lean používají několik různých aktivit ke generování událostí kaizen.Jsou uvedeny zde.Každá z těchto činností je určena ke stimulaci konverzace o problémech, které nepříznivě ovlivňují schopnost a v důsledku toho možnost splnění poptávky.Podstata metody kaizen v odbornosti práce je, že mezi skupinami lidí z různých týmů a různých kvalifikací musíme vyvolat konverzace o problémech.

Denní standup meetingy

Týmy vývojářů softwaru často až 50, se obvykle schází před systémem vizuální kontroly, například tabulí zobrazující vizualizaci jejich průběhu práce.Diskutují dynamiku toku a faktory ovlivňující tok práce.Zvláštní zaměření na externě blokovanou práci a práci zpožděnou z důvodu chyb.Problémy s procesem se často projeví po řadě schůzek.Výsledkem je, že menší skupina může po schůzce diskutovat o problému a navrhnout řešení nebo proces změny.Bude následovat událost kaizen.Tyto spontánní schůzky jsou ve starší literatuře často označovány jako spontánní kroužky kvality.Tyto spontánní schůzky jsou srdcem kultury skutečné metody kaizen.Manažeři podpoří vznik událostí metody kaizen po každodenních standup schůzkách, aby podpořili přijetí koncepce Lean v rámci organizace.

Retrospektiva

Projektové týmy mohou naplánovat pravidelná setkání tak, aby reagovaly na nejnovější práci.Jsou často provedeny po dokončení dodávek konkrétního projektu nebo po časově ohraničených přírůstků vývoje, známých též jako iterace nebo v agilním vývoji softwaru jako sprinty.

Retrospektiva obvykle využívá přístup reflexe anecdotal kladením otázek, jako např. „co šlo dobře?“, „co bychom mohli udělat jinak“ a „co bychom měli přestat dělat?“

Retrospektiva obvykle vytváří rezervy návrhů pro události kaizen.Tým pak může upřednostnit některé z těchto implementací.

Revize operací

Kontrola činností je obvykle rozsáhlejší než retrospektiva a zahrnuje zástupce z celého hodnotového proudu.Je společné až pro 12 oddělení pro prezentaci objektivních kvantitativních dat, která ukazují aktuální poptávku a jejich schopnosti tuto poptávku uspokojit.Revize operací probíhají většinou měsíčně.Klíčovými rozdíly mezi operacemi zkoumání a zpětnou působností je, že operace zkoumání pokrývá širší sadu funkcí, obvykle široké portfolia projektů a jiných iniciativ a používá objektivní, kvantitativní údaje.Retrospektiva má ve srovnání tendenci zaměřovat se na jediný projekt, využívá pouze několik málo týmů, jako např. tým pro analýzu, vývoj a testování a obecně využívá postupy anecdotal.

Kontrola činností vyvolá diskuse o dynamice ovlivňující výkon mezi týmy.Možná jeden tým způsobuje neúspěšnou poptávku, kterou jiný tým zpracovává?Možná tato neúspěšná poptávka ruší a je důvodem, proč druhý tým přichází o své závazky a nedaří se mu doručovat podle očekávání?Kontrola činností poskytuje příležitost k prodiskutovaní takových problémů a navržení změn.Revize operací většinou vytvářejí malé rezervní položky potenciálních událostí kaizen, u kterých mohou být stanoveny priority a plány pro budoucí implementaci.

Neexistují žádné takové věci jako jeden proces vývoje softwaru metodikou Lean.U procesu lze říci, že využívá metodiku Lean, pokud jasně vyhovuje hodnotám a principům vývoje softwaru Lean.Vývoj softwaru Lean nepředepisuje žádné postupy, ale některé činnosti se staly běžnými.Organizace uplatňující koncepci Lean se snaží podporovat metody kaizen prostřednictvím vizualizace pracovního postupu a prováděné práce prostřednictvím pochopení dynamiky toku a faktorů (například problémových míst, absence okamžité dostupnosti, variability a plýtvání), které je ovlivňují.Zdokonalení procesu jsou navrhována a odůvodněna coby způsoby snížení zdrojů variability, odstranění odpadu, zlepšení toku nebo zvýšení hodnoty dodání či řízení rizik.Procesy vývoj štíhlého softwaru se tak vždy budou vyvíjet a budou jedinečně přizpůsobeny organizaci, ve které se vyvíjejí.Nebude přirozené jednoduše zkopírovat definici procesu z jedné organizace do druhé a očekávat, že bude fungovat v jiném kontextu.Je také nepravděpodobné, že po návratu do organizace po několika týdnech nebo měsících bude používaný proces stejný jako proces pozorovaný dříve.Bude se vždy vyvíjet.

Organizace může být prohlášena za splňující metody Lean pomocí procesu vývoje softwaru metodikou Lean, pokud produkuje pouze malé množství odpadu ve všech třech formách metodiky Lean („mura“, „muri“ a „muda“) a může být prokázána optimalizace doručování hodnoty prostřednictvím účinného řízení rizika.Hledání dokonalosti v metodice Lean je vždy cesta.Neexistuje žádný cíl.Pravé štíhlé organizace vždy hledají další zlepšení.

Vývoj softwaru Lean je stále ještě nově vznikající oblast a lze očekávat, že se bude v následujícím desetiletí dále rozvíjet.

1. Anderson, David J., Kanban: úspěšné evoluční změny pro podnikové technologie, Blue Hole Press, 2010

2. Anderson, David J., Agilní správa softwarového inženýrství: aplikování teorie omezení obchodních výsledků, Prentice Hall PTR, 2003

3. Womack, James P. a Daniel T.Jones a Daniel Roos, The Machine That Changed the World: The Story of Lean Production, aktualizovaná verze z roku 2007, Free Press, 2007

4. Womack, James P. a Daniel T.Jones, Lean Thinking: Banish Waste and Create Wealth in your Corporation, 2. vydání, Free Press, 2003

5. Beck, Kent et al, Manifest agilního vývoje softwaru, 2001 http://www.agilemanifesto.org/

6. Highsmith, James A., Agile Software Development Ecosystems, Addison Wesley, 2002

7. Poppendieck, Mary a Tom Poppendieck, vývoj softwaru metodikou Lean: agilní sada nástrojů, Addison Wesely, 2003

8. Poppendieck, Mary a Tom Poppendieck, implementace vývoje softwaru metodikou Lean: od pojmu k hotovosti, Addison Wesley, 2006

9. Poppendieck, Mary a Tom Poppendieck, vedení vývoje softwaru metodikou Lean: cílem nejsou výsledky, Addison Wesley, 2009

10. Reinertsen, Donald G., Správa továrny na design, Free Press, 1997

11. Reinertsen, Donald G., Zásady toku vývoje produktu: druhá generace vývoje produktu metodikou Lean, Celeritas Publishing, 2009

12. Sutton, James a Peter Middleton, Lean Software Strategies: Proven Techniques for Managers and Developers (Strategie softwaru Lean: Osvědčené postupy pro manažery a vývojáře), Productivity Press, 2005

13. Anderson, David J., Agilní správa softwarového inženýrství: aplikování teorie omezení obchodních výsledků, Prentice Hall PTR, 2003

14. Shalloway, Alan a Guy Beaver a James R.Trott, vývoj štíhlého agilního softwaru: Dosažení flexibility korporace Addison Wesley, 2009

15. Larman, Craig a Bas Vodde, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum, Addison Wesley Professional, 2008

16. Postupy pro změny měřítka agilního vývoje a vývoje Lean: velký vývoj produktu na více pracovištích nebo mimo hlavní pracoviště s rozsáhlým Scrumem, Addison Wesley Professional, 2010

17. Coplien, James O.a Gertrud Bjornvig, Štíhlá architektura: pro vývoj agilního softwaru, Wiley, 2010

18. http://leansystemssociety.org/credo/

19. http://lssc12.leanssc.org/

20. http://hakanforss.wordpress.com/2010/11/23/visual-wip-a-kanban-board-for-tfs/