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? Hogyan lehet jó előrehaladást 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 az Agile-eljárásoknak 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 szokásos funkciók áttekintését a Munkahelyi elemek és a munkaelemtípusok című témakörben tekintheti meg.

A hibák a következő 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

• Projekthozzáférés: Hozzá kell adni egy projekthez.

• Engedélyek:

  • A csomópont munkaelemeinek megtekintése és a munkaelemek szerkesztése ezen csomópont engedélyeinek engedélyezése beállítással. Alapértelmezés szerint a Közreműködők csoport rendelkezik ezekkel az engedélyekkel. További információ: A munkakövetési engedélyek beállítása.

  • Ha új címkéket szeretne hozzáadni a munkaelemekhez, rendelkeznie kell alapszintű hozzáféréssel vagy magasabb szintű hozzáféréssel, és a projektszintű Új címkedefiníció létrehozása engedély beállítása Engedélyezés értékre. Alapértelmezés szerint a Közreműködők csoport rendelkezik ezzel az engedéllyel.

    Feljegyzés

    Az érdekelt felek a hozzáférési szint miatt akkor sem adhatnak hozzá új címkéket, ha az engedély kifejezetten be van állítva. További információ: Érdekelt hozzáférés – rövid referencia.

• E-mail munkaelemek: Minden projekttag, beleértve az Olvasók csoportot is, küldhet munkahelyi elemeket tartalmazó e-maileket.

Tipp.

Hiba bejelentéséhez a felhasználónak legalább az érdekelt felek hozzáféréssel kell rendelkeznie. A felhasználónak rendelkeznie kell szerkesztési munkaelemekkel ebben a csomóponti engedélyben, és engedélyeznie kell annak a területnek az elérési útját , ahol hozzáadja a hibát. További információ: A munkakövetési engedélyek beállítása

Hiba munkaelem típusa

Az alábbi képen a Scrum-folyamat hiba típusú munkaelem-típusa látható. Az Agile és a Capability Maturity Model Integration (CMMI) hiba munkaelemtípusa hasonló adatokat követ nyomon. Megjelenik a termék hátralékában a követelményekkel együtt, vagy a feladattáblán a tevékenységekkel 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ésébő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: Agilis, Alapszintű, 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.

---

A buildben található rendszerinformációk

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 kritériumot 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 klasszikus folyamatok konfigurációja című témakörben 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 belül (ritka esemény) egy alkalmazás vagy weblap összeomlását okozza (súlyos ügyfélélmény), megadhatja a Súlyosság = 2 – Magas és a Prioritás = 3 értéket. 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. A szükséges eredmények eléréséhez nincs elfogadható alternatív módszer.
• 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 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.

---

Jegyzetek

¹ 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 munkájának szervezé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 vagy rangsorolása a követelményekkel együtt
• Hibamennyiség becslése az előrejelzéshez
• Hibaállapot frissítése a fedélzeten
• 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úzásával rendelhetők hozzá hibák egy futamhoz
• A kézbesítési csomagok hibáinak megtekintése

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úzásával rendelhetők hozzá hibák egy futamhoz

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 láthatók 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 Hibák kategóriához vannak társítva, és nem jelennek meg sem a hátralékokon, sem a táblákon
• A hibák nem láthatók 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úzhatja a hibákat a Tervezés panelre, ha hibákat szeretne hozzárendelni egy futamhoz

---

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áról és testreszabásáról szóló cikket.

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 az eszközök 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ő, amikor hibát hoz létre. Az Azure Boards használatával ugyanúgy adhat hozzá hibákat, ahogyan felhasználói történeteket vagy termékháttételeket. Bizonyos mezőket feltételes szabályok állapotváltozáson alapuló hozzáadásával lehet kötelezővé tenni. További információ: Szabály hozzáadása munkaelemtípushoz.

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

Ha a csapat úgy döntött, hogy követelményekkel kezeli a hibákat, a termékhátraljából vagy a táblából is meghatározhatja a hibákat. További információ: Termékháttúlnapló létrehozása vagy A tábla használata.

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

  

• Hiba hozzáadása a táblából

  

Tipp.

Ha hibát ad hozzá a termékháttérből vagy a táblából, a hiba automatikusan hozzárendeli a csapathoz definiált alapértelmezett területelérési útvonalat é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, meghatározhatja a hibákat a táblából, a termék-há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 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.

  

• Csatolt gyermekhiba hozzáadása a 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.

  

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ó: Feltáró tesztelés a Test & Feedback kiterjesztéssel.

  

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 munkát talál, az állapot véglegesített vagy aktív állapotra állításával aktiválja újra.

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 az állapotváltozás alapján történő újbóli hozzárendelés automatizálása című témakört.

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

Bezárhat egy hibát, ha egy csapattag kijavítottként ellenőrzi. Előfordulhat azonban, hogy az alábbi okok valamelyike miatt is bezár egy hibát. Az elérhető okok a projektfolyamattól és a hibaáttűnés állapotától függnek.

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. Lekérdezéseket és lekérdezési diagramokat 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, például az elmúlt három hétben megnyitott hibák (Created Date > @Today-21)

Ha rendelkezik a csapat számára érdekes lekérdezésekkel, á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 tart 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 felfelé és lefelé mozoghat a hibamunkaelemek listájában a felfelé és lefelé mutató nyilakkal. 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. Rangsorolás 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 leképezése szolgáltatásokra vagy egyéb portfolió-teendőnapló-elemekre 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. Minden futamban megjelennek a futamhoz rendelt hibák 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 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 nincs szülő-teendőlista-elemhez csatolva. A sprint hátralék oldalán csak a hibák és a feladatok vannak társítva egy szülőtermék-hátralékelemhez (Scrum), felhasználói történethez (Agile) vagy követelményhez (CMMI), amelynek iterációs útvonala a sprintre van beállítva.
• 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 feladatok, hibák vagy felhasználói történetek hierarchiáját hozza létre, csak a gyermekszintű feladatok vagy a gyermekszintű történetek jelennek meg a hierarchia alján. További információ: Az átrendezéssel és a beágyazással kapcsolatos problémák elhárítása.
• 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 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 táblát az alábbi képen látható módon. További információ: Munkaelem állapotának frissítése.

  

• 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 táblához
• Sprint taskboard testreszabása
• Tábla változásainak lekérdezése

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 annak a személynek legyen, aki megnyitotta a hibát, amikor egy csapattag feloldja azt. 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élda a #300 és a 301 munkaelemet feloldott, a 323- és a 324-et pedig lezártra állítja.

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ésekre és a lekéréses kérelmekre mutató hivatkozások csatolását és megjelenítését. 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ó: Munkaelem létrehozása hiba esetén.

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

A hibaállapot, a hozzárendelések és a trendek nyomon követhetők olyan lekérdezések használatával, amelyeket diagramokkal és irányítópultokhoz adhat hozzá. 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.

A lekérdezésekkel, diagramokkal és irányítópultokkal kapcsolatos további információkért lásd a felügyelt lekérdezéseket, diagramokat és irányítópultokat.

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ési platformja. Az SQL Server Reporting Services alapján lecseréli az előző platformot.

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

További információ az elemzési nézetek használatáról: About Analytics views and Create a active bugs report in Power BI based a custom Analytics view.

A Power BI használatával összetettebb jelentéseket hozhat létre, mint egy lekérdezés. További információ: Csatlakozás a Power BI-adatösszekötővel.

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 eltávolítása, törlése vagy visszaállítása
• Munkaelem másolása vagy klónozása

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

• Projektek kezelése hátralékokkal
• A hátralék létrehozása
• Funkciók és eposzok definiálása
• A hátralék rendszerezése és a gyermekmunkaelemek hozzárendelése a szülőkhöz
• 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

Beszáll

• Tudnivalók a Táblákról és a Kanbanról
• A tábla használata
• Kártyák átrendezés
• Tevékenységek vagy gyermekelemek hozzáadása ellenőrzőlistaként

Sprint hátralék és feladattábla

• Tudnivalók a Scrum ajánlott eljárásairól
• 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