Hotovo a vráceno
Ken Schwaber a David Starr, Scrum.org
Leden 2012
Dodání hotového přírůstku je důležité pro úspěch vývoje agilního softwaru.Pomocí teoretických i skutečných příkladů autoři prokázali rozdíl mezi vnímáním „hotovo“ a skutečným stavem „hotovo“, a že má vliv na úspěch projektu.Pomocí těchto příkladů autoři přejdou k prokázání nástrojů a strategií, které pomáhají týmům začít s definicí dokončování, jež má pro ně smysl, a metod, kterými mohou týmy komunikovat ohledně posloupnosti, stavu a významu „hotovo“.
Platí pro
Správa životního cyklu aplikací; server Team Foundation Server
V tomto článku:
Úvod
Ve společnosti Anny byla ztracena transparentnost
Co si lidé mysleli, že se stalo
Co se skutečně stalo
Lekce
Technický dluh ve společnosti Nanomedtronics AZ
Co si lidé mysleli, že se stalo
Co se skutečně stalo
Lekce
Technický dluhu roste s více týmy
Plán vydání v A Datum Corporation
Co si lidé mysleli, že se stalo
Co se skutečně stalo
Lekce
Metody velkého rozsahu pro dokončování
Scrum Scrumů
Nepřetržitá integrace
Závěr
Scrum představuje opakující se, přírůstkové a agilní pracovní prostředí.Týmy to využívají k rychlému dodaní přírůstků „hotovo“ nebo potenciálně použitelné softwarové funkce každého opakování nebo sprintu.
„Hotovo“ představuje jednoduché slovo, které je však často špatně chápáno.Pro mě to znamená dokončeno, finalizováno a kompletní.Hotovo znamená, že nezbývá žádná další práce.Hotovo lze jednoduše definovat; dodání hotových přírůstků však zůstává jedním ze základních požadavků a nesnadných požadavků metody Scrum a agility.
Agilita vyžaduje dodání hotových postupných kroků pracovního softwaru připravených k použití v každém sprintu. Většina týmů Scrum a agilních týmů dokončení částečně, nekompletní přírůstky. Pokud je tým Scrum dotázán, proč požadavky rezervních položek produktu nebyly dokončeny během Sprintu, členové týmu často odpoví „Neměli jsme čas“.
Tento papír řeší problémy spojené s hotovými přírůstky prostřednictvím příkladu skutečných případových studií z počátků Scrum. Názvy a místa zúčastněných byly změněny, ale jsem si jistý, že osoby rozpoznají sami sebe i jejich tvrdou práci. V tomto článku jsou všechny Sprinty měsíční iterace, pokud není uvedeno jinak.
Ve společnosti Anny byla ztracena transparentnost
Anna potřebovala automatizovat příjem změn názvu vlastností pro své oddělení.Firma, pro kterou pracovala, vybudovala a provozovala plynovody napříč většinou Severní Ameriky.Její oddělení zpracovalo a zaplatilo poplatky lidem, kteří vlastnili půdu, kterou překřížilo.Základní informace Annina oddělení byla přijata formou výtisků listiny změny vlastnosti.Svazek se stával nadměrným, tak chtěla Anna automatizovat informační kanály a platební proces.
Náš tým pro vývoj navrhl, abychom pro Annu pomocí Scrumu sestavili honorářový systém.Tím bylo zajištěno, aby mohla mít použitelnou část softwaru ke kontrole všech měsíců.Má právo také každý měsíc změnit svůj názor na to, jak by náš tým měl dál postupovat.
Na konci třetího sprintu jsme měli vstup z jedné z provincií zavedený a integrovaný se staršími daty.To jsme prokázali pomocí jednoduchého řešení SQL.Anna byla potěšena, protože většina nevyřízených položek produktu jejích zaměstnanců byla z této provincie.
Chtěla po nás, abychom její zaměstnance naučili pracovat s jazykem SQL tak, aby mohli okamžitě začít používat software, který vývojářský tým poskytnul.
Co tím myslela, že to chce použít?Určitě nemluvila o dokončení sprintu jako o dokončení softwaru!
Řekli jsme to Anně co nejopatrněji.Byla rozlícená. "Co tím chcete říct, že to není hotovo?Viděl jsem první přírůstek, druhý přírůstek a teď je chci začít používat.Proveďte nasazení a naučte nás SQL používat.“
Začali jsme pociťovat neklid.Řekli jsme Anně, že, Ano, je to hotovo.Ale takto to hotovo nebylo.Bylo provedeno jako ukázka, ale stále zde byly problémy, které ještě vyžadovaly řešení, aby bylo možné software používat:
Nebylo možné zpracovat některé příchozí záznamy.Potřebujeme spíše zařízení pro ukládání a správu, než se jich zbavovat.
Několik polí v příchozí sestavě pravděpodobně slouží pro účely jiné, než jaké jsou uvedeny.Co s nimi můžeme udělat
Pole ve stávající databázi obsahují ukazatele nebo informace, které vypadají jako referenční informace.To bylo celé skrze databázi.
Když byly spouštěny příchozí kanály a byly odesílány požadavky na databázi, došlo několikrát ke zhroucení systému.Vypadá to, že při těchto pádech došlo k porušení dat.
Anna se nás zeptala, jak dlouho bude trvat, než to uděláme tak, aby to podle ní bylo hotovo, využitelně hotovo.Odhadovali jsme, že bude za potřebí dalších dvou Sprintů k uvedení přírůstků do použitelného stavu.Řekla, ať pokračujeme a vše připravíme pro její oddělení.Následně mě „požádala“, jestli bych se s ní příští ráno nesetkal.
Příští ráno tam byli Anna, její šéf a ředitel rozvoje.Vyjádřili své zklamání, že mnou nabídnutá průhlednost se neprojevila.Cítili, že bych měl zpracovat nevyřešené problémy jinak, než je pouze zaznamenat jako chyby.Došlo k vyrušení, protože průběh vyobrazený v sestavách burndown poskytnutých všem, byl nesprávný.
Po schůzce byly naše rozkazy k přesunu:
Zjistěte a opravte tyto čtyři chyby.
Dokončit a rozvrhnout první tři Přírůstky, aby je Annino oddělení mohlo začít užívat.
Zlepšili jsme naše technické dovednosti a automatizaci testování, takže naše definice dokončení byla stejná jako Annina definice (okamžitá použitelnost pro podnikání).
Změňte způsob, kterým jsme zaznamenali závady tak, aby nebyl požadavek považován za hotový, dokud nebudou opraveny.
Bylo nám sděleno, že se jedná o skvělou studijní příležitost, pokud se všichni naučíme požadované informace.
Co si lidé mysleli, že se stalo
Když jsme vytvořili směrný plán pro systém, namítaly zúčastněné strany a Anna, co by se mohlo stát.Vývojový tým ohlásil pokrok, který vypadal jakoby vydání bylo podle plánu a osoby zprávě důvěřovaly.
Vývojový tým se skutečně domníval, že dělá správnou věc, když ukázal, že práce postupovala podle předepsaného plánu.
Co se skutečně stalo
Rychlost je měřítko a historický záznam produktivity vývojového týmu na Sprint.Rychlost se měří v každém Sprintu a slouží k vytvoření vzorců produktivity.
Náš tým pro vývoj potřeboval ke splnění plánu stálou rychlost 8 dokončených pracovních jednotek za každý sprint.Když je něčím způsobena hrozba zpomalení rychlosti na hodnotu nižší než 8, nebudou dokončeny všechny práce na těchto položkách.
Dodali jsme také funkce, které fungovaly skutečně dobře, ale nebyly dostatečně celistvé, aby se daly použít nebo na nich stavět.Máme sklony odkládat zlepšování.Když přejdeme zpět k odhadu nedokončené práce, bylo přidáno dalších 14 jednotek práce.
S tím, jak složité byly úvodní kanály nadpisu, jsme přepracovali celý plán, aby odrážel pravděpodobný dvacetiměsíční vývin.Annino oddělení vydávalo přírůstky přibližně každé dva měsíce, což umožňovalo nové kanály.Nové automatické kanály snížily celkovou ruční práci tak výrazně, že bylo zklamáním, když životnost systému byla 22 měsíců od jeho spuštění.
Lekce
True průhlednost vyžaduje, aby kdokoli, kdo prohlíží přírůstek viděl a pochopil totéž.Transparentní ověření přírůstku by umožnilo Anně řídit riziko a získat předvídatelnost.Jelikož přírůstek nebyl transparentní, nemohla efektivně plánovat.
Na začátku projektu stanovila Anna dílčí cíl.Po sprintu 1 hodnotila pokrok směrem k cíli zkontrolováním toho, co považovala za užitečný krok.Rozhodla se, co ve sprintu 2 dělat, podle přírůstkového pokroku směrem k cíli.Kdyby si myslela, že náš postup byl neadekvátní, mohla projekt zrušit.
Na konci sprintu 3 Anna předpokládala, že 3/10 celku byly hotovy, což bylo zjevně nesprávně.
Bohužel jsme dokončili k prezentaci pouze rozsah každého přírůstku.Nedokončená práce způsobila, že přírůstky vytvořené Anniným oddělením jsou nepoužitelné a neprůhledné pro inspekci.
Neprůhlednost při kontrole přírůstku je stejná, jako byste přikryli termostat studenou, vlhkou žínkou.Termostat nechápe správně skutečnou pokojovou teplotu a mohl by zapnout vytápění, když by měl zapnout chlazení.
Bez přehledných přírůstky zainteresované osoby nemají přehled, co se skutečně děje a mohou nesprávně přijmout opatření, která nemají smysl.
Stručně řečeno, bez úplné transparentnosti není možná efektivní kontrola a adaptace týmů.
Technický dluh ve společnosti Nanomedtronics AZ
Technický dluh je odložená práce, která musí být dokončena před tím, než je software považován za dokončený.Technický dluh se projevuje v mnoha formách, jako jsou nekvalitní návrh, duplikace kódu a netestované funkce.Následující příklad ukazuje příčinu a dopad technického dluhu jako nedokončené práce během projektu.
Nanomedtronics AZ byla malá začínající softwarová společnost.Měli jeden tým Scrum pracující na nové verzi jejich životně důležitého produktu; softwaru, který je používán nano roboty k čištění ucpaných tepen pacientů trpících vysokým tlakem krve.
Co si lidé mysleli, že se stalo
Když tým započal, obdržel úkol s výběrem rezervních položek produktu, se kterými je třeba něco udělat (žádné další práce nezbývá, použitelné, potenciálně odeslatelné) do jednoměsíčního Sprintu. Vývojový tým měl všechny dovednosti k plnému rozvoji požadavků do dokončeného přírůstku.
Když tým Scrum zahájil první sprint, viděl, že je nutné provést 80 jednotek práce za 10 měsíců.Proto vývojový tým zodpovědně vybral 8 jednotek práce pro každý sprint.Odůvodnili to, pokud bylo protlačeno 8 jednotek na Sprint, měly by být hotovi za 10 měsíců přidělených společností.
Vývojový tým ukázal pracovní přírůstek na konci každého Sprintu.Podle veškerého vnějšího vzhledu metoda Scrum fungovala a společnost Nanomedtronics AZ měla stihnout dodat svůj produkt podle plánu.
Co se skutečně stalo
To co nebylo známo mimo vývojový tým byla skutečnost, že každý dodaný přírůstek ve skutečnosti zahrnoval některé nekvalitní implementace, nekritické chyby, opakovanou logiku a obecně nečistý kód.Dále, přírůstky nebyly plně testovány, protože Vývojový tým zastavil testování Sprint z důvodu časového stresu.Vývojový tým zaručil, že stihne své termíny a způsobem, jak toho dosáhnout bylo snižování kvality.
Tým pracoval tvrdě a vytvořil svůj produkt za více než 10 měsíců.Zákazník byl potěšen a připraven k implementaci a používání softwaru.Vývojový tým měl nahromaděno 48 jednotek nevykonané práce vrátit, jak ukazuje následující obrázek jako nový technický dluh.
.png "Dokončené a nedokončené práce")
Tým Nanomedtronics AZ nepovažoval veškeré činnosti a práce, které skutečně potřebují provést k dosažení výsledku, za nutné.Zahrnuje následující věci, které se týmu nepodařilo zvážit a nejsou v žádném smyslu vyčerpávající.Existuje mnoho dalších věcí, které by měly být zahrnuty.
Analýza
Návrh
Analýza závislosti
Testování výkonu
Testování stability
Refaktoring
Testování imunitní odpovědi
Integrace s prací všech dalších týmů, které pracují na produktu.
Testování integrace s prací jakýchkoli dalších týmů, takže přírůstek je souhrnem všech příspěvků týmu
Poznámky k verzi
Přizpůsobení pro šest kultur, kde bude produkt prodáván
Testování přijetí uživateli
Testování regrese
Revize kódu
Výše uvedená práce musí být dokončena, aby do konce sprintu vytvořila ucelený a integrovaný přírůstek.Většina Vývojových týmů však dokončí všechny výše uvedené práce.Nechají za sebou při každém sprintu nějakou „nedokončenou“ práci.Tím jsou vytvořeny přírůstky s nekvalitním návrhem, duplicitním kódem, příliš složitou logikou, netestovanými funkcemi či schopnostmi nebo jiná forma nedodělků.Jedná se o způsob, jakým týmy tvoří v softwaru technický dluh.
Společnost Nanomedtronics AZ zjistila, že její produkt obsahuje všechny funkce potřebné pro dodání zákazníkům, ale obsahuje také mnoho vad a postrádá balení a konečné zpracování potřebné pro uvedení produktu na trh.Vývojový tým nechtěně rezervu další práce, jejíž dokončení zabere dalších 6 měsíců, za předpokladu nesprávné rychlosti 8 jednotek na Sprint.
Čekat 6 měsíců dodání výrobku nebylo pro vedení společnosti přijatelné a produkt byl dodán se zbývající nedokončenou prací pouze po 3 měsících.Ztracený potenciál nebyl pouze 3měsíční zpoždění v dodání produktu, ale také pomalejší možnost přidat nové funkce, protože vývojový tým nyní musel zápasit s technickým dluhem v budoucích Sprintech.
Lekce
Technické dluh skryje skutečný pokrok i průhlednost vyžadovanou pro strategické rozhodování vlastníka produktu a zúčastněných stran.Technický dluh bude splacen buď záměrně v čase stráveném odstraňováním technických problémů nebo ztrátou kvůli pozdní dodávce či nízké kvalitě.
Ve většině situací zbývá při vydání produktu dodělat nejméně 50 % práce. Proto se nevykonaná práce stane součástí společnosti jako trvalý dluh.Technický dluh rychle způsobuje nestálost produktu a nakonec může vynutit negativní obchodní rozhodnutí, stejně jako v přepsání softwaru nebo zrušení produktu.
Technický dluhu roste s více týmy
Vývojový tým musí pečlivě určit pouze takové množství práce, jaké dokáže v rámci sprintu provést.Vývojový tým učí prostřednictvím svých zkušeností, kolik je to práce.Tým má stále využívat moderní technologie výrobních postupů, například automatické sestavení a regresní testování, aby dosáhl co nejvíce všeho.Pokud tito nejsou zapojeni, manuální práce většinou zdolá tým u čtvrtého nebo pátého běhu.
Zvažte vývojový tým se třemi programátory a dvěma specialisty QA.Každý den programátoři zaznamenávají kód do systému zdrojového kódu.Je testován a jsou zjišťovány chyby, které budou předány správnému programátorovi.Mezi přihlášením kódu a zjištěním a hlášením vad uplyne jistý čas.Během této doby mohou jiní programátoři vrátit kód se změnami provedenými na chybném kódu.Úsilí nutné k odstranění počátečních potíží je nyní větší.Kdyby Vývojový tým měl nepřetržitou sestavu a zkušební zařízení, chyba by bývala byla zjištěna okamžitě. Lidé by jej mohli prozkoumat, opravit a pokračovat.Práci navíc a plýtvání se lze vyhnout.
Mnoho organizací používá k sestavování softwaru více než jeden Scrum Team.Pokud k tomu dojde, problém technického charakteru, který byl popsán v části výše, se značně rozšíří.Příležitosti k rezervaci kódu na základě vadného kódu jsou výrazně větší.Náklady k nápravě rostoucí zranitelnosti přítomného softwaru rostou exponenciálně s postupem prací.
Plán vydání v A Datum Corporation
Nedávno jsem pracoval s jinou společností, vyvíjeli software pro infrastruktury. Budu jim říkat Datová společnost.Hlavní produktová výroba zaměstnává více než 800 vývojářů, včetně 250 programátorů. Rozvoj infrastruktury byl částečně automatizovaný a částečně ruční.Testování často zaostávalo kvůli kódování podle dnů.Čas mezi rezervací vadného kódu programátorem a jeho zjištěním byl často deset nebo více dnů.
Pokud chcete omezit komplexnost tolika programátorů, pracovali jednotlivé vývojové týmy na svém vlastním kódu pobočky.Vedoucí vývoje pomohli uspořádat požadavky rezervních položek a minimalizovat tak závislosti. Pokud každý Vývojový tým každý den sloučí svůj hlavní kód do hlavní kódové řádky každý den, minimalizuje se množství potenciálně opakované práce.
Správa se však domnívala, že by to trvat příliš dlouho.Správa rozhodla sloučit všechny větve kódu do kořenové větve každý třetí Sprint.Zkoušky integrace zjistí všechny vady, které budou poté opraveny. Verze Release candidate bude připravena na konci každého třetího měsíce.
Co si lidé mysleli, že se stalo
Následující obrázek znázorňuje plánované vydání plánu a cyklu.
.png "Plánování plánované verze a cyklu")
Původní plán předpokládá, že:
9 sprintů
3 verze Release Candidate a poté úplná verze
Vývojová organizace s 800 zaměstnanci
Co se skutečně stalo
Pokud je při této organizaci datum vydání po devítiměsíčních sprintech, produkt nebyl připraven k vydání.Šestá verze Release Candidate měla více než 5 000 závad a více než 2 000 požadavků na rezervní položky bylo neúplných.Zajímalo nás, jak k tomu mohlo dojít.Každý třetí měsíc jsme viděli verzi Release Candidate.Při prozkoumání zjistíme, že ukázky pochází od jednotlivých vývojových poboček týmu.Nedošlo k žádné integraci.Nedošlo k žádnému testování integrace.
Pokud chcete zachovat požadovanou rychlost do data vydání, vývojové týmy odloží veškerou integrační práci a tím vytvoří velké množství technického dluhu.Výsledkem bylo osmiměsíční odchylka od naplánovaného data vydání.Slova „release candidate“ neměla žádný význam.
Následující obrázek znázorňuje skutečný projekt a dobu potřebnou pro stabilizaci.
.png "Skutečný projekt plus doba potřebná pro stabilizaci")
Verze Release Candidate byly částečně funkční z větve kódu pro každý tým.Před vydáním byla vyžadována doba pěti měsíců „stabilizace“.Jedním z obzvláště nepříjemných problémů, který pozdržel dodávku více, než ostatní, byl „nízký výkon“. Tento problém byl nahlášen v rámci prvního sprintu.
Lekce
Různé týmy pracující se stejným softwarem nakonec svou práci sloučí.Integrace softwaru pro zajištění jeho fungování snižuje riziko integrací a měla by se provádět pravidelně.
Čekání na sloučení práce více týmů je lákavé, protože umožňuje opoždění nákladů na sloučení.Tyto konečné náklady na zpoždění jsou však vynaloženy počtem zúčastněných týmů a počtem poboček, které musí být integrovány.
Metody velkého rozsahu pro dokončování
Je obtížné dosáhnout stavu „Hotovo“ ve více týmech.Je zapojeno mnoho složitostí.Existují závislosti mezi týmy a mezi větvemi kódu.Přestože tato míra složitosti představuje náklady, je dosažitelná a nabízí skvělou hodnotu, když synchronizované týmy dodávají výsledky ve společném rytmu.
Existuje několik postupů, které mi připadají užitečné při spolupráci více týmů.
Scrum Scrumů
Pokud na stejném projektu pracuje více týmů Scrum, potřebují techniku, která umožňuje koordinovat jejich práci.Doporučuji „Scrum ze Scrumu“. Jde o každodenní událost, která se uskutečňuje neprodleně po denním Scrumu týmu.Zúčastní se někdo technicky založený z každého týmu.Každý zástupce týmu popíše, na čem jejich tým právě pracoval.Člen poté popíše, na čem plánuje během nadcházejícího dne pracovat.Na základě těchto informací se zástupci pokusí identifikovat veškerou potřebnou opakovanou práci, všechny nadcházející závislosti a veškerou práci, kterou může být nutné znovu naplánovat.
Scrum Scrumů byl užitečný v mnoha organizacích.To je však nedostatečné.Závislosti a opakovaná práce mohou či nemusí být úspěšně identifikovány, protože problémy jsou předpokládány, nikoli známy.Nečekané závislosti způsobila přepracování a selhání testů.Některé týmy stráví více než 50 % každého Sprintu prací a přepracováním závislostí.
Nepřetržitá integrace
Extrémní programování (XP) vyžaduje nepřetržitou integraci a testování integrace práce týmu.Proč nerozšířit tuto možnost na všechny týmy?Ať už se jedná o dva nebo padesát týmů, jsou týmy povinny vytvářet integrované a testované přírůstky na konci každého sprintu.Provedete to tak, že týmy budou často integrovat svoji práci.Protože veškerá neintegrovaná práce může potenciálně skrývat nevyřešené závislosti, nejlepším řešením je kontinuální integrace.
Nepřetržitá integrace veškeré práce je podobná štíhlým postupům výroby.Na linkách využívajících koncepci Lean se používá mnoho postupů pro posouzení jakosti výrobku v celém procesu výroby.Pokud dojde k odchylkám nebo problémům s kvalitou, dojde k zastavení výrobní linky.Nepřetržitá integrace a testování integrace poskytují stejné postupy pro vývoj softwarového produktu.
I když je to těžké, doporučuji, aby každý tým a člen týmu přestali s kódováním, jakmile selže souvislá sestava nebo test.Veškerá pokračující práce představuje potenciální stavění na závadách, což způsobuje zvlněný efekt chyb.Pokud je užívána nepřetržitá integrace, týmy úzce spolupracují, aby vyloučily chyby při integraci.Jejich pracovní návyky se zlepšují, odpad se sníží a zvyšuje se kvalita.
Většina organizací, které přijmou Scrum, nezačíná se všemi technickými dovednostmi a nástroji pro sestavení hotového přírůstku. K dosažení hotových přírůstků musí být spuštěn a dodržován přísný program.Skupiny méně než padesáti osob mohou velmi rychle dosáhnout stavu, kdy v rámci Sprintu dokončují přírůstky.Organizace s více než 500 vývojáři často vyžadují několik let na to dostat se do tohoto bodu.
Nedokončené přírůstky produkují plýtvání a brání týmu dosažení skutečné flexibility.Skutečné náklady na nedokončenou práci jsou mnohem více než nedostatečné na funkci nebo přírůstek funkce.Náklady zahrnují odpady na přeplánování a opětovnou tvorbu, pokud přírůstek není skutečně dokončen, stejně jako náklady na nižší předvídatelnost a vyšší riziko.
Mnoho organizací požaduje výhody agility a využívá Scrum k jejich získání.Dodání hotového přírůstku je důležité pro úspěch vývoje agilního softwaru.Týmy by měly začít s definicí dokončeno, jež jim smysl a záměrně definici časem rozšiřovat.Teprve potom dosáhnou originální flexibility.
Viz také
Koncepty
Spolupráce (podrobnější informace) [přesměrováno]
Správa a odhadování nevyřízených položek