Netzwerkprodukte (22 / Agile Softwareentwicklung/2)

(Agile Softwareentwicklung/1)

(Netzwerkprodukte)

Das „Manifesto for Agile Software Development” sagt:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Quelle

Eric S. Raymond wundert sich, warum man diese Punkte so hervorhebt, obwohl sie bloß all jene Grundsätze zusammenfassen, denen die Community der Hacker schon seit jeher folgt (wobei er hervorhebt, daß „Agile” diese Grundsätze besser formuliert, als dies je zuvor geschah[1]). Damit liegt er zunächst natürlich völlig richtig - übersieht dabei aber eine ganze Reihe von Werkzeugen, die eine zentrale Rolle für Scrum und Co. spielen.

Die agilen Methoden versuchen keineswegs, den Entwicklern ein schönes Leben zu verschaffen; sie stellen lediglich in Rechnung, daß Softwareentwicklung ein kreativer Prozeß ist, den man nach anderen Regeln organisieren muß als z.B. die Arbeit einer Sekretärin, wenn man erreichen will, daß für Sales und Marketing Planbarkeit entsteht. - Auf den letzten Halbsatz kommt es an: man versucht hier, Kreativität Regeln der Verwertung zu unterwerfen.

Softwareentwicklung funktioniert letztlich nicht anders als z.B. das Schreiben eines Buchs. Es passiert regelmäßig, daß irgendein Einfall wie aus dem Nichts auftaucht, ausprobiert wird, um verworfen oder weiter gesponnen zu werden. Dabei gehört es zur gängigen Praxis, daß ein vielversprechender Ansatz, der ausgiebig diskutiert und spezifiziert wurde, sich nach längerer Zeit als Sackgasse herausstellt. Umgekehrt kann ein zunächst viel zu kompliziert (oder auch zu blauäugig) erscheinendes Design dazu führen, daß sich bei der Betrachtung eines Prototypen überraschende Perspektiven ergeben, an die - in der Phase der Spezifikation - niemand gedacht hatte.

Kreativität ist nicht plan- oder berechenbar. Man kommt nicht weiter, wenn man versucht, sie gewaltsam zu erzwingen. Es ist also eine elementare Anforderung, daß man auf Änderungen - möglicherweise sogar in Bezug auf die strategischen Ziele - vorbereitet ist und ihr Auftauchen als notwendigen Teil des Prozesses begreift.

Der erste Schritt besteht darin, daß man in iterativen Zyklen vorgeht. Das ist nicht neu - eine These in ESR's Buch „The Cathedral and the Bazaar” lautet: „Release early. Release often. And listen to your customers”. Bei den „Agilen Methoden” geht es natürlich - wie bei Open Source - zunächst darum, möglichst rasch Feedback vom User zu bekommen, um die Qualität der Features zu sichern. Daneben aber will man zwei Dinge erreichen, die den politischen Ideen von Open Source[2] letztlich entgegen stehen: man will die Vertragsverhandlungen mit dem User (der hier der zahlende „Customer” ist) vereinfachen - zumal ein zufriedener Kunde es nicht nötig hat, die Gerichte zu bemühen. Zum zweiten - und das ist in meiner Sicht der zentrale Punkt - bezieht man in die Iterationen auch die Aufwandsabschätzungen ein.

  1. [1] Den Begriff „Refactoring” biegt er in dem Artikel allerdings in einer Weise, daß sich mir die Fußnägel zusammenrollen.
  2. [2] Nachtrag: Es gibt einen feinen, aber entscheidenden Unterschied zwischen „Open Source” und „Free Software”, den ich nicht recht auf dem Zettel hatte, als ich Open Source (wie oben im Text) politische Qualitäten unterstellte.

[Ich breche für heute mal ab.]