Das war kein leichtes Unterfangen. Die 17 Experten hatten ganz unterschiedliche Erfahrungen gesammelt und vertraten sehr verschiedene Meinungen. Es war sehr unwahrscheinlich, dass solch eine Gruppe zu einem Konsens kommen würde. Und doch wurde entgegen allen Erwartungen ein Konsens erzielt, das agile Manifest. Damit wurde eine der einflussreichsten und langlebigsten Bewegungen auf dem Gebiet der Softwareentwicklung geboren.
Solche Bewegungen in der Softwareentwicklung verlaufen immer vorhersehbar. Am Anfang gibt es eine Minderheit begeisterter Unterstützer, eine weitere Minderheit enthusiastischer Kritiker und eine große Mehrheit, der das Ganze egal ist. Viele dieser Bewegungen verlaufen in dieser Phase im Sande oder kommen nie über sie hinaus. Denken Sie nur an aspektorientierte Programmierung, logische Programmierung oder CRC-Karten (Class-Responsibility-Collaboration-Karten). Einige jedoch schaffen den Sprung, erfreuen sich außerordentlicher Beliebtheit und werden kontrovers diskutiert. In manchen Fällen wird auch diese Kontroverse überwunden, und die Bewegung wird zum allgemeinen Gedankengut. Für Letzteres ist Objektorientierung (OO) ein gutes Beispiel. Ebenso wie agile Softwareentwicklung.
Ist eine solche Bewegung erst einmal groß geworden, kommt es durch Missverständnisse und Usurpation leider schnell dazu, dass ihre Bezeichnung unscharf wird. Produkte und Verfahren, die nichts mit der Bewegung zu tun haben, verwenden den Begriff, um aus seiner Bekanntheit und Signifikanz Profit zu schlagen. So war es auch bei der agilen Softwareentwicklung.
Der Zweck dieses Buchs, das fast zwei Jahrzehnte nach dem Treffen in Snowbird entstand, ist es, das richtigzustellen. Es ist der Versuch, so pragmatisch wie möglich zu sein und agile Softwareentwicklung ohne Nonsens und ohne unklare Begriffe zu beschreiben.
In diesem Buch werden die Grundlagen der agilen Softwareentwicklung vorgestellt. Diese Konzepte wurden in der Vergangenheit oftmals erweitert und ausgeschmückt – und daran ist auch nichts verwerflich. Allerdings sind solche Erweiterungen und Ausschmückungen keine agile Softwareentwicklung. Es handelt sich vielmehr um agile Softwareentwicklung plus irgendetwas anderes. In diesem Buch werden Sie lesen, was agile Softwareentwicklung ist, was sie war und was sie zwangsläufig immer sein wird.
1.1 Ursprung der agilen Softwareentwicklung
Wann nahm die agile Entwicklung ihren Anfang? Vermutlich vor mehr als 50.000 Jahren, als Menschen sich erstmals entschlossen, zusammenzuarbeiten, um ein gemeinsames Ziel zu erreichen. Die Vorstellung, einfachere Zwischenziele zu verfolgen und nach ihrem Erreichen den Fortschritt zu beurteilen, ist schlicht und einfach zu naheliegend und zu menschlich, um als irgendeine Art von Revolution betrachtet zu werden.
Und wann nahm die agile Softwareentwicklung in der modernen Wirtschaft und Gesellschaft ihren Anfang? Das ist schwer zu sagen. Ich denke, die erste Dampfmaschine, die erste Mühle, der erste Verbrennungsmotor und das erste Flugzeug sind durch Verfahren zustande gekommen, die wir heute als agil bezeichnen würden. Der Grund dafür ist, dass es einfach zu naheliegend und menschlich ist, in kleinen, messbaren Schritten vorzugehen, sodass es gar nicht auf andere Weise hätte geschehen können.
Wann also nahm die agile Softwareentwicklung ihren Anfang? Ich hätte gerne Mäuschen gespielt, als Alan Turing 1936 seine Arbeit verfasst hat. Ich nehme an, dass er die vielen »Programme« in dieser Arbeit in kleinen Schritten mit jeder Menge informeller Tests, den sogenannten Desk Checks (auch: Schreibtischtests) entwickelt hat. Den ersten Code, den er 1946 für die Automatic Computing Engine geschrieben hat, wird er wohl auch in kleinen Schritten entwickelt haben, wieder mit vielen Desk Checks und vielleicht sogar mit einigen richtigen Tests.
In der Anfangszeit der Softwareentwicklungen finden sich viele Beispiele für ein Verhalten, das wir heute als agile Softwareentwicklung bezeichnen würden. So haben beispielsweise die Programmierer, die die Steuerungssoftware für die Mercury-Raumkapsel schrieben, in halbtäglichen Schritten gearbeitet, die durch Unit-Tests unterbrochen wurden.
Über diese Zeit wurde an anderen Stellen schon viel veröffentlicht. Craig Larmann und Vic Basili haben eine Historie geschrieben, die in Ward Cunninghams Wiki und auch in Larmans Buch Agile & Iterative Development: A Manager’s Guide zusammengefasst ist.
Aber die agile Softwareentwicklung war nicht die einzige Hochzeit, auf der man tanzen konnte. Tatsächlich gab es ein konkurrierendes Verfahren, das im verarbeitenden Gewerbe und in der Großindustrie beträchtlichen Erfolg hatte: Scientific Management (zu Deutsch etwa: wissenschaftliche Betriebsführung).
Scientific Management ist ein Top-down-Ansatz zur Führung. Manager verwenden solche Verfahren, um zu gewährleisten, dass zum Erreichen eines Ziels die besten verfügbaren Methoden eingesetzt werden, und weisen die Mitarbeiter an, dem Plan exakt zu folgen. Oder anders ausgedrückt: Es gibt eine umfassende vorherige Planung, der eine sorgfältige und detaillierte Umsetzung folgt.
Scientific Management ist wohl schon so alt wie die Pyramiden, Stonehenge oder die anderen großen Werke der Antike, weil es einfach unmöglich ist, zu glauben, dass sie ohne es entstanden sein könnten. Ich wiederhole es noch einmal: Das Konzept, einen erfolgreichen Vorgang zu wiederholen, ist zu naheliegend und zu menschlich, um es als revolutionär zu betrachten.
Die Bezeichnung Scientific Management geht auf die Arbeiten von Frederick Winslow Taylor in den 1880er-Jahren zurück. Er formalisierte und kommerzialisierte diesen Ansatz und machte als Management-Berater ein Vermögen. Das Verfahren war äußerst erfolgreich und führte in den nachfolgenden Jahrzehnten zu einer deutlichen Erhöhung der Effizienz und der Produktivität.
Und so kam es dazu, dass die Softwarewelt 1970 vor dem Scheideweg dieser beiden gegensätzlichen Verfahren stand. Beim prä-agilen Verfahren (agile Softwareentwicklung, bevor sie so bezeichnet wurde) werden kleine, reagierende Schritte unternommen, die bewertet und verfeinert werden, um durch zufällige Bewegungen in Richtung eines guten Ergebnisses vorwärtszukommen. Beim Scientific Management hingegen werden Aktionen verschoben, bis durch gründliche Analyse ein detaillierter Plan erstellt worden ist. Prä-agile Verfahren sind gut für Projekte geeignet, bei denen Änderungen nicht aufwendig sind und die teilweise definierte Aufgaben mit zwanglos festgelegten Zielen lösen. Scientific Management funktioniert am besten, wenn Projekte, bei denen Änderungen sehr aufwendig sind, genau definierte Aufgaben mit äußerst präzisen Zielen lösen.
Nun stellte sich die Frage: Zu welcher Kategorie gehörten Softwareprojekte zu diesem Zeitpunkt? Waren Änderungen sehr aufwendig und die Ziele präzise festgelegt oder waren Änderungen nicht aufwendig und die Ziele nur teilweise und zwanglos definiert?
Messen Sie dem letzten Absatz keine allzu große Bedeutung bei. Nach meinem Wissen stellt tatsächlich niemand diese Frage. Der Weg, den wir 1970 einschlugen, wurde ironischerweise offenbar eher zufällig als absichtlich ausgewählt.
1970 veröffentlichte Winston Royce eine Arbeit, die sein Konzept zur Verwaltung umfangreicher Softwareprojekte beschreibt. Die Arbeit enthielt ein Diagramm (Abbildung 1.1), das seinen Plan veranschaulichte. Royce hatte dieses Diagramm nicht selbst erstellt und er befürwortete das dargestellte Vorgehen auch nicht. Tatsächlich diente ihm das Diagramm nur als Vorwand, um es auf den nachfolgenden Seiten seiner Arbeit auseinandernehmen zu können.
Dessen ungeachtet führten die Platzierung an prominenter Stelle und die Neigung der Leser, aus einem Diagramm auf der ersten oder zweiten Seite einer Arbeit auf ihren Inhalt zu schließen, zu einer drastischen Umwälzung in der Softwarebranche.
Das Diagramm hat große Ähnlichkeit mit Wasser, das eine Reihe von Steinen herabfließt, deshalb wurde das Verfahren unter der Bezeichnung Wasserfallmodell bekannt.
Das Wasserfallmodell war der logische Nachfolger des Scientific Managements. Es geht vor allem darum, eine gründliche Analyse vorzunehmen, einen detaillierten Plan auszuarbeiten und diesen Plan in die Tat umzusetzen.
Royce hatte das Modell überhaupt nicht empfohlen, aber dieses Konzept war es, was die Leser seiner Arbeit entnahmen. Und es sollte die nächsten drei Jahrzehnte dominieren.
Und hier fängt die eigentliche Geschichte an. 1970 war ich 18 Jahre alt und bei einer Firma namens A.S.C. Tabulating in Lake Bluff, Illinois, als Programmierer tätig. Das Unternehmen verfügte über eine IBM 360/30 mit 16K Kernspeicher, eine IBM 360/40 mit 64K Kernspeicher und einen Minicomputer des Typs Varian 620/f mit 64K Kernspeicher. Ich programmierte die 360er in COBOL, PL/1, Fortran und Assembler. Auf dem 620/f programmierte ich nur Assembler.
Es ist wichtig, sich vor Augen zu führen, was es damals bedeutete, als Programmierer tätig zu sein. Wir schrieben unseren Code mit Bleistift auf Formulare, anhand derer Kartenstanzer-Operatoren Lochkarten für uns erstellten. Wir übergaben unsere sorgfältig überprüften Lochkarten an Computer-Operatoren, die unsere Programme und Tests während der dritten Schicht ausführten, weil die Computer tagsüber viel zu sehr damit beschäftigt waren, richtige Arbeit zu erledigen. Es dauerte oft mehrere Tage, um vom ursprünglichen Schreiben des Codes zur ersten Kompilierung zu gelangen. Und jede nachfolgende Aktualisierung dauerte für gewöhnlich einen Tag.
Bei der 620/f verhielt es sich für mich etwas anders. Die Maschine stand unserem Team zur Verfügung, sodass wir rund um die Uhr auf sie zugreifen konnten. Wir schafften zwei, drei, vielleicht auch mal vier Aktualisierungen oder Tests pro Tag. Das Team, zu dem ich gehörte, bestand aus Leuten, die – im Gegensatz zu heutigen Programmierern – in der Lage waren, Lochkarten zu stanzen. Wir konnten unsere Lochkartenstapel also selbst stanzen und waren nicht auf die Launen der Kartenstanzer-Operatoren angewiesen.
Welches Verfahren haben wir damals genutzt? Jedenfalls kein Wasserfallmodell. Wir hatten kein Konzept, einem detaillierten Plan zu folgen. Wir programmierten einfach so vor uns hin, kompilierten und testeten unseren Code und behoben Fehler. Es handelte sich um eine strukturlose Endlosschleife. Es war auch keine agile Softwareentwicklung, noch nicht einmal eine prä-agile. Unsere Arbeitsweise war undiszipliniert. Es gab keine Testsuiten oder vorgegebene Zeitintervalle. Wir programmierten und behoben Fehler, Tag für Tag, Monat für Monat.
Um 1972 habe ich zum ersten Mal in einer Fachzeitschrift etwas über das Wasserfallmodell gelesen. Es erschien mir als ein Glücksfall. Sollte es tatsächlich möglich sein, ein Problem vorab zu analysieren, eine Lösung dafür zu entwickeln und diese dann zu implementieren? Konnten wir wirklich anhand dieser drei Phasen einen Plan erstellen? Hätten wir nach Abschluss der Analyse tatsächlich ein Drittel des Projekts erledigt? Mir wurde die Leistungsfähigkeit dieses Konzepts bewusst. Ich wollte daran glauben. Denn wenn es funktionierte, würde das bedeuten, dass ein Traum wahr wird.
Ich war offenbar nicht der Einzige, denn viele andere Programmierer waren ebenfalls darauf aufmerksam geworden. Und wie gesagt dominierte das Wasserfallmodell allmählich unsere Denkweise.
Es war zwar vorherrschend, funktionierte aber nicht. Die nächsten 30 Jahre sollten ich, meine Kollegen und Programmierer rund um den Globus es immer wieder versuchen, die Analyse und die Fehlerbehebung richtig hinzubekommen. Aber immer wenn wir dachten, das Ziel erreicht zu haben, entglitt uns die Lösung in der Implementierungsphase wieder. Monate sorgfältiger Planung wurden durch irgendeinen unvermeidlichen kleinen Fehler hinfällig – vor den Augen der Manager und Kunden, nachdem die Abgabefrist schon krass überzogen worden war.
Doch trotz der praktisch nicht enden wollenden Reihe von Fehlschlägen blieben wir dem Wasserfallmodell treu. Was könnte schon falsch daran sein? Wie konnte eine gründliche Analyse des Problems, eine sorgfältige Entwicklung einer Lösung und die anschließende Implementierung immer wieder so spektakulär scheitern? Es war undenkbar, dass die Problematik etwas mit der Strategie zu tun hatte. Wir mussten das Problem sein. Irgendetwas machten wir falsch.
Das Ausmaß, in dem das Wasserfallmodell unsere Denkweise dominierte, zeigt sich in der damaligen Sprache. Nachdem Dijkstra 1968 strukturierte Programmierung vorgestellt hatte, folgten schon bald strukturierte Analyse und strukturiertes Design. Nachdem 1988 objektorientierte Programmierung (OOP) Verbreitung fand, folgten ebenfalls schon bald objektorientierte Analyse und objektorientiertes Design (OOD). Dieses Dreigestirn der Phasen hatte uns völlig in seinen Bann gezogen. Wir konnten uns schlicht und einfach keine andere Arbeitsweise vorstellen.
Und plötzlich konnten wir es doch.
Die Umstellung auf agile Softwareentwicklung nahm Ende der 1980er- oder Anfang der 1990er-Jahre ihren Anfang. In der Smalltalk-Community gab es Ende der 1980er-Jahre die ersten Anzeichen. Im 1991 erschienenen Buch von Booch gibt es ebenfalls Hinweise. Weitere Anzeichen finden sich in Cockburns Crystal Methods und die Design-Pattern-Commun...
![[Bild]](https://book-extracts.perlego.com/1644842/images/Abb01_00-plgo-compressed.webp)
![[Bild]](OEBPS/Images/Abb01_01-plgo-compressed.webp)