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

Kategória	Követelmények
engedélyek	- Munkaelemek megtekintése, követése és szerkesztése: Munkaelemek megtekintése ezen a csomóponton és A csomópont munkaelemeinek szerkesztése engedélyeknél Engedélyezés. 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. - Címkék hozzáadása munkaelemekhez: Projektszintű Új címkedefiníció létrehozása engedélykészlet beállítva Engedélyezés. Alapértelmezés szerint a Közreműködők csoport rendelkezik ezzel az engedéllyel.
hozzáférési szintek	- projekttag. – Új címkék hozzáadása munkaelemekhez, illetve lekéréses kérelmek megtekintése vagy követése: Legalább Egyszerű hozzáférés. - Munkaelemek megtekintéséhez vagy követéséhez szükséges: Legalább Érdekelt hozzáférés. További információ: A hozzáférési szintek ismertetése. - Minden projekttag, beleértve a Olvasók csoportban lévőket is, küldhet munkahelyi elemeket tartalmazó e-maileket.

Feljegyzés

• Hozzáférést biztosít az érdekelt feleknek azokhoz a tagokhoz, akik hozzá szeretnének járulni a vitához és áttekinteni az előrehaladást. Ezek általában olyan tagok, akik nem járulnak hozzá a kódhoz, de meg szeretnék tekinteni a munkaelemeket, a hátralékokat, a táblákat és az irányítópultokat.
• A nyilvános projektekben alapértelmezés szerint az közreműködők és az érintettek új és meglévő címkéket adhatnak meg. Magánprojektekben az érdekelt felek csak meglévő címkéket adhatnak hozzá. Az új címkék létrehozásának szabályozásához állítsa be a Címkedefiníció létrehozása engedélyt a projekt szintjén. További információ: Projektszintű engedélyek módosítása.

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 azzal a „Munkaelemek szerkesztése ebben a csomópontban” jogosultsággal, amely engedélyezve van, azon a területi elérési útvonalon, ahol a hibát hozzáadják. 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) folyamatok hibaügyi munkaelem tí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. Amikor hibát hoz létre egy teszteszközön keresztül, a Rendszeradatok és a Létrehozási azonosító mezők automatikusan kitöltődnek. 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 csapatoknak ezt a kritériumot kell használniuk az elfogadási tesztek alapjául, és értékelniük kell, hogy egy elem kielégítően befejeződött-e.

---

Integrálva a fordításba

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 a futtatott buildek legördülő menüjének eléréséhez frissítheti a FIELDBuildben található és a Buildbe integrált definíciókat úgy, hogy egy globális listára hivatkozzon. 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 megköveteli a munkaelem sikeres megoldását, mielőtt elindul, és hamarosan kezelni kell.
• 2: A termék megköveteli a munkaelem sikeres rendezését, mielőtt kiszállítják, de nem szükséges azonnal foglalkozni vele.
• 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ó módon megkerülhető a szükséges eredmények elérésére.

---

Ü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-commit-ek és a pull request-ek, 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 kisebb erőforráshasználattal működhetnek, ha a hibákat követelményszintűként kezelik.
• 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á, a hibákat tekintse követelményeknek és kövesse nyomon azokat ennek megfelelően.
• 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, amely a csapatok számára rendelkezésre áll a hibák nyomon követésére. További információkért és a csapat opcióinak beállításához tekintse meg a hibák hátralékon és táblákon való megjelenítéséről szóló témakört.

---

Beállítás

Válassza ki, hogy mikor...

---

Hibák nyomon követése a követelmények alapján

• A hibák priorizálása vagy sorba állítása a követelményekkel együtt
• A hibajavítási erőfeszítés becslése az előrejelzéshez
• Hibaállapot frissítése a fedélzeten
• Hibák belefoglalása a sebességdiagramokba és a halmozott folyamatábrákba
• Legyen képes az Előrejelzés eszközt használni a futamtervezés támogatására.
• A hibák a Tervezés panelre húzásával rendelhetők hozzá hibák egy futamhoz
• A Kiszállítási tervek 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

• Becsülje meg a hibák elvégzéséhez szükséges munkát a feladatokhoz hasonlóan.
• Hibaállapot frissítése a sprint feladattáblákon
• Hibák kapcsolása a követelményekhez alárendelt elemként
• Húzza a hibákat a Tervezés panelre, hogy hozzá lehessen rendelni őket egy sprinthez.

Feljegyzés

• A hibák a feladatkategó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 szállítási tervekben

---

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

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

Megjegyzé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, táblákon, sprint-hátralékokon, feladattáblákon vagy szállítási terveken.
• 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á hibabejegyzéseket, ahogyan felhasználói történeteket vagy termék-visszalépési té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óért lásd: Termékvárólista létrehozása vagy A tábla használata.

• Adjon hozzá egy hibát a termék hátralékából

  

• Hiba hozzáadása a táblához

  

Tipp.

Ha hibát ad hozzá a termék-várólistáról vagy tábláról, a hiba automatikusan hozzárendelésre kerül a csapat számára definiált alapértelmezett területútvonalhoz és iterációs útvonalhoz. További információkért tekintse meg a hátralékok és táblák által hivatkozott csapat alapértelmezéseket.

Hibát adjon hozzá a sprint hátralékához vagy a feladatkezelő táblábó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.

• Kapcsolt al-hiba hozzáadása a Sprint Backlogból

  Ugyanúgy adhat hozzá hibát, mint ahogy feladatot ad egy Sprint-feladatlistához. További információ: Tevékenységek hozzáadása a hátralékelemekhez.

  

• Kapcsolt gyermekhiba hozzáadása a táblán

  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 állapotbó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 Állapot-ot Elkötelezett értékről (az Aktív-hoz 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, állítsa az Állapot-ot Véglegesített vagy Aktív értékre az aktiválás érdekében.

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 Duplikátum/Duplikátuma hivatkozástípussal, és lezá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 Duplikált/Duplikált másolata hivatkozástípussal, és lezá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 kiadásra került a telepítések során, ajánlott, hogy a visszaesés elkerülése érdekében soha ne nyissák azt meg újra. Ehelyett javasolt, hogy nyisson meg egy új hibát, és hivatkozzon 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.

Hibák lezárásának automatizálása pull kérések összevonásakor

Ha a csapata Git-tárházat használ, beállíthatja a csatolt hibák és egyéb munkaelemek állapotát, hogy automatikusan záródjanak 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.

Lekérdezési eredmények osztályozási módja

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ényként követi nyomon a hibákat, nézd 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átralistán. Rangsorolás más elemekkel szemben. A rangsorolás tiltva van, ha a szűrés engedélyezve van.
• Hibák hozzárendelése egy sprinthez a visszamaradt feladatok közül a Tervezés panelen.
• Szülőhibák leképezése funkciókra vagy egyéb portfólió-backlog-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 sprintben megjelennek a sprinthez 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 feladat vagy a hiba szülői naplóelemének területútvonala eltér a feladat 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 előírja, hogy a hibát arra a személyre kell visszairányítani, aki megnyitotta azt, amikor egy csapattag megoldja. 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-as és a #301-es munkaelemet megoldottra, a #323-ast és a #324-est 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, commit-ekre és pull requestekre 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ó: Git-fejlesztés elősegítése egy munkaelemből.

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 üzembe helyezésekhez.

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 kimutatásokba foglalhatók és irányítópulthoz adhatók. 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 analitikai nézetek használatáról, lásd: About Analytics views és Aktív hibajelentés készítése a Power BI-ben egy egyedi analitikai nézet alapján.

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ékkövetelménylista és feladat tábla

• Projektek kezelése feladatlisták segítségével
• 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

Testület

• Tudnivalók a Táblákról és a Kanbanról
• Használd a tábládat
• Kártyák átrendezése
• 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 pull request 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
• Technikai adósság kezelése közzétette: Sven Johann & Eberhard Wolff