Szoftverfejlesztési életciklus: adatsablon

Azure DevOps
Szoftverfejlesztési életciklus: adatsablon

Szoftverfejlesztési életciklus: adatsablon

Ez a sablon útmutatást ad ahhoz, hogyan készítse elő a szoftverfejlesztési életciklus adatait process mining elemzéshez. Bemutatja a gyűjtendő alapvető adatattribútumokat és a követendő fő tevékenységeket, valamint gyakorlati tanácsokat ad az adatok Azure DevOpsból történő kinyeréséhez. Használja a sablont, hogy adatai megfelelő szerkezetben álljanak rendelkezésre az elemzéshez és a folyamatfejlesztéshez.
  • Javasolt attribútumok
  • Az SDLC-ben követendő fő tevékenységek
  • Részletes útmutató az adatok kinyeréséhez Azure DevOpsból
Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

A szoftverfejlesztési életciklus attribútumai

Ezeket az adatmezőket érdemes felvenni az eseménynaplóba a szoftverfejlesztési életciklus részletes elemzéséhez és fejlesztéséhez.
5 Kötelező 7 Javasolt 6 Nem kötelező
Név Leírás
Esemény időpontja
EventTime
Az a pontos időbélyeg, amely megmutatja, mikor történt egy adott tevékenység vagy esemény a fejlesztési elemmel kapcsolatban.
Leírás

Az esemény időpontja rögzíti a fejlesztési életciklus egyes tevékenységeinek dátumát és időpontját. Ez az alapvető időadat rendezi időrendbe az eseményeket, és lehetővé teszi a köztük eltelt idő kiszámítását.

Az elemzésben ez az attribútum szükséges minden időalapú mutató, köztük a ciklusidő, a feldolgozási idő és a várakozási idő kiszámításához. Segítségével időrendbe rendezett eseménynapló készíthető, amely minden process mining elemzés alapja. A késések feltárására, az SLA-k teljesülésének mérésére és az időbeli trendek követésére is használható.

Miért fontos?

Ez az időbélyeg adja meg az események időrendi sorrendjét. Ez szükséges az időtartam-alapú KPI-k kiszámításához, valamint a folyamat menetének és szűk keresztmetszeteinek megértéséhez.

Hol szerezhető be?

Ez a munkaelem előzményeiben szereplő „Changed Date” mező. Külső események, például buildek vagy bevezetések esetén az esemény befejezésének időbélyege.

Példák
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Fejlesztési elem
DevelopmentItem
Egy munkaegység egyedi azonosítója, például egy funkcióé, hibáé vagy User Storyé. Ez szolgál a folyamat esetazonosítójaként.
Leírás

A Development Item az Azure DevOpsban nyomon követett, önálló munkaegységet jelöli. Minden elemnek egyedi azonosítója van, és ez az elem áll a folyamattevékenységek középpontjában a létrehozástól és tervezéstől a fejlesztésen és tesztelésen át a bevezetésig.

A process mining elemzésben ez az attribútum kapcsolja össze az összes kapcsolódó eseményt egyetlen eset teljes útjává. Így minden munkaelem teljes életciklusa rekonstruálható, és elemezhetők az egyes elemek ciklusidejei, folyamattól való eltérései és az ismételt munkához vezető körei.

Miért fontos?

Ez az alapvető azonosító kapcsolja össze a folyamat összes lépését egyetlen esetté, így lehetővé teszi a szoftverfejlesztési életciklus teljes körű elemzését.

Hol szerezhető be?

Az Azure DevOps Boards munkaelemének „ID” mezőjének felel meg. Az Azure DevOps REST API Work Item Tracking végpontján keresztül érhető el.

Példák
10234102351023610237
Tevékenység neve
ActivityName
A munkaelem fejlesztési életciklusa során egy adott időpontban bekövetkezett esemény vagy elvégzett feladat neve.
Leírás

A tevékenység neve a folyamat egy konkrét lépését vagy mérföldkövét jelöli, például a „Development Started”, a „Pull Request Created” vagy a „Deployed to Production” eseményt. Ezek az események a munkaelem állapotváltozásaiból, a buildhez vagy Pull Requesthez kapcsolódó eseményekből, illetve egyéni eseményekből származnak.

Ez az attribútum szükséges a munkafolyamatot szemléltető folyamattérkép elkészítéséhez. Segítségével az elemzők megérthetik az események sorrendjét, azonosíthatják a gyakori útvonalakat, feltárhatják az egyes tevékenységek közötti szűk keresztmetszeteket, és elemezhetik az egyes lépések gyakoriságát.

Miért fontos?

Meghatározza a folyamat lépéseit, a folyamattérkép alapját adja, és lehetővé teszi a munkafolyamat, a szűk keresztmetszetek és az eltérések elemzését.

Hol szerezhető be?

Ez az adat jellemzően a munkaelem „State” mezőjének változásaiból, illetve a buildhez, commitokhoz és Pull Requestekhez kapcsolódó eseményekből származik. Ezeknek az eseményeknek a nyers adatait a munkaelem előzményei tartalmazzák.

Példák
Fejlesztés megkezdvePull Request lezárvaQA-tesztelés sikertelenÉles környezetbe bevezetveMunkaelem lezárva
Adatok utolsó frissítése
LastDataUpdate
Az időbélyeg azt mutatja, mikor frissítették utoljára a folyamat adatait a forrásrendszerből.
Leírás

Ez az attribútum rögzíti, mikor nyerték ki és frissítették utoljára az adatkészletet az Azure DevOpsból. Megmutatja, mennyire frissek az adatok, és milyen időszakot fed le az elemzés.

A megalapozott döntésekhez minden folyamatelemzésnél tudni kell, mennyire frissek az adatok. Ez az időbélyeg segít eldönteni, hogy valós idejű információt vagy egy korábbi időszak adatait látja-e, ami befolyásolja a megállapítások aktualitását.

Miért fontos?

Tájékoztatja a felhasználókat az adatok frissességéről, így az elemzések és döntések időbeli kerete egyértelmű.

Hol szerezhető be?

Az ETL-folyamat során létrehozott és tárolt metaadat-időbélyeg.

Példák
2024-05-20T08:00:00Z
Forrásrendszer
SourceSystem
Az a rendszer, amelyből a folyamatadatokat kinyerték, ebben az esetben az Azure DevOps.
Leírás

Ez az attribútum azonosítja, melyik rendszerből származnak az adatok. Különösen hasznos, ha több rendszer adatait egyesítik a folyamat átfogóbb elemzéséhez. Ebben a modellben az értéke mindig Azure DevOps.

Egyetlen rendszer elemzésekor ez az érték állandónak tűnhet, mégis fontos információt ad az adatok eredetéről. Ez nélkülözhetetlen az adatkezeléshez, a hibakereséshez és a későbbi, például ServiceNow- vagy SAP-rendszerekkel való integrációhoz.

Miért fontos?

Fontos információt ad az adatok eredetéről, ami szükséges az adatkezeléshez, az ellenőrzéshez és a több rendszert érintő folyamatelemzéshez.

Hol szerezhető be?

Ez egy állandó érték, amelyet az adatok kinyerése és átalakítása során kell hozzáadni az adatkészlet megjelöléséhez.

Példák
Azure DevOps
Állapot
State
A fejlesztési elem aktuális állapota a munkafolyamatban, például „Új”, „Aktív”, „Megoldva” vagy „Lezárva”.
Leírás

Az Állapot attribútum a munkaelem hivatalos státuszát mutatja az adott időpontban, a projekt folyamatsablonja szerint. Az állapotok közötti váltásokból állíthatók elő az eseménynapló tevékenységei.

A „Tevékenység” attribútum gyakran részletesebben írja le az állapotváltozást, de a nyers „Állapot” attribútum is hasznos szűréshez és elemzéshez. Segítségével megállapítható, mennyi időt töltenek az elemek az egyes állapotokban. A szakasz időtartamát bemutató dashboard elkészítéséhez és az átadások elemzéséhez is alapvető.

Miért fontos?

Megmutatja a munkaelem életcikluson belüli állapotát. Ez alapvető a folyamat menetének megértéséhez és az egyes szakaszokban eltöltött idő kiszámításához.

Hol szerezhető be?

Az Azure DevOps munkaelemének „State” mezőjének felel meg.

Példák
ÚjAktívTesztelés alattMegoldvaLezárva
Átdolgozás történt
IsRework
Logikai jelző, amely megmutatja, hogy a fejlesztési elem visszakerült-e az életciklus egy korábbi szakaszába.
Leírás

A jelző értéke igaz, ha a munkaelem átdolgozási ciklusba kerül, például a „QA Testing Completed” állapotból visszalép a „Development Started” állapotba. Az érték kiszámítása az eset tevékenységeinek sorrendjéből történik, a nem lineáris előrehaladás felismerésével.

Ez az attribútum alapja az átdolgozás és az ismételt tesztelés gyakoriságát bemutató dashboardnak, valamint az átdolgozási ciklusok gyakoriságát mérő KPI-nak. Segítségével egyszerűen szűrhető és számszerűsíthető az átdolgozás, így feltárhatók a hatékonyságot rontó minőségi problémák, kommunikációs hiányosságok és elégtelen tesztelés.

Miért fontos?

Közvetlenül azonosítja és számszerűsíti az átdolgozást, így feltárhatók a minőségi problémák és a ciklusidőt növelő folyamathatékonysági hiányosságok.

Hol szerezhető be?

Számított attribútum, amely az egyes esetek eseménynaplójában szereplő tevékenységek sorrendjének elemzéséből származik.

Példák
truefalse
Befejezés időpontja
EndTime
Az időbélyeg azt mutatja, mikor fejeződött be egy tevékenység. A tevékenység feldolgozási idejének kiszámítására használható.
Leírás

A befejezés időpontja jelöli egy tevékenység végét. Sok eseménynaplóban a következő tevékenység kezdési időpontja szolgál az előző tevékenység befejezési időpontjaként. Ha külön befejezési időpont is rendelkezésre áll, pontosabban számítható ki a tevékenység feldolgozási ideje és a tevékenységek közötti holtidő.

Ez az attribútum szükséges a ProcessingTime KPI kiszámításához és a szűk keresztmetszetek részletes elemzéséhez. Segít elkülöníteni a feladaton végzett tényleges munkát attól az időtől, amíg a következő lépésre várnak. Ez fontos a Stage Handoff Analysis dashboard használatakor.

Miért fontos?

Lehetővé teszi a tevékenységek feldolgozási idejének és a holtidőknek a pontos kiszámítását, ami alapvető a szűk keresztmetszetek elemzéséhez és a hatékonyság javításához.

Hol szerezhető be?

Ezt az értéket gyakran számítással határozzák meg. Lehet ugyanazon eset következő eseményének kezdési időpontja, vagy kifejezetten rögzített adat, ha a forrásrendszer a feladatok kezdési és befejezési időpontját is tárolja.

Példák
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Csapat neve
TeamName
A munkaelemért felelős fejlesztőcsapat neve.
Leírás

A csapat neve megmutatja, melyik csapathoz rendelték a munkaelemet. Az Azure DevOpsban a munkát gyakran csapatok szerint szervezik, amelyek egy nagyobb projekt részei lehetnek.

Ez az attribútum lehetővé teszi a folyamat csapatonkénti elemzését. Segítségével összehasonlítható a különböző csapatok működése és teljesítménye, azonosíthatók a jól teljesítő csapatok bevált gyakorlatai, valamint azok a területek, ahol egyes csapatoknak támogatásra vagy folyamatfejlesztésre lehet szükségük.

Miért fontos?

Lehetővé teszi a csapatok teljesítményének összehasonlítását, segít feltárni az eltéréseket és megosztani a bevált gyakorlatokat a szervezeten belül.

Hol szerezhető be?

Az érték gyakran a munkaelem „Area Path” mezőjéből származik, mivel az Azure DevOpsban a csapatokat jellemzően meghatározott területi útvonalakhoz rendelik.

Példák
Phoenix csapatOmega osztagPlatformmagFrontend csapat
Hozzárendelve
AssignedTo
Az a felhasználó vagy csapattag, akihez jelenleg a fejlesztési elem tartozik.
Leírás

Ez az attribútum azonosítja, hogy a folyamat egy adott szakaszában ki felel a munkaelemért. A hozzárendelés az elem életciklusa során többször is változhat, például a fejlesztőtől a tesztelőhöz, majd a kiadásért felelős munkatárshoz kerülhet.

A „Hozzárendelve” szerinti elemzés szükséges a Developer and Tester Workload Overview dashboard használatához. Segít megérteni az erőforrások elosztását, azonosítani a túlterhelt csapattagokat, és összehasonlítani az egyes munkatársak vagy csapatok teljesítményét.

Miért fontos?

Lehetővé teszi az erőforrások szerinti elemzést: megmutatja a munkaterhelés eloszlását, segít feltárni az erőforrásokhoz kapcsolódó szűk keresztmetszeteket, és támogatja a csapat kapacitásának tervezését.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Assigned To” mezőjének felel meg. Az érték minden eseménynél a munkaelem előzményeiből származik.

Példák
jane.doe@example.comjohn.smith@example.comnincs hozzárendelve
Munkaelem típusa
WorkItemType
A fejlesztési elem besorolása, például hiba, funkció, felhasználói történet vagy feladat.
Leírás

A munkaelem típusa a végzett munka jellegét határozza meg. A különböző típusú munkaelemek gyakran eltérő folyamatokon haladnak végig, és más teljesítményelvárások vagy SLA-k vonatkoznak rájuk. Például egy „Bug” javítása gyorsított folyamatot követhet egy „Feature” fejlesztéséhez képest.

Ez az attribútum szükséges az összehasonlító elemzéshez. A folyamattérkép és a KPI-k munkaelem-típus szerint szűrhetők, így összehasonlítható, hogy a hibajavítás vagy a funkciófejlesztés folyamata hatékonyabb-e, illetve nyomon követhetők az egyes munkakategóriák korábbi ciklusidői.

Miért fontos?

Lehetővé teszi a folyamatelemzés kategóriák szerinti bontását, így összehasonlíthatók a különböző munkatípusok, például a hibajavítások és a funkciófejlesztések munkafolyamatai és teljesítménye.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Work Item Type” mezőjének felel meg.

Példák
HibaFunkcióFelhasználói történetFeladat
Prioritás
Priority
A fejlesztési elem fontosságát jelző számszerű vagy szöveges besorolás a többi elemhez képest.
Leírás

A prioritás mutatja, mennyire sürgős egy munkaelem ütemezése. A magasabb prioritású elemeket általában hamarabb kell kezelni, mint az alacsonyabb prioritásúakat. Gyakoriak a számmal jelölt értékek, például 1, 2, 3 és 4, ahol az 1 a legmagasabb prioritás.

Ez az attribútum alapja a prioritás szerinti átbocsátást és ciklusidőt bemutató dashboardnak. Segítségével ellenőrizhető, hogy hatékony-e a prioritási rendszer, vagyis a magas prioritású elemek valóban gyorsabban haladnak-e végig a folyamaton, mint az alacsonyabb prioritásúak.

Miért fontos?

Segítségével ellenőrizhető, hogy a folyamat valóban gyorsabban kezeli-e a magas prioritású elemeket. Ez fontos szempont a prioritási stratégia eredményességének értékelésekor.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Priority” mezőjének felel meg.

Példák
1234
Iterációs útvonal
IterationPath
Az a fejlesztési sprint vagy időszak, amelyhez a munkaelemet rendelték.
Leírás

Az iterációs útvonal, vagyis a sprint, egy meghatározott időtartamú fejlesztési időszakot jelöl. A munkaelemeket az adott időszakban történő elvégzésre rendelik egy iterációhoz.

Az iterációs útvonal szerinti elemzés megmutatja a folyamat teljesítményét sprintenként. Nyomon követhető, hogy javul-e a ciklusidő az egymást követő sprintekben, elemezhető a következő sprintre átvitt munka, és értékelhető a sprinttervezés kiszámíthatósága.

Miért fontos?

Sprintenkénti elemzést tesz lehetővé, így a csapatok idővel értékelhetik teljesítményüket és fejleszthetik agilis munkamódszereiket.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Iteration Path” mezőjének felel meg.

Példák
E-kereskedelmi platform\12. sprintE-kereskedelmi platform\13. sprintMobilalkalmazás újraindítása\2. fázis\4. sprint
Jóváhagyásra várakozás ideje
ApprovalWaitingTime
Az az idő, amelyet a fejlesztési elem a jóváhagyási kérelem benyújtása után jóváhagyásra várva tölt.
Leírás

Ez a mutató azt méri, mennyi ideig vár jóváhagyásra egy munkaelem. Jó példa erre az „UAT Started” és az „UAT Approved” közötti idő. Kiszámításához az adott esetben meg kell mérni a két tevékenység közötti időt.

Ez a számított attribútum közvetlenül támogatja a jóváhagyásra várakozási időt elemző dashboardot és a hozzá tartozó KPI-t. A késedelmek elkülönítésével a csapatok javíthatják a kommunikációt és a döntéshozatalt, csökkenthetik a tétlen várakozást, és felgyorsíthatják a teljes életciklust.

Miért fontos?

Kifejezetten a döntésekre vagy jóváhagyásokra várakozásból eredő késedelmeket méri, így megmutatja, hol javítható a kommunikáció és a döntéshozatal.

Hol szerezhető be?

Az eseménynaplóban meg kell keresni a jóváhagyási folyamat kezdetét és végét jelző tevékenységeket, például az „UAT Started” és az „UAT Approved” eseményt, majd ki kell számítani a köztük eltelt időt.

Példák
3 nap 2 óra1 nap 8 óra 30 perc4 óra
Projekt neve
ProjectName
Annak az Azure DevOps-projektnek a neve, amelyhez a fejlesztési elem tartozik.
Leírás

Ez az attribútum azonosítja, hogy az Azure DevOps-szervezeten belül melyik projekthez tartozik a munkaelem. Magas szintű kontextust ad, különösen akkor, ha a szervezetben sok projekt fut.

A projekt neve fontos szűrési és összehasonlítási szempont. A korábbi ciklusidő-trendeket bemutató dashboardon projektenkénti elemzést tesz lehetővé. Így kiderülhet, hogy egyes projektek hatékonyabban működnek-e másoknál, illetve hogy javított-e a teljesítményen egy adott projekt folyamatfejlesztése.

Miért fontos?

Magas szintű csoportosítást tesz lehetővé, így összehasonlítható a projektek teljesítménye és az időbeli trendek.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Team Project” mezőjének felel meg.

Példák
E-kereskedelmi platformMobilalkalmazás újraindításaAdattárház korszerűsítése
Pull request azonosítója
PullRequestId
A fejlesztési elemhez kapcsolódó pull request azonosítója.
Leírás

Ez az attribútum egy munkaelemet egy adott pull requesthez kapcsol, amelyen keresztül a kódmódosításokat benyújtják és felülvizsgálják. Egy munkaelemhez több pull request is tartozhat.

A pull request azonosítójával részletesebben elemezhető a kódellenőrzés és az integráció folyamata. Mérhető például a pull request létrehozásától a lezárásáig eltelt idő, valamint az, hogy milyen gyakran utasítják el, vagy kérnek rajta jelentős módosításokat. Ez a kódminőségre vagy a követelmények egyértelműségére is utalhat.

Miért fontos?

Összekapcsolja a fejlesztési munkát a konkrét kódellenőrzési tevékenységekkel, így részletesen elemezhető a kódintegráció és a minőségbiztosítás folyamata.

Hol szerezhető be?

Ez az információ az Azure DevOps munkaelemének „Links” vagy „Development” szakaszában található.

Példák
452145334589
Súlyosság
Severity
A hiba vagy probléma rendszerre, illetve végfelhasználókra gyakorolt hatását jelzi.
Leírás

A súlyosság a hibák hatását osztályozza a kritikus rendszerhibáktól az apró, megjelenést érintő problémákig. Nem azonos a prioritással, amely a munka sorrendjét határozza meg. Egy súlyos hiba prioritása is lehet alacsony, ha könnyen alkalmazható kerülőmegoldás áll rendelkezésre.

Ez az attribútum újabb elemzési szempontot ad, különösen a prioritás szerinti átbocsátást és ciklusidőt bemutató dashboardhoz. Segítségével olyan kérdések vizsgálhatók, mint például: „Először a legsúlyosabb hibákat javítjuk ki?” Emellett a feldolgozott munkák kockázati profiljának megértését is segíti.

Miért fontos?

Az üzleti hatásuk szerint csoportosítja a munkaelemeket, így elemezhető, mennyire hatékonyan kezeli a csapat a nagy hatású problémákat.

Hol szerezhető be?

Az Azure DevOps munkaelemének „Severity” mezőjének felel meg, jellemzően hibák esetén.

Példák
1 - Kritikus2 - Magas3 - Közepes4 - Alacsony
Szakaszok közötti átadási idő
StageHandoffTime
Az egyik fő szakasz befejezése és a következő kezdete között tétlenül eltelt idő.
Leírás

A szakaszok közötti átadási idő az egymást követő folyamatlépések közötti várakozást méri. Ilyen például a „Development Completed” és a „QA Testing Started” közötti idő. Kiszámításához azonosítani kell ezeket az átmeneteket, majd meg kell mérni az első tevékenység vége és a második kezdete közötti időt.

Ez a mutató áll a szakaszok időtartamát és az átadásokat elemző dashboard középpontjában. Az átadási idő elkülönítése és mérése segít feltárni a rejtett szűk keresztmetszeteket, amikor a munka tétlenül várakozik, például erőforráshiány, kommunikációs késedelem vagy nem hatékony folyamat miatt.

Miért fontos?

Számszerűsíti a folyamatlépések közötti várakozást, így láthatóvá teszi a rejtett szűk keresztmetszeteket és az aktív munkán kívüli késedelmeket.

Hol szerezhető be?

Számított attribútum. Az átadást jelentő, egymást követő tevékenységpárokat kell azonosítani, majd ki kell számítani a köztük eltelt időt.

Példák
2 óra 15 perc1 nap 4 óra30 perc
Kötelező Javasolt Nem kötelező

A szoftverfejlesztési életciklus tevékenységei

Ezeket a fő folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban a folyamat pontos feltárásához és a szűk keresztmetszetek azonosításához.
7 Javasolt 8 Nem kötelező
Tevékenység Leírás
Éles környezetbe bevezetve
A munkaelemhez tartozó kód sikeres éles környezetbe való bevezetését jelöli. Ezt az eseményt az Azure Pipelines kiadási naplói rögzítik.
Miért fontos?

Ez a fontos mérföldkő jelzi, hogy az eredmény eljutott a felhasználókhoz. A teljes átfutási idő és a ciklusidő számításának végpontja.

Hol szerezhető be?

Az Azure Pipelines kiadási folyamatának adataiból származik. Pontosabban a munkaelemhez kapcsolódó, „Production” szakaszba történő bevezetés befejezési eseményéből.

Rögzítés

A kiadási folyamat bevezetést lezáró eseményéből származik.

Eseménytípus explicit
Fejlesztés megkezdve
Azt jelzi, hogy a fejlesztő megkezdte a munkát az elemen. Erre a munkaelem állapotának „Active”, „In Progress” vagy „Committed” értékre váltásából lehet következtetni.
Miért fontos?

Az aktív fejlesztési szakasz kezdetét jelöli. A „Created” és a „Development Started” közötti idő elemzésével mérhető a backlogban töltött várakozási idő.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, amikor a System.State mező „New” vagy „Approved” értékről „In Progress” értékre változik.

Rögzítés

A State mező „Active” vagy „In Progress” értékre váltásából következtethető ki.

Eseménytípus inferred
Munkaelem létrehozva
Ez a tevékenység jelöli a fejlesztési életciklus kezdetét: ekkor jön létre egy új munkaelem, például felhasználói történet, hiba vagy feladat. A rendszer akkor rögzíti, amikor az Azure DevOps Boardsban mentik az új rekordot.
Miért fontos?

Ez a folyamat elsődleges kezdőeseménye. Nélküle nem mérhető a teljes fejlesztési ciklusidő, és a munka kezdeti forrásai sem érthetők meg.

Hol szerezhető be?

Az esemény a munkaelem „Created Date” mezőjéből származik. A munkaelem előzményei az első állapotátmenetet is rögzítik.

Rögzítés

A munkaelem „Created Date” mezőjéből származik.

Eseménytípus explicit
Pull Request létrehozva
Azt jelzi, hogy a fejlesztő befejezte az első kódolási szakaszt, és Pull Requesten keresztül ellenőrzésre küldte a módosításokat. Az esemény összekapcsolja a munkaelemet az Azure Reposban végzett konkrét kódmódosítással.
Miért fontos?

Ez a fejlesztés és a kódellenőrzés közötti fontos átadás. Nyomon követésével mérhető a kódolás időtartama, és megállapítható, mikor áll készen a kód a szakmai ellenőrzésre.

Hol szerezhető be?

Az Azure Repos adataiból rögzíthető, ha a Pull Request létrehozásának eseményét összekapcsolják a hozzá tartozó munkaelemmel. Ezt a kapcsolatot gyakran a fejlesztő hozza létre.

Rögzítés

Az Azure Reposban rögzített Pull Request-létrehozási eseményből származik, amely egy munkaelemhez kapcsolódik.

Eseménytípus explicit
Pull Request lezárva
A kódellenőrzés sikeres befejezését jelöli: a Pull Requestet jóváhagyták, a kódot pedig beolvasztották a célágba. Ezt az eseményt az Azure Repos kifejezetten rögzíti.
Miért fontos?

A kódellenőrzési szakasz végét jelöli, amely gyakran szűk keresztmetszet. A Pull Request létrehozása és lezárása közötti időből megítélhető az ellenőrzési ciklus hatékonysága.

Hol szerezhető be?

Az Azure Reposban rögzített lezárási vagy beolvasztási eseményből származik, ha a Pull Request egy munkaelemhez kapcsolódik.

Rögzítés

A munkaelemhez kapcsolódó Pull Request beolvasztási eseményéből származik.

Eseménytípus explicit
QA-tesztelés megkezdve
A hivatalos minőségbiztosítási tesztelési szakasz kezdetét jelöli. Erre akkor lehet következtetni, ha a munkaelem állapota „In QA”, „Testing” vagy egy hasonló értékre változik.
Miért fontos?

A QA-ciklus kezdetét jelöli. A szakasz időtartamának elemzése segít feltárni a tesztelés szűk keresztmetszeteit és megítélni annak hatékonyságát.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező értéke „In QA” vagy egy másik kijelölt tesztelési állapotra változik.

Rögzítés

A State mező „In QA” vagy „Testing” értékre váltásából következtethető ki.

Eseménytípus inferred
UAT jóváhagyva
Azt jelzi, hogy az üzleti érintettek a felhasználói átvételi tesztelés után jóváhagyták a módosításokat. Erre általában az „In UAT” állapotból „UAT Approved” vagy „Ready for Release” állapotba váltásból lehet következtetni.
Miért fontos?

Ez a fontos jóváhagyási mérföldkő igazolja, hogy a munkaelem megfelel az üzleti követelményeknek, és készen áll az éles környezetbe való bevezetésre.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező UAT-állapotról jóváhagyott vagy kiadásra kész állapotra változik.

Rögzítés

A State mező „In UAT” értékről „Ready for Release” értékre váltásából következtethető ki.

Eseménytípus inferred
Build sikeres
Ez a tevékenység igazolja, hogy a buildfolyamat sikeresen lefordította és csomagolta a forráskódot, az új módosításokkal együtt. Az Azure Pipelines ezt kifejezetten rögzíti.
Miért fontos?

Fontos minőségi ellenőrzési pont: igazolja, hogy az új kód megfelelően illeszkedik, és nem töri el a buildet. Az itt jelentkező hibák integrációs problémára utalhatnak.

Hol szerezhető be?

Az Azure Pipelines buildbefejezési eseményeiből származik. A buildet közvetlenül vagy a hozzá tartozó Pull Requesten keresztül kell összekapcsolni a munkaelemmel.

Rögzítés

Az Azure Pipelines buildbefejezési eseményéből származik.

Eseménytípus explicit
Fejlesztés befejezve
Azt jelzi, hogy a fejlesztés és az egységtesztelés befejeződött, az elem pedig készen áll a hivatalos tesztelésre. Erre általában a munkaelem „Resolved” vagy „Ready for Test” állapotba váltásából lehet következtetni.
Miért fontos?

Ez a fejlesztőcsapat és a QA-csapat közötti fontos átadást jelöli. A befejezés és a „QA Testing Started” közötti idő mérésével feltárhatók az átadás késései.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező értéke „Resolved” vagy egy QA-ra való felkészültséget jelző egyéni állapotra változik.

Rögzítés

A State mező „Resolved” értékre váltásából következtethető ki.

Eseménytípus inferred
Munkaelem jóváhagyva
A munkaelem hivatalos jóváhagyását jelöli. Ez megerősíti, hogy az elem meghatározása megfelelő, és készen áll a fejlesztésre. Az eseményre általában a „State” mező „Approved” vagy „Ready for Dev” értékre váltásából lehet következtetni.
Miért fontos?

A jóváhagyások nyomon követésével elemezhető az ötlet benyújtása és a fejlesztés vállalása közötti idő. Így feltárhatók a tervezés és a backlog rendezése során jelentkező késések.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező értéke „Approved” vagy egy hasonló egyéni állapotra változik.

Rögzítés

A State mező „Approved” értékre váltásából következtethető ki.

Eseménytípus inferred
Munkaelem lezárva
A munkaelem végleges lezárását jelöli a bevezetés és az esetleges utólagos ellenőrzések után. Ezt a „Closed” vagy „Done” állapotba váltás rögzíti.
Miért fontos?

Ez a tevékenység jelöli a munkaelemhez kapcsolódó teljes folyamat sikeres lezárását. Az életciklus végpontja.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező „Closed” vagy a „Completed” kategória egy hasonló végállapotára változik.

Rögzítés

A State mező „Closed” értékre váltásából következtethető ki.

Eseménytípus inferred
Munkaelem törölve
Azt jelzi, hogy a munkaelemet törölték, ezért nem fejezik be és nem vezetik be. Ezt a „Removed”, „Cancelled” vagy egy hasonló állapotra váltás rögzíti.
Miért fontos?

Ez a folyamat sikertelen, alternatív lezárását jelöli. A törölt elemek elemzése feltárhatja a tervezéssel, a prioritásokkal vagy a követelmények meghatározásával kapcsolatos problémákat.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező a „Removed” kategória valamely végállapotára változik.

Rögzítés

A State mező „Removed” vagy „Cancelled” értékre váltásából következtethető ki.

Eseménytípus inferred
QA-tesztelés befejezve
A minőségbiztosítási szakasz sikeres befejezését jelöli. Erre akkor lehet következtetni, ha a munkaelem tesztelési állapotból „Ready for UAT” vagy „QA Approved” állapotba vált.
Miért fontos?

Ez fontos minőségi ellenőrzési pont: azt jelzi, hogy az elem készen áll a felhasználói átvételi tesztelésre vagy a kiadásra. Az ezt követő késések az UAT vagy a kiadás tervezésének szűk keresztmetszeteire utalhatnak.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező „In QA” értékről egy következő állapotra, például „Ready for UAT” vagy „Done” értékre változik.

Rögzítés

A State mező „In QA” értékről „Ready for UAT” értékre váltásából következtethető ki.

Eseménytípus inferred
QA-tesztelés sikertelen
Azt jelzi, hogy a munkaelem nem felelt meg a QA-tesztelésen, ezért visszakerül a fejlesztéshez. Ezt a tesztelési állapotból „In Progress” vagy „Active” állapotba történő visszaváltás rögzíti.
Miért fontos?

Ez a tevékenység segít feltárni az ismételt munkához vezető köröket. Ha gyakran fordul elő, az a kód minőségével, a követelményekkel vagy a tesztelési folyamattal kapcsolatos problémákra utalhat.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha az állapot például „In QA” értékről „Active” vagy „In Progress” értékre vált vissza.

Rögzítés

A State mező „In QA” értékről „Active” értékre váltásából következtethető ki.

Eseménytípus inferred
UAT megkezdve
A felhasználói átvételi tesztelés kezdetét jelöli. Ennek során az üzleti érintettek ellenőrzik a funkcionalitást. Az eseményre általában az „In UAT” vagy egy hasonló állapotra váltásból lehet következtetni.
Miért fontos?

A kiadás előtti végső ellenőrzés kezdetét méri. A folyamat javításához elemezni kell az UAT időtartamát és a jóváhagyásra várakozással töltött időt.

Hol szerezhető be?

A munkaelem előzményeiből következtethető ki, ha a System.State mező UAT-t jelölő egyéni állapotra, például „In UAT” értékre változik.

Rögzítés

A State mező „In UAT” értékre váltásából következtethető ki.

Eseménytípus inferred
Javasolt Nem kötelező

Adatkinyerési útmutatók

Adatok kinyerése Azure DevOpsból

Kezdheti?

Kezdje el még ma szoftverfejlesztési életciklusának fejlesztését. Ez a sablon az első lépés ahhoz, hogy értékes információkat nyerjen ki a folyamataiból.

Fejlessze SDLC-folyamatát Azure DevOpsban, kezdje el még ma!

Csökkentse 30%-kal a ciklusidőt, és szüntesse meg az SDLC-munkafolyamat szűk keresztmetszeteit.

Próbálja ki ingyen

Nincs szükség bankkártyára. Néhány perc alatt elkezdheti.