Metriken erfassen
Zweck
|
Qualitäts- und Fortschrittsinformationen zum Projekt in Bezug auf den Status und Verbesserungen erfassen.
|
Dieser Schritt umfasst die folgenden Arbeiten, basierend auf dem Projektkontrollplan:
-
Basismetriken erfassen.
-
Metriken berechnen, prüfen und validieren.
-
Metriken in den Statusbewertungsbericht einfügen.
Während einer Iterationsauswertung werden Metriken untersucht und Entscheidungen über viele Aktionen getroffen, die
sich auf Neuplanung, neuen Einsatz von Tools, Training, Umorganisation usw. und eine Überarbeitung des
Projektkontrollplans beziehen können. Am Ende eines Zyklus kann durch eine "Post-Mortem-Prüfung" sichergestellt werden,
ob einige der erfassten Metriken für eine Verbesserung des Prozesses oder als Grundlage für neue Schätzungen verwendet
werden können. Weitere Informationen zu Metriken finden Sie in Richtlinie für
Arbeitsergebnis: Metriken.
Für Iterationen, die sich über Wochen oder sogar Monate erstrecken, sind die Erfassung von Metriken und die Erstellung
von Berichten fortlaufende Aufgaben mit regelmäßigen Statusauswertungen, bei denen die vorläufigen Ergebnisse erfasst
werden.
|
Ergebnisse der Iteration auswerten
Zweck
|
Tatsächliche und erwartete Ergebnisse der Iteration miteinander vergleichen.
|
Gegen Ende jeder Iteration muss sich das Kernprojektteam zusammensetzen und die Iteration unter den folgenden
Gesichtspunkten auswerten:
-
War die Iteration in Bezug auf die Erfüllung ihrer Ziele erfolgreich?
-
Wurden Risiken minimiert oder sogar eliminiert?
-
Erfüllt das Release seine Ziele in puncto Funktionalität und Qualität? Leistungs- und Kapazitätsziele?
-
Sind alle Änderungen am Projekt- und an künftigen Iterationsplänen erforderlich?
-
Wurden alle Untersuchungsergebnisse, die in der Bewertung der Entwicklungsorganisation erfasst wurden, durch
Änderungen während der Iteration entkräftet (in Folge erforderlicher Änderungen an anderen Arbeitsergebnissen, z.
B. des Entwicklungsprozesses des Projekts)?
-
Sind Schwierigkeiten in Bezug auf den Entwicklungsprozess des Projekts während der Iteration
aufgetreten?
-
Von welchem Teil des aktuellen Release wird eine Referenzversion erstellt und welcher Teil wird überarbeitet?
-
Wurden neue Risiken erkannt?
-
Sind externe Änderungen aufgetreten (Änderungen am Markt, in der Benutzergemeinde oder in den Anforderungen)?
Werten Sie die Ergebnisse der Iteration anhand der Auswertungskriterien aus, die für den Iterationsplan festgelegt
wurden: Funktionalität, Leistung, Kapazität, Qualität. Verwenden Sie, sofern verfügbar, Messwerte aus Testaufgaben und
aus dem Schritt Metriken erfassen als Basis für die Auswertung, um die Auswertung zu
quantifizieren. Qualitative Messwerte eignen sich für die Konzeptionsphase und möglicherweise in frühen Iterationen,
wohingegen sich die Ausarbeitungs-, Konstruktions- und Übergangsphasen auf spezifische Testmessungen stützen müssen, um
Qualität, Leistung, Kapazität usw. zu beurteilen. Behandeln Sie alle nicht behobenen Probleme, die in den
Statusbewertungen während der Iteration erfasst wurden, und die Probleme, die in der Liste der offenen Punkte des
Projektleiters aufgeführt sind.
Wenn alle Risiken auf ein angemessenes Maß vermindert wurden, die gesamte Funktionalität implementiert wurde und alle
Qualitätszielsetzungen erreicht wurden, ist das Produkt vollständig. Eine gute Planung und Ausführung sind
entscheidend, damit dies als Ergebnis am Ende der Übergangsphase steht.
|
Externe Änderungen berücksichtigen
Zweck
|
Sicherstellen, dass das Projekt mit der "Außenwelt" in Kontakt bleibt
|
Es kann leicht passieren, dass das Projektteam sich so nach innen orientiert, dass es die Änderungen außerhalb des
Projektteams nicht mehr wahrnimmt. Das Geschäft kann sich ändern, es können neue Schlüsselanforderungen hinzukommen, es
können sich Schlüsselanforderungen ändern, und es können Schlüsselanforderungen wegfallen. Ein Konkurrent könnte ein
ähnliches Produkt auf den Markt bringen, was Änderungen in den Anforderungen bezüglich der Markteinführung, der
Features oder der Kosten für das Zielprodukt verursachen kann.
Ist der Projektplan (einschließlich der Meilensteine) vor dem Hintergrund des aktuellen Zustands der externen Umgebung
noch gültig? Haben sich die Risiken geändert und ist somit eine Überarbeitung der Iterationspläne erforderlich? Wird
das richtige Produkt erstellt und ist die Vision noch gültig? Ist das Produktteam mit der Bereitstellung dieses
Produkts auf dem richtigen Weg? Sind aufgrund geänderter äußerer Umstände Prozessänderungen erforderlich?
Verwenden Sie die Ergebnisse dieser Diskussionen, um Änderungsanfragen für die Vision, die
Liste der Risiken, den Softwareentwicklungsplan, den Iterationsplan
oder den Entwicklungsprozess des Projekts zu generieren.
|
Bewertungskriterien untersuchen
Zweck
|
Sicherstellen, dass die Bewertungskriterien realistisch sind.
|
Manchmal bleibt eine Iteration hinter den Erwartungen zurück, weil die Zielsetzungen zu hoch angesetzt wurden. Sich
hohe Ziele zu stecken, ist zwar wichtig, aber die Linie zwischen offensiven und unrealistischen Zielen ist sehr fein.
Ziele motivieren Projektteams, ihre Fähigkeiten auszureizen. Wenn die Zielsetzungen jedoch kontinuierlich über die
Grenzen des Erreichbaren hinausgehen, kann dies für die Projektteams demoralisierend sein. Um Ziele so zu definieren,
dass das Projektteam zwar gefordert, aber nicht überfordert wird, sind manchmal ein paar Iterationen erforderlich, in
denen das Team zusammenfindet und seine Grenzen auslotet.
Untersuchen Sie die Bewertungskriterien, um festzustellen, ob sie realistisch waren. Manchmal kann in einer Iteration
aufgedeckt werden, dass eine bestimmte Anforderung nicht so wichtig ist, wie ursprünglich gedacht. Projekte werden
häufig von komplexen Anforderungen mit relativ geringem Wert erdrückt, die von übereifrigen Benutzern gestellt werden,
die von der neuesten Technologie ganz gefesselt sind. Mit einer oder zwei Iterationen können Sie die Erwartungen
zurückschrauben und die Benutzer dazu bringen, den Schwerpunkt auf Funktionalität zu setzen, die einen echten Wert
darstellt.
Manchmal kann eine Iteration aufdecken, dass ein bestimmtes Feature sehr aufwändig zu implementieren ist und die
Architektur praktisch nicht mehr pflegbar macht. In diesem Fall muss die Kosten-Nutzen-Analyse für dieses Feature
nochmals bearbeitet werden, um festzustellen, ob das Feature im geplanten Rahmen weiterentwickelt oder vielleicht
überarbeitet werden sollte, um die Anforderung auf eine kostenwirksame Weise erreichbar zu machen.
|
Änderungsanfragen erstellen
|