Das Vorgehensmodell im Projektmanagement – die RTD-Methode
Die RTD-Methode kombiniert die Vorgehensmodelle Rational Unified Prozess RUP, Scrum und Rapid Prototyping
Die Projektplanung erfolgt klassisch iterativ in den Phasen des Rational Unified Prozess (RUP). Die Phasen gliedern sich in Inception, Elaboration, Construction, Transition.
Innerhalb der Phasen werden die Ergebnistypen sukzessiv erarbeitet bzw. verfeinert.
Ergebnistypen
• Business Model
• Requirements
• Implementation
• Test
• Deployment
Die RTD-Methode ergänzt die herkömmlichen RUP Ergebnistypen.
UI-Prototypen (User Interfaces d.h. Eingabeoberflächen) werden innerhalb der Requirements (Anforderungen) erzeugt.
Die Implementierung (Implementation) erfolgt mittels Rapid Prototyping. Aus einem explorativen Prototypen werden in weiteren Schritten evolutionäre Prototypen entwickelt, bis das Endprodukt entstanden ist.
Explorativ (siehe Exploratives Prototyping) kennzeichnet hierbei die Eigenschaft des Prototypen, dass sich in den frühen Phasen das System komplett ändern kann und Entwicklungen verworfen werden müssen. In den späteren Phasen werden die Prototypen evolutionär überführt und bauen aufeinander auf (evolutionäres Prototyping). Die Prototypen nähern sich so dem Endprodukt.
Die Planung erfolgt in Iterationsschritten und Meilensteinen, die via Scrum organisiert sind.
Die Sprints werden mit einer Planung gestartet und mit Review und Retrospektive abgeschlossen.
Die Retrospektive folgt dem Deming Wheel
Der ProductOwner hat dabei den Gesamtplan, das Endziel (Endprodukt) und den Endzeitpunkt vor Augen.
Die Rollen in der RTD-Methode.
Als neue Rolle wird der Projektleiter hinzugenommen. Er hat Termin und Budget im Blick und hält äußere Einflüsse vom Team fern.
Der Projektleiter verantwortet ebenfalls die Stakeholder-Analyse, den ProjektStrukturPlan PSP, den Projektplan zur Kommunikation mit den Stakeholdern und das Risikomanagement. Er kann aktiv in die Ressourcenplanung eingreifen, indem er neue Teammitglieder anfordert / freistellt.
Eine weitere Rolle im Projekt ist der System-Architekt. Er kanalisiert das Wissen, ist für die Dokumentation und Einhaltung der Styleguides und ist für die Kommunikation der Architektur an alle Beteiligten verantwortlich.
Ebenfalls gibt es die Rolle des Testmanagers. Er übernimmt den Aufbau der Test- und Entwicklungsumgebung, sorgt für das Deployment, überwacht die Tests und die Fehlerbehebung. Er ist zuständig für die Pflege von Regressionstests und wiederverwendbaren Testdaten. Er ist ebenfalls verantwortlich für die Daten in der Entwicklungsumgebung.
Die Projektgröße entscheidet letztendlich, wie viele einzelne Personen die entsprechenden Rollen übernehmen. In einem kleinen Projekt können alle Rollen auf wenige Personen verteilt werden. Hierdurch können beispielsweise der ProductOwner und der ScrumMaster eine Person sein, was eine völlige Abkehr von einem Scrum-Prinzip ist.
SCRUM MASTER
Räumt Hindernisse für das Team aus
Wacht über Einhaltung der Prozesse und Rollen innerhalb eines Sprints
Weitere Aufgaben:
Moderiert das Daily Scrum und Retrospektive
PRODUCT OWNER
Erfüllung der fachlichen Ziele (auch des zeitlichen Rahmens)
Wissenstransfer der Fachlichkeit ins Projekt
Verantwortlich fürs Product Backlog
Weitere Aufgaben:
Kommuniziert die Produkt Anforderungen (als User Stories)
Definiert den Inhalt des Sprints anhand einer Vision
TEAM
Verantwortlich für Softwarequalität
Verantwortlich für vollumfängliche Umsetzung zugesagter Aufgaben
Verantwortlich für Umsetzung der Visionen des Product Owners
Weitere Aufgaben:
Technische Implementierung der User Stories
PROJECT LEAD
Erfüllung der Projektziele (Time, Money, Quality)
Projektplanung (ProjektStrukturPlan, Projektplan)
Projektcontrolling
Stakeholder-Analyse und Kommunikation
Risikomanagement
Weitere Aufgaben:
Repräsentat des Projekts (Fortschritt und Ergebnisse) gegenüber Stakeholdern
Oberster Feuerwehrmann
Hält äußere Einflüsse vom Projekt fern
TECHNICAL ARCHITEKT
Erfüllung der fachlichen Ziele (auch des zeitlichen Rahmens)
Verantwortet Vollständigkeit der fachlichen Ziele
Business Case Analysen (Wirtschaftlichkeit der Anforderungen)
Kommunikation der Projektziele nach außen
Weitere Aufgaben:
Abnahme der Projektergebnisse
Hat den Gesamtüberblick über die Fachlichkeit
SYSTEM ARCHITEKT
Architektur der Anwendung
Dokumentation der Architektur / Grundsätze
Kontrolle der Software-Styleguides
Verantwortet die Entwicklung, ist für die Wissenübertragung an die Entwickler zuständig
Weitere Aufgaben:
Hat den Gesamtüberblick über die Applikation
TEST MANAGER
Aufbau der Test- und Entwicklungsumgebung
Releasemanagement – Verantwortet das Deployment (auch in Produktion)
Überwacht die Tests und Fehlerbehandlung
Verantwortet die Erstellung von Regressionstests und wiederverwendbaren Testdaten
Verantwortet die Daten der Entwicklungsumgebung
Artefakte
Die RTD-Methode im Projekt
Kein Projekt wird nach Lehrbuch durchgeführt. Kein Projekt enthält alle Elemente der RTD-Methode.
Die RTD-Methode ist der Leitfaden, an dem sich der Projektleiter orientieren kann. Kein Element der RTD-Methode ist unverzichtbar. Am Ende zählt das erstellte Produkt. Das Ziel ist das Ziel und nicht der Weg dahin.
Die Ergebnisse des Projekts sind in absteigender Relevanz:
Die Software-Applikation
Dokumentation im SourceCode beispielsweise JavaDoc
Dokumentation der Architektur und der Abläufe mit UML und narrativen Dokumenten
Eine portable Entwicklungs- und Testumgebung