1 Einführung eines iterativen und inkrementellen ...
1 Einführung eines iterativen und inkrementellen ...
1 Einführung eines iterativen und inkrementellen ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
1<br />
(LQI KUXQJHLQHVLWHUDWLYHQXQGLQNUHPHQWHOOHQ(QWZLFNOXQJVSUR]HVVHVLQ*UR‰XQWHUQHKPHQ<br />
YHU|IIHQWOLFKWLQ2%-(.7VSHNWUXP<br />
3HWHU6W|FNO(0DLOSV#FRUWH[EUDLQZDUHGHDUEHLWHWDOV%HUDWHUEHLGHU&RUWH[%UDLQZDUH&RQVXOWLQJ 7UDLQLQJ<br />
*PE+(UEHVFKlIWLJWVLFKVHLWHLQLJHQ-DKUHQPLWGHQ7KHPHQ6RIWZDUHHQWZLFNOXQJVSUR]HVVHXQG5HTXLUHPHQWV<br />
0DQDJHPHQW<br />
Die <strong>Einführung</strong> neuer Entwicklungsprozesse ist eine vielschichtige Aufgabe. Gerade in Großunternehmen reicht es<br />
nicht aus nur softwaretechnische Aspekte zu betrachten. Die geplanten Änderungen haben Auswirkungen auf<br />
zahlreiche Organisationseinheiten <strong>und</strong> auf jeden einzelnen der betroffenen Mitarbeiter. Der Artikel beschreibt typische<br />
Probleme bei der <strong>Einführung</strong> von neuen Entwicklungsprozessen <strong>und</strong> mögliche Lösungen.<br />
Iterative <strong>und</strong> inkrementelle objektorientierte Entwicklungsprozesse (im Folgenden 223UR]HVVHgenannt) haben ihre<br />
Überlegenheit gegenüber Prozessen, die auf dem Wasserfall-Modell basieren, inzwischen auf breiter Front bewiesen.<br />
Ihre wichtigsten Vorteile sind:<br />
• geringeres Entwicklungsrisiko<br />
• schnellere Reaktionszeiten bei geänderten Anforderungen<br />
• früheres Feedback der Anwender bzw. Auftraggeber<br />
Bekannte OO-Prozesse sind beispielsweise<br />
der 2EMHFW(QJLQHHULQJ3URFHVV2(3 (vgl. [Oes99]),<br />
der 2EMHFWRULHQWHG3URFHVV(QYLURQPHQWDQG1RWDWLRQ23(13URFHVV(vgl. [Gra97]),<br />
der 2EMHFW2ULHQWHG6RIWZDUH3URFHVV2263 (vgl. [Amb98]) <strong>und</strong><br />
der 5DWLRQDO8QLILHG3URFHVV583 (vgl. [Kru99]).<br />
Für die meisten Unternehmen stellt sich daher nicht mehr die Frage, ob sie einen OO-Prozess einsetzen sollen, sondern<br />
wie er am besten eingeführt werden kann. Bei einer Prozesseinführung sind einige fachliche Aufgaben zu erledigen.<br />
Der Prozess muss an die speziellen Bedürfnisse des Unternehmens angepasst werden, eine sinnvolle Dauer der<br />
einzelnen Iterationen muss festgelegt werden <strong>und</strong> einiges mehr. Diese Aktivitäten sind inzwischen in etlichen Artikeln<br />
<strong>und</strong> Büchern ausführlich beschrieben.<br />
Das Erledigen dieser fachlichen "Hausaufgaben" reicht aber nicht aus, um einen OO-Prozess erfolgreich in einem<br />
Unternehmen einzuführen. Sein Einsatz zieht nämlich Änderungen in der Organisation nach sich <strong>und</strong> hat<br />
Auswirkungen auf die einzelnen Mitarbeiter. Wird dies nicht berücksichtigt, ist die Gefahr groß, dass die <strong>Einführung</strong><br />
<strong>eines</strong> OO-Prozesses trotz seiner fachlichen Vorzüge scheitert.<br />
Dieser Artikel richtet sich nicht nur an Softwareentwickler, sondern auch an Projektmanager <strong>und</strong> Führungskräfte. Er<br />
beschreibt die Erfahrungen, die der Autor in den letzten zwei Jahren bei der <strong>Einführung</strong> von OO-Prozessen in<br />
Unternehmen gemacht hat, die zuvor nach dem Wasserfall-Modell gearbeitet haben. Dabei wird vor allem auf die<br />
organisatorischen <strong>und</strong> psychologischen Aspekte eingegangen.<br />
$NWXHOOH6LWXDWLRQLQ*UR‰XQWHUQHKPHQ<br />
Heutige Großunternehmen sind in der Regel seit einigen Jahren ISO-9000-zertifiziert <strong>und</strong> arbeiten daher nach einem<br />
definierten Entwicklungsprozess, der üblicherweise auf dem Wasserfall-Modell basiert. Zuerst wird ein Fachkonzept<br />
erstellt, danach ein DV-Grobkonzept <strong>und</strong> ein DV-Feinkonzept. Anschließend wird die Software codiert <strong>und</strong> zum<br />
Schluss getestet. Dieses Vorgehen hat den Vorteil, dass es sich einfach planen lässt <strong>und</strong> eine Arbeitsteilung gut<br />
unterstützt.<br />
Die Strukturen in den Unternehmen sind daher auf das Wasserfall-Modell abgestimmt. Die Aufgaben Spezifikation,<br />
Softwarearchitektur, Implementierung <strong>und</strong> Test sind organisatorisch getrennt, häufig als Profitcenter, die an einer<br />
gleichmäßigen Auslastung interessiert sind. Die Richtlinien zur Vertragsgestaltung mit K<strong>und</strong>en <strong>und</strong> mit<br />
Unterauftragnehmern setzen das Wasserfall-Modell <strong>und</strong> seine Meilensteine voraus. Abbildung 1 veranschaulicht dies.
2<br />
$EE2UJDQLVDWLRQVVWUXNWXULP:DVVHUIDOO0RGHOO<br />
In der Praxis wurden mit dem Wasserfall-Modell jedoch nur bei kleinen Projekten gute Erfahrungen gemacht. Bei<br />
größeren Projekten konnte man regelmäßig feststellen, dass zwischen den einzelnen Phasen relativ unkontrolliert<br />
gewechselt wurde. Während der Realisierungsphase wurden Anforderungen geändert, während der Testphase das<br />
Softwaredesign usw. Dies verursachte natürlich auch organisatorische Probleme. In der Realisierungsphase waren<br />
beispielsweise die Fachdesigner nicht mehr verfügbar, obwohl neue Anforderungen auftauchten. Diese Probleme<br />
wurden aber nicht dem Prozess angelastet, sondern den Projekten bzw. den jeweiligen Projektbeteiligten. Daher wurde<br />
der Sinn der oben beschriebenen organisatorischen Strukturen nie in Frage gestellt.<br />
Die Mitarbeiter in den Unternehmern, vor allem die Erfahrungsträger, arbeiten häufig seit vielen Jahren nach dem alten<br />
Vorgehen <strong>und</strong> sind mit diesem bestens vertraut. Dieses Wissen ist ein Teil ihres Kapitals. Sie haben meist kein großes<br />
Interesse an Veränderungen.<br />
Diese Situation muss bei der Umstellung auf einen OO-Prozess berücksichtigt werden. Andernfalls kann es sehr schnell<br />
zum Scheitern des gesamten Vorhabens kommen. Es ist daher sinnvoll bei der Prozesseinführung folgende Reihenfolge<br />
einzuhalten:<br />
1. Auswahl <strong>eines</strong> Pilotprojekts <strong>und</strong> der Projektmitarbeiter<br />
2. Definition des Entwicklungsprozesses<br />
3. Anpassen des betroffenen organisatorischen Umfelds<br />
4. Durchführung des Pilotprojekts<br />
Im Folgenden wird auf jeden dieser Punkte genauer eingegangen.<br />
$XVZDKOHLQHV3LORWSURMHNWV<br />
Es ist praktisch nie der Fall, dass ein Unternehmen den gesamten unternehmensweiten Entwicklungsprozess auf einen<br />
Schlag umstellt. Normalerweise wird der neue Prozess in einem Pilotprojekt erprobt. Die Auswahl <strong>eines</strong> geeigneten<br />
Pilotprojekts ist entsprechend wichtig. Das Projekt muss nämlich beweisen, dass der neue Prozess besser ist als der<br />
bisherige. Daher ist es wichtig, dass es folgende Kriterien erfüllt:<br />
• 'DV3LORWSURMHNWVROOWHNHLQHWULYLDOH$XIJDEHQVWHOOXQJEHVLW]HQ Triviale Aufgaben lassen sich mit jedem Prozess,<br />
notfalls sogar ohne Prozess lösen. Damit gezeigt werden kann, dass ein iteratives Vorgehen besser ist als ein<br />
Vorgehen nach dem Wasserfall-Modell, ist also eine gewisse Komplexität erforderlich.
3<br />
• 'DV3LORWSURMHNWGDUI]HLWOLFKQLFKWNULWLVFKVHLQ. Es darf also keinen festen Termin <strong>und</strong> keine knappen zeitlichen<br />
Vorgaben besitzen. Für die Projektmitarbeiter wird die neue Vorgehensweise so ungewohnt sein, dass<br />
Verzögerungen unvermeidbar sind.<br />
• 'DV3LORWSURMHNWPXVVGLH$QZHQGXQJGHVQHXHQ3UR]HVVHVHUODXEHQ Das ist immer der Fall, wenn das System,<br />
das entstehen soll, "auf der grünen Wiese" entwickelt werden kann. Etwas problematischer ist es, wenn das<br />
Pilotprojekt mit bestehenden anderen Projekten koordiniert werden muss, die nach einem herkömmlichen Prozess<br />
durchgeführt werden. Es ist zum Beispiel schwierig Schnittstellen zwischen zwei Systemen festzulegen, wenn das<br />
eine System nach dem Wasserfall-Modell entwickelt wird <strong>und</strong> das andere gleichzeitig iterativ. Die Informationen,<br />
die für die Schnittstellenspezifikation nötig sind, müssen nämlich zu unterschiedlichen Zeitpunkten erstellt werden<br />
bzw. verfügbar sein. In einem <strong>iterativen</strong> Vorgehen werden zuerst die architekturrelevanten Anforderungen<br />
detailliert beschrieben <strong>und</strong> realisiert. Schnittstellen gehören oft nicht zu diesen Anforderungen. Das Wasserfall-<br />
Modell erfordert es, alle Schnittstellen genau festzulegen, bevor die Spezifikationsphase abgeschlossen werden<br />
kann. Die Erweiterung <strong>eines</strong> bestehenden Systems ist oft kein geeignetes Pilotprojekt. In einem solchen Fall liegen<br />
meist Entwicklungsdokumente vor, die für eine Weiterverwendung in einem <strong>iterativen</strong> Prozess nicht geeignet sind.<br />
Häufig ist eine Softwarearchitektur vorhanden, die kein inkrementelles Vorgehen erlaubt, da kleine Ergänzungen<br />
der Funktionalität Änderungen in weiten Teilen des Systems erfordern. Häufig wird jedoch der Wunsch bestehen,<br />
gerade solche Aufgaben als Pilotprojekt durchzuführen, da mit der bestehenden Software <strong>und</strong> den<br />
Entwicklungszeiten bei der Einbringung von neuen Leistungsmerkmalen in der Vergangenheit schlechte<br />
Erfahrungen gemacht wurden. Der neue Entwicklungsprozess soll nun eine Verbesserung dieser Situation bringen.<br />
Die Motive sind also durchaus nachvollziehbar, richtig wird die Wahl dadurch aber nicht.<br />
Dem Gesamtverantwortlichen für das Pilotprojekt muss klar sein,<br />
• dass Mitarbeiter irritiert <strong>und</strong> verunsichert sein werden,<br />
• dass Organisationseinheiten, mit denen zusammengearbeitet werden muss, möglicherweise mit dem neuen<br />
Vorgehen nicht zurechtkommen <strong>und</strong><br />
• dass ein Termindruck für das Projekt fatal sein kann. Der neue Prozess sollte wenigstens im Pilotprojekt in voller<br />
Breite durchlebt werden. Es ist gefährlich, wegen <strong>eines</strong> aggressiven Endtermins Abstriche bei den vorgesehenen<br />
Arbeiten zu machen. Wenn nämlich noch keine Erfahrungen im neuen Vorgehen vorhanden sind, kann nicht<br />
entschieden werden, auf welche Arbeiten verzichtet werden kann <strong>und</strong> welche absolut notwendig sind.<br />
Der Verantwortliche wird die oben genannten Schwierigkeiten nur dann akzeptieren, wenn ihm gezeigt wird, was er<br />
durch den neuen Prozess in Zukunft gewinnen kann: bessere Kontrolle über die Projekte, geringere Risiken <strong>und</strong><br />
zufriedenere K<strong>und</strong>en.<br />
$XVZDKOGHU3URMHNWPLWDUEHLWHU<br />
Nachdem ein geeignetes Pilotprojekt gef<strong>und</strong>en ist, kann mit der Auswahl der Projektmitarbeiter begonnen werden.<br />
Durch das Thema des Projekts <strong>und</strong> seine zeitliche Terminierung ist der mögliche Mitarbeiterkreis bereits<br />
eingeschränkt. Geeignete Kandidaten müssen die benötigten Erfahrungen besitzen <strong>und</strong> für die Laufzeit des Projekts<br />
verfügbar sein. Um so wichtiger ist es, dass aus dem verbleibenden Personenkreis frei ausgewählt werden darf. Es ist<br />
absolut entscheidend für den Erfolg des Pilotprojekts <strong>und</strong> der gesamten Prozesseinführung, dass das Projektteam den<br />
neuen Prozess unterstützt. Bei der Zusammenstellung des Teams müssen also auch psychologische Aspekte<br />
berücksichtigt werden.
4<br />
$EE5HDNWLRQHQDXI9HUlQGHUXQJHQ<br />
Die <strong>Einführung</strong> <strong>eines</strong> neuen Prozesses bedeutet zunächst einmal für jeden einzelnen Mitarbeiter eine Veränderung. Wie<br />
Menschen mit Veränderungen umgehen, hängt von ihrer Persönlichkeit ab. Die Reaktionen reichen von totaler<br />
Begeisterung bis zu völliger Ablehnung. Die Häufigkeit der jeweiligen Reaktion besitzt die Form einer Gaußschen<br />
Glockenkurve, wie in Abbildung 2 dargestellt. Extreme Ablehnung oder Begeisterung trifft man eher selten, eine<br />
Indifferenz am häufigsten an. Bei der Analyse der Reaktionen ist eine Einteilung der Personen in vier Gruppen<br />
hilfreich:<br />
• Die meist recht kleine Gruppe derIU KHQ8QWHUVW W]HU Sie sind von allem Neuen begeistert, einfach weil es neu<br />
ist. Sie stellen für die <strong>Einführung</strong> <strong>eines</strong> neuen Entwicklungsprozesses kein Problem dar, helfen aber auch nicht, da<br />
ihre Begeisterung für neue Dinge bei den Kollegen bekannt ist <strong>und</strong> daher nicht ernst genommen wird.<br />
• Die ebenfalls recht kleine Gruppe der SULQ]LSLHOOHQ*HJQHU Sie fühlen sich nur in vertrauter Umgebung wohl <strong>und</strong><br />
lehnen daher alles Neue ab. Jeder Versuch, solche Personen von Neuem zu überzeugen, ist verschwendete Mühe.<br />
Sie müssen sich einfach langsam an Neuerungen gewöhnen. Glücklicherweise wird dieser Personenkreis von<br />
seinen Kollegen ebenso wenig ernst genommen wie der erste.<br />
• Die relativ große Gruppe der ]XU FNKDOWHQG=XVWLPPHQGHQ Sie sind Änderungen gegenüber prinzipiell positiv<br />
eingestellt, bleiben aber kritisch.<br />
• Die ebenfalls große Gruppe der ]XU FNKDOWHQG$EOHKQHQGHQ Sie sind eher skeptisch, setzen sich aber mit<br />
Neuerungen auseinander <strong>und</strong> können durch gute Argumente überzeugt werden.<br />
Für das Pilotprojekt ist es wichtig, keine prinzipiellen Gegner im Projektteam zu haben <strong>und</strong> möglichst mehr<br />
zurückhaltend Zustimmende als zurückhaltend Ablehnende. Der letzten Gruppe muss die größte Aufmerksamkeit<br />
geschenkt werden. Wenn es gelingt, genügend viele aus dieser Gruppe vom neuen Vorgehen zu überzeugen, setzt ein<br />
gruppendynamischer Prozess innerhalb des Teams ein, in dessen Verlauf das gesamte Team die neue Methode<br />
befürwortet.<br />
Neben diesen eher theoretischen Überlegungen darf nicht vergessen werden, dass es bei jeder Neuerung Gewinner <strong>und</strong><br />
Verlierer gibt. Oft betrachten sich gerade erfahrene Mitarbeiter als Verlierer bei der <strong>Einführung</strong> <strong>eines</strong> neuen Prozesses,<br />
weil sie das Gefühl haben, dass ihre erworbenen Erfahrungen wertlos werden <strong>und</strong> relativ neue Leute mit entsprechend<br />
neuem Wissen im Wert steigen. In diesem Fall werden sie unter Umständen versuchen, den Erfolg des Pilotprojekts zu<br />
verhindern. Da auf ihr Wissen häufig nicht verzichtet werden kann <strong>und</strong> da sie meist gute Verbindungen zum<br />
Management besitzen, sind ihre Chancen groß, dies auch zu erreichen. Solche Mitarbeiter lassen sich an folgenden<br />
Verhaltensweisen erkennen:<br />
• Offene Ablehnung.
5<br />
• Scheinbare Auseinandersetzung mit dem neuen Thema. Diese darf nicht mit echtem Interesse verwechselt werden.<br />
Hierbei werden oft endlose, nicht konstruktiv geführte Diskussionen über die richtige Umsetzung der neuen<br />
Vorgehensweise gestartet.<br />
• Stille Verweigerung, zum Beispiel durch Dienst nach Vorschrift. Der Mitarbeiter wird in diesem Fall<br />
argumentieren, dass der schlechte Fortschritt der Arbeiten am neuen Vorgehen liegt. Wenn er wie früher arbeiten<br />
dürfte, wären seine Leistungen auch besser.<br />
Mit solchen Personen im Projektteam ist das Pilotprojekt zum Scheitern verurteilt. Daher ist es in diesem Fall besser,<br />
ein Pilotprojekt zu suchen, in dem auf die entsprechenden Mitarbeiter verzichtet werden kann.<br />
Eine besondere Rolle im Pilotprojekt spielt auch der Projektleiter. Er muss im Vorfeld des Projekts gründlich geschult<br />
werden, was in der Praxis häufig erstaunlich schwierig ist, da diese Personen meist einen vollen Terminkalender haben<br />
<strong>und</strong> außerdem die typischen Standardschulungen eher auf Entwickler als auf Projektleiter ausgerichtet sind.<br />
'HILQLWLRQGHV3UR]HVVHV<br />
Die Qualitätsnorm ISO 9000 verlangt, dass in einem Unternehmen ein verbindlicher Entwicklungsprozess vorhanden<br />
<strong>und</strong> dokumentiert ist <strong>und</strong> dass alle Projekte nach diesem Prozess durchgeführt werden. Da die vorhandenen<br />
Prozessrichtlinien normalerweise nicht mit einem modernen OO-Prozess übereinstimmen, gibt es nur zwei<br />
Möglichkeiten, das Pilotprojekt ISO-9000-konform durchzuführen:<br />
• Die Prozessrichtlinien werden so geändert, dass sie auch den neuen Prozess als Vorgehensmodell zulassen. Das ist<br />
normalerweise nicht durchsetzbar, da die dafür zuständigen Mitarbeiter meist auch die Schöpfer der bestehenden<br />
Richtlinien <strong>und</strong> für ihre Einhaltung verantwortlich sind. Sie werden nicht ohne triftige Gründe "bewährte"<br />
Vorgehensweisen durch neue <strong>und</strong> unbekannte ersetzen.<br />
• Es wird eine Erlaubnis erteilt, ein Pilotprojekt nach dem neuen Entwicklungsprozess durchzuführen. Diese<br />
Erlaubnis muss normalerweise vom Entwicklungsleiter oder einem ähnlichen Funktionsträger gegeben werden.<br />
Auch an dieser Stelle ist also Überzeugungsarbeit zu leisten. Außerdem sind eigene Prozessrichtlinien erforderlich,<br />
in denen das neue Vorgehen im Detail beschrieben wird.<br />
Die Erstellung der Prozessrichtlinien ist eine Gradwanderung. Sind sie nicht detailliert <strong>und</strong> formal genug, entsprechen<br />
sie nicht den Anforderungen von ISO 9000. Sind sie zu formal, werden sie nicht gelesen <strong>und</strong> schon gar nicht befolgt<br />
<strong>und</strong> sind damit wertlos. Folgende Fragen sollten mindestens geklärt werden:<br />
• Welche Rollen gibt es im Prozess?<br />
• Welche Ergebnisse müssen wann <strong>und</strong> von wem erbracht werden?<br />
• Welche Organisationseinheiten sind zu welchen Zeitpunkten am Projektgeschehen beteiligt?<br />
• Welche Planungsdokumente werden zu welchen Zeitpunkten benötigt?<br />
Dabei ist es wichtig, für die einzelnen Planungsdokumente entsprechende Vorlagen zu erstellen. Das Erstellen dieser<br />
Vorlagen ist sehr zeitintensiv, da dabei viele Regeln <strong>und</strong> Vorschriften beachtet werden müssen, die in einem großen<br />
Unternehmen normalerweise vorhanden sind.<br />
Die Prozessrichtlinien sollten bereits vor dem Start des Pilotprojekts bereits fertig sein. Wenn das nicht der Fall ist, ist<br />
die Gefahr groß, dass die Anfangsphase des Projekts unkoordiniert abläuft.<br />
$QSDVVHQGHVEHWURIIHQHQRUJDQLVDWRULVFKHQ8PIHOGV<br />
Der neue Prozess wird es erfordern, einige Regelungen <strong>und</strong> Gewohnheiten innerhalb des Unternehmens zu ändern.<br />
Diese Änderungen können nur in Zusammenarbeit mit den jeweiligen Entscheidungsträgern durchgeführt werden. Am<br />
häufigsten sind die folgenden Gebiete betroffen.<br />
&RQWUROOLQJ<br />
Es gehört zu den Aufgaben <strong>eines</strong> Projektleiters, sein Projekt zu überwachen. Dabei wird er bestimmte Metriken<br />
erheben <strong>und</strong> Kennzahlen ermitteln. Einen Teil dieser Kennzahlen muss er an die Controlling-Abteilung weitergeben,<br />
deren Aufgabe es ist, die Wirtschaftlichkeit der einzelnen Entwicklungsabteilungen zu prüfen. Die Kennzahlen sind<br />
üblicherweise genau festgelegt <strong>und</strong> auf das Wasserfall-Modell abgestimmt. Zum Beispiel werden an den jeweiligen<br />
Meilensteinen das noch zur Verfügung stehende Budget <strong>und</strong> die verbrauchte Zeit ermittelt oder zu Projektbeginn muss<br />
mit Hilfe der )XQFWLRQ3RLQWAnalyse eine Aufwandsabschätzung abgegeben werden.<br />
In Projekten, die nach einem OO-Prozess durchgeführt werden, stehen dem Projektleiter wesentlich genauere<br />
Kennzahlen zur Verfügung, als dies beim Wasserfall-Modell der Fall ist. Die Kennzahlen werden aber anders <strong>und</strong> zu<br />
anderen Zeitpunkten erhoben. Daher muss in Zusammenarbeit mit der Controlling-Abteilung festgelegt werden,
6<br />
• ob die einzelnen Kennzahlen anders ermittelt werden müssen,<br />
• ob sie anders interpretiert werden müssen oder<br />
• ob komplett neue Kennzahlen benötigt werden.<br />
=XVDPPHQDUEHLWÃYRQÃ2UJDQLVDWLRQVHLQKHLWHQ<br />
Falls im Unternehmen eine sehr starke Arbeitsteilung herrscht, sind auch die Verantwortlichen der einzelnen<br />
Organisationseinheiten vom neuen Entwicklungsprozess betroffen. In vielen Unternehmen werden folgende<br />
Tätigkeiten von eigenen Organisationseinheiten vorgenommen: Spezifikation des Systems, Erstellen einer<br />
Softwarearchitektur, Realisieren der Software, Testen <strong>und</strong> Einführen der Software (vgl. Abb. 1). Jede dieser<br />
Organisationseinheiten ist an einer gleichmäßigen Auslastung ihrer Mitarbeiter interessiert.<br />
Das Wasserfall-Modell macht dies in der Theorie einfach. Zuerst kommt eine relativ lange Phase, in der das<br />
Fachkonzept erstellt wird. Danach kommt eine Phase der Erstellung des DV-Konzepts, anschließend wird realisiert <strong>und</strong><br />
danach getestet. Mit dieser Vorgehensweise kann der Personaleinsatz leicht geplant werden.<br />
In einem <strong>iterativen</strong> Prozess stellt der schnelle Wechsel zwischen den einzelnen Aktivitäten eine echte Herausforderung<br />
für stark arbeitsteilige Organisationen dar. Die Überlappung der einzelnen Iterationen so zu gestalten, dass alle<br />
Beteiligten gleichmäßig ausgelastet sind, ist nicht sinnvoll. Dies würde zu einer so starken Überlappung führen, dass<br />
keine Erfahrungen aus früheren Iterationen in den darauffolgenden Iterationen berücksichtigt werden können. Das<br />
Lernen aus früheren Iterationen ist jedoch einer der Hauptvorteile einer <strong>iterativen</strong> Vorgehensweise.<br />
$EE,WHUDWLRQVSODQXQJ
7<br />
Im Pilotprojekt muss daher gelegentlich in Kauf genommen werden, dass für einzelne Mitarbeiter Zeiten entstehen, in<br />
denen sie im Projekt nicht benötigt werden (siehe Abb. 3). Das bedeutet unter Umständen einen Umsatzverlust für die<br />
betroffene Organisationseinheit, der von jemandem bezahlt werden muss: entweder vom Projekt oder von der<br />
Organisationseinheit. Dieser Punkt sollte vor Beginn des Pilotprojekts geklärt werden. An dieser Stelle muss erwähnt<br />
werden, dass die gleichmäßige Auslastung der Mitarbeiter im Wasserfall-Modell nur in der Theorie funktioniert. Die<br />
Praxis zeigt, dass die einzelnen Aktivitäten nicht mit dem Ende der entsprechenden Phase abgeschlossen sind.<br />
Gef<strong>und</strong>ene Fehler <strong>und</strong> geänderte Anforderungen oder Randbedingungen machen die Wiederaufnahme von eigentlich<br />
abgeschlossenen Aktivitäten erforderlich. Falls die erforderlichen Personen bereits in anderen Projekten eingesetzt sind,<br />
muss das restliche Team warten, bis diese Mitarbeiter wieder Zeit haben.<br />
Wenn der iterative Entwicklungsprozess im ganzen Unternehmen eingesetzt wird, ist es meist möglich, die Mitarbeiter<br />
in den Wartezeiten in anderen Projekten einzusetzen. Besser wäre es natürlich, wenn man sich dazu entschließt,<br />
langfristig auf eine derart starke Arbeitsteilung zu verzichten. Das hat folgende Vorteile:<br />
• Die Arbeit wird für die einzelnen Mitarbeiter abwechslungsreicher <strong>und</strong> damit interessanter. Die Mitarbeiter sind<br />
daher besser motiviert.<br />
• Die Mitarbeiter machen wertvolle Erfahrungen. Wer seine entwickelten Architekturen auch selbst realisieren kann,<br />
erlebt Fehler in der Architektur viel unmittelbarer. Entsprechend größer ist auch der Lerneffekt. Wer seine<br />
Software auch testen muss, erfährt, welche Vorteile es hat, bei der Erstellung der Software auf Testbarkeit zu<br />
achten. Mitarbeiter mit solchen Erfahrungen sind sehr wertvoll in zukünftigen Projekten.<br />
• Es wird verhindert, dass gerade die besten Mitarbeiter den Bezug zur Praxis verlieren, weil sie nur noch Konzepte<br />
erstellen müssen <strong>und</strong> nicht mehr realisieren dürfen.<br />
Hier kann man sich ein Beispiel an anderen Branchen nehmen, wie etwa der Automobilindustrie, in denen die ehemals<br />
vorhandene starke Arbeitsteilung inzwischen wieder aufgehoben wird.<br />
9HUWUDJVPDQDJHPHQW<br />
Die Gestaltung der Verträge mit K<strong>und</strong>en <strong>und</strong>/oder Unterauftragnehmern ist ebenfalls von der <strong>Einführung</strong> <strong>eines</strong><br />
<strong>iterativen</strong> Vorgehens betroffen. Auch hier ist die Welt des Wasserfall-Modells scheinbar einfacher:<br />
• Eine Firma, die nicht selbst realisiert, kann nach der Erstellung des Fachkonzepts verschiedene Angebote einholen<br />
<strong>und</strong> das attraktivste annehmen.<br />
• Ein Softwarehersteller wartet üblicherweise, bis das Fachkonzept fertig ist, bevor er ein Angebot abgibt oder mit<br />
der eigentlichen Arbeit beginnt.<br />
• Sollen Teile der Entwicklung ausgelagert werden, wird gewartet, bis das DV-Grobkonzept fertig ist. Danach sind<br />
alle Informationen vorhanden, die ein Unterauftragnehmer benötigt, um ein Angebot abgeben zu können.<br />
Ein OO-Prozess erkennt die Tatsache an, dass es bei einem komplexen System nicht sinnvoll ist, eine detaillierte<br />
Spezifikation des gesamten Systems zu erstellen, bevor mit der Architektur begonnen wird. Die Vollständigkeit <strong>und</strong><br />
Widerspruchsfreiheit einer solchen Spezifikation kann nämlich nicht geprüft werden, solange nur Dokumente<br />
existieren.<br />
Dies macht die Gestaltung der Verträge allerdings komplizierter. Eine gute <strong>und</strong> faire Vertragsform wäre zum Beispiel,<br />
die Entwurfsphase nach Aufwand abzurechnen <strong>und</strong> nach der Entwurfsphase ein Festpreisangebot zu erstellen, da zu<br />
diesem Zeitpunkt bereits sehr viele Informationen vorliegen <strong>und</strong> eine Aufwandsabschätzung entsprechend genau sein<br />
kann. Ein solcher Vertrag ist zwar aufwändiger, aber die Wahrscheinlichkeit, dass der Vertrag eingehalten werden<br />
kann, ist größer.<br />
Gelegentlich ist es schwierig, dies in die Praxis umzusetzen. Öffentliche Institutionen haben beispielsweise oft<br />
gesetzlich geregelte Ausschreibungsverfahren, die ein detailliertes Fachkonzept zwingend erfordern. Auch hier kann<br />
eine Lösung nur in Zusammenarbeit mit den jeweiligen Spezialisten erfolgen.<br />
Der Aufwand lohnt sich dennoch. Gerade langfristig ausgelegte Geschäftsbeziehungen profitieren von einem OO-<br />
Prozess. Kostenabschätzungen werden genauer <strong>und</strong> nachvollziehbarer <strong>und</strong> das Vertrauen zwischen den<br />
Vertragspartnern wächst. In den herkömmlichen Vertragsbeziehungen kommt es dagegen oft vor, dass eine<br />
Entwicklungsfirma genötigt wird, zu einem Zeitpunkt Preise zu nennen, zu dem dies eigentlich noch nicht möglich ist.<br />
Hat sie sich verkalkuliert, wird versucht, die restlichen Kosten bei Änderungswünschen hereinzuholen, was wiederum<br />
zu entsprechenden Irritationen beim Auftraggeber führt.<br />
'XUFKI KUXQJGHV3LORWSURMHNWV<br />
Nach diesen Vorbereitungen kann das Pilotprojekt endlich gestartet werden. In der ersten Zeit sind die<br />
Projektmitarbeiter <strong>und</strong> der Projektleiter häufig sehr verunsichert. Besonders das Gefühl, mit einer Softwarearchitektur
8<br />
beginnen zu müssen, bevor das System in allen Details spezifiziert ist, kann Entwicklern Probleme bereiten, die<br />
jahrelang nach dem Wasserfall-Modell gearbeitet haben. Eine entsprechend enge Betreuung durch Personen mit<br />
Erfahrung in der neuen Vorgehensweise, zum Beispiel durch externe Berater, ist daher erforderlich. Ein Pilotprojekt<br />
ohne eine solche Begleitung hat kaum eine Chance, erfolgreich abgeschlossen zu werden. Die dafür notwendigen<br />
Kosten müssen also rechtzeitig im Projektbudget eingeplant werden.<br />
Eine vielfach unterschätzte Rolle im Pilotprojekt spielt die Informationspolitik. Pilotprojekte sollen beweisen, dass der<br />
neue Entwicklungsprozess funktioniert. Daher werden sie meist von außenstehenden Mitarbeitern genau verfolgt. Die<br />
Informationen, die dabei über den "kleinen Dienstweg" ausgetauscht werden, führen bei den restlichen Kollegen zu<br />
einem ersten Eindruck von der neuen Methode. Ist der Eindruck positiv, bekommt sie einen wichtigen<br />
Vertrauensvorschuss, ist er negativ, ist es schwer die Methode allgemein einzuführen. Ebenso wichtig ist es, dass die<br />
direkten Vorgesetzten der Projektmitarbeiter über die neue Methode informiert sind. Nur dann werden sie die Berichte<br />
ihrer Mitarbeiter richtig einordnen können <strong>und</strong> sich eine objektive Meinung über das Projekt bilden.<br />
In vielen Unternehmen gibt es eine Mitarbeiterzeitung. Die Macher dieser Zeitung sind meistens dankbar, wenn sie<br />
interessante Themen bekommen. Ihre Fähigkeiten <strong>und</strong> Erfahrungen sollten genutzt werden, um der neuen Methode <strong>und</strong><br />
dem Pilotprojekt eine gute Publicity zu verschaffen. Der Idealfall ist dann erreicht, wenn die Mitarbeiter, die nicht am<br />
Pilotprojekt beteiligt sind, das Gefühl haben, dass ihnen dadurch wichtige Qualifikationsmöglichkeiten vorenthalten<br />
werden.<br />
Falls das Pilotprojekt scheitern sollte, was nie ausgeschlossen werden kann, wird die weitere Zukunft des neuen<br />
Entwicklungsprozesses ganz entscheidend davon abhängen, ob die "Öffentlichkeitsarbeit" gut war oder nicht. Sogar<br />
wenn das Projekt erfolgreich war, kann das Projektteam oder das Management unzufrieden sein, weil eine noch bessere<br />
Qualität oder noch kürzere Entwicklungszeiten erwartet wurden. In diesem Fall wurde versäumt überzogene<br />
Erwartungen rechtzeitig zu korrigieren. Die neue Methode ist eben kein Allheilmittel. Unrealistische Terminvorgaben,<br />
unklare Projektziele <strong>und</strong> ständig wechselnde Anforderungen können nach wie vor zum Scheitern <strong>eines</strong> Projekts führen.<br />
Die Produktivität wird durch einen OO-Prozess zwar deutlich steigen, aber sie wird sich nicht gleich im ersten Projekt<br />
verdoppeln oder verdreifachen.<br />
Eine wichtige Rolle für die erfolgreiche <strong>Einführung</strong> <strong>eines</strong> OO-Prozesses spielen die Anwender der Software oder --<br />
falls kommerzielle Software entwickelt wird -- die Marketingabteilung. Ein OO-Prozess erlaubt es ungleich besser, die<br />
Anwender frühzeitig in die Entwicklung einzubeziehen <strong>und</strong> mit ihnen in einer Sprache zu kommunizieren, die sie auch<br />
verstehen können. Daher werden diese Personen den neuen Prozess entsprechend unterstützen.<br />
Abbildung 4 zeigt noch einmal die wichtigsten externen Einflussfaktoren auf das Pilotprojekt.
9<br />
$EE([WHUQH(LQIOXVVIDNWRUHQ<br />
=XVDPPHQIDVVXQJ<br />
Viele Unternehmen stellen sich nicht mehr die Frage, ob sie einen <strong>iterativen</strong> <strong>und</strong> <strong>inkrementellen</strong> Entwicklungsprozess<br />
einsetzen sollen. Sie haben sich längst dafür entschieden <strong>und</strong> überlegen nun, wie man ihn am besten einführt. Dabei<br />
muss beachtet werden, dass diese Aufgabe nicht nur ein fachliches Problem für Softwarespezialisten ist. Es gibt eine<br />
Reihe anderer Personen, die davon betroffen sind, <strong>und</strong> es gibt etliche, eher unerwartete Probleme, auf die man stoßen<br />
wird. Für diese Probleme gibt es keine universellen Lösungen. Wer sich von ihnen überraschen lässt, läuft Gefahr zu<br />
scheitern. Wer sie kennt, kann sie bewältigen <strong>und</strong> die Vorteile <strong>eines</strong> modernen <strong>und</strong> leistungsfähigen<br />
Entwicklungsprozesses ausnutzen.<br />
/LWHUDWXU<br />
>$PE@ S.W. Ambler, Process Patterns, Cambridge University Press / SIGS Books, 1998<br />
>*UD@ I. Graham, B. Henderson-Sellers, H. Younessi, The OPEN Process Specification, Addison-Wesley, 1997<br />
>.UX@ P. Kruchten, The Rational Unified Process, Addison-Wesley, 1999<br />
>2HV@ B. Oestereich, P. Hruschka, N. Josutti, H. Kocher, H. Krasemann, M.Reinhold, Erfolgreich mit<br />
Objektorientierung, Oldenbourg Wissenschaftsverlag, 1999