Szoftverhibák definiálása, rögzítése, osztályozása és kezelése az Azure Boardsban

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Hogyan követheti nyomon és kezelheti a kód hibáit? Hogyan gondoskodhat arról, hogy a szoftverproblémák és az ügyfelek visszajelzései gyorsan megoldva legyenek a kiváló minőségű szoftvertelepítések támogatásához? És hogyan lehet jó eredményeket elérni az új funkciók terén, és kezelni a technikai adósságot?

Legalább meg kell adnia a szoftverproblémák rögzítésének, rangsorolásának, egy csapattaghoz való hozzárendelésének és az előrehaladás nyomon követésének módját. A kódhibákat pedig az Agilis gyakorlatnak megfelelő módon szeretné kezelni.

A forgatókönyvek támogatásához az Azure Boards egy adott munkaelem-típust biztosít a Hiba nevű kódhibák nyomon követéséhez. A hibakeresési munkaelemek más munkaelemtípusok összes szokásos funkcióját megosztják néhány további lehetőséggel. A standard funkciók áttekintését a felhasználói történetek, problémák, hibák, funkciók és eposzok nyomon követése című témakörben tekintheti meg.

A hibák a következő további funkciókat is biztosítják:

• Az egyes csapatok beállításai a hibák nyomon követésének módjának kiválasztásához
• A hibák rögzítésére szolgáló eszközök tesztelése
• Beépített integráció az Azure DevOpsban a buildekhez, kiadásokhoz és tesztekhez kapcsolódó hibák nyomon követéséhez

Feljegyzés

A hiba típusú munkaelem-típusok nem érhetők el az alapszintű folyamattal. Az alapszintű folyamat problémákként követi nyomon a hibákat, és akkor érhető el, ha új projektet hoz létre az Azure DevOps Servicesből vagy az Azure DevOps Server 2019.1 vagy újabb verzióiból.

Előfeltételek

• Hozzá kell adnia egy projekthez.
• A munkaelemek megtekintéséhez vagy módosításához rendelkeznie kell a munkaelemek megtekintésével ebben a csomópontban, és engedélyeznie kell a munkaelemek szerkesztését ebben a csomópontban. Alapértelmezés szerint a Közreműködők csoport rendelkezik ezzel az engedélykészlettel. További információ: Engedélyek és hozzáférés beállítása a munkakövetéshez.
• Ha új címkéket szeretne hozzáadni a munkaelemekhez, alapszintű hozzáféréssel vagy magasabb szintű hozzáféréssel kell rendelkeznie, és a projektszintű Új címkedefiníció létrehozása engedélyekkel kell rendelkeznie. Alapértelmezés szerint a Közreműködők csoport rendelkezik ezzel az engedélykészlettel. Még ha az engedély kifejezetten be van állítva egy érintett számára, akkor sem rendelkeznek engedéllyel új címkék hozzáadására, mivel a hozzáférési szintjükön keresztül tiltottak. További információ: Érdekelt hozzáférés – rövid referencia.
• Minden projekttag, még az Olvasók csoport tagjai is küldhetnek munkaelemeket tartalmazó e-maileket.

Tipp.

Hiba bejelentéséhez a felhasználónak legalább az Érintett hozzáféréssel és a Munkaelemek szerkesztése beállítással kell rendelkeznie ebben a csomópont-engedélyben , és engedélyeznie kell annak a területnek az elérési útját , amelyhez hozzáadja a hibát. További információ: Engedélyek és hozzáférés beállítása a munkakövetéshez

Hiba munkaelem típusa

Az alábbi képen a Scrum-folyamat hiba típusú munkaelem-típusa látható. Az Agile- és CMMI-folyamatok hiba típusú munkaelemtípusa hasonló információkat követ nyomon. Úgy lett kialakítva, hogy megjelenjen a termékhátralján a követelményekkel együtt vagy a feladattáblán a feladatokkal együtt.

Feljegyzés

A webportálon látható képek eltérhetnek a cikkben látható képektől. Ezek a különbségek a webalkalmazás frissítéseiből, az Ön vagy a rendszergazda által engedélyezett beállításokból, valamint a projekt létrehozásakor kiválasztott folyamatból erednek ( Agile, Basic, Scrum vagy CMMI). Az Alapszintű folyamat az Azure DevOps Server 2019 1. és újabb verzióival érhető el.

A hibákra jellemző mezők

A Hiba munkaelem típusa hibaspecifikus mezőket használ. A kezdeti probléma és a folyamatban lévő felfedezések rögzítéséhez használja az alábbi táblázatban leírt mezőket. A képesség-érettségi modell integrációjának (CMMI) folyamatához definiált hibára vonatkozó mezőkkel kapcsolatos információkért tekintse meg a hibák, problémák és kockázatok mezőreferenciáját. További információ az összes többi mezőről: Munkaelem mezőindexe.

---

Mező, csoport vagy lap

Használat

---

A reprodukálás lépései
(rövid név=Repro Steps)

Elegendő információ rögzítésére szolgál, hogy a csapat többi tagja teljes mértékben megértse a kódhibát. A hiba és a várt viselkedés megkeresésére vagy reprodukálására tett műveletek belefoglalása.

---

Rendszerinformációk
A buildben található

Az alkalmazandó hiba és tesztek szempontjából releváns szoftver- és rendszerkonfigurációval kapcsolatos információk. A rendszer automatikusan kitölti a Rendszeradatok és a Build mezőkben található adatokat, amikor hibát hoz létre egy teszteszközön keresztül. Ezek a mezők megadják a szoftverkörnyezettel kapcsolatos információkat, és azt, hogy hol történt a hiba. További információ: Különböző konfigurációk tesztelése.

---

Elfogadási feltételek

Adja meg azokat a feltételeket, amelyek teljesülnek a hiba bezárása előtt. A munka megkezdése előtt írja le a lehető legérthetőbben az ügyfél-elfogadási feltételeket. A teamsnek ezt a feltételt kell használnia az elfogadási tesztek alapjául, és értékelnie kell, hogy egy elem megfelelően befejeződött-e.

---

Integrálva a buildbe

Megadja annak a buildnek a nevét, amely tartalmazza a hibát javító kódot. Ezt a mezőt a hiba megoldásakor kell megadni. A helyszíni Azure DevOps esetében az összes futtatott build legördülő menüjének eléréséhez frissítheti a FIELD Buildben található és a Buildbe integrált definíciókat egy globális listára való hivatkozáshoz. A globális lista automatikusan frissül az egyes futtatott buildekkel. További információ: Az integrációs mezők összeállítása és tesztelése alapján végzett lekérdezés.
A buildszámok definiálásáról további információt a buildszámformátum beállításaiban talál.

---

1. prioritás

• 1: A termék sikeres megoldását igényli a munkaelem, mielőtt a hajó, és foglalkozni hamarosan.
• 2: A terméknek sikeres megoldásra van szüksége a munkaelemhez, de nem kell azonnal foglalkoznia.
• 3: A munkaelem feloldása nem kötelező az erőforrások, az idő és a kockázat alapján.

---

Súlyosság¹

Egy hiba vagy munkaelem projektre vagy szoftverrendszerre gyakorolt hatásának szubjektív értékelése. Például: Ha egy távoli hivatkozás a felhasználói felületen – egy ritka esemény – egy alkalmazás vagy weblap összeomlását okozza – súlyos ügyfélélményt okoz, a súlyosság = 2 – Magas és a Prioritás = 3 értéket is megadhatja. Az engedélyezett értékek és a javasolt irányelvek a következők:

• 1 – Kritikus: Ki kell javítani. Olyan hiba, amely egy vagy több rendszerösszetevő vagy a teljes rendszer leállítását okozza, vagy jelentős adatsérülést okoz. És nincsenek elfogadható alternatív módszerek a szükséges eredmények eléréséhez.
• 2 – Magas: Fontolja meg a javítást. Olyan hiba, amely egy vagy több rendszerösszetevő vagy a teljes rendszer leállítását okozza, vagy jelentős adatsérülést okoz. A szükséges eredmények eléréséhez azonban létezik elfogadható alternatív módszer.
• 3 – Közepes: (alapértelmezett) Olyan hiba, amely miatt a rendszer helytelen, hiányos vagy inkonzisztens eredményeket eredményez.
• 4 – Alacsony: Kisebb vagy kozmetikai hiba, amely elfogadható kerülő megoldásokkal rendelkezik a szükséges eredmények eléréséhez.

---

Üzembe helyezés

Az Üzembe helyezés vezérlő támogatja a munkaelemeket tartalmazó kiadásokra mutató hivatkozásokat és azok megjelenítését. A vezérlő használatához engedélyeznie kell a kiadás beállításait. További információ: Munkaelemek csatolása kiadásokhoz a cikk későbbi részében.

---

Fejlesztés

A Fejlesztési vezérlő támogatja a fejlesztési objektumokra mutató hivatkozások hivatkozásait és megjelenítését. Ezek az objektumok közé tartoznak a Git-véglegesítések és a lekéréses kérelmek, illetve a TFVC-módosítások és a verziószámozott elemek. A munkaelemből vagy a véglegesítésekből, lekéréses kérelmekből vagy más fejlesztési objektumokból is definiálhat hivatkozásokat. További információ: Munkaelemek csatolása fejlesztéshez a cikk későbbi részében.

---

Megjegyzések:

¹ A menü kiválasztásának vagy választólistájának módosításához lásd : A munkakövetési felület testreszabása. A testreszabási módszer a projekt által használt folyamatmodelltől függ.

Válassza ki, hogyan követi nyomon a csapat a hibákat

A csapat nyomon követheti a hibákat követelményekként vagy feladatként. A csapatválasztás támogatásához vegye figyelembe az alábbi tényezőket.

• A csapat mérete. A kisebb csapatok könnyű lábnyomot tudnak fenntartani a hibák követelményekként való nyomon követésével.
• A munka nyomon követésére vonatkozó szervezeti követelmények. Ha a csapatnak nyomon kell követnie az órákat, válassza a hibák nyomon követését feladatként.
• A csapat rendszerezése. Ha a csapat a termék-teendőlista alapján rangsorolja a munkát, és hibákat ad hozzá, kövesse nyomon a hibákat követelményekként.
• A csapat által használni kívánt eszközök, például a Tervezés panel, a sebességdiagram, az előrejelzés, az összesítés és a kézbesítési tervek. A hibák tevékenységekként való nyomon követése megakadályozza ezen eszközök több használatát.

Az alábbi táblázat összefoglalja a három lehetőséget, amelyeket a csapatoknak nyomon kell követniük a hibákat. További információkért és a csapat beállításának beállításához tekintse meg a hibák megjelenítése hátralékokon és táblákon című témakört.

---

Beállítás

Válassza ki, hogy mikor...

---

Hibák nyomon követése követelményekként

• A hibák rangsorolása a követelményekkel együtt
• Hibamennyiség becslése az előrejelzéshez
• Hibaállapot frissítése a Kanban táblán
• Hibák belefoglalása sebességdiagramba és halmozott folyamatábrákba
• Az Előrejelzés eszközzel támogathatja a futamtervezést
• A hibák a Tervezés panelre húzhatók a hibák sprinthez való hozzárendeléséhez
• Megtekintheti a kézbesítési csomagok hibáit

Feljegyzés

• A hibák a Követelmények kategóriához vannak rendelve

---

Hibák nyomon követése feladatokként

• Feladatokhoz hasonló hibák becsült munkája
• Hibaállapot frissítése a sprint feladattáblákon
• Hibák csatolása a követelményekhez gyermekelemként
• A hibák a Tervezés panelre húzhatók a hibák sprinthez való hozzárendeléséhez

Feljegyzés

• A hibák a tevékenységkategóriához vannak rendelve
• A Felhasználói történetek (Agile), a Termékháttúlnapló-elemek (Scrum) vagy a Követelmények (CMMI) a hibák természetes szülőmunkaelem-típusa
• A hibák nem jelennek meg a kézbesítési csomagokban

---

A hibák nem jelennek meg a hátralékokon vagy a táblákon

• Hibák kezelése lekérdezésekkel

Feljegyzés

• A hibák a hibakategóriához vannak társítva, és nem jelennek meg sem a hátralékokon, sem a táblákon
• A hibák nem jelennek meg a hátralékokon, a táblákon, a sprint-hátralékokon, a feladattáblákon vagy a kézbesítési csomagokon
• Nem húzhatók a hibák a Tervezés panelre, hogy hibákat rendelhessenek hozzá a futamokhoz

---

Munkaelem típusának testreszabása

Testre szabhatja a hiba- és egyéb munkaelem-típusokat. Vagy hozzon létre egyéni típusokat a szoftverproblémák vagy az ügyfelek visszajelzésének nyomon követéséhez. Az összes munkaelemtípus esetében testre szabhatja a következő elemeket:

• Egyéni mezők hozzáadása vagy eltávolítása
• Egyéni vezérlők vagy egyéni lapok hozzáadása a munkaelem-űrlapon
• A munkafolyamat-állapotok testreszabása
• Feltételes szabályok hozzáadása
• Válassza ki a teendőlista szintjét, amelyben a munkaelemek megjelennek

A folyamat testreszabása előtt javasoljuk, hogy tekintse át az Azure Boards konfigurálását és testreszabását.

Az adott folyamat testreszabásához tekintse meg az öröklési folyamat testreszabása című témakört.

Hibák hozzáadása vagy rögzítése

Különböző Azure DevOps-eszközök hibáit definiálhatja. Ezek közé tartoznak a hátralékok, a táblák és a tesztelési eszközök.

Tipp.

Alapértelmezés szerint a Cím mező az egyetlen kötelező mező hiba létrehozásakor. Az Azure Boards használatával gyorsan hozzáadhat hibákat ugyanúgy, mint a felhasználói történetek vagy a termékháttételeket. Ha kötelezővé szeretne tenni néhány mezőt, ezt feltételes szabályok állapotváltozáson alapuló hozzáadásával teheti meg. További információ: Szabály hozzáadása munkaelemtípushoz (Öröklési folyamat).

Hiba hozzáadása a hátralékból vagy a táblából

Ha csapata úgy döntött, hogy követelményekkel kezeli a hibákat, akkor a termékhátralékból vagy a Kanban táblából határozhatja meg a hibákat. További információ: A termékhátrelék létrehozása vagy a Kanban-tábla használatának megkezdése.

• Hiba hozzáadása a termék hátralékából

  

• Hiba hozzáadása a termék hátralékából

  

Tipp.

Ha hibát ad hozzá a termékháttérből vagy a Kanban táblából, a hiba automatikusan hozzárendeli a csapathoz definiált alapértelmezett területelérési utat és iterációs útvonalat. További információkért tekintse meg a hátralékok és táblák által hivatkozott alapértelmezett csapattagokat.

Hiba hozzáadása a sprint hátralékából vagy a Taskboardból

Ha a csapat úgy döntött, hogy feladatokkal kezeli a hibákat, definiálhat hibákat a Kanban táblából, a termékhátralékból, a Sprint hátralékból vagy a Sprint Taskboardból. Gyermekként hozzáad egy hibát egy termék-hátralék munkaelemhez.

• Csatolt gyermekhiba hozzáadása a Kanban táblából
  Ugyanúgy adhat hozzá hibát, mint egy feladatot a hátralékelemhez. További információ: Tevékenységek vagy gyermekelemek hozzáadása ellenőrzőlistaként.

  

• Csatolt gyermekhiba hozzáadása a Sprint hátralékából
  Ugyanúgy adhat hozzá hibát, mint egy feladatot a Sprint-hátralékhoz. További információ: Tevékenységek hozzáadása a hátralékelemekhez.

  

Hiba létrehozása tesztelési eszközből

A tesztelés során a hibák hozzáadására használható két tesztelési eszköz közé tartozik a tesztfuttató webes portál és a Test &visszajelzés bővítmény.

• Tesztfuttató: Manuális tesztek futtatásakor dönthet úgy, hogy hibát hoz létre. További információ: Manuális tesztek futtatása.

  

• Teszt és visszajelzés bővítmény: Feltáró tesztek futtatásakor választhatja a Hiba létrehozása vagy a Feladat létrehozása lehetőséget. További információ: Exploratory testing with the Test &feedback extension

Hiba életciklusa és munkafolyamat-állapotai

Az összes többi munkaelemtípushoz hasonlóan a Hiba munkaelem típusa is jól definiált munkafolyamattal rendelkezik. Minden munkafolyamat három vagy több államból és egy okból áll. Az okok határozzák meg, hogy az elem miért váltott át egyik állapotról a másikra. Az alábbi képek az Agile-, Scrum- és CMMI-folyamatokhoz definiált alapértelmezett hibafolyamatot szemléltetik.

Rugalmas	Scrum	CMMI

Scrum-hibák esetén az állapotot a véglegesített állapotról (az aktívhoz hasonlóan) Kész értékre kell módosítania. Az Agile és a CMMI esetében először meg kell oldania a hibát, és meg kell adnia egy okot, amely jelzi, hogy a hiba kijavítva. A hibát létrehozó személy általában ellenőrzi a javítást, és frissíti az állapotot feloldottról lezártra. Ha egy hiba megoldása vagy bezárása után több munka is található, újraaktiválhatja az állapot véglegesített vagy aktív állapotúraállításával.

Feljegyzés

Az Agilis folyamat hiba munkaelemtípusának korábban volt egy szabálya, amely hozzárendelte a hibát a létrehozó személyhez. Ez a szabály el lett távolítva az alapértelmezett rendszerfolyamatból. Ezt az automatizálást egy szabály hozzáadásával visszaállíthatja. Öröklési folyamat esetén lásd : Szabályok alkalmazása munkafolyamat-állapotokra, az állapotváltozás alapján történő újbóli hozzárendelés automatizálása.

Javítás ellenőrzése

A javítás ellenőrzéséhez egy fejlesztő vagy tesztelő megpróbálja reprodukálni a hibát, és váratlanabb viselkedést keres. Szükség esetén újraaktiválniuk kell a hibát.

Hibajavítás ellenőrzésekor előfordulhat, hogy a hiba nem lett javítva, vagy nem ért egyet a megoldással. Ebben az esetben beszélje meg a hibát azzal a személlyel, aki megoldotta, megállapodásra jut, és esetleg újraaktiválja a hibát. Ha újraaktivál egy hibát, adja meg a hiba újraaktiválásának okait a hiba leírásában.

Hiba bezárása

A hiba kijavítása után bezárhat egy hibát. Előfordulhat azonban, hogy az alábbi okok valamelyike miatt is bezár egy hibát. A választható okok a projektfolyamattól és a hibaáttűnési állapottól függenek.

Agilis folyamat:

• Halasztás: Halasztja a hibajavítást a következő termékkiadásig.
• Javítva: A hiba kijavítva lett ellenőrizve.
• Duplikált: A hiba egy másik, jelenleg definiált hibát követ nyomon. Az egyes hibákat összekapcsolhatja a hivatkozástípus duplikált/duplikált típusával , és bezárhatja az egyik hibát.
• A tervezésnek megfelelően: A funkció a tervezett módon működik.
• Nem reprodukálható: A tesztek igazolják, hogy a hiba nem reprodukálható.
• Elavult: A hiba funkciója már nem szerepel a termékben.
• Átmásolva a hátralékba: Megnyílt egy felhasználói történet a hiba nyomon követéséhez.

Scrum-folyamat:

• Nem hiba: A rendszer ellenőrzi, hogy a hiba nem hiba-e.
• Duplikált: A hiba egy másik, jelenleg definiált hibát követ nyomon. Az egyes hibákat összekapcsolhatja a hivatkozástípus duplikált/duplikált típusával , és bezárhatja az egyik hibát.
• Eltávolítva a hátralékból: A rendszer ellenőrzi, hogy a hiba nem hiba-e. Távolítsa el a hibát a hátralékból.
• A munka befejeződött: A hiba kijavítva lett ellenőrizve.

CMMI-folyamat:

• Halasztás: Halasztja a hibajavítást a következő termékkiadásig.
• Duplikált: A hiba egy másik, jelenleg definiált hibát követ nyomon. Az egyes hibákat összekapcsolhatja a hivatkozástípus duplikált/duplikált típusával , és bezárhatja az egyik hibát.
• Elutasítva: A rendszer ellenőrzi, hogy a hiba nem hiba-e.
• Igazolt: A hiba kijavítva lett ellenőrizve.

Tipp.

Miután bezártak egy hibát, és a javítás aktívan megjelent az üzemelő példányokban, ajánlott, hogy a regresszió miatt soha ne nyissa meg újra. Ehelyett érdemes lehet megnyitnia egy új hibát, és hivatkoznia kell a régebbi, lezárt hibára.

A hiba bezárásával kapcsolatos további részleteket mindig érdemes leírni a Vitamezőben , hogy elkerüljük a későbbi félreértéseket, hogy miért lett bezárva a hiba.

Hibalezárás automatizálása lekéréses kérelmek egyesítésekor

Ha a csapata Git-adattárat használ, beállíthatja az állapotot csatolt hibákban és egyéb munkaelemekben a lekéréses kérelmek sikeres egyesítésekor. További információ: A munkaelem állapotának beállítása lekéréses kérelemben a cikk későbbi részében.

Hibák listázása és osztályozása

A legtöbb csapat, bármilyen lehetőséget is választott a hibák nyomon követésére, definiáljon egy vagy több hibakeresést. A lekérdezésekkel felsorolhatja az aktív hibákat, a hozzárendeletlen hibákat, az elavult hibákat, a hibatrendeket és egyebeket. Ezután lekérdezéseket és lekérdezésdiagramokat adhat hozzá a csapat irányítópultjaihoz a hibaállapot és a haladás figyeléséhez.

Hibakeresések

Nyisson meg egy megosztott lekérdezést, vagy a lekérdezésszerkesztővel hozzon létre hasznos hibakereséseket, például a következő lehetőségeket:

• Aktív hibák prioritás (State <> Done vagy State <> Closed) szerint
• Folyamatban lévő hibák (State = Committed vagy State = Active)
• A célkiadáshoz kijavítandó hibák (Tags Contains RTM)
• Legutóbbi hibák - az elmúlt három hétben megnyitott hibák (Created Date > @Today-21)

Miután megkapta a csapat számára érdekes lekérdezéseket, állapot- vagy trenddiagramokat hozhat létre. A létrehozott diagramot egy irányítópulthoz is hozzáadhatja.

Triage mód a lekérdezési eredményekben

Miután megkezdte a kódolást és a tesztelést, rendszeres triage értekezleteket kell tartania a hibák áttekintéséhez és rangsorolásához. A projekttulajdonos általában futtatja a hibaleképezési értekezleteket. A csapatvezetők, az üzleti elemzők és más érdekelt felek, akik konkrét projektkockázatokról beszélnek, részt vesznek a triage értekezleteken.

A projekt tulajdonosa meghatározhat egy megosztott lekérdezést az új és újra megnyitott hibákhoz, hogy listázhassa az osztályozásra váró hibákat.

A lekérdezés eredményoldalán gyorsan felfelé és lefelé mozoghat a hibamunkaelemek listájában a fel- és le nyílbillentyűkkel. Az egyes hibák áttekintése során hozzárendelheti, adatokat adhat hozzá vagy prioritást állíthat be.

Hibák rendszerezése és hozzárendelése egy futamhoz

Ha a csapat követelményekként követi nyomon a hibákat, tekintse meg az aktív hibák listáját a hátralékból. A szűrőfüggvény segítségével kizárólag a hibákra összpontosíthat. A termék hátralékából a következő feladatokat is elvégezheti:

• A hibák rendszerezése a hátralékon, a verem rangsorolása más elemekhez (a verem rangsorolása le van tiltva, ha a szűrés engedélyezve van)
• Hibák hozzárendelése egy futamhoz a hátralékból a Tervezés panelen
• Szülőhibák a Szolgáltatások vagy más portfolió-teendőnapló-elemekhez a Leképezés panelen
• A feladatok összesítésének megtekintése a portfolió-hátralékelemekhez.

Ha a csapat feladatként követi nyomon a hibákat, felügyelt lekérdezésekkel listázhatja és csoportosíthatja a hibákat. Ezután minden futamon látni fogja a futamhoz rendelt hibákat a Sprint hátralékából vagy a Taskboardból.

Feladattáblaelemek és lekérdezéslistaelemek

Észreveheti és elgondolkodhat azon, hogy a sprint feladattáblán látható elemek miért különbözhetnek a megfelelő sprint-hátralékban létrehozott lekérdezéslistától.

Feladatokat vagy hibákat hozzárendelhet egy iterációhoz, de nem csatolhatja őket szülő-teendőlista-elemhez. Ezek az elemek megjelennek a létrehozott lekérdezésben, de előfordulhat, hogy nem jelennek meg a feladattáblán. A rendszer futtatja a lekérdezést, majd alkalmaz néhány háttérfolyamatot a feladattábla elemeinek megjelenítése előtt.

Ezek az okok azt okozhatják, hogy a tevékenységkategóriához tartozó munkaelemek nem jelennek meg a sprint-hátralékon vagy a feladattáblán:

• A feladat vagy hiba nem lett csatolva szülő-teendőlista-elemhez. A sprint hátralék oldalán csak a szülőtermék-hátralékelemhez (Scrum), felhasználói történethez (Agile) vagy követelményhez (CMMI) társított hibák és feladatok jelennek meg a futamhoz beállított iterációs útvonallal.
• A feladat vagy hiba egy másik tevékenység vagy hiba szülője, vagy a felhasználói történet egy másik felhasználói történet szülője. Ha tevékenységek, hibák vagy felhasználói történetek hierarchiáját hozta létre, csak a gyermekszintű tevékenységek vagy a gyermekszintű történetek jelennek meg a hierarchia alján.
• A tevékenység vagy hiba csatolt szülője egy másik csapathoz definiált hátralékelemnek felel meg. Vagy a tevékenység vagy hiba szülőnaplójának területútvonala eltér a tevékenység vagy a hiba területútvonalától.

Hibákhoz kapcsolódó beágyazott tesztek létrehozása

Ha a csapat követelményekként követi nyomon a hibákat, a Kanban táblával teszteket adhat hozzá a hibajavítások ellenőrzéséhez.

Hibaállapot frissítése

A hibaállapot frissítéséhez húzza a hibákat egy új oszlopba a táblán.

• Ha a csapat követelményekként követi nyomon a hibákat, használja a Kanban táblát az alábbi képen látható módon. További információ: Ismerkedés a Kanban-táblával.

  

• Ha a csapat feladatként követi nyomon a hibákat, használja a Feladattáblát. További információ: A feladattábla frissítése és figyelése.

  

A tábla testreszabása köztes állapotok nyomon követéséhez

Köztes oszlopokat is hozzáadhat a hiba állapotának nyomon követéséhez a táblán. Olyan lekérdezéseket is definiálhat, amelyek a táblaoszlopok állapota alapján szűrnek. További információért tekintse át az alábbi cikkeket:

• Oszlopok hozzáadása a Kanban-táblához
• Sprint taskboard testreszabása
• Kanban táblamódosítási lekérdezések

Hiba újbóli hozzárendelésének automatizálása munkafolyamat-állapot alapján

A kijelölési műveletek automatizálásához adjon hozzá egyéni szabályokat a Hiba munkaelemtípushoz. Adjon hozzá például egy szabályt az alábbi képen látható módon. Ez a szabály azt határozza meg, hogy a hiba újbóli hozzárendelése a hibát megnyitó személyhez a probléma megoldása után. Ez a személy általában ellenőrzi, hogy a hiba kijavítva lett-e, és bezárja-e a hibát. További információ: Szabályok alkalmazása munkafolyamat-állapotokra (Öröklési folyamat).

Munkaelem állapotának beállítása lekéréses kérelemben

Lekéréses kérelem létrehozásakor a leírásban megadhatja a csatolt munkaelemek állapotértékét . Kövesse a szintaxist: {state value}: #ID. A lekéréses kérelem egyesítésekor a rendszer felolvassa a leírást, és frissíti a munkaelem állapotát. Az alábbi példában a 300- és a 301-et feloldott, a 323-at és a 324-et pedig lezártnak állítjuk be.

Integráció az Azure DevOpsban

Az Azure DevOps által az integráció támogatásához használt egyik módszer az objektumok más objektumokhoz való csatolása. A munkaelemek munkaelemekhez csatolása mellett a munkaelemeket más objektumokhoz is csatolhatja. Hivatkozás objektumokra, például buildekre, kiadásokra, ágakra, véglegesítésekre és lekéréses kérelmekre az alábbi képen látható módon.

Hozzáadhat egy hivatkozást a munkaelemből vagy a buildelési és kiadási objektumokból.

Munkaelemek csatolása a fejlesztéshez

A fejlesztési vezérlő támogatja a buildekre, a Git véglegesítésére és a lekéréses kérelmekre mutató hivatkozások csatolását és megjelenítését. Vagy TFVC-adattár használata esetén támogatja a módosításkészletekre és a verziószámozott elemekre mutató hivatkozásokat. A hivatkozás kiválasztása megnyitja a megfelelő elemet egy új böngészőlapon. További információ: Drive Git development from a work item.

Munkaelemek csatolása kiadásokhoz

Az Üzembe helyezés vezérlő támogatja a munkaelemeket tartalmazó kiadásokra mutató hivatkozásokat és azok megjelenítését. Az alábbi képen például több olyan kiadás látható, amelyek az aktuális munkaelemre mutató hivatkozásokat tartalmaznak. Az egyes kiadások kibontásával megtekintheti az egyes fázisok részleteit. Az egyes kiadások és fázisok hivatkozását választva megnyithatja a megfelelő kiadást vagy szakaszt. További információ: Munkaelemek csatolása az üzemelő példányokhoz.

Munkaelemek csatolása folyamatfuttatáshoz

A folyamatok gyakran úgy vannak definiálva, hogy automatikusan fussanak, amikor új véglegesítés történik egy Git-adattárban. A véglegesítési folyamatokhoz társított munkaelemek a folyamatfuttatás részeként jelennek meg, ha testre szabja a folyamat beállításait. További információ: A folyamat testreszabása.

Munkaelem létrehozása vagy szerkesztése buildelési hiba esetén

Ha klasszikus folyamatokat használ (nem YAML-et), létrehozhat munkaelemeket buildelési hibák esetén. További információ: Buildbeállítások, Munkaelem létrehozása hiba esetén.

Hibaállapot, hozzárendelések és trendek monitorozása

A hibaállapotokat, a hozzárendeléseket és a trendeket olyan lekérdezésekkel követheti nyomon, amelyeket aztán diagramra állíthat, és felvehet egy irányítópultra. Az alábbi két példa például az aktív hibatrendeket mutatja be állapot és aktív hibák prioritás szerint az idő függvényében.

További információ a lekérdezésekről, diagramokról és irányítópultokról; lásd: Felügyelt lekérdezések , diagramok és irányítópultok.

Hibajelentések létrehozása az Analytics-nézetek és az Analytics szolgáltatás használatával

Az Analytics szolgáltatás az Azure DevOps jelentéskészítési platformja, amely az előző platformot váltja fel az SQL Server Reporting Services alapján.

Az elemzési nézetek előre összeállított szűrőket biztosítanak a munkaelemek megtekintéséhez. A hibajelentéshez négy elemzési nézet támogatott. Ezeket a nézeteket definiált módon használhatja, vagy további szerkesztéssel egyéni, szűrt nézetet hozhat létre.

• Hibák – Minden előzmény hónap szerint
• Hibák - Az elmúlt 26 hétben
• Hibák – Az elmúlt 30 napban
• Hibák – Ma

Az elemzési nézetek használatáról további információt a What are Analytics views and Create a active bugs report in Power BI based on a custom Analytics view. (Az elemzési nézetek és az aktív hibák jelentésének létrehozása a Power BI-ban egyéni Elemzési nézet alapján) című témakörben talál.

A Power BI használatával összetettebb jelentéseket hozhat létre, mint amennyit egy lekérdezésből kaphat. További információ: Csatlakozás a Power BI Data Csatlakozás or használatával.

Marketplace-bővítmények

Több hibaalapú Marketplace-bővítmény is létezik. Tekintse meg az Azure DevOps piacterét.

A bővítményekről további információt a Microsoft által kifejlesztett Azure Boards-bővítményekben talál.

Következő lépések

Munkaelemek hozzáadása és frissítése sablonok használatával

Kapcsolódó cikkek

• Munkaelemek áthelyezése, módosítása vagy törlése
• Munkaelem másolása vagy klónozása

Termékháttúllépés és Kanban-tábla

• Hátralékok, portfóliók és Agilis projektkezelés
• A hátralék létrehozása
• Funkciók és eposzok definiálása
• A hátralék rendszerezése, a gyermekmunkaelemek leképezése a szülőknek
• Hátralékok, táblák, lekérdezések és tervek interaktív szűrése
• A termék hátralékának előrejelzése

Kanban tábla

• Tudnivalók a Táblákról és a Kanbanról
• Kanban board – rövid útmutató
• Kártyák átrendezés
• Tevékenységek vagy gyermekelemek hozzáadása ellenőrzőlistaként

Sprint hátralék és feladattábla

• A scrum és a futamok használatának ajánlott eljárásai
• Hátralékelemek hozzárendelése futamhoz
• Tevékenységek hozzáadása
• A feladattábla frissítése

Integráció az Azure DevOpsban

• Felhasználói történetek, problémák, hibák és egyéb munkaelemek összekapcsolása
• Munkaelem vagy lekéréses kérelem követése
• Futtatási vagy buildelési számok konfigurálása

Iparági erőforrások

• Jó és rossz technikai adósság (és hogyan TDD segít) Henrik Kniberg
• A Technikai adósság kezelése által közzétett Sven Johann &Eberhard Wolff