Stand: online seit 11/05

Von Olaf Stefan Göhrs, Büttelborn*
Strategien zur Chaosvermeidung in IT-Projekten

Chaos in der Software-Entwicklung?

 "Chaotisch" ist, spätestens seit den Reports der Standish Group, das vermutlich meistverwendete Attribut bei der Beschreibung fehlgeschlagener IT-Projekte. "Chaos" wird jedoch im Zusammenhang von IT-Projekten in der Regel sehr unspezifisch verwendet und beschreibt dabei keine wirklich greifbare Eigenschaft des Projekts, sondern eher (dem ursprünglichen griechischen Wort entsprechend) eine irgendwie geartete Unordnung, einem allgemeinen Durcheinander.
Der Begriff des "Chaos" wurde aber in den letzten Jahrzehnten erheblich konkretisiert. Die neu entstandene Disziplin der Chaosforschung untersuchte dabei insbesondere niederdimensionale, deterministische dynamische Systeme. In diesen herrscht nicht der reine Zufall, sondern es existieren identifizierbare Ordnungsstrukturen (wie z.B. seltsame Attraktoren). Obwohl diese Systeme deterministisch sind, bleiben sie großteils unvorhersagbar: Kleine Abweichungen in den Ausgangsbedingungen können zu extrem unterschiedlichen Ergebnissen führen; ein Verhalten das durch den sogenannten "Schmetterlingseffekt" beschrieben wird.
Derartige chaotische Systeme besitzen jedoch ein Gerüst aus periodischen Bahnen, also geschlossenen Trajektorien im Zustandsraum. Diese sind zwar instabil und von der Wahrscheinlichkeit "Null", können aber durch geeignete Maßnahmen stabilisiert werden, d.h. das Chaos kann kontrolliert werden.

Können die Ergebnisse der Chaostheorie auch auf IT-Projekte übertragen werden und wenn ja, können sie helfen, Chaos zu kontrollieren oder gar zu vermeiden?

Eine quantitative Chaostheorie hierzu existiert nicht; jedoch können qualitativ zahlreiche Analogien zwischen deterministischem Chaos und demjenigen in IT-Projekten gefunden werden:
In aller Regel ist der Verlauf eines Softwareentwicklungsprojekts im Detail nicht vorhersagbar. Anhand von den Ausgangsbedingungen, wie Anforderungsanalysen, Festlegung der zur Verfügung stehenden Manpower und Bestimmung der Entwicklungswerkzeuge, kann ein Projekt lediglich geplant werden, der tatsächliche Verlauf wird aber mit Sicherheit von der ursprünglichen Planung abweichen. Je besser die Anforderungen bekannt sind, desto größer ist die Wahrscheinlichkeit, dass ein Projektplan eingehalten werden kann. Abweichungen von diesem Plan wird es aber immer geben. Je chaotischer der gesamte Entwicklungsprozess ist, desto stärker werden auch diese Abweichungen sein.
Ähnlich wie die periodischen Bahnen können auch viele Wege zum Erfolg eines Projekts führen, allerdings können noch weitaus mehr Wege diesen Erfolg gefährden. Es ist aber leider fast unmöglich, einen als richtig identifizierten Weg von Anfang bis Ende ohne Korrekturen einzuhalten.
Welche Möglichkeiten existieren nun um ein chaotisches System zu kontrollieren? Zunächst kann versucht werden, das Gesamtsystem (sei es durch Reduktion der Freiheitsgrade oder auch durch einfache Parameteränderung) weniger chaotisch zu gestalten. Hierzu können (im Hinblick auf IT-Projekte) fest definierte Softwareentwicklungsprozesse und Reifegradmodelle dienlich sein.
Eine weitere (zusätzliche) Möglichkeit besteht darin, das Chaos zu kontrollieren, also vorhersagbare Bahnen zu stabilisieren. Hierzu muss flexibel auf Abweichungen von den bisherigen Planungen reagiert werden. Die derzeit recht beliebten "agilen Methoden" bieten einen geeigneten Ansatzpunkt für eine derartige "Chaos-Kontrolle".
Das Zielflussmanagement beschäftigt sich abschließend mit der Fragestellung, wie ein IT-Projekt von außen berechenbar wird. D.h. wie ein Kunde auf eine stabile Entwicklung Einfluss nehmen kann.

 Die Chaosreduktion: Prozess- und Reifegradmodelle

Dynamische Systeme sind unterschiedlich chaotisch. Als Maß für das Chaos haben sich verschiedene Größen, wie Kolmogorov-Entropie oder Lyapunov-Exponenten, etabliert. Diese geben im Wesentlichen an, wieviel Information durschnittlich im Laufe der Zeit verloren geht, bzw. wie weit sich ein tatsächlicher Verlauf bei leicht geänderten Ausgangsbedingungen im Mittel von dem geplanten entfernt. Unterliegt das chaotische System stochastischen Störfaktoren, wird die Vorhersagbarkeit zusätzlich reduziert. Daher ist die erste und vielleicht wichtigste Maßnahme, um das Auftreten chaotischen Verhaltens zu vermindern, die Stabilisierung des Gesamtsystems und dabei insbesondere die Eliminierung von "hausgemachten" Störmechanismen.
Stochastisches Chaos wird in IT-Projekten häufig durch das Fehlen eines verbindlichen Regelwerks begünstigt. Prozesse laufen unkoordiniert ohne gemeinsame Linie parallel zueinander ab: Interne Abhängigkeiten werden übersehen, einige essentielle Prozesse werden fast völlig vernachlässigt.

Reifegradmodelle wie CMMI oder SPICE geben Richtlinien, wie ein sinnvolles Regelwerk aussehen sollte. Dabei stellen die Reifegrade ein Maß für die Unordnung des Systems, sprich der IT-Organisation, dar. Je niedriger der Reifegrad, desto chaotischer das System.
CMMI unterscheidet verschiedene Prozessgebiete, denen Ziele und Praktiken zugeordnet sind. Die verschiedenen Reifegrade beinhalten unterschiedliche Prozessgebiete. Ein Reifegrad ist dann erreicht, wenn alle Ziele dieser Stufe erfüllt sind.
Die entsprechenden Praktiken können als die Koordinaten eines Zustandsraums betrachtet werden. Damit stellen die Prozessgebiete einzelne Subräume des Systems dar. Einige der Praktiken gelten für alle Prozessgebiete ("generische Praktiken") und sind somit Bestandteil jeden Prozessgebiets. Die Subräume werden also von den generischen und den für sie "spezifischen" Praktiken aufgespannt.
Mit diesen Festsetzungen können nun weitere Analogien zu chaotischen Systemen gezogen werden: - Wird eine Praktik ignoriert, so entspricht dies einer zufälligen Bewegung, also einem Rauschen bezüglich einer Achse. Die Unordnung des Systems wächst (sofern diese Praktik direkte Auswirkungen auf eines der Ziele hat).
- Werden die Praktiken unabhängig voneinander geplant und durchgeführt, wird die Vorhersagbarkeit des Systems vermindert.

Reifegradmodelle bieten den Rahmen für eine Reduzierung des Chaos, stellen jedoch keine konkreten Maßnahmen dazu bereit. Derartige Vorgehensweisen werden durch Prozessmodelle, wie das Wasserfallmodell, das V-Modell oder den Rational Unified Process, definiert. CMMI fordert die Nutzung eines geeigneten Prozessmodells, schreibt jedoch kein konkretes Modell vor.
Eine IT-Organisation kann aber erst dann stabile Strukturen hervorbringen, wenn ein solches Lebenszyklus-Modell nicht nur existiert, sondern auch gelebt wird.
Insbesondere Modelle mit iterativem Ansatz (wie das Spiralmodell oder der RUP) weisen eine weitere Analogie zu chaotisch dynamischen Systemen auf: Die Iterationszyklen. Diese können mit den periodischen Bahnen innerhalb eines chaotischen Systems verglichen werden. Kurze Iterationszyklen lassen sich dabei leichter stabilisieren als lange, eine Eigenschaft, die sich agile Methoden zunutze machen.

 Die Chaoskontrolle: Agile Software-Entwicklung

 In den letzten Jahren wurden agile Methoden1, allen voran das Extreme Programming (XP)2, in der Softwareentwicklung immer populärer. Diese leichtgewichtigen Prozesse schienen besser geeignete, das in der Softwareentwicklung herrschende Chaos zu kontrollieren3. Die bis dahin etablierten Modelle (wie das V-Modell des Bundes oder der Rational Unified Process) hatten sich in vielen Fällen als zu träge erwiesen, um schnell genug auf veränderte Anforderungen einzugehen.
Dieses Problem entsteht dadurch, dass die Softwareentwicklung kein autonomes System ist. Während des gesamten Projektverlaufs muss mit externen Einflüssen gerechnet werden, die wesentliche Voraussetzungen und Randbedingungen des Systems verändern können. Insbesondere betrifft dies die Erwartungen an die zu erstellende Software. Diese bleiben in den seltensten Fällen nach der Erstellung von Lasten- und Pflichtenheften konstant. Auch andere Randbedingungen, wie z.B. der Wegfall eines Entwicklers, können ein Projekt erheblich beeinflussen.
Es ist somit auch bei einer hervorragenden Organisation kaum möglich, langfristig zu planen; das Chaos ist systemimmanent. Der Ansatz agiler Methoden ist daher weniger das Gesamtsystem zu stabilisieren, sondern eher innerhalb der Unordnung für kurze Perioden vorhersagbaren Bahnen zu folgen. Dabei gilt die Regel: Viele Wege führen zum Ziel.
In einem chaotischen System kann ein geplanter Zyklus stabilisiert werden, indem nach kurzen überprüfungszeiträumen die Abweichung von dem Plan bestimmt wird. Anhand der Messung dieser Abweichung ist dann möglich, geeignete Korrekturmaßnahmen durchzuführen, um wieder den Plan zu erreichen. Durch erhebliche Störungen kann jedoch der Ist-Zustand des Systems soweit von dem geplanten Zyklus abweichen, dass der Aufwand, bzw. die notwendige Energie, um diesen Plan wieder zu erreichen, nicht zu rechtfertigen ist. Daher sind drei Punkte bei einer derartigen Chaoskontrolle zu beachten:
Wesentlich ist dabei das schnelle Reagieren, denn je länger eine Fehlentwicklung zugelassen wird, desto größer werden die Abweichungen vom geplanten Ziel. Agile Methoden basieren daher gerade, wie der Name schon sagt, auf der Idee des behenden und flexiblen Reagierens. Kurze Iterationen und Releasezyklen ersetzen langfristige Planungen.
Eine Grundvoraussetzung bei allen leichtgewichtigen Prozessen sind daher auch Komponententests, die ein frühzeitiges Erkennen interner Probleme ermöglichen. Techniken wie die Retrospektive helfen, aus dem bisherigen Projektverlauf zu lernen und somit falsche Korrekturmaßnahmen zu vermeiden. Welche Maßnahmen ergriffen werden, hängt von dem Problem und dem konkreten Projektzustand ab. Die verschiedenen agilen Methoden stellen ein (durchaus unterschiedliches) Repertoire zur Verfügung, das ein zeitnahes und effektives Handeln erlaubt. Sie setzen weniger auf langfristige Planung des Prozesses, die in einem chaotischen System ohnehin kaum möglich ist, sondern vertrauen eher auf die Selbstorganisation der Projektteams.
Damit dies überhaupt möglich ist, kommt dem Auftraggeber und Anwender der zu entwickelnden Software eine aktivere Rolle zu. Reaktionen auf äußere Einflüsse, wie z.B. veränderte Anforderungen, bedürfen des frühen Feedbacks vom Kunden.

Gekoppelte Systeme: Zielflussmanagement

 Das Zielflussmanagement4 kann als eine Ergänzung der agilen Methoden aus Auftraggebersicht gesehen werden.
Agile Methoden versuchen den Kunden und dabei insbesondere den Anwender in das Entwicklungsprojekt mit einzubinden. So ist eine wesentliche Praktik des XP der "On-Site Customer"; also die direkte Zusammenarbeit von Anwender und Entwickler. Das Zielflussmanagement sieht den Kunden noch direkter als die treibende Kraft des Projekts.
Das eigentliche Ziel eines Projekts ist die Erstellung einer Software mit den gewünschten Eigenschaften und der erwarteten Qualität innerhalb eines gewissen Zeit- und Budgetrahmens. Diese vier Größen spannen einen Zielraum auf; am Ende des Projekts sollen Ergebnis und Ziel übereinstimmen. In klassischen Festpreisprojekten wird das Ziel nach Erstellung von Lasten- und Pflichtenheft als eindeutig bestimmter Punkt des Zielraums angenommen, die Entwicklung sorgt für ein kontinuierliche Annäherung an diesen Punkt. Die Aufgabe des Auftraggebers ist zum eigentlichen Start des Projekts schon weitgehend erledigt5.
Dass ein fest definiertes, über den Projektverlauf konstant bleibendes Ziel nur in den seltensten Fällen existiert, wurde schon im letzten Abschnitt angesprochen. Die Aufgabe des Zielflussmanagements besteht daher darin, das Projekt von Auftraggeberseite her derart zu steuern, dass das abschließende Ergebnis den Rahmenvorgaben bzgl. Zeit, Budget, Produkt und Qualität bestmöglich entspricht. Die letztgenannten Zielgrößen stellen für den Auftraggeber zugleich die Observablen des Softwareentwicklungssystems dar. Anhand geeigneter Messungen dieser Größen und der eigenen Zielvorstellung muss er während des laufenden Projekts, in Absprache mit dem Auftragnehmer, neue Rahmenvorgaben definieren können.
Da der Auftraggeber nur eine beschränkte Sicht auf das eigentliche chaotische System der Softwareentwicklung hat, stellt sich das Chaos für ihn ganz anders dar als für den Auftragnehmer oder gar den Entwickler. Für den letzteren ist das Chaos greifbar: Jedes Problem hat eine eindeutige Ursache, eine Vielzahl von Details können den Entwicklungsfluss behindern6. Es ist daher leicht möglich, dass der Entwicklungsprozess selbst die Verfolgung des Projektziels in den Hintergrund treten lässt.
Aus Auftraggebersicht stellt sich das System völlig anders dar. Das konkrete Chaos findet für ihn in einer Art Blackbox statt. In der Regel kann er den Projektverlauf nur anhand von Zwischenergebnissen, also einzelnen Punkten im Zielsystem verfolgen. Im ungünstigsten Fall erhält er nur ein Endergebnis, das seinen Vorstellungen nicht entspricht; d.h. das Projekt ist gescheitert. Agile Methoden erhöhen mittels unterschiedlicher Verfahren die Transparenz der Entwicklung, der Kunde erhält deutlich häufiger Rückmeldungen über den Projektstand. Durch das Planungsspiel7 in XP erhält der Kunde sogar eine direkte Eingriffsmöglichkeit zur Steuerung der Entwicklung.
Dennoch bleibt auch hier die Rolle des Kunden unbefriedigend. Dies liegt vor allem daran, dass die Rolle des Kunden als solchen gar nicht existiert. Vielmehr liegt auf Auftraggeberseite regelmäßig ebenfalls ein recht komplexes System vor. Der "Kunde" kann also aus ein oder mehreren Anwendergruppen, einem Abteilungsleiter, einem Projektleiter, IT-Administrator und vielen weiteren Personen mehr bestehen, welche u.U. alle unterschiedliche Anforderungen an die zu entwickelnde Software stellen. Dir grundlegenden Anforderungen sind jedoch, dass durch die Softwareentwicklung die eigenen Geschäftsprozesse verbessert werden und dass dieser Nutzen die Ausgaben für die Entwicklung deutlich überwiegt.
Es liegen also bei einem Softwareerstellungsprojekt zwei weitgehend voneinander unabhängige Systeme mit unterschiedlichen Zielsetzungen vor. Die Kopplung dieser Systeme kann, wie gesehen, auf unterschiedliche Weise geschehen: Durch einen einfachen Auftrag, durch ein Planungsspiel oder auch durch die Projektleitung seitens des Auftraggebers bei Auftragsprojekten. Wie auch immer diese Kopplung geartet sein mag, es besteht immer das Risiko, dass durch einen äußeren Antrieb ein instabiles, ein metastabiles oder sogar ein weitgehend stabiles System chaotisch wird. Aufgabe des Zielflussmanagements ist, dieses Umkippen ins Chaos zu verhindern. Durch geeignete Maßnahmen können die Systeme über Synchronisationseffekte stabilisiert werden.
Grundvoraussetzung für eine Stabilisierung ist eine funktionierende Schnittstelle zwischen den beiden Systemen. Die dadurch definierte Kopplung darf dabei nicht einseitig sein, da ansonsten eine Anpassung der treibenden Kraft, also des Auftraggeber-Systems, nicht erfolgen kann. Zugleich muss der Informationsfluss kontinuierlich sein, Reaktionen müssen zeitnah erfolgen. Somit sind Transparenz und Agilität die Grundpfeiler des Zielflussmanagements. Transparenz muss in erster Linie vom Auftragnehmer gewährleistet werden, Agilität ist auf beiden Seiten vonnöten.
Ein erster wichtiger Schritt im Zielflussmanagement ist eine flexible Vertragsgestaltung, oder auch ein "agiles Vertragsmanagement": Verträge müssen an das spezifische Projekt und dessen Ausgangvoraussetzungen angepasst sein und sie müssen Freiräume bieten, notwendige Veränderungen während des Projektverlaufs vornehmen zu können.
Durch ein regelmäßiges Reporting wird der Projektverlauf für den Auftraggeber transparenter. Ein "On-Site Customer" ist weiterhin wünschenswert, aber nicht zwingend erforderlich. Existiert kein Kunde vor Ort, müssen auf andere Weise fachliche Fragen für den Auftragnehmer einsichtig beantwortet werden. Der Auftraggeber ist für diesen Informationsfluss verantwortlich. Da sich Anforderungen und Abschätzungen im Laufe des Projekts verändern können, wird von beiden Seiten höhere Flexibilität gefordert. Die erhöhten Kontrollmöglichkeiten bedeuten gleichzeitig größere Aktivität und Verantwortlichkeit auf Auftraggeberseite. Der in der Regel dafür notwendige Lernprozess wird durch das Zielflussmanagement unterstützt. Erhöhte Modularität der Software sowie ein "From-Front-To-Back"-Vorgehen sind hierbei förderlich.
Sind die beteiligten Systeme gut aufeinander abgestimmt, wird die Wahrscheinlichkeit von chaosbedingten Fehlentwicklungen erheblich reduziert. Das Projekt kann für beide Seiten ein Erfolg werden.

 Chaos existiert beinahe zwangsläufig in IT-Projekten. Es kann aber reduziert und kontrolliert werden; fatale Folgen einer chaotischen Entwicklung können somit vermieden werden!


* 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 Manifesto for Agile Software Development.

2 siehe: http://www.extremeprogramming.org oder http://www.xprogramming.com.

3 Es überrascht daher nicht, dass die zentrale Website über SCRUM, eine der führenden agilen Methoden, unter http://www.controlchaos.com zu finden ist.

4 Vgl.hierzu: http://www.jur-psv.de/cl_zielfluss.html.

5 Die Verantwortung für Abweichungen des Endergebnisses vom vorgegebenen Ziel musste anhand eines zu Beginn geschlossenen Vertrags, oft in langen Verhandlungen, ermittelt werden.

6 Dabei sind oftmals gerade Vorschläge des Auftraggebers eines dieser Details.

7 Der Kunde kann beim Planungsspiel Anforderungen vorgeben, deren Aufwand von den Entwicklern abgeschätzt wird. Anschließend werden die Anforderungen vom Kunden priorisiert.