Šablona dat pro životní cyklus vývoje softwaru

Azure DevOps
Šablona dat pro životní cyklus vývoje softwaru

Šablona dat pro životní cyklus vývoje softwaru

Tato šablona vám ukáže, jak připravit data o životním cyklu vývoje softwaru pro process mining. Obsahuje přehled potřebných datových atributů, aktivit, které je vhodné sledovat, a praktický návod, jak data získat z Azure DevOps. Pomůže vám připravit data ve vhodné struktuře pro analýzu a zlepšování procesů.
  • Doporučené atributy ke sběru
  • Aktivity SDLC, které je vhodné sledovat
  • Podrobný návod na získání dat z Azure DevOps
Pracujete se záznamy událostí poprvé? Přečtěte si, jak vytvořit záznam událostí pro process mining.

Atributy životního cyklu vývoje softwaru

Jde o doporučená datová pole pro záznam událostí, která využijete při analýze a zlepšování životního cyklu vývoje softwaru.
5 Povinné 7 Doporučené 6 Volitelné
Název Popis
Čas události
EventTime
Přesné časové razítko, které udává, kdy u položky vývoje nastala konkrétní činnost nebo událost.
Popis

Čas události zaznamenává datum a čas každé činnosti v životním cyklu vývoje. Toto časové razítko slouží k seřazení událostí podle času a výpočtu doby mezi nimi.

Při analýze je tento atribut nezbytný pro výpočet všech časových ukazatelů, včetně doby cyklu, doby zpracování a čekání. Umožňuje vytvořit časově seřazený záznam událostí, který je nutným vstupem pro každou analýzu process mining. Pomáhá odhalovat prodlevy, měřit výkon vůči SLA a sledovat vývoj v čase.

Proč je to důležité

Časové razítko určuje pořadí událostí. To je nezbytné pro výpočet všech KPI založených na délce trvání i pro pochopení průběhu procesu a jeho úzkých míst.

Kde data získat

Jde o hodnotu „Changed Date“ zaznamenanou u každé aktualizace v historii pracovní položky. U externích událostí, například sestavení nebo nasazení, jde o čas dokončení události.

Příklady
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Název činnosti
ActivityName
Název konkrétní události nebo úkolu, který v určitém okamžiku nastal v životním cyklu vývoje dané pracovní položky.
Popis

Název činnosti označuje konkrétní krok nebo milník procesu, například „Zahájení vývoje“, „Vytvoření pull requestu“ nebo „Nasazení do produkčního prostředí“. Činnosti se odvozují ze změn stavu pracovní položky, propojených událostí, jako jsou sestavení nebo pull requesty, případně z vlastních událostí.

Tento atribut je nezbytný pro vytvoření procesní mapy, která znázorňuje workflow. Analytici díky němu mohou sledovat pořadí událostí, určit obvyklé cesty, najít úzká místa mezi konkrétními činnostmi a analyzovat četnost jednotlivých kroků.

Proč je to důležité

Určuje jednotlivé kroky procesu, tvoří základ procesní mapy a umožňuje analyzovat workflow, úzká místa i odchylky.

Kde data získat

Obvykle se odvozuje ze změn pole „State“ pracovní položky nebo z propojených událostí, jako jsou sestavení, commity a pull requesty. Zdrojová data pro tyto události poskytuje historie pracovní položky.

Příklady
Zahájení vývojeDokončení pull requestuNeúspěšné testování QANasazení do produkčního prostředíUzavření pracovní položky
Položka vývoje
DevelopmentItem
Jedinečný identifikátor konkrétní pracovní položky, například funkce, chyby nebo uživatelského příběhu. V procesu slouží jako identifikátor případu.
Popis

Položka vývoje představuje samostatnou práci sledovanou v Azure DevOps. Každá položka má jedinečné ID a je hlavním objektem, ke kterému se vztahují všechny činnosti procesu, od vytvoření a plánování přes vývoj a testování až po nasazení.

Při analýze process mining je tento atribut základem pro propojení souvisejících událostí do jednoho případu. Umožňuje rekonstruovat celý životní cyklus každé pracovní položky a analyzovat dobu cyklu, odchylky od procesu i opakované průchody u jednotlivých položek.

Proč je to důležité

Jde o hlavní identifikátor, který propojuje všechny kroky do jednoho případu a umožňuje analyzovat celý životní cyklus vývoje softwaru.

Kde data získat

Odpovídá poli „ID“ pracovní položky v Azure DevOps Boards. Je dostupné prostřednictvím Azure DevOps REST API pro Work Item Tracking.

Příklady
10234102351023610237
Poslední aktualizace dat
LastDataUpdate
Časové razítko označující, kdy byla data procesu naposledy obnovena ze zdrojového systému.
Popis

Tento atribut zaznamenává, kdy byla datová sada naposledy získána a aktualizována z Azure DevOps. Ukazuje, jak aktuální data jsou a jaké období analýza pokrývá.

Při analýze procesu je důležité vědět, jak stará data jsou, abyste se mohli správně rozhodovat. Časové razítko uživatelům ukazuje, zda pracují s aktuálními informacemi, nebo s historickým snímkem. To ovlivňuje relevanci zjištění.

Proč je to důležité

Informuje uživatele o aktuálnosti dat, takže vědí, jaké období analýza a rozhodnutí pokrývají.

Kde data získat

Jde o časové razítko metadat vytvořené a uložené během procesu získávání, transformace a načítání dat (ETL).

Příklady
2024-05-20T08:00:00Z
Zdrojový systém
SourceSystem
Systém, ze kterého byla data procesu získána. V tomto případě jde o Azure DevOps.
Popis

Tento atribut označuje zdrojový systém dat. Hodí se zejména v prostředích, kde se pro širší pohled na proces kombinují data z více systémů. V tomto modelu je jeho hodnota vždy Azure DevOps.

Při analýze jediného systému se může zdát neměnný, přesto poskytuje důležitý kontext o původu dat. To je podstatné pro správu dat, řešení problémů i budoucí integrace s dalšími systémy, například ServiceNow nebo SAP.

Proč je to důležité

Poskytuje důležitý kontext o původu dat, který je potřebný pro správu a ověřování dat i analýzu procesů napříč systémy.

Kde data získat

Jde o neměnnou hodnotu, kterou je třeba přidat při získávání a transformaci dat, aby označovala datovou sadu.

Příklady
Azure DevOps
Čas ukončení
EndTime
Časové razítko označující dokončení činnosti. Používá se k výpočtu doby jejího zpracování.
Popis

Čas ukončení označuje konec činnosti. V mnoha záznamech událostí slouží jako čas ukončení předchozí činnosti začátek té následující. Samostatný čas ukončení však umožňuje přesněji vypočítat dobu zpracování činnosti i nečinnou dobu mezi činnostmi.

Tento atribut je nezbytný pro výpočet KPI ProcessingTime a podrobnou analýzu úzkých míst. Pomáhá rozlišit dobu aktivní práce na úkolu od čekání na zahájení dalšího kroku. To je důležité pro dashboard Stage Handoff Analysis.

Proč je to důležité

Umožňuje přesně vypočítat dobu zpracování činností i nečinnou dobu. To je základ pro analýzu úzkých míst a zvyšování efektivity.

Kde data získat

Tato hodnota se často odvozuje. Může jít o čas zahájení následující události ve stejném případu, případně se zaznamenává přímo, pokud zdrojový systém ukládá začátek i konec úkolu.

Příklady
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Název týmu
TeamName
Název vývojového týmu odpovědného za pracovní položku.
Popis

Název týmu označuje konkrétní tým, kterému je pracovní položka přiřazena. V Azure DevOps se práce často organizuje do týmů, které mohou být součástí většího projektu.

Díky tomuto atributu můžete analyzovat procesy po jednotlivých týmech. Snadno tak porovnáte jejich postupy a výsledky, najdete osvědčené postupy u výkonných týmů a zjistíte, kde některé týmy potřebují podporu nebo úpravu procesu.

Proč je to důležité

Umožňuje porovnat týmy, odhalit rozdíly ve výkonnosti a sdílet osvědčené postupy napříč organizací.

Kde data získat

Často se odvozuje z pole „Area Path“ pracovní položky, protože týmy v Azure DevOps obvykle odpovídají konkrétním oblastem.

Příklady
Tým PhoenixTým OmegaJádro platformyTým frontendového vývoje
Opakovaná práce
IsRework
Logická hodnota označující, zda se vývojová položka vrátila do předchozí fáze životního cyklu.
Popis

Hodnota je nastavena na true, pokud se pracovní položka vrátí v procesu zpět, například z „Testování QA dokončeno“ do „Vývoj zahájen“. Vypočítá se analýzou posloupnosti aktivit případu a vyhledáním nelineárního postupu.

Tento atribut je důležitý pro dashboard četnosti opakované práce a opakovaného testování i pro KPI četnosti návratů v procesu. Umožňuje opakovanou práci snadno filtrovat a kvantifikovat. Pomáhá tak odhalit problémy s kvalitou, nedostatky v komunikaci nebo nedostatečné testování, které snižují efektivitu.

Proč je to důležité

Přímo označuje a kvantifikuje opakovanou práci. Pomáhá odhalit problémy s kvalitou a neefektivní postupy, které prodlužují dobu cyklu.

Kde data získat

Jde o vypočítaný atribut, který se odvozuje z posloupnosti aktivit v záznamu událostí každého případu.

Příklady
truefalse
Priorita
Priority
Číselné nebo slovní vyjádření důležitosti vývojové položky ve srovnání s ostatními položkami.
Popis

Priorita určuje, jak rychle je třeba pracovní položku naplánovat a řešit. Položky s vyšší prioritou by měly přijít na řadu dříve než položky s nižší prioritou. Běžně se používá číselná škála, například 1, 2, 3, 4, kde 1 označuje nejvyšší prioritu.

Tento atribut je důležitý pro dashboard Průchodnost a doba cyklu podle priority. Analýza těchto údajů ukáže, zda systém prioritizace funguje, tedy zda položky s vysokou prioritou skutečně procházejí procesem rychleji než položky s nízkou prioritou.

Proč je to důležité

Umožňuje zjistit, zda proces skutečně urychluje vyřizování položek s vysokou prioritou. To je důležité při hodnocení strategie prioritizace.

Kde data získat

Odpovídá poli „Priority“ u pracovní položky v Azure DevOps.

Příklady
1234
Přiřazeno uživateli
AssignedTo
Uživatel nebo člen týmu, kterému je položka vývoje aktuálně přiřazena.
Popis

Tento atribut označuje osobu odpovědnou za pracovní položku v dané fázi procesu. Přiřazení se může během životního cyklu položky několikrát změnit, například z vývojáře na testera a poté na správce vydání.

Analýza podle pole „Assigned To“ je důležitá pro dashboard Developer and Tester Workload Overview. Pomáhá pochopit rozdělení zdrojů, odhalit přetížené členy týmu a porovnat výkon jednotlivců nebo týmů.

Proč je to důležité

Umožňuje analyzovat proces podle zdrojů, pochopit rozložení pracovní zátěže, odhalit úzká místa související s konkrétními zdroji a řídit kapacitu týmu.

Kde data získat

Odpovídá poli „Assigned To“ pracovní položky v Azure DevOps. Hodnota se zaznamenává z historie pracovní položky pro každou událost.

Příklady
jane.doe@example.comjohn.smith@example.comnepřiřazeno
Stav
State
Aktuální stav vývojové položky v rámci workflow, například „Nová“, „Aktivní“, „Vyřešená“ nebo „Uzavřená“.
Popis

Atribut State označuje formální stav pracovní položky v daném okamžiku podle šablony procesu projektu. Přechody mezi stavy jsou hlavním zdrojem aktivit v záznamu událostí.

Atribut 'Activity' často popisuje změnu stavu podrobněji, ale původní atribut 'State' se hodí pro filtrování a analýzu. Pomáhá zjistit, kolik času položky stráví v jednotlivých stavech. Je také základem pro vytvoření dashboardu délky jednotlivých fází a analýzu předávání práce.

Proč je to důležité

Udává stav pracovní položky v průběhu jejího životního cyklu. Díky tomu lze sledovat tok procesu a počítat dobu strávenou v jednotlivých fázích.

Kde data získat

Odpovídá poli „State“ u pracovní položky v Azure DevOps.

Příklady
NováAktivníV testováníVyřešenáUzavřená
Typ pracovní položky
WorkItemType
Klasifikace vývojové položky, například chyba, funkce, uživatelský příběh nebo úkol.
Popis

Typ pracovní položky určuje povahu vykonávané práce. Různé typy položek často procházejí odlišnými procesy a mají jiné požadavky na výkon nebo SLA. Například „Bug“ může mít zrychlený postup oproti položce „Feature“.

Tento atribut je nezbytný pro srovnávací analýzu. Umožňuje filtrovat procesní mapu nebo KPI podle typu práce a zjistit, zda jsou procesy pro chyby efektivnější než pro funkce. Můžete také sledovat historický vývoj doby cyklu u různých kategorií práce.

Proč je to důležité

Umožňuje rozdělit analýzu procesu a porovnávat workflow i výkon u různých kategorií práce, například chyb a funkcí.

Kde data získat

Odpovídá poli „Work Item Type“ pracovní položky v Azure DevOps.

Příklady
ChybaFunkceUživatelský příběhÚkol
Čekání mezi fázemi
StageHandoffTime
Doba nečinnosti mezi dokončením jedné hlavní fáze a zahájením další.
Popis

Čekání mezi fázemi měří dobu mezi navazujícími částmi procesu, například mezi „Vývoj dokončen“ a „Testování QA zahájeno“. Vypočítá se tak, že se určí tyto přechody a změří se čas od konce první aktivity do začátku druhé.

Tato metrika je základem dashboardu délky fází a analýzy předávání práce. Samostatné měření čekání mezi fázemi pomáhá odhalit skrytá úzká místa, kde práce stojí. Příčinou bývá například nedostupnost zdrojů, zpožděná komunikace nebo neefektivní postupy.

Proč je to důležité

Kvantifikuje čekání mezi fázemi procesu a odhaluje skrytá úzká místa i prodlevy mimo aktivní práci.

Kde data získat

Jde o vypočítaný atribut. Nejprve je třeba určit dvojice navazujících aktivit, které představují předání práce, a poté vypočítat časový rozdíl mezi nimi.

Příklady
2 hodiny 15 minut1 den 4 hodiny30 minut
Čekání na schválení
ApprovalWaitingTime
Doba, po kterou vývojová položka čeká na schválení od podání žádosti.
Popis

Tato metrika měří dobu, po kterou pracovní položka čeká na schválení. Příkladem je čas mezi aktivitami „UAT zahájeno“ a „UAT schváleno“. Pro daný případ se vypočítá rozdíl mezi časem těchto dvou aktivit.

Vypočítaný atribut přímo podporuje dashboard analýzy čekání na schválení a související KPI. Když týmy tyto prodlevy oddělí od ostatní práce, mohou se zaměřit na komunikaci a rozhodování, omezit nečinnost a zkrátit celý životní cyklus.

Proč je to důležité

Měří prodlevy způsobené čekáním na rozhodnutí nebo schválení a ukazuje, kde lze zlepšit komunikaci a rozhodování.

Kde data získat

Vypočítá se tak, že se v záznamu událostí najdou konkrétní aktivity zahájení a dokončení schvalování, například „UAT zahájeno“ a „UAT schváleno“, a určí se časový rozdíl mezi nimi.

Příklady
3 dny 2 hodiny1 den 8 hodin 30 minut4 hodiny
Cesta iterace
IterationPath
Vývojový sprint nebo časově ohraničené období, do kterého je pracovní položka zařazena.
Popis

Cesta iterace neboli sprint označuje konkrétní, časově ohraničené období vývoje. Pracovní položky se přiřazují k iteraci, aby byly dokončeny v jejím průběhu.

Analýza podle cesty iterace ukáže, jak se proces vyvíjí sprint po sprintu. Můžete sledovat, zda se doba cyklu v dalších sprintech zkracuje, analyzovat nedokončenou práci přenesenou do dalšího sprintu a vyhodnocovat přesnost plánování.

Proč je to důležité

Analýza po sprintech týmům pomáhá průběžně vyhodnocovat výsledky a zlepšovat agilní postupy.

Kde data získat

Odpovídá poli „Iteration Path“ u pracovní položky v Azure DevOps.

Příklady
Platforma pro elektronický obchod\Sprint 12Platforma pro elektronický obchod\Sprint 13Nové vydání mobilní aplikace\Fáze 2\Sprint 4
ID žádosti o začlenění změn
PullRequestId
Identifikátor žádosti o začlenění změn propojené s vývojovou položkou.
Popis

Tento atribut propojuje pracovní položku s konkrétní žádostí o začlenění změn, která slouží k odeslání a kontrole změn kódu. Jedna pracovní položka může souviset s více žádostmi.

ID žádosti o začlenění změn umožňuje podrobněji analyzovat kontrolu a integraci kódu. Můžete měřit dobu od vytvoření žádosti do jejího dokončení a sledovat, jak často jsou žádosti zamítnuty nebo vyžadují rozsáhlé úpravy. To může upozornit na problémy s kvalitou kódu nebo nejasné požadavky.

Proč je to důležité

Propojuje vývojovou práci s konkrétními kontrolami kódu a umožňuje podrobně analyzovat jeho integraci a zajištění kvality.

Kde data získat

Tyto informace najdete v části „Links“ nebo „Development“ pracovní položky v Azure DevOps.

Příklady
452145334589
Název projektu
ProjectName
Název projektu Azure DevOps, do kterého vývojová položka patří.
Popis

Tento atribut určuje konkrétní projekt v organizaci Azure DevOps, ve kterém se pracovní položka nachází. Poskytuje základní kontext, zejména v organizacích s mnoha projekty.

Název projektu je důležitý pro filtrování a porovnávání. V dashboardu historických trendů doby cyklu umožňuje rozdělit analýzu podle projektů. Zjistíte tak, zda jsou některé projekty efektivnější než jiné a zda změny procesu v jednom projektu přinesly zlepšení.

Proč je to důležité

Umožňuje seskupit data pro analýzu a porovnávat výkonnost i trendy napříč projekty.

Kde data získat

Odpovídá poli „Team Project“ u pracovní položky v Azure DevOps.

Příklady
Platforma pro elektronický obchodNové vydání mobilní aplikaceModernizace datového skladu
Závažnost
Severity
Udává dopad chyby nebo problému na systém či jeho koncové uživatele.
Popis

Závažnost vyjadřuje dopad chyby, od kritického výpadku systému po drobnou kosmetickou vadu. Na rozdíl od priority, která určuje pořadí práce, závažnost popisuje samotný dopad. Kritická chyba může mít nízkou prioritu, pokud je k dispozici snadné náhradní řešení.

Tento atribut přidává další pohled na analýzu, zejména v dashboardu průchodnosti a doby cyklu podle priority. Pomáhá například odpovědět na otázku: „Opravujeme nejdřív nejzávažnější chyby?“ Zároveň ukazuje rizikovost zpracovávané práce.

Proč je to důležité

Umožňuje třídit pracovní položky podle jejich dopadu na podnikání a zjistit, jak dobře tým řeší problémy s největším dopadem.

Kde data získat

U chyb odpovídá poli „Severity“ u pracovní položky v Azure DevOps.

Příklady
1 - Kritická2 - Vysoká3 - Střední4 - Nízká
Povinné Doporučené Volitelné

Aktivity životního cyklu vývoje softwaru

Zachyťte tyto důležité kroky a milníky procesu v záznamu událostí. Pomohou vám přesně zjistit, jak proces probíhá, a odhalit úzká místa.
7 Doporučené 8 Volitelné
Aktivita Popis
Dokončení pull requestu
Označuje úspěšné dokončení kontroly kódu, kdy je pull request schválen a kód sloučen do cílové větve. Tato událost se výslovně zaznamenává v Azure Repos.
Proč je to důležité

Označuje konec kontroly kódu, která často bývá úzkým místem. Analýza doby od vytvoření po dokončení PR ukáže, jak efektivně probíhá kontrola.

Kde data získat

Zaznamenává se událost dokončení nebo sloučení pull requestu v Azure Repos, který je propojený s pracovní položkou.

Zachycení

Zaznamenává se událost sloučení pull requestu propojeného s pracovní položkou.

Typ události explicit
Nasazení do produkčního prostředí
Označuje úspěšné nasazení kódu souvisejícího s pracovní položkou do produkčního prostředí. Jde o výslovně zaznamenanou událost z protokolů vydání Azure Pipelines.
Proč je to důležité

Jde o důležitý milník, který představuje dodání hodnoty. Slouží jako koncový bod pro výpočet doby průchodu a doby cyklu.

Kde data získat

Zaznamenává se z dat release pipeline v Azure Pipelines, konkrétně z události dokončení nasazení do fáze „Production“ propojené s pracovní položkou.

Zachycení

Zaznamenává se událost dokončení nasazení v release pipeline.

Typ události explicit
Schválení UAT
Tato činnost znamená, že zainteresované strany z byznysu schválily změny po uživatelském akceptačním testování. Obvykle se odvozuje ze změny stavu z „In UAT“ na „UAT Approved“ nebo „Ready for Release“.
Proč je to důležité

Jde o důležitý milník schválení, který potvrzuje, že pracovní položka splňuje obchodní požadavky a je připravena k nasazení do produkčního prostředí.

Kde data získat

Odvozuje se z historie pracovní položky zjištěním změny pole System.State ze stavu UAT na schválený stav nebo stav připravený k vydání.

Zachycení

Odvozuje se ze změny pole State z „In UAT“ na „Ready for Release“.

Typ události inferred
Vytvoření pracovní položky
Tato aktivita označuje začátek vývojového cyklu a představuje vytvoření nové pracovní položky, například uživatelského příběhu, chyby nebo úkolu. Zaznamená se při uložení nového záznamu v Azure DevOps Boards.
Proč je to důležité

Jde o hlavní počáteční událost procesu. Je nezbytná pro měření celkové doby vývoje a pochopení toho, odkud práce přichází.

Kde data získat

Událost se zaznamenává z pole „Created Date“ přímo v pracovní položce. Tabulka historie pracovní položky zaznamenává také tento počáteční přechod stavu.

Zachycení

Zaznamenává se z pole „Created Date“ pracovní položky.

Typ události explicit
Vytvoření pull requestu
Označuje, že vývojář dokončil první verzi kódu a odeslal změny ke kontrole prostřednictvím pull requestu. Tato událost propojuje pracovní položku s konkrétní změnou kódu v Azure Repos.
Proč je to důležité

Jde o předání práce z vývoje ke kontrole kódu. Sledování této události pomáhá měřit dobu programování a určit, kdy je kód připraven ke kontrole kolegy.

Kde data získat

Zaznamenává se z dat Azure Repos propojením události vytvoření pull requestu s příslušnou pracovní položkou. Toto propojení obvykle vytvoří vývojář.

Zachycení

Zaznamenává se událost vytvoření pull requestu v Azure Repos propojená s pracovní položkou.

Typ události explicit
Zahájení testování QA
Označuje začátek formální fáze testování kvality. Událost se odvozuje ze změny stavu pracovní položky na „In QA“, „Testing“ nebo podobnou hodnotu.
Proč je to důležité

Označuje začátek cyklu QA. Analýza délky této fáze je důležitá pro pochopení úzkých míst a efektivity testování.

Kde data získat

Odvozuje se z historie pracovní položky sledováním změny pole System.State na „In QA“ nebo jiný určený stav testování.

Zachycení

Odvozuje se ze změny pole State na „In QA“ nebo „Testing“.

Typ události inferred
Zahájení vývoje
Tato činnost znamená, že vývojář začal na položce aktivně pracovat. Odvozuje se ze změny stavu pracovní položky na „Active“, „In Progress“ nebo „Committed“.
Proč je to důležité

Označuje začátek aktivní fáze vývoje. Analýza doby od „Created“ do „Development Started“ odhalí, jak dlouho položky čekají v backlogu.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State změní ze stavu „New“ nebo „Approved“ na „In Progress“.

Zachycení

Odvozuje se ze změny pole State na „Active“ nebo „In Progress“.

Typ události inferred
Dokončení testování QA
Označuje úspěšné dokončení fáze QA. Odvozuje se ze změny stavu pracovní položky z testovacího stavu na hodnotu jako „Ready for UAT“ nebo „QA Approved“.
Proč je to důležité

Jde o důležitou kontrolu kvality, která potvrzuje, že je položka připravena k uživatelskému akceptačnímu testování nebo vydání. Prodlevy po tomto bodě mohou ukazovat na úzká místa při UAT nebo plánování vydání.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State změní z „In QA“ na následující stav, například „Ready for UAT“ nebo „Done“.

Zachycení

Odvozuje se ze změny pole State z „In QA“ na „Ready for UAT“.

Typ události inferred
Dokončení vývoje
Označuje dokončení vývoje a jednotkových testů. Položka je připravena k formálnímu testování. Obvykle se odvozuje ze změny stavu pracovní položky na „Resolved“ nebo „Ready for Test“.
Proč je to důležité

Označuje důležité předání práce od vývojového týmu týmu QA. Měřením doby do zahájení „QA Testing Started“ lze odhalit prodlevy při předávání.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State změní na hodnotu jako „Resolved“ nebo na vlastní stav označující připravenost ke kontrole QA.

Zachycení

Odvozuje se ze změny pole State na „Resolved“.

Typ události inferred
Neúspěšné testování QA
Označuje, že pracovní položka neprošla testováním QA a vrací se do vývoje. Událost se zaznamená při změně stavu z testovacího stavu zpět na „In Progress“ nebo „Active“.
Proč je to důležité

Tato činnost pomáhá odhalit opakované průchody procesem. Častý výskyt události může ukazovat na problémy s kvalitou kódu, požadavky nebo testováním.

Kde data získat

Odvozuje se z historie pracovní položky zjištěním přechodu ze stavu jako „In QA“ zpět do stavu jako „Active“ nebo „In Progress“.

Zachycení

Odvozuje se ze změny pole State z „In QA“ zpět na „Active“.

Typ události inferred
Schválení pracovní položky
Označuje formální schválení pracovní položky a potvrzuje, že je dostatečně popsaná a připravená k vývoji. Obvykle se odvozuje ze změny pole „State“ na hodnotu jako „Approved“ nebo „Ready for Dev“.
Proč je to důležité

Sledování schválení pomáhá analyzovat dobu od zadání nápadu po závazek zahájit vývoj. Odhalí možné prodlevy při plánování a úpravách backlogu.

Kde data získat

Odvozuje se z historie pracovní položky. Zjišťuje se změna pole System.State na „Approved“ nebo na podobný vlastní stav.

Zachycení

Odvozuje se ze změny pole State na „Approved“.

Typ události inferred
Úspěšné sestavení
Tato činnost potvrzuje, že build pipeline úspěšně zkompilovala a zabalila zdrojový kód včetně nových změn. Azure Pipelines tuto událost zaznamenává výslovně.
Proč je to důležité

Jde o důležitou kontrolu kvality, která ověřuje, že se nový kód správně začlenil a sestavení neporušil. Neúspěch v této fázi může ukazovat na problémy s integrací.

Kde data získat

Zaznamenává se z událostí dokončení sestavení v Azure Pipelines. Sestavení musí být propojeno s pracovní položkou, přímo nebo prostřednictvím souvisejícího pull requestu.

Zachycení

Zaznamenává se událost dokončení sestavení v Azure Pipelines.

Typ události explicit
Uzavření pracovní položky
Označuje konečné uzavření pracovní položky po nasazení a případném ověření po nasazení. Zaznamená se při změně stavu na „Closed“ nebo „Done“.
Proč je to důležité

Tato činnost označuje konečné úspěšné dokončení celého procesu pro pracovní položku. Jde o jednoznačný koncový bod jejího životního cyklu.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State změní na „Closed“ nebo podobný koncový stav v kategorii „Completed“.

Zachycení

Odvozuje se ze změny pole State na „Closed“.

Typ události inferred
Zahájení UAT
Označuje začátek uživatelského akceptačního testování, při kterém zainteresované strany z byznysu ověřují funkčnost. Obvykle se odvozuje ze změny stavu na „In UAT“ nebo podobný stav.
Proč je to důležité

Měří začátek závěrečného ověření před vydáním. Při zlepšování procesu je důležité analyzovat délku UAT i čekání na schválení.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State aktualizuje na vlastní stav označující UAT, například „In UAT“.

Zachycení

Odvozuje se ze změny pole State na „In UAT“.

Typ události inferred
Zrušení pracovní položky
Označuje, že pracovní položka byla zrušena a nebude dokončena ani nasazena. Zaznamená se při změně stavu na „Removed“, „Cancelled“ nebo podobný stav.
Proč je to důležité

Jde o alternativní, neúspěšné ukončení procesu. Analýza zrušených položek může odhalit problémy s plánováním, prioritizací nebo definicí požadavků.

Kde data získat

Odvozuje se z historie pracovní položky, když se pole System.State změní na koncový stav v kategorii „Removed“.

Zachycení

Odvozuje se ze změny pole State na „Removed“ nebo „Cancelled“.

Typ události inferred
Doporučené Volitelné

Návody na získání dat

Jak získat data z Azure DevOps

Chcete začít?

Začněte zlepšovat životní cyklus vývoje softwaru ještě dnes. Tato šablona je prvním krokem k užitečným poznatkům o vašem procesu.

Začněte zlepšovat SDLC v Azure DevOps ještě dnes!

Zkraťte dobu cyklu o 30 % a odstraňte úzká místa ve workflow SDLC.

Zahájit zkušební verzi

Bez platební karty. Začít můžete během několika minut.