Einen sehr nachdenklichen Beitrag hat Gunter Dueck in seinem Daily Dueck zur Gier in Großunternehmen geschrieben, zu dem ständigen Zwang, alles noch schneller zu machen, und zur Rolle der Mitarbeiter in diesem Spiel: Das Schweigen ist Schrei!
Lesenswert.
Seit gestern ist es offiziell: Ich werde ab der Ausgabe September/Oktober 2008 als neuer Chefredakteur des OBJEKTspektrum die bisherige Chefredakteurin Frances Paulisch ablösen. Die Aufgabe ist spannend und es wird sich einiges tun. Das ist einer der Gründe, warum die letzten Wochen nicht mehr ganz so viel Zeit war zum Bloggen.
Für’s erste haben wir eine, wie ich finde, sehr gute Redaktion zusammengestellt, die mir bei der Auswahl der Artikel und Betreuung der Autoren helfen wird. Das heißt, in Zukunft erhalten Autoren Reviews zu ihren Manuskripten und Begründungen, warum ein Artikel angenommen wurde oder eben nicht. Zudem gibt es ab sofort einen regelmäßigen Aufruf zu Beiträgen, den man sich in Kürze abonnieren kann.
Für mich ist es ein wichtiger Schritt, mich neben meiner Beratungsarbeit auch stärker publizistisch zu engagieren. Ich hoffe, den Ruf des OBJEKTspektrum halten und in Richtung Qualität auch ausbauen zu können. Dafür sind wir natürlich auf gute Autoren angewiesen und auch auf jene, die noch gar nicht wissen, dass sie gute Autoren sind. Ich hege die Hoffnung, dass beide Gruppen unter den Lesern dieses Blogs überproportional vertreten sind – und rechne auf Ihre/Eure Unterstützung 🙂
Selbstverständlich werde ich auch weiterhin den größten Teil meiner Arbeitszeit der Beratung und Schulung zu agiler Entwicklung und Organisation widmen. Dafür macht mir die Arbeit einfach zu viel Spaß.
Ich höre immer wieder den Vorwurf an Teams, die mit XP arbeiten, sie hätten „keine Architektur“. Das halte ich für eine fundamentale Fehlinterpretation des Begriffs „Architektur“. Jedes Programm hat eine Architektur. Die mag adäquat sein, oder nicht, sie mag explizit dokumentiert sein, durch Tests abgesichert sein, oder unbewusst entstanden. Aber immer gibt es eine Architektur.
Die Vorstellung, man müsse eine Architektur explizit vor Beginn der Realisierung dokumentieren, damit sie kontrollierbar bleibe, halte ich ebenfalls für falsch. Ich habe viele Architekturdokumentationen erlebt, die zwar nett aussahen, mit der realen Architektur aber höchstens noch rudimentäre Ähnlichkeit besaßen. Umgekehrt habe ich exzellente Architekturen erlebt, die nirgends explizit dokumentiert waren. Sie waren höchstens durch Unit Tests und Mockobjekte abgesichert.
Wenn es um den wirtschaftlichen Nutzen einer Architektur geht, zählt die reale Architektur im Code. „Architekturen“, die nur auf der virtuellen Powerpointmaschine existieren und nichts mit dem real existierenden Code zu tun haben, sind wertlos. Ich habe eindrucksvolle und gut funktionierende Architekturen gesehen, die in traditioneller Technik zu Projektbeginn entworfen wurden. Gerade in XP Projekten entstehen aber auch immer wieder ausgezeichnete Architekturen ohne den großen ersten Wurf.
Will man einmal richtig Spaß haben, so werfe man in eine Gruppe von „Agilisten“ und „Traditionalisten“ das Stichwort „Architektur“: Als hätte man ein Zündholz in einen Strohhaufen geworfen entflammt sofort eine äußerst emotionale Diskussion, deren Randbereiche zwei Statements markieren: „Ohne eine saubere Anfangsanalyse und solide Anfangsarchitektur kommt kein ernsthaftes Projekt aus“ und „Wir brauchen keinen Architekten, die Architektur entsteht beim Programmieren“. Zwischen diesen beiden Extremen findet man fast jede denkbare Zwischenposition.
Ich habe viele dieser Diskussionen verfolgt und bin mittlerweile zu dem Schluss gelangt, dass hier mindestens drei verschiedene Themen munter durchmischt werden:
Ich denke, auf welche „Seite“ man sich bei diesen drei Fragen schlägt, hängt entscheidend von der Frage ab, was man sich von der Architektur erwartet. Die Antwort darauf wird oft stillschweigend als „selbstverständlich“ vorausgesetzt, ohne zu sehen, dass dort der eigentliche Konflikt liegt:
In traditioneller Sicht soll die Architektur Änderungen an bestehendem Code vermeiden. Sie sollte also so flexibel sein, dass zukünftige oder absehbare Anforderungen möglichst schon abgedeckt sind und ohne Änderungen an bestehendem Code oder zumindest der Architektur implementiert werden können. Architektur versucht die zukünftige Entwicklung vorauszusehen.
In agiler Interpretation soll Architektur Änderungen des Codes und ihrer selbst ermöglichen. Eine gute Architektur kann schnell an neue funktionale und nicht-funktionale Anforderungen angepasst werden. Sie ermöglicht möglichst viele zukünftige Entwicklungen. Änderbarkeit ist daher das Leitmotiv agiler Praktiken wie einfaches Design, testgetriebene Entwicklung, Refaktorisieren und Redundanzvermeidung.
Steht man auf dem Standpunkt, Änderungen an der Architektur seien schlecht und zu vermeiden, so wird man fast zwangsläufig zu dem Ergebnis kommen, dass die Architektur vor der Realisierung von einem starken Architekten erstellt werden müsse und daher nicht im Code repräsentiert werden kann.
Sieht man Änderungen als willkommenes Designwerkzeug, kann man die drei Fragen deutlich entspannter angehen. Die Antworten können sich nach anderen Faktoren richten, wie Kritikalität, Team- und Führungskultur und Erfahrung in der Domäne. Fast alle Kombinationen sind hier möglich; viele von ihnen auch in bestimmten Situationen sinnvoll.
In meinen Projekten kamen einige Teams ohne Architekten aus, andere ernannten irgendwann ein Mitglied zum Hüter der Architektur. Immer waren durch Refaktorisieren entstehende Architekturen in fast allen Qualitätsmerkmalen den zu Beginn erstellten Architekturen deutlich überlegen — und dazu auch noch wesentlich billiger. Zudem halte ich mir gerne Optionen offen.
„Der Horizont vieler Menschen ist ein Kreis mit Radius Null – und das nennen sie ihren Standpunkt.“
Entweder
Albert Einstein oder
David Hilbert oder
Leonhard Euler — so ganz klar ist das nicht
Sven Lindenhahn von der Uni Magdeburg führt eine Online-Umfrage für seine Diplomarbeit „Teams in Softwareentwicklungsprojekten“ durch. Die Umfrage beschäftigt sich vor allem mit der Auswirkung bestimmter Praktiken auf das Projekt, wobei ein starkes Gewicht auf agile Praktiken gelegt wird. Es dauert etwa 10 Minuten, den Fragebogen auszufüllen — gut investierte Zeit, um Forschungsarbeit zu agiler Entwicklung zu unterstützen. Wer seine E-Mail Adresse hinterlässt, bekommt die Ergebnisse zugesandt.
Direkt zur Umfrage geht es hier.
Im letzten Jahr habe ich die Ausgaben Mai und Oktober des Cutter IT Journal als Gasteditor herausgegeben. Die Maiausgabe beschäftigte sich unter dem Titel „Exploring the Agile Frontier“ mit dem Einsatz agiler Verfahren außerhalb der „Standardprojekte“, also mit verteilten Teams, bei lebenserhaltenden Systemen und in nicht-agilen Organisationen.
Die Oktoberausgabe hatte den Titel „Fostering Innovation: What Role Does Agile Software Development Play?„. Sie enthielt fünf Beiträge zum Zusammenhang zwischen Innovation und Agilität. Die Thesen verliefen von „Agilität behindert Innovation“ bis zu „Agilität ist die Geburtshelferin der Innovation“.
Aufgrund der großen Nachfrage hat Cutter nun beide Ausgaben zu dem Report „Fostering Innovation on the Agile Frontier“ zusammengefasst.
Frank Westphal hat in seinem Podcast „Tonabnehmer“ den fünfzehnten Beitrag dem siebenjährigen Jubiläum des Agilen Manifests gewidmet. In diesem einstündigen Beitrag diskutieren Jutta Eckstein, Johannes Link, Henning Wolf und ich über die Auswirkungen des agilen Manifests auf die Branche, auf uns persönlich und auf die Zukunft. Hören Sie den Beitrag unter http://www.frankwestphal.de/Tonabnehmer15-JuttaEckstein-JohannesLink-JensColdewey-HenningWolf-7JahreAgilesManifest.html.
Vielleicht gehören Sie zu denen, die einiges zu agiler Entwicklung gelesen haben, die manches interessant finden, anderes eher skeptisch sehen und die im Großen und Ganzen noch nicht so recht wissen, was Sie davon halten sollen. Wenn Sie Lust haben, einen Tag dafür zu investieren, agile Entwicklung zu erleben, sollten Sie darüber nachdenken, am 28. April zur SEE 2008 in Bern zu kommen.
Sie haben dort Gelegenheit, agile Techniken zu erleben und zum Teil auch auszuprobieren. Gemeinsam mit Bernd Schiffer von it-agile werde ich die Grundlagen agiler Entwicklung vorstellen, Sie werden ein „Mini-Projekt“ selbst mit agilen Managementtechniken durchführen und können am praktischen Beispiel verfolgen, wie testgetriebene Entwicklung und Refaktorisieren in der täglichen Arbeit ablaufen.
Nähere Informationen finden Sie unter http://www.see-conf.de/workshop_agile.html
Ich: „So ein Wasserfall ist ja meistens eh ein potempkin’sches Dorf, hinter dessen Kulissen Chaos herrscht.“
Meine Frau: „Nicht ganz, ich sehe das eher als ‚Einstürzende Neubauten’…“