Iterationsaktivitäten
In MSF für CMMI Process Improvement planen Sie ein Projekt als Reihe von Iterationen. Jede Iteration dauert in der Regel vier bis sechs Wochen, in denen das Entwicklungsteam einen angegebenen Satz von Anforderungen implementiert.
Zu Beginn einer Iteration
Die Iterationsplanung erfolgt zu Beginn oder vor Beginn jeder Iteration. Sie umfasst die folgenden Aufgaben:
Überprüfen der Anforderungen, die der Iteration zugewiesen sind, und ausführlicheres Definieren dieser Anforderungen.
Erstellen von Arbeitsaufgaben für eine Aufgabe für die Arbeit, die ausgeführt werden muss, um jede Anforderung zu implementieren und zu testen. Verknüpfen Sie die Aufgaben mithilfe des Linktyps Übergeordnet mit der Anforderungsarbeitsaufgabe.
Festlegen des Felds Ursprüngliche Schätzung jeder Aufgabe. Unterteilen Sie Aufgaben, deren geschätzte Dauer mehrere Tage überschreitet.
Vergleichen der Schätzungen mit der Zeit, die für die Iteration verfügbar ist. Wenn die geschätzte Gesamtdauer zu lang ist, vereinfachen Sie einige der Anforderungen, oder verschieben Sie sie auf spätere Iterationen.
Weitere Informationen finden Sie unter Planen einer Iteration (CMMI).
Während einer Iteration
Aufgabenausführung
Teammitglieder beginnen Aufgaben und schließen sie ab, wobei sie diese Ereignisse in Arbeitsaufgaben aufzeichnen. Der Abschluss einer Aufgabe umfasst möglicherweise das Einchecken von Programmcode und anderen Artefakten. Jede Aufgabe sollte nicht länger als einige Tage dauern. Größere Aufgaben werden während der Iterationsplanung unterteilt. Weitere Informationen finden Sie unter Schreiben von neuem Code für eine User Story.
Wenn ein Teammitglied auf ein Hindernis für seine Arbeit trifft, das nicht sofort beseitigt werden kann, sollte das Teammitglied eine Problemarbeitsaufgabe protokollieren.
Tests
Es sollten manuelle oder automatische Tests entwickelt werden, und es sollten Testfälle mit den Produktanforderungen verknüpft werden. Eine Produktanforderung gilt erst als abgeschlossen, wenn die Arbeitsaufgabe mit Testfällen verknüpft ist, die bestanden wurden und nachweisen, dass die Arbeitsaufgabe einwandfrei ausgeführt wird.
Die Entwicklungsarbeit für die Tests sollte in den Aufgaben enthalten sein, die mit der Produktanforderung verknüpft sind.
Parallele und nächtliche Builds
Das Buildsystem erstellt das Produkt aus vor kurzem eingecheckten Updates und führt automatisierte Tests aus. Sie können Haupttests festlegen, die fortlaufend ausgeführt werden, und Sie können eine vollständige Reihe von Tests festlegen, die jede Nacht ausgeführt werden. Auf diese Weise können Sie verhindern, dass sich im Verlauf mehrerer Inkremente Fehler ansammeln. Weitere Informationen finden Sie unter Konfigurieren und Verwalten des Buildsystems.
Kurzbesprechung
Das gesamte Team führt eine kurze tägliche Überprüfung des Status der Aufgaben in der Iteration durch. Teammitglieder können das Task Board verwenden oder das Statusdashboard an die Wand projizieren, es mit Office Live Meeting freigeben oder beide Methoden verwenden.
Jedes Teammitglied berichtet kurz über den aktuellen Status, über die für den Tag geplante Arbeit und ggf. über die Arbeit blockierende Probleme.
Der Projektmanager oder Teamleiter berichtet über den Fortschritt beim Lösen von Problemen. Weitere Informationen finden Sie unter Verwalten von Problemen (CMMI).
Die Fehleranzahl wird überprüft. Fehler sollten Priorität vor neuer Entwicklungsarbeit erhalten. Versuchen Sie, die Fehleranzahl während des gesamten Projekts gering zu halten. Wenn die Anzahl der Fehler zunimmt, erörtern Sie die Ursachen und die möglichen Auswirkungen auf die Entwicklungsarbeit.
Die Burndownrate wird überprüft.
Anpassungen des Projektumfangs
Das Burndowndiagramm gibt möglicherweise an, dass die Aufgaben nicht bis zum Ende der Iteration abgeschlossen werden. In diesem Fall veranlasst der Projektmanager oder Teamleiter eine Diskussion darüber, wie sich Anforderungen vereinfachen lassen, damit Aufgaben reduziert werden können. Weitere Informationen finden Sie unter Bericht "Burndown und Verbrauchsrate".
Die Anforderungen und entsprechende Tests werden angepasst. In den Projektplan wird eine neue Anforderungsfunktion für die fehlende Funktionalität eingefügt. In der Projektplanüberprüfung, die gegen Ende der Iteration abgehalten wird, kann die Funktion einer zukünftigen Iteration zugewiesen oder entfernt werden.
Änderungsanforderungen und Risiken werden während einer Iteration nicht berücksichtigt.
Selektierung
Einige Teammitglieder (normalerweise nicht das gesamte Team) halten regelmäßig Besprechungen ab, um Fehler zu überprüfen. Jedes Teammitglied muss einen Fehler protokollieren, wenn es einen Fehler ermittelt. Ein protokollierter Fehler weist zunächst den Zustand Vorgeschlagen auf, und in der Selektierungsbesprechung wird entschieden, ob der Fehler korrigiert, in eine spätere Iteration verschoben oder abgelehnt wird.
Weitere Informationen finden Sie unter Nachverfolgen von Fehlern.
Am Ende einer Iteration
Überprüfung
Die Anforderungen gelten nur als abgeschlossen, wenn die zugeordneten Tests bestanden werden. Weitere Informationen finden Sie unter Überprüfen von Anforderungen.
Retrospektive
Die Prozessverbesserung ist ein wichtiges CMMI-Ziel.
In der Iterationsretrospektive wird überlegt, was in der Iteration gut oder schlecht ausgeführt wurde, und es werden Verbesserungen des Prozesses und der vom Team verwendeten Tools erwogen. Im Internet steht eine umfangreiche Menge an Informationen über Retrospektiven zur Verfügung.
Teammitglieder sollten jede Schuldzuweisung vermeiden. Versuchen Sie, den Prozess zu verbessern, um die Wahrscheinlichkeit zu verringern, dass Fehler von Einzelpersonen Auswirkungen haben.
Wenn Sie eine Änderung des Prozesses einführen, stellen Sie sicher, dass das Team den folgenden Entscheidungen zustimmt:
Wie Sie ermitteln, ob es eine Verbesserung war.
Wann Sie diese Bewertung durchführen.
Welche Aktion Sie aufgrund des Ergebnisses ausführen.
Integration
Wenn das Projekt Teil eines größeren Programms ist, führt jedes Team seine Arbeit in einer Verzweigung des Versionskontrollsystems aus. Die Main-Verzweigung ist zum Integrieren der Arbeit der Teams reserviert. Das Team kann am Ende einer Iteration seine Arbeit in die Main-Verzweigung integrieren. Weitere Informationen finden Sie unter Verwenden von Verzweigungen zum Isolieren von Risiken in der Team Foundation-Versionskontrolle.
Die Integration besteht aus zwei Schritten:
Eine Vorwärtsintegration, um den neueren Code aus der Main-Verzweigung mit der lokalen Projektverzweigung zusammenzuführen. Nach der Zusammenführung werden automatische und manuelle Tests ausgeführt. Dies erzeugt einige Fehler. Die Fehler werden mit hoher Priorität korrigiert.
Eine Rückwärtsintegration. Der Code der lokalen Verzweigung wird mit der Main-Verzweigung zusammengeführt, und der Build sowie die vollständige Testsammlung für die Main-Verzweigung werden ausgeführt. Die Änderungen werden rückgängig gemacht, wenn Fehler auftreten. Das Einführen von Fehlern in die Main-Verzweigung wird missbilligt. Wenn keine Fehler auftreten, wird die Integration als abgeschlossen erklärt.
Es empfiehlt sich, am Ende jeder Iteration eine Integration auszuführen. Wenn Sie die Integration verzögern, erhöht sich die Anzahl der Fehler, die nach der Vorwärtsintegration korrigiert werden müssen. Wenn das Korrigieren der Fehler viel Zeit erfordert, enthält die Main-Verzweigung neues Material, und Sie müssen eine weitere Vorwärtsintegration ausführen.
Vorbereiten der nächsten Iteration
Gegen Ende oder am Ende einer Iteration werden mehrere Projektmanagementaktivitäten ausgeführt. Zu diesen zählen das Überprüfen von Risiken und das Überprüfen des Plans hinsichtlich Änderungsanforderungen und geänderten Entwicklungsschätzungen.
Weitere Informationen finden Sie unter Projektaktivitäten.