Geschäftsausrichtung und moderne Entwicklungsverfahren

Bereitstellung der Anforderungen

Ein solches „agiles“ Entwicklungsteam ist optimal aufgestellt, die Entwicklung eng am Geschäftsnutzen auszurichten. Dafür muss allerdings auch das Anforderungs- und Abnahmemanagement neu gestaltet werden: Die Anforderungen müssen in enger Zusammenarbeit von Fachexperten und Entwicklern in hinreichend kleine Brocken zerlegt werden. Diese Einzelschritte werden regelmäßig anhand ihres Geschäftnutzens, ihres Risikos und der technischen Abhängigkeiten priorisiert, vom Entwicklungsteam geschätzt und in die Entwicklung eingeschleust. In der Regel geschieht dies in mehreren Rhythmen. Viele Teams priorisieren einmal in der Woche für jede Iteration, alle vier Wochen, um die nächsten fachlichen Blöcke umzusetzen und nach jeder Auslieferung, um die mittel- und langfristige Planung an die neuen Gegebenheiten und Erkenntnisse anzupassen.

Regelmäßige Zerlegung und Priorisierung der Anforderung stellt gemeinsam mit der engen Kooperation zwischen Endanwendern, Fachexperten und Entwicklern sicher, dass stets nur die wichtigsten Aufgaben durchgeführt werden, also keine Ressourcen für weniger wichtige „goldene Henkel“ verbraucht werden, ehe die wichtigen Geschäftsprozesse hinreichend unterstützt werden. Das Ziel ist also nicht, ein perfektes System zu bauen, das alle Wünsche erfüllt, sondern ein System, das gut genug ist, um den Geschäftsprozess zu unterstützen. Dieser Pragmatismus kann die Entwicklungsaufwände gegenüber dem „Traumsystem“ erheblich senken, ohne den Nutzen zu gefährden, führt also zu einer deutlich wirtschaftlicheren Entwicklung.

Zudem kann das System durch dieses Vorgehen früher zumindest in Teilbereichen eingesetzt werden. Da Software erst mit dem produktiven Einsatz beginnt, Rendite für die Entwicklungsinvestitionen zu erwirtschaften, führt der frühe Produktionsstart zu einer besseren Gesamtbilanz über den gesamten Lebenszyklus.

Risiken werden minimiert

Die kurzen Inkremente haben noch einen anderen Effekt: Zu jedem Zeitpunkt steht lauffähige Software zur Verfügung, ein „Totalverlust“, wie er bei traditioneller Entwicklung immer wieder auftritt, ist damit praktisch ausgeschlossen: Schließlich kann jede Woche produktionsfähiger Code ausgeliefert werden. Da auch andere Risiken so früh wie möglich angegangen werden, minimieren sehr kurze Iterationen viele Projektrisiken. Selbst wenn sich im Laufe der Entwicklung ein unüberwindbares Hindernis auftut – ein Ereignis, das ich in meiner Laufbahn bei iterativem Vorgehen noch nicht erlebt habe – kann das Projekt früher abgebrochen werden, ist also der Schaden geringer, als wenn dieses Hindernis erst mit dem Abschluss des Projekts erkannt wird.
In traditionellen Verfahren stehen am Ende der Entwicklung die Integrations- und Testphase. Weil hier die Software das erste Mal vollständig laufen soll, entpuppen sich diese Phasen immer wieder als Krisenphasen, deren Dauer kaum schätzbar ist und die damit ein erhebliches Projektrisiko darstellen. Bei schnellen Iterationen finden Integration und Test jede Woche statt – oft sogar täglich, so dass man vor unangenehmen Überraschungen sicher ist.

Schnelle Iterationen technisch beherrschen

Es reicht allerdings nicht aus, einfach nur in schnellen Iterationen zu entwickeln: Naiv angewendet führt dieses Vorgehen dazu, dass die Qualität der Software rapide schlechter wird und Änderungen bald nicht mehr sicher möglich sind, ohne die bestehende Funktionalität zu gefährden. In den letzten zehn Jahren sind unter Schlagwörtern wie „testgetriebene Entwicklung“ und „Refaktorieren“ technische Verfahren etabliert worden, mit denen die Codequalität und die Änderbarkeit des Codes langfristig sichergestellt werden kann. Eine wichtige Rolle spielt dabei die Automatisierung von Tests auf allen Ebenen, um das gesamte System immer wieder testen zu können. Obwohl die meisten Werkzeuge dafür quelloffen verfügbar sind, bedeuten diese Techniken aber grundlegende Änderungen im Arbeitsablauf der Entwickler. Diese Änderungen müssen erlernt werden, es dauert typischerweise sechs bis zwölf Monate, bis ein Team diese Techniken sicher beherrscht.

Agile Entwicklung zur Ausrichtung auf den Geschäftsnutzen

Die Verfahren zur Entwicklung von Individualsoftware müssen also bei konsequenter Ausrichtung auf das Geschäft stark angepasst werden. Die dafür notwendigen Techniken sind unter dem Schlagwort „Agile Entwicklung“ bekannt. Sie helfen, unnötige Entwicklungskosten und -risiken zu vermeiden und gerade strategische Aufgaben schneller und flexibler anzugehen, als dies mit traditionellen Verfahren möglich ist. Die Einführungszeit für solche Verfahren beträgt zwischen sechs und zwölf Monaten, je nach den technischen und personellen Voraussetzungen. Dazu kommen auch noch Anpassungen im Controlling und bei Leistungsanreizen, die oft auf traditionelle Entwicklung ausgelegt sind.

Jens Coldewey (jens_coldewey@acm.org) ist freier Berater in München. Er unterstützt Organisationen bei der Einführung agilen Projektmanagements und der zugehörigen Entwicklungstechniken. Herr Coldewey ist Mitglied der Agile Project Management Practice des Cutter Consortiums, Gründungsmitglied der Agile Alliance Non-Profit Organization und Mitglied im Bundesverband Deutscher Unternehmensberater (BDU) e.V.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.