Kleine Releases

Es gibt mehrere Gründe, kleine Releases zu machen. In traditionellen Entwicklungsansätzen kann es sein, daß für ein Release mehrere Jahre vergehen können.

Beispiel: Eine Software für die Polizeifahndung in Deutschland (INPOL-neu) wurde 1992 von der Innenministerkonferenz der Länder beschlossen. Nach heutiger Planung (Stand 23.10.2001) sollte das System per 15. Oktober 2001 das bisherige System vollständig ersetzen (Quellen: Heise, Golem).

Es gibt jedoch eine Reihe von Nachteilen großer Releases. Beispielsweise wird es für Kunden immer wichtiger, dass sich eine Investition sich möglichst schnell rechnet. Je eher also ein System produktiv eingesetzt werden kann, um so eher kann damit auch Geld verdient werden.

Kundenanforderungen unterliegen fortlaufenden Änderungen. Die zunehmende Globalisierung, aber auch das zunehmende informationelle Zusammenwachsen der Welt führen zu Anforderungsänderungen in immer kürzeren Zeitabschnitten.

Mit großen Releases kann zwar viel Funktionalität auf einmal geliefert werden. Aber typischerweise werden die Anforderungen zu Beginn der Implementierung, also am Anfang des Releasezyklus, festgelegt. Während der Projektlaufzeit verändern sich die Anforderung, z.B. weil der Markt sich weiterentwickelt. Wenn dann das System ausgeliefert wird, kann es dann passieren, dass die Funktionalität den sicher veränderten Anforderung nicht mehr in hinreichendem Maß entspricht.

Kleine Releases, eine der 12 Arbeitsmethoden von XP, können das Risiko zwar nicht vollständig ausschließen; durch die zeitnahe Auslieferung von Funktionalität hat aber der Anwender (Kunde) dann aber mindestens zwei Vorteile:

Er kann die bereits fertig implementierte Funktionalität bereits produktiv einsetzen.
Er hat eine zusätzliche und dabei zugleich einfache Möglichkeit, den weiteren Projektverlauf zu beeinflussen, z.B. indem er die Prioritäten verändert, oder auch Funktionalitäten hinzufügt oder aus den Anforderungen herausnimmt.

Ad 1: Die Funktionalität sind deshalb einsetzbar, weil sie reproduzierbar und automatisch auf Richtigkeit getestet sind. Dafür werden Komponententests und Akzeptanztests verwendet.

Ad 2: Immer zu Beginn eines Releasezyklus wird ein Planungsspiel gemacht. Dazu spezifiziert der Kunde seine Anforderungen mit Hilfe von Benutzergeschichten. Es können zu diesem Zeitpunkt Benutzergeschichten hinzugefügt und existierende Benutzergeschichten verändert oder sogar komplett entfernt werden, z.B. weil sie obsolet sind.

Tipps

Ein kleines Release hat eine typische Dauer von etwa 3 Monaten.
Ein kleines Release sollte in keinem Fall länger als 4 Monate dauern.
Ein extrem kurzes Release dauert 1 Tag.

Beispiel: In einem schweizerischen Versicherungskonzern wird ein Smalltalk-basiertes System im Aussendienst eingesetzt. Mit Hilfe von XP wurde die Release-Dauer auf einen Tag reduziert. Mit anderen Worten: Jeden Tag wurde released. (Quelle: Persönliches Gespräch mit Kent Beck)

Tipps