Alistair Cockburn: Agile Software Development – The Cooperative Game

Alistair Cockburn: Agile Software Development – The Cooperative Game

Alistair Cockburn
Agile Software Development: The Cooperative Game

2. Auflage
2007, xxxiv, 467 Seiten, Broschur
Addison-Wesley
ISBN: 978-0-32148-275-4



Agile Software Development: The Cooperative Game ist ein sehr umfangreiches und lehrreiches Buch über agile Softwareentwicklung, über deren Geschichte, Grundlagen, Prinzipien und Praktiken. Es geht dabei um das „Big Picture“ der Softwareentwicklung – das Zusammenspiel von Menschen, Technologie, Organisation und Methodologie. Komplexes wird verständlich dargestellt und Zusammenhänge werden klar erläutert – ein absolut lesenswertes Buch.


Struktur

Dieser Abschnitt befasst sich mit der Strukturierung der zweiten Auflage von Cockburns Buch Agile Software Development: The Cooperative Game, wobei auch immer wieder auf die Änderungen gegenüber der ersten Auflage eingegangen wird. Insgesamt handelt es sich um eine relativ lange und „technische“ Betrachtung, die für die meisten Leser vollkommen uninteressant sein dürfte, weswegen der Abschnitt ohne großen Verlust auch übersprungen werden kann.

Alistair Cockburns ambitionierter Plan ein neues Vokabular für die Beschreibung der Softwareentwicklung zu erschaffen, schlägt sich selbstverständlich in der Struktur des Buches nieder. So fängt das Buch nach den zwei Vorwörtern (für die erste und zweite Auflage) mit dem nullten Kapitel an, wobei der Zusatz Kapitel fehlt (in der ersten Auflage war das Kapitel 0 noch Introduction benannt), in dem Cockburn fragt, was man wissen kann und was davon übermittelbar ist. Der Name des Kapitels lässt die Antwort erahnen: Unknowable and Incommunicable.

Weiter geht es im ersten Kapitel (A Cooperative Game of Invention and Communication) mit der Frage danach, wie sich das Vorgehen der Softwareentwicklung am besten beschreiben ließe. Über das Betrachten des Einzelnen im zweiten Kapitel – betitelt Individuals – und den Teams im dritten – betitelt Communicating, Cooperating Teams (im Inhaltsverzeichnis heißt dieses Kapitel Communication, Cooperating Teams, es handelt sich dabei aber höchstwahrscheinlich um einen Fehler) –, erreicht Cockburn zum Thema Zusammenarbeit, genauer: zu den im vierten Kapitel behandelten Methodologies.

Im fünften Kapitel betitelt Agile and Self-Adapting konvergiert das in den vorherigen Kapiteln Schritt für Schritt Aufgebaute zu der (zumindest damals) modernen Antwort auf die Probleme der Zeit: die Agilität. Den Abschluss macht das Kapitel The Crystal Methodologies, in dem Cockburns eigene Methodologien-Familie beschrieben wird.

Mehrere Anhänge folgen auf das sechste Kapitel. Anhang C (Afterword) ist dabei ein Zusatz der zweiten Auflage, Anhang C der ersten Auflage (Books and References) rutscht ein Buchstabe weiter im Alphabet und wird zu Anhang D.

Jedem Kapitel wird ein weiteres Kapitel mit dem Zusatz Evolution beigefügt. Diese „Evolution“-Kapitel haben jeweils die Kapitelnummerierung der vorhergehenden Kapiteln, die aber von einem Punkt und einer Eins gefolgt sind. So z.B. wird Chapter 2 Individuals das Kapitel Chapter 2.1 Individuals: Evolution beigefügt usw. Wie leicht vermutet werden kann, handelt es sich dabei um Erweiterungen der zweiten Auflage, also um eine „Evolution“ gegenüber der ersten. Anhang B verfügt ebenfalls über einen „Evolution“-Teil. Bei Anhang A wird das Muster dadurch gestört, dass die Erweiterung den „Evolution“-Zusatz nicht enthält. So heißt Anhang A The Agile Software Development Manifesto und Anhang A.1 The Agile Software Development Manifesto and the Declaration of Interdependence. Die Declaration of Interdependence kann als Weiterentwicklung des Manifests für Agile Softwareentwicklung betrachtet werden, somit wird – in einem gewissen Sinne – das Muster doch nicht gebrochen.

Die einzelnen Kapitel (also die „vollen“ Kapitel, nicht die Erweiterungen der zweiten Auflage) enden jeweils mit einem kurzen Abschnitt in dem der Autor der Frage nachgeht, was man als Leser nach dem Lesen konkret machen kann. Sinnvollerweise heißen die meisten dieser Abschnitte What Should I Do Tomorrow? oder ähnlich.

Die folgende Zusammenfassung geht in den meisten Fällen nicht explizit auf die Erweiterungen der zweiten Auflage (also auf die „Evolution“-Kapitel) ein. Somit wird z.B. unter Kapitel 0: Unknowable and Incommunicable in der folgenden Zusammenfassung sowohl das Kapitel 0 als auch das Kapitel 0.1 des Buches behandelt. Eine erwähnenswerte Ausnahme bildet das Kapitel fünf, wo der Text in der zweiten Auflage erheblich erweitert wurde; da wird klar zwischen Kapitel 5 und Kapitel 5.1 unterschieden.

Inhalt

Kapitel 0: Unknowable and Incommunicable

Ohne Scheu macht sich Cockburn gleich im ersten Kapitel von Agile Software Development (also das nullte – für Details siehe die Struktur des Buches) daran, einige sehr schwierige Fragen aufzuwerfen – und zu beantworten –, Fragen, die aber von grundlegender Wichtigkeit für das behandelte Thema und für die Entwicklung der weiteren Kapitel sind:

  • Was können wir wissen und was von dem, was wir wissen können, lässt sich auch übermitteln?
  • Wie muss das, was sich übermitteln lässt, gestaltet sein, damit es verstanden wird?
  • Hängt die Art der Übermittlung vom Zuhörer ab, wenn ja, inwiefern?

Was sich sehr philosophisch anhört, ist es auch – in einem gewissen Maße, zumindest. Cockburn hat jedoch bei der Diskussion der Fragen ein festes Ziel vor Augen und verliert sich nicht in unnötigen Details. Nichtsdestotrotz fühlt sich aber verpflichtet, den Leser vor der Abstraktheit des nullten Kapitels zu warnen (S. 1).

Die Kapitelüberschrift gibt die vereinfachte Antwort auf die ersten beiden aufgeworfenen Fragen: Vieles lässt sich nicht wissen und Vieles lässt sich nicht übermitteln. Aber schlimm ist das aus Cockburns Sicht nicht: man müsse nicht alles wissen und verstehen und man müsse auch nicht absolut präzise kommunizieren können – es reiche, wenn die Kommunikation gut genug funktioniere. Was gut genug bedeutet, hängt aber unter anderem auch von den kommunizierenden Personen ab.

Wer, welche Informationen benötigt und wie diese aufbereitet sein müssen, damit sie verstanden werden, hängt vom Wissen, Können und von der Erfahrung ab – das dreistufige Modell Shu-Ha-Ri sollt dabei helfen, die Entwickler abhängig von ihrem Können und ihrer Erfahrung einzustufen. Die drei Ebenen beschreiben die drei Stufen, die ein „Schüler“ auf den Weg zur Meisterschaft aufsteigen muss. Shu ist dabei die Anfängerstufe – wer sich auf dieser Ebene befindet, braucht klare Antworten und Vorgaben – Ri ist entsprechend die Meisterebene, der Schüler ist nun Meister, kennt unterschiedliche Wege zum Ziel und weiß wann von der reinen Lehre abgewichen werden kann und vielleicht sogar muss. Die Moral ist nun, dass abhängig von der Ebene, auf der man sich befindet, die Information anders strukturiert sein muss und auch einen anderen Umfang benötigt.

Kapitel 1: A Cooperative Game of Innovation and Communication

Nachdem die Grundlagen geschaffen sind, widmet sich Cockburn einer weiteren schwierigen Frage, welche die Softwaregemeinde seit Jahrzehnten beschäftigt: was ist nun Softwareentwicklung? Ist das Schreiben von Software eine Ingenieursdisziplin? Oder vielleicht ein Handwerk? Oder ganz was anderes? Nachdem der Autor mehreren Metaphern nachgeht, legt er sich fest: am ehesten dürfte es ein kooperatives Spiel sein, bei dem es um Erfindungsgeist und Kommunikation geht. Zwei Ziele hat laut Cockburn dieses Spiel:

  1. das erste und wichtigste Ziel ist laufende Software zu produzieren
  2. das zweite, nachgelagerte, aber letztendlich nicht minder wichtige, ist sicherzustellen, dass das Spiel eine weitere Runde gespielt werden kann – es geht letztendlich um Wartung und Dokumentation.

Das alles könnte schon als ziemlich kompliziert betrachtet werden, um es aber noch komplizierter zu machen, beschreibt Cockburn zwei weitere – mit dem „Hauptspiel“ eng verzahnte – „Spiele“:

  • das Karrierespiel jedes Einzelnen (von der Art eines unendlich wiederholten Spiels) und
  • das Existenzspiel eines Unternehmens (ebenfalls unendlich wiederholter Art).

Das Zusammenspiel der drei Spiele, führt selbstverständlich zu einem äußerst komplexen Ganzen, das jedoch nicht weiter vertieft wird, das Ziel des Buches bleibt ganz klar die Softwareentwicklung.

Kapitel 2: Individuals

Der Leser hat bis zum zweiten Kapitel mehrere wichtige Punkte erfahren:

  • wissen und verstehen kann man nicht alles
  • das, was man weiß und versteht, kann man sowieso nicht absolut präzise weitergeben (was aber nicht unbedingt schlimm ist) und
  • das Bauen von Software kann als ein kooperatives Spiel, das zwei Ziele hat, betrachtet werden.

Im zweiten Kapitel widmet sich der Autor nun denen, die das Spiel spielen: den Programmierern (also dem Menschen als Individuum). Cockburn geht dabei wieder einer Reihe schwieriger Fragen nach. Hier einige davon:

  • Was können Menschen schlecht (allgemeine menschliche Schwächen)?
  • Was können sie gut (allgemeine menschliche Stärken)?
  • Welche Variablen beeinflussen unser Verhalten?

Die Schlussfolgerungen Cockburns zeichnen ein komplexes Bild, aber Gründe zur Verzweiflung gibt es aus seiner Sicht eher nicht: Wir sind sehr unterschiedlich und nicht unbedingt konsequent, es gibt viele Situationen in denen wir nicht mit unseren Eigenschaften brillieren – so ist Disziplin z.B. keine menschlichen Stärken – aber Menschen haben auch Stärken und solange wir die Methodologien um diese Stärken herum aufbauen, sind wir besser dran, als wenn wir sie ignorieren. (Dies bedeutet aber auch nicht, dass eine Methodologie, die z.B. einen hohen Grad an Disziplin verlangt, zwangsweise fehlschlagen wird.)

Kapitel 3: Communicating, Cooperating Teams

Nach dem Betrachten des Individuums geht es nun – logischerweise – zum Team. Cockburn erläutert, wie Informationen am besten übermittelt werden können, welche Kommunikationsmodalitäten existieren und welche Stärken und Schwächen diese haben und welche Rolle z.B. eine geeignete Möblierung und Raumgestaltung haben kann.

Teams haben eigene Subkulturen im gesamtkulturellen Gefüge der Organisation, viel mehr als das aber: Methodologien, stellt Cockburn fest, sind – Ralph Hodgson zitierend – nichts anderes als „soziale Konstruktionen“, woraus auch resultiert, dass alle Methodologien adaptiert werden müssen, damit sie zum Team passen (S. 140). Methodologien werden dabei als ein „Satz von Konventionen und Richtlinien“ (S. 140 – eigene Übersetzung) definiert.

Kapitel 4: Methodologies

Nahtlos, noch ein Mal Ralph Hodgsons Zitat aufnehmend, fährt Cockburn fort aufzuzeigen

  • was eine Methodologie ist,
  • welche methodologischen Arten es gibt,
  • wie und woraus Methodologien aufgebaut sind,
  • an wen sich diese adressieren,
  • welche Fehler beim Design einer Methodologie gemacht werden können (ein Beispiel: Intoleranz),
  • usw.

Die Beziehung zwischen dem Autor einer Methodologie und dieser, oder präziser: der Einfluss der Persönlichkeit und der Erfahrungen des Autors auf die Methodologie wird beleuchtet. Kent Beck hat die Wichtigkeit des Autors bei der Entwicklung der Methodologie schon in der ersten Auflage seines erfolgreichen Buches zum Thema XP beschrieben. Cockburn zitiert Beck und stellt fest, dass dieser recht hatte. Cockburn schreibt: „One can almost guess at a methodology author’s past experiences by looking at the methodology“ (S. 180 f.). Selbstverständlich folgen als Nächstes einige Details aus dem eigenen Leben, welche offensichtliche Parallelen zu seiner Gedankenwelt aufzeigen (vgl. S. 181 f.).

Sieben Prinzipien, die aus Sicht des Autors für die Entwicklung und Evaluation von Methodologien wichtig sind, werden daruafhin diskutiert (vgl. S. 182 ff – Reihenfolge wie im Buch):

  • persönliche, direkte Kommunikation ist die günstigste, schnellste und effektivste Kommunikationsart
  • umfangreichere Methodologien haben ihren Preis – man sollte keine Methodologie wählen, die umfangreicher (der Begriff „weight“ wird dabei verwendet) ist als notwendig
  • der notwendige Umfang (ebenfalls „weight“) einer Methodologie steigt mit der Größe des Teams
  • komplexere („[g]reater ceremony“ im Original) Methodologien sind bei kritischen Projekten notwendig
  • mehr Feedback und mehr Kommunikation führen dazu, dass weniger „intermediate deliverables“ – z.B. Dokumentation – notwendig sind
  • diszipliniertere und kompetentere Entwickler benötigen weniger Prozesse, Formalitäten und Dokumentation
  • nur in Engpasssituationen ist Effizienz unbedingt notwendig.

Aus der Kombination der sieben Prinzipien zieht Cockburn sechs Schlussfolgerungen. Die – meiner Meinung nach – wahrscheinlich wichtigste ist die vierte Schlussfolgerung, dass unterschiedliche Projekte unterschiedliche Methodologien (oder besser: Herangehensweisen) benötigen (vgl. S. 196).

Das Kapitel endet mit einer Analyse von Becks Extreme Programming (auf Basis der ersten Auflage des Buches Extreme Programming Explained: Embrace Change).

Im „Evolution“-Kapitel unterstreicht Cockburn u.a. den Unterschied zwischen Methodologie und Projektmanagement, eine Unterscheidung, die er in der ersten Auflage des Buches nicht bewusst gemacht hätte, die ihm aber wichtig erscheint (vgl. S. 209 ff.).

Kapitel 5: Agile and Self-Adapting

Das fünfte Kapitel ist in zweierlei Hinsicht bemerkenswert: alles was voranging, konvergiert zu dem, was das eigentliche Thema des Buches ist – die agile Softwareentwicklung –, und das „Evolution“-Kapitel ist fast viermal so lang, wie der Text der ersten Auflage. Die weiterführenden Überlegungen der zweiten Auflage nehmen in keinem anderen Kapitel so viel Platz gegenüber der ersten Auflage ein; so ist das Verhältnis gleich oder fast 1 bei den Kapiteln 1 und 6 (ebenfalls Anhang A), ansonsten sind die „Evolutions“ relativ kurz gehalten. Beim fünften Kapitel ist die Umkehrung des Verhältnisses jedoch nicht nur verständlich, sondern vielmehr notwendig – zwischen der ersten Auflage (2001, Copyright-Jahr 2002) und der zweiten (2006, Copyright-Jahr 2007) hatte sich letztendlich viel getan.

Schauen wir, was Cockburn zum Thema zu sagen hat. Laut ihm geht es prinzipiell darum ausreichende methodologische Leichtigkeit („lightness“) zu finden. Agile Praktiken wie kleine Teams an einem Ort oder inkrementelle Entwicklung sind hilfreiche Tools. Wenn man obendrauf noch bestrebt ist, sich ständig zu verbessern und die verwendete Methodologie an die eigenen Gegebenheiten anzupassen, wird man „self-adapting“ (vgl. S. 228ff). Cockburns Ratschlag ist, Agilität als Einstellung zu betrachten, als eine Art Leitspruch und nicht als Formel oder Dogma (vgl. S. 239).

Kapitel 5.1: Agile and Self-Adapting: Evolution

Viele haben Agilität aus der Sicht Cockburns missverstanden. Diesen Missverständnissen (wie z.B. dass Agilität und Pläne einander ausschließen würden) begegnet er im ersten Teil des „Evolution“-Kapitels. Aber nicht nur ausprobiert wurden die agilen Methodiken – was überhaupt die Missverständnisse aufkommen lassen konnte –, diese haben sich weiterentwickelt in der Zeit seit der ersten Auflage des Buches.

Einige dieser Änderungen werden ebenfalls diskutiert, so z.B. die zweite Auflage von Extreme Programming Explained: Embrace Change (Kent Beck und Cynthia Andres) oder die Weiterentwicklung von Scrum. Über die zweite Auflage von Extreme Programming Explained urteilt Cockburn, dass dieses auf der Ri-Ebene geschrieben wäre (auf der Meisterebene), wohingegen die erste Auflage XP auf Shu-Ebene betrachten würde, also eine Darstellung für wenig Erfahrene sei (vgl. S. 262 f.).

Cockburn widmet sich in diesem Unterkapitel vielen weiteren Themen, die vielleicht am Anfang durch die agilen Methodologien etwas stiefmütterlich behandelt werden konnten, die aber zunehmend relevanter wurden: Projektmanagement, Zusammenspiel von agilen Methoden und CMMI (Capability Maturity Model Integration) und viele andere. Aber auch dem Thema Agilität außerhalb der Softwareentwicklung widmet sich der Autor: so z.B. „agiles“ Bauen (von Häusern oder Flughäfen) oder agile Buchpublikation, wobei Cockburn dabei oft auf eigene Erfahrungen zurückgreift.

Kapitel 6: The Crystal Methodologies

Im sechsten und letzten Kapitel beschreibt Cockburn seinen eigenen Vorschlag für ein agiles Vorgehen, oder genauer – es wäre ja ein Widerspruch zum restlichen Buch, wenn Cockburns Vorschlag eine Methodologie wäre – der Autor schlägt eine Familie von Methodologien vor, die je nach Projektart eingesetzt werden können. Der Name der Familie ist Crystal. Durch einen farblichen Zusatz wie Clear, Yellow, Orange usw. wird die „Härte“ ausgedrückt (vgl. S. 335). Je kritischer und größer ein Projekt ist, desto „härter“ muss das „Kristall“ sein. Die notwendige Härte wird auf der nach Cockburn benannten Cockburn-Skala bestimmt.

Auf drei Ausprägungen der Crystal-Familie geht Cockburn ein: Crystal Clear, Crystal Orange und Crystal Orange Web. Im „Evolution“-Kapitel wird ebenfalls Crystal Yellow vorgestellt, eine Anpassung von Géry Derbier.

Anhänge

Etwa 70 Seiten lang sind die Anhänge (ausgenommen Anhang D, der die Bibliografie enthält):

  • Anhang A geht auf das Manifest für Agile Softwareentwicklung ein, dessen Entstehungsgeschichte, Inhalte und Limitierungen und ebenfalls auf die Declaration of Interdependence (DOI), einer Erweiterung/Anpassung des Manifests für Agile Softwareentwicklung für das Management und für nicht-Software-Produkte. Neben Cockburn gehören z.B. Mike Cohn, Robert Wysocki und Jim Highsmith zu den Unterzeichnern.
  • Anahng B enthält Auszüge, die Cockburn besonders wichtig erscheinen und die ihn auch nach eigener Aussage besonders geprägt haben, aus Peter Naurs Artikel Programming as Theory Building, Pelle Ehns Buchkapitel Skandinavian Design: On Participation and Skill (aus Usability: Turning Technologies into Tools herausgegeben von P. S. Adler und T. A. Winograd) und Miyamoto Musashis (ein Samurai, der im 17. Jahrhundert gelebt hat) Buch The Book of Five Rings. Referenzen auf diese Texte tauchen immer wieder in Agile Software Development: The Cooperative Game auf. Cockburn empfiehlt aufs wärmste das Lesen dieser Texte (S. XXXIII).
  • Anhang C ist ein sehr kurzes Nachwort, das mit einer etwas emphatischen Erinnerung endet, die besagt, dass wir alle im gleichen Boot sitzen (will heißen, dass Kooperation äußerst wichtig ist).

Anhang D beinhaltet, wie schon geschrieben, eine – recht umfangreiche – Bibliografie.

Diskussion

Alistair Cockburn versucht in Agile Software Development: The Cooperative Game etwas außerordentlich Ambitioniertes: ein (neues) Vokabular zu entwickeln zur Beschreibung dessen, was im Rahmen der Softwareentwicklung vor sich geht, um dann mit der Unterstützung dieses Vokabulars Softwareprojekte und Methodologien zu beschreiben, mit dem Ziel aufzuzeigen welche Methodologie wann verwendet werden kann. Schon der Versuch allein – sollte er nicht allzu kläglich scheitern – wäre lobenswert, Cockburn gelingt es jedoch das zu machen, was er sich vornimmt.

So ist ein umfangreiches und sehr komplexes Buch entstanden, das die Softwareentwicklung facettenreich darstellt. Cockburn nimmt sich Zeit, um die Gedanken, die er vermitteln möchte zu entwickeln, und geht dabei sowohl in die Tiefe als auch in die Breite. Die vielen Referenzen auf die Arbeit anderer, was nicht zuletzt anhand der umfangreichen Bibliografie sichtbar wird, sind mit Cockburns eigenem großen Erfahrungs- und Erkenntnisschatz verflochten.

Und obwohl Alistair Cockburn einer der Erstunterzeichner des Manifests für Agile Softwareentwicklung ist, zeigt er sich vollkommen undogmatisch bezüglich der agilen Methodologien und stellt fest, dass die Methodologie abhängig vom durchzuführenden Projekt gewählt (und angepasst) werden muss. Größere Projekte erfordern dabei komplexere Methodologien.

Der einzige wirklich negative Aspekt des Buches ist dessen Aufmachung. Die Länge des Buches – dieses ist bemerkenswert lang für ein Softwareengineering-Buch – ist absolut gerechtfertigt, der zweispaltige Druck mit ziemlich engen Rändern ist aber erstens ästhetisch wenig ansprechend und zweitens kann sich das angenehme Gefühl des Lesefortschritts wegen der langen Lesedauer jeder Seite nur sehr schwer einstellen.

Es lohnt sich jedoch über diese Schwäche hinwegzusehen und die Mühe auf sich zu nehmen dieses lange aber unglaublich lehrreiche Buch zu lesen.


Zum Autor

Informationen über Alistair Cockburn finden Sie auf der separaten Buchautorenseite.


Folgende Rezensionen könnten Sie ebenfalls interessieren:

Petre Sora

Petre Soras Interessen sind vielfältig und befinden sich an der Schnittstelle zwischen Mensch und Informationstechnologie. Als studierter Psychologe und Software Engineer war er sechs Jahre als Java-Entwickler in mehreren Unternehmen tätig. Mit der Gründung der Rezensionsplattform nososo hat er sich entschieden eigene Wege zu gehen.

Schreibe einen Kommentar