CMMI-proceswerkitemtypen en werkstroom in Azure Boards
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Teams gebruiken de werkitemtypen (WIT's) die zijn geleverd met het CMMI-proces voor CMMI-procesverbetering (CMMI) om de voortgang van softwareprojecten te plannen en bij te houden. Teams definiëren vereisten voor het beheren van de achterstand van het werk en volgen vervolgens de voortgang door de status van de vereisten bij te werken.
Om inzicht te krijgen in een portfolio met vereisten, kunnen producteigenaren vereisten toewijzen aan functies. Wanneer teams in iteraties werken, definiëren ze taken die automatisch worden gekoppeld aan vereisten.
Met Behulp van Microsoft Test Manager en de webportal maken testers testcases en voeren ze fouten uit om codefouten bij te houden.
Om andere CMMI-processen te ondersteunen, kunnen teams wijzigingsaanvragen, risico's, problemen en notities bijhouden die zijn vastgelegd in controlevergaderingen. Als u geen kennis hebt met het CMMI-proces, bekijkt u het sectieplan en houdt u het werk bij met CMMI om aan de slag te gaan.
Vereisten definiëren
Vereisten maken op basis van het deelvenster Snel toevoegen op de pagina achterstall van het product. Later kunt u elke vereiste openen om meer details te geven en de grootte ervan te schatten.
U kunt ook bulksgewijs vereisten toevoegen met behulp van een cvs-bestand.
U kunt ook bulksgewijs vereisten toevoegen met Excel of Project.
Belangrijk
Microsoft Project Integration en de TFSFieldMapping opdracht worden niet ondersteund voor:
- Visual Studio 2019 en Azure DevOps Office Integration 2019.
- Azure DevOps Server 2019 en latere versies, waaronder Azure DevOps Services.
Volledige ondersteuning voor Microsoft Excel-integratie wordt gehandhaafd, waardoor werkitems bulksgewijs kunnen worden geïmporteerd en bijgewerkt. Alternatieven voor het gebruik van Microsoft Project zijn:
- Leveringsplannen
- Marketplace-extensies zoals Project Connect - of GANTT-diagram
Vereisten geven de functies en productelementen op die teams moeten maken. Producteigenaren definiëren en stapelen doorgaans vereisten voor rangschikking op de pagina met productachterstanden. Het team bereikt vervolgens de grootte van de inspanning om de items met de hoogste prioriteit te leveren.
Gebruik de volgende richtlijnen en velden die worden gebruikt voor algemene typen werkitems bij het invullen van het formulier. Zie Een project plannen voor meer informatie.
Veld
Gebruik
Geef voldoende details op voor het schatten van de hoeveelheid werk die nodig is om de vereiste te implementeren. Richt u op wie de vereiste is, wat gebruikers willen bereiken en waarom. Beschrijf niet hoe de vereiste moet worden ontwikkeld. Geef voldoende details op, zodat uw team taken en testcases kan schrijven om het item te implementeren.
In HTML-velden kunt u tekst met opmaak en afbeeldingen toevoegen.
De impact van de klant op het niet implementeren van deze vereiste. U kunt details van het Kano-model opnemen over of deze vereiste zich in de verrassings-, vereiste of voor de hand liggende categorieën bevindt. U legt deze informatie vast in het HTML-veld met opmaak dat overeenkomt met de impactbeoordeling.
Vereistetype (vereist)
Het soort vereiste om te implementeren. U kunt een van de volgende waarden opgeven:
- Bedrijfsdoelstelling
- Functie (standaard)
- Functioneel
- Interface
- Operationeel
- Quality of Service
- Veiligheid
- Scenario
- Beveiliging
Het gebied van de klantwaarde dat wordt aangepakt door het epische, functie, vereiste of achterstandsitem. Tot de waarden behoren:
- Architectuur: Technische services voor het implementeren van bedrijfsfuncties die een oplossing leveren
- Bedrijf: Services die voldoen aan de behoeften van klanten of belanghebbenden die rechtstreeks klantwaarde leveren ter ondersteuning van het bedrijf (standaard)
Maak een schatting van de hoeveelheid werk die nodig is om een vereiste te voltooien met behulp van een numerieke maateenheid die uw team de voorkeur geeft. Door de grootte voor vereisten te definiëren, kunnen teams de Agile-snelheidsdiagrammen en prognosehulpmiddelen gebruiken om toekomstige iteraties of werkinspanningen te schatten. Het cumulatieve stroomdiagram verwijst naar de waarden in dit veld. Zie het witboek Schatten voor meer informatie.
De hoeveelheid geschatte hoeveelheid werk die nodig is om een taak te voltooien. Dit veld wordt doorgaans niet gewijzigd nadat het is toegewezen.
U kunt werk opgeven in uren of in dagen. Er zijn geen inherente tijdseenheden gekoppeld aan dit veld.
De doeldatums voor wanneer het werk begint of eindigt.
Prioriteit (vereist)
Een subjectieve beoordeling van de vereiste die betrekking heeft op het bedrijf. Toegestane waarden zijn:
- 1: Product kan niet worden verzonden zonder het item.
- 2: (standaard) Product kan niet worden verzonden zonder het item, maar het hoeft niet onmiddellijk te worden geadresseerd.
- 3: Implementatie van het item is optioneel op basis van resources, tijd en risico.
Triage (vereist)
Geeft het type sorteerbeslissing aan dat in behandeling is voor het werkitem. Gebruik dit veld wanneer het werkitem de status Voorgesteld heeft en geef een van de volgende waarden op: In behandeling (standaard), Meer informatie, Ontvangen info en Triaged.
Hiermee wordt aangegeven of een teamlid geen voortgang kan maken bij het implementeren van een vereiste of taak of het oplossen van een bug, wijzigingsaanvraag of risico. Als er een probleem is geopend om een blokkeringsprobleem bij te houden, kunt u een koppeling naar het probleem maken. U kunt Ja van Nee opgeven.
Vastgelegd (vereist)
Geeft aan of de vereiste al dan niet is vastgelegd in het project. U kunt Ja of Nee opgeven (standaard).
Productbuildnummer met de vereiste, wijzigingsaanvraag of oplossing van een bug.
Acceptatietest voor gebruikers (vereist)
De status van de acceptatietest van de gebruiker voor een vereiste. U kunt een van de volgende waarden opgeven:
- Inhalen
- Mislukken
- Niet gereed (standaard)
- Gereed
- Overgeslagen
- Ontvangen informatie
U geeft Not Ready op wanneer de vereiste de actieve status heeft en u geeft Gereed op wanneer de vereiste de status Opgelost heeft.
De namen van teamleden die bekend zijn met het klantgebied dat deze vereiste vertegenwoordigt.
Opmerkingen vastleggen in de sectie Discussie
Gebruik de sectie Discussie om opmerkingen toe te voegen en te bekijken over het uitgevoerde werk.
De werkbalk rtf-editor wordt weergegeven onder het tekstinvoergebied wanneer u de cursor in een tekstvak plaatst dat ondersteuning biedt voor tekstopmaak.
Notitie
Er bestaat geen veld discussiewerkitem. Als u een query wilt uitvoeren op werkitems met opmerkingen uit het discussiegebied, filtert u op het veld Geschiedenis. De volledige inhoud van de tekst die in het tekstvak Discussie is ingevoerd, wordt toegevoegd aan het veld Geschiedenis.
Iemand, een groep, werkitem of pull-aanvraag vermelden
Selecteer een van de volgende pictogrammen om een menu met recente vermeldingen te openen waarin u iemand hebt genoemd, gekoppeld aan een werkitem of gekoppeld aan een pull-aanvraag. U kunt ook hetzelfde menu openen door @, #of !.
Voer een naam of nummer in om de menulijst te filteren die overeenkomt met uw invoer. Selecteer de vermelding die u wilt toevoegen. Als u een groep in de discussie wilt brengen, voert u @ de naam van de groep in, zoals een team of beveiligingsgroep.
Een opmerking bewerken of verwijderen
Als u een van uw discussieopmerkingen wilt bewerken of verwijderen, kiest u 
Bewerken of kiest u het 
pictogram Acties en kiest u Vervolgens Verwijderen.
Notitie
Voor het bewerken en verwijderen van opmerkingen is versie 1 of hoger van Azure DevOps Server 2019 Update 1 of hoger vereist.
Nadat u de opmerking hebt bijgewerkt, selecteert u Bijwerken. Als u de opmerking wilt verwijderen, bevestigt u dat u deze wilt verwijderen. Een volledig audittrail van alle bewerkte en verwijderde opmerkingen wordt bijgehouden op het tabblad Geschiedenis op het werkitemformulier.
Belangrijk
Configureer voor on-premises Azure DevOps Server een SMTP-server voor teamleden om meldingen te ontvangen.
Een reactie toevoegen aan een opmerking
Voeg een of meer reacties toe aan een opmerking door in de rechterbovenhoek van een opmerking een lachebekje te kiezen. U kunt ook kiezen uit de pictogrammen onder aan een opmerking naast eventuele bestaande reacties. Als u uw reactie wilt verwijderen, kiest u de reactie onderaan uw opmerking. In de volgende afbeelding ziet u een voorbeeld van de ervaring van het toevoegen van een reactie en de weergave van reacties op een opmerking.
Een opmerking opslaan zonder het werkitem op te slaan
Notitie
Deze functie is beschikbaar vanaf Azure DevOps Server 2022.1.
Als u alleen machtigingen hebt om toe te voegen aan de discussie van een werkitem, kunt u dit doen door opmerkingen op te slaan. Deze machtiging wordt beheerd door gebiedspadknooppunten en de opmerkingen over werkitems bewerken in deze knooppuntmachtiging . Zie Machtigingen voor het bijhouden van werk instellen, onderliggende knooppunten maken, werkitems wijzigen onder een gebied of iteratiepad voor meer informatie.
Nadat u de opmerkingen hebt opgeslagen, hoeft u het werkitem niet op te slaan.
Notitie
Wanneer u wijzigingen opslaat die zijn aangebracht in het besturingselement Discussie , wordt alleen de opmerking opgeslagen. Er worden geen werkitemregels gedefinieerd voor het type werkitem uitgevoerd.
Werkvoortgang bijhouden
Naarmate het werk vordert, wijzigt u het veld Status om de status bij te werken. U kunt desgewenst een reden opgeven. De status- en redenvelden worden weergegeven in het werkitemformulier in het koptekstgebied.
CMMI-werkstroomstatussen
Deze diagrammen tonen de belangrijkste voortgang en regressiestatussen voor de WIT's vereiste, bug en taak.
| Vereiste | Bug | Opdracht |
|---|---|---|
 |
 |
 |
De typische werkstroomvoortgang voor een vereiste is:
- De producteigenaar maakt een vereiste in de status Voorgesteld met de standaardreden, Nieuwe vereiste.
- De producteigenaar werkt de status bij naar Actief wanneer deze begint te implementeren.
- Het team werkt de status bij naar Opgelost wanneer codeontwikkeling is voltooid en systeemtests zijn geslaagd.
- Ten slotte verplaatst het team of de producteigenaar de vereiste naar Gesloten wanneer de producteigenaar ermee akkoord gaat dat het is geïmplementeerd volgens de acceptatiecriteria en alle validatietests heeft doorstaan.
Werkstatus bijwerken met een bord of taskboards
Teams kan het bord gebruiken om de status van vereisten bij te werken en het sprint taskboard om de status van taken bij te werken. Als u items naar een nieuwe statuskolom sleept, worden zowel de velden Status als Reden bijgewerkt.
U kunt het bord aanpassen om meer zwembanen of -kolommen te ondersteunen.
Vereisten toewijzen aan functies
Wanneer u een suite met producten of gebruikerservaringen beheert, kunt u het bereik en de voortgang van het werk in het productportfolio bekijken. U kunt het bereik weergeven door functies en toewijzingsvereisten voor functies te definiëren.
Met behulp van portfolioachterstanden kunt u inzoomen van de ene backlog naar de andere om het gewenste detailniveau weer te geven. U kunt ook portfolioachterstanden gebruiken om een samenvouwen van werk in uitvoering voor verschillende teams weer te geven wanneer u een hiërarchie van teams instelt.
Het functiewerkitem bevat vergelijkbare velden die zijn opgegeven voor vereisten en bevat andere velden, zoals in de volgende tabel wordt beschreven.
Taken definiëren
Wanneer uw team hun werk in sprints beheert, kunnen ze de pagina sprintachterstand gebruiken om het werk op te splitsen dat in afzonderlijke taken moet worden uitgevoerd.
Geef de taak een naam en schat het werk dat nodig is.
Wanneer teams werk schatten, definiëren ze taken en schatten ze de uren of dagen om taken te voltooien. Teams voorspellen werk en definiëren taken aan het begin van een iteratie en elk teamlid voert een subset van deze taken uit. Taken kunnen betrekking hebben op ontwikkeling, testen en andere soorten werk. Een ontwikkelaar kan bijvoorbeeld taken definiëren om vereisten te implementeren en een tester kan taken definiëren voor het schrijven en uitvoeren van testcases. Door taken te koppelen aan vereisten en bugs, zien ze de voortgang van deze items. Zie Iteratieactiviteiten voor meer informatie.
Veld
Gebruik
Selecteer het type taak dat u wilt implementeren vanuit de toegestane waarden:
Corrigerende actie
Beperkingsactie
Planmatig
Selecteer de discipline die deze taak aangeeft wanneer uw team de sprintcapaciteit per activiteit schat.
Analyse
Ontwikkeling
Testen
Gebruikersonderwijs
Gebruikerservaring
Dit veld wordt ook gebruikt om de capaciteit per discipline te berekenen. Deze is toegewezen type="Activity" aan het ProcessConfiguration-bestand. (2)
Zie Ontwikkelingstaken implementeren voor meer informatie.
De hoeveelheid geschatte hoeveelheid werk die nodig is om een taak te voltooien. Dit veld wordt doorgaans niet gewijzigd nadat het is toegewezen.
De hoeveelheid werk die resteren om een taak te voltooien. Werk dit veld bij naarmate het werk vordert. Het wordt gebruikt om capaciteitsdiagrammen, de burndowngrafiek voor sprints en het rapport Sprint Burndown te berekenen. Als u een taak onderverdeelt in subtaken, geeft u alleen uren op voor de subtaken. U kunt werk opgeven in elke maateenheid die uw team kiest.
De hoeveelheid werk die is besteed aan het implementeren van een taak.
Voortgang van test bijhouden
Testvereisten
Vanuit de webportal of Testbeheer kunt u testcases maken die automatisch een koppeling maken naar een vereiste of fout. U kunt ook een vereiste aan een testcase koppelen via het 
tabblad Koppelingen.
De testcase bevat veel velden, waarvan veel geautomatiseerd en geïntegreerd zijn met Test Manager en het buildproces. Zie Query op basis van build- en testintegratievelden voor een beschrijving van elk veld.
Het tabblad (koppelingen) bevat alle vereisten en bugs in een testcase. Door koppeling te gebruiken, kan het team de voortgang bijhouden die is gemaakt bij het testen van elk item en ondersteuning bieden voor informatie die wordt weergegeven in het rapport Overzicht van vereisten .
Codefouten bijhouden
U kunt bugs maken vanuit de webportalwebportal, Visual Studio of bij het testen met Test Manager.
Wijzigingsaanvragen, risico's, problemen en notities bijhouden die zijn vastgelegd in controlevergaderingen
Samen met de vereiste, functie, taak en bug-WIT's kunt u informatie bijhouden die wordt aanbevolen door het CMMI-proces met de volgende WITS.
- Wijzigingsaanvraag voor het beheren van voorgestelde wijzigingen in elk werkproduct dat onder wijzigingsbeheer valt.
- Probleem bijhouden van een gebeurtenis of situatie die werk kan blokkeren of het werk op het product blokkeert. Problemen verschillen van de risico's in die teams spontaan identificeren, meestal tijdens dagelijkse teamvergaderingen.
- Risico om de waarschijnlijkheid en mate van variantie tussen werkelijke en gewenste resultaten bij te houden. Wanneer u risico's beheert, minimaliseert u de variantie tussen het gewenste resultaat en het werkelijke resultaat.
- Bekijk om de resultaten van een ontwerp of codebeoordeling te documenteren. Teamleden kunnen de details vastleggen van hoe het ontwerp of de code voldoet aan standaarden op het gebied van naam correctheid, relevantie van code, uitbreidbaarheid, codecomplexiteit, algoritmencomplexiteit en codebeveiliging.
U kunt een probleem toevoegen vanuit de widget Nieuw werkitem dat is toegevoegd aan een teamdashboard of vanuit het menu Nieuw op de pagina Query's.
Werkitems die u vanuit de widget toevoegt, worden automatisch afgestemd op het standaardgebied en iteratiepaden van uw team. Zie Teamcontext wisselen om de teamcontext te wijzigen.
Definities voor algemene velden voor het bijhouden van werk
De volgende velden en tabbladen worden weergegeven in de meeste werkitems. Elk tabblad wordt gebruikt om specifieke informatie bij te houden, zoals 
Geschiedenis, Koppelingen of 
Bijlagen. Deze drie tabbladen bieden een geschiedenis van wijzigingen, weergave van gekoppelde werkitems en de mogelijkheid om bestanden te bekijken en bij te voegen.
Het enige vereiste veld voor alle typen werkitems is Titel. Wanneer u een werkitem opslaat, wordt dit door het systeem een unieke id toegewezen. Het formulier markeert het vereiste veld geel. Zie de veldindex werkitem voor meer informatie over andere velden.
Notitie
Mogelijk zijn er extra velden vereist, afhankelijk van aanpassingen die zijn aangebracht in uw proces en project.
Veld/tabblad
Gebruik
Voer een beschrijving in van 255 tekens of minder. U kunt de titel later altijd wijzigen.
Wijs het werkitem toe aan het teamlid dat verantwoordelijk is voor het uitvoeren van het werk.
Wanneer het werkitem wordt gemaakt, wordt de status standaard ingesteld op de eerste status in de werkstroom. Werk het bij naarmate het werk vordert, zodat deze overeenkomt met de huidige status.
Gebruik eerst de standaardwaarde. Werk deze bij wanneer u de status wijzigt. Elke status is gekoppeld aan een standaardreden.
Kies het gebiedspad dat is gekoppeld aan het product of team of laat leeg totdat deze is toegewezen tijdens een planningsvergadering. Zie Gebiedspaden definiëren en toewijzen aan een team om de vervolgkeuzelijst met gebieden te wijzigen.
Kies de sprint of iteratie waarin het werk moet worden voltooid, of laat het leeg en wijs het later toe tijdens een planningsvergadering. Zie Iteratiepaden (sprints) definiëren en teamiteraties configureren om de vervolgkeuzelijst met iteraties te wijzigen.
Controleer het audittrail dat het systeem vastlegt en aanvullende informatie vastlegt.
Telkens wanneer het werkitem wordt bijgewerkt, wordt informatie toegevoegd aan de geschiedenis. Geschiedenis bevat de datum van de wijziging, wie de wijziging heeft aangebracht en welke velden zijn gewijzigd. U kunt ook opgemaakte tekst toevoegen aan het geschiedenisveld.
Voeg alle typen koppelingen toe, zoals hyperlinks, wijzigingensets, bronbestanden enzovoort.
Dit tabblad bevat ook alle koppelingen die zijn gedefinieerd voor het werkitem.
Deel meer gedetailleerde informatie door bestanden toe te voegen aan het werkitem, zoals e-mailthreads, documenten, afbeeldingen, logboekbestanden of andere bestandstypen.
Typen werkitems aanpassen
Voor de meeste typen werkitems kunt u velden toevoegen, de werkstroom wijzigen, aangepaste regels toevoegen en aangepaste pagina's toevoegen aan het werkitemformulier. U kunt ook aangepaste typen werkitems toevoegen. Zie Een overnameproces aanpassen voor meer informatie.
Voor de meeste typen werkitems kunt u velden toevoegen, de werkstroom wijzigen, aangepaste regels toevoegen en aangepaste pagina's toevoegen aan het werkitemformulier. U kunt ook aangepaste typen werkitems toevoegen. Zie Een overnameproces aanpassen of het on-premises XML-procesmodel aanpassen, afhankelijk van het procesmodel dat door uw project wordt gebruikt, voor meer informatie.
Verwante artikelen:
- Een project maken
- Werkitems toevoegen om een project te beheren
- Een achterstand maken
- Toegang tot specifieke functies beheren
- Meer informatie over standaardmachtigingen en toegangsniveaus voor Azure Boards
Volgorde van achterstandslijst
Het veld Stack Rank wordt gebruikt om de relatieve rangorde van vereisten, functies of epics bij te houden. Standaard wordt dit echter niet weergegeven in het werkitemformulier. De volgorde van items op de achterstandspagina wordt bepaald op basis van waar u de items hebt toegevoegd of de items op de pagina hebt verplaatst. Wanneer u items sleept, wordt dit veld bijgewerkt door een achtergrondproces.
Dit veld wordt niet weergegeven in het werkitemformulier.