Šablona dat pro životní cyklus vývoje softwaru
Šablona dat pro životní cyklus vývoje softwaru
- Doporučené atributy ke sběru
- Aktivity SDLC, které je vhodné sledovat
- Podrobný návod na získání dat z Azure DevOps
Atributy životního cyklu vývoje softwaru
| 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á
|
|||
Aktivity životního cyklu vývoje softwaru
| 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
|
|||
Návody na získání dat
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.
Bez platební karty. Začít můžete během několika minut.