Ein hochdisziplinierter Software-Entwicklungsprozess für kleine Teams: XP (Extreme Programming)
Die Problematik des herkömmlichen Software-Entwicklungsprozesses - oder warum die Fixpreisverträge nicht immer von Vorteil sind
Der herkömmliche Software-Entwicklungsprozess läuft folgendermaßen ab: der Kunde bestimmt die Aufgabe, sagt seine Anforderungen, und das Software-Entwicklerteam stellt einen Plan zusammen, der den Weg zur Verwirklichung beschreibt, einschließlich Vergütung und Fertigstellungstermin. Wenn das Projekt einmal gestartet ist, wird dieser Plan als "Standard" angenommen, und jede Abweichung als Fehler aufgefasst.
Es ist leicht einzusehen, dass es unmöglich ist, alle Änderungen auf dem Markt, in den Technologien und im Geschäftsleben voraus zu sehen, deshalb ist es in den meisten Fällen fast unmöglich einen Plan aufzustellen, der ohne jegliche Veränderung eingehalten werden kann. Bei der herkömmlichen auf jede Einzelheit eingehende Software-Planung sitzen wir in der Falle unserer historischen Denkweise. Dieser Denkweise nach wird der Software-Entwicklungsprozess ähnlich wie die Ingenieurarbeit aufgefasst: bei den Ingenieuringsprojekten (Brücken, Gebäuden) ist es sehr kostspielig auch das kleinste Detail zu ändern. Auch die Kunden bevorzugen Festpreisvorträge, weil sie glauben, dass es sehr teuer sei an der Software etwas zu ändern. Das stimmt eigentlich, wenn wir einen nach festgesetztem Plan, und für Festpreis ablaufenden Software-Entwicklungsprozess analysieren. Bei diesen Projekten bekommt das Entwicklerteam die Anforderungen des Kunden ganz detailliert, und das Programm wird nach diesen Kriterien erstellt. Die Testphase kommt erst zum Schluss des ganzen Projekts, bevor das Programm dem Kunden übergeben wird. Erst nach der Übergabe des Projekts stellt es sich heraus wie weit es die Anforderungen des Kunden erfüllt, welche Änderungen nötig sind - und in diesem Falle sind die Änderungen wirklich teuer.
Der Software-Entwicklungsprozess ist in der Wirklichkeit ein gegenseitiger Prozess, zwischen Kunde und Entwicklungsteam.
Dafür ist in den letzten 5 Jahren der sog. Extreme Programming (kurz XP) erschienen, der den Programmierungsprozess auf eine neue Grundlage stellt.
XP ist ein hochdisziplinierter Software-Entwicklungsprozess für kleine Teams, die während der Entwicklung mit sich rasch ändernden Anforderungen konfrontiert werden. Die wichtigsten Werte von XP sind Kommunikation, Einfachheit, feedback und Mut. XP beruht auf der Beobachtung, dass die Kosten zur Änderung von Software durch einfache Verfahren reduziert werden können. XP fasst Software-Entwicklungsprozess wie einen ständigen Dialog mit dem Kunden auf, und zur Anforderungsdefinition wird auch ein Dialog geführt, anstatt ausführliche Dokumente zu schreiben.
Ein XP Projekt besteht aus kürzeren Iterationen (im allgemeinen zwei-oder dreiwöchigen Iterationen einige Projekte arbeiten aber mit einwöchigen Iterationen). Die kurzen Iterationszeiten sichern, dass wir innerhalb von sehr kurzer Zeit feedback bekommen. In den Software-Entwicklungsprozess werden ständig funktionale Abnahmetest integriert weil das frühe Testen auch zu den Kernbegriffen von XP Programming gehört, sowie die Programmierung in Paaren, damit die Code Reviews auch zur Geltung kommt.
Am Ende jeder Iteration bekommt der Kunde eine funktionierende Software, die er bereits anwenden kann, und eigentlich testen wie alles in der Wirklichkeit funktioniert. Für XP Programming ist der Kontakt mit dem Kunden sehr wichtig, da die ganze Methode auf der engen Zusammenarbeit basiert, so wird häufig ein direkter Ansprechpartner auf Kundenseite ins Team integriert, so nach dem Schluss einer Iteration, kann der Kunde direkt entscheiden wir die nächste Iteration weitergehen soll, damit das ganze Projekt den größten Gewinn bringt, und er kann sehen wie weit die ursprünglichen Anforderungen erfüllt wurden. Dadurch dass der Kunde am Ende jeder Iteration eine funktionierende Software bekommt, wird die hohe Qualität der Software gesichert. Die kleineren Iterationen und das ständige Testen sichern auch, dass die eventuellen Bags schnell gefunden werden können, und es genügt, immer auf die letzte Iteration zurückzugreifen, und nicht auf das ganze Programm.
Die XP Methode minimalisiert das Risiko dass die erstellte Software in der Wirklichkeit nicht das ursprüngliche Ziel erfüllt, und nicht benutzt wird. Wenn bei der Übergabe einer Iteration es so aussieht, dass die gelieferte Software nicht den erwünschten Anforderungen entspricht, kann die ganze Arbeit ohne großes Risiko beendet werden. Bei Festpreisprojekten sieht es anders aus. Da stellt es sich nur beim Schluss des ganzen Projektes heraus, dass das Entwicklerteam nicht dass entsprechende Software liefern kann - dann ist aber schon viele wertvolle Zeit vergangen. Einige auf die Weise verlaufende Festpreisprojekte führten schon zu Prozessen, zB das RAVC gegen Unisys.
Wenn das Entwicklerteam seine Leistungsfähigkeit gut einschätzt, gibt XP dem Kunden mehr Zufriedenheit als ein Festpreisprojekt, weil er die Schritte der Entwicklung verfolgen kann, und die funktionierende Software so früh wie möglich benutzen kann. Es kann vorkommen, das die ursprüngliche Zielsetzung des Kunden früher, mit wenigeren Schritten erreicht wird als geplant, und das erhöht noch seine Zufriedenheit, und letztendlich leben alle Entwicklerfirmen von zufriedenen Kunden.
Unser Entwicklerteam ist der Meinung, dass in unserer turbulenten Geschäftswelt für kleinere Entwicklergruppen XP die beste Lösung ist.
XP funktioniert prima bis zu einer Gruppenzahl von 10 Entwicklern.
Bei größeren Projekten kann man mit einer so kleinen Gruppe natürlich nicht auskommen, da benötigt man Hunderte von Entwicklern.
Bei diesen Projekten steht RUP (Rational Unified Process) als Lösung - das möchten wir hier aber nicht erörtern.
zurück
|
