Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Projektleiter, Business Product Owner und Technischer Product Owner beschrieben.

...

  • Die Anforderungen waren zu mehr als 80% ausgearbeitet gewesen
  • Die wichtigsten Architekturentscheide, Frameworkdefinitionen und Businessprozesse waren bekannt
  • Alle Anforderungen waren klar (in Use Cases) beschrieben und konnten einzeln geschätzt werden. Dies konnte erreicht werden, da ein Anforderungsprojekt vorgeschalten wurde in dem die wichtigsten Eckpunkte bereits festgelegt waren.
  • Das eingesetzte Entwickler Team beherrschte die komplette Umgebung und hatte vorher schon in dem Kundenumfeld gearbeitet
  • Zwischen Team und Kunde wurden von Beginn an saubere Schnittstellen (technischer Product Owner und Bussines Product Owner) festgelegt
    Der technische Product Owner war ein Requirement Engineer des Kunden. Diese Person hatte enge Verbindungen zu den Architekten, der internen Entwicklung und dem Betrieb.
    Der Business Product Owner war eine Person aus dem Fachbereich. Er vertrat die Anforderungen der Systemnutzer.
    Beide Product Owner definiterten gemeinsam die Priorisierung der Umsetzung. Der Gesamtprojektleiter war hier mit anwesend und konnte seine Punkte mit aufbringen. Der Scrum Master moderierte diese Sitzungen. Der Business Product Owner wurde als "Master" Product Owner definiert. Falls es zu einem Konflikt bei der Priorisierung des Product Backlogs gekommen ist, hat er die Entscheidung gefällt was als nächstes durchgeführt werden sollte.
  • Die Aufgaben des Projektleiters wurde in diesem Teil der Entwicklung auf die Product Owner, das Team und den Scrum Master aufgeteilt. Im Gesamtprojekt wurde ein Wasserfall-Modell eingesetzt. Der Projektleiter definierte die groben Schritte der Entwicklung, jede Iteration erhielt einen sinnvollen Namen der auch im Projektplan dargestellt wurde. Beispiele: PoC, Setup Identity Management, Setup Workflow Management...
    Es wurden im Gesamtprojektplan die Use Cases eingetragen und pro Iteration wurden die tatsächlich realisierten Use Cases festgelegt. So entstand am Anfang Projektplan-Änderung von ca. 40%. Nach drei Iterationen waren es unter 10% und somit überschaubar.
  • Eine enge Zusammenarbeit zwischen dem Kunden und dem Dienstleister wurde von Beginn an angestrebt. Bei Fragen und Änderungen wurde gezielt über Lösungen gesprochen.
  • Beide Parteien sahen den Festpreis nur als eine Fixierung der Projektvariablen (Preis, Qualität, Funktion, Zeit, Team) an. Weiter wurde auf die wichtigsten Geschäftsprozesse Wert gelegt und damit der Festpreis definiert

...