Ein Gespräch mit Martin Fowler, Wolf Schlegel und Erik Dörnenburg von ThoughtWorks

Agile, DevOps und Continuous Delivery – eine Bestandsaufnahme

In Frankfurt trafen wir auf Martin Fowler, ein Urgestein der agilen Softwareentwicklung und Mitunterzeichner des Agilen Manifests, sowie seine ThoughtWorks-Kollegen Erik Dörnenburg und Wolf Schlegel. Neben dem Thema Agile ging es auch um Continuous Integration, Continuous Delivery und die DevOps-Bewegung.

Martin Fowler

Martin Fowler ist Autor, Konferenzsprecher und ein allgemein gefragter Experte für Softwareentwicklung mit Schwerpunkt auf Enterprise-Software.
Er leistete Pionierarbeit in den Bereichen Refactoring, Patterns, Agile Methoden und Domain Modeling. Seit 2000 ist Fowler Chief Scientist bei der internationalen Anwendungsentwickler Firmma ThoughtWorks. Er hat sechs Bücher über Softwareentwicklung veröffentlicht, zuletzt Patterns of Enterprise Application Architecture und Domain Specivic Languages. Ferner
schreibt er regelmäßig Artikel, die er auf martinfowler.com veröffentlicht.

Erik Dörnenburg

Erik Dörnenburg ist Head of Technology Europe bei ThoughtWorks. In Projekten hilft er Kunden bei Design und Implementierung von Enterprise-
Software. Häufig mit übermäßig komplexer Software konfrontiert,
entwickelte er ein starkes Interesse an einfachen Architekturen und Möglichkeiten, Software zu visualisieren, um sie dadurch verständlicher zu machen. Seine Karriere im Bereich Enterprise-Software begann in den frühen Neunziger Jahren mit der NeXTSTEP-Plattform. Seit damals ist er ein Verfechter agiler Werte und von Open-Source-Software. Er studierte
Informatik an der Universität Dortmund sowie Computerwissenschaft und Linguistik am University College in Dublin.

Wolf Schlegel

Wolf Schlegel ist Principal Consultant bei der ThoughtWorks Deutschland GmbH in Hamburg. In den letzten Jahren hat Wolf vorwiegend in den Bereichen Continuous Delivery und E-Commerce gearbeitet. Das Spektrum seiner Aufgaben umfasst Workshops und Assessments in den Bereichen Technologieauswahl, Architektur und Continuous Delivery ebenso wie Hands-on-Entwicklung in langlaufenden Projekten.

Sebastian Meyen: Zunächst interessiert mich deine Sicht auf die zehn Jahre, seit die Agile-Bewegung mit dem Manifest begann. Einerseits gab es die ALM-Welt die die Auffassung vertrat, dass es für ausgereifte Prozesse eine ganze Reihe schwergewichtiger Tools braucht. Mein Eindruck ist nun der, dass wir gerade eine Post-ALM-Ära erreichen oder schon erreicht haben, insofern, als ALM-Provider agiler und leichtgewichtiger werden, während die traditionellen Agile-Leute nun ein wenig über Tools reden, was vorher nicht der Fall war. Wie siehst du das?

Martin Fowler: Dass Tools von Agile-Leuten immer ignoriert wurden, stimmt nicht. Die Agile-Community hat sich doch zum Beispiel für Refactoring-Tools sehr stark gemacht oder für das Erstellen von Testframeworks. Und wer entwickelte JUnit? Kent Beck, man kann sich keinen besseren Vertreter der agilen Bewegung vorstellen. Nein, es war eher die Art der von vielen Herstellern beworbenen Werkzeuge, die wir für unangemessen hielten. Was wir brauchten, war ein Umdenken in Sachen Tools, die Einsicht, dass Tools gegenüber den Entwicklern zweitrangig sind. Das ist auch ein Grundgedanke des Manifests: die Einsicht, dass die Menschen, die in einem Team zusammenarbeiten, viel wichtiger sind als Werkzeuge. Was nicht bedeutet, dass Tools unwichtig wären. Aber sie spielen eben eine untergeordnete Rolle.

Erik Dörnenburg: In diesem Kontext dürfen wir Continuous Integration nicht vergessen. Vor mehr als zehn Jahren haben wir Tools in Bereichen verwendet, wo sie nicht so auffielen. Sie haben aber eine völlig neue Arbeitsweise ermöglicht. Also stimme ich mit Martin darin überein – das passiert durchaus hier und da (lacht) – dass Tools sogar eine wichtige Rolle in der Agile-Community spielten. Schließlich steht Agile für ein Wertesystem, nicht nur für einen Prozess, und die Werkzeuge waren eine Voraussetzung für eine darauf aufbauende Arbeitsweise. Ohne IDE, mit der man binnen einer halben Sekunde einen Test ausführen kann, waren die anderen Werkzeuge, die du erwähnt hast, auch nicht sinnvoll. Oder nehmen wir die Unterstützung für automatisches Refactoring – das sind alles Dinge, die dadurch beeinflusst wurden, wie wir Software schreiben.

Meyen: Könnt ihr beschreiben, welche Art von Werkzeugen im Rahmen dieses Wertesystems entstanden sind? Gibt es eurer Meinung nach Unterschiede zwischen der „alten Welt“ mit ihren Tool Chains und der agilen, taktischen, Open-Source-orientierten Toollandschaft von heute?

Wolf Schlegel: Rufen wir uns die Schlüsselkonzepte von Continuous Delivery ins Gedächtnis: Zusammenarbeit, Kommunikation und Automatisierung. Automatisierung ist unmöglich ohne Werkzeuge. Zusammenarbeit und Kommunikation können durch Tools unterstützt werden, aber wiederum, und das ist das Entscheidende, um die Menschen zu unterstützen. Wenn es darum geht, die entsprechenden Werkzeuge für ein neues Projekt auszuwählen, bin ich ein sehr starker Befürworter der Best-of-Breed-Strategie, das heißt, das jeweils beste Tool für eine bestimmte Aufgabe auszuwählen, statt sich eine komplette Toolsuite verkaufen zu lassen. Selbst wenn man einiges in die Benutzung eines bestimmten Tools investiert hat: Werkzeuge sind letztendlich nur als Teil einer Software für einen bestimmten Zeitraum gedacht. Früher oder später wird man sie sowieso ausrangieren und sich nach anderen umschauen. Nicht an überholten Werkzeugen festhalten, nur weil sie teuer sind! Es ist viel teurer, an ihnen festzuhalten.

Fowler: Meiner Ansicht nach hat die wesentliche Veränderung nichts mit der Unterscheidung zwischen „praktisch“ und „strategisch“ zu tun. Ich halte zum Beispiel Werkzeuge, die im Kontext von Continuous Integration und Delivery verwendet werden, für sehr strategisch, überhaupt nicht für taktisch. Gleiches gilt für Testtools. Die Veränderung besteht darin, dass die Werkzeuge von denjenigen ausgewählt werden, die sie verwenden. Bisher war es üblich, dass Werkzeuge zwei oder drei Ebenen höher in der Managementkette bestimmt werden oder, wie ich immer sage, auf dem Golfplatz. Hier liegt der Kern vieler Probleme: Sobald man zu weit von der tatsächlichen Anwendung entfernt ist, macht man es sich mit der Auswahl der Werkzeuge allzu leicht. Wir haben immer wieder beobachtet, dass Leute das Gefühl haben, sie müssten die Werkzeuge nur zum Einsatz bringen, um deren Anschaffung zu rechtfertigen, mit anderen Worten: erst anschaffen, dann einen Zweck dafür finden. Erst muss ein konkretes Geschäftsproblem bestehen, bevor man abschätzen kann, ob sich der Einsatz eines Tools lohnt.

Mehr zum Thema


src=“http://entwickler.com/develop/zonen/magazine/onlineartikel/pspic/picture_file/73/Java_Magaz4f70327d1144b.png?1332755185″ hspace=“10″ vspace=“5″ alt=““>

Mehr zu den Themen DevOps und Continuous Delivery finden Sie in den Ausgaben 1.2012 und 3.2012 des Java Magazins:

Java Magazin 1.2012: DevOps

Java Magazin 3.2012: Continuous Delivery

Ein Blick lohnt sich!

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.