Barry Boehm, Richard Turner: Balancing Agility and Discipline

You are currently viewing Barry Boehm, Richard Turner: Balancing Agility and Discipline

Barry Boehm, Richard Turner
Vorwörter: Grady Booch, Alistair Cockburn, Arthur Pyster
Balancing Agility and Discipline: A Guide for the Perplexed

7. Druck, Oktober 2009
2004, XXVII, 266 Seiten, Broschur
Addison-Wesley
ISBN: 0-321-18612-5



Plangesteuert oder agil? Die Antwort der zwei Autoren ist klar: selten sind die Fälle, in denen oder die richtige Konjunktion ist, öfter ist und die bessere Wahl. In ihrem Buch zeigen Barry Boehm und Richard Turner wieso das der Fall ist und wie „plangesteuert und agil“ aussehen kann.


Inhalt und Struktur

Kapitel 1: Discipline, Agility, and Perplexity

Der Ausgangspunkt ist: Disziplin und Agilität als extreme Pole des gleichen methodologischen Kontinuums, das Ziel: Vor- und Nachteile beider Vorgehen herauszuarbeiten und deren Verbindung anzustreben. So gehen die beiden Autoren sowohl auf plangesteuerte („plan-driven“ im Original), z.B. Cleanroom und Capability Maturity Model Integration (CMMI), als auch auf agile Methodologien, z.B. XP, Scrum und Crystal, ein.

Agile Praktiken sind in ihrer Essenz nicht unbedingt neu, zeugen, laut den Autoren, jedoch – in der vom Manifest für Agile Softwareentwicklung losgetretenen agilen Bewegung – von einer neuen Einstellung und einer „besseren Verpackung“ (S. 18). Während die plangesteuerten, „disziplinierten“ Vorgehen die Vorhersagbarkeit eines Projektes und die durch Fluktuation eintretenden Risiken minimieren wollen (vgl. S. 12), geht es bei den agilen Methoden um iterative, inkrementelle Entwicklung mit selbstorganisierenden Teams (vgl. S. 17).

Wie man Agilität und Disziplin am besten mixt, kann durch die Projektrisiken vorgegeben werden (vgl. S. 24).

Kapitel 2: Contrasts and Home Grounds

Sowohl plangesteuerte Methodologien als auch agile Vorgehen haben ihre Vor- und Nachteile und beide stellen ganz eigene Anforderungen an das Management der Projekte, den technischen Praktiken und dem Personal, das die Projekte ausführt.

Im zweiten Kapitel arbeiten Boehm und Turner die Stärken und Schwächen der beiden Vorgehensarten heraus und räumen mit einigen Missverständnissen bezüglich der Agilität und der plangesteuerten Methoden auf. So z.B. garantieren Pläne nicht deren Einhaltung und Entwickler, die agil arbeiten, planen auch, nur ihre Pläne basieren eher auf implizitem statt explizitem Wissen (S. 53f.).

Die „Home Grounds“ sind anhand von fünf Faktoren beschrieben (vgl. S. 54ff):

  • Teamgröße,
  • Kritikalität des Projektes (wie kritisch können sich auftretende Fehler auswirken),
  • Dynamismus (Änderungsrate der Anforderungen),
  • Kompetenz der Einzelnen, wobei die Kompetenz der Einzelnen auf der Skala -1/1B/1A/2/3 bewertet wird, eine Skala die an Alistair Cockburns dreistufiger Bewertungsskala angelehnt ist (vgl. S. 48); der Kompetenz-Faktor wird als Prozentsatz der sogenannten Level 2- und Level 3-Entwickler quantifiziert,
  • Kultur (Prozentzahl derer, die in einer chaotischen Umgebung – vs. einer geordneten – gedeihen).

Mehr kompetente Leute, mehr Dynamismus, kleinere Kritikalität, kleinere Teamgröße und weniger geordnete Zustände sind am ehesten für agile Vorgehen geeignet (umgekehrt eher plangesteuert).  

Kapitel 3 bis 5

Kapitel drei und vier zeigen, wie plangesteuerte und agile Vorgehen „live“ aussehen können (Kapitel 3: A Day in the Life) und wie agiles Vorgehen in einem plangesteuerten Umfeld helfen kann und umgekehrt (Kapitel 4: Expanding the Home Grounds: Two Case Studies). Dabei wählen die Autoren im dritten Kapitel als plangesteuertes Vorgehen PSP/TSP (Personal Software Process / Team Software Process), beides Methoden, die von Watts Humphrey entwickelt wurden, der als Vater der Softwarequalität bekannt ist und als agile Methode Kent Becks Extreme Programming.

Im fünften Kapitel entwickeln die Autoren ein Rahmenwerk, das bei der Wahl einer geeigneten Methodologie anhand der Bewertung der Projektrisiken unterstützen soll. Das Framework wird anhand dreier Beispielprojekte veranschaulicht.

Kapitel 6: Conclusions

Sechs Schlussfolgerungen werden dem Leser im letzten Kapitel präsentiert (vgl. S. 148f., Reihenfolge wie im Buch):

  1. Methoden, seien sie agil oder plangesteuert, lösen nicht auf wundersame Art und Weise alle Probleme
  2. Sowohl agile als auch plangesteuerte Vorgehen haben ihre Vor- und Nachteile
  3. Beides ist notwendig: Agilität und Disziplin (Disziplin als Gegensatz von Agilität)
  4. „Mischverfahren“, die Agilität und Disziplin berücksichtigen, sind dabei zu entstehen
  5. Die Autoren stellen fest, dass der Ausbau der verwendeten Methoden leichter ist als deren Vereinfachung
  6. Die Berücksichtigung der Bedürfnisse der involvierten Personen, gute Kommunikation und passende Werte sind wichtiger als Methoden

Anhänge

Die relativ umfangreichen Anhänge bieten dem interessierten Leser viel Zusatzinformation. So sind im Anhang A Beschreibungen vieler Vorgehensweisen zu finden (eine Auswahl: Scrum, Crystal, Extreme Programming, CMMI, PSP und Cleanroom). Anhang B beinhaltet das Manifest für Agile Softwareentwicklung, während Anhang C eine kurze Einführung in CMM (Capability Maturity Model) und CMMI bietet. Anhang D zählt hilfreiche Tools auf und Anhang E fasst einige empirische Ergebnisse zu agilen und plangesteuerten Prozessen zusammen.

Diskussion

Als Boehms und Turners Buch 2003 erschien (Copyright-Jahr 2004), waren sicherlich viele verwirrt: das traditionelle Vorgehen war vielleicht schlecht, aber vielleicht doch nicht ganz so schlecht, wie manche Agilisten meinten, agile Vorgehen waren vielleicht gut, aber vielleicht doch nicht so gut, wie die gleichen Agilisten kundtaten. Ein „Guide for the Perplexed“ war zu jenem Zeitpunkt eine gute Idee. Durch ihren konstruktiven und integrativen – oder noch besser: ausgeglichenen – Ansatz entwickeln die Autoren ein Rahmenwerk, mit dessen Hilfe im methodologischen „Dschungel“ etwas Ordnung geschaffen werden kann. Grady Booch spricht im Vorwort von einer „veritable cacophony of competing approaches“ (S. XIII) – meint aber die Zeiten der strukturierten Analyse und des strukturierten Designs – die Geschichte wiederholt sich.

Wurde der Ruf der Autoren nach Pragmatismus und Integration erhört? Vielleicht, aber dann eher von denen, die eh schon pragmatisch und integrativ dachten. Dies kann jedoch nicht dem Buch angelastet werden, dieses ist gut strukturiert, verständlich geschrieben und durchaus auch heute noch lesenswert. Aber sowohl Pragmatismus als auch Integration setzen Offenheit, Verständnis und Kompetenz voraus. Mit jeder neuen methodologischen Welle wird es schwieriger und zeitintensiver das notwendige Verständnis zu entwickeln, auch wenn oft lediglich alte Ideen neu verpackt werden, um dann als die Lösung präsentiert zu werden. Somit sind wir vielleicht, knapp zwanzig Jahre nach der Veröffentlichung von Balancing Agility and Discipline nicht weit von den nächsten, von Booch im Vorwort prognostizierten, „method wars“.


Zu den Autoren

Barry Boehm

Informationen über Barry Boehm finden Sie auf der separaten Buchautorenseite.

Richard Turner

Richard Turner hat Methematik (B.A. verliehen im Jahre 1975 vom Huntingdon College), Computer Science (M.S. verliehen im Jahre 1977 von der University of Louisiana at Lafayette) und Engineering Management (DSc. verliehen im Jahre 2003 von der The George Washinton University) studiert. Aktuell ist er unter anderem als Senior Software Engineer am Software Engineering Institute der Carnegie Mellon Universität tätig. Turner ist unter anderem als Mitentwickler des CMMI (Capability Maturity Model Integration) bekannt. Er ist Koautor mehrerer Bücher so z.B. (Informationen gemäß Library of Congress, Abruf 22.02.2021):

  • 2001. Zusammen mit Dennis Ahern und Aaron Clouse. CMMI Distilled: A Practical Introduction to Integrated Process Improvement. Addison-Wesley.
  • 2004. Zusammen mit Barry Boehm. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley.
  • 2007. Zusammen mit Suzanne Garcia. CMMI Survival Guide: Just Enough Process Improvement. Addison-Wesley.

Quelle: Die Informationen über den Autor sein seinem LinkedIn-Profil entnommen – letzter Zugriff am 22.02.2021.


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