Agile Softwareentwicklung: Ein Leitfaden für Manager

Von Steffen Fischer und Niklas Schlimm

Agilität ist ein wichtiges Thema in der professionellen Softwareentwicklung. Das Buch wendet sich an Manager von agilen Teams, aber auch Architekten oder Entwickler erhalten wertvolle Hinweise. Die Autoren beschreiben, was man unter Agilität versteht, und beleuchten das Thema erstmalig aus betriebswirtschaftlicher Perspektive. Nach einer Definition von Agilität geht es um die Besonderheiten und die Abgrenzung von üblichen Vorgehensweisen. Dabei wird der für agile Teams erforderliche Managementstil vermittelt. Der spannende Überblick zu den Facetten agiler Verfahren beinhaltet praxisrelevante Handlungsempfehlungen, die den Erfolg agiler Projekte entscheidend beeinflussen. Der Leser soll im Anschluss nicht nur verstanden haben, worum es sich bei Agilität handelt, sondern auch wissen, was er als Manager beitragen kann und was er besser unterlassen sollte.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 8. Apr. 2014
• ISBN: 9783868026474

Buchvorschau

geschützt.

1 Einleitung

Dieses Buch beginnt mit einer kleinen Geschichte: Einige Menschen sind seit der Geburt in einer Höhle so festgebunden, dass sie immer nur auf die ihnen gegenüber liegende Wand im Höhleninneren blicken können. Diese wird lediglich durch einen über ihnen angebrachten Schlitz mit Licht beleuchtet. Vor der Höhle befinden sich hinter einer niedrigen Mauer andere Menschen. Hinter diesen Menschen scheint die Sonne, die das Treiben außerhalb der Höhle als unscharfe Schatten auf die Höhlenwand projiziert. Die Wahrnehmung der Welt außerhalb der Höhle beschränkt sich für die an die Höhle gefesselten Menschen also auf Schatten von Lebewesen und Dingen, die sich außerhalb der Höhle befinden. Da sie nichts anderes wahrnehmen und kennen, halten die Menschen diese Schattenbilder für die wirklichen Dinge des Lebens. Das bleibt auch so, als einer von ihnen losgebunden wurde, sich die Welt und die Sonne draußen anschaut und zurückkehrt, um von seinen Beobachtungen über die „andere Welt" zu berichten. Anstatt ihm Glauben zu schenken, halten die Höhlenbewohner an ihrer Überzeugung fest, dass es sich nämlich bei den Schatten in der Höhle um die wahre Realität handele.

Bei der Übertragung des Höhlengleichnisses von Platon auf den Kontext dieses Beitrags muss man wirklich mit einiger Vorsicht vorgehen. Dies ist eine Abhandlung über das Management von agilen Teams. Es soll einen Beitrag zur weiteren Aufklärung über die Rolle und Aufgaben des Managers leisten. Das Höhlengleichnis soll auf etwas aufmerksam machen: es könnte immer eine andere, vielleicht „bessere" Realität geben als die, in der man gerade lebt. Und deswegen muss man sich gegenseitig genau zuhören. In der Praxis kommt es vor, dass die Entwickler ganz begeistert sind von agilen Verfahren. Das Management dagegen steht den Berichten der Entwickler zurückhaltend gegenüber. Das hat dann sicher verschiedene Gründe. Man kann natürlich nicht annehmen, dass das Management angefesselt in einer dunklen Höhle sitzt. Es ist aber schon denkbar, dass es schwierig sein kann, eine gut bekannte Realität zu verlassen, die über viele Jahre stabil Bestand hatte. Softwareentwicklung war ja auch in der Vergangenheit häufig erfolgreich, zumindest in weit mehr Fällen als man wirklich von Misserfolg sprechen könnte. Warum sonst würde man immer wieder neue Softwareprojekte durchführen wollen, egal in welcher Vorgehensweise?

Dieser Beitrag soll ein wenig Licht ins Dunkel bringen, in einer Art und Weise, die für das Management verträglich ist. Es wird also nicht, das sei vorweggenommen, viel von technischen Details gesprochen. Es werden einige wichtige Kontroversen aufgegriffen, die sich im Bereich des Managements von agilen Softwareprojekten ergeben – immer im Hinblick darauf, ob es für Führungskräfte interessant ist, sich eben mit genau diesem Aspekt von Agilität zu beschäftigen. Das kann deswegen der Fall sein, weil es hier immer wieder zu Problemen im Anwendungskontext von Agilität kommt. Oder weil es sich hier um einen wirklich kritischen Erfolgsfaktor bei der Anwendung handelt. Häufig fallen beide Aspekte zusammen. Die Darstellung erfolgt wohlgemerkt aus Managementsicht! Hier geht es also beim Thema Agilität einmal nicht um den Entwickler, sondern um den Manager, um denjenigen, der – bei allem Respekt gegenüber Selbstorganisation und Eigenverantwortung – nach „oben hin" die Verantwortung behält.

Es wird hier für Manager näher beschrieben, was mit „agiler Softwareentwicklung genau gemeint ist. Was sind die besonderen Eigenschaften agiler Verfahren? Was unterscheidet agile von den herkömmlichen Vorgehensweisen? Wie grenzen sie sich untereinander ab? So lauten die zentralen Fragen. Einer Antwort auf diese Fragen wird sich genähert, indem auf verschiedene Diskussionen eingegangen wird, mit denen man in Gesprächen oder Artikeln öfter konfrontiert wird. Man kann annehmen, dass gerade die Diskussion in der Praxis ein Indiz dafür ist, dass sich etwas ändert. Denn warum sollte über die Qualität verschiedener Herangehensweisen gestritten werden, wenn es sich dabei nicht um ganz relevante Unterschiede handeln würde? Und zwar genau die Unterschiede zwischen der früheren Art zu arbeiten und wie sie es nun nach agilen Grundsätzen tun sollen. Sie haben vielleicht auch schon einmal jemanden sagen hören: „In agilen Projekten herrscht doch das Chaos! Dann spricht dort jemand, der vermutlich sehr lange anders gearbeitet hat: eben in herkömmlichen, dokumentenorientierten oder teilweise stark reglementierten Vorgehensmodellen.

Es wird zunächst erklärt, was unter herkömmlichen und unter agilen Vorgehensweisen zu verstehen ist. Auch das agile Manifesto und dessen abgeleitete Prinzipien werden vorgestellt. Das ist ein erster Ansatz, eine Einführung in die wesentlichen Eigenschaften. Überhaupt dreht sich bei agilen Verfahren, das wird später noch genauer aufgezeigt, viel um das Thema Regeln. Die agilen Werte und Prinzipien können als Regeln des Zusammenarbeitens verstanden werden. Danach werden drei der agilen Verfahren vorgestellt: Extreme Programming, Feature-driven Development und Scrum. Es ist hilfreich für den weiteren Verlauf der Diskussion, diese Beispiele vor Augen zu haben. Trotz alledem sind es eben nur diese Beispiele agiler Verfahren. Die anschließende Diskussion, die den größten Teil dieses Beitrags ausmacht, bindet sich nicht an eine konkrete Vorgehensweise, sondern geht der Frage nach den grundsätzlichen Eigenschaften oder Ideen von agiler Softwareentwicklung nach:

Können wir Agilität als Ingenieurkunst ansehen? (Kapitel 3.1)

Was ist agiles Management und was nicht? (Kapitel 3)

Was meinen agile Vorgehensweisen mit „Verschwendung"? (Kapitel 4)

Wie organisiere ich agile Teams? (Kapitel 5)

Welche ganz zentrale Grundidee verbirgt sich hinter Agilität? (Kapitel 6)

Was ist meine Aufgabe als Manager? (Kapitel 7)

KOMPAKT: In diesem Beitrag wird das Verständnis für die agilen Werte vertieft, womit das Ziel verfolgt wird, dass Sie die agilen Vorgehensweisen in Ihrem Unternehmen mitgestalten können. Dabei wird immer vom Vergleich zwischen herkömmlichen und agilen Vorgehensweisen ausgegangen.

1.1 Agile und herkömmliche Verfahren

Die Begriffe „Vorgehensmodell oder „Vorgehensweise werden einige Male verwendet. Daher soll kurz erläutert werden, was hier darunter zu verstehen ist: Es handelt sich ganz grundsätzlich um eine allgemeine Beschreibung eines systematischen Prozesses zur Entwicklung von Software. Darüber hinaus wird hier immer wieder von abstrakten, herkömmlichen und von agilen Vorgehensweisen gesprochen, dessen jeweilige Wesensmerkmale ja der Inhalt dieses Beitrags sind. Daher fällt eine Abgrenzung allgemeingültiger Art natürlich hier und jetzt schwer, weil dann das Ergebnis vor die Diskussion gestellt würde. Aus diesem Grund seien hier nur beispielhaft die typischen Vertreter der Familien genannt, die einen großen Einfluss auf die Projektpraxis genommen haben. Zu den abstrakten Vorgehensweisen gehören insbesondere das Wasserfallmodell nach Royce (1970), das Spiralmodell nach Boehm (1988) sowie das iterative und inkrementelle Modell nach Basil und Turner (1975). Diese Aufteilung erfolgt in Anlehnung an Bunse und von Knethen (2002), die hier analog von „Familien von Vorgehensweisen" sprechen. Darauf aufbauend wurden in der Vergangenheit konkrete Ableger der abstrakten Vorgehensmodelle entwickelt, die diese erweitern und um konkrete Techniken und Aktivitäten anreichern: das Vorgehensmodell von Booch (1997), die Object Modeling Technique (OMT) von Rambaugh, der Unified Process von IBM Rational (Jacobson et al., 1999) sowie das V-Modell XT (Höhn und Höppner, 2008). Diese Beispiele stellen Interpretationen der abstrakten Vertreter dar, sie werden hier im Weiteren als herkömmliche Vorgehensmodelle bezeichnet.

Zu den agilen Vorgehensweisen gehören insbesondere die Methoden Extreme Programming (XP) von Kent Beck (2005), Feature-driven Development (FDD) von Jeff de Luca (Palmer und Felsing, 2002), Crystal von Allastair Cockburn (2003) sowie das Managementframework Scrum von Ken Schwaber (2004). Man könnte sagen, dass alles, was nicht explizit als agile Vorgehensweise ausgewiesen werden kann, hier als „herkömmlich bezeichnet wird. Die Anmerkung ist deswegen zweckmäßig, weil Teile der Ideen abstrakter und herkömmlicher Vorgehensweisen durchaus Eingang auch in agile Vorgehensweisen gefunden haben, zum Beispiel das Ideengut des inkrementellen Modells nach Basil und Turner. Die agilen Vorgehensweisen unterscheiden sich jedoch in einigen wesentlichen Eigenschaften von den herkömmlichen. Von diesen Unterschieden wird im Folgenden die Rede sein. Insbesondere wird aus Managementsicht näher begründet, warum agile Verfahren genau so – und nicht irgendwie anders – ausgestaltet sind. Welcher tiefere Sinn steckt hinter der Umsetzung agiler Verfahren? Und wie kann man als Manager an der Anwendung agiler Verfahren mitwirken? Steckt hinter der vermeintlich „unmethodischen, da oft undokumentierten, Vorgehensweise vielleicht eine konkrete Absicht? Davon wird hier gesprochen. Es geht also darum, eine Idee zu vermitteln, ihr einen tieferen Sinn zu geben und auszuloten, welchen Platz man als Manager im Lichte dieser Idee hat.

KOMPAKT: Jede Vorgehensweise zur Softwareentwicklung, die nicht explizit als agile Vorgehensweise gekennzeichnet ist, wird als herkömmliche Vorgehensweise bezeichnet.

1.2 Die agilen Grundwerte

Was ist der Wesenskern agiler und herkömmlicher Vorgehensweisen? Da kommt man auch hier nicht an dem agilen Manifesto (Manifesto, 2001) vorbei, das im Jahre 2001 von einigen Beratern und Autoren im Bereich Softwareentwicklung unterzeichnet und veröffentlich wurde. Dort kann man nachlesen:

Individuen und