Bei der Einführung von Scrum für Softwareprojekte stellen die unterschiedlichen Projektkonstellationen, denen man als Scrum-Coach beim Kunden begegnet, die erste spannende Herausforderung dar. Scrum ist ein Projektmanagement-Framework, das immer (und immer wieder) auf die Situation und die Bedürfnisse des Projekts angepasst werden muss. Es gibt also nicht „den“ Scrum-Prozess, sondern nur projektindividuelle Vorgehensweisen, die sich alle aus demselben Werkzeugkasten bedienen. Aktuell befasse ich mich mit der Anpassung von Scrum für einen Proof of Concept.
In diesem Proof of Concept (PoC) soll ein Portalsystem auf seine Eignung als Informations- und Applikationsportal in der IT-Landschaft des Kunden auf Herz und Nieren untersucht werden. In einer vorgeschalteten strategischen Untersuchung hatten wir aus der Vielzahl am Markt erhältlicher Systeme einen Kandidaten ausgewählt. Da wir bei dieser Auswahl nicht alle Anforderungen bei allen Kandidaten im Detail untersuchen konnten, soll uns der PoC das tiefere Verständnis für das ausgewählte Portalsystem vermitteln.
Ergebnis des PoC-Projekts ist eine Empfehlung für oder gegen die Einführung dieses Systems. Das ist dann auch bereits der erste Unterschied zu klassischen Softwareentwicklungsprojekten, bei denen üblicherweise ein Softwaresystem entsteht. In agilen Projekten entsteht ein solches Softwaresystem iterativ, d.h. der Funktionsumfang wächst von Iteration zu Iteration. Jede Funktion, die beispielsweise in Form von User Stories und fachlichen Akzeptanzkriterien beschrieben ist, wird in einer Iteration vollständig umgesetzt. Im PoC hingegen müssen wir alle wesentlichen Anforderungen an ein Portalsystem mindestens angeschaut und bewertet, aber nicht zwingend vollständig umgesetzt haben. Unser Blick geht also eher in die Breite (Abdeckungsgrad) als in die Tiefe (Fertigungsqualität). Das ist der zweite Unterschied zu klassischen Softwareentwicklungsprojekten. Diese Unterschiede schlugen sich in unserer Definition of Done nieder, die wie folgt formuliert ist:
Eine User Story gilt als fertig (done), wenn sie
- so weit implementiert wurde, dass man das Lösungskonzept erkennen und bewerten kann; dazu gehört
- eine Dokumentation der notwendigen Konfigurationsschritte im Portalsystem
- das Einchecken aller Systemanpassungen und -erweiterungen im Versionskontrollsystem
- eine Dokumentation der Funktion aus Anwendersicht, entweder als Screencast oder Kurzanleitung
oder
- der Lösungsweg und mögliche Alternativen beschrieben und mit einer Größenangabe versehen wurden
Mit dieser Definition of Done sind wir in der Lage, den geforderten Abdeckungsgrad unserer Untersuchung zu erreichen, ohne uns in Details verlieren zu müssen. So ist beispielsweise nicht gefordert, das Design eines zu migrierenden Portals pixelgenau umzusetzen. Es genügt zu zeigen, dass das bestehende HTML-Gerüst kompatibel zum Layout-Mechanismus des Portalsystems ist.
Die zweite Option der Definition of Done werden wir vor allem für jene fachlichen Anforderungen nutzen, die in dem gegebenen Zeitrahmen des PoC nicht umgesetzt werden können. Damit ist klar, dass das gewählte Portalsystem diese Funktionalität nicht von Haus aus unterstützt. Dieses Vorgehen hat einen großen Vorteil für das Produktmanagement. Mit dem Wissen um den Preis für verschiedene Realisierungsalternativen einer fachlichen Funktion kann der Produktmanager den Auftraggeber viel besser beraten. Über das Verhältnis von Geschäftswert zum Preis einer Realisierungsalternative lässt sich die vernünftigste Alternative recht genau bestimmen.
Die anderen Artikel dieser Serie: