Planen eines Projekts (CMMI)
Ein Projektplan sollte einen Projektumfang, einen Zeitplan, ein Budget, einen Risikomanagementplan, eine Festlegung und die Zustimmung aller Projektbeteiligten umfassen. Nachdem Übereinstimmung über einen Projektplan erzielt wurde, sind die nächsten Schritte Analyse, Entwurf, Entwicklung, Tests und schließlich Lieferung.
Mit einer iterativen Entwicklungsmethode können Sie das Risiko verringern. Mit Iterationen können Sie am Ende jeder Iteration ein teilweise funktionsfähiges Produkt vorführen und in der weiteren Entwicklung Feedback zu dieser Vorführung berücksichtigen. Daher bietet der Plan einen allgemeinen Umriss, und er kann vor Beginn jeder Iteration überprüft und verfeinert werden.
Erfassen und Modellieren der Anforderungen
Bei dieser Aktivität werden mit Projektbeteiligten, potenziellen Benutzern und Experten die gewünschten Funktionen des Systems erörtert. Kenntnisse des Geschäftskontexts sind erforderlich. Wenn Sie eine Anwendung für Polizeibeamte schreiben sollen, ist es hilfreich, wenn Sie deren Jargon, Verfahren und Regeln kennen.
UML-Modelle sind ein nützliches Werkzeug, um komplexe Beziehungen darzustellen und zu begreifen. Sie können sie in Visual Studio zeichnen und mit anderen Dokumenten sowie mit Team Foundation-Arbeitsaufgaben verknüpfen. Weitere Informationen finden Sie unter Modellieren von Benutzeranforderungen.
Aktualisieren und verfeinern Sie das Anforderungsmodell während des gesamten Projekts. Fügen Sie vor Beginn jeder Iteration den Aspekten des Modells, die für die jeweilige Iteration relevant sind, weitere Details hinzu. Sie können vom Modell Überprüfungstests ableiten.
Weitere Informationen finden Sie unter Entwickeln von Anforderungen und Entwickeln von Tests aus einem Modell.
Erstellen von inkrementellen Produktanforderungen
Die Anforderungen, die Sie von den Kunden erfasst haben, eignen sich nicht direkt für die Planung der inkrementellen Entwicklung. Um beispielsweise klarzustellen, wie Benutzer ein Produkt auf einer Website erwerben, können Sie eine Reihe detaillierter Schritte schriftlich ausarbeiten: Der Kunde durchsucht den Katalog, fügt dem Einkaufswagen den Artikel hinzu, geht mit dem Einkaufswagen zur Kasse, gibt seine Adresse an und zahlt, das Lager plant die Lieferung usw. Diese Schritte oder ein entsprechendes Aktivitätsdiagramm müssen nicht inkrementell sein.
Stattdessen wird im ersten Inkrement des Systems möglicherweise nur ein Artikel zum Kauf angeboten, dieser wird an nur eine Adresse geliefert, und es wird nur eine Testtransaktion mit dem Zahlungsdienst ausgeführt. Im zweiten Inkrement kann ein Katalog bereitgestellt werden, der aus einer einfachen Liste besteht. In anschließenden Inkrementen wird eventuell eine optionale Geschenkverpackung oder eine Option zum Anfordern von Katalogen anderer Anbieter hinzugefügt. Einige Inkremente stellen möglicherweise eine höhere Servicequalität bereit, z. B. die Fähigkeit, nicht nur einen Kunden, sondern 1.000 Kunden zu bearbeiten.
Anders ausgedrückt: Die frühen Inkremente sollten die Hauptanwendungsfälle als End-to-End-Anwendungsfälle behandeln und allmählich weitere Funktionen für den gesamten Vorgang hinzufügen.
Wenn Sie mit einem vorhandenen Produkt arbeiten, ist das Prinzip das Gleiche, jedoch beginnen Sie mit den vorhandenen Funktionen. Wenn Sie mit dem internen Entwurf nicht vertraut sind, sind die Kosten von Updates eventuell schwierig zu schätzen. Es empfiehlt sich, die Kosten für die ersten Änderungen großzügig zu schätzen.
Weitere Informationen finden Sie unter Entwickeln von Anforderungen.
Eingeben und Bearbeiten von Produktanforderungen
Zeichnen Sie in Team Foundation die inkrementellen Produktanforderungen als Anforderungsarbeitsaufgaben auf, und legen Sie den Anforderungstyp auf Funktion fest. Sie können einen Backlog von Anforderungen mithilfe von TWA oder Team Explorer erstellen. Wenn Sie über einige Arbeitsaufgaben verfügen, die Sie gleichzeitig erstellen möchten, verwenden Sie Excel.
Schätzen der Produktanforderungen
Das Entwicklungsteam sollte die zum Entwickeln der einzelnen Produktanforderungen benötigte Arbeit schätzen. Die Schätzung sollte im Feld Ursprüngliche Schätzung der Arbeitsaufgabe in Stunden eingegeben werden.
In einem frühen Stadium des Projekts ist nur eine grobe Schätzung erforderlich.
Teilen Sie umfangreiche Produktanforderungen in geringere Produktanforderungen auf. Idealerweise erfordert jede Produktanforderung nur einige Tage an Entwicklungszeit.
Zuweisen von Produktanforderungen zu Iterationen
Personen aus dem Kreis der Projektbeteiligten und des Entwicklungsteams sollten gemeinsam Iterationen Produktanforderungen zuweisen. In der Regel erfolgt dies in einer Besprechung, in der Sie die Office Excel-Ansicht der Abfrage Produktanforderungen freigeben oder projizieren.
Die Zuweisung wird mit den folgenden Informationen ausgeführt:
Die Priorität der Anforderung. Siehe die Hinweise im folgenden Unterabschnitt.
Die geschätzten Kosten. Entsprechend der Anzahl der Teammitglieder und der Länge der Iteration enthält jede Iteration nur eine feste Anzahl von Stunden, die für die Entwicklung verfügbar sind. Weiterhin wird eine erhebliche Anzahl dieser Stunden für die Iterationsplanung und andere Aufgaben verwendet, bei denen es sich nicht direkt um Entwicklungsaufgaben handelt.
Abhängigkeiten zwischen den Produktanforderungen. In einer inkrementellen Reihe von Anforderungen müssen die einfachsten Anforderungen vor Erweiterungen im gleichen Bereich behandelt werden.
Sie können die Anforderung in einer Arbeitsaufgabe definieren, indem Sie vielfältige Informationen angeben, wie in den folgenden Abbildungen veranschaulicht:
.png "Requirement work item form")
Einige Richtlinien zur Prioritätszuordnung
Es gibt viele detaillierte Schemas für die Prioritätszuordnung. Einige dieser Schemas werden beim Erörtern der Iterationsplanung untersucht. An dieser Stelle, auf Projektebene, werden einige Richtlinien beschrieben, die zum Verwalten von Risiken und Optimieren des Nutzwerts hilfreich sein können.
Priorisieren Sie minimale End-to-End-Szenarien.
Versuchen Sie, in einem möglichst frühen Stadium des Projekts ein einfaches End-to-End-Szenario zu erstellen. Fügen Sie später den verschiedenen Teilen des Szenarios weitere Funktionen hinzu. Diese Vorgehensweise stellt sicher, dass die Hauptfunktionen der Plattform und die wichtigsten Konzepte der Anforderungen frühzeitig getestet werden.
Unterteilen Sie hingegen nicht den Zeitplan entsprechend der Architektur. Ein Zeitplan, in dem die Datenbank, dann die Geschäftslogik und dann die Benutzeroberfläche erstellt wird, erfordert wahrscheinlich umfangreiche Überarbeitungen, um schließlich die Teile zu integrieren. Ebenso wird eine horizontale Unterteilung, z. B. {Verkaufskomponente; Lagerkomponente; Zahlungskomponente}, nicht empfohlen. Dieser Zeitplan ergibt wahrscheinlich ein traumhaftes System für den Verkauf im Internet, wird jedoch niemals rechtzeitig umgesetzt, um die Bezahlfunktionen erfolgreich implementieren zu können. Vollständige Komponenten können nur für spätere Iterationen geplant werden, wenn es sich tatsächlich um optionale Add-Ons handelt.
Priorisieren Sie technische Risiken.
Wenn ein Szenario ein technisch riskantes Element einschließt, entwickeln Sie es zu einem frühen Zeitpunkt im Zeitplan. Überprüfen Sie Risiken zu einem frühen Zeitpunkt, um Fehler zu erkennen. Wenn etwas nicht erreicht werden kann, sollten Sie dies zu einem frühen Zeitpunkt im Projekt wissen, damit das Element abgebrochen oder durch eine andere Vorgehensweise ersetzt werden kann. Behandeln Sie daher technisch riskante Anforderungen in frühen Iterationen.
Priorisieren Sie die Verringerung der Ungewissheit.
Die Projektbeteiligten sind von einigen Anforderungen nicht vollständig überzeugt. Es ist schwierig vorherzusagen, welches Produktverhalten im Geschäftskontext die besten Ergebnisse liefert. Priorisieren Sie die Arbeit, von der Sie annehmen, dass Sie Ungewissheiten verringert. Dies kann oft erreicht werden, indem Sie eine einfachere Version des Szenarios entwickeln, mit der Benutzer experimentieren können. Erstellen Sie das vollständige Szenario erst in einer späteren Iteration, in der die Ergebnisse dieser Experimente berücksichtigt werden können.
Priorisieren Sie Anforderungen mit hohem Wert.
Versuchen Sie nach Möglichkeit, für jedes Szenario eine Opportunitätskostenfunktion zu erstellen. Bestimmen Sie mit diesen Funktionen die Anforderungen, die möglicherweise dem Kunden zu einem früheren Zeitpunkt einen größeren Nutzen bringen. Behandeln Sie diese Anforderungen in frühen Iterationen. So erhalten Sie eventuell die Möglichkeit, einen Teil des Produkts frühzeitig zu veröffentlichen.
Fassen Sie Szenarien, die mehreren Personas gemeinsam sind, in Gruppen zusammen.
Wenn Szenarien für mehrere Personas von Nutzen sind, fassen Sie sie in Gruppen zusammen. Legen Sie ihre Rangordnung nach der Anzahl von Personas fest, die das Szenario benötigen. Behandeln Sie die Szenarien, die für eine größere Anzahl von Personas gelten, in frühen Iterationen.
Legen Sie eine Rangordnung von Personas fest.
Personas stellen Marktsegmente oder Benutzergruppen dar. Marketingexperten oder Geschäftsinhaber sollten in der Lage sein, die Priorität dieser Segmente oder Gruppen auf Grundlage des zu liefernden Nutzens oder des Werts des Segments anzugeben. Wenn Segmente oder Benutzergruppen nach Priorität in eine Rangordnung gebracht werden können, stellen Sie dies dar, indem Sie die Personas für jedes Segment nach Rang aufführen. Identifizieren Sie die Szenarien für die Personas mit dem höchsten Rang, und behandeln Sie diese in frühen Iterationen des Zeitplans.
Im Allgemeinen sollte aufgrund der Möglichkeit von Fehlern die Verringerung des Risikos priorisiert werden. Allgemeine Funktionen sollten priorisiert werden, da sie wahrscheinlich erforderlich sind und es unwahrscheinlich ist, dass sie geändert werden. Anforderungen mit höherem Wert sollten priorisiert werden. Die frühzeitige Veröffentlichung des Produkts für eine Teilmenge von Personas sollte ermöglicht werden, indem alle Szenarien priorisiert werden, die erforderlich sind, um die Anforderungen jeder einzelnen Persona zu erfüllen.
Planen von Tests
Die Schätzung der Arbeit für jede Anforderung muss den Aufwand einschließen, der erforderlich ist, um die Anforderung manuell oder durch Erstellen eines automatisierten Tests zu testen.
Bevor eine Produktanforderung als abgeschlossen gilt, muss sie mit einem Satz von Testfallarbeitsaufgaben verknüpft werden, die zusammen nachweisen, ob die Anforderung erfüllt wurde, und die Tests müssen bestanden werden.
Wenn Sie Produktanforderungen erstellen oder überarbeiten, muss der entsprechende Testplan aktualisiert werden.
Überarbeiten der Produktanforderungen
Rufen Sie vor jeder Iteration diese Aktivität erneut auf, um überarbeitete und neue Anforderungen, überarbeitete Prioritäten und überarbeitete Schätzungen zu überprüfen. In den ersten Iterationen erfolgt eine größere Anzahl von Überarbeitungen.
Nach den ersten Iterationen können die Mitglieder des Entwicklungsteams zuverlässigere Schätzungen erstellen. Sie sollten die Schätzungen in der folgenden Iteration oder in den folgenden zwei Iterationen überprüfen und die Felder Ursprüngliche Schätzung der Anforderungen überarbeiten, die diesen Iterationen zugewiesen sind.