[ 1 ] [ 2 ]

Session D-KPUT

„Warum OO sowieso nicht funktioniert“

Alf Borrmann
Wizards & Builders GmbH


Einführung

Objektorientierung (OO) ist eine wundervolle, elegante Technologie, sie funktioniert und sie bietet hervorragende Möglichkeiten, Applikationen zu bauen und Aufgabenstellungen vielerlei Art zu lösen.

Warum also dann der Titel "Warum OO sowieso nicht funktioniert"?

Der Einstieg in die Objektorientierung ist eine große Umstellung in allen Belangen eines Projektes. Dementsprechend groß sind die Risiken, die damit verbunden sind. Und innerhalb einer Firma oder in der Zusammenarbeit mit Kunden gibt es immer Leute, die, falls ein Projekt schief läuft, es (natürlich immer nachher) besser wissen und dem Promoter dann sagen: "das waren Sie mit Ihrer Objekt-Manie".

Denn natürlich können OO-Projekte schief gehen. Der Einsatz von objektorientierter Technologie ist keine Gewähr dafür, daß eine Software den Ansprüchen genügt. Ganz im Gegenteil: dadurch, daß es eine Menge neue Verfahren, Regeln, Notwendigkeiten und Begriffe gibt, gibt es natürlich auch neue Risiken. Und wenn Sie viel Arbeit darein gesteckt haben, ihr Projekt OO-gerecht zu organisieren, in bessere Ausbildung investiert, neue Tools gekauft haben etc., ist damit schon eine Menge Geld ausgegeben worden. Das Scheitern eines OO-Projektes wird damit erheblich teurer und schmerzhafter, als das Scheitern eines konventionellen Projektes.

In diesem Beitrag soll nun aufgelistet werden, welche Dinge es in einem Softwareprojekt - und speziell in einem OO-Projekt - zu beachten gibt.

Es geht dabei nicht um die Vermittlung endgültiger Wahrheiten, ja es werden nicht mal allzuviele Antworten gegeben. Denn viele Entscheidungen in einem Projekt können so oder so ausfallen. Es gibt zwar in der Literatur eine (bzw. mehrere) Idealvorstellung davon, wie ein OO-Projekt optimal läuft. In der Praxis lassen sich diese idealen Modelle aber an vielen Stellen nicht durchhalten.

Als Beispiel sei hier ein relationales Datenmodell genannt:

Trotzdem gib es in den meisten Entity-Relationship-Modellen Abweichungen davon, nämlich Daten, die mehrfach gespeichert werden. Wozu dies? Weil es Performance bringt! Damit wird zwar gegen die Theorie verstoßen, aber dies ist eine aktive Entscheidung:

Das Feld ist also nicht zufällig in dem Datenmodell, sondern hat einen klaren Zweck. Und wenn später der Einwand auftaucht: "da ist etwas redundant, eigentlich geht die Rechnungssumme doch aus den Einzelpositionen hervor", ist der Zweck dieser Redundanz und der Grund, gegen diese Regel verstoßen zu haben, aus der Dokumentation klar ersichtlich.

Hier sind die wichtigsten Kriterien, die beim Handhaben von solchen Entscheidungen beachtet werden müssen:

Analog zu diesem Beispiel gibt es Notwendigkeiten zu Entscheidungen bei der Abwicklung von OO-Projekten. In diesem Beitrag werden einige der zusätzlichen Risiken aufgelistet, die in OO-Projekten vorhanden sind. Es werden Hinweise gegeben, wie man solche Risiken erkennt und nach Möglichkeit Hinweise gegeben, wie Fehler bei Entscheidungen vermieden werden können bzw. wie man die Folgen einer Entscheidung zwischen zwei gleich großen Übeln verringert.

Was in diesem Beitrag genannt wird, basiert auf Einsichten, die Softwareentwickler durch schmerzhafte Erfahrungen in der Praxis erworben haben.

Das, was in einem Fall ein Fehler ist, kann sich in einem anderen Fall als goldrichtig herausstellen. Nutzen sie die Hinweise dazu, regelmäßige Projekt-"walk-througs" zu machen. Wenn Ihnen etwas verdächtig erscheint, stellen Sie es auf den Prüfstand. Wenn es sich als notwendig und sachdienlich erweist, gegen eine Regel zu verstoßen, ist das OK. Aber: dokumentieren Sie Ihre Entscheidungen.

Besonderheiten von OO-Projekten

„Ein Projekt ist die Kollision zwischen Wünschen, festgelegtem Termin und vorhandenem Geld.“

Notwendigkeit zur Planung

In OO-Projekten muß ein besonderes Augenmerk auf Planung und Dokumentation gelegt werden. Zusätzlich zu konventionellen Projekten sind in OO-Projekten Planungen für die Analyse und Designphase (A&D), den Aufbau eines Klassenmodells und die Wiederverwendung notwendig. Daraus ergeben sich natürlich auch eine Menge Risiken, denn man muß ja in die Zukunft schauen, um ein Projekt planen zu können.

Vorschußlorbeeren

Von der objektorientierten Technologie (OOT) verspricht man sich oft, daß alles viel einfacher wird, die Komplexität wird beherrschbar, durch Wiederverwendung wird die Softwareerstellung billiger und schneller, man muß nicht mehr soviel testen …

Aber auch mit OOT kann man Projekte ganz toll versenken. In der Tat sind OO-Projekte, die versenkt werden, sogar viel teurer versenkt, als wenn man es 'normal' gemacht hätte, jedenfalls in der Anfangsphase, in der hohe Investitionen in Know-how und Training und in das Sammeln von Erfahrung nötig sind. Besonders gefährlich ist es, einen als OO 'getarnten' prozeduralen Ansatzes zu implementieren. Dies passiert gerade bei VFP, wie bei jeder anderen hybriden Sprache sehr schnell.

Paradigmawechsel

Verbunden mit dem Wechsel von der prozeduralen zur objektorientierten Programmierung ist die Einführung eines komplett neuen Modells für die Programmierung. Dieses Modell und das alte, prozedurale schließen sich gegenseitig aus. Ein solcher Übergang von einem alten zu einem neuen Modell wird Paradigmawechsel genannt. Paradigmawechsel rufen bei den betroffenen Personen typische Reaktionen hervor. Diese Reaktionsmuster sind in der Psychologie erforscht worden und lassen sich einteilen in:

Alle diese Reaktionen bergen die Möglichkeit für neue Risiken. Sie können durch Fehleinschätzungen ein Projekt behindern oder gar scheitern lassen.

Grundlagen des Projektmanagements

Alle Möglichkeiten, die Sie in normalen Projekten einsetzen, sind natürlich in OO-Projekten weiterhin angebracht und sinnvoll.

Planung

Planung heißt zu allererst, daß man einen Plan erstellt, daß man sich im Vorhinein Gedanken macht, wie man ein entsprechendes Ziel erreichen will. Daß man überlegt, welche Ressourcen man benötigt und wann sie benötigt werden.

Planung heißt, die Ziele, die man erreichen will, festzuschreiben.

Planung ist keine Tätigkeit, die einmal getan wird und die damit erledigt ist. Planung ist ein ständig laufender Prozeß. Planung bedeutet auch, sich abzeichnende Entwicklungen an dem zu messen, was vorgesehen war und den Vergleich dazu zu nutzen, die weitere Planung zu verbessern bzw. zu adjustieren.

Trotz guter Planung kommt es aber in Softwareprojekten oft zu Problemen. Wie diese Probleme entstehen, wie man sie erkennt und wie man gegensteuert, wird weiter unten an verschiedenen Beispielen erläutert.

Feststellen von Abweichungen

Bei der Erreichung eines Teilziels oder bei der Fertigstellung eines Teilprojektes wird der Plan meist nicht eingehalten. Nach (oder während) der Erreichung von geplanten Teilzielen gilt es, Abweichungen festzustellen. Dies kann z.B. durch regelmäßige Projektbesprechungen oder Reviews geschehen.

Prüfung der Kollisionsmöglichkeiten

Das Prüfen auf mögliche Kollisionen heißt insbesondere, eine Betrachtung der geplanten und der erreichten Ziele und der bei der Erreichung aufgetretenen Schwierigkeiten. Jedes der Zwischenziele hatte ja wiederum ein Zeitziel, ein Kostenziel und eine Featureliste, die es gilt, miteinander in Einklang zu bringen. Die Kollisionen, die bei der Erreichung von Teilzielen aufgetreten sind, lassen Rückschlüsse zu auf die möglichen Kollisionen bei den Zielen, die man noch vor sich hat.

Erarbeiten von Gegenmaßnahmen

Die Ergreifung von Gegenmaßnahmen beinhaltet natürlich auch, daß man die Möglichkeit zu deren Umsetzung bzw. Durchsetzung hat und den richtigen Zeitpunkt findet, sie anzusprechen.

Stellen Sie sich die Situation vor: Sie sind Programmierer in einem Projekt, das völlig aus dem Zeitplan geraten ist. Der Projektleiter hat das gemerkt, hat einen Rundgang gemacht, um mit den Programmierern das weitere Vorgehen zu besprechen. Sie sind dabei besonders unangenehm aufgefallen, weil Sie immer als letzter an Ihrem Arbeitsplatz sind und Ihr Schreibtisch ein Chaos aus leeren Pizzaschachteln ist. Daß Sie der produktivste Programmierer im Team sind und immer als letzter aus dem Büro gehen, wird in dem Zusammenhang natürlich gerne übersehen. Sie haben sich sogar noch Gedanken zu dem Projekt gemacht und ein paar Ideen, die das Management wieder auf Kurs bringen könnten. Trotzdem: dies ist keine Situation, in der Ihre Gedanken auf verstärkte Gegenliebe stoßen. Im Gegenteil: der Projektleiter wird möglicherweise den Verdacht haben, Daß Sie seine Kritik nur kontern zu wollen.

Anders herum: Sie sind Projektleiter. Einer Ihrer Chefprogrammierer kommt in Ihr Büro und meldet freudestrahlend, daß er eine wichtige Komponente sehr elegant und sauber fertiggestellt hat. Sie sollten das nicht als Selbstverständlichkeit nehmen und dann sofort darauf zu sprechen kommen, daß er den chaotischsten Arbeitsplatz in der ganzen Firma hat. Das demotiviert und macht Ihr Gegenüber nicht empfänglich für das, was Sie sagen wollen.

Vorbereitung und Dokumentation von Entscheidungen

Bei der Vorbereitung von Entscheidungen kommt es darauf an, die Gründe, die für jede Alternative sprechen, aufzulisten und als Dokumentation später zur Verfügung zu haben. Vielleicht muß die Entscheidung später noch einmal überdacht werden und vielleicht sind dann verschiedene Gründe weggefallen. In dieser Situation verkürzt eine Liste der Gründe die Zeit, die notwendig ist und verbessert die Entscheidung, weil einmal gefundene Kriterien nicht vergessen werden.

Risikogruppen

Die Bereiche, die in OO-Projekte spezifische Risiken bergen, lassen sich in mehrere Gruppen einteilen. Im großen und ganzen kann man die spezifischen Risiken der OO auf 9 Bereiche verteilen, die sich allerdings teilweise überschneiden. Einige dieser Risikobereiche sind nicht exklusiv auf OO-Projekte beschränkt, sondern auch konventionelle Projekte sind in der einen oder anderen Form damit behaftet.

Man kann bewußt das eine oder andere Risiko eingehen, weil man ein spezielles Ziel damit erreichen will. Wenn man jedoch aus Unwissenheit oder Unachtsamkeit gegen eine Regel verstößt oder ein Risiko eingeht oder sich keine Gedanken über die Folgen macht, kann man damit den Projekterfolg gefährden.

In einem OO-Projekt gibt es eine Menge Möglichkeiten, in Fallen zu tappen. Diese im Detail zu besprechen, würde den Rahmen diese Beitrags sprengen. Es geht hier nur darum, die verschiedenen Kategorien von Gefahren vorzustellen und andere Beispiele zu zeigen. Hinweise zu weiterführender Literatur findet sich in der Bibliographie.

Zu den Beispielen wird nach Möglichkeit aufgezeigt, woran Sie sie erkennen, was die Auswirkungen sein können, wenn eine Entscheidung nicht richtig getroffen wurde, wie Sie eine solche Klippe umschiffen können und was Sie zur Prävention tun können.

Die 9 Kategorien von Risiken sind:

Konzeptionelle Risiken

Konzeptionelle Entscheidungen sind in einem Projekt die mit den am weitesten reichenden Folgen, da sie die Grundlage aller weiteren Entscheidungen stellen. Fehlgriffe bei konzeptionellen Entscheidungen sind obendrein am schwierigsten zu entdecken, da sie normalerweise vor Beginn eines Projektes gefällt werden im Projektverlauf oft nicht weiter diskutiert werden.

Konzeptionelle Gefahren lassen sich auf eine oder mehrere von drei prinzipiellen Fehleinschätzungen zurückführen:

Diese Probleme sind nicht OO-spezifisch, wirken sich in einem OO-Projekt aber verstärkt aus.

Die Annahme, daß OO umsonst zu haben ist

Stellen Sie sich vor, Sie sind Manager eines Boxers. Sie wollen, daß er an einer Kickbox-Europameisterschaft teilnimmt. Sie geben Ihm ein paar Bücher über Kickboxen, zeigen ihm einen Film und schicken Ihn ein paar Tage in ein Trainingscamp. Wie schätzen Sie seine Chancen, bei der Meisterschaft ein?

Klingt ziemlich dumm, nicht wahr? Aber Tatsache ist, daß genau das sehr häufig mit Software-Entwicklern gemacht wird. Sie erhalten Bücher über OO, Beispielprogramme und eine Schulung. Dann wird von Ihnen erwartet, daß sie - ohne echte OO-Erfahrung - ein kritisches Projekt in Rekordzeit erledigen. Am Ende sehen die Entwickler so aus, wie der Boxer in dem Beispiel, wenn nicht schlimmer.

Anzeichen: Widerstand bei Ihren Chefs, wenn zusätzliche Mittel bereitgestellt werden sollen. Schlüsselfrage: "Ich dachte, daß wir mit OO Zeit und Geld sparen sollten, statt mehr auszugeben." Noch gefährlicher: Entwickler, die glauben, daß sie keine zusätzlichen Schulungen für den ganzen 'OO-Krempel' brauchen.

Auswirkungen: das Projekt profitiert nicht von den spezifischen OO-Vorteilen wie Wiederverwendung, bessere Abbildung der Anforderungen etc.

Erkennung: Fragen Sie sich: "Wenn ich unsere Entwickler in einen Programmier-Wettkampf mit den besten OO-Entwicklern schicken müßte, was würde ich tun, damit sie vorzubereiten?"

Beseitigung: Wirken Sie daraufhin, daß alle Beteiligten einsehen, daß bessere Vorbereitung auch bessere Ergebnisse bringt. Wenn Sie in einem Projekt stecken und bereits Zeitdruck haben, sind Ihre Möglichkeiten begrenzt. Machen Sie eine Liste der Ausbildungsmaßnahmen, die am wichtigsten sind. Wenn Sie dieses Risiko erkennen, machen Sie den Beteiligten klar, daß das Projekt möglicherweise länger dauert, als angepeilt.

Prävention: Tun Sie das, was Sie als Antwort auf den Punkt Erkennung erhalten haben. In der Regel sind Investitionen in den Bereichen

nötig. Der Aufwand für solche Investitionen mag schwer zu verkaufen sein, aber er bietet zweierlei Vorteile: Sie haben eine besser ausgebildete und professionellere Gruppe von Entwicklern und dieses Klima trägt dazu bei, wirklich gute Entwickler bei der Stange zu halten.

Der Einsatz von OO-Techniken aus den falschen Gründen

Es gibt eine Menge gute Gründe, Objektorientierung einzusetzen: Handhabung von Komplexität, Abstraktion, Wiederverwendbarkeit, Kapselung, Vererbung …

Leider gibt es auch eine Anzahl ziemlich schlechter Gründe, auf OOT umzusteigen. Dazu gehören z.B.:

Anzeichen: Sie glauben, daß Sie mit OO alle Ihre Probleme Ihres Entwicklungsprozesses lösen; Sie sind der Ansicht, daß OOT eine ausgereifte Technik ist;

Auswirkungen: Zeitverzögerungen; Vorteile werden nicht erreicht, was zu Enttäuschungen bei Ihnen und (schlimmer) bei Ihren Chefs oder Auftraggebern führt; Köpfe rollen, ggf. Ihr eigener

Erkennung: Bitten Sie die Leute, die mit Ihnen an dem Projekt arbeiten, die Gründe, die sie haben, um OOT einzusetzen, aufzuschreiben. Bitten Sie sie, die Risiken, die sie sehen, aufzulisten. Wenn einer der genannten Gründe auftaucht, haben Sie ein Problem. Wenn auf diesen Listen keine Risiken genannt werden, haben Sie noch mehr Probleme.

Beseitigung: Besprechen Sie sich mit den Entscheidungsträgern und diskutieren Sie die Listen, die Sie erhalten haben. Erklären sie (vorsichtig) die Probleme, die damit verbunden sind. Drehen Sie die Erwartungen, die an den Einsatz von OOT geknüpft werden, auf ein erfüllbares Maß zurück.

Prävention: Im großen und ganzen das gleiche, was unter Erkennung und Beseitigung steht, außer, daß man es tut, bevor ein Projekt gestartet wird.

Weitere konzeptionelle Risiken

Politische Risiken

Der Begriff Politik ist durch den normalen Sprachgebrauch etwas in die Nähe von Schmutz und Schmier geraten. Manchmal wird ja auch von "Politik als schmutzigem Geschäft" gesprochen. Aber wenn man den Politikbegriff auf seine Ursprünge bezieht, wird klar, daß es hier immer um die Beziehungen zwischen Personen geht. Und in modernen Softwareprojekten sind immer mehrere Personen beteiligt. Leider ist es so, daß politische Fehler zu den häufigsten Gründen gehören, die ein Projekt als gescheitert erscheinen lassen. Oft sind Projekte technisch ein Erfolg. Nur weil irgend jemand unbedingt ein Feature haben wollte, das Sie nicht bringen konnten, wird dieses Projekt von dieser Person möglicherweise sehr wirksam schlecht gemacht. Wenn Ihnen klar ist, daß Leute, die nach einem Feature fragen, dafür vielleicht politische Gründe haben, werden Sie vielleicht leichter damit umgehen können.

Viele der politischen Risiken sind in dem Buch 'Death March' von Edward Yourdon (im Anhang genannt) sehr gut beschrieben.

Den Widerstand unterschätzen

Objekte sind wundervoll. Wenigstens Denken Sie das, basierend auf der Lektüre eines Fachartikels oder auch auf Basis langjähriger Erfahrung. Für Sie ist das Hantieren mit Klassen und Objekten ganz offensichtlich und einfach zu begreifen und Sie meinen daher daß es auch für andere ganz einfach und offensichtlich ist. Wenn Sie nun anfangen, mit Elan OOT einzuführen, wundern Sie sich nicht, wenn Sie auf Widerstände stoßen.

Der Satz "Ich habe da eine wundervolle neue Technologie entdeckt" ist ein absolutes Alarmzeichen für Ihre Umgebung. Stellen Sie sich folgende Situation vor: Sie nehmen an einer Arbeitssitzung teil, um eine anstehende Aufgabe zu beraten. Die Runde ist mit vollem Ernst bei der Sache, es wird engagiert diskutiert. Die Fetzen fliegen. Plötzlich geht die Tür auf und ein verspäteter Teilnehmer kommt aufgeregt herein und ruft: "Ich habe da eine wundervolle neue Technologie entdeckt!". Die Runde fühlt sich möglicherweise veralbert, nicht ernst genommen. Warum sollte gerade dieser Typ, der nicht mal die Diskussionslage kennt, die Lösung aller Fragen wissen. Der Nachzügler nimmt die geleistete Arbeit nicht wahr oder nicht ernst …

Das gleiche gilt natürlich, wenn Sie Leiter oder Mitglied eines Entwicklerteams sind und anfangen, mit Ihre Kollegen ganz schnell davon überzeugen zu wollen, daß OOT das einzige Mittel ist, die Aufgabe zu lösen. Wenn es Widerstand gibt, OOT einzusetzen und Sie nicht darauf eingehen, sind Sie sehr schnell in einer politischen Debatte. Ihre Kollegen haben vielfältige Gründe, OO abzulehnen, sie reichen von klaren sachlichen Argumenten bis zu irrationalen Ängsten:

Anzeichen: Sie erhalten nur sehr zögerlich Unterstützung. Es kursieren Gerüchte, daß Sie die Firma oder die Abteilung völlig umkrempeln wollen. In Meetings werden immer wieder Ziele in Frage gestellt. Ihr Projekt wird geringer priorisiert oder mit weniger Ressourcen bedacht.

Auswirkungen: Bedeutende Verschiebungen des Projektes, Verlust von Einfluß

Erkennung: Wenn Sie die Hartnäckigkeit des Widerstandes gegen OOT überrascht, sollten Sie die Gründe dafür herausfinden. Das kann allerdings recht schwierig sein, denn je nach dem werden Ihre Kollegen Ihnen nicht ihre wahren Gründe nennen.

Beseitigung: Je nach Schwere des Widerstandes und Ihrem eigenen Status ergeben sich folgen Möglichkeiten, damit umzugehen:

Prävention: Erstellen Sie eine Liste aller Leute, die Einfluß auf Ihre Bemühungen nehmen können und versuchen Sie, deren Standpunkt zu erfahren. Versuchen Sie, Anreize zu schaffen. Versuchen Sie, den Aufwand dafür in Relation zu setzen zu dem Ergebnis, das Sie von der Einführung von OOT erwarten.

In die „das Feature muß hinein“-Mühle geraten

Sie kennen das: nach endlosen Diskussionen, ständigen Kompromissen, hunderten von Überstunden ist die Version 1.0 fertig. Nun wollen Sie all die Stellen, an denen der Code ziemlich schlecht zusammengezimmert wurde, erstmal aufräumen. Sie wissen, nachdem sie das Produkt nun das erste Mal komplett haben, an welchen Stellen Sie was besser machen können. Sie wollen gerade anfangen, als Ihnen den Vertrieb eine Liste hereinreicht, auf der die Features aufgelistet sind, die nun auf jeden Fall in die Version 2.0 müssen. Die Pläne für Ihre Architekturverbesserung verschieben Sie also auf Version 3.0 … oder für immer.

Möglicherweise ist das Management der Meinung, daß es unnötig ist, daß Sie eine "elegante" Architektur in Ihrem Programm haben oder daß die Programmierer nur ihr Hobby pflegen, wenn sie ihren Code dahin entwickeln wollen, daß er knapper, klarer und verständlicher wird. Aber solche Pflegemaßnahmen zahlen sich immer aus. Immer. Die einzige Frage ist, wann sie sich auszahlen und wieviele Vorteile man erhält. Leider läßt sich das meist nicht eindeutig berechnen, und das Fehlen einer klaren Antwort kann dazu führen, daß Ihnen nicht die Zeit gegeben wird, Codepflege zu betreiben.

Anzeichen: Sie werden ständig dazu angehalten, Arbeit in die nächste Version und nicht in die aktuelle zu stecken.

Auswirkungen: Die Kosten für neue oder erweiterte Funktionen steigen und fallen nicht, wie sie es eigentlich beim Einsatz von OOT tun müßten.

Erkennung: Setzen Sie sich mit dem Management zusammen, um im Detail zu erklären, welche Arbeiten "unter der Haube" zu tun sind. Erklären Sie, welche Auswirkungen das auf die Liste der neuen Features hat. Schauen Sie, welche Reaktion Sie erhalten.

Beseitigung: Die schwerere Möglichkeit ist, das Thema mit dem Management und den Anwendern zu diskutieren, um eine Priorisierung der gewünschten Features zu erhalten. Die Wahl dieser Möglichkeit hängt von der Reaktion auf den Erkennungsversuch ab. Die zweite Möglichkeit ist, die benötigten Zeiten für neue Funktionen höher anzusetzen und die Reserven zu nutzen, um den Code zu überarbeiten.

Prävention: Fördern der Erkenntnisse, daß sich eine saubere Architektur lohnt, daß sie aber im ersten Anlauf mehr Zeit kostet. Auswirkungen von OOT auf Zeitpläne werden im Kapitel Managementfehler weiter beleuchtet.

Weitere politische Risiken

Managementfehler

Die Notwendigkeit für Training und Schulung von Entwicklern ist inzwischen bekannt. Hinzu kommt aber die - möglicherweise noch dringendere - Notwendigkeit, auch die Projektleiter zu schulen. Ein Projektleiter als technischer Manager sollte fähig und willens sein, folgende Punkte zu regeln:

Dazu braucht man vor allem Erfahrung, aber auch das Studium von Fachliteratur hilft und gibt Ideen, worauf man beim Management eines Projektes achten sollte.

Eine lineare Entwicklungskurve erwarten

Unter einer linearen Entwicklungskurve wird hier verstanden, daß der Output an Features oder ganz allgemein "technischem Material" wie Dokumentation, Klassenentwürfen, Klassenbibliotheken etc. über die Zeit konstant bleibt und sich das Projekt stetig seiner Fertigstellung nähert. In OO-Projekten ist der Verlauf aber nicht so. Im Verlauf von OO-Projekten werden die Entwürfe automatisch immer weiter verfeinert. Dadurch entstehen ständig neue Wege, Klassen und Objekte zusammenzufassen. Die Folge ist normalerweise eine Reduzierung der Komplexität des Designs und der Implementation. In solchen Phasen des Reduzierens von Komplexität wird Zeit für das Überdenken und das Redesign der Lösung aufgewendet. Das erscheint nach außen als Phase, in der nicht produziert, in der kein Fortschritt erzielt wird. Oft ist es in solchen Phasen schwierig, zu erklären, daß tatsächlich wichtige Arbeiten stattfinden und daß diese Arbeiten nötig sind, um das Projekt überhaupt am Laufen zu halten.

Anzeichen: Diagramme des Managements, die einen linearen Projektverlauf zeigen; Meilensteine, die nicht erreicht werden; Köpfe rollen.

Auswirkungen: Projekte sind zu spät und ständig werden Schlußtermine verschoben. Bei der Verschiebung von Terminen kann Panik auftreten.

Erkennung: Achten Sie auf Terminpläne oder Projektdiagramme, die einen linearen Verlauf des Projektes implizieren. Achten Sie auf die Erwartungen, die das Management sehen will und wann welche Resultate gewünscht werden.

Beseitigung: Sollte das Projekt schon laufen, machen Sie gnadenlos einen neuen, realistischen Zeitplan. Fordern Sie die Entwickler auf, über den Stand der Subsysteme einen brutal ehrlichen Bericht zu geben. Planen Sie vom gegebenen Punkt des Projektes neu und berücksichtigen Sie die Phasen der Verringerung von Komplexität.

Prävention: Planen Sie, das Projekt mit dem Spiralmodell zu entwickeln und planen Sie dort genügend Phasen für Projektreviews ein.

Weitere Managementrisiken