Größere Entwicklungsprojekte ohne Chaos realisieren

Worin liegt der Vorteil, ein IT-Erstellungsprojekt mit Realprojekten als kleinster Einheit zu organisieren? Zwischen verschiedenen organisatorischen Einheiten sind Beziehungen in der Regel zu formalisieren. Innerhalb der kleinsten Einheit, dem Realprojekt, können die Mitglieder jedoch Absprachen formfrei und auf Zuruf treffen. Beispielsweise einigen sie sich mündlich auf bestimmte Aufrufparameter für verschiedene Java-Klassen und stellen im gemeinsamen Compiler unmittelbar fest, ob die Programme logisch miteinander funktionieren. Da die Mitglieder sich sehr schnell absprechen können, bilden sie bald ein eingespieltes Team. In dieser kleinsten Einheit herrscht dadurch die höchste Effizienz des gesamten IT-Projekts. Innerhalb des einzelnen Realprojekts sind keine weiteren formalen Strukturen zwingend. Lediglich sein Chefentwickler verantwortet, dass die Arbeiten auf die Anforderungen des Realisierungskonzepts passen.

Zwar können auf diese Weise organisierte Entwicklungsteams auch auf einem Fachkonzept aufbauen. Da hier die IT-Funktionen vielfach jedoch noch nicht technischen Systemen und Realprojekten zugeordnet sind, besteht die Gefahr, dass manche IT-Funktionen eventuell von keinem Team oder von zwei Teams gleichzeitig realisiert werden. Eine wirklich übergreifende Sicht auf die IT-Prozesse mit den erforderlichen Abstimmungen besteht demnach nur im Realisierungskonzept. In ihm modelliert der Architekt grafisch alle Anwendungsfälle als Aktivitätsdiagramme mit Swimlanes – wie etwa die Funktion „Prämie bestellen“. Durch die Verwendung der Realprojekte als Swimlanes werden die Schnittstellen zwischen Realprojekten als Pfeile zwischen Aktivitäten grafisch klar erkennbar. Das Entwicklungsteam des Realprojekts „Internetplattform“ erkennt somit sofort, dass es für den Anwendungsfall „Prämie bestellen“ das Oracle-Team des Realprojekts „Kontoführung“ kontaktieren muss, weil zur Bestellung dort Prämienpunkte abgebucht werden.

Über Schnittstellen hinweg arbeiten die Entwicklungsteams jedoch weitaus weniger effizient zusammen als innerhalb eines Realprojekts. Da kein gemeinsamer Compiler, sondern nur noch ein echter Laufzeittest (Systemtest) sicherstellen kann, dass die entwickelten Codes zusammen laufen, dauert die Korrektur von Fehlern hier wesentlich länger. In der Regel nimmt ein solcher Korrekturprozess (Roundtrip) zwei bis drei Tage in Anspruch. Dagegen dauert innerhalb eines Realprojekts ein Roundtrip wenige Minuten. Weil Fehler, etwa unterschiedliche Validierungsregeln, nun nicht mehr sofort im Compiler auffallen, dürfen die Entwickler aus unterschiedlichen Realprojekten Absprachen nun nicht mehr auf Zuruf treffen, sondern müssen sie schriftlich fixieren – etwa mit XML.

Im Gegensatz zum geschilderten Vorgehen verwenden viele IT-Projekte dagegen immer noch wesentlich kompliziertere Ansätze: So wollen deren Verantwortliche auch innerhalb eines Entwicklungsteams und Realprojekts noch sehr viele Absprachen formal als Schnittstellen definieren. Durch dieses Sicherheitsbedürfnis entsteht jedoch eine hohe Ineffizienz: Denn jede geänderte Hilfsfunktion erfordert in diesem Fall einen vorübergehenden Stillstand des Projekts, weil ein Entwickler zunächst einmal viele Dokumentationen ändern müsste. In einer Organisation mit Realprojekten reicht es dagegen aus, nur die Schnittstellen zwischen technisch getrennten Systemen formal zu definieren