Im vorhergehenden Teil dieser Artikelserie habe ich Ihnen gezeigt wie schwer es ist ein Softwareprojekt anhand des ökonomischen Prinzips auszurichten und welche Schwierigkeiten bezüglich Wirtschaftlichkeit, Termintreue und Kundenzufriedenheit sich daraus ergeben. In diesem Artikel möchte ich Ihnen eine mögliche Lösungsvariante aufzeigen.

 
Einleitung

Zusammenfassend aus dem vorhergehenden Artikel haben wir folgende Situation vorliegen. In unserem Projekt wurden vor Projektstart die Features mit dem Kunden ausgehandelt und Liefertermin und Preis vereinbart. Somit sind Kosten und Nutzen exakt definiert. Solch ein Projekt lässt sich dadurch keiner Ausprägung des ökonomischen Konzeptes zuordnen und ist aus den im vorigen Artikel genannten Gründen von Beginn an zum Scheitern verurteilt. Unter „Scheitern“ verstehe ich nicht nur das Fehlschlagen des Projektes, sondern auch eine Kosten- und Zeitüberschreitung.

 
Features mit Tiefe

Die Features und der Liefertermin stehen fest. Aber Features sind meist nicht im Detail spezifiziert. Und genau hier findet sich ein Punkt an dem angesetzt werden kann. Ein Feature sollte nicht nur in seiner Breite, also seinen Zweck, sondern auch in seiner Tiefe betrachtet werden. Jedes Feature sollte dahingehend untersucht werden, wie dieses abgestuft umgesetzt werden könnte. Dabei empfehle ich eine projektweit allgemeingültige Abstufungstiefe vorzugeben. Wenn nötig können die Abstufungstiefen aber auch bedarfsgerecht je Feature festgelegt werden.

Betrachten wir dazu ein kleines Beispiel. Es wird projektweit eine Tiefe von drei Stufen vorgegeben. Zusätzlich sollten Einteilungskriterien definiert werden, welche die Zuordnung zu den Stufen erleichtern. Diese Kriterien sollten dabei je nach Art des Features festgelegt werden. Die nachfolgende Tabelle zeigt dies beispielhaft für ein GUI Features und Features auf Ebene der Geschäftslogik.

Diese Einteilung möchte ich anhand eines konkreten Beispiels verdeutlichen. Es sollen Messwerte visualisiert werden. Aus dieser Anforderung lässt sich ein GUI Feature ableiten – die Visualisierung – und ein  Feature für die Geschäftslogik – die Berechnung der Messwerte. Die nachfolgende Tabelle zeigt wie die entsprechende Tiefenplanung für diese Anwendungsfälle aussehen kann.

Tiefenbasiertes Maximalprinzip

Wie gezeigt lassen sich Features abgestuft umsetzen. Die daraus resultierenden Grundgedanken zur Tiefenplanung möchte ich nachfolgend kurz auflisten:

• Features und Liefertermin stehen fest
• Features sind nicht im Detail spezifiziert
• Features können mittels Tiefenplanung weiter aufgeteilt werden
• Der Kunde möchte das alle Features umgesetzt werden
• Die minimaltiefe der Umsetzung jedes Features lässt sich anhand der Spezifikationen definieren, selbst wenn diese nicht alle Details klären
• Das Kundenfeedback nach jedem Iterationsschritt kann die Minimaltiefe eines Features verändern (meist wird diese dabei angehoben)
• Ob bei der Umsetzung eines Features über die vorgegebene Minimaltiefe hinausgegangen wird entscheidet der Projektleiter
• Ein Hinausgehen über die Minimaltiefe hat keinen direkten wirtschaftlichen Nutzen (das Projektergebnis lässt sich dadurch meistens nicht teurer verkaufen) kann aber indirekten wirtschaftlichen Nutzen bringen (Prestige durch Mehrwert, eventuell ein Folgeauftrag).

 
Durch die Tiefenplanung ist es nun möglich das Maximalprinzip als Ausprägung des ökonomischen Prinzips anzuwenden. Bis zum Liefertermin, also mit gegebenem Aufwand, soll das Maximum an Feature-Tiefe implementiert werden.

 
Zusammenfassend lässt sich das tiefenbasiertes Maximalprinzip wie folgt definieren:

Der Liefertermin eines Projektes und damit die einsetzbaren Mittel sind vorgegeben. Im Rahmen dieser Mittel soll ein Maximum an Nutzen erzielt werden. Dieses Nutzenmaximum entsteht durch die Überschreitung der geforderten Umsetzungstiefe von Features, nachdem alle Features in der geforderten Umsetzungstiefe realisiert wurden.

 
Umsetzung in der Praxis

In der ersten Projektphase (ca. im ersten Drittel) sollten Features nur in der kleinsten Tiefe umgesetzt werden. Dadurch können dem Kunden nach kurzer Projektlaufzeit und in kurzen Abständen Prototypen der Software vorgelegt werden. Dies führt zu einem frühzeitigen Feedback des Kunden. Dadurch lässt sich bereits in einer frühen Projektphase erkennen ob irgendwo in die falsche Richtung gesteuert wird. Eine dementsprechende Anpassung oder Erweiterung der Softwarespezifikationen führt in dieser Phase zu einem vertretbaren Mehraufwand.

Eine Beschränkung auf die erste Feature-Tiefenstufe hat einen weiteren Vorteil. Ohne diese Beschränkung stürzen sich die Entwickler meist auf Dinge die ihnen bekannt sind oder die sie gern umsetzen möchten. Sie implementieren diese Features somit als erstes und das zumeist in der höchsten Detailtiefe.

In der zweiten Projektphase sollten alle Features auf die vom Kunden gewünschte Tiefe angehoben werden. Auch hier bietet eine iterative Programmierung den Vorteil der ständigen Präsentation von Zwischenergebnissen verbunden mit Feedbacks des Kunden. Der Abschluss der zweiten Projektphase sollte nach ca. 80% der Projektzeit geplant werden und damit einige Zeit vor dem geforderten Liefertermin. Alle ursprünglich geforderten Features sollten nach dieser Zeit in der geforderten Tiefe vorliegen.

Warum nach 80% der Projektzeit? Weil es immer Änderungen, Detaillierungen und Erweiterungen der Spezifikationen geben wird. Somit muss etwas Puffer eingeplant werden um diesen Anpassungen gerecht zu werden.

In der dritten Phase, also ab 80% der Zeit bis zum Liefertermin sollten diese geänderten oder neuen Spezifikationen umgesetzt werden. Ist dies erledigt bleibt mit etwas Glück noch Zeit übrig. Diese sollte genutzt werden um ausgewählte Features über die geforderte Tiefe hinaus umzusetzen. Und darin liegt meist auch der Anreiz für die Entwickler. Wenn die Entwickler in den ersten Projektphasen qualitativ und quantitativ hochwertig arbeiten und somit die 20% Projektzeit am Ende gewinnen, dann können sie ohne Zeitdruck die Softwareentwicklung abschliessen und darüber hinaus noch ein paar nette Details implementieren, also bei einigen Features in die Tiefe gehen. Dies ist meist ein hoher Anreiz für engagierte Entwickler und wirkt sich daher positiv auf das Projekt aus.

 
Zusatzaufwand durch das mehrfache Umsetzen eines Features

Eine berechtigte Frage ist, ob ein Vorgehen nach dem tiefenbasierten Maximalprinzip zu einem Mehraufwand führt. Denn schliesslich wird jedes Feature nicht nur einmalig sondern entsprechend der gewählten Tiefe zum Beispiel dreifach umgesetzt.

Ich kann Sie aber beruhigen. Dadurch entsteht gar kein oder nur geringer Aufwand. Die Features der unterschiedlichen Tiefen bauen meist aufeinander auf. Das obige Beispiel der Berechnung der Messwerte in der Geschäftslogik zeigt dies gut. Es entsteht kein Zusatzaufwand da die Tiefen nur unterschiedliche Entwicklungsmeilensteine des Features repräsentieren. Im Beispiel der Visualisierung in der GUI entsteht ein minimaler Zusatzaufwand. Die Tabelle zur textuellen Ausgabe der Messwerte wird später durch eine grafische Darstellung ersetzt. Der Zusatzaufwand ist aber sehr gering und wird im Allgemeinen durch das damit ermöglichte frühzeitige Feedback des Kunden mehr als kompensiert.

 
Fazit

Das vorgestellte Prinzip lässt sich ohne Umstellung der Geschäftsprozesse des Unternehmens einsetzen. Es ist mit sehr wenig Zusatzaufwand realisierbar, der sich darüber hinaus durch die frühzeitige Feedbackmöglichkeiten mehr als amortisieren sollte. Ein Vorgehen nach dem tiefenbasierten Maximalprinzip sorgt dafür, dass keine unnötigen Implementierungen erfolgen. Es ist darauf ausgerichtet mit gegebenen Mitteln den grösstmöglichen Kundennutzen zu erzielen.