Es werden sehr kurze Releasezyklen (max. 6 Monate für das erste und max. 3 Monate für alle nachfolgenden Releases) durchgeführt, die weiter in Iterationen (je Iteration max. 4 Wochen) unterteilt werden.

Dadurch erhält das Projekt schnell und häufig Feedback von den Anwendern über das entwickelte System. Außerdem werden viele technische Risiken (Performance, Last, Anbindung von Middleware etc.) dadurch automatisch frühzeitig erkannt.

Eine notwendige Bedingung für dieses Vorgehen ist natürlich, dass bei den Anwendern die allfällig nötigen Voraussetzungen personeller, technischer, räumlicher, zeitlicher etc. pp. Art gegeben sein müssen. Wenn dem so ist, dann muss man noch das Glück haben, dass die Anwender das System auch wirklich nutzen, und es nicht in der Ecke vor sich hinstaubt und man nur Pseudorückmeldungen erhält.

Wenn die Anwender es nicht für sinnvoll halten, das System zu nutzen - ist das nicht auch sehr wichtiges Feedback für das Projekt? -- IljaPreuß

Dann ist doch auch sehr wichtig, *das* möglichst früh zu wissen, damit man reagieren kann. Schließlich ist das genialste System nichts wert, wenn es von den Anwendern nicht akzeptiert wird, warum auch immer. Im obigen Fall könnte man sich z. B. entschließen, die Oberfläche des neuen Systems stärker an das alte anzulehnen - zumindest optional/übergangsweise.

Als Diskussionsanstoß/Kontrapunkt ist anzumerken, dass sich die Releasezyklen der 'stabilen' Distribution von DebianGNULinux im ein- bis zwei-Jahres-Bereich bewegen. Abgesehen von dem internen Problem 10.000 Pakete gleichzeitig in einen akzeptablen Zustand zu bringen, wird der Standpunkt verteten, daß zu häufige Systemupgrades eine Risikoquelle an sich sind bzw. in Produktionsumgebungen wegen Verfügbarkeitsverpflichtungen oder Arbeitsaufwand bei einem Upgrade als unpraktikabel angesehen werden.

Das Beispiel Debian hinkt insofern, als dass diese Software in der Entwicklergemeinde selbst schon eine sehr breite Nutzerbasis hat. KurzeReleaseZyklen ist außerdem eher was für Auftragsarbeiten. Die kommerzielle Softwareentwicklung hat seit langem das Problem, dass ein hoher Anteil Projekte scheitert. Ein Ansatzpunkt: Eine Software muss Anforderung des Kunden erfüllen, die sich aus unterschiedlichsten Gründen auch während der Entwicklungszeit noch ändern. Sie wird dies besser leisten, wenn der Kunde früh sieht, wie die Entwickler die Anforderungen verstanden haben und umsetzen. Meine Erfahrungen mit kurzen Release-Zyklen sind in diesem Sinne ausgesprochen positiv. In der Wartung (also gerade dort, wo der Kunde den Fehler besonders schnell behoben sehen möchte) ist jedoch äußerste Vorsicht geboten. Ein kleiner Patzer, und das ganze Produktivsystem liegt lahm. -- SaschaDördelmann