Čtení čas: 13 minut
agilní přístup k vývoji software, je již dlouho běžnou praxí. Podle průzkumu HP online se 16 procent IT profesionálů rozhodne pro čistě agilní, 51 procent se k němu přikloní a 24 procent přijme agilní hybridní přístup. Dnes je vývoj vodopádů nejčastěji zmiňován jako agilní diferenciátor, co agilní není. Široce jsme diskutovali o hlavních rozdílech v našem whitepaperu o metodikách agilního řízení projektů.
navzdory přizpůsobivosti a flexibilitě agilního řízení a jeho rychlé reakci na změny může pracovní postup zůstat centralizovaný a kontrolovaný. Agilní KPI (klíčové ukazatele výkonnosti) poskytují vodítko pro strategické plánování, hodnocení a zlepšování provozních procesů.
tradiční systémy správy hodnot se obvykle zaměřují na dokončení úkolů v rámci kategorického harmonogramu a nákladů. S agile však zákazníci a členové týmu vidí okamžité výsledky a upravují časové rámce a úsilí o dodání produktu, který odpovídá požadavkům harmonogramu. Jaké nástroje a techniky tyto znalosti vyžadují? Zde je náš přehled hodnocení výkonnosti metrik agilního vývoje.
KPI agilního vývoje softwaru
v tomto článku nebudeme zkoumat všechny možné metriky agilního vývoje a KPI. Kromě toho můžete vymyslet své vlastní, které nejlépe odpovídají vašemu projektu. Popíšeme však nejběžnější KPI používané v různých aspektech vývoje softwaru:
- Rychlost
- Sprint počítá
- Uvolnění počítá
- doba Cyklu
- Kumulativní tok
- Tok účinnost
- pokrytí Kódu automatickými testy
- Test automatizace proti manuální testování
- McCabe Cyclomatic Složitost (MCC)
- Kód konve
toto jsou klíčové ty, které musíte prozkoumat první
Měření práce v pokroku
Rychlost
Rychlost měří množství práce (počet funkcí) dokončena ve sprintu. I když to není predikce nebo srovnávací nástroj, velocity poskytuje týmům představu o tom, kolik práce lze udělat v příštím sprintu.
index rychlosti je jedinečný pro každý tým a měl by být nastaven tak, aby posoudil, jak realistický je závazek. Například, pokud je projekt nevyřízených příběh má 200 bodů a v průměru tým dokončí 10 příběh bodů za sprint, to znamená, že tým bude vyžadovat asi 20 sprinty na dokončení projektu.
Čím déle budete sledovat rychlost, vyšší přesnost korespondence mezi závazky a náklady
tým, který je prostě přijala agilní metodiky, nebo dokonce pustil na nový produkt, rychlost odhady prvních několika sprinty bude pravděpodobně být nevyzpytatelné. Ale jak týmy získávají zkušenosti, rychlost bude vrcholit a pak dosáhne plató předvídatelného toku a očekávané výkonnosti. Snížení konzistentního toku bude znamenat problémy ve vývoji a odhalí potřebu změny.
Tipy pro použití metriky rychlosti
bojové nekonzistence po 3-5 sprintech. Pokud rychlost zůstane nekonzistentní po dlouhé době, zvažte posouzení vnějších i vnitřních faktorů, které brání jasnému odhadu.
změňte sledování rychlosti po týmových a úkolových změnách. Když člen týmu opustí projekt nebo je přidáno více členů / úkolů, přepočítejte rychlost nebo restartujte výpočet úplně.
pro včasné předpovědi stačí tři sprinty. Pro předpovídání budoucích výkonů použijte průměr ze tří předchozích sprintů.
Sprint počítá chart
sprint počítá chart ukazuje množství zbývající práce být hotové do konce sprintu. Tento nástroj je obzvláště cenný, protože zobrazuje pokrok směrem k cíli namísto výpisu dokončených položek. Je to také velmi užitečné při odhalování plánovacích chyb, které tým udělal na začátku sprintu.
Na níže uvedeném grafu je černá čára představuje předpokládané (ideální trend) v řádku ukazuje, na které hodnotit tým potřebuje spálit příběh body k dokončení sprintu na čase. Modrá čára označuje celkové množství práce a její průběh v průběhu sprintu. Je vidět, že během pěti a šesti dnů se jednomu týmu nepodařilo dosáhnout předpokládaného postupu. Sedmý den se však problém řešil a práce se opět rozjely. Tyto průběžné aktualizace umožňují týmům řešit vznikající problémy během každodenních stand-up setkání.
Kromě toho pracovní výkon sám o sobě, počítá grafy mohou odhalit otázky plánování
Tipy na přístup sprint počítá
Příběh body by měly být i v rozsahu. Pokud pracovní postup není konzistentní, některé úkoly mohly být rozděleny na nerovnoměrné kousky. Rozsah odchylky mezi ideálním trendem a realitou tento problém zřetelně zdůrazňuje.
účet pro neplánované úkoly. Burndown graf je užitečný pro pochopení rozsahu skrytých a nesledovaných úkolů. Pokud se množství práce zvyšuje místo snižování, má Projekt mnoho nedoceněných nebo neplánovaných úkolů, které by měly být řešeny.
použijte tabulku vyhoření k posouzení důvěry týmu. S ohledem na aktuální sazby, zeptejte se svého týmu, jak si jsou jisti, že dokončí sprint včas. Čím déle tuto metriku použijete, tím přesnější jsou vaše odhady sprintu.
Odhad vydáním se počítá chart
uvolnění počítá graf ukazuje množství práce, která musí být dokončena před vydáním. Graf znázorňuje přehled pokroku a umožňuje implementovat změny pro zajištění včasného doručení.
tradiční verze grafu je podobný sprint počítá chart, ale dává přehled o celém projektu, kde osa y je sprinty a na x-ose je míra zbývající práce (dnů, hodin, nebo příběh bodů). Ale co když se do projektu přidá více práce nebo vaše odhadovaná práce nesplňuje očekávání?
v tabulce níže tým plánoval dokončit projekt ve čtyřech sprintech a zpočátku měl 45 příběhových bodů. Zatímco během prvního a druhého sprintu postupoval podle plánu, při třetím sprintu se odhadovaná práce zvýšila, což se odráží na ose y v záporných hodnotách. Během třetího sprintu se objevilo 5 nových příběhových bodů. Nedokončili a čtvrtý sprint přidal dalších 5 bodů. Proto musel být upraven postup a doba vydání.
uvolnění počítá grafu je super efektivní v situacích, se spoustou měnící se požadavky a umožňuje tým, aby zůstali na trati v průběhu každého sprintu
Jak může propuštění počítá graf pomoc?
real-time predikce na vydání. Jakmile váš projekt projde změnami, což se děje pokaždé s iterativně vyvíjejícími se produkty, musíte vidět, jak tyto změny ovlivňují datum vydání. Graf vyhoření vydání umožňuje předpovídat datum vydání v reálném čase podle aktualizací v pracovním rozsahu.
termínové předpovědi. Můžete odhadnout, zda tým může dokončit vydání produktu včas, nebo předvídat, že termín by se měl posunout dále s ohledem na přidané úkoly.
odhad počtu sprintů. Posouzení, jak mnoho sprinty jsou nutné k dokončení práce je také důležitým faktorem, aby zvážila s vydáním počítá grafu.
Hodnocení procesu zdraví a nalezení úzkých míst
doba Cyklu
doba cyklu metrika popisuje, kolik času jste strávili na úkolu, včetně pokaždé, práce musela být znovu otevřena a úspěšně absolvováno znovu. Výpočet doby cyklu poskytuje informace o celkovém výkonu a umožňuje odhadnout dokončení budoucích úkolů. Zatímco kratší doba cyklu ilustruje lepší výkon, týmy, které poskytují v rámci konzistentního cyklu, jsou oceňovány nejvíce.
pomocí níže uvedeného grafu můžete určit průměrnou dobu potřebnou k dokončení úkolu, nakreslit střední nebo kontrolní mezní čáru, která by neměla být překročena, a všimnout si, které úkoly trvalo neobvykle dlouho.
směrodatná odchylka kreslí čáru mezi normální a nedoporučuje se počet dní k dokončení úkolu
můžete také zásobník cyklů pro konkrétní období a čerpat poznatky z porovnávání s ostatními daty. Provedením dalšího šetření můžete vyvodit závěry o kvalitě práce.
Tady můžete vidět, že počet dokončených úkolů od Března do června vzrostl, stejně jako počet chyb
Jak používat čas cyklu
Podívejte se na podobnosti. Dobrou praxí je najít podobné položky, které vyžadují nepředvídatelné doby cyklu k dokončení, odhalující opakující se problémy, a to buď ve strojírenství nebo řízení.
nakreslete předpovědi. Rozhodnutí založená na datech můžete provádět předpovídáním času na dokončení nových úkolů na základě podobných úkolů z minulosti.
Sledujte tempo. Graf popisuje, jak udržujete stejné tempo práce a definujete, zda existují vnitřní problémy, které snižují rychlost práce.
Kumulativní Flow Chart (CFC)
kumulativní tok metrika je popsána oblast grafu zobrazující počet různých typů úkolů v každé fázi projektu s x-osy s uvedením data a na ose y ukazuje počet příběh bodů. Jeho hlavním cílem je poskytnout snadnou vizualizaci toho, jak jsou úkoly distribuovány v různých fázích. Řádky na grafu by měly zůstat víceméně i v době, kdy by kapela s“ hotovými “ úkoly měla neustále růst.
graf odhaluje mnoho důležitých informací, jako jsou náhlé překážky nebo stoupá v kterémkoli z kapely
CFC bude mít velké využití pro Kanban týmů jako jednoduchý vizualizační práce týmu. Graf také odpovídá Kanbanovu třístupňovému pracovnímu postupu. Zde také mapujete tři hlavní kategorie úkolů: úkoly, probíhající a dokončené.
kromě toho graf pomáhá určit, kdy jsou překročeny limity WIP (work-in-progress). Jako jeden z nejcennějších nástrojů v agilním vývoji jsou limity WIP určeny k kultivaci kultury dokončovacích prací a eliminaci multitaskingu nastavením maximálního množství práce pro každý stav projektu.
na jaké problémy CFC poukazuje?
- Zpoždění růstu označuje nevyřešené úkoly, které jsou buď příliš nízkou prioritou řešit na chvíli, nebo jsou zastaralé
- Nekonzistentní tok a náhlé překážky uvést, které oblasti by měly být vyhlazeny ven v pozdějších fázích
- šířka každá kapela ukazuje, průměrná doba cyklu
- významné rozšíření „In progress“ oblasti může znamenat, že tým nebude schopen dokončit celý projekt na čas
Tok Účinnost
Tok účinnost je velmi užitečné metriky v Kanban vývoj většinou přehlížena rozvoj jednotka. Zatímco účinnost toku doplňuje kumulativní tok, poskytuje přehled o rozdělení mezi skutečnou prací a čekací dobou. Je to vzácný případ, kdy vývojář pracuje na jedné věci najednou bez čekání. Realita je obvykle složitější. A „work-in-progress“ je jméno, které ne vždy odpovídá stavu.
například, kód může mít mnoho závislostí a můžete začít pracovat s nějakou funkcí, než ten další je hotový, nebo se ti změní priority, nebo čekáte na zúčastněných schválení. Měření, kolik času čekáte na práci, může být ještě užitečnější než zefektivnění procesů souvisejících se skutečnou prací.
při pohledu na nejnižší ukazatele účinnosti, můžete pochopit hlavní překážky
Jak používat tok účinnost
vzorec pro Výpočet. Pokud nepoužijete nějaký software pro správu projektů, který obsahuje tyto metriky, můžete vypočítat efektivitu toku pomocí tohoto jednoduchého vzorce: práce / (práce+čekání) * 100%. Pak si jej můžete vizualizovat digitálně nebo dokonce nakreslit graf na tabuli v kanceláři.
Definujte svou normální účinnost toku. Stejně jako u všech ostatních metrik není možné nárokovat normální čísla pro všechny projekty. Někteří říkají, že 15 procentní známka je pro většinu projektů v pořádku, což v podstatě znamená, že příběh nebo jiný předmět práce čeká 85 procent oproti 15 procentní době zpracování. David J. Anderson, odborník na management z LeanKanban School of Management, naznačuje, že 40 procent a vyšší by mělo být cílem pro většinu týmů.
před stanovením účinnosti toku rozložte podrobnosti o práci. Graf umožní zobrazení přesných časových období, kdy byla vaše účinnost nejnižší. A tato data musí být analyzována velmi pečlivě, protože skutečná příčina a její náprava není odhalena tak snadno. Než začnete intenzivní akce, důkladně prozkoumejte příčiny.
zvýšení účinnosti toku pomocí blokovací analýzy. Dobrým prostředkem k realizaci předchozího bodu je zvýšit efektivitu toku pomocí blokovací shlukovací analýzy. Pokud je nějaká práce zablokována, zaslouží si barevnou nálepku nebo jinou formu vizuálního signálu, aby tyto blokátory upozornily tým, aby na ně mohli reagovat.
můžete označit kolik dní některé práce je blokován a priority řešení
Obvykle, blokátory se hromadí ve shlucích, protože mají mnoho závislostí s sebou. Lepší analýzu blokátorů lze provést, pokud je shlukujete od podobností na vysoké úrovni, jako jsou interní a externí blokátory, a poté upřesníte další design, chybějící obsah nebo jiné chybějící funkce. Blokovací analýza je jednoduchý způsob, jak prozkoumat údolí v účinnosti toku.
měření kvality kódu
pokrytí kódu
pokrytí kódu určuje, kolik řádků kódu nebo bloků se provádí za běhu automatizovaných testů. Pokrytí kódem je kritická metrika pro testovací vývoj (TDD) a nepřetržité doručování. Tradičně je metrika interpretována jednoduchým přístupem: čím vyšší pokrytí kódem, tím lépe. K měření budete potřebovat jeden z dostupných nástrojů, jako jsou kombinézy. Ale všechny fungují téměř stejně: Při spuštění testů nástroj zjistí, který z řádků kódu je volán alespoň jednou. Procento volaných řádků je pokrytí vašeho kódu.
Kombinézy, například, bude prolomit pokrytí kódu se každý soubor měření a zvýraznit kryté a nekryté linky
Jak používat pokrytí kódu
Zaměřit se na odkryté linie a nepřeceňujte něž ty. Pokud řádek kódu je volána jednou nebo i více, nemusí to nutně znamenat, že funkce podporuje funguje velmi dobře a uživatelé budou zůstat spokojeni. Volání řádku kódu není vždy dostačující k uzavření testovací úlohy. Na druhou stranu procento nekrytých linek ukazuje, co vůbec nebylo pokryto a může si zaslouží testování.
upřednostněte krytý kód a nezaměřujte na 100 procent. I když se to zdá neintuitivní, 100% pokrytí neznamená, že jste správně testovali kód. Váš projekt má kód, na kterém záleží, a zbytek kódové základny. Protože automatizace testování je obvykle nákladná iniciativa, měla by upřednostňovat funkce a odpovídající části kódu.
Test automatizace proti manuální testování
Toto měření určuje, kolik řádků kódu uvnitř funkce jsou již pokryty automatizovaných testů proti těm, které jsou testovány ručně. To přímo navazuje na předchozí metriku, ale má konkrétní případ použití. Podíl automatizace testu proti ručnímu testování se používá pouze tehdy, když kriticky potřebujete automatizaci k pokrytí regresí. Regresní testování se provádí za účelem ověření, zda se po aktualizaci funkcí něco zlomilo. A pokud váš produkt prochází neustálým zlepšováním-což by měl-testování regrese by mělo být automatizováno. Pokud tomu tak není, vaši manuální specialisté QA budou muset opakovat stejné testovací scénáře opakovaně po každém odevzdání aktualizace.
můžete použít stejné nástroje používané pro pokrytí kódu čerpat tato metrika
Navrhovat automatizovaný test pokrytí na funkce vám umožní upřednostnit vlastnosti, že 1) může trpět z regrese po změnách, a 2), pro které automatické testy jsou rozhodující. Obvykle nemáte dostatek času a lidských zdrojů na pokrytí všeho automatizovanými testy najednou, pokud nepracujete v rámci vývojového rámce založeného na testech. Je tedy lepší upřednostnit funkce, které jistě ovlivní uživatelský dojem.
McCabe Cyclomatic Složitost (MCC), kód
Kód složitost měření se používá pro posouzení rizika problémů při testování kódu a údržbu. Čím vyšší je složitost kódu, tím obtížnější je zajistit, aby měl přijatelný počet chyb a udržoval vysokou udržovatelnost. Nejběžnějším přístupem k měření složitosti kódu je McCabe Cyclomatic Complexity Metric (MCC). Jedním ze vzorců pro kreslení výsledků složitosti pro MCC je následující:
MCC = hrany – uzly + return prohlášení
MCC na obrázku se rovná 3
S tímto metrické, vývojáři nejsou odhadu jejich kód složitost tím, že subjektivně se na to dívat. Jako inženýři skillsets liší, jejich hodnocení liší, což dělá kód refactoring nebo opravování chyb náročnější v dlouhodobějším horizontu. Na trhu existuje mnoho nástrojů pro měření MCC, které lze kombinovat s dalšími metrikami složitosti kódu, jako je hloubka hierarchie kódu a počet řádků kódu.
MCC použít specifika a úskalí
Bilance lidské a strojové vnímání kód složitosti. Jedním z hlavních důvodů pro použití MCC je, aby kód čitelný pro kolegy vývojáře. Čitelnost kódu snižuje riziko dlouhodobého nástupu nových vývojářů, kteří se musí vypořádat se starším kódem. Zjednoduší také refaktorování po silnici. Problém je v tom, že model MCC může považovat některé složité, ale čitelné metody za nepřijatelné. A pokud jste vývojář refaktorovat komplexních metod do mnoha dílčích metod, můžete dosáhnout opačný výsledky: Mnoho metod, pomocí jednoduché logiky se může stát ještě více obtížné pochopit pro člověka než jeden, ale komplexní metodou.
nedělejte z MCC omezující metriku. Některé organizace praktikují ukončení kódových závazků, které neprošly testem MCC. I když to může potenciálně zvýšit jednoduchost kódu, je přirozené mít komplexní kód na úrovních tříd, metod a funkcí. Jejich úplné blokování není vždy prospěšné. Dobrou praxí je nastavit pro vývojáře obecnou složitost kódu KPI, což je povzbudí k vědomějšímu přístupu ke kódování a přemýšlení o jednoduchosti.
použít MCC pro kontrolu kódu. Další cennou praxi pro MCC testů je aplikovat během zákoníku recenze zúžit rozsah práce, na přezkoumání konkrétní kusy kódu, kde jsou rizika vad jsou nejvyšší.
Kód konve
Kód konve je velmi užitečné vizualizace trendů a výkyvů, které stát kód základny a to jak z hlediska celkového procesu a času, než uvolnění. Churn měří, kolik řádků kódu bylo přidáno, odstraněno nebo změněno. Grafy někdy zobrazují všechna tři měření.
Tento příklad z Microsoft zahrnuje všechny tři parametry, ale můžete je použít selektivně
i když měřicí kód máselnice může zdát poněkud primitivní, metrické, to umožňuje pro posouzení kód stability v různých fázích rozvoje. Měli byste očekávat nejnižší stabilitu během prvních sprintů a nejvyšší stabilitu – se současným nejnižším vírem – těsně před uvolněním. Pokud je váš kód vysoce nestabilní a datum vydání se blíží, zvuk alarmu.
Code churn případy použití
hledat zákonitosti. Pravidelné špičky změn kódu mohou odhalit, že přístup generování úkolů není dostatečně zaměřen a opakovaně vytváří mnoho velkých úkolů.
nepravidelné, ale vysoké hroty vyžadují vyšetřování. Máte-li nepravidelné, ale silné hroty v změny kódu, můžete zjistit, které úkoly způsobilo seismické vrcholy v kódu a přehodnotit míru závislosti, a to zejména, když počet nových řádky kódu zvýšil počet změněných řádků, stejně.
věnujte pozornost trendům. Stabilita vašeho produktu se před vydáním stává velmi kritickou. Jak jsme již zmínili, míra churn by měla mít klesající trend, čím blíže se Váš tým dostane k vydání. Rostoucí trend znamená možnou nestabilitu produktu po vydání, protože je pravděpodobné, že nový kód nebude podroben dostatečnému testování.
Usilovat o pokrok, ne kontrolu
Stejně jako všechny ostatní ukazatele výkonnosti, agilní metriky ne vždy mají odlišné odpovědi nebo žalovatelné tipy, které zpečetí váš úspěch. Měli byste však využít znalosti, které poskytují, k zahájení diskuse, provedení hodnocení a nabídnutí vlastního plánu při řešení problematických otázek.
zatímco metriky poskytují numerický pohled na výkon týmu a celkovou spokojenost s prací, nezaměřujte se na ně. Vzhledem k tomu, že agilní metriky nejsou standardizovány, nemá smysl porovnávat úspěchy různých týmů. Spíše se ujistěte, že přijmete zpětnou vazbu svého týmu, zahájíte pravidelné diskuse a vyživujete atmosféru společných cílů a podpory.