Im Rahmen der strategischen Neuausrichtung will das Assekuranzunternehmen Kompetenz für objektorientierte Software- Entwicklung aufbauen. Der Versicherer beabsichtigt, zukünftige Projekte mit einem objektorientierten Ansatz durchzuführen. Verknüpft mit dieser Ausrichtung gibt es Bedarf, Mitarbeiter in einem Zeitraum von zehn Wochen kurzfristig auf anstehende Projekte vorzubereiten, in denen objektorientiert entwickelt wird. Dabei werden die Beschäftigten als Entwickler in einer Smalltalk/Visual- Age-Umgebung mitarbeiten.

Die Teilnehmer sollen den objektorientierten Ansatz verstehen und möglichst weitgehend verinnerlichen. Die Vertiefung findet in Praxisprojekten statt.

Nach gemeinsamen Gesprächen schlug QUi vor, die Ausbildung der Entwickler als Projekt aufzusetzen, da es eine effiziente Form ist, gezielt Veränderungsprozesse herbeizuführen.

Aufgrund der Erfahrungen aus der Praxis müssen Entwickler folgende Voraussetzungen erfüllen, wenn sie produktiv in OO- Anwendungsprojekten mitarbeiten wollen:

-Befähigung zur "OO-Denke" und zum Umgang mit dem dazugehörigen Instrumentarium: Konzepte, Vorgehensweise, Werkzeuge etc.

-Anwendung des Instrumentariums in konkreten Problemsituationen. Dies bedeutet, daß Entwickler Problemlösungskompetenz besitzen müssen, um prozessuale Abläufe strukturieren und gestalten zu können.

-Bereitschaft zur Teamarbeit, soziale Kompetenz.

Ein Ausbildungsansatz, der Entwickler effektiv auf Projekte vorbereiten soll, muß diesen Aspekten gleichermaßen Rechnung tragen. Die Vermittlung der Inhalte und deren Anwendung in konkreten Projektsituationen sind von gleicher Bedeutung. Gelingt es, diese beiden Aspekte sinnvoll zu kombinieren, so erhält man für die spätere Projektarbeit wichtige Synergie-Effekte.

Der Alltag in Softwareprojekten ist die Problemlösung im Team. Dies gilt auch bei Verwendung eines objektorientierten Ansatzes. Gerade dessen Durchgängigkeit ermöglicht und erfordert es, unterschiedliche Sichtweisen auf ein Problem mit Hilfe des "Denkwerkzeugs" Objekt auszudrücken und zu diskutieren. Zur Modellierung der fachlichen und der technischen Sichtweise werden gleiche Denkkonstrukte verwendet, wenn auch mit unterschiedlichen Schwerpunkten. Die Nutzung eines Denkwerkzeugs für die Modellierung fachlicher und technischer Aspekte gibt es in dieser Form in der konventionellen DV nicht.

Der für die effektive Nutzung des objektorientierten Ansatzes notwendige Umdenkprozeß erfordert von einem Entwicklerteam eine intensive Lernphase anhand einer durchgängigen Praxisaufgabe. Konventionelle Ausbildungsansätze etwa in Form von Seminarreihen mit anschließendem Einsatz der Mitarbeiter in Projekten, können dies nicht bewerkstelligen.

Die Vorbereitung und die Erfahrung der Lösung im Team kommen dabei zu kurz. Das Erlernen eines neuen Denkansatzes erfordert Raum und Zeit zum Experimentieren. Dies ist erfahrungsgemäß gerade bei Entwicklern aus dem konventionellen Host-Umfeld der Fall. Die wirklichen Fragen treten erst bei der Umsetzung der zuvor vermittelten Inhalte auf.

Die eigentliche Krux - nämlich die Anwendung der Inhalte in konkreten Situationen inklusive der dazugehörigen Kommunikations- und Entscheidungsprozesse - möglichst sofort nach Vermittlung dieser Inhalte bleibt in konventionellen Ansätzen außen vor, weil die Zeit in fünftägigen Seminaren dafür gar nicht gegeben ist. Die Unsicherheit in der Umsetzung des objektorientierten Ansatzes läßt sich auch in einem nachfolgenden Projekt nicht leicht wieder wettmachen, denn hier fehlt der Raum zum Ausprobieren.

Es liegt also nahe, den Lernprozeß und die Projektarbeit miteinander zu verbinden das heißt, die Ausbildung als Projekt zu gestalten. Dies bedeutet, daß die Teilnehmer später auftretende Situationen möglichst realitätsnah in der Ausbildung erleben, wobei der Schwerpunkt aber auf der Schulung liegt. Die Vermittlung der Inhalte und deren konkrete Umsetzung folgen unmittelbar aufeinander.

Parallel dazu werden aber auch die Grenzen des Erlernten deutlich. Die auftretende Unsicherheit in der Praxis des objektorientierten Ansatzes wird durch projekterfahrene Coaches aufgefangen, die auch gleichzeitig die fachlichen Inhalte vermitteln. Die Coaches stehen die ganze Zeit über zur Verfügung, um die Gestaltung von Prozessen vorzuleben und zu begleiten.

Primäres Ziel der Vorbereitung von DV-Entwicklern mit konventioneller Ausrichtung auf OO-Projekte ist die effiziente Gestaltung des Umdenkprozesses.

Die inhaltliche Vermittlung von Methoden und Werkzeugen allein reicht nicht aus, um Mitarbeiter auf OO-Projekte vorzubereiten. Gerade objektorientierte Software-Entwicklung bedeutet in erster Linie Gestaltung von Lösungen, wobei unterschiedliche Sichten integriert werden müssen und können. Das Denkwerkzeug Objekt/Klasse läßt sich sowohl unter fachlichen wie auch technischen Gesichtspunkten nutzen.

In der konventionellen DV ist es nicht üblich, diese Aspekte gemeinsam zu behandeln beziehungsweise in einem Prozeß permanent zwischen diesen Aspekten zu wechseln. Hier herrscht die Trennung zwischen fachlicher und DV-technischer Modellbildung (Analyse, Design und Implementierung). Im objektorientierten Ansatz existieren Analyse, Design und Implementierung zwar immer noch, doch wird hier im Unterschied zum konventionellen Vorgehen an einem Modell gearbeitet.

Dieses Modell wird dabei nach unterschiedlichen Perspektiven gestaltet, untersucht und implementiert. Um eine adäquate Lösung zu entwickeln, muß ein Programmierer sowohl die fachliche als auch die technische Sichtweise einnehmen und zwischen diesen nach Bedarf wechseln können. Das zentrale Ausdrucksmittel, dessen er sich dabei bedient, ist das Objekt. Diese Arbeitsweise an einem Modell hat eine Menge Vorteile, setzt aber einen intensiven, auf praktische Erfahrungen hin ausgerichteten Lernprozeß voraus.

Viele Unternehmen sind nicht bereit, eine solche Lernphase in Kauf zu nehmen und in die Ausbildung ihrer Mitarbeiter zu investieren, obwohl gerade im IT-Bereich das Humankapital der wichtigste Erfolgsfaktor überhaupt ist. Oft fehlt bei Entscheidern das Problembewußtsein dafür, daß sich ein Umdenkprozeß nicht durch eine Reihe von Seminaren abdecken läßt.

Die Lernphase für objektorientierte Software-Entwicklung sieht häufig so aus, daß die Mitarbeiter einige wenige - oft unzusammenhängende - Seminare (meist nur zu den Themen OOP und Werkzeuge) besuchen, um dann in meist kritischen Projekten ihre neuen "Kenntnisse" anzuwenden.

Dies bedeutet, daß die Lernphase und die damit zusammenhängende Unsicherheit in der Anwendung des objektorientierten Ansatzes in produktive Projekte mit Erfolgsdruck verlagert wird. Angeblich macht der OO-Ansatz die Mitarbeiter ja auch kurzfristig "produktiver"! Erfahrungsgemäß scheitern Projekte, die auf diese Art und Weise angegangen werden. Die Schlußfolgerung lautet dann häufig, daß der OO-Ansatz nichts tauge.

Die Investition zahlt sich aus

In diesem konventionellen Ansatz versucht man, die entscheidende Phase im Umdenkprozeß einzusparen: die Zeit zur Gestaltung und Durchführung von Prozessen im Team. Hierfür gibt es aber keine Abkürzung - auch in der objektorientierten Software-Entwicklung nicht.

Im oben skizzierten konventionellen Szenario der OO-Ausbildung konzentriert man sich auf die Vermittlung der Inhalte. Teilnehmer können aus Zeitgründen keine durchgängige und etwas komplexere Aufgabenstellung bearbeiten. Eine auch für größere Projekte skalierbare Vorgehensweise läßt sich praktisch nicht erproben. Die für Projekte so notwendigen Entscheidungs- und Abstimmprozesse über Modellierung, Design und Implementierung bestimmter fachlicher Anforderungen sind ebenfalls aus Zeitgründen nicht durchführbar. Damit bleibt das vermittelte Wissen aber ungefestigt - bis zum ersten Einsatz in einem Folgeprojekt. Die Kosten aufgrund mangelnder Erfahrung im praktischen Umgang mit dem OO- Ansatz treten in der konventionellen Vorgehensweise versteckt erst nach der Ausbildung auf.

Ein zeitlicher Rahmen von zehn Wochen intensiver Arbeit im Ausbildungsprojekt erscheint vordergründig zunächst als Kostenblock. Anders sieht der Sachverhalt aus, wenn man die "Investitionsbrille" aufsetzt und das Ergebnis anschaut: Die ausgebildeten Mitarbeiter sind nach der Projektabwicklung in der Lage, produktiv in nachfolgenden Vorhaben mitzuarbeiten. Sie haben die Durchgängigkeit des objektorientierten Ansatzes an einer auch für größere Projekte skalierbaren Vorgehensweise praktisch erfahren. Sie sind in der Lage, Problemlösungsprozesse mit diesem Ansatz effizient zu gestalten und damit im Team zu arbeiten. Das vermittelte Wissen ist gefestigt, weil die Zusammenhänge erlebt wurden. Wiederverwendbarkeit ist als Arbeitshaltung erfahren worden, die weit mehr umfaßt als nur die Nutzung von Klassenbibliotheken. Sicherlich beherrschen die Mitarbeiter in dieser Zeit nicht die vollständige Visual-Age/Smalltalk- Bibliothek, sie sind aber in der Lage, selbständig die Lücken aufzuarbeiten. Die ausgebildeten Mitarbeiter sind projekt- und teamfähig. Zusätzlich hat das durchgeführte Ausbildungsprojekt für das Unternehmen den Charakter eines Referenzprojektes, das anderen Entwicklern als Muster in der späteren produktiven Entwicklung dienen kann.

Der Versicherer wählte eine ungewöhnliche Form, die Beschäftigten auf ihr künftiges OO-Arbeitsgebiet vorzubereiten: Die Mitarbeiter wurden für einen Zeitraum von zehn Wochen dem Ausbildungsprojekt unter Einbeziehung der vollen Arbeitszeit zugeordnet und waren räumlich von ihrem bisherigen Arbeitsplatz getrennt. Zwischen einer mehr konzeptionellen Phase und einer Implementierungsphase wurde vereinbart, daß die Teilnehmer zwei Wochen ihres Jahresurlaubs einbringen. Da die Arbeit im Projekt während der gesamten Zeit sehr intensiv ist und hohe Anforderungen an Leistungs- und Konzentrationsvermögen der Teilnehmer stellt, ist diese zweiwöchige Verschnaufpause gut, um einen freien Kopf zu bekommen. Dieser wird in der nachfolgenden - ebenfalls sehr intensiven - Implementierungsphase auch dringend benötigt. Unmittelbar nach Ende des Ausbildungsprojektes ist vorgesehen, die Mitarbeiter anstehenden OO-Projekten zuzuordnen.

Eine weitere wichtige Rahmenbedingung ist der Konsens zwischen Führungskräften und Teilnehmern hinsichtlich der Ausbildungsziele. Den Auszubildenden muß klar sein, was das Management von ihnen nach Ende der Ausbildung erwartet. Damit haben sie eine Grundlage, das Ausbildungsprojekt mitzugestalten. Eine klare Zielformulierung gibt den Teilnehmern eine Orientierung über ihre eigene Verantwortung für den Projekterfolg. Damit haben sie die Möglichkeit, den Lernerfolg während des Ausbildungsprojekts zu kontrollieren und bekommen Mut, zu experimentieren.

Zur inhaltlichen Gestaltung können nur einige wichtige Highlights genannt werden, da eine detailliertere Darstellung den Rahmen sprengen würde.

Die Teilnehmer sind aktiv an der Gestaltung und Planung des Projektes beteiligt. Sie sind für den Ausbildungserfolg mitverantwortlich. Die Einbindung aller Teilnehmer in ein gemeinsames Ziel fördert die Motivation zum Lernen und die Bereitschaft zur Auseinandersetzung in der Erarbeitung von konsensfähigen Lösungen.

Das Ausbildungsprojekt umfaßt zwei Abschnitte:

-Der erste Abschnitt ist eher konzeptioneller Natur und legt das Gewicht auf die Erarbeitung von OO-Inhalten anhand einer durchgängigen Aufgabenstellung (Projektaufgabe). Zu den Inhalten gehören OOA, OOD und Visual Age/Smalltalk. Dieser Abschnitt beinhaltet auch die Erarbeitung eines gemeinsamen OOA-/OOD-Modells (inklusive Dokumentation und zugehöriger Layouts), das die Grundlage für die Implementierung im zweiten Abschnitt ist.

-Der zweite Abschnitt beinhaltet die Implementierung des gemeinsam erarbeiteten OOA/OOD-Modells der Projektaufgabe. Dieser Abschnitt wird - wie der erste auch - von projekterfahrenen Coaches betreut, die unterschiedliche Rollen einnehmen. So ist auch in dieser Phase eine intensive Betreuung der Teilnehmer sichergestellt.

Klare Orientierung notwendig

Das Projekt beginnt mit einem Planungsworkshop, auf dem die Projektziele vorgestellt werden und eine darauf basierende Projektplanung und -organisation erarbeitet wird. Unternehmensziele und Ziele der Teilnehmer werden abgeglichen, so daß eine klare Orientierung für den Ablauf des Projektes entsteht. Es werden Meilensteine im Projektverlauf definiert und ein Vorgehen zur begleitenden Qualitätssicherung vereinbart. Weiter wird die zu implementierende Projektaufgabe vorgestellt, die den roten Faden in der Vermittlung der Inhalte darstellt.

Hier lernen die Projektbeteiligten sich kennen und arbeiten schon vom ersten Tag an intensiv zusammen. Der erste Schritt zur Teambildung ist damit getan. Die Teilnehmer sind von Anfang an aktiv in die Gestaltung des Projektes eingebunden. Das Projekt endet mit einem Abschlußworkshop, in dem die Ergebnisse dem Auftraggeber präsentiert und übergeben werden.

Wiederverwendung ist wichtig

Die Wiederverwendung von Ergebnissen ist ein zentrales Thema, das sich durch die gesamte Arbeit zieht. Ob OOA, OOD oder OOP: In jeder Aktivität stellt sich die Frage, ob bereits bestehende Ergebnisse wiederzuverwenden beziehungsweise für die spätere Wiederverwendung nutzbar zu machen sind. So lernen die Teilnehmer, daß Wiederverwendung eine Arbeitshaltung ist, die mehr als nur die Nutzung von Klassenbibliotheken umfaßt. Die Inhalte (OOA, OOD OOP) werden in jeweils viertägigen Workshops vermittelt. Im Anschluß an einen solchen Workshop gibt es jeweils einen "Aufräumtag", an dem die Teilnehmer die vermittelten Inhalte reflektieren und auftretende Fragen formulieren können. Im Anschluß an die Teile OOA und OOD gibt es jeweils einwöchige Vertiefungsphasen, in denen die Teilnehmer daran arbeiten, ein gemeinsames Modell der zu realisierenden Projektaufgabe zu erstellen. Der Coach steht während der gesamten Zeit zur Verfügung. Alle verwendeten Beispiele und Übungen beziehen sich immer auf die Projektaufgabe. QUi legt Wert darauf, daß die vermittelte Vorgehensweise und die damit zusammenhängende Software-Architektur für größere betriebliche Anwendungsprojekte skalierbar ist.

Die Teilnehmer werden kontinuierlich durch mindestens einen projekterfahrenen Coach mit Moderationserfahrung betreut. Die Coaches vermitteln Inhalte und begleiten die Teilnehmer bei der Erarbeitung von Ergebnissen in der Lösung der Projektaufgabe. Dabei nehmen sie unterschiedliche Rollen ein, um bestimmte in der Praxis auftretende Problemsituationen zu provozieren. Sie helfen, Unsicherheiten in der Anwendung des OO-Ansatzes zu artikulieren.

Die Dozenten unterstützen die Teilnehmer bei der Erarbeitung ihrer Lösung, bis sie selbst "laufen können". Der Rückfall in alte Denkgewohnheiten wird soweit wie möglich verhindert.

Eine Teilnehmerin des ersten Ausbildungsprojektes faßt einige wichtigen Aspekte folgendermaßen zusammen: "Die Gestaltung der OO- Ausbildung als ein Schulungsprojekt mit durchgängiger Aufgabenstellung von der Analyse über die Designphase bis zur Implementierung wird von uns sehr positiv beurteilt, ja sogar als notwendig erachtet." Die objektorientierte Software-Entwicklung erfordere von allen Lernenden, die sehr unterschiedliche Ausbildungsprofile und Berufserfahrungen aufweisen, ein vollständiges Umdenken.

Erfahrung der Teilnehmer

"Dieser Denkansatz läßt sich nicht in einem oder mehreren einwöchigen Seminaren, die mehr oder weniger aufeinander aufbauen, erlernen", so die Teilnehmerin weiter. Daher sei es wichtig gewesen, für zehn Wochen dem Ausbildungsprojekt "fulltime" zugeordnet zu sein. "Gegenüber der herkömmlichen Entwicklung ist es ein großer Vorteil der objektorientierten Software-Entwicklung, daß eine Methode in der Analyse- und Designphase angewandt wird", meint die Teilnehmerin. Das Ausbildungsprojekt mit seiner durchgängigen Aufgabenstellung habe ihr ermöglicht, diesen Vorteil zu erfahren.

Da die Teilnehmer für den Erfolg des Ausbildungsprojektes selber verantwortlich waren und dieses mitgestalten durften, tauchten schon sehr bald Probleme auf, wie es sie in jedem OO-Projekt gibt. "Die Ausbildung hat uns daher gut auf kommende Aufgaben vorbereitet", lautet die Schlußfolgerung.

Der Projektansatz in der Vorbereitung von Mitarbeitern auf OO- Projekte hat sich aus der Sicht des Unternehmens und der Teilnehmer in der Praxis bewährt. Nach Einschätzung der ehemaligen Teilnehmer ist es entscheidend, unmittelbar nach der Ausbildung in einem OO-Projekt zu arbeiten, um das Gelernte praktisch umsetzen zu können und damit zu vertiefen. Im ersten Projekt ist Coaching sehr wichtig, um technische Details zu behandeln, die sich im Zeitrahmen des Ausbildungsprojekts nicht praktisch bearbeiten lassen. Der Ansatz des Ausbildungsprojektes ist eine praktikable Möglichkeit, den Umdenkprozeß von konventioneller auf objektorientierte Software-Entwicklung effizient, schnell und zielgerichtet zu gestalten. Hinsichtlich Einsatz- und Gestaltungsmöglichkeiten läßt er eine Menge Flexibilität zu.

Der Aufbau von OO-Kompetenz mit eigenen Mitarbeitern ist auch aus einem weiteren Grund interessant: Derzeit gibt es wenige Entwickler auf dem freien Markt, die Projekterfahrung in objektorientierter Software-Entwicklung mitbringen. Für viele Unternehmen ist es daher eine sinnvolle Alternative, eigene Mitarbeiter, die sich für die Arbeit in OO-Projekten weiterqualifizieren wollen, durch ein Ausbildungsprojekt auf ihre zukünftige Aufgabe schnell und effektiv vorzubereiten. Im Vergleich zur Neueinstellung von Mitarbeitern, die wenig Erfahrung besitzen, hat diese Strategie den Vorteil, daß die Beschäftigten im eigenen Haus die Gegebenheiten im Betrieb kennen. Dies ist gerade für die Durchführung späterer Anwendungsprojekte oft ein ganz entscheidender Erfolgsfaktor.

Will ein Unternehmen den objektorientierten Ansatz in der Software-Entwicklung nutzen, so muß es eine Lernphase einplanen. Diese muß Raum zum Experimentieren lassen und die Lösung im Team in den Vordergrund stellen. Dafür gibt es keine Abkürzung - auch durch objektorientierte Software-Entwicklung nicht. Es existieren aber Möglichkeiten, den damit verbundenen Umdenkprozeß effizient zu gestalten..

Angeklickt

Ein Versicherungsunternehmen wollte Kompetenz für objektorientierte Entwicklung aufbauen und hat vor, künftige Projekte mit einem objektorientierten Ansatz durchzuführen. Gedacht war, die Qualifizierungsmaßnahme als ein Projekt mit einer durchgängigen Problemstellung durchzuziehen, um den Umdenk- und Umlernprozeß für die Entwickler einfacher zu gestalten. Welche Probleme dabei aufgetaucht sind, und wie sie gelöst wurden, schildert Gerd Krützer.

*Gert Krützer ist Geschäftsführer der Gesellschaft für Qualität und Innovation (QUI) in Köln.