Agile Softwareentwicklung
Das Problem: Der Kunde hat oft nur eine grobe Vorstellung von dem was er will. Bsp.: Ich brauche ein System, um meine Kundenanfragen besser im Überblick zu haben.
Da stellen sich gleich eine ganze Reihe von Fragen:
- Worum geht es bei den Kundenanfragen?
- Wie kommen die Kundenanfragen ins System?
- Wie wird auf Kundenanfragen reagiert?
- Was ist mit System gemeint?
- Wer sind die Kunden?
- usw.
Einige der Fragen lassen sich recht schnell beantworten, andere sind für den Auftraggeber so offensichtlich, dass er vergisst, sie uns mitzuteilen.
In der klassichen Softwareentwicklung wird jetzt ein Pflichtenheft erstellt, indem soviel wie möglich festgeschrieben wird. Es erfolgt ein Angebot und dann der Auftrag. Mit besten Wissen und Gewissen wird dann das Pflichtenheft umgesetzt, und am Ende die Software ausgeliefert. Und jetzt?
Der Kunde stellt fest, es ist zwar das, was ich beauftragt habe (hoffentlich stell er das fest), aber nicht das was ich benötige. Und warum? - Weil vieles, was dem Kunden selbstverständlich erschien, nicht umgesetzt wurde, da es im Pflichtenheft fehlt. Und jetzt?
Anders bei der agilen Softwareentwicklung:
Es wird nicht am Anfang der komplette Funktionsumfang festgelegt. Sondern im Absprache mit dem Auftraggeber gehen wir Stück für Stück vor. Und zwar nach Wichtigkeit. Auf diese Weise kann auf Änderungen sofort reagiert werden, es wird während der Umsetzung erkannt, was weiter benötigt wird. Also, mit weniger Bürokratie mehr für den Auftraggeber erreichen. Dies bedeutet für den Auftraggeber die Erkenntnis, das Softwareentwicklung ein fortlaufender Prozess ist und keine einmalige Anschaffung. Aber selbst beim Kauf von Software von der Stange wird oft übersehen, dass es später Updates gibt, die gekauft werden, oder Module zur Ergänzung.
