Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.07.2002 - 

Softwareprojekte managen/Wie Entwickler Softwareprojekte flexibel und iterativ betreiben können

Agile Prozesse statt starrer Vorgehensmodelle

Langjährige Untersuchungen zeigen, dass sich jährlich zehn bis 25 Prozent der Anforderungen an Software ändern. Management und Architekten von Softwareprojekten müssen sich durch flexible und bedarfsgerechte Vorgehensweisen darauf einstellen. Das Schlüsselwort lautet "Agilität". Von Gernot Starke*

Agilität im Softwareprojekt bedeutet nicht, dass jeder Beteiligte planlos und unkoordiniert arbeitet. Vielmehr soll er in relativ kurzen Iterationszyklen kontinuierlich die aktuellen Projektziele und Projektrisiken sowie das Feedback der Kunden und Anwender bewerten und in die kurzfristige Planung einbeziehen. Agilität beruht somit auf der Erfahrung, dass Änderungen und Anpassungen der Normalfall sind und nicht die Ausnahme.

Agile Projekte zeichnen sich durch eine hohe Orientierung am Endergebnis aus: Das zu erstellende System steht im Mittelpunkt des Projekts, nicht wie bisher oft üblich die Einhaltung starrer Vorgehensmodelle. Der Weg dahin führt über Iterationen und kurze Release-Zyklen. Dabei stehen praktisch jederzeit lauffähige Versionen der gewünschten Anwendungen bereit, wodurch Kunden viel früher als üblich solche Systeme auch produktiv einsetzen können. Das Risiko, die Projektziele zu verfehlen, sinkt.

Agile Prozesse erfordern eine Softwarearchitektur, die ein hohes Maß an Änderungen und Erweiterungen erlaubt. Softwarearchitekten müssen dabei die organisatorischen und technischen Einflüsse und Risiken von Projekten ausbalancieren.

Zudem sollten sich alle Beteiligten über die Architektur verständigen und sämtliche wichtigen Informationen erhalten, statt dass sich, wie es in traditionell organisierten Projekten oft geschieht, nur die Programmierer untereinander abstimmen. Wenn alle Beteiligten die Einfluss- und Risikofaktoren kennen, die das Projekt betreffen, wird auch das Risiko-Management proaktiv und transparent, statt zur ausschließlich reaktiven Feuerwehr zu degradieren.

In der Praxis liegen mittlerweile viele positive Erfahrungen mit agilen Projekten vor (siehe Kasten "Tipps für agile Projekte"). Dabei beschränkt sich Agilität nicht nur auf kleine Studien oder Testprojekte, sondern auch umfangreiche Projekte in der Größenordnung bis 200 Personenjahre lassen sich iterativ und flexibel betreiben. Wenn solche Projekte dennoch scheitern, so liegt die Ursache oftmals im inneren Widerstand: Mitarbeiter weigern sich, vom starren Denken nach dem Wasserfallmodell abzuweichen. Perfektionismus und Dokumentationseifer erscheinen wichtiger als Orientierung an konkreten Zielen. Solche Fälle fordern den Einsatz von Projektleitung und Auftraggeber. Coaching und sachliche Überzeugung können dem Starrsinn abhelfen. (as)

*Gernot Starke arbeitet als Berater für Softwarearchitektur und IT-Strategie bei der Blue-carat AG in Köln. Er ist Mitglied der b-agile Initiative (www.b-agile.de) und Autor des Buchs "Effektive Software-Architekturen" (Hanser-Verlag, München 2002).

Angeklickt

In Softwareprojekten ist mehr Agilität gefordert denn je. Anforderungen und Projektziele verschieben sich relativ schnell, Märkte schwanken, und technische Standards entwickeln sich rascher als noch vor einigen Jahren. All dies fordert entsprechend flexible Softwaresysteme. Statt etablierten Vorgehensmodellen starr zu folgen, müssen sich Entwickler verstärkt auf Ergebnisse konzentrieren. Neben der Architekturphase von Projekten betrifft dies vor allem das Projekt-Management.

Tipps für agile Projekte

In der Praxis hat sich eine Reihe einfacher Maximen bewährt, die Flexibilität zur Chance statt zum Desaster werden lassen:

- Lassen Sie Ihren Entwicklern Mitspracherecht bei der Softwarearchitektur. Das erleichtert es im Projektverlauf, Auswirkungen von Änderungen zu bewerten.

- Erstellen Sie angemessene und bedarfsgerechte Modelle und Diagramme. Schwierige oder riskante Teile sollten Sie detaillierter entwerfen, dafür können Sie bei der Modellierung einfacher Komponenten einsparen. Betrachten Sie dabei Ihr System aus unterschiedlichen Sichten.

- Beginnen Sie sehr früh im Projekt mit der Implementierung von Prototypen. Schwierige und riskante Teile sollten Sie unbedingt zuerst fertig stellen und auf keinen Fall verschieben.

- Streben Sie nach Einfachheit - vermeiden Sie goldene Wasserhähne.

- Bearbeiten Sie schwierige und riskante Teile im Team. Die Begründung hierfür liefert eine der Grundregeln erfolgreicher Architekten: Sie glauben nur so lange, dass ihr Konzept perfekt ist, bis sie es jemand anderem gezeigt haben.

- Niemand arbeitet unter hohem Druck schneller oder produktiver. Im Gegenteil: Hoher Druck erhöht die Fehlerquote und die Bereitschaft zu "schmutzigen Tricks".

- Setzen Sie gezielt Unit-Tests ein. Beschreiben Sie sowohl technische als auch fachliche Testfälle in der eingesetzten Programmiersprache und lassen sie diese am besten täglich durchlaufen. Hierfür existieren hervorragende Open-Source-Systeme wie etwa "Junit". Solche Tests geben dem gesamten Team frühzeitig Feedback und sind eine notwendige Voraussetzung für Entwurfs- und Codeänderungen, das "Refactoring".

- Setzen Sie im Projekt periodisch ein kleines Team darauf an, die Komponenten voneinander unabhängiger zu machen. Abhängigkeiten sind der Todfeind von Flexibilität: Sie lassen Änderungen und Anpassungen immer riskanter werden und erschweren daher agiles Vorgehen.

Abb: Schrittweise zum Projektziel

Agile Entwicklungsprozesse erlauben es, auf neue Anforderungen im Projekt flexibel und kontrollierter zu reagieren als mit traditionellen Vorgehensweisen. Quelle: Klaus Eberhardt