Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer
Agile! The Good, the Hype and the Ugly

2014, 190 Seiten, Broschur
Springer International Publishing
ISBN: 978-3-319-05154-3

Informationen zum Buch im Katalog der Deutschen Nationalbibliothek.



Betrand Meyer betrachtet und bewertet agile Methodologien (konkret: Extreme Programming, Scrum, Crystal und Lean Softwareentwicklung) und kategorisiert schonungslos deren Prinzipien, Techniken und Methodiken in „The Good, the Hype and the Ugly“ (plus der speziellen Kategorie brillanter Konzepte). Dadurch leistet der Autor, der als Entwickler der Programmiersprache Eiffel und des Konzepts des Design By Contract bekannt ist, einen wichtigen Beitrag zur Objektivierung der Diskussion rund um das Thema agile Softwareentwicklung.


Inhalt

Kapitel 1: Overview

Meyers Buch beginnt mit einem Überblick der im Buch behandelten Themen, Überblick, der mit einer ersten Bewertung der agilen Prinzipien, Techniken und Methodiken endet. Der Autor interpretiert die agilen Methodiken als eine „revolt of the cubicles“ (S. 3, kursiv im Original), als einen Behauptungsversuch der Entwickler gegen das, was ihnen als überkommene Managementmethoden vorkommen: „Agile methods are, in part, the rehabilitation of code“ (S. 3).

Leitmotive des Buches,

  • wie die Rehabilitation des „Big Upfront Anything“ – das von agilen Methodologien so stark abgewertet wird – (siehe Zusammenfassung des 3. Kapitels für was Meyer unter „Big Upfront Anything“ versteht),
  • und die Kritik an der logischen und stilistischen Qualität agiler Texte, („There is a charmingly adolescent quality to the agile literature: I am sooooo unique! Nobody before me understood what life is about! My folks are sooooo, like, 20-th century!“ – S. 14)

werden im ersten Kapitel offensichtlich.

Kapitel 2: Deconstructing agile texts

Im zweiten Kapitel identifiziert der Autor die „most outrageous rhetorical devices“ (S. 22), denen sich agile Texte bedienen, weist diese anhand von Zitaten nach und kritisiert deren Verwendung. Die besprochenen „rhetorischen Figuren“ sind (siehe S. 22, Reihenfolge wie im Buch):

  1. Proof by anecdote
  2. Slander by association
  3. Intimidation
  4. Catastrophism
  5. All-or-nothing
  6. Cover-your-behind
  7. Unverifiable claims.

Meyer wirft den Autoren agiler Texte vor, überzeugen, oder eher bekehren zu wollen, weswegen sie des Öfteren Sachverhalte ungebührend vereinfachen würden (S. 21).

Kapitel 3: The enemy: Big Upfront Anything

Kapitel drei widmet sich dem „Bösewicht“ agiler Softwareentwicklung: „Agile’s villain is variously called ‚waterfall‘ […] and ‚Big Upfront Anything‘ where ‚Anything‘ particularly includes requirements and design.“ (S. 31). Meyer diskutiert und entkräftet die Argumente der agilen Community gegen das „Big Upfront Anything“.

Die Argumente der agilen Vorgehensmodelle, die sich gegen die umfangreiche Erfassung und Dokumentation von Anforderungen richten, sind (vgl. S. 33):

  • Anforderungsdokumente sind im Sinne der Lean Softwareentwicklung „Verschwendung“, da sie nicht an die Kunden geliefert werden;
  • Anforderungen ändern sich, weswegen es sich nicht lohne, diese von vornherein einfrieren zu wollen; es sei besser, diese nach und nach zu erheben und auf unvermeidliche Änderungen zu reagieren.

Ebenfalls setzt sich Meyer für Architektur und Design ein.

Das Kapitel diskutiert auch einige Phasenmodelle (den Rational Unified Process, das Capability Maturity Model Integration – CMMI und den Personal Software Process – PSP) und deren Relation zu agilen Vorgehensmodellen.

Kapitel 4: Agile principles

Das Manifest für Agile Softwareentwicklung definiert zwölf grundlegende Prinzipien, deren Diskussion des vierte Kapitel ausmachen. Das vierte Kapitel beginnt mit der Definition der Eigenschaften eines Prinzips: ein Prinzip soll laut Meyer abstrakt, falsifizierbar und präskriptiv (statt deskriptiv) sein (vgl. S. 49). Viele der zwölf Prinzipien können jedoch Meyers Definition eines Prinzips nicht standhalten: manche sind Praktiken, manche nennt Meyer Plattitüden und manche enthalten redundante Bestandteile. Nach der Einteilung in organisatorische und technische Prinzipien beginnt der Autor mit deren Besprechung.

Einige Prinzipien, die Meyer negativ oder eher negativ bewertet, sind:

  • Selbstorganisation: während erfahrende Teams sehr wohl auch ohne Führung selbstorganisiert und erfolgreich agieren können, ist Meyer der Meinung, dass die allermeisten Teams einen Manager brauchen (S. 53 ff.)
  • Minimale Lösung: während die Forderung selbst, Meyer sinnvoll erscheint, hebt er hervor, dass viele der Probleme durch schlechtes Management entstehen (S. 61). Meyer unterscheidet zwischen additiver und multiplikativer Komplexität, lediglich die additive Komplexität ließe sich „Stück für Stück“ in die Software einbauen. In diesem Kontext hebt er erneut die Wichtigkeit der Anforderungen hervor.

Positiv oder eher positiv schreibt Meyer (allerdings wie bei den meisten Themen des Buches mit Einschränkungen und Nuancen) zum Beispiel über die Themen Time-Boxing, Testing und das Willkommen heißen von Änderung.

Kapitel 5-8: Rollen, Praktiken und Artefakte

In den Kapiteln fünf bis acht (Agile roles, Agile practices: managerial, Agile practices: technical und Agile artifacts) beschreibt und bewertet Meyer

  • Rollen in der agilen Welt: Manager, Product Owner, das Team, Beobachter oder Stakeholder, Kunden und Coach (Scrum Master im Scrum-Framework);
  • Praktiken wie z.B. das Daily Meeting, Sprints und Collective Code Ownership oder Pair Programming, Refactoring und Test Driven Development (TDD);
  • Artefakte wie z.B. die Definition of Done, Velocity und Burndown Charts und den Product Backlog.

Kapitel 9: Agile methods

Das neunte Kapitel widmet sich den wohl bekanntesten agilen Methodologien: Lean Softwareentwicklung und Kanban, Extreme Programming, Scrum und Alistair Cockburns Crystal.

Interessant ist Meyers Einschätzung zu Crystal (vor allem weil es als Prognose gelesen werden kann):

[…] Crystal, with its attempt to integrate the best ideas of software engineering regardless of their source and to provide a realistic framework for projects large and small, could grow into a real method, defining precise techniques of software management and development, and emerge as a first step towards agile methods of a third generation.

S. 143

Die agilen Methoden der ersten und zweiten Generation sind jeweils Extreme Programming und Scrum. Meyer schreibt aber im gleichen Atemzug, dass Crystal ebenfalls auch nur ein episodischer Charakter beschert sein könnte.

Kapitel 10: Dealing with agile teams

Das sehr kurze zehnte Kapitel (lediglich drei Seiten) geht auf die Einführung agiler Methodologien in Firmen ein.

Kapitel 11: The Ugly, the Hype and the Good: an assessment of the agile approach

Das letzte Kapitel teilt die Praktiken und Ideen der agilen Entwicklungsmethoden in vier Kategorien ein (vgl. S. 149-154):

  1. The Bad and the Ugly
    • Der größte Kritikpunkt Meyers in dieser Kategorie ist die Ablehnung des „Big Upfront Anything“ vonseiten der agilen Ansätze;
    • Unter den anderen „Hässlichkeiten“ befinden sich laut Meyer die Praxis des TDD und die Verwendung von User Stories anstelle klassischer Anforderungen.
  2. The Hyped
    • Gehypt erscheinen dem Autor unter anderen die Praxis des Pair Programmings, selbstorganisierende Teams oder das Collective Code Ownership.
  3. The Good
    • Refactoring oder das Daily Meeting, unter anderen, sind unterhalb dieser Kategorie aufgezählt.
  4. The Brilliant
    • Unter anderen sind hier die Rolle des Product Owners, die kurzen Iterationen, die Praxis des Continuous Integration gepaart mit Regressionstests zu nennen.

Diskussion

Agile! The Good, the Hype and the Ugly ist ein Buch, das es nicht einfach nur wagt, die auch heute noch oft genug den Status einer heiligen Kuh genießende agile Softwareentwicklung zu kritisieren, sondern dies auch auf einer bemerkenswert offenen und direkten (und für gewöhnlich augenzwinkernden oder kopfschüttelnden) Weise tut. Dadurch leistet Betrand Meyer, der als Entwickler der Programmiersprache Eiffel und des Konzepts des Design By Contract bekannt ist, einen wichtigen Beitrag zur Objektivierung der Diskussion rund um das Thema agile Softwareentwicklung.

Meyer zeigt keine Scheu bei der Diskussion der grundlegenden agilen Schriften. Er analysiert minutiös die Schwächen der Texte und betrachtet dabei sehr genau nicht nur was gesagt, sondern auch wie es ausgedrückt wird. Meyer schreibt: „[i]n its quest to convert the world, the agile literature resorts to various devices, some of them, let us say, intellectually less impeccable than others“ (S. 17). Indem er zeigt was alles “intellectually less impeccable” ist, geht es Meyer nicht um Kritik der Kritik willen – auch wenn sein Schreibstil sehr wohl eine gewisse spielerische Freude aufweist – sondern um einen besseren Entwicklungsprozess und um bessere Software. Entsprechend spart er auch nicht mit dem Lob, wo ihm Lob gebührend erscheint.

Positiv hervorzuheben ist Meyers Bestreben die eigene Meinung und die Aussagen der agilen Texte klar voneinander abzugrenzen. Die eigenen Kommentare werden jeweils von einem speziellen Piktogramm eingeleitet. Ebenfalls ist die Fülle an Informationen hervorzuheben. Trotz der geringen Seitenzahl ist das Buch in der Beschreibung und der Bewertung der agilen Welt unglaublich umfangreich.

Meyer präzisiert im Vorwort den Geist seiner kritischen Auseinandersetzung mit den agilen Entwicklungsmethodiken:

Progress in science and engineering relies on free, critical inquiry of previous work. In reviewing the agile literature, I have found a number of reasons to disagree with its authors, and a few reasons to be shocked; I have not been coy about taking their claims to task. I have also, however, found elements to admire, and learned new insights about software development. This observation is worth remembering whenever you encounter criticism in the following pages.

S. XII

Sollten wir nicht vielleicht im Software-Bereich generell etwas freier und kritischer in unseren Untersuchungen sein, so wie es Meyer ist? Da, wo teilweise ein Hype den nächsten jagt, würden wahrscheinlich alle Beteiligten von einer distanzierteren und kritischeren Attitüde profitieren. Und dies nicht der Skepsis und Kritik willen, sondern um unsere Arbeit besser zu machen und um unser Leben als Software-Entwickler zu vereinfachen, denn letztendlich, um mit dem abschließenden Satz des Vorworts zu enden: „We are all in the same boat“ (S. XII).

Fazit: ganz klare Leseempfehlung für jeden, der professionell Software entwickelt.


Zum Autor

Informationen über Bertrand Meyer finden Sie auf der separaten Buchautorenseite.


Die Rezensionen folgender Bücher 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