- Agilität (94)
- Allgemein (10)
- Ankündigungen (29)
- Buchtipp (13)
- Crystal (7)
- Konferenzen (23)
- Kunden (5)
- Lean Software Development (1)
- Management (36)
- Planung (20)
- Politik (14)
- Praktiken (7)
- Refactoring (11)
- Scrum (15)
- Software Design (10)
- Surftipp (28)
- Testgetriebene Entwicklung (8)
- Werkzeuge (7)
- Zitate (8)
- 21.1.2010: it-agile und Coldewey Consulting gehen zusammen
- 11.12.2009: Aufspalten einer User Story
- 6.11.2009: Vortrag auf der W-Jax zu langfristiger agiler Planung
- 2.10.2009: Alistair Cockburns Keynote "I come to bury Agile, not to praise it" als Video
- 22.9.2009: Apple und die Macht einer Vision
- 21.9.2009: Pair Programming in der New York Times
- 10.9.2009: Neue XING-Gruppe zu Lean Software Development
- 9.9.2009: CSM+Crystal Kurse mit Alistair Cockburn
- 7.8.2009: Alistair Cockburn gibt CSM-Kurs in Deutschland im November
- 21.7.2009: Folien der Karlsruher Entwicklertage online
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Juni 2009
- Mai 2009
- April 2009
- März 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- September 2008
- Juli 2008
- Juni 2008
- Mai 2008
- April 2008
- März 2008
- Februar 2008
- Januar 2008
- Dezember 2007
- November 2007
Ist agile Entwicklung billiger?
Eine der Standardfragen zu agiler Entwickung lautet: “Können Sie denn nachweisen, dass das billiger ist, als traditionelle Vorgehensweise?”
Der Frage liegt ein interessantes Bild zugrunde, nämlich dass es auf der einen Seite ein Projekt gäbe, also ein definiertes Ergebnis, auf der anderen Seite einen Prozess, der auf einer völlig anderen Dimension steht und das Ergebnis nicht beeinflusst.
Dieses Bild spiegelt die Realität der Softwareentwicklung leider nicht so ganz vollständig wider: Agile Teams entwickeln die fachliche Lösung in enger Zusammenarbeit mit den Fachexperten. Das tun sie nicht, weil sie zu faul oder unfähig wären, Pflichtenhefte, Lastenhefte und Spezifikationen zu schreiben (die meisten Agilisten, die ich kenne, können das deutlich besser, als der Durchschnitt), sondern weil sie überzeugt sind, auf diese Weise ein fachlich und wirtschaftlich besseres Ergebnis zu erhalten.
Das bedeutet auf jeden Fall, dass das Ergebnis anders sein wird, als mit traditioneller Vorgehensweise. Nur die Kosten zu vergleichen, vergleicht also Äpfel mit Birnen. Wer noch dazu Schätzungen vergleicht, statt der Gesamtkosten über die Lebenszeit des Softwaresystems, vergleicht auch noch mit Birnen, deren Bäume noch nicht einmal gepflanzt sind — in der Regel auf Böden, von denen man nicht einmal weiß, ob da Obstbäume überhaupt gedeihen.
Ist das jetzt der Versuch, sich einem “objektiven” Vergleich zu entziehen? Ganz im Gegenteil, wir sollten nur die richtigen Parameter vergleichen: Kundenzufriedenheit, weil das das Primärziel jedes Projekts sein sollte, und Motivation des Teams, weil damit die Investition in Ausbildung und Aufbau des Teams, der Kundenbeziehung und des Wissens geschützt wird. Bei beiden Kriterien schneidet agile Entwicklung in allen mir bekannten Untersuchungen signifikant besser ab, als traditionelle Verfahren (auch wenn es natürlich Ausreißer gibt).
Wem das zu “unwissenschaftlich” ist, der wird nicht um die Mühe herum kommen, zwei Teams an die gleiche Aufgabe zu setzen und unter wirklich vergleichbaren Bedingungen Kosten und Nutzen zu vergleichen. Leider habe ich bisher noch niemanden gefunden, der es dann doch so genau wissen wollte und bereit gewesen wäre, das Geld dafür in die Hand zu nehmen. Und das wäre natürlich auch nur ein einzelnes Projekt, das nicht repräsentativ wäre, und keinerlei “wissenschaftlich fundierte” Aussage zulassen würde…