Arbeitsaufgabentypen und Workflow für CMMI-Prozessvorlagen
Teams verwenden die Arbeitsaufgabentypen (WITs), die mit der MSF for CMMI Process Improvement 2013 (CMMI)-Prozessvorlage bereitgestellt werden, um den Fortschritt von Softwareprojekten zu planen und nachzuverfolgen. Teams definieren Anforderungen zur Verwaltung des Arbeitsbacklogs und verwenden dann das Kanban-Board, um den Fortschritt nachzuverfolgen, indem sie den Anforderungsstatus aktualisieren.
Um Einblick in ein Anforderungsportfolio zu erhalten, können Produktbesitzer Funktionen Zuordnungsanforderungen zuordnen. Wenn Teams in Iterationen arbeiten, definieren sie Aufgaben, die automatisch mit Anforderungen verknüpft sind.
Mithilfe von Microsoft Test-Manager und dem Team Web Access (TWA) können Tester Testfälle erstellen und ausführen sowie Fehler definieren, mit denen sich defekter Code nachverfolgen lässt.
Um zusätzliche CMMI-Prozesse zu unterstützen, können Teams Änderungsanforderungen, Risiken, Probleme und Hinweise, die in den Überprüfungsbesprechungen erfasst wurden nachverfolgen.
Planen Sie ein Projekt, indem Sie Anforderungen definieren und den Aufwand schätzen
Erstellen Sie Anforderungen im Bereich zum schnellen Hinzufügen auf der Product Backlog-Seite. Alternativ können Sie mehrere Anforderungen mit Excel oder Project gleichzeitig hinzufügen.
Später können Sie jede Anforderung öffnen, um weitere Details bereitzustellen und die Größe zu schätzen.
Anforderungen geben Funktionen und Produktelemente an, die die Teams erstellen müssen. Produktbesitzer definieren und priorisieren Anforderungen auf der Product Backlog-Seite. Das Team schätzt dann den erforderlichen Aufwand zur Bereitstellung der Elemente mit der höchsten Priorität.
Durch Definieren der Größe für Anforderungen können Teams anhand der Vorhersagefunktion und Geschwindigkeitsdiagramme zukünftige Iterationen oder den Arbeitsaufwand einschätzen. Erfassen Sie die wichtigsten Informationen mithilfe der folgenden Registerkarten und Felder. Weitere Anleitungen finden Sie unter Planen eines Projekts.
Feld/Registerkarte |
Verwendung |
---|---|
Größe (siehe Hinweis 1) |
Schätzen Sie den Arbeitsaufwand zum Fertigstellen einer Anforderung in der vom Team bevorzugten Maßeinheit ab, ob T-Shirt-Größe, Storypunkte oder Zeit. Von flexiblen Geschwindigkeitsdiagrammen und Vorhersagetools wird auf die Werte in diesem Feld verwiesen. Dies ist ein Pflichtfeld zum Generieren des Geschwindigkeitsdiagramms. |
Priorität [erforderlich] (2) |
Eine subjektive Bewertung der Anforderung und ihrer Auswirkungen auf das Geschäft. Zulässige Werte sind:
|
Selektierung [erforderlich] (2) |
Gibt den Typ der Selektierungsentscheidung an, die für die Arbeitsaufgabe ausstehend ist. Verwenden Sie dieses Feld, wenn die Arbeitsaufgabe den Zustand "Vorgeschlagen" aufweist, und geben Sie einen der folgenden Werte an: Ausstehend (Standard), Weitere Informationen, Informationen empfangen und Selektiert. |
Blockiert (2) |
Gibt an, ob ein Teammitglied daran gehindert wird, Fortschritte bei der Implementierung einer Anforderung oder Aufgabe oder beim Beheben eines Fehlers, Problems, einer Änderungsanforderung oder eines Risikos zu machen. Wenn ein Problem geöffnet wurde, um ein Blockierungsproblem nachzuverfolgen, können Sie einen Link zum betreffenden Problem erstellen. Sie können Ja oder Nein angeben. |
Zugesichert [erforderlich] (2) |
Gibt an, ob ein Commit für die Anforderung im Projekt ausgeführt wird. Sie können Ja oder Nein angeben (Standard). |
Stapelrang (1) |
Wird verwendet, um die relative Rangfolge der Anforderungen zu verfolgen. Die Reihenfolge der Elemente auf der Product Backlog-Seite richtet sich danach, wo die Elemente auf der Seite hinzugefügt bzw. wohin sie verschoben wurden. Beim Ziehen von Elementen aktualisiert ein Hintergrundprozess dieses Feld, das in der ProcessConfiguration-Datei type="Order" zugewiesen ist. |
(Anforderung) Typ [erforderlich] (2) |
Die Art der Anforderung, die implementiert werden soll. Sie können einen der folgenden Werte angeben:
|
Geben Sie genug Details zur Einschätzung des Arbeitsaufwands zur Implementierung der Anforderung an. Konzentrieren Sie sich auf die vorgesehenen Anwender der Anforderung: Was soll erreicht werden, und weshalb? Beschreiben Sie nicht, wie die Anforderung entwickelt werden soll. Stellen Sie ausreichende Informationen bereit, damit das Team Aufgaben und Testfälle schreiben kann, um das Element zu implementieren. In HTML-Felder können Sie Rich Text und Images hinzufügen. |
|
Analyse |
Die Auswirkungen für Kunden, wenn die Anforderung nicht implementiert wird. Sie können auch Details zum Kano-Modell einschließen, um anzugeben, ob es sich um eine Basis-, Leistungs- oder Begeisterungsanforderung handelt. Erfassen Sie diese Informationen im Rich Text-HTML-Feld, das der Bewertung der Auswirkungen entspricht. |
Andere |
Die folgenden Felder auf der Registerkarte Andere sind nicht erforderlich.
|
Hinweise:
Informationen zum Ändern der Feldzuweisung finden Sie unter Konfigurieren und Anpassen von Agile-Planungstools für ein Teamprojekt.
Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.
Sie können die Arbeit in Stunden oder in Tagen angeben. Es gibt keine inhärenten Zeiteinheiten, die diesem Feld zugeordnet sind.
Wenn Sie Microsoft Project verwenden, um Ressourcen zuzuweisen und einen Zeitplan nachzuverfolgen, können Sie diese Felder mithilfe von Project aktualisieren.
Nachverfolgen des Fortschritts
Teams können mithilfe des Kanban-Board den Status von Anforderungen und mithilfe des Sprint-Task Board den Status von Aufgaben nachverfolgen. Durch Ziehen von Elementen zu einer neuen Zustandsspalte werden die Felder Zustand und Grund aktualisiert.
Sie können Kanban-Board anpassen, um weitere Verantwortlichkeitsbereiche oder Spalten zu unterstützen. Sie können auch den Workflow für die Anforderungen und die Aufgaben-WITs anpassen, wodurch die Standardspaltenüberschriften geändert werden.
Eine typische Workflowprogression für eine Anforderung:
Der Produktbesitzer erstellt eine Anforderung mit dem Status Vorgeschlagen mit dem Standardgrund Neue Anforderung.
Der Produktbesitzer aktualisiert den Status in Aktiv, wenn damit begonnen wird, diese zu implementieren.
Das Team aktualisiert den Status in Gelöst, wenn die Codeentwicklung abgeschlossen ist und Systemtests bestanden wurden.
Abschließend verschiebt das Team oder der Produktbesitzer die Anforderung in Geschlossen, wenn der Produktbesitzer zustimmt, dass sie entsprechend den Akzeptanzkriterien implementiert wurde und alle Überprüfungstests bestanden wurden.
Zuordnen von Anforderungen zu Funktionen
Wenn Sie eine Gruppe von Produkten oder Benutzererfahrungen verwalten, sollten Sie den Umfang und den Status der Arbeit für das Produktportfolio anzeigen. Definieren Sie dazu Funktionen und ordnen Sie diesen Funktionen Anforderungen zu.
Auf der Funktions-Backlog-Seite können Sie Funktionen genauso schnell hinzufügen wie Anforderungen.
Die Funktionsarbeitsaufgabe enthält ähnliche Felder, die für Anforderungen bereitgestellt werden, und umfasst weitere Felder, wie in der folgenden Tabelle beschrieben.
Die Registerkarte Anforderungen erfasst die Links mit zugeordneten Anforderungen.
Feld |
Verwendung |
---|---|
Geben Sie eine Zahl an, die den relativen Wert einer Funktion im Vergleich mit anderen Funktionen darstellt. Je größer die Zahl, desto größer ist der Geschäftswert. |
|
Geben Sie das Datum an, bis zu dem die Funktion implementiert werden soll. |
Ziehen Sie von der Backlog-Seite mit aktivierter Zuordnungsfunktion Anforderungen zu der Funktion, die sie implementieren.
Diese Zuordnung erstellt Links zwischen übergeordneten und untergeordneten Daten von der Funktion zu Anforderungen erstellt, die auf der Registerkarte Anforderungen erfasst werden.
Mithilfe von Portfolio-Backlogs können Sie einen Drilldown zwischen Backlogs durchführen, um den gewünschten Detailgrad anzuzeigen. Außerdem können Sie Portfoliobacklogs verwenden, um einen Rollup der in Bearbeitung befindlichen Aufgaben für mehrere Teams anzeigen, wenn Sie eine Hierarchie für die Teams festlegen.
Definieren Sie die Aufgaben, die erforderlich sind, um Anforderungen zu implementieren und Teamkapazität und Burndown nachzuverfolgen
Wenn das Team die Arbeit in einer Reihe von Iterationen verwaltet, können sie die Sprint-Backlog-Seite verwenden, um die Arbeit in einzelne Aufgaben zu untergliedern.
Geben Sie der Aufgabe einen Namen und schätzen Sie die dafür erforderliche Arbeit.
Wenn Teams den Arbeitsaufwand einschätzen, definieren sie Aufgaben und schätzen die Stunden oder die Tage, die zum Abschließen der Aufgaben erforderlich sind. Die Teams planen die Arbeit und definieren die Aufgaben zu Beginn jeder Iteration. Dabei führt jedes Teammitglied einen Teil dieser Aufgaben aus. Zu Aufgaben zählen Entwicklung, Tests und andere Arbeitsschritte. Zum Beispiel kann ein Entwickler Aufgaben definieren, um Anforderungen zu implementieren, und ein Tester kann Aufgaben definieren, um Testfälle zu schreiben und auszuführen. Das Verknüpfen von Aufgaben mit Anforderungen und Fehlern ergibt Informationen zum Fortschritt dieser Elemente. Weitere Anleitungen finden Sie unter Iterationsaktivitäten.
Feld |
Verwendung |
---|---|
Aufgabentyp (siehe Hinweis 1) |
Wählen Sie die Art der zu implementierenden Aufgabe aus folgenden zulässigen Werten aus:
|
Disziplin (1) |
Wählen Sie die Disziplin aus, die diese Aufgabe darstellt, wenn das Team die Sprintkapazität nach Aktivität schätzt.
Dieses Feld wird auch zur Berechnung der Kapazität nach Disziplin verwendet. Es ist type="Activity" in der ProcessConfiguration-Datei zugewiesen. (2) Weitere Anleitungen finden Sie unter Implementieren von Entwicklungsaufgaben. |
Der geschätzte Arbeitsaufwand, der zum Abschluss einer Aufgabe erforderlich ist. In der Regel wird dieses Feld nicht geändert, nachdem es zugewiesen ist. |
|
Geben Sie an, wie viele Stunden oder Arbeitstage bis zum Abschluss einer Aufgabe verbleiben. Aktualisieren Sie dieses Feld im Verlauf der Arbeit. Es wird zum Berechnen von Kapazitätsdiagrammen, des Sprint-Burndown Diagramms und des Bericht "Burndown und Verbrauchsrate"-Berichts verwendet. Wenn Sie eine Aufgabe in Unteraufgaben unterteilen, geben Sie Stunden nur für die Unteraufgaben an. Sie können die Arbeit in einer die oft ausgegebene Befehlszeilen Maßeinheit angeben, ganz nach Wunsch des Teams. |
|
Der Arbeitsaufwand, der zum Implementieren einer Aufgabe erforderlich war. |
Hinweise:
Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste.
Informationen zum Ändern der Feldzuweisung finden Sie unter Konfigurieren und Anpassen von Agile-Planungstools für ein Teamprojekt.
Sie können die Arbeit in Stunden oder in Tagen angeben. Es gibt keine inhärenten Zeiteinheiten, die diesem Feld zugeordnet sind.
Wenn Sie Microsoft Project verwenden, um Ressourcen zuzuweisen und einen Zeitplan nachzuverfolgen, können Sie diese Felder mithilfe von Project aktualisieren.
Nachverfolgen des Teststatus von User Stories und Erfassen von Codefehlern
Testanforderungen
Über Test Manager oder TWA können Sie Testfälle erstellen, die automatisch mit einer Anforderung oder einem Fehler verknüpft sind.
Der Testfall enthält mehrere Felder, von denen viele automatisiert und in Test Manager und im Buildprozess integriert sind. Eine Beschreibung jedes Felds finden Sie unter Feldverweis für Build- und Testintegration.
Auf der Registerkarte Getestete Anforderungen werden alle Anforderungen und Fehler in einem Testfall aufgelistet. Mithilfe des Verknüpfens kann das Team den für jedes Element erzielten Teststatus verfolgen und Informationen, die im Bericht "Anforderungsübersicht" (CMMI) Bericht angezeigt werden, unterstützen.
Nachverfolgen von Codefehlern
Sie können Fehler über TWA, Visual Studio erstellen oder beim Testen mit Test Manager. Weitere Anleitungen finden Sie unter Nachverfolgen von Fehlern.
Feld/Registerkarte |
Verwendung |
---|---|
Wählen Sie die Ursache des Fehlers aus den folgenden zulässigen Werten aus:
Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste. |
|
Zeichnen Sie ausreichende Informationen auf, sodass andere Teammitglieder sowohl die vollständigen Auswirkungen des Problems verstehen als auch sicherstellen können, dass der Fehler behoben wurde. Hierzu gehören Aktionen zum Finden oder Reproduzieren des Fehlers und des erwarteten Verhaltens. Beschreiben Sie die Kriterien, die das Team verwenden soll, um zu überprüfen, dass der Fehler behoben ist. |
|
Wählen Sie einen der zulässigen Werte aus, die eine subjektive Bewertung der Auswirkungen eines Fehlers auf das Projekt darstellen:
Zum Ändern der Menüauswahl finden Sie unter Anpassen einer Auswahlliste. |
|
Wenn Test Manager Fehler erstellt, werden die Felder Systeminfo und In Build gefunden mit Informationen über die Softwareumgebung und den Build, in dem der Fehler auftrat, automatisch ausgefüllt. Mehr über das Definieren der Softwareumgebungen finden Sie unter Einrichten von Testcomputern zum Ausführen von Tests oder Sammeln von Daten. Geben Sie beim Beheben des Fehlers unter In den Build integriert den Namen des Builds ein, der den Code enthält, mit dem der Fehler korrigiert wird. Wenn Sie mit einem Dropdownmenü auf alle Builds zugreifen möchten, die ausgeführt wurden, können Sie die FIELD-Definitionen für "In Build gefunden" und "In Build integriert" aktualisieren, sodass diese auf eine globale Liste verweisen. Die globale Liste wird jedes Mal automatisch aktualisiert, wenn der Build ausgeführt wird. Weitere Informationen dazu finden Sie unter Felder, die die Integration in die Test-, Build- und Versionskontrolle unterstützen. Weitere Informationen zum Definieren von Buildnamen finden Sie unter Verwenden von Buildnummern, um abgeschlossene Builds mit aussagekräftigen Namen zu versehen. |
Nachverfolgen von Änderungsanforderungen, Risiken, Problemen und Anmerkungen, die in den Überprüfungsbesprechungen erfasst werden
Mit den folgenden WITs können Teams die Informationen nachverfolgen, die vom CMMI-Prozess empfohlen werden.
Erstellen Sie, immer wenn eine Änderung an einem Arbeitsprodukt vorgeschlagen wird, das der Änderungssteuerung unterliegt, eine Änderungsanforderung. Weitere Anleitungen finden Sie unter Verwalten von Änderungen und Änderungsanforderungsfeld-Verweis (CMMI).
Auf der Registerkarte Analyse geben Sie Details zu den Auswirkungen an, die die Änderungsanforderung auf die Architektur, die Benutzerfreundlichkeit, den Test, den Entwurf/die Entwicklung oder die technischen Veröffentlichungen hat.
Erstellen Sie ein Problem, um ein Ereignis oder eine Situation nachzuverfolgen, das bzw. die die Arbeit am Produkt blockieren könnte oder derzeit blockiert. Probleme unterscheiden sich von Risiken dahingehend, dass die Teams Probleme i. d. R. spontan, z. B. während der täglichen Teambesprechung, feststellen.
Weitere Anleitungen finden Sie unter Verwalten von Problemen und Feldverweis für Fehler, Probleme und Risiken (CMMI).
Erstellen Sie ein Risiko, um ein Ereignis oder eine Situation nachzuverfolgen, das bzw. die die Arbeit am Produkt blockieren könnte oder derzeit blockiert. Probleme unterscheiden sich von Risiken dahingehend, dass die Teams Probleme i. d. R. spontan, z. B. während der täglichen Teambesprechung, feststellen.
Weitere Anleitungen finden Sie unter Verwalten von Risiken und Feldverweis für Fehler, Probleme und Risiken (CMMI).
Erstellen Sie eine Überprüfung, um die Ergebnisse einer Entwurfs- oder Codeüberprüfung zu dokumentieren. Teammitglieder können Details zur Einhaltung von Standards durch den Entwurf oder Code im Hinblick auf Namenskorrektheit, Coderelevanz, Erweiterbarkeit, Codekomplexität, algorithmische Komplexität und Codesicherheit erfassen.
Weitere Anleitungen finden Sie unter Implementieren von Entwicklungsaufgaben und Überprüfungsbesprechungsfeldverweis (CMMI).
Definieren allgemeiner Felder und Registerkarten von Arbeitsaufgaben
In den meisten Arbeitsaufgabenformularen werden folgende Felder und Registerkarten angezeigt. Auf jeder Registerkarte werden bestimmte Informationen nachverfolgt, z. B. Verlauf, Links oder Anlagen. In diesen drei Feldern werden jeweils der Änderungsverlauf, eine Ansicht der verknüpften Arbeitsaufgaben sowie die Möglichkeit zum Anzeigen und Anfügen von Dateien bereitgestellt.
Das einzige Pflichtfeld ist Titel. Beim Speichern der Arbeitsaufgabe wird dieser vom System eine eindeutige ID zugewiesen.
Feld/Registerkarte |
Verwendung |
---|---|
Titel (erforderlich) |
Geben Sie eine höchstens 255 Zeichen lange Beschreibung ein. Sie können den Titel später jederzeit ändern. |
Weisen Sie die Arbeitsaufgabe dem für die Bearbeitung zuständigen Teammitglied zu. Ja nach dem Kontext der Arbeiten werden im Dropdownmenü nur Teammitglieder oder am Teamprojekt Mitwirkende aufgeführt. |
|
Verwenden Sie zunächst den Standardwert. Aktualisieren Sie den Wert im Verlauf der Arbeit mit dem aktuellen Zustand. Informationen zum Ändern der Dropdownliste mit Zuständen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp. |
|
Verwenden Sie zunächst die Standardeinstellung. Aktualisieren Sie den Wert bei Zustandsänderungen. Jeder Zustand ist einem Standardgrund zugeordnet. Informationen zum Ändern der Dropdownliste mit Gründen finden Sie unter Ändern des Workflows für einen Arbeitsaufgabentyp. |
|
Wählen Sie den zum Produkt oder Team gehörenden Bereichspfad aus, oder lassen Sie dieses Feld leer, bis ein entsprechender Pfad bei einer Planungsbesprechung zugewiesen wird. Informationen zum Ändern der Dropdownliste mit Bereichen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden. |
|
Wählen Sie den Sprint oder die Iteration aus, in dem bzw. der die Arbeit abgeschlossen werden soll, oder lassen Sie dieses Feld leer, und legen Sie es später bei einer Planungsbesprechung fest. Informationen zum Ändern der Dropdownliste mit Iterationen finden Sie unter Hinzufügen und Ändern von Bereichs- und Iterationspfaden. |
|
Fügen Sie beliebige Linktypen hinzu, z. B. Hyperlinks, Changesets, Quelldateien usw. Auf dieser Registerkarte werden außerdem sämtliche für die Arbeitsaufgabe definierten Links aufgeführt, einschließlich der Links von anderen Registerkarten zur Linksteuerung. |
|
Geben Sie ausführlichere Informationen frei, indem Sie der Arbeitsaufgabe Dateien hinzufügen, z. B. E-Mail-Threads, Dokumente, Bilder, Protokolldateien oder andere Dateitypen. |
|
Überprüfen Sie den vom System erfassten Audit-Trail, und zeichnen Sie zusätzliche Informationen auf. Bei jeder Aktualisierung der Arbeitsaufgabe werden dem Verlauf Informationen hinzugefügt. Der Verlauf enthält das Datum der Änderung, die Person, die die Änderung vorgenommen hat, sowie die geänderten Felder. Sie können dem Verlaufsfeld auch formatierten Text hinzufügen. |
Informationen zu anderen Feldern finden Sie im Index von Arbeitsaufgabenfeldern.
Mit dem Nachverfolgen der Arbeit beginnen
Damit Sie mit dem Nachverfolgen der Arbeit beginnen können, benötigen Sie erst ein Teamprojekt. Hier können Sie eines erstellen.
Führen Sie zum Nachverfolgen der Arbeit einen der folgenden Schritte aus:
Hier können Sie sich mit häufigen Aufgaben bei Arbeitsaufgaben vertraut machen: Erste Schritte mit Arbeitsaufgaben.
Verwenden Sie TWA zum Erstellen eines Backlogs. Siehe Erstellen Ihres Backlogs.
Verwenden Sie Project oder Excel zum Erstellen einer Arbeitsablaufstruktur.
Mehr über das Verwenden des richtigen Clients erfahren Sie hier: Auswählen des Team Foundation-Clients zur Unterstützung Ihrer Aufgaben.
Fragen und Antworten
F: Welche Workflowzustände unterstützt CMMI?
A: Diese Diagramme zeigen die wichtigsten Progressions- und Regressionsstatus von Funktion, Anforderung, Fehler und Aufgabe. Den Workflow können Sie hier anpassen.
Funktion |
Anforderung |
Fehler |
Aufgabe |
F: Wie behebe ich einen Fehler als Duplikat?
A: Legen Sie den Status auf "Entfernt" fest, und geben Sie bei Grund "Duplikat" an.
F: Wie erstelle ich eine Verknüpfung zu einem vorhandenen Fehler im Test Runner?
A: Informationen finden Sie unter Aktualisieren eines vorhandenen Fehlers während der Verwendung von Test Runner.