naše zkušenosti s používáním nejběžnějších agilních metrik

naše zkušenosti s používáním nejběžnějších agilních metrik

používání agilních metrik k měření produktivity týmu je klíčovou součástí filozofie Agile. Manažeři týmů a všichni členové by měli vidět důsledky své práce a používat tato data ke zlepšení pracovního postupu a zvýšení efektivity.

koncoví uživatelé a klienti mohou také těžit z použití agilních metrik projektu, které se zaměřují na vyhodnocení výsledku produktu. Metriky umožňují mistrům scrum, vývojářům, návrhářům a testerům měřit výkon aplikace a sledovat, zda současné a předchozí úkoly zlepšují produkt.

v tomto článku přezkoumáme agilní metriky, na kterých záleží, a podělíme se o naše zkušenosti s aplikací tohoto panelu agilních metrik na projekt v reálném životě. Ukázalo se, že k úspěšnému vedení týmu a dosažení výsledků potřebujete nejen vědět, které metriky použít, ale jak to udělat — podělíme se o to, jak jsme na to přišli.

typy běžných agilních metrik

klasifikace agilních metrik není nastavena do kamene-neustále se mění a restrukturalizuje. Přesto jsme v průběhu let zaznamenali vzestup tří hlavních druhů agilních metrik v různých agilních rámcích.

1. Kanban metrics – tyto metriky jsou založeny na měření investovaného času (doby cyklu) a dodaných výsledků (propustnosti) a jejich poměru.
2. Scrum metrics — metriky, které jsou zaměřeny na plánování a pochopení pracovního postupu a demonstraci toho, kolik práce bylo v daném období provedeno;
3. Lean metrics — průběžné měření efektivity výroby a kvality produktu s technickým hodnocením testováním funkcí, kontrolou možných chyb a předvídáním negativních účinků.

všechny tři typy metrik používáme k posouzení hlavních aspektů procesu vývoje softwaru a výsledků: kvalita produktu, Produktivita týmu a zdraví.

agilní metriky kvality

než začnete měřit rychlost a efektivitu týmu, musíte vědět, zda se obecně pohybujete správným směrem. K čemu je rychlé doručení všech vývojových úkolů, pokud jsou samotné úkoly vytvořeny špatně? Prioritou každého týmu a manažera vývoje softwaru je zajistit, aby všechny činnosti souvisely se zlepšením produktu — to se provádí měřením jeho kvality a detekcí negativních tendencí.

uniklé vady

každý agilní projekt má sprinty nebo pracovní cykly, na jejichž konci je zadán určitý úkol. Po dokončení práce musí manažer týmu posoudit kvalitu výsledků. Všechny změny, úpravy a nefixované chyby jsou uniklé vady-problémy, které vývojáři mohli opravit, ale neudělali to. Zaznamenejte jejich přesný počet a povahu, abyste věděli, jaké chyby obvykle unikají očím vývojářů.

poté, co jste udělali zprávu o uniklých vadách a shromáždili hmatatelné statistiky, musíte o výsledcích diskutovat se svým týmem. Ujistěte se, že každý člen týmu ví, jaké chyby tým obvykle chybí. Pokud máte individuální návrhy, diskutujte o nich se členy týmu jeden na jednoho.

neúspěšné nasazení

pokud byl produkt nasazen, ale nebyl uvolněn nebo nedokázal přilákat uživatele, je to zaznamenáno jako neúspěšné nasazení. Někdy se neúspěšné nasazení stane rozhodnutím jedné ze zúčastněných stran nebo se obchodní model ukáže jako nespolehlivý. Ať už byla příčina problému jakákoli, musíte zaznamenat všechna neúspěšná nasazení spolu s důvody jejich selhání.

před uvolněním nového nasazení se tým může vždy podívat na seznam dříve neúspěšných nasazení a prozkoumat, zda tento nemůže podstoupit stejný proces. Analýza důvodů selhání předchozích verzí umožňuje vyhnout se budoucím problémům.

Release Net Promoter Score (NPS)

Net Promoter Score je metrika, která zahrnuje hodnocení reakcí uživatelů v kvantitativních (čísla ,statistiky, průměrné hodnocení) a kvalitativní zpětné vazby (recenze, přímá zpětná vazba, zprávy, e-maily, hovory). Poté, co tým shromáždil a analyzoval zpětnou vazbu, každý člen týmu navrhne skóre, které vyhodnotí, do jaké míry uživatel pravděpodobně produkt doporučí (obvykle jsou skóre nastavena v mezích od 1 do 10).

agilní metriky řízení projektů

poté, co máte úplnou historii předchozích neúspěchů a úspěchů, můžete analyzovat směr, který se ubírá u všech současných neúplných projektů, a rozdávat příslušné úkoly, spoléhat se na předchozí zkušenosti. Poté, co jste stanovili směr vývoje – „co dělat“ produktu, „musíte posoudit efektivitu týmu-je to faktor“ jak to děláme“. Pomocí metrik agilních projektů můžete zjistit, zda členové týmu splňují vaše očekávání, rozumějí jejich úkolům, řídí termíny a zda jsou všechny procesy koordinovány a synchronizovány.

Dodací lhůta

Dodací lhůta je metrika, která umožňuje týmům zkontrolovat, kolik trvalo, než položka nevyřízených produktů dorazila na konec sprintu. Může být použit ke sledování produktů v jakékoli fázi vývoje, úkol podle úkolu, nebo posoudit celkové časové náklady, od nápadu po vydání. Je to dlouhodobá metrika, kterou mohou vývojáři použít při plánování své budoucí práce a odhadu cen.

nezapomeňte zaznamenat dodací lhůtu pro každý z vašich projektů. Nejlepší je udržovat jak statistiky většího obrazu, které pokrývají celý projekt, tak i organizované metriky sprintu-takže můžete každou fázi prozkoumat zvlášť.

doba cyklu

pokud je dodací lhůta mezi dlouhodobými metrikami výkonu týmu, doba cyklu se zaměřuje na jednotlivé úkoly. Tato metrika vyhodnocuje dobu trvání jednoho cyklu, kde je jeden cyklus proveden jedním úkolem, vypočítává počet cyklů na projekt a měří dosažené výsledky pro koncového uživatele, pokud je produkt již beta-testován nebo uvolněn.

s časem cyklu mohou týmy okamžitě zjistit, zda jeden úkol trvá příliš mnoho času nebo zda někteří členové týmu nesplňují své cíle. Tato krátkodobá metrika usnadňuje řízení projektů a pomáhá rychle určit problémy, které nastanou.

Sprint burndown

tato metrika se používá jak krátkodobě, tak dlouhodobě. Manažeři mohou vytvářet zprávy sprint burndown Scrum v reálném čase, aby sledovali pokrok svého týmu v aktuálním projektu — za tímto účelem musí odhadnout celkový počet sprintů a předpovědět pravděpodobné časové náklady. Může být také použit dlouhodobě-manažeři mohou analyzovat zprávy o předchozích projektech, určit fáze, které selhaly očekávané časové rámce, a analyzovat příčiny zpoždění.

a co je nejdůležitější, sprint burndown umožňuje sledovat dynamiku pracovního postupu týmů. Někteří členové mají tendenci pracovat pomaleji v prvních fázích, zatímco jiní vyhoří ke konci projektu. S vypálením sprintu, vedoucí týmů mohou tyto tendence detekovat, určit jejich příčiny, a pomáhat členům s distribucí práce a řízením času.

Epic & Release burndown

tato metrika je podobná Sprint Burndown – jediný klíčový rozdíl je v tom, že se zaměřuje na produktivitu týmu před a po vydání. Manažeři mohou přidávat nové požadavky a začlenit úkoly, které jsou založeny na zpětné vazbě koncových uživatelů. Je to vylepšená verze sprint burndown, protože také zahrnuje úkoly zadané po vydání projektu.

Velocity

tato metrika vyhodnocuje počet dokončených příběhových bodů za určité období. Na základě vaší historie můžete předvídat časové náklady na budoucí příběhové body. Snížení rychlosti týmu na jednotlivých sprintech může ukazovat na nedorozumění mezi členy týmu nebo na naznačené úkoly, které jsou těžší, než se původně předpokládalo.

další agilní metriky

agilní metriky pomáhají týmu lépe poznat svůj projekt a sledovat mnoho významných aspektů vývoje produktu. Existují také agilní metriky pro vedoucí pracovníky, které umožňují vidět větší obraz vývoje a pohody týmu. Podle našich zkušeností tyto dodatečné metriky pomáhají měřit jakýkoli aspekt vaší práce. Přesto jsme definovali Klíčové vlastnosti, které nejvíce vypovídají o konečném produktu a pomáhají dosáhnout úplného výsledku.

kumulativní tok

název metriky jasně sděluje svůj účel-shromáždit všechny toky projektu a vyhodnotit je v jediném diagramu. Mít takový graf vám poskytne rozsáhlý pohled — může být zaslán zúčastněným stranám projektu, kteří nemají čas analyzovat podrobnější agilní zprávy.

diagram obvykle popisuje následující procesy:

• úkoly v backlogu: kolik úkolů v backlogu mají členové týmu v daném časovém rámci;
• schválená práce: kolik úkolů mezi plánovanými bylo dokončeno — manažer týmu okamžitě vidí rozdíly mezi plánovanými a dokončenými činnostmi;
• vyrovnávací úkoly: veškerá práce, která čeká na schválení, je definována jako nárazníková zóna;
• probíhá: musíte vyhodnotit aktuální pracovní zátěž.

kód churn

tato metrika ukazuje trendy změn základu kódu před vydáním. Churn diagramy ukazují, kolik kódu bylo přidáno, odstraněno nebo změněno najednou. Na začátku sprintu bude na grafu mnoho hrotů a pádů, protože kód je stále nestabilní, ale jak projekt postupuje, graf churn kódu by se měl stát stabilním, bez drastických vzestupů a pádů.

před vydáním by měl churn dostat pokles-přidání nebo úprava kódu před samotným vydáním znamená, že nebude podroben dostatečnému testování. Celkově, kdykoli dojde k nesrovnalosti v agilních grafech, prozkoumejte důvody.

kontrolní graf

kontrolní graf je graf, kde tým může vidět informace o době trvání svého cyklu. Ideální výsledek by měl čáru na grafu neustále klesá s časem-to by znamenalo zvýšení rychlosti týmu-méně času je zapotřebí na jeden cyklus. Dalším důležitým aspektem je konzistence-časy cyklu musí zůstat i bez ohledu na typ úkolu-to znamená, že máte správné rozdělení práce.

metriky zdraví

týmy pro vývoj softwaru se musí zaměřit na dlouhodobé priority, jako je udržování plynulé komunikace mezi členy a kontrola, zda jsou všichni spokojeni. Agile je flexibilní metodika, což znamená, že se může přizpůsobit zájmům různých členů, jakmile manažeři vědí, na co je třeba věnovat pozornost. Zde je návod, jak zjistit, zda jsou všichni členové našeho týmu spokojeni s pracovním postupem.

štěstí

pokud máte ve svém týmu důvěryhodné neformální vztahy, je snazší začít s otevřeným dialogem s každým členem. Požádejte každého, aby ohodnotil své zkušenosti ve společnosti od 1 do 5. Můžete klást pomocné otázky-Jaké jsou nejlepší a nejhorší aspekty jejich práce — co by se dalo zlepšit, a co by mohlo zvýšit štěstí? Pokud tým nemá přátelské komunikační návyky, použití anonymních průzkumů může vést k objektivnějším výsledkům.

týmová morálka

týmová morálka a štěstí nejsou stejné věci. Štěstí má více co do činění s komfortem, zatímco morálka týmu je spojena s produktivitou, sebeúctou, hodnocením vlastních profesionálních kvalit. Opět můžete požádat zaměstnance, aby hodnotili svou morálku od 1 do 5 a položili následující otázky;

• pomohla vám práce ve společnosti zlepšit vaše dovednosti?
• kolik je váš plný potenciál prozkoumán se současnou pracovní zátěží?
• Baví vás vaše práce?
• vidíte jasné výsledky své práce?
• jste nadšeni novými projekty?

cílem je pochopit, že vývojový proud týmu jde správným směrem. Někdy manažer týmu pro vývoj softwaru přijímá ziskové, ale nudné úkoly a ignoruje zájmy členů. Tento průzkum vám pomůže zjistit, zda jsou zaměstnanci nadšeni a zpochybňováni svou prací.

obrat členů týmu

pokud vedoucí týmu často nahrazují členy týmu, znamená to, že pracovní prostředí je pravděpodobně nezdravé. Určitá míra obratu v průběhu času je zdravá — ve skutečnosti nechcete mít žádné další lidi po celá léta, protože by to znamenalo stagnaci. Měli byste však dávat pozor na náhlé výkyvy v aktivitě-měsíce, kdy několik lidí opustilo tým nebo se připojilo mnoho lidí. Pokud máte náhlý přírůstek mnoha nových účastníků, musíte věnovat pozornost procesu nástupu, než půjdete přímo do práce související s projektem.

měření výhod pro koncové uživatele

agilní týmy by měly vědět, jak dobře produkt vyhovuje potřebám konečného uživatele a vlastníka firmy. To se provádí komplexní analýzou kódu, která určuje kvalitu kódu a jeho použitelnost pro konečného uživatele, jakož i možné komplikace údržby.

statická analýza kódu

je to jednoduchý typ analýzy kódu, když je software neaktivní. Pouhým automatickým sledováním kódu pomocí nástrojů s otevřeným zdrojovým kódem můžete identifikovat bezpečnostní problémy, detekovat technické dluhy a chyby a odesílat problematické fragmenty kódu do sběrače odpadků.

dynamická analýza kódu

dynamická analýza kódu vyžaduje, aby váš tým spustil software pro vyhodnocení zkušeností získaných koncovými uživateli. Doporučujeme našim vývojářům a testerům, aby se vždy vžili do obuvi uživatelů a prozkoumali nejběžnější scénáře. Například, mohou seznámit své kolegy a členy rodiny s řešením, požadovat zpětnou vazbu-pokud to není zakázáno dohodou. A co je nejdůležitější, máme tým profesionálů QA, kteří jsou plně zodpovědní za dynamickou analýzu kódu – i když věříme, že čím více lidí přispívá k testování metrik v Agile, tím lepší je konečná kvalita produktu.

jak aplikovat nejlepší agilní metriky

ze všech dostupných agilních metrik musíte vybrat ty, které budou relevantní pro váš tým a projekty dlouhodobě. Sledování těchto klíčových charakteristik by mělo být zvykem, zatímco by vás nemělo odvádět od naléhavější práce. Zde je návod, jak jsme bezproblémově začlenili agilní metriky do našeho pracovního postupu.

zaměřte se na výkon, rozpočet a kvalitu

musíte se ujistit, že po výběru všech metrik budete mít jasnou představu o kvalitě, zatížení, časových výdajích a rozpočtu vaší práce. Za prvé, nastavili jsme krátkodobé metriky, které se vztahují k našim aktivním projektům: doba cyklu a rychlost pro agilní hodnocení výkonu, analýza kódu pro hodnocení kvality kódu a kumulativní tok pro sledování všech vývojových procesů a jejich nákladů.

během prvního sprintu se ujistíme, že uděláme následující:

• Definujte, kolik sprintů a cyklů bude mít Projekt;
• odhadněte časové náklady na celý projekt s přihlédnutím k potřebám klienta;
• posouzení konkurenčních řešení pro pochopení úrovně složitosti konečného produktu;
• shromažďujte zpětnou vazbu od členů našeho týmu o jejich očekáváních ohledně nejzajímavějších, nejnáročnějších a nejobtížnějších aspektů projektu.

tímto způsobem můžeme vědět, kolik času strávíme dokončením projektu, stanovením standardů kvality založených na podobných řešeních a zda je náš tým motivován pracovat na úkolech nebo ne (má obrovský dopad na produktivitu).

metriky po prvním sprintu

zde se zaměřujeme na získání zpětné vazby od klienta a všech členů týmu. Po prvním sprintu chceme vědět, že všechny strany zapojené do pracovního postupu chápou proces a cítí se pohodlně. Také klademe důraz na hodnocení kvality kódu-dokonce plánujeme analýzu kódu a hodnocení technického dluhu jako součást každého z našich dalších sprintů. Jakmile byly napsány první řádky kódu, zachování jeho kvality je naší prioritou.

rychlost přichází po

rychlost je jednou z nejdůležitějších metrik v našich projektech, ale ne klíčovou. Zdržujeme se zakládání našeho úsudku na rychlostních číslech v počátečních fázích. Strategie rychlého překonání prvních kroků je katastrofa, která čeká – tým může přeskočit plánování — nebo zapomenout položit klientovi několik zásadních otázek. První fáze produktu nespěcháme, necháváme klienty a členy týmu najít své tempo.

zvýšení rychlosti našeho týmu se stává jednou z našich priorit, když jsme v bodě provedení. Jakmile jsou všechny funkce a design jsou stanoveny, snažíme se minimalizovat časové náklady a dokončit všechny úkoly tak rychle, jak je to možné.

jednotlivé metriky

každá z použitých metrik by měla být dostupná pro celý tým i jednotlivé členy. Vývojáři, testeři, návrháři by měli být schopni vidět tempo a výsledky své práce, nejen tým jako celek. Aby se to stalo, používáme nástroje produktivity a sledovače času, jako jsou Jira a Hubstaff. Všechny obecné zprávy jsou synchronizovány s jednotlivými-členové mohou vidět, jaké procento celkového produktivního času jejich hodiny dělají.

Často kladené otázky

co je KPI v Agile?

klíčové ukazatele výkonnosti v Agile jsou měřitelné hodnoty, které ukazují efektivitu týmu při dosahování obchodních cílů. KPI na vysoké úrovni se zaměřují na dlouhodobé výsledky, které závisí na mnoha faktorech-kolik uživatelů přilákal konečný produkt — míra konverze, kvalita zpětné vazby. Nízkoúrovňové KPI jsou krátkodobé hodnoty, které nejsou ovlivněny mnoha souvisejícími faktory-čas strávený na projektu (obvykle počítán v hodinách), rozpočet projektu (investice na úkol) atd.

Agile je vývojová metodika založená na neustálém zlepšování-vývoj softwaru analyzuje data a přizpůsobuje se jim. Tým analyzuje agilní KPI na jeho výkon a kvalitu práce, a implementuje změny hned, v příštím sprintu.

co jsou metriky sprintu?

Sprint metrics jsou metriky, které vyhodnocují výstupy týmu pro vývoj softwaru a kontrolují, kolik hodnoty bylo koncovému zákazníkovi doručeno na konci každého sprintu . Tuto hodnotu lze měřit pomocí nové funkce, vylepšení designu nebo odstranění chyb.

dalším cílem metrik sprint je měřit efektivitu týmu z obchodního hlediska — jak rychle bylo řešení dodáno na trh, jaká je zpětná vazba klienta a úrovně konverze. A konečně, metriky musí ukázat spokojenost vývojářů s jejich projektem a směrem, kterým se tým obecně ubírá.

proč jsou metriky důležité pro agilní projekty?

celý bod agilní metodiky spočívá v tom, že vývojáři mohou vždy provádět opravy v procesu po každém sprintu. Mít hmatatelná data, statistiky a grafy umožňuje vývojářům pochopit, jaké změny je třeba provést pro příští sprint — a umožňuje vyhodnotit kvalitu konečného produktu-jinak by bylo snadné se zachytit v technických a organizačních detailech.

co je sprint v Agile?

sprint je jasně definované období s datem startu a cíle, kdy je tým nastaven na splnění určitého počtu úkolů. Sprinty jsou základem Scrum, Agile a DevOps-týmy rozdělují své pracovní vytížení na menší zvládnutelné kousky a sledují výsledky každého sprintu. Každé z těchto období je považováno za mini-projekt s předběžným plánováním, posouzení rizik, přiřazení odpovědnosti, a post-sprintová analýza.

každý projekt se skládá ze série sprintů. Protože je každý sprint vyhodnocen, je snadné včas odhalit problémy a odstranit je při příštím sprintu-takže pracovní postup je neustále optimalizován.

jaké jsou metriky pro vývoj softwaru?

metriky vývoje softwaru jsou kvantitativní hodnoty, které umožňují měřit kvalitu, výkon a zdraví týmu projektu vývoje softwaru. Pomáhají zlepšovat proces vývoje v průběhu projektu a mohou být použity pro budoucí práci týmu na zlepšení organizace a plánování.

existuje šest hlavních typů metrik vývoje softwaru:

• formální metriky kódu-jedná se o objektivní kvalitativní hodnoty, které vypočítávají, kolik práce bylo provedeno stanovením počtu řádků kódu (LOC), délky instrukční cesty a dalších.
• metriky účinnosti vývojářů-tým může vypočítat kód přiřazení, aktivní dny a čas strávený na úkolu.
• metriky agilních procesů – když je projekt rozdělen na sprinty, tým může měřit efektivitu menších částí projektu-dodací lhůta (kolik času bylo vynaloženo na určitou vývojovou fázi, která může obsahovat několik sprintů), doba cyklu (jeden sprint obvykle spadá pod jeden cyklus) a rychlost (kolik úkolů bylo provedeno v určitém časovém rámci).
• provozní metriky – tyto metriky kontrolují charakteristiky běhu softwaru a určují, jak efektivní jsou zaměstnanci společnosti při údržbě nástroje bez pomoci třetích stran. Průměrná doba mezi poruchami a střední doba zotavení (MTTR) zkontrolujte, jak bude software běžet za přirozených okolností a jak je vybaven interní tým při manipulaci s nákladem.
• testovací metriky-tyto metriky vyhodnocují pokrytí kódu – kolik kódu bylo testováno — počet chyb a procento technického dluhu.
• spokojenost zákazníků-tým získá přehled o reakcích koncových uživatelů na produkt měřením čistého skóre promotoru, skóre spokojenosti zákazníků a skóre úsilí zákazníků. Tyto metriky vyhodnocují, zda by uživatelé produkt doporučili a zda jsou s výsledkem spokojeni.

agilní metriky jsou součástí softwarových sítí a mohou se skládat z dalších kategorií, jak si můžete všimnout v našem průvodci.

co jsou metriky SDLC?

SDLC je životní cyklus vývoje softwaru-soubor fází, které typická technologie prochází během svého pojetí, provádění a finalizace. Průměrná SDLC se skládá z následujících fází:

• hodnocení stávajících systémů a definování jejich vlastností, výhod, problémů;
• definování požadavků na funkčnost nového projektu, design, cílové publikum atd.;
• navrhování systému a nastínění typické uživatelské cesty;
• vývoj softwaru, což znamená psaní kódu, přípravu hardwaru a vytváření funkcí;
• testování výkonu softwaru, funkčnosti, zabezpečení, rozhraní atd.;
• nasazení softwaru v jeho přirozeném prostředí, kde technologie poběží dlouhodobě;
• udržování systému aktualizací kódu, nahrazením nebo úpravou určitých fragmentů a odstraněním chyb.

každý stupeň SLDC lze měřit podle následujících charakteristik.

• požadavky: tým musí shromáždit všechny požadavky na projekt a vyhodnotit realizaci každého z nich z hlediska času a peněz;
• kvalita softwaru: všechny agilní metriky kvality lze použít ve fázi vývoje SDLC;
• testovací případy: tým musí vypočítat počet provedených testovacích činností, jejich rychlost a konečné pokrytí kódem;
• vady: pro měření efektivity své práce si vývojáři a testeři musí být vědomi přesného počtu problémů, které vznikají během vývoje;
• úkoly: měření času stráveného a peněz získaných za úkol umožňuje vyhodnotit, zda jsou všichni členové týmu produktivní nebo ne.

všechny metriky popsané v našem průvodci mohou být použity v různých fázích životního cyklu vývoje softwaru. Projekt je v nejvyšší potřebě monitorování blíže k vydání, protože problémy se mohou hromadit a je snadné vynechat kritickou vadu produktu.

co je propustnost v agilních metrikách?

je to metrika, která vypočítává počet příběhů dokončených na sprint. Ve Scrumu se podobná metrika označuje jako Rychlost sprintu.

závěr

agilní metriky vytvářejí pevný základ pro informovaná rozhodnutí v celém projektu vývoje softwaru. Vývojáři mohou pomocí těchto poznatků zvýšit svou efektivitu v příštích sprintech a neustále zlepšovat kvalitu svého produktu. Je však třeba poznamenat, že metriky vývoje by se neměly stát absolutní prioritou v projektu vývoje softwaru. Vývojáři by se měli spoléhat především na potřeby projektu a preference publika.

v Jelvixu používáme osobní přístup k aplikaci metrik na projekt. Nejprve diskutujeme o MVP projektu s klientem, zkoumáme cílové publikum, analyzujeme konkurenční řešení a teprve poté vybereme metriky, které nejlépe vyhovují projektu. Nesnažíme se aplikovat každý jednotlivý KPI-místo toho vybíráme ty, které nejvíce odrážejí potřeby projektu.