Das Eiserne Dreieck
Im klassischen Projektmanagement wird das Eiserne Dreieck als Verhältnis zwischen Zeit, Kosten und Umfang (bzw. Qualität) beschrieben: Ein Projekt erreicht nur dann seine Ziele, wenn diese drei Grössen im Gleichgewicht gehalten werden. Wer am Umfang festhält, muss mehr Zeit oder Geld investieren; wer Budget und Termine hart setzt, muss beim Umfang flexibel sein.
Das Problem bei der Entwicklung von Software: Der Projektumfang ist nie wirklich fix, sondern ändert sich aufgrund sich verändernder Anforderungen laufend und sprengt so den ursprünglichen Termin- und Kostenrahmen.
Komplexität von Softwareprojekten
Softwareentwicklung ist schwer planbar und lässt sich durch das Hinzufügen zusätzlicher Ressourcen nicht einfach skalieren. Einer der klassischen Aufsätze der Softwareentwicklung von Frederick P. Brooks («The Mythical Man-Month») zeigt, dass mehr Personal nicht zwangsläufig zu einer schnelleren Projektabwicklung führt. Im Gegenteil: Zusätzliche Mitarbeitende können den Fortschritt sogar verlangsamen, da der Kommunikationsaufwand steigt und Einarbeitung notwendig ist («Adding manpower to a late software project makes it later»). Brooks verdeutlicht, dass Zeit und Aufwand nicht beliebig skalierbar sind – der Projektzeitrahmen lässt sich also nicht einfach durch mehr Ressourcen verkürzen. Deshalb ist es sinnvoll, Zeit und Kosten zu fixieren und den Umfang flexibel zu halten.
Darum stellen wir das klassische Eiserne Dreieck für Softwareprojekte vom Kopf auf die Füsse: Nicht mehr der Umfang – und somit die Funktionen der zu entwickelnden Software – wird als fix gegeben betrachtet, sondern die Projektdauer sowie der Kostenrahmen. Der Umfang bleibt sehr bewusst flexibel.
Minimum Viable Product (MVP)
Statt zu Beginn alles perfekt planen zu wollen, beginnen wir bei Seantis mit einem Minimum Viable Product (MVP). Ein MVP ist die erste Entwicklungsstufe eines Produkts, die unter realistischen Bedingungen beim Kunden getestet werden kann; nur Funktionen, die zum eigentlichen Zweck unbedingt nötig sind, werden implementiert. Diese kleinste lieferbare Produktversion ermöglicht es, in kurzer Zeit Feedback zu sammeln und Ressourcen sparam einzusetzen.
Der Ansatz ist kostengünstig und risikoarm, solange das MVP noch das zugrunde liegende Geschäftsmodell bzw. den abzubildenden Kernprozess repräsentiert. Das MVP wird entwickelt, um eine IT-Implementierung oder Innovationen zu testen; durch den fokussierten Funktionsumfang sinkt das Risiko von Fehlentwicklungen und der Aufwand bleibt überschaubar.
Iterationen als Kostendach
Nachdem das MVP ausgeliefert und getestet worden ist, arbeiten wir in kurzen Entwicklungszyklen (Cycles) von typischerweise 10 Tagen Dauer. Dies entspricht den Prinzipien der Agilen Softwareentwicklung: Funktionierende Software regelmässig und möglichst in kurzen Zeitabständen auszuliefern. So schaffen wir früh messbaren Nutzen und können flexibel auf neue Anforderungen reagieren.
Jeder Cycle funktioniert dabei als Kostendach. Das Kostendach definiert eine Kostenobergrenze. Dieses Modell sichert primär die Auftraggeberseite ab. Wir kombinieren den Ansatz eines Kostendachs mit agilen Prinzipien: Für jeden Entwicklungszyklus vereinbaren wir ein Budget und eine feste Dauer. Der zu entwicklende Funktionsumfang wird zu Beginn jedes Zyklus gemeinsam mit dem Kunden definiert.
Was bis zum Zyklusende nicht abgeschlossen werden kann, wandert in den nächsten Zyklus – der Umfang bleibt flexibel und Anpassungen möglich, Zeit und Kosten aber sind begrenzt.
Funktionierende Software
Agile Methoden fordern, dass funktionierende Software das wichtigste Fortschrittsmass ist. In unseren Entwicklungszyklen stellen wir sicher, dass das Team am Ende jeder Iteration eine lauffähige Version liefert, die die vereinbarten Funktionen erweitert oder verbessert. Durch die kontinuierliche Integration und automatische Tests wird die Software nach jedem Zyklus produktiv einsetzbar. Fehler oder Qualitätsprobleme bleiben dank dieser kurzen Feedbackschleifen klein und sind schnell korrigierbar.
Transparenz und Qualität
Das Eiserne Dreieck zeigt, dass Projekte nur erfolgreich sind, wenn Zeit, Kosten und Umfang zusammenpassen. Seantis adressiert diese Herausforderung mit agiler Softwareentwicklung: Wir starten mit einem MVP, um das Risiko gering zu halten und schnell echten Nutzen zu schaffen. Anschliessend entwickeln wir die Software in kurzen Iterationen, die als Kostendach fungieren und unseren Kunden klare Budgets geben. Jede Iteration liefert funktionierende Software und ermöglicht Feedback, sodass Umfang und Prioritäten flexibel angepasst werden können. Mit diesem Ansatz schaffen wir Transparenz und Vertrauen: Unsere Kunden wissen, dass Zeit und Geld gut investiert sind, und unser Team kann sich auf das Wesentliche konzentrieren – die Unterstützung unserer Kunden mit qualitativ hochwertiger Software.
Literaturverzeichnis
- Robert C. Martin (2019): Clean Agile: Back to Basics
- Robert C. Martin (2017): Clean Architecture: A Craftsman's Guide to Software Structure and Design
- Robert C. Martin (2011): The Clean Coder: A Code of Conduct for Professional Programmers
- Sandro Mancuso (2014): The Software Craftsman: Professionalism, Pragmatism, Pride
- Fred Brooks (1995): The Mythical Man-Month: Essays on Software Engineering
- Fred Brooks (1986): No Silver Bullet — Essence and Accidents of Software Engineering
- Andrew Hunt, David Thomas (1999): The Pragmatic Programmer: From Journeyman to Master
- Kent Beck (2002): Test Driven Development: By Example
- Erich Gamma , Richard Helm (1994): Design Patterns. Elements of Reusable Object-Oriented Software
- Kent Beck und Cynthia Andres (2004): Extreme Programming Explained: Embrace Change
- Eric J. Evans (2003): Domain-Driven Design: Tackling Complexity in the Heart of Software
- Martin Fowler (1996): Analysis Patterns: Reusable Object Models
- Martin Fowler (2002): Patterns of Enterprise Application Architecture
- Martin Fowler (2018): Refactoring: Improving the Design of Existing Code