Unsere Datenschutzrichtlinie wird in Kürze aktualisiert. Bitte sehen Sie sich die Vorschau an.

Projektmanagement: Planung und Strukturierung

Anforderungen beschreiben

Testen Sie unsere 2016 Kurse

10 Tage kostenlos!

Jetzt testen Alle Abonnements anzeigen
Um die Projektanforderungen zu bündeln und zu dokumentieren, setzen Sie bei der klassischen Vorgehensweise auf Pflichtenheft und Lastenheft, beim agilen Projektmanagement hingegen auf Backlog bzw. Product Backlog.

Transkript

Sie haben bereits eine Menge an Anforderungen für Ihr Projekt identifiziert. Aber wie bündeln und dokumentieren Sie diese? In diesem Film werden Sie erfahren, wie dies in einem klassischen und wie in einem agilen Umfeld erfolgt. Dabei werden Sie auf die zentralen Konzepte "Lastenheft", "Pflichtenheft" und "Backlog" stoßen. Beginnen wir mit der Dokumentation von Anforderungen im klassischen Umfeld. Zur Veranschaulichung dient uns ein stark vereinfachtes zeitliches Schema, das nur Projektinitiierung, Umsetzung und Projektabschluss unterscheidet. Ganz am Anfang steht der "Projektauftrag". Idealerweise beinhaltet der Projektauftrag bereits die gesammelten Anforderungen Ihres Auftraggebers. Wenn nicht, sollten Sie schnellstens Sorge tragen, dass ein vollständiger Anforderungskatalog entsteht und mit dem Auftraggeber abgestimmt wird, damit Sie auch verlässlich wissen, was der Auftraggeber wirklich will. Dieses vollständige Wünsch-dir-was nennt man "Lastenheft". Von der Idee her beinhaltet das Lastenheft bereits zu Beginn die vollständigen Anforderungen Ihres Projekts. Aufgrund der Dynamik von Anforderungen benötigen Sie aber vermutlich trotzdem ein Änderungsmanagement, indem Sie Änderungswünsche, "Change Requests", aufnehmen und in den Anforderungskatalog einarbeiten. Die Antwort auf das Lastenheft nennt man "Pflichtenheft". Im Pflichtenheft beschreibt das Projektteam, der Auftragnehmer, wie die Anforderungen aus dem Lastenheft umgesetzt werden sollen. Das kann durchaus auch Verhandlungsprozesse nach sich ziehen. Wenn sich Kundenwünsche beispielsweise als nicht machbar erweisen oder Änderungen zwischen Auftraggeber und Projektteam abgestimmt werden müssen. Manchmal finden sich statt der Begriffe "Lasten- und Pflichtenheft" auch Bezeichnungen, die synonym verwendet werden. Zum Beispiel "Fachkonzept" für das Lastenheft und "Feinkonzept" für das Pflichtenheft. Lastenheft, Pflichtenheft und Change Request sind die zentralen Anforderungsdokumente für Ihr Projekt. Die Anforderungen aus dem Lastenheft gehen in Test- und Abnahmekonzepte ein. Das Pflichtenheft wiederum liefert wesentlichen Input für die Dokumentation. Für die Gliederung eines Lastenhefts gibt es gängige Schemata, wie "Volere", eine Sammlung von Hilfsmitteln und Materialien um das Thema "Requirements Engineering", das "V-Modell XT", abgeleitet aus dem Entwicklungsstandard für IT-Systeme der öffentlichen Hand in Deutschland, oder die "Software Requirements Specification" des "Institute of Electrical and Electronic Engineers". Für alle drei finden sich zahlreiche Ausführungen im Web, insbesondere in "Wikipedia", sodass wir an dieser Stelle nicht weiter darauf eingehen wollen. Kommen wir zur agilen Welt. Wie müssen Anforderungen spezifiziert sein, damit Sie sie gut in Ihrem Projekt bearbeiten können? Zunächst sollen Anforderungen unabhängig sein, das heißt, möglichst überschneidungsfrei, dass sie unabhängig voneinander umgesetzt werden können. Bei komplexen Systemen ist es durchaus eine Herausforderung. Sie sollten verhandelbar sein. In welcher Iteration, welchem Sprint, welchem Release eine Anforderung umgesetzt wird, muss wenigstens diskutierbar sein, um dem Team Spielraum zur Optimierung der Produktivität zu geben. Einzelne Anforderungen können dann zwecks besserer Auslastung von einer Iteration in eine andere verschoben werden. Sie wollen mit Ihrem Projekt Wert stiften. Das erreichen Sie nur, wenn auch die Anforderungen, die Sie umsetzen, Wert stiften, also nützlich sind. Die Schätzbarkeit von Anforderungen, genauer die Schätzbarkeit des mit einer Anforderung verbundenen Übersetzungsaufwands ist wieder eine Frage der optimalen Auslastung in der einzelnen Iteration. In der agilen Welt haben sich zur Schätzung eigene Methoden etabliert. Die "Story Points", mit denen die Komplexität einer User-Story bewertet wird, oder "Planning Poker", einer spielerischen Aufwandsabschätzung im Team, bei der mittels Spielkarten die Teammitglieder sehr schnell und unbeeinflusst voneinander den Aufwand für einzelne Anforderungen abschätzen. Hierzu ist es auch hilfreich, wenn die Anforderungen klein geschnitten sind und sich deren Umsetzung möglichst nicht über mehrere Iterationen erstreckt und dann sollten sie auch noch testbar sein. Durch das iterative Vorgehen besteht fortlaufender Integrations- und Testaufwand. Auch ein Thema wie "Testautomatisierung" hat im Agilen daher eine besondere Bedeutung. Testbare Anforderungen unterstützen diesen Prozess. Ein zentrales Konzept in der Welt der agilen Anforderungen ist das "Definition of Done". Über alle Planungsebenen soll teamübergreifend ein gemeinsames Verständnis bestehen, was getan werden muss, dass eine Anforderung, ein Feature, als fertig angesehen wird. Sozusagen ein agiles Abnahmekriterium, das gegebenenfalls auch Test und Dokumentationen miteinschließt. Im Agilen Manifest heißt es: "Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen." "Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden." Priorität genießt frühe, kontinuierliche Auslieferung an den Kunden. Funktionierende Produkte und Prozesse. Ein Kennzeichen von Agilität ist dieser besondere Umgang mit Änderungsanforderungen und mit Unsicherheit. Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation. Im agilen Umfeld werden Sie daher eher selten Lasten- und Pflichtenhefte finden. Anstelle eines umfassenden Dokuments tritt das "Backlog", in "Scrum" das "Product Backlog", als Themenspeicher für Ihre Anforderungen. Dem Themenspeicher hier gegenüber stehen die Planungsebenen von "Projekt", "Release" und "Iteration". Die Anforderungen aus dem Themenspeicher gehen in die einzelnen Planungsebenen ein und finden dort Berücksichtigung. Je nach Planungsebene bedarf es möglicherweise unterschiedlicher Detailierungsstufen für die Anforderungen. Auf Projekt- und Release-Ebene steht die Priorisierung der Anforderungen im Vordergrund. Was muss unbedingt in das nächste Release? Was sollte hinein, was könnte hinein? Was kann verschoben werden? Fragen, die vor allem Product Owner und Auftraggeber interessieren. Innerhalb der Iteration geht es eher um eine optimale Auslastung, eine vernünftige Verteilung der Last. Hier ist das Team gefragt. Soweit wollen wir es beim Thema "Anforderungsbeschreibung" belassen. In diesem Film haben Sie Lasten- und Pflichtenheft als die zentralen Anfroderungsdokumente im klassischen Projektmanagement gelernt. Im agilen Umfeld tritt stattdessen der zentrale Anforderungsspeicher, das Backlog in den Vordergrund. Agiles Projektmanagement ist insbesondere durch die Bejahung der laufenden Änderungen und Anpassungen gekennzeichnet.

Projektmanagement: Planung und Strukturierung

Erfahren Sie, was Planung im klassischen und agilen Sinn ist und wie Sie zu einer Planung von Aufgaben, Ablauf, Termine, Ressourcen, Kosten und Qualität kommen.

1 Std. 17 min (12 Videos)
Derzeit sind keine Feedbacks vorhanden...
 
Exklusiv für Abo-Kunden
Erscheinungsdatum:16.03.2017

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!