Vergleiche zwischen unterschiedlichen Methoden in der Softwareentwicklung bleiben theoretisch und erfassen allenfalls ähnliche Projekte oder Projektabschnitte. Der Grund dafür: Welcher Auftraggeber leistet sich schon den Luxus, ein und dieselbe Aufgabe von mehreren Teams lösen zu lassen?

Das hat jetzt der japanische IT-Dienstleister NTT Data in Zusammenarbeit mit seiner deutschen Consulting-Tochter Cirquent getan. Drei Projektteams - ein rein japanisches, ein deutsch-japanisches und ein indisch-japanisches - traten an, um mit unterschiedlichen Methoden eine identische Aufgabe zu lösen. Ziel dieser "Versuchsanordnung" war es, agile und klassische Methoden der Softwareentwicklung einem Praxisvergleich zu unterziehen. Die japanische Zentrale von NTT Data arbeitete als Auftraggeber, und die dort verlangten Reports über Projektdesign, Methoden, Fortschritte und Aufwände dienten zugleich als Grundlage für den empirischen Vergleich der Methoden.

Verwaltung der Zutrittskontrolle

Allen drei Teams wurde die Aufgabe gestellt, die Verwaltungssoftware für eine standortübergreifende, komplexe Zutrittskontrolle zu modernisieren. Dies schloss ein Web-Frontend für die Administratoren, Rollenmodelle für Berechtigungen sowie Workflows für Kartenverlust, Neuausgabe, Sperre etc. ein. Den Teams wurden Spezifikationen und Anforderungen übergeben, bestimmte Bereiche wie das Oberflächendesign sollten im Projektverlauf mit Anwendern näher definiert werden.

Das erste Team bestand aus neun japanischen Entwicklern, die an ein und demselben Standort im klassischen Wasserfall-Ansatz an die Entwicklungsaufgabe gingen. Team zwei setzte sich aus zwei Gruppen in Japan und Indien zusammen, die in zwei stark überlappenden Schichten arbeiteten. Das von der deutschen Cirquent geleitete Team drei bildete drei Gruppen, um in drei Schichten rund um die Uhr ("Follow-the-Sun") entwickeln zu können: zwei in getrennten Standorten und Schichten in Japan, eine in München.

"Die drei Vergleichsgruppen arbeiteten mit unterschiedlichen Ansätzen", erläutert Jürgen Schön, Programmleiter bei Cirquent. "Das von uns geleitete Team kombinierte agile Scrum-Methoden und ihre üblichen Sprints mit einer Follow-the-Sun-Organisation." So wurde 24 Stunden pro Werktag am Projekt gearbeitet. Die jeweils drei Mitarbeiter starken Teams übergaben die Projektstände im "Kreis" durch Telefon- und Videokonferenzen während der nur einstündigen Schichtüberlappung.

Das indisch-japanische Team nutzte dagegen Mischformen zwischen klassischer und agiler Methodik. In Teilprojekten wurde nach Waterfall gearbeitet, in anderen Teilbereichen fanden Übergaben zwischen der japanischen und indischen Gruppe statt - insgesamt wurde zeitlich stark überlappend von 8.30 Uhr bis 20.45 Uhr lokaler japanischer Zeit gearbeitet.

ActiF
Requirement-Management (RM) und Implementierung (IMP) sind ist voll abgedeckt, keine Unterstützung gibt es für Wartung (W) und Betrieb (B). Auch der Test (T) ist schwach ausgeprägt. Besser schneidet AcriF bei der Integration (INT), Projekt-Management (PM), Qualitäts-Management (QM) und Systemdesign (SD) ab.

Adaptive Software Development (ASD)
ASD schneidet nur im Qualitäts-Management (QM) sehr gut ab. Disziplinen wie Integration (INT), Wartung (W), und Betrieb (B) werden überhaupt nicht abgedeckt. Projekt- und Requirement-Management (PM/RM), Systemdesign (SD), Implementierung (IMP) und Test (T) sind schwach ausgeprägt.

Agile Enterprise
Agile Enterprise leistet vollständige Unterstützung in den Bereichen Projekt-Management (PM), Requirements-Management (RM), Implementierung (IMP) und Test (T). Nicht ganz so gut sieht es bei der Integration/Einführung (INT), dem Qualitäts-Management (QM) oder dem Systemdesign/technische Konzeption (SD) aus. Schwachpunkt ist die Wartung (W), für den Betrieb (B) kommt überhaupt keine Unterstützung.

Agile Model Driven Development
AMDD deckt unter den Disziplinen des Software Engineering die des Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Integration/Einführung (INT), Wartung (W) und Betrieb (B) sowie für Implementierung (IMP). Auf mittlerem Niveau bewegen sich das Qualitäts-Management (QM), Requirements-Management (RM) und das Systemdesign/technische Konzeption (SD) während für Projekt-Management (PM) nur wenig Unterstützung kommt.

Behavior Driven Development
Behavior Driven Development schneidet nur im Requirements-Management (RM) sehr gut ab, gefolgt vom Qualitäts-Management (QM). Keine Punkte gibt es im Bereich Wartung (W), Betrieb (B) und Projekt-Management (PM). Die Disziplinen Systemdesign (SD), Implementierung (IMP), Test (T) und Integration (INT) schwächeln.

Crystal
Crystal hat seine Stärke im Bereich Test (T), auch das Qualitäts-Management (QM) und die Implementierung (IMP) werden gut abgedeckt. Mittel bis schwach ausgeprägt sind dagegen Projekt-Management (PM), Requirement-Management (RM), Integration/Einführung (INT) und Wartung (W). Keine Unterstützung gibt es für Betrieb (B) und Systemdesign/technische Konzeption (SD).

Design Driven Development
D3 unterstützt nur wenige Disziplinen im Software Engineering. Am ehesten gilt dies noch für das Requirement-Management (RM), schwache Abdeckung gibt es auch in den Bereichen Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Qualitäts-Management (QM). Keine Unterstützung gibt es für Integration/Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).

Dynamic System Development Method
DSDM spiel seine Stärken in den Bereichen Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Integration/Einführung (INT) aus. Weniger gut werden die Aspekte der Wartung (W), des Betriebs (B) sowie des Projekt- (PM) und Qualitäts-Managements (QM) abgedeckt.

Eclipse Way Process
Aufgrund der Kombination unterschiedlicher Techniken im Eclipse Way Process ergeben sich zahlreiche Stärken. Disziplinen im Software Engineering, die vollständig abgedeckt werden, sind Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T). Nicht ganz so gut schneidet Integration/Einführung (INT) ab. Eine schwache Abdeckung gibt es für Wartung (W) und Qualtitäts-Management (QM), während Betrieb (B) überhaupt nicht unterstützt wird.

Evolutionary Process For Integrating Cots-Based Systems (Epic)
Epic hat seine besondere Stärke im Projekt-Management (PM). Recht gut abgedeckt werden auch Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Test (T) und Integration/Einführung (INT). Mittlere Abdeckung gibt es für den Bereich Implementierung (IMP), während Wartung (W) und Betrieb (B) überhaupt keine Unterstützung finden.

Evolutionary Project Management & Product Development (EVO)
Projekt-Management (PM) und Test (T) sind die Stärken des EVO-Vorgehens. Schwächer fallen Systemdesign/technische Konzeption (SD), Qualitäts-Management (QM), Requirements-Management (RM), Implementierung (IMP) und Integration/Einführung (INT) aus. Die Bereiche Wartung (W) und Betrieb (B) werden überhaupt nicht abgedeckt.

Extreme Programming
Extreme Programming (XP) deckt unter den Disziplinen des Software Engineering die Implementierung (IMP) und den Test (T) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Qualitäts-Management (QM) und Requirements-Management (RM). Mittlere Abdeckung erfährt das Systemdesign/technische Konzeption (SD) sowie die Integration/Einführung (INT), während Wartung (W) und Projekt-Management (PM) nur schwach ausgeprägt sind. Der Betrieb (B) ist nicht abgebildet.

Feature Driven Development
FDD deckt die Aspekte des Systemdesign/technische Konzeption (SD) vollständig ab. Nicht ganz so gut sieht es beim Projekt-Management (PM), Qualitäts-Management (QM), Requirements-Management (RM) und bei der Implementierung (IMP) aus. Wenig Abdeckung gibt es für Test (T) und Integration/Einführung (INT). Wartung (W) und Betrieb (B) werden überhaupt nicht unterstützt.

Iconix
Iconix deckt die Bereiche Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign (SD), Implementierung (IMP) und Test (T) vollständig ab. Recht gut ist die Methode auch, wenn es um die Integration (INT) und das Projekt-Management (PM) geht. Defizite gibt es bei der Wartung (W), der Betrieb (B) wird überhaupt nicht berücksichtigt.

Internet-Speed Development
Internet-Speed Development ist im Bereich Integration und Einführung (INT) hervorragend. Keine Abdeckung erfährt der Bereich Wartung (W) und Qualitäts-Management (QM). Mäßige bis gute Abdeckung erzielt die Methode bei Betrieb (B), Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), Implementierung (IMP) und Test (T).

Lean Software Development
Lean Software Development zeigt seine Stärken vor allem in den Bereichen Qualitäts-Management (QM) und Test (T). Auch das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) sind gut abgedeckt. Vergleichsweise schwach ausgeprägt sind dagegen die Bereiche Requirements-Management (RM), Integration und Einführung (INT), Wartung (W), Betrieb (B) und Projekt-Management (PM).

Microsoft Solutions Framework (MSF)
Das Microsoft Solutions Framework for Agile Software Development deckt die Bereiche Projekt-Management (PM), Implementierung (IMP) und Test (T) gut ab. Mittlere Unterstützung gibt es für Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD)sowie Integration/Einführung (INT). Wartung (W) und Betrieb (B) erfahren dagegen keine Abdeckung.

Mobile-D
Gute bis mittlere Abdeckung bietet Mobile-D für die Software-Engineering-Disziplinen Test (T), Implementierung (IMP), Requirements-Management (RM), Qualitäts-Management (QM) und Projekt-Management (PM). Schwach ausgeprägt sind Systemdesign/technische Konzeption (SD) und Integration/Einführung (INT). Keine Unterstützung gibt es für Wartung (W) und Betrieb (B).

Rapid Application Development
RAD deckt die Belange der Implementierung (IMP) voll ab, gut ist die Methode in den Bereichen Test (T) und Integration/Einführung (INT). Mittlere bis schwache Abdeckung gibt es fürs Requirements-Management (RM), Qualitäts-Management (QM), Projekt-Management (PM) und für die Wartung (W). Systemdesign/technische Konzeption (SD) und Betrieb (B) sind nicht berücksichtigt.

Scrum
Scrum punktet in den Software-Engineering-Disziplinen Projekt-Management (PM) und Requirements-Management (RM). Gut abgedeckt sind auch das Qualitäts-Management (QM) und die Integration/Einführung (INT). Nur mäßige Unterstützung gibt es dagegen für Systemdesign/technische Konzeption (SD), Implementierung (IMP), Test (T) und Wartung (W). Der Betrieb (B) ist nicht abgedeckt.

Test Driven Development
Seine Stärken zeigt TDD naturgemäß im Bereich Test (T), aber auch bei der Implementierung (IMP). Gute bis mittlere Abdeckung gibt es für das Qualitäts-Management (QM) und die Integration/Einführung (INT), während Wartung (W) und Requirements-Management (RM) nur schwach ausgeprägt sind. Keine Unterstützung erfahren die Disziplinen Betrieb (B), Projekt-Management (PM) sowie Systemdesign und technische Konzeption (SD).

Unified Process
Unter den Disziplinen im Software Engineering deckt UP das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD) und die Implementierung (IMP) vollständig ab. Gute Unterstützung gibt es auch für die Bereiche Test (T) und Integration/Einführung (INT). Schwach ausgeprägt sind dagegen die Wartung (W), das Projekt-Management (PM) und das Qualitäts-Management (QM). Den Betrieb (B) unterstützt die Methode nicht.

Agile Unified Process
Der Agile Unified Process (AUP) deckt die Disziplinen Projekt-Management (PM) und Implementierung (IMP) vollständig ab. Gute Unterstützung kommt auch für das Requirements-Management (RM), das Systemdesign/technische Konzeption (SD), den Test (T) und die Integration/Einführung (INT). Schwach ist die Methode dagegen in den Bereichen Qualitäts-Management (QM) und Wartung (W), während der Betrieb (B) überhaupt nicht unterstützt wird.

Essential Unified Process
EssUP hat seine Stärken in den Software-Engineering-Disziplinen Projekt-Management (PM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP). Gut abgedeckt sind auch Test (T), Integration/Einführung (INT) und Requirements-Management (RM). Etwas schwächer ist die Methode beim Qualitäts-Management (QM) und bei der Wartung (W) - der Betrieb (B) wird überhaupt nicht unterstützt.

Open Unified Process
Der Open Unified Process deckt die Software-Engineering-Disziplinen Projekt-Management (PM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD) und Implementierung (IMP) vollständig ab. Auch die Bereiche Test (T) und Integration/Einführung (INT) werden gut unterstützt. Schwach ist OpenUP dagegen bei der Wartung (W), während der Betrieb (B) überhaupt nicht berücksichtigt wird.

Usability Driven Development
Usability Driven Development besitzt seine Stärken in den Bereichen Test (T) und Integration/Einführung (INT). Gut bis befriedigend ist die Methode auch beim Qualitäts-Management (QM), Requirements-Management (RM), Systemdesign/technische Konzeption (SD), bei der Implementierung (IMP) und beim Projekt-Management (PM). Schwächen gibt es bei der Wartung (W), der Betrieb (B) wird nicht unterstützt.

Umfangreiches Reporting

Für den Vergleich erfassten alle Teams ihre Aufwände und Fortschritte. Im deutsch-japanischen Cirquent-Team wurde dazu mit "VersionOne" ein für die agile Softwareentwicklung konzipiertes Planungs- und Monitoring-Tool genutzt, zusätzlich wurden die Aufwände in einem "Effort Monitoring File" akribisch für das Reporting an den Auftraggeber erfasst. Abstimmung und Arbeitsübergaben zwischen den drei regionalen Gruppen des Cirquent-Teams wurden über ein spezielles "Handover File" koordiniert. Um wettbewerbsverzerrende Unterschiede in den Funktionen und den Skills von Mitarbeitern innerhalb der drei konkurrierenden Teams auszuschließen, wurden die angefallenen Aufwände zudem über einen Skill-Faktor-Index gewichtet.

Der Projektverlauf zeigte, wie schnell und gut sich das verteilte Cirquent-Team der ungewohnten 24-Stunden-Entwicklung anpasste. Zunächst als knapp empfunden, erwiesen sich die Übergaben in der einstündigen Schichtüberlappung der drei lokalen Gruppen im weiteren Projektverlauf als gut ausreichend. Die Lernkurve war steil, schnell wussten die drei Gruppen, auf welche Informationen es für die Fortführung der Arbeit in der jeweils nachfolgenden Gruppe ankam.

60 Prozent Zeitersparnis

Wie bei jedem Verchönuch begann man bei NTT Data mit einer Hypothese über die zu erwartenden Resultate. Das Cirquent-Team kalkulierte dabei die Zeitersparnis durch die "aggressive" Kombination einer Follow-the-Sun-Organisation mit agiler Entwicklungsmethodik vor dem Projekt auf etwa 60 Prozent. "Diese Schätzung war fast eine Punktlandung", wie Jürgen Schön später zufrieden feststellen konnte. Verglichen mit dem japanischen Waterfall-Team konnte die Projektzeit auf 42 Prozent reduziert werden. Auch das japanisch-indische Team mit seinem in puncto Schichten und Methodik deutlich moderateren Ansatz brauchte nur 68 Prozent der Projektzeit des Waterfall-Teams.

1. Fokus auf Kernfunktionen
Konzentrieren Sie sich bei der Definition der Anforderungen auf die Kernfunktionen der umzusetzenden Anwendung. Das Pareto-Prinzip gilt in der Regel auch in der Softwareentwicklung. Demnach sollten 80 Prozent der Funktionalität einer Anwendung durch 20 Prozent des Funktionsumfangs erbracht werden.

2. Defensiver Technikeinsatz
Vermeiden Sie technische Spielereien. Es muss nicht immer jedes neueste Feature genutzt werden. Wägen Sie den Einsatz neuer Techniken sorgfältig ab, auch wenn diese eine höhere Entwicklereffizienz und schnelle Ergebnisse versprechen. Grundsätzlich gilt: Je mehr Funktionen, desto komplexer und damit aufwändiger und teurer wird die Anwendungsentwicklung.

3. Einsatz vorgefertigter Komponenten
Prüfen Sie, ob Sie verfügbare Komponenten, Plattformen und Produkte nutzen können. Wenn es sich um nicht allzu komplexe Teillösungen handelt, kann das viel Aufwand ersparen. Allerdings ist eine "Buy"-Entscheidung nicht in jedem Fall der richtige Weg. Wenn die Komponenten erst "hingebogen" werden müssen, bis sie allen Anforderungen gerecht werden, ist das aufwändig und birgt Folgerisiken - etwa den Verlust der Release-Fähigkeit.

6. Nutzung von Erfahrungen
Frühe Fehler können sich zu einem späteren Zeitpunkt zu Kostentreibern entwickeln. Unerfahrene Mitarbeiter sind daher ein Projektrisiko. Zumindest an den neuralgischen Punkten eines Projektes - etwa dem Architekturdesign oder der Projektplanung - sollten Sie den Projektbeteiligten daher erfahrene Mitarbeiter oder externe Berater zur Seite stellen.

7. Stabile Anforderungen und verbindliche Absprachen
Sorgen Sie für stabile Anforderungen und klare Erwartungen an das Softwaresystem sowie für verbindliche Absprachen zwischen den Projektbeteiligten und strukturierte Change-Request-Verfahren. Dieses Vorgehen wirkt auf den ersten Blick etwas bürokratisch, letztlich hilft es aber, häufige Kurswechsel im Projektverlauf und daraus resultierende arbeitsintensive Nacharbeiten zu vermeiden.

8. Kalkulation interner Ressourcen
Bewerten Sie die Verfügbarkeiten und Kapazitäten der internen Projektbeteiligten realistisch. Mitarbeiter, die beispielsweise zusätzlich zu ihrem Tagesgeschäft "nebenbei" im Projekt mitarbeiten, verursachen oft versteckte Mehrkosten, Terminverschiebungen und vor allem Qualitätsprobleme.

10. Realistische Aufwandsplanung
Planen Sie die Aufwände eher vorsichtig. Zu optimistische Einschätzungen - "das ist schnell gemacht", "das ist ja fast fertig" - verfälschen die Kalkulation. Hektisches Nacharbeiten und Terminverzüge verursachen letztlich meist mehr Kosten als sauber geplante Projekte.

Effiziente Übergaben

Kritiker der agilen Entwicklungsmethode und des 24-Stunden-Ansatzes bemängeln oft, dass dieser Gewinn an absoluter Projektzeit sehr teuer erkauft werden muss, weil beispielsweise die Übergaben und Abstimmungen zwischen den Untergruppen oder die Zusammenarbeit mit Anwendern viel Zeit und damit Geld kosten. "Das können wir nach unserem empirischen Vergleich nicht bestätigen. Bereits nach kurzer Zeit verlaufen die Übergaben extrem effizient", resümiert der Cirquent-Berater. "Rechnet man die Kostenvorteile durch die Offshore-Entwicklung ein, sind die Aufwände denen von komplett lokalen Waterfall-Teams in den Industrieländern absolut vergleichbar."

Mit diesem Praxisvergleich sieht Cirquent die Möglichkeit, mit agilen Methoden und Sprints die Projektzeit zu verkürzen, bestätigt - besonders in der Kombination mit einer Follow-the-Sun-Organisation. Bei fast 60 Prozent Zeitersparnis fielen die rund 27 Prozent Mehraufwand, die aufgrund der Sprint-Abstimmungen und Übergaben im Projekt entstehen, weniger bedeutend aus, als von Kritikern agiler Methoden angenommen.

Den von vielen CEOs und CIOs gefürchteten Risiken einer Offshore-Entwicklung halten die Berater entgegen: Wer nur die Geschwindigkeitsvorteile nutzen will, aber die Gefahren von Offshore-Entwicklungen scheut, kann grundsätzlich auch ein Drei-Schichten-Modell in der lokalen IT-Abteilung einführen. Allerdings habe man die Erfahrung gemacht, dass der regionale Abstand die formal und inhaltlich geordnete Übergabe fördert, denn der übliche Plan B mit gemeinsamen Überstunden entfalle hier. (ue)