Stand: online seit 11/05

Von Olaf Stefan Göhrs, Büttelborn*

Transparenz und Agilität in Softwareentwicklungsprojekten

Die Rolle des Kunden in IT-Projekten

Die Erstellung von Individualsoftware ist heutzutage vielmehr Dienstleistung als produktive Tätigkeit. Umso erstaunlicher ist daher die Tatsache, dass die Rolle des Auftraggebers in der Softwareentwicklung jahrelang erheblich unterschätzt und vernachlässigt wurde. In klassischen Festpreisprojekten waren die Aufgaben des Kunden nach Erstellung des Lastenhefts und Abnahme des Pflichtenhefts sogar weitgehend beendet. Dies war (und ist) ein wichtiger Grund für das Scheitern zahlreicher Projekte.
Agile Methoden1 wie das "Extreme Programming" (XP) setzen auf eine permanente Präsenz des Kunden während des Entwicklungsprozesses. Der Kunde steht dabei dem Entwicklerteam als fachlicher Ansprechpartner zur Verfügung, durch Priorisierung von einzelnen Aufgaben kann er zudem den Entwicklungsprozess indirekt steuern.
Reichen aber derartige Maßnahmen aus, um den Erfolg eines Projekts sicherzustellen?
Der Auftraggeber ist durch diese Maßnahmen in das Projekt integriert. Er kann die fachlichen Anforderungen ändern und ihre Wichtigkeit bewerten. Gleichzeitig muss er damit aber auch einen Großteil der Verantwortung für das Ergebnis tragen. Agilität wird in der Regel durch Unterteilung einer großen Anforderung in kleinere überschaubare Teilaufgaben gewährleistet. Nicht das gesamte System wird spezifiziert, sondern einzelne Features, Story-Cards2 werden geschrieben und implementiert. Daher obliegt es dem Kunden den Überblick über das Gesamtergebnis zu behalten.
Neben den fachlichen muss der Kunde auch die Anforderungen an die Qualität, sowie die Rahmenbedingungen für Zeit und Budget beachten. Für ihn muss weniger die Entwicklung als der spätere Einsatz und die Wirtschaftlichkeit der Software im Blickpunkt stehen. Die Software muss die bisherigen Geschäftsprozesse verbessern und dadurch auch die Kosten für ihre Erstellung rechtfertigen.
Der Kunde darf zudem nicht in ein Abhängigkeitsverhältnis zum Auftragnehmer geraten. Damit spielen auch Gesichtspunkte wie Wartungsfreundlichkeit, Erweiterbarkeit oder auch die Möglichkeit, einzelne Teile der Software später zu ersetzen, eine hervorgehobene Rolle.
Um die notwendige Flexibilität in einem Softwareentwicklungsprojekt gewährleisten zu können, existieren zwei notwendige Forderungen:
1.
Transparenz - für alle Projektteilnehmer müssen die Prioritäten und die Zielrichtung des Projekts und einzelner Maßnahmen ersichtlich sein; für Entscheider muss zudem der Entwicklungsprozess bewertbar sein.
2.
Agilität - auf neue Anforderungen und Randbedingungen muss zeitnah reagiert werden.

Agilität

Die Flexibilität bei der Entwicklung kann auf Auftragnehmerseite durch die Verwendung agiler Methoden, wie z. B. Scrum, Extreme Programming oder das Feature Driven Development, sichergestellt werden. Diese stellen eine Reihe (zum Teil unterschiedlicher) Praktiken zur Verfügung, durch die auf veränderte Projektsituationen schnell und angemessen reagiert werden kann. Auch die als schwergewichtig und träge eingeschätzten Vorgehensmodelle, wie der RUP oder das V-Modell3, legen mittlerweile größeren Wert auf Agilität.
Mit der Einbindung des Kunden in das Projektgeschehen und insbesondere dessen Möglichkeit zur Einflussnahme wird aber auch implizit von der Auftraggeberseite Agilität gefordert.
Der Auftraggeber verfügt über kein endgültiges Pflichtenheft mehr, dass ihm die Fertigstellung der Software mit vorgegebener Funktionalität zu einem festen Budget und Zeitpunkt garantiert. Vielmehr wächst ein virtuelles Pflichtenheft mit dem Projektfortschritt. Der Auftraggeber muss die vollständige Spezifikation antizipieren, er muss jederzeit die Auswirkungen von Änderungen der Anforderungen, der Aufwandsschätzungen oder von anderen unvorhergesehenen Ereignissen und Entwicklungen auf das zu erreichende Ziel beurteilen können. Nur so wird ihm ein brauchbares Risikomanagement ermöglicht, und er kann durch neue Zielvorgaben, das Projekt in eine von ihm gewünschte Richtung lenken. Mit jeder neuen Information reift die Vorstellung vom Endergebnis, jedoch muss die bisherige Planung zugleich überdacht und gegebenenfalls korrigiert werden.

Transparenz

Auf beiden Auftragsseiten liegen komplexe Systeme mit eigenständiger Dynamik vor. Um die Erfolgswahrscheinlichkeit eines Projekts zu erhöhen, muss der Informationsfluss über die Schnittstelle beider Systeme optimiert werden: Transparenz ist ein wesentlicher Faktor für das Gelingen eines Softwareprojekts.
Voraussetzung für die Optimierung des Informationsflusses ist das Vorhandensein einer Schnittstelle. So trivial und selbstverständlich diese Forderung klingen mag, so scheint sie in der realen Welt dennoch nicht konsequent verwirklicht zu werden. In vielen Projekten existiert nach der Auftragserteilung keine wirkliche Schnittstelle mehr und somit kann auch keine Information fließen.
Um Transparenz erreichen zu können, muss demnach zunächst eine Schnittstelle definiert werden. Diese kann in eine Vertrags-, eine Entscheidungs- und eine Fachebene untergliedert werden. Auf der vertraglichen Ebene sollten gewöhnlich die anderen Ebenen festgehalten werden. Die Dynamik der unterschiedlichen Ebenen findet auf verschiedenen Zeitskalen statt: Die vertragliche Schnittstelle ist für einen Releasezyklus statisch, Entscheidungen sind parallel zu den Iterationszyklen der Entwicklung erforderlich, die fachlich-technische Kommunikation sollte annähernd kontinuierlich erfolgen.
Transparenz ist auf allen Ebenen erforderlich und muss beidseitig sein. Nur so kann gewährleistet werden, dass Probleme rechtzeitig erkannt und die notwendigen Maßnahmen ergriffen werden können.

Prinzipien und Praktiken

Damit Transparenz und Agilität zum Erfolg eines Projekts führen können, müssen drei Grundprinzipien beachtet werden:
1. Kooperationswillen - jeder muss versuchen mit dem Partner zusammen das gemeinsame Ziel zu erreichen. Alleingänge sind riskant, Verantwortung abschieben ist kontraproduktiv.
2. Vertrauen - in den Partner (Misstrauen hemmt den Informationsfluss) und in die eigenen Möglichkeiten (selbstbewusst die eigenen Standpunkte vertreten). 3. Kommunikation - offene Fragen müssen schnell geklärt, Probleme rechtzeitig publik gemacht werden.

Zahlreiche Praktiken können die Zusammenarbeit von Kunde und Entwickler erleichtern. Neben denjenigen, welche die gewählte, agile Entwicklungsmethode vorgibt, sind im folgenden einige aus Kundensicht wichtige Praktiken herausgestellt:



Fazit

Für den Erfolg von Softwareentwicklungsprojekten ist es von immer größerer Bedeutung, den Kunden in das Projekt zu integrieren5. Allerdings kann sowohl auf Kunden- wie auch auf Entwicklerseite die Einführung von größerer Transparenz und Agilität Probleme bereiten. Während es für den Kunden häufig ungewohnt ist, sich selbst um die Belange und Probleme der Softwareentwicklung kümmern zu müssen, ist bei Softwareentwicklern das Vorurteil weit verbreitet, dass der Kunde ohnehin keine Ahnung habe und den Projektfluss daher höchstens aufhalte.
Tatsächlich kann eine größere Schnittstelle zwischen Auftraggeber und Auftragnehmer auch dazu führen, dass ein Projekt sogar chaotischer wird. Dies geschieht insbesondere dann, wenn das beiderseitige Verhältnis nicht von Offenheit und Kooperation geprägt ist.
Gerade wenn die beteiligten Parteien noch nicht in diesem recht komplexen Zusammenspiel geübt sind, empfiehlt es sich, einen unabhängigen Moderator hinzuziehen. Alternativ oder zusätzlich kann ein Coach bei den ersten Schritten hinzugezogen werden. Das Risiko eines Scheiterns des Projekts wird dann durch Transparenz und Agilität erheblich minimiert.


* Dr. rer. nat. Olaf Stefan Göhrs ist Mitanbieter der Website www.jur-psv.de - juristisches Projekt Supervising; Herr Göhrs hat über Informationsflüsse in chaotischen Systemen promoviert und ist seither in unterschiedlichen Bereichen der Softwareentwicklung tätig.

1 Siehe dazu: Manifesto for Agile Software Development (http://agilemanifesto.org/).

2 Story-Cards im XP sind kurze Geschichten, die aus Kundensicht kleinere, fachliche Teilaspekte und Eigenschaften des zu entwickelnden Systems beschreiben.

3 Siehe dazu das V-Modell XT (http://www.v-modell-xt.de/).

4 Vgl.: Göhrs: Strategien zur Chaosvermeidung in IT-Projekten (http://www.ius-it.de/beitraege/Chaos_in_IT_Projekten.html).

5 Das Zielflussmanagement im juristischen Projekt-Supervising (http://www.jur-psv.de) bietet dafür einen Ansatz (vgl.: Engelhardt, Göhrs: Juristisches Projekt Supervising im Überblick [http://www.ius-it.de/beitraege/PSV_Einfuehrung.html]).