Früher stellte das Wasserfall-Modell die effektivste Art und Weise dar, um Software zu entwickeln. Diese Methode bedingt, dass man nicht beginnen kann, ehe bekannt ist, was getan werden muss, und dies bis ins kleinste Detail.
Die Erfahrung zeigt, dass diese Herangehensweise ein nicht konstruktives Gefühl der Kontrolle bewirkte. Sie vermittelte den Eindruck, dass Risiken gemindert werden. Es lag die Annahme zugrunde, wenn alle Erfordernisse im Voraus bekannt sind, die notwendig für die Lieferung der Software sind, der Arbeitsaufwand genau eingeschätzt werden kann. Wir erprobten, dass das Gegenteil wahr ist: Projekte benötigten mehr Zeit, wurden kostenintensiver, bargen mehr Risiken als eingeplant. Die ursprünglich spezifizierten Anforderungen am Anfang des Projektes waren oft weit von dem entfernt, was tatsächlich geliefert werden sollte und was der Anwender erwartet hatte.
Einige Gründe, weshalb dies eintrat: Oftmals ist die Liste der „must-have“-Anforderungen am Anfang des Projektes lang und die Anwender zögern lange, diese Liste zu unterzeichnen. Möglicherweise weil sie vermeiden wollen, dass etwas fehlt oder weil sie nicht wissen, was sie vielleicht noch benötigen werden. Die daraus resultierende Deutung der Spezifikationen, sowohl durch die Entwickler als auch durch die Anwender führte zu umfangreichen Überarbeitungen und Zeitverlusten. Einbringen von neuen Anforderungen von den Anwendern sind in der Entwicklungsphase nicht vorgesehen.
Wir suchten nach einer anderen, flexibleren Herangehensweise und beschlossen weitestgehend Agile Prinzipien anzuwenden. Wir studierten die Methode, und weit wichtiger noch, wir setzen diese in der Praxis um. Je mehr wir Agile Methoden nutzen, desto mehr sind wir überzeugt, dass es die richtige Vorgehensweise ist, um die Entwicklung zeitlich und finanziell zu optimieren. Das Beste ist jedoch, dass es uns hilft, die Erwartungen unseren Kunden zu steuern.
Agiles Vorgehen gibt uns die Möglichkeit: Zusammenhängende Features aufzulösen in steuerbare Einheiten. Es lässt uns die Anwender-Erfahrung bzw. –Story als Ausgangspunkt nehmen und nicht das Design oder den Aufbau. Es lässt uns exzessiven Bestand minimieren, indem nicht zu früh auf zukünftige Features fokussiert wird. Es lässt uns Probleme behandeln, erst wenn sie auftreten und nicht im Voraus. Wir erhalten Anwender-Rückmeldungen rechtzeitig und häufig, so dass wir die Entwicklungsrichtung dem raschen Tempo von Veränderungen anpassen können.
Agiles Vorgehen, Schrittweise Vorgehen.
Sie interessieren sich für Agiles Vorgehen? Es gibt hervorragende Quellen im web.
http://www.youtube.com/watch?v=OWvSnYjqOTQ
http://www.poppendieck.com
http://en.wikipedia.org/wiki/Agile_software_Entwicklung
http://www.computerworld.com/printthis/2004/0,4814,90325,00.html
Oder Sie rufen uns an: 040 180 539 03
