Szoftverfejlesztési életciklus: adatsablon

Jira Software
Szoftverfejlesztési életciklus: adatsablon

Szoftverfejlesztési életciklus: adatsablon

Ez a sablon útmutatást ad a szoftverfejlesztési életciklus elemzéséhez szükséges adatok összegyűjtéséhez. Bemutatja a gyűjtendő alapvető adatmezőket, a követendő folyamatlépéseket, és gyakorlati tanácsokat ad az adatok Jira Software-ből történő kinyeréséhez. Az útmutatóval előkészítheti az eseménynaplót a process mining elemzéshez.
  • Javasolt attribútumok
  • Követendő tevékenységek
  • Útmutató az adatok kinyeréséhez a Jira Software-bő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.
5 Kötelező 6 Javasolt 10 Nem kötelező
Név Leírás
Esemény időpontja
EventTime
Az a pontos dátum és időpont, amikor egy adott fejlesztési tevékenység vagy esemény történt.
Leírás

Az esemény időpontja rögzíti, hogy mikor történt egy tevékenység. Ez adja a process mining elemzések időbeli alapját, és meghatározza az események sorrendjét az egyes ügyeken belül.

Ez az attribútum nélkülözhetetlen minden időalapú mutató kiszámításához, beleértve az átfutási, feldolgozási és a tevékenységek közötti várakozási időt. Segítségével időben is elemezhető a folyamat teljesítménye, így feltárható, mikor és hol keletkeznek késések a fejlesztési életciklusban.

Miért fontos?

Ez az időbélyeg szükséges az események helyes sorrendbe állításához és az időtartam-alapú mutatók kiszámításához. Ezek segítenek megérteni a folyamat hatékonyságát és feltárni a késéseket.

Hol szerezhető be?

Ez az issue változásnaplójában vagy előzményeiben szereplő bejegyzés „created” időbélyegének felel meg.

Példák
2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
Fejlesztési tétel
DevelopmentItem
Egyetlen munkaegység egyedi azonosítója a Jira Software-ben, például egy story, hiba vagy feladat azonosítója.
Leírás

A fejlesztési tétel az elsődleges ügyazonosító. Egy konkrét munkaegységet jelöl, például egy funkciót, hibajavítást vagy feladatot. Összekapcsolja az adott tételhez tartozó összes tevékenységet a kezdeti ötlettől és tervezéstől a fejlesztésen és tesztelésen át a telepítésig. A Jira rendszerben ez általában az issue kulcsának felel meg, például „PROJ-123”.

Ennek az attribútumnak az elemzésével nyomon követhető minden munkaelem teljes életútja. Ez az alapja a folyamattérképek létrehozásának, az átfutási idők kiszámításának és annak feltárásának, hogy az egyes tételek milyen eltérő útvonalakon haladnak végig a fejlesztési folyamaton.

Miért fontos?

Ez az azonosító kapcsolja össze a fejlesztési tevékenységeket, így egyetlen munkaelem útja az elejétől a végéig nyomon követhető.

Hol szerezhető be?

Ez a Jira Software Issue API-objektum issue-jának szabványos „key” mezője.

Példák
PROJ-101CORE-5432API-789
Tevékenység
Activity
Egy adott esemény vagy állapotváltozás neve, amely a tétel fejlesztési életciklusa során történt.
Leírás

Ez az attribútum a szoftverfejlesztési folyamat egy-egy lépését vagy mérföldkövét jelöli. A tevékenységek a Jira-issue állapotmezőjének változásaiból vagy más jelentős eseményekből, például kódmódosításokból és felülvizsgálatokból származnak.

A process mining során ezek a tevékenységek alkotják a folyamattérkép sorrendjét. Elemzésükkel feltárható a folyamat menete, mérhető az egyes szakaszok időtartama, és észrevehetők a szokásos munkafolyamattól való eltérések, például az ismételt javítási körök vagy a minőségellenőrzési lépések kihagyása.

Miért fontos?

A tevékenységek határozzák meg a folyamat lépéseit. Sorrendjük alapján jeleníthető meg a folyamat menete, azonosíthatók a szűk keresztmetszetek és elemezhetők a folyamat eltérései.

Hol szerezhető be?

Általában a Jira-issue előzményeiben vagy változásnaplójában szereplő „status” mező változásaiból származik. Kapcsolódó fejlesztőeszközök adataival is kiegészíthető.

Példák
Fejlesztés megkezdveKódellenőrzés elvégezveQA-tesztelés befejezveÉles környezetbe telepítve
Adatok utolsó frissítése
LastDataUpdate
Az időpont, amikor a folyamat adatait legutóbb frissítették a forrásrendszerből.
Leírás

Ez az attribútum rögzíti a Jira Software-ből végzett legutóbbi adatkinyerés dátumát és időpontját. Megmutatja, mennyire frissek az elemzett adatok.

Az utolsó frissítés időpontja segít megítélni, mennyire aktuálisak a folyamatra vonatkozó megállapítások. Az elemzők és az üzleti felhasználók ellenőrizhetik, hogy a legfrissebb adatokkal dolgoznak-e, és láthatják, meddig tart az elemzésben szereplő események köre.

Miért fontos?

Megmutatja, mennyire frissek az adatok. Így ellenőrizhető, hogy az elemzések és a dashboardok a folyamat legutóbbi állapotát tükrözik-e.

Hol szerezhető be?

Ez az időbélyeg az adatkinyerési, -átalakítási és -betöltési (ETL) folyamat végén jön létre és kerül rögzítésre.

Példák
2024-03-15T02:00:00Z2024-03-16T02:00:00Z
Forrásrendszer
SourceSystem
Az a rendszer, amelyből a fejlesztési életciklus adatait kinyerték.
Leírás

Ez az attribútum azonosítja az adatok forrását. Ennél a folyamatnál az értéke mindig „Jira Software”, de akkor is hasznos, ha egy nagyobb elemzés több forrásrendszer adatait egyesíti.

A teljes IT-környezetben a forrásrendszer megadása egyértelművé teszi az adatok eredetét, és segít az adatminőség, valamint a különböző platformok közötti integráció kezelésében.

Miért fontos?

Egyértelművé teszi az adatok eredetét. Ez különösen fontos több rendszer adatainak összekapcsolásakor, valamint az adatirányítás és az auditálás során.

Hol szerezhető be?

Ez egy állandó érték, amelyet az adatok kinyerése és átalakítása során kell megadni.

Példák
Jira Software
Csapat neve
TeamName
A munkaelemért felelős fejlesztőcsapat.
Leírás

A fejlesztési tételhez rendelt agilis vagy funkciófejlesztő csapatot jelöli. A Jirában ez gyakran egy egyéni mező, de a projektből vagy egy adott komponensből is meghatározható.

Ez az attribútum nélkülözhetetlen a csapatok teljesítményének elemzéséhez. A dashboardok csapat szerint szűrhetők, így megjeleníthetők például az egyes csapatok átfutási idejére, ismételt munkájára és áteresztőképességére vonatkozó mutatók. Ez különösen hasznos az „Inter-Phase Handoff Efficiency” és a „Developer Workload & Item Progress” dashboardokhoz.

Miért fontos?

Lehetővé teszi a fejlesztőcsapatok teljesítményének mérését és összehasonlítását, így azonosíthatók a jól teljesítő csapatok és megoszthatók a bevált gyakorlatok.

Hol szerezhető be?

Ez gyakran egyéni Jira-mező. A pontos mezőnévért kérdezze meg a Jira-adminisztrátort. A mező neve lehet például „Team”, „Squad” vagy hasonló.

Példák
Team PhoenixAlapszolgáltatásokUI/UX Avengers
Felelős
Assignee
A fejlesztési tétel kezeléséért jelenleg felelős felhasználó.
Leírás

A felelős az a személy, aki a munkaelem aktuális szakaszában a munkáért felel. A Jira szabványos mezője, amelynek értéke változik, ahogy a tétel másik személyhez vagy csapathoz kerül.

A felelős elemzése segít megérteni az erőforrások elosztását, a munkaterhelést és az átadási pontokat. Megmutatja, mely fejlesztők vagy csapatok vesznek részt az egyes szakaszokban, hol alakul ki szűk keresztmetszet, és hogyan oszlik meg a munka a szervezeten belül.

Miért fontos?

Azonosítja a tevékenységért felelős felhasználót vagy erőforrást. Ez lehetővé teszi a munkaterhelés elemzését, az erőforrások kezelését és a személyek közötti átadások nyomon követését.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „assignee” mező.

Példák
Alice SmithBob JohnsonNincs felelős
Projekt neve
ProjectName
Annak a Jira-projektnek a neve, amelyhez a fejlesztési tétel tartozik.
Leírás

A Jira a munkaelemeket projektekbe rendezi. A projekt neve magas szintű kontextust ad, és gyakran egy adott terméknek, csapatnak vagy kezdeményezésnek felel meg.

Ez az attribútum hasznos szűrési és összehasonlítási szempont. Segítségével különböző projektek vagy termékek SDLC-folyamatai elemezhetők és vethetők össze. Kiderülhet, mely projektek működnek hatékonyabban, hol gyakoribb az ismételt munka, és hogy a csapatok eltérő folyamatváltozatokat követnek-e.

Miért fontos?

Lehetővé teszi a folyamat elemzésének projekt, termék vagy csapat szerinti bontását, így összehasonlítható a teljesítmény és azonosíthatók a bevált gyakorlatok.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „project” mező.

Példák
Mobilalkalmazás-fejlesztésAlapplatformAdattudomány
Tétel állapota
ItemStatus
A fejlesztési tétel aktuális állapota a munkafolyamatban.
Leírás

Ez az attribútum a fejlesztési elem adott időpontban érvényes állapotát mutatja, például „Folyamatban”, „Ellenőrzés alatt” vagy „Kész”. Az állapotváltozások időbeli sorrendje adja a process mininghez szükséges tevékenységeket.

Az „Activity” attribútum a változást jelző eseményt mutatja, az „ItemStatus” pedig az elem állapotát. Az „ItemStatus” szűrési és elemzési szempontként használható: megmutatja, hány elem van éppen egy adott állapotban, illetve segít elemezni azok jellemzőit, amelyek hosszú ideig maradnak ugyanabban az állapotban.

Miért fontos?

Megmutatja, hol tart a tétel az életciklusában. Ez alapot ad az állapot szerinti elemzéshez és a folyamatban lévő munka aktuális helyzetének megértéséhez.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „status” mező.

Példák
TeendőkFolyamatbanFelülvizsgálat alattKész
Tétel prioritása
ItemPriority
A fejlesztési tételhez rendelt prioritási szint, amely jelzi a sürgősségét.
Leírás

A tétel prioritása a munkaelem relatív fontosságát vagy sürgősségét jelzi. A Jira szabványos „priority” mezője konfigurálható értékeket kínál, például Highest, High, Medium és Low.

A prioritás elemzésével ellenőrizhető a folyamatnak való megfelelés, és feltárhatók a kritikus tételek szűk keresztmetszetei. A „Priority Item Conformance Check” dashboard például ezt az attribútumot használja annak ellenőrzésére, hogy a magas prioritású tételek a várakozásoknak megfelelően gyorsabban haladnak-e, vagy az alacsony prioritásúakkal azonos sorokban torlódnak fel.

Miért fontos?

Segít megvizsgálni, hogy a magas prioritású tételek gyorsabban készülnek-e el, mint az alacsony prioritásúak, és gördülékenyebb útvonalon haladnak-e, hogy teljesüljenek az SLA-k.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „priority” mező.

Példák
LegmagasabbMagasKözepesAlacsony
Tétel típusa
ItemType
A fejlesztési elem besorolása, például hiba, történet, feladat vagy epik.
Leírás

A tétel típusa a végzett munka jellegét határozza meg. A Jira szabványos „issuetype” mezője különbözteti meg a munkaelemek típusait, amelyekhez gyakran eltérő munkafolyamat tartozik.

Ez az attribútum nélkülözhetetlen az összehasonlító elemzéshez. Segítségével szűrhetők a folyamat adatai munkaelem-típus szerint, például összevethető egy „Bug” és egy „Story” életútja. Így kiderülhet, hogy bizonyos munkatípusoknál gyakoribbak-e a késések, az ismételt javítások vagy a szokásos folyamattól való eltérések.

Miért fontos?

Lehetővé teszi a folyamat elemzésének munkaelem-típus szerinti bontását. Összehasonlítható például a hibák és az új funkciók kezelése, és feltárhatók a folyamatok közötti különbségek.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „issuetype” mező.

Példák
StoryHibaFeladatEpic
Átadásra várakozás ideje
HandoffWaitTime
Két egymást követő tevékenység közötti tétlen idő.
Leírás

Ez a mutató az egyik tevékenység befejezése és a következő kezdete közötti várakozási, illetve sorban állási időt méri. Azt mutatja meg, mennyi ideig vár a munka arra, hogy valaki foglalkozzon vele.

Ez a mutató az „Átlagos átadási várakozási idő” KPI és a „Szakaszok közötti átadás hatékonysága” dashboard alapja. A hosszú átadási idők gyakran koordinációs problémára, erőforráshiányra vagy a csapatok közötti nem hatékony kommunikációra utalnak, például a fejlesztés és a QA között. A tétlen idő csökkentésével mérsékelhető a teljes átfutási idő.

Miért fontos?

Megmutatja a folyamat tétlen és sorban állással töltött idejét. Feltárja a csapatok vagy munkatársak közötti átadások hatékonysági problémáit és a koordinációs nehézségeket.

Hol szerezhető be?

Számított mutató. Az adott esetben egy tevékenység kezdési időpontjából le kell vonni az előző tevékenység befejezési időpontját.

Példák
017280043200
Bejelentő
Reporter
Az a felhasználó, aki eredetileg létrehozta vagy bejelentette a fejlesztési tételt.
Leírás

A bejelentő az a személy, aki létrehozta az issue-t a Jirában. Lehet fejlesztő, QA-tesztelő, termékmenedzser vagy akár ügyfél is, aki egy ügyfélszolgálati integráción keresztül küldte be a bejelentést.

A bejelentő elemzése megmutathatja, honnan érkezik a munka. Például összehasonlítható a QA-csapat és az ügyfelek által bejelentett hibák életútja. Az elemzés a kommunikációs minták és a folyamat elején zajló információáramlás megértésében is segíthet.

Miért fontos?

Megmutatja, honnan származik a munkaelem. Segítségével elemezhetők a feladatok létrehozásához és a hibák bejelentéséhez kapcsolódó minták.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „reporter” mező.

Példák
Charles DarwinMarie CurieIsaac Newton
Esemény befejezési időpontja
EventEndTime
Az az időpont, amikor egy tevékenység vagy állapot befejeződött.
Leírás

Ez az attribútum jelöli a tevékenység befejezésének időpontját. Egy adott ügy eseménysorában ez a következő tevékenység időbélyege.

Míg az „EventTime” (StartTime) a tevékenység kezdetét jelöli, az EventEndTime a végét. A két időbélyeg különbsége adja a tevékenység feldolgozási idejét. Ez szükséges az „Average Stage Processing Time” KPI kiszámításához és a tevékenységek időtartamát elemző dashboardok létrehozásához.

Miért fontos?

Meghatározza a tevékenység végét, így kiszámítható a folyamat egyes lépéseinek időtartama. Ez nélkülözhetetlen a szűk keresztmetszetek elemzéséhez.

Hol szerezhető be?

Ez egy származtatott attribútum. Egy adott esemény befejezési időpontja ugyanazon ügy következő eseményének kezdési időpontja.

Példák
2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
Ismételt munka
IsRework
Jelző, amely megmutatja, hogy a tevékenység része-e egy ismételt munkakörnek.
Leírás

Ez a logikai attribútum akkor igaz, ha egy tevékenység visszalépést jelent a folyamatban, például ha egy elem sikertelen minőségbiztosítási teszt után visszakerül a „Fejlesztés megkezdve” állapotba. Az érték meghatározásához az eset tevékenységeinek sorrendjét kell elemezni.

Az utómunka azonosítása alapvető a folyamat hatékonyságának és minőségének javításához. Ez az attribútum közvetlenül támogatja az „Utómunka aránya” KPI-t és az „Utómunka ismétlődése és útvonalai” dashboardot. Segítségével számszerűsítheti a felesleges munkát, és azonosíthatja az utómunkát okozó minőségi problémák kiváltó okait.

Miért fontos?

Egyértelműen jelzi, ha egy tevékenység a folyamatot lassító ismétlődő kör része. Így pontosan mérhető és elemezhető a folyamatveszteség és a minőségi problémák mértéke.

Hol szerezhető be?

Számított attribútum. Először meg kell határozni az elvárt folyamatmenetet, majd megjelölni minden olyan tevékenységet, amely egy korábbi szakaszba visszalépve eltér ettől.

Példák
truefalse
Javító verzió
FixVersion
Az a szoftververzió, amelyben a fejlesztési tételt ténylegesen megoldották és kiadták.
Leírás

A Jira „Fix Version” mezője jelzi, melyik kiadás tartalmazza a tételhez elkészült munkát. A fejlesztés konkrét eredményét rögzíti.

Ez az attribútum megadja a tényleges kiadás kontextusát, amely összevethető a „PlannedReleaseVersion” értékével a szállítási teljesítmény elemzéséhez. Az adott kiadásban szállított tételek csoportosítására is használható, így egy helyen áttekinthető, mi készült el.

Miért fontos?

Megerősíti, melyik kiadásba került be az adott munka. Ez adja a kiadáselemzés és a leszállított funkciók nyomon követésének tényleges alapját.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fixVersions” mezőjének felel meg.

Példák
v2.1.1 gyorsjavításv3.0.0 főverzióv2.2.0
Komponens
Component
A projekt egy részterülete vagy funkcionális egysége, amelyhez a tétel tartozik.
Leírás

A Jira komponensekkel kisebb, könnyebben kezelhető részekre bonthatók egy projekt issue-jai. A komponens jelölhet egy funkcióterületet, például a „User Authentication” részt, egy technikai réteget, például a „Backend API”-t, vagy egy modult, például a „Reporting” részt.

A komponensenkénti elemzés részletesebb képet ad a fejlesztési folyamatról. Segít feltárni, hogy az alkalmazás egyes részeinél gyakoribbak-e a hibák, hosszabbak-e a fejlesztési ciklusok vagy többször kell-e javítani. Ez technikai adósságra vagy összetettségre utalhat.

Miért fontos?

Lehetővé teszi a folyamat termékfunkciók vagy technikai területek szerinti bontását, így meghatározható, mely komponenseknél jelentkeznek késések vagy minőségi problémák.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található szabványos „components” mező.

Példák
Felhasználói felületAdatbázisAPI-átjáróHitelesítés
Sprint neve
SprintName
Annak az agilis sprintnek a neve, amelyhez a fejlesztési tételt rendelték.
Leírás

A Scrumot használó csapatoknál a sprint egy meghatározott időtartamú időszak, amely alatt egy adott munkacsomag készül el. Ez az attribútum rögzíti annak a sprintnek a nevét vagy azonosítóját, amelyhez a tétel tartozik.

A sprintenkénti elemzés az agilis folyamatok process mining alapú vizsgálatának egyik alapja. Segít értékelni az egyes sprintek teljesítményét, megérteni az áthúzódó munkát és nyomon követni a sprintcélok teljesülését. Az általános dátumtartományoknál pontosabb időbeli kontextust ad.

Miért fontos?

Fontos kontextust ad az agilis csapatoknak, és lehetővé teszi a folyamat hatékonyságának és áteresztőképességének sprintenkénti elemzését.

Hol szerezhető be?

Ezt az információt általában a Jira Software (Agile) által kezelt egyéni „Sprint” mező tárolja. Az adatok az Issue API-n keresztül érhetők el.

Példák
PROJ 1. sprintQ4-2023 3. sprintNovemberi PI 2. sprint
Teljes átfutási idő
CycleTime
Egy fejlesztési feladat teljes, elejétől a végéig tartó időtartama.
Leírás

Az átfutási idő azt mutatja meg, mennyi idő telik el egy fejlesztési feladat létrehozásától a végleges lezárásáig, például az éles környezetbe történő telepítésig. Esetenként az első és az utolsó esemény időbélyege közötti különbségként számítható ki.

Ez az egyik legfontosabb KPI a folyamat sebességének és hatékonyságának mérésére. Az „Átlagos teljes átfutási idő” KPI és a „Teljes SDLC-átfutásiidő-elemzés” dashboard közvetlenül ezen a számításon alapul. A folyamatfejlesztési kezdeményezések gyakori célja az átfutási idő csökkentése.

Miért fontos?

A fejlesztési folyamat elejétől a végéig tartó sebességét méri, így a teljes hatékonyság és a szállítási sebesség egyik fő mutatója.

Hol szerezhető be?

Esetenként számított attribútum. Az adott „DevelopmentItem” esetében az első esemény időbélyegét le kell vonni az utolsó esemény időbélyegéből.

Példák
12096002592000604800
Tervezett kiadás
PlannedReleaseVersion
Az a célként megadott szoftververzió vagy kiadás, amelyben a tételt telepíteni tervezik.
Leírás

Ez az attribútum, amelyet a Jirában gyakran az „Affects Version/s” mező tartalmaz, megadja, melyik kiadásba szánják a funkciót vagy javítást. A munka befejezésének határidejét vagy célját jelöli.

Ez az attribútum szükséges az „On-Time Release Delivery Rate” KPI kiszámításához. Ha összeveti a tényleges telepítés dátumát az ehhez a verzióhoz tartozó tervezett kiadási dátummal, mérheti az ütemterv betartását és a kiadási folyamat kiszámíthatóságát.

Miért fontos?

Meghatározza a célként kitűzött szállítási dátumot vagy kiadást. Segítségével kiszámítható a határidőre történő szállítás aránya, és elemezhető az ütemterv betartása.

Hol szerezhető be?

Ez a Jira Issue API „versions” vagy „fixVersions” mezőjének felel meg. A tervezéshez használt mező eltérhet.

Példák
2.1-es verzió2024. első negyedévi kiadásProject Phoenix indulása
Tétel lezárásának oka
ItemResolution
A fejlesztési tétel végső kimenetele vagy lezárásának oka.
Leírás

A lezárás oka megmutatja, miért került egy tétel lezárt állapotba. Az állapot lehet például „Closed”, a lezárás oka pedig „Done”, „Won't Do”, „Duplicate” vagy „Cannot Reproduce”. Ez fontos háttér-információt ad a munka kimeneteléről.

A lezárási ok elemzésével megkülönböztethetők a sikeresen befejezett munkák a törölt vagy elutasított tételektől. Ez segít a minőség elemzésében, valamint annak megértésében, hogy mennyi értékes munka készült el, és mennyi ráfordítás jutott végül elvetett tételekre.

Miért fontos?

Megkülönbözteti a sikeresen befejezett tételeket az egyéb okból lezártaktól. Ez pontosabb termelékenységi és minőségi elemzést tesz lehetővé.

Hol szerezhető be?

Ez a Jira Issue API válaszának „fields” objektumában található „resolution” mező. Általában csak az issue lezárásakor kap értéket.

Példák
KészNem készül elDuplikátumNem reprodukálható
Kötelező Javasolt Nem kötelező

A szoftverfejlesztési életciklus tevékenységei

A szoftverfejlesztési életciklus pontos feltérképezéséhez ezeket a fontos folyamatlépéseket és mérföldköveket rögzítse az eseménynaplóban.
6 Javasolt 8 Nem kötelező
Tevékenység Leírás
Éles környezetbe telepítve
Ez az esemény jelzi, hogy a fejlesztési tételhez tartozó kódmódosítások éles környezetben elérhetővé váltak. Ez kikövetkeztethető az állapot végső „Done” vagy „Released” értékre váltásából, de rögzíthető egy integrált CI/CD-eszköz kifejezett eseményeként is.
Miért fontos?

Ez a folyamat elsődleges sikeres végpontja. Nélkülözhetetlen a teljes, elejétől a végéig tartó átfutási idő kiszámításához, valamint a telepítések gyakoriságának és áteresztőképességének méréséhez.

Hol szerezhető be?

A Jira-issue változásnaplójából következtethető ki, amikor az állapot „Released” vagy „Done” értékre változik. Pontosabban rögzíthető a CI/CD-eszközök, például a Jenkins vagy a Bamboo által küldött telepítési eseményekből, illetve a Jira Deployments funkciójával.

Rögzítés

Az az időpont, amikor az állapot „Done” vagy „Released” értékre változik.

Eseménytípus inferred
Fejlesztés megkezdve
Azt jelöli, amikor a fejlesztő ténylegesen elkezd dolgozni a fejlesztési tételen. Ezt szinte mindig a Jira-munkafolyamat állapotváltozásából lehet megállapítani, például amikor az ügy állapota „In Progress” lesz.
Miért fontos?

Ez fontos mérföldkő az aktív fejlesztési idő méréséhez. Segít elkülöníteni a várakozást az értéket teremtő munkától, ami fontos mutató a szűk keresztmetszetek feltárásához.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Az időbélyeg azt mutatja, mikor vált először „In Progress”, „In Development” vagy hasonló aktív állapotra a „status” mező.

Rögzítés

Az állapot „In Progress” értékre váltásának időbélyege.

Eseménytípus inferred
Fejlesztési tétel létrehozva
Ez jelöli az életciklus kezdetét, amikor egy új fejlesztési tételt, például történetet, hibát vagy feladatot rögzítenek a Jirában. A rendszer minden ügyhöz rögzíti a létrehozás időbélyegét.
Miért fontos?

Ez a tevékenység jelöli a folyamat egyértelmű kezdetét. Erre van szükség a teljes ciklusidő kiszámításához és a beérkező munka mennyiségének nyomon követéséhez.

Hol szerezhető be?

Ez minden Jira-ügy alapvető eseménye. A létrehozás időbélyegét az ügyrekord „created” mezője tárolja, amely a Jira API-n keresztül érhető el.

Rögzítés

A Jira Issue objektum „created” időbélyegmezője.

Eseménytípus explicit
QA-tesztelés befejezve
Azt jelzi, hogy a fejlesztési tétel sikeresen teljesítette az összes minőségbiztosítási ellenőrzést, és készen áll a következő szakaszra, például a User Acceptance Testingre vagy a kiadásra. Ez a fő tesztelési állapotból való továbblépés alapján állapítható meg.
Miért fontos?

Ez jelöli egy fontos minőségellenőrzési pont teljesítését. A QA-szakasz időtartamának elemzése segít javítani a tesztelési folyamatokat és az erőforrások elosztását.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Az időbélyeg azt mutatja, mikor vált a „status” mező „In QA” értékről egy következő állapotra, például „Ready for UAT” vagy „Ready for Release” értékre.

Rögzítés

Az állapot „In QA” értékről „Ready for UAT” értékre váltásának időbélyege.

Eseménytípus inferred
QA-tesztelés megkezdve
Ez az esemény jelöli a fejlesztési tétel hivatalos minőségbiztosítási tesztelésének kezdetét. A Jira állapotváltozásából állapítható meg, amikor az ügy például „In QA”, „In Testing” vagy „Ready for Testing” állapotba kerül.
Miért fontos?

Ez fontos mérföldkő, amely elindítja a minőségellenőrzési ciklust. A „Development Completed” és e pont közötti idő mérése megmutatja a fejlesztői és QA-csapat közötti átadás késedelmét.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Az időbélyeg azt mutatja, mikor vált a „status” mező egy kijelölt QA-tesztelési állapotra, például „In QA” értékre.

Rögzítés

Az állapot „In QA” vagy „In Testing” értékre váltásának időbélyege.

Eseménytípus inferred
UAT jóváhagyva
A User Acceptance Testing sikeres befejezését jelzi, vagyis az érintettek jóváhagyták a kiadást. Ez az „In UAT” állapotból például „Ready for Release” vagy „Done” állapotba történő váltásból állapítható meg.
Miért fontos?

Ez a mérföldkő igazolja az üzleti elfogadást, és jóváhagyja a tételt az élesítésre. Fontos ellenőrzési pont annak biztosításához, hogy az elkészült munka megfeleljen a felhasználói elvárásoknak.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Az időbélyeg azt mutatja, mikor vált az állapot „In UAT” értékről a munkafolyamat következő állapotára, jelezve a jóváhagyást.

Rögzítés

Az állapot „In UAT” értékről „Ready for Release” értékre váltásának időbélyege.

Eseménytípus inferred
A QA-tesztelés sikertelen
Azt jelzi, hogy a QA-csapat hibát talált, ezért a fejlesztési tételt javításra visszaküldték a fejlesztőknek. Ez az állapot visszalépéséből állapítható meg, például amikor az ügy „In QA” állapotból visszakerül „In Progress” vagy „To Do” állapotba.
Miért fontos?

Ez a tevékenység fontos az ismételt munkakörök feltárásához. Gyakoriságának nyomon követésével számszerűsíthető a gyenge minőség költsége, és azonosíthatók a fejlesztés vagy a követelmények javítandó területei.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Akkor rögzíthető, amikor a „status” mező tesztelési állapotból, például „In QA” értékről egy korábbi fejlesztési állapotra, például „In Progress” értékre vált.

Rögzítés

Az állapot tesztelési állapotról fejlesztési állapotra váltásának időbélyege.

Eseménytípus inferred
Fejlesztés befejezve
Ez a tevékenység azt jelzi, hogy a fejlesztő befejezte a kódolást, és a tétel készen áll a következő szakaszra, például a kódellenőrzésre vagy a tesztelésre. Ez a Jira állapotváltozásából állapítható meg, például amikor az ügy „In Progress” állapotból „In Review” vagy „Ready for QA” állapotba kerül.
Miért fontos?

Ez jelöli az alapvető fejlesztési szakasz végét. Így elemezhető a kódolás időtartama és a minőségbiztosítási csapatnak történő átadás hatékonysága.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. A rendszer rögzíti azt az időbélyeget, amikor a „status” mező aktív fejlesztési állapotból egy következő állapotba, például „In Review” vagy „Ready for QA” értékre vált.

Rögzítés

Az állapot „In Progress” értékről „In Review” vagy „Ready for QA” értékre váltásának időbélyege.

Eseménytípus inferred
Fejlesztési tétel lezárva
Ez az utolsó adminisztratív lépés, amely megerősíti, hogy a tétellel kapcsolatban nincs további teendő. Gyakran abból következtethető ki, hogy az állapot „Closed” értékre változik, és kitöltik a „Resolution” mezőt.
Miért fontos?

A tétel életútjának tényleges végét jelöli. Ha összeveti az „Éles környezetbe telepítve” eseménnyel, láthatóvá válhat az adminisztratív késedelem vagy a telepítés utáni megfigyelési időszak.

Hol szerezhető be?

A Jira-issue változásnaplójából következtethető ki. Ez az az időpont, amikor a „status” mező értéke „Closed” lesz, és megadják a lezárás okát.

Rögzítés

Az az időpont, amikor az állapot „Closed” értékre változik.

Eseménytípus inferred
Fejlesztési tétel törölve
A fejlesztési tétel befejezés előtti megszüntetését jelöli. Erre abból lehet következtetni, hogy az állapot egy végleges értékre, például „Canceled”, „Rejected” vagy „Won't Do” értékre változik. Ezt gyakran egy konkrét lezárási ok is kíséri.
Miért fontos?

Ez a tevékenység a sikertelen folyamatkimeneteleket követi nyomon. A törölt tételek okainak elemzése feltárhatja a tervezési, rangsorolási vagy követelmény-meghatározási problémákat.

Hol szerezhető be?

A Jira-issue változásnaplójából következtethető ki. Ez az az időpont, amikor az issue „status” mezője „Canceled” vagy „Won't Do” értékre változik, és megadják a megfelelő lezárási okot.

Rögzítés

Az az időpont, amikor az állapot „Canceled”, „Rejected” vagy „Won't Do” értékre változik.

Eseménytípus inferred
Fejlesztésre kész tétel
Azt jelzi, hogy a fejlesztési tétel leírása teljes, megtörtént az ellenőrzése és a prioritás meghatározása, így a fejlesztő megkezdheti a munkát. Ez általában a munkafolyamat állapotváltozásából állapítható meg, például amikor az ügy a „Backlog” állapotból „To Do” vagy „Ready for Dev” állapotba kerül.
Miért fontos?

Ennek nyomon követésével mérhető, mennyire áll készen a backlog, és mennyi ideig várnak a tételek a fejlesztés megkezdésére. Elkülöníthető a tervezésre és pontosításra fordított idő az aktív fejlesztési időtől.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Keresse meg azt az időbélyeget, amikor a „status” mező értéke „Ready for Dev”, „To Do” vagy „Selected for Development” lesz.

Rögzítés

Az állapot fejlesztés előtti, kész állapotra váltásának időbélyege.

Eseménytípus inferred
Kiadásra előkészítve
Azt jelzi, hogy a fejlesztési tétel minden ellenőrzésen megfelelt, és bekerült egy adott szoftverkiadásba. A telepítésre vár. Ez gyakran abból következtethető ki, hogy a Jira-issue állapota „Ready for Release” értékre változik, vagy kitöltik a „Fix Version” mezőt.
Miért fontos?

Ez a tevékenység segít nyomon követni, hogy a kiadás készen áll-e, és mennyi időt várnak a tételek a telepítési időablakra, miután a fejlesztés és a tesztelés befejeződött.

Hol szerezhető be?

Általában a Jira-issue változásnaplójából következtethető ki, ha az állapot „Ready for Release” értékre változik. A „Fix Version/s” mező kitöltésének időpontja is használható erre.

Rögzítés

Az az időpont, amikor az állapot „Ready for Release” értékre változik, vagy kitöltik a „Fix Version” mezőt.

Eseménytípus inferred
Kódellenőrzés elvégezve
Azt jelzi, hogy egy kolléga vagy vezető ellenőrizte a kód minőségét, szabványosságát és működését. Ez megállapítható az állapotváltozásból, például amikor az ügy „In Review” állapotból „Ready for QA” állapotba kerül, vagy közvetlenül az integrált fejlesztőeszközökből.
Miért fontos?

Ez a tevékenység fontos minőségellenőrzési pont. Az időtartam és az eredmények, például az ismételt munka elemzése segít javítani a kód minőségét és csökkenteni a folyamat későbbi szakaszaiban feltárt hibákat.

Hol szerezhető be?

Általában a Jira-ügy változásnaplójából állapítható meg, amikor az állapot kikerül a „Code Review” állapotból. A Bitbuckethez vagy GitHubhoz hasonló kódtároló eszközök integrálásával közvetlen eseményként is rögzíthető.

Rögzítés

Az állapot „In Review” értékről a következő állapotra váltásának időbélyege.

Eseménytípus inferred
UAT megkezdve
A User Acceptance Testing kezdetét jelöli. Ebben a szakaszban az üzleti érintettek vagy a végfelhasználók ellenőrzik az új funkciókat. Ez a Jira állapotváltozásából állapítható meg, például amikor az ügy „In UAT” vagy „User Acceptance Testing” állapotba kerül.
Miért fontos?

Ez a tevékenység a kiadás előtti végső ellenőrzési szakasz kezdetét jelöli. Időtartamának elemzése segít megérteni és csökkenteni az érintettek elérhetősége vagy a visszajelzési körök miatt kialakuló késedelmeket.

Hol szerezhető be?

A Jira-ügy változásnaplójából állapítható meg. Az időbélyeg azt mutatja, mikor frissült a „status” mező „In UAT” vagy hasonló kijelölt állapotra.

Rögzítés

Az állapot „In UAT” értékre váltásának időbélyege.

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

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a Jira Software-ből

Készen áll a kezdésre?

Kezdje el még ma a szoftverfejlesztési életciklus optimalizálását: készítse elő adatait ezzel a sablonnal. Tárja fel, hogyan gyorsíthatja a szállítást és javíthatja a minőséget.

Optimalizálja az SDLC-t a Jira Software-ben, kezdje el még ma!

Tárja fel a hatékonysági problémákat, és csökkentse 30%-kal az SDLC átfutási idejét.

Próbálja ki ingyen

Nincs szükség bankkártyára, perceken belül elkezdheti az optimalizálást.