Vergleicht man die Softwareentwicklung mit klassischen, eher industriell ausgerichteten Berufen, fällt ein Aspekt besonders aus: Während in industriellen Berufen die Arbeitszeit in der Regel deckungsgleich mit der Anwesenheitszeit ist, gilt dies in den Berufen der Softwareentwicklung nicht.

Fast jeder Softwareentwickler kennt den Effekt, dass es gewisse Zeiten am Arbeitsplatz gibt, in denen man sich mit allem beschäftigt, nur nicht mit der eigentlichen Arbeit: Man ruft E-Mails ab, stöbert in Foren, liest Nachrichten, ruft nochmals E-Mails ab, …

An solchen Tagen befindet man sich nicht im Fluss. Selbst wenn man an solchen Tagen versucht, produktiv zu arbeiten – es gelingt einfach nicht. Joel Spolsky hat dies in einem äußert lesenswerten Blogeintrag namens Fire and Motion beschrieben. Sein zwischen den Zeilen eingeschobenes Fazit lautet:

Maybe as a software developer I really can't control when I'm productive, and I just have to take the slow times with the fast times and hope that they average out to enough lines of code to make me employable.

Das Interessante daran ist nicht, dass dieses Verhalten verbreiteter ist als allgemein angenommen – schließlich wird kaum ein Arbeitnehmer diese Einstellung öffentlich zugeben.

Das Interessante daran ist, dass ein solches Verhalten all zu menschlich und durchaus auch in Ordnung ist – sofern das Ergebnis stimmt.

Anders formuliert: Wenn ein bestimmtes Ergebnis in einer bestimmten Zeit mit einer bestimmten Qualität vorliegen muss, ist es für das Ergebnis zunächst unerheblich, ob der dafür verantwortliche Entwickler eine Stunde oder zwei Wochen benötigt hat.

Dass in diesem Fall nicht nach Zeit abgerechnet werden kann, sondern ein fixer Betrag für das Ergebnis vereinbart werden muss, liegt auf der Hand. Nichtsdestotrotz: Für das reine Ergebnis spielt die dafür benötigte Zeit keine Rolle – sofern das Ergebnis stimmt und alle Bedingungen wie beispielsweise Qualität oder Zeit eingehalten wurden.

Ein solches Arbeiten lässt dem Arbeitnehmer viele Freiheiten, insbesondere im Hinblick auf seine Arbeitszeit und damit prinzipiell auch auf den Arbeitsort. Nun könnte man vermuten, dass ein solches Arbeiten illusorisch ist – Fakt ist aber, dass es von einigen Firmen bereits gelebt wird. Die Bezeichnung hierfür lautet ROWE – Results-Only Work Environment.

Ralf Westphal hat darüber schon einige Male berichtet, doch auch die Häufigkeit der Erwähnung in Zeitschriften nimmt zu: Spiegel Online und das Wall Street Journal sind dafür nur zwei Beispiele von vielen.

Wird ROWE als funktionierend akzeptiert, steigt zugleich auch die Bereitschaft, Arbeit in verstreuten Teams gutzuheißen: Dass räumliche Nähe überbewertet wird, zeigt sich bei ROWE mehr denn je: Denn sofern das Ergebnis stimmt, spielt nicht nur die dafür benötigte Zeit keine Rolle – auch die Lokation wird irrelevant.

Dass ROWE zu Beginn ungewohnt und nicht funktionsfähig erscheint, liegt auf der Hand: Zu sehr sind Arbeitnehmer die klassische Arbeit in einem gemeinsamen Büro von 9 bis 17 Uhr gewöhnt, als dass sie überhaupt jemals über mehr Freiheit nachgedacht hätten. Ralf hat diese Haltung in einem Kommentar bereits schön beschrieben:

Die meisten suchen nach einem Nein zur Verteilung. Immer wieder wird der Kopf in Skepsis gewogen. "Ei, ei, ei, das ist aber schwierig... Hm... Ne, besser Colocation..."

Das versteh ich nicht. Was ist denn das für eine Argumentation? Die ist nämlich immer aus dem Blickwinkel von Kunde und Chef. Denen will man mit möglichen Friktionen durch Distanz keinen Schaden zufügen.

Das ist natürlich eine löbliche Haltung. "Brav, liebe Angestellte, dass ihr so für uns Unternehmer denkt."

Ich habe zunehmend das Gefühl, dass die Kritiker von verstreuter Entwicklung noch kein Projekt miterlebt haben, in dem verstreute Entwicklung funktioniert hat.

Aus dieser Empirie wird der naheliegende, jedoch falsche Schluss gezogen, dass diese Empirie eine entsprechende Regel rechtfertigen würde – da eine verstreute Entwicklung anscheinend nicht funktioniert, wird auf das vertraute und vermeintlich bewährte Konzept von Colocation zurückgegriffen wird.

Dabei wird übersehen, dass es durchaus erfolgreiche verstreute Teams gibt – doch niemand fragt sich, wieso es bei diesen Teams funktioniert und was diese Teams von dem eigenen unterscheidet. Niemand hinterfragt die eigene Arbeitsweise kritisch und versucht, den Ursachen gemäß Root Cause Analysis auf den Grund zu gehen.

Insofern kann ich mich Ralf nur anschließen, wenn er fragt:

Niemand, nicht ein einziger hat so reagiert. Warum? Warum sucht keiner ein Ja zur Verteilung für sich selbst – um dann natürlich zu überlegen, wie das Projektziel immer noch erreicht werden kann?

Ist Autonomie/Freiheit so furchtbar? Ist es soviel angenehmer, die lieben Kollegen jeden Tag 9-17 sehen zu müssen? Steht das Wohl des Projektes (das anscheinend an der Colocation hängt) höher als mein Wohl?

Ein Faktor dabei sind wie bereits gesagt die Arbeitnehmer, die sich verstreutes Arbeiten auf Grund fehlenden positiven Erlebens wenn, nur sehr schwer vorstellen können – und es für etwas exotisches, fremdartiges halten, das nur bei hochspezialisierten Teams funktionieren könne, aber nicht in ihrem eigenen.

Dass man Dingen, die man nicht kennt und die zudem noch fremdartig erscheinen, zunächst skeptisch gegenübersteht, ist all zu menschlich. Insofern besteht die einzige Möglichkeit, hieran etwas zu ändern, darin, die Skepsis zu nehmen – indem positives Erleben vermittelt wird.

Ein anderer Faktor sind jedoch auch die Arbeitgeber, beziehungsweise deren Vertreter – im weitesten Sinne also das Management. Und warum fällt es dem Management schwer, sich auf ROWE einzulassen? Weil ROWE bedeutet, Kontrolle abzugeben und Vertrauen zu müssen.

Dass diese Kontrolle bei Softwareentwicklung ohnehin mehr Augenschein als Fakt ist, wird dabei gerne übersehen.

Doch vom Management wird noch mehr gefordert, als lediglich Kontrolle durch Vertrauen zu ersetzen: Implizit wird nämlich die Existenzberechtigung des Managements in Frage gestellt: Wenn sich – allen agilen Methoden zu Folge – die Teams selbst organisieren und dann noch nicht einmal kontrolliert werden – wer braucht dann noch Management?

Aus Selbsterhaltung wird also lieber am bewährten Status Quo festgehalten, zumal die meisten Arbeitnehmer dies ohnehin nicht in Frage stellen. Dass aber unter diesem künstlich aufrecht erhaltenen Status Quo vor allem die Motivation der Arbeitnehmer leidet, wird missachtet.

Auf diese Art erweist sich ein Unternehmen einen Bärendienst: Nicht nur, dass ein aufwändiges Management zur Kontrolle der Arbeitnehmer beschäftigt wird – die wie gesagt nicht wirklich gegeben ist – nein, zusätzlich erbringen die Arbeitnehmer auch nicht die Leistung, die sie erbringen könnten und sogar gerne würden, wenn sie sich nur rundherum wohlfühlen würden.

Die Folge dessen ist, dass entweder Überstunden angeordnet werden, die allerdings die Motivation noch weiter senken, oder weitere Mitarbeiter eingestellt werden – wobei eine Aufgabe nicht unbedingt dadurch schneller erledigt wird, dass mehr Leute zeitgleich daran arbeiten.

Doch – ist die Existenzberechtigung des Managements wirklich in Frage gestellt, wenn nach ROWE gearbeitet wird?

Ich meine nicht. Das Management muss sich nur als etwas anderes begreifen als dies in der Regel der Fall ist: Das Verb to manage bedeutet außer leiten und verwalten nämlich auch bedienen und besorgen: Nimmt man diese Bedeutung einmal wörtlich – welche Konsequenzen ergeben sich daraus für das Management?

Entwickler sind bekanntermaßen im Vergleich zu anderen Arbeitnehmern relativ teuer. Provokant gefragt: Warum räumt das Management dann nicht ungefragt alle Hindernisse aus dem Weg, die der effizienten Arbeit der Softwareentwickler im Weg stehen?

Warum müssen sich teure Entwickler in der Realität mit anderen, nebensächlichen Aufgaben aufhalten, statt sich auf ihre Arbeit konzentrieren zu können? Zu diesen nebensächlichen Aufgaben gehören klassischerweise Aufgaben wie:

• Sicherstellen, dass im Drucker und Kopierer stets genügend Papier vorhanden ist und gegebenenfalls nachgefüllt wird.
• Umständliche Formulare ausfüllen, wenn ein Buch für die persönliche Weiterbildung und die des Teams angeschafft wird.
• Aufwändige Reisekostenanträge ausfüllen, nachdem sie von einem geschäftlichen Termin zurück sind.

Diese Liste ließe sich problemlos noch um zahlreiche weitere Punkte ergänzen: Warum übernimmt nicht das Management diese Aufgaben und lässt die Entwickler einfach nur das machen, wofür sie ursprünglich und eigentlich eingestellt wurden und was sie auch am Besten können – entwickeln?

Genau das war der Antrieb für Joel Spolsky, FogCreek Software zu gründen, die sich an dem selbst gewählten Motto

We help the world’s best developers make better software.

orientiert. Auf der offiziellen Über uns-Seite der Firmenwebseite von FogCreek Software wird die Firma folgendermaßen beschrieben:

We had a different idea. What if the programmers were treated like rock stars? What if management’s number one responsibility was recruiting extremely talented software people, treating them well, and then getting the heck out of the way while they did great work?

At Fog Creek Software, management, not coding, is the support function. Management’s first responsibility is to create an abstraction layer for developers: to create the infrastructure so that programmers really just have to program:

Genau das beschreibt, was ich als Managament as a Service (MaaS) bezeichne – und genau das beschreibt, was für ROWE und verstreute Entwicklung zwingend erforderlich ist.

Gestern habe ich in meinem Blogeintrag Räumliche Nähe wird überbewertet über die häufig betonte – meiner Meinung nach überbewertete – Bedeutung von räumlicher Nähe für Entwickler geschrieben.

Besonders interessant fand ich die zahlreichen Reaktionen, die mich größtenteils in Form von Kommentaren in meinem Blog erreicht haben. Diese reichen von absoluter Zustimmung wie

Schön, dass du diesen Mythos mal aufs Korn nimmst. Ich sehe es genauso: Colocation ist überbewertet.

bis hin zu gänzlich gegensätzlichen Ansichten:

Deswegen kann ich nur allen raten die von “Colocation” und der Unbedeutsamkeit der Örtlichkeit reden sich ins reelle Leben zu begeben […] Think global. Face reality.

Besonders gefreut hat mich, dass Ilker Cetinkaya das Thema aufgegriffen und seine Sicht der Dinge in dem Blogeintrag Räumliche Nähe wird unterschätzt beschrieben hat. Dort widerspricht er mir mit den Worten:

Nun, dem muss ich deutlich widersprechen. Genau das Gegenteil ist der Fall – und sowohl sein Artikel als auch die Kommentare dazu sind in meinen Augen eine Bestätigung: Räumliche Nähe wird einfach noch viel zu oft unterschätzt!

Das ist eine spannende Ausgangslage – zwei Blogeinträge zum gleichen Thema, aber gänzlich verschiedene Meinungen.

Da ich in meinem Blogeintrag Bezug auf die gute Zusammenarbeit von Peter Bucher und mir genommen habe, und Ilker diese nicht kennen kann, traf er einige Annahmen – diese möchte ich zunächst mit Fakten unterlegen, bevor ich auf die übrigen Argumente eingehe.

Das Beispiel ist ein Zeugnis von professioneller Software-Entwicklung. Da arbeiten offensichtlich zwei Profis zusammen. Sehr gut. Golo leitet daraus ab, dass es nicht zwingend notwendig sei, Teammitglieder an einem Ort, in einem Gebäude, in einem Raum zu haben, um effektiv ein “Team” zu sein. Nun, das mag ja schön und gut sein. Aber Golo: Hast Du denn Vergleiche? Und wenn ja, hast Du gemessen, wie “effektiv” denn beides ist? Ich befürchte nein. Wäre dem so, dann wäre mit großer Wahrscheinlichkeit Dein Fazit anders ausgefallen.

Was ich damit zum Ausdruck bringen will, ist, daß Golo und Peter wohl nie in einem Raum über längere Zeit zusammen gearbeitet haben. Ich unterstelle das jetzt einfach einmal Golo & Peter; bitte korrigiert mich und verzeiht mir, wenn dem nicht so ist. Es dient mir zur Illustration meiner Perspektive zum Thema.

Die kurze Antwort lautet: Deine Vermutung ist richtig. Da Peter und ich uns auf Grund der Entfernung eher selten – und wenn, dann zumeist im Rahmen von Usergroups und ähnlichen Treffen – sehen, haben wir noch nicht zusammen an einem Tisch gearbeitet.

Also, wäre dem so, so hätte Golo gar keinen Vergleich der Effektivität & Effizienz des Teamgefüges zwischen ihm und Peter. Beide sind ausgewiesene Profis in der Software-Entwicklung und schaffen aus der Distanz gemeinsam gute und effiziente Teamarbeit. Der Artikel von Golo beweist es. Man stelle sich nur vor, welche Produktivität und Ingenieursleistung möglich wäre, wenn zwei solche Profis an einem Tisch arbeiten würden. Wow.

Der Schluss von Ilker ist korrekt – ich habe keinen Vergleich bezüglich der Effektivität und Effizienz des Teamgefüges zwischen Peter und mir. Nun fehlen mir an dieser Stelle aber zwei Punkte:

Erstens: Ilker impliziert, dass unsere Produktivität und Ingenieursleistung noch viel höher sein könnte, wenn Peter und ich an einem Tisch arbeiten würden. Zweitens: Ilker sieht die Frage, ob ich den Vergleich überhaupt ziehen kann, als relevant an.

Ich habe in meinem vorigen Blogeintrag geschrieben, dass erfolgreiche Teams zwei Aspekte als Grundlage bedürfen: Vertrauen und gegenseitige Wertschätzung. Zwei Metriken, die auf Grund ihrer emotionalen und allzu menschlichen Natur nur schlecht in harte Zahlen gefasst und messbar gemacht werden können.

Warum auch immer, im Lauf der Zeit sind zwischen Peter und mir großes Vertrauen und hohe gegenseitige Wertschätzung entstanden und gewachsen. Dazu war die fehlende räumliche Nähe unerheblich – das Verständnis könnte heute nicht besser sein, auch wenn die räumliche Nähe gegeben gewesen wäre.

Natürlich kann ich das nicht im wissenschaftlichen Sinne beweisen, aber wie gesagt, dies sind ohnehin Metriken, die nur schlecht in Zahlen gefasst und gemessen werden können.

Daher bezweifle ich auch nicht nur, dass unsere Produktivität und Effizienz höher sein könnte, wenn wir an einem Tisch sitzen würden, sondern auch, dass die Frage nach der Vergleichbarkeit relevant ist.

Damit sind wir auch schon an einem wichtigen Punkt. Agile Software-Entwicklung und deren Verfahrensweisen behaupten nicht, dass es notwendig sei, ein Team an einem Fleck zu haben, um (gut) Software zu entwickeln.

Agile Methoden behaupten das vielleicht nicht durch die Bank, aber es gibt doch einige Fälle, in denen dies postuliert wird:

• Extreme Programming (XP): Einer der Werte von XP ist Communication, in dessen Definition unter anderem “[…] and we communicate face to face daily” enthalten ist. Da face to face ein persönliches Gespräch von Angesicht zu Angesicht bedeutet, erfordert XP de facto räumliche Nähe.
• Crystal Clear: Alistair Cockburn, der Erfinder der Crystal-Familie, geht in seinem Buch Crystal Clear: A Human-Powered Methodology for Small Teams sogar so weit, zu behaupten, dass Crystal Clear für verteilte Entwicklung nicht geeignet sei und räumliche Nähe zwingend erforderlich ist.

Selbst das Agile Manifest hebt in den zwölf agilen Prinzipien den Wert persönlicher Gespräche von Angesicht zu Angesicht als eigenen Punkt hervor:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Insofern wird zwar nicht explizit verlang, dass sich das Entwicklungsteam an einem gemeinsamen Standort befinden muss – implizit ist diese Forderung aber sehr wohl enthalten.

Weiter schreibt Ilker:

Doch nicht nur gute Kommunikation ist ein Ziel der Co-location. Ein aus meiner Sicht wesentlich wichtigerer Faktor ist der Faktor der Transparenz.

Durch die Nähe zueinander sieht man auch, was der andere so macht. Soll heissen, man lernt seinen Tagesablauf, seine Aufgaben, seine Tools, seine Herausforderungen – na eben das ganze Arbeitsumfeld. Umgekehrt sehen andere, mit welchen Dingen man selbst tagtäglich konfrontiert ist und was es tatsächlich bedeutet, Software zu entwickeln. Durch die Transparenz entsteht mehr Verständnis zu der Aufgabe und der Leistung des anderen Teammitglieds. Man versucht sich gegenseitig zu helfen und aufzubauen. Das wiederum hilft der Kommunikation und der Produktivität im Team.

Das, was Ilker als Transparenz bezeichnet, erachte ich ebenfalls als wichtig. Doch auch hierfür ist meiner Erfahrung nach räumliche Nähe nicht zwingend erforderlich: Wenn die Frage Na, wie geht’s? nicht nur eine Floskel ist, sondern ihr ernsthaftes Interesse am Wohlbefinden des Gegenübers widerspiegelt, ist es gleich, ob ich das in Skype, im Windows Live Messenger oder eben persönlich frage.

Räumliche Nähe fördert dies nicht zwingend – wie viele Entwickler werden zu Beginn der Woche von ihrem Chef gefragt, wie das Wochenende war – aber nicht aus wirklichem Interesse, sondern als Smalltalk, als Floskel. Wenn es aber kein Smalltalk und keine Floskel ist, sondern es um den Menschen an sich geht, dann funktioniert das auch, wenn sich beide Gesprächspartner am jeweils anderen Ende der Welt befinden.

Spricht man darüber hinaus nicht nur über fachliche Belange im Sinne der aktuellen anstehenden Aufgaben, sondern auch über alltägliches und persönliches, dann ergibt sich auch ohne räumliche Nähe Verständnis für den anderen. Auch dann versucht man, sich gegenseitig zu helfen, sich aufzubauen, …

Abschließend führt Ilker noch den Wert

Individuals and Interactions over Processes and Tools

des des Agilen Manifests an, als Beleg für die Notwendigkeit räumlicher Nähe. Doch inwiefern ist der Zwang nach räumlicher Nähe ein Eingehen auf Individuen und deren Interaktion? Ist räumliche Nähe als bindende Verpflichtung nicht vielmehr ein Mittel eines Prozesses, der Individuen aufgezwungen wird?

Wenn ein Team sich entscheidet, dass es auch in einem verteilten Szenario dermaßen gut miteinander interagiert, dass es darauf guten Gewissens verzichten kann – ist dann die Forderung nach verbindlicher räumlicher Nähe nicht gerade das Gegenteil dessen, was das Agile Manifest fordert?

Vergangene Nacht habe ich geschrieben, dass räumliche Nähe überbewertet wird –zumindest in Bezug auf das eigentliche Entwicklungsteam. Letztlich argumentierte ich hierbei auf Basis der Aussage, dass nicht die räumlichen Gegebenheiten ein Team formen, sondern die beteiligten Menschen:

Natürlich hat räumliche Nähe Vorteile – aber sie ist für das Funktionieren als Team unerheblich. Wichtig hierfür sind andere Aspekte, allen voran jedoch Vertrauen und gegenseitige Wertschätzung. Wenn ein Team diese Aspekte aufweist, ist es unerheblich, wie viele Kilometer zwischen den Teammitgliedern liegen.

Wichtig ist also, dass innerhalb eines Teams Vertrauen zueinander herrscht, und die einzelnen Teammitglieder einander wertschätzen:

Denn dann entsteht eine viel intensivere Nähe als es die räumliche Nähe per se jemals leisten könnte. Diese intensivere Nähe zeichnet sich durch Verständnis, Wertschätzung und gemeinsame Werte aus – und das ist es, was ein Team als Team erfolgreich macht.

Die Frage ist nur, wie ein Team dorthin gelangt? Den entscheidenden Faktor habe ich bereits erwähnt, wenn auch ein wenig versteckt in einem Nebensatz: Das Management kann ein Team nicht aktiv dorthin bringen, Vertrauen und gegenseitige Wertschätzung aufzubauen.

Das einzige, was das Management dazu beitragen kann, ist, mit viel Menschenkenntnis geeignete Mitarbeiter auszusuchen, so dass sich das Team selbst als Team bilden kann – letztlich auf die gleiche Art, wie sich Freundschaften bilden. Auch hierzu kann ein Außenstehender wenig beitragen:

Die hohe Kunst ist nun, Teams sich entwickeln zu lassen, dass solche Konstellationen überhaupt erst entstehen können. Hierzu kann das Management nicht viel beitragen, außer Menschenkenntnis, […]

Das bedeutet insbesondere, dass nicht jede Konstellation von Menschen im Lauf der Zeit automatisch zu einem erfolgreichen Team wird – es hängt schlichtweg von den einzelnen Menschen ab, ob und wie diese miteinander zurecht kommen. Diese Erkenntnis weist nun jedoch zwei Seiten auf:

Einerseits mag diese Erkenntnis bitter und unangenehm sein, weil es sich mitunter als äußerst schwierig erweisen kann, geeignete Teammitglieder zu finden – zu den üblichen fachlichen Ansprüchen kommen nun noch gruppendynamische hinzu, was den Prozess der Auswahl eines Bewerbers bedeutend erschwert.

Andererseits bedeutet dies jedoch auch zugleich, dass ein Team, das sich einmal gefunden hat, in der Regel auch langfristig miteinander harmoniert, und die gewonnenen Synergieeffekte im Lauf der Zeit automatisch zunehmen – schließlich spielt sich das Team immer besser ein und weiß, wie es als Team funktioniert.

Hat sich ein solches Team einmal etabliert, ist von Seiten des Managements kaum noch aktiv etwas zu leisten – außer Vertrauen und dem Schaffen von ungestörtem und unbehindertem Arbeiten. Das heißt, für ein solches Team besteht die Aufgabe des Managements darin, alles aus dem Weg zu räumen, was die Produktivität und Effizienz des Teams senken könnte.

Insgesamt resultiert daraus auch eine essenzielle Konsequenz: Etablierte Teams, die als gemeinsames Team funktionieren und Synergieeffekte ausgebildet haben, dürfen unter keinen Umständen wieder getrennt werden – ansonsten verliert man nicht nur das Team, sondern setzt auch die Motivation der einzelnen Teammitglieder auf das Spiel.

Wichtig ist also, dass Teams dauerhaft zusammen bleiben, was ich als Stetige Teams (Team Continuity) bezeichnen würde.

Häufig wird stetigen Teams entgegengesetzt, dass dies nicht möglich sei – schließlich sei das aktuelle Projekt eines Tages abgeschlossen, und die einzelnen Teammitglieder würden für neue Projekte benötigt. Zumeist dienst dies als Begründung, etablierte und funktionierende Teams nach einer Weile doch zu trennen.

Doch es gibt einen einfachen, aber hoch effektiven Ausweg: Teams bleiben dauerhaft erhalten – und nach Beendigung des aktuellen Projekts wird nicht danach geschaut, welches Teammitglied welcher neuen Aufgabe zugeordnet werden kann – statt dessen wird danach geschaut, welche Aufgabe dieses etablierte Team als Team als nächstes übernehmen kann.

Auf diese Art bleiben Synergieeffekte projektübergreifend erhalten und neue Projekte können wesentlich schneller begonnen werden – schließlich ist das Team bereits aufeinander eingespielt und kennt sich.

Das bedeutet in letzter Konsequenz jedoch auch, dass ein Team die verschiedensten Aufgabenbereiche abdecken können muss – das eine Projekt ist technologielastiger, das andere hingegen UI-lastiger. Hier zahlt sich aus, wenn ein Team nicht aus reinen Spezialisten besteht, sondern jeder Spezialist auch in gewissem Sinne Generalist ist und Wissen innerhalb des Teams ausgetauscht und weitergegeben wird.

Auch agile Methoden profitieren von stetigen Teams – als Beispiel hierfür sei genannt, dass ein bestehendes Team seine Velocity kennt und ein neues Projekt auf dieser Basis wesentlich verlässlicher schätzen kann als ein neu zusammengestelltes Team, das noch über keinerlei Erfahrungswerte verfügt.

Auf den Tag ein Jahr ist es heute her, dass ich erstmals über Extreme Programming geschrieben habe. Seither habe ich mich ausgiebig auch mit anderen agilen Methoden beschäftigt – allen voran mit Scrum, aber auch mit weniger bekannten beziehungsweise verbreiteten Methoden wie Kanban oder Feature Driven Development (FDD).

Interessant ist, dass all diese Methoden eine gemeinsame Forderung implizieren, ohne diese explizit zu formulieren. Diese implizite Forderung besagt, dass die Entwicklung von Software featurebezogen durchgeführt wird. Am ehesten findet man diese Forderung – dem Namen entsprechend wenig verwunderlich – noch in FDD.

Was besagt die Forderung nach featurebezogener Entwicklung? Ich persönlich würde sie wie folgt formulieren:

Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features.

Anders formuliert: Wird ein laufendes Entwicklungsprojekt vorzeitig abgebrochen, kann der Kunde eine Software, bei der 25% der ursprünglich geplanten Features jeweils zu 100% implementiert wurden, zumindest partiell nutzen – eine Software, bei der 100% der ursprünglich geplanten Features jeweils zu 25% implementiert wurden, jedoch gar nicht.

Daraus folgt, dass es in der Regel sinnvoller ist, die Entwicklung an Hand logischer statt physischer Features auszurichten. Zudem bedeutet dies aber auch, dass ein Entwickler zu einem Zeitpunkt nach Möglichkeit nur an einem einzigen Feature arbeiten sollte – und nicht an verschiedenen gleichzeitig.

Auf diese Art kann ein Entwickler effizient dazu beitragen, dem Kunden beständig neue Features zur Verfügung zu stellen zu können, die für jenen einen eigenen Geschäftswert darstellen und den Wert der in der Entwicklung befindlichen Software stetig steigern.

Die Gefahr, dass der Kunde das Projekt auf Grund von fehlenden Resultaten vorzeitig abbricht, sinkt gleichzeitig – es wird also nicht nur der Gewinn für den Kunden erhöht, sondern zugleich auch das eigene Risiko vermindert.

Die verschiedenen agilen Methoden implizieren dieses Vorgehen, zumindest teilweise, formulieren es jedoch nicht explizit:

• Scrum: Scrum fordert, dass das Team am Ende eines jeden Sprints die zuvor für diesen Sprint ausgewählten Backlog Items erledigt hat, wobei jedes dieser Backlog Items als User Story formuliert ist und einen Kundennutzen darstellt – abgesehen von der fehlenden Forderung, dass ein Entwickler zu jedem Zeitpunkt ausschließlich an einer Aufgabe arbeiten sollte, unterstützt Scrum featurebezogene Entwicklung vollständig.
• XP: Extreme Programming fordert, dass die entwickelte Software häufig veröffentlicht wird, jeglicher Code durch Unittests abgedeckt wird, für jeden gefundenen Fehler neue Unittests geschrieben werden und Code sämtliche Unittests bestehen muss, bevor er veröffentlich werden darf. In Kombination folgt daraus, dass kein fehlerbehafteter Code ausgeliefert wird – da zudem gefordert wird, dass jede Iteration den Kundennutzen verbessert, fehlt in XP letztlich nur die gleiche Forderung wie in Scrum.
• Kanban: Kanban ist das Missing Piece zu Scrum und XP – Kanban sagt zwar nichts darüber aus, wie die einzelnen Tasks aufgeteilt werden, beschränkt aber explizit die Last des einzelnen Entwicklers. Dabei wird in Kanban zwar nicht gefordert, dass zu einem Zeitpunkt nur ein Task bearbeitet werden darf, der Ansatz hierfür ist jedoch enthalten. Nicht zuletzt deshalb werden Scrum und Kanban in der Praxis häufig zu Scrumban kombiniert.
• FDD: Feature-Driven Development schließlich fordert die Ausrichtung auf logische Features explizit, wobei der für die Implementierung eines einzelnen Features benötigte Zeitraum nicht länger als zwei Wochen betragen darf. Auch hier gelten also die gleichen Einschränkungen wie bei Scrum und XP.

Fasst man nun die genannten Aspekte in eine Regel zusammen, würde ich diese als Featurebezogene Entwicklung (Feature Related Development) bezeichnen und wie folgt formulieren:

Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features. Daher arbeitet jeder Entwickler stets an nur einem einzigen Feature zur gleichen Zeit, wobei dieses Feature in sich logisch abgeschlossen ist und einen eigenen Kundennutzen darstellt.

Zu guter letzt verbleibt die Frage, wann ein Feature als abgeschlossen gilt – hier zahlt sich eine gute Definition of Done (DoD) aus, die den Prozess der Entscheidung, ob ein Feature abgeschlossen ist oder nicht, transparent und für alle Beteiligten jederzeit nachvollziehbar gestaltet.

In ihrer vollständigen Fassung besagt die Regel Featurebezogene Entwicklung (Feature Related Development) also:

Der Kundennutzen weniger, aber voll funktionsfähiger Features wiegt höher als der vieler, aber kaum funktionsfähiger Features. Daher arbeitet jeder Entwickler stets an nur einem einzigen Feature zur gleichen Zeit, wobei dieses Feature in sich logisch abgeschlossen ist und einen eigenen Kundennutzen darstellt. Ein Feature gilt dann als fertiggestellt, wenn es die Definition of Done erfüllt.

Wird diese Regel beachtet, wird der Nutzen für den Kunden maximiert und das eigene Risiko minimiert – zudem gelten natürlich alle Vorteile agiler Entwicklung wie zeitnahes Feedback weiterhin.

Am 8. Juli 2010 fand in der Universität Augsburg der erste Agile Day statt, zu dem ich als Referent eingeladen war.

Nach einer allgemeinen Einführung wurde zunächst Scrum vorgestellt, wobei der Praxis ein sehr großer Stellenwert eingeräumt wurde: Die ungefähr 20 Teilnehmer erhielten auf diese Art die Gelegenheit, diverse Schritte selbst durchzuführen.

Mir persönlich fällt bei Scrum immer wieder auf, dass die Schere zwischen Theorie und Praxis extrem auseinanderklafft: Einerseits hat man Scrum durchaus in fünf Minuten auf einer Serviette erklärt. Andererseits stößt man während der praktischen Umsetzung auf dermaßen viele Probleme, dass man gut beraten ist, jemanden mit Scrum-Erfahrung in verfügbarer Nähe zu haben.

Im Anschluss an diese sehr dynamische und interaktive – und auch sehr gut gemachte – Einführung in Scrum habe ich in meiner Session einen kurzen Überblick zu Unittests im Allgemeinen und Test-Driven Development (TDD) im Speziellen gegeben.

Auch ich habe neben der Theorie großen Wert auf die Praxis gelegt, weshalb ich den Teilnehmern in einer Art Dojo die Aufgabe gestellt habe, die Kata FizzBuzz zu lösen – auch wenn wir dies in der gegebenen Zeit nicht geschafft haben, war der Lerneffekt im Hinblick auf TDD meines Erachtens sehr groß.

Zum Abschluss des Agile Days wurde eine sogenannte Extreme Hour angeboten, in der eine vorgegebene Aufgabe mit den Praktiken von Extreme Programming (XP) erledigt werden sollte – inklusive kurzer Iterationen und ähnlichem.

Durch das große Interesse, die vielen Fragen und die ungewöhnlich hohe Bereitschaft der Teilnehmer, aktiv mitzumachen, war nicht nur die Extreme Hour, sondern auch der gesamte Agile Day ein großer Erfolg, der – nicht nur mir – sehr viel Spaß gemacht hat.

Der nächste Agile Day wird am 29. Oktober 2010 stattfinden.

Scrum als agile Methode verlangt ein dediziertes Dokument, in dem definiert wird, wann Code als “fertig” anzusehen ist. Dieses Dokument wird als Definition of Done bezeichnet und dient allen Beteiligten als gemeinsame Basis zur Abnahme von Code.

Mir gefällt diese Idee.

Allerdings fordert Scrum nur, dass es ein solches Dokument geben muss – es wird jedoch keinerlei Aussage dazu getroffen, wie eine entsprechende Definition aussehen könnte.

Hieran zeigt sich wieder das typische Problem von Scrum: Es bietet nur einen Rahmen, aber keinen Inhalt. Das macht Scrum sehr portabel und vielfältig einsetzbar, das macht Scrum aber auch sehr unspezifisch.

Aus diesem Grund habe ich mir Gedanken gemacht, welche Eigenschaften Code für mich aufweisen muss, um als “fertig” gelten zu können. Entstanden ist meine ganz persönliche Definition of Done.

Code is considered to be “done”, when:

1. It does satisfy all its functional and non-functional requirements.
2. It does not contain any known errors.
3. It has been commented and documented.

4. It has been either pair-programmed or reviewed.
5. It has been developed test-driven using 4-Step TDD.
6. It does not need to be refactored or rearranged.

7. It has been written according to well-known best practices.
8. It does conform to accepted coding standards.
9. It does pass static code analysis without any errors or warnings.

10. It has been integrated and does not break the integration build.
11. It has been checked in into source control.

Wenn Code all diese Punkte erfüllt, kann man den dazugehörigen Task in meinen Augen guten Gewissens als abgeschlossen betrachten.

Den Teilnehmern des dotnetpro.powerdays C# für Profis wurde im Anschluss an die eigentliche Veranstaltung die Teilnahme an einem .NET Coding Dojo angeboten, das von Ilker Cetinkaya durchgeführt wurde.

Im Rahmen dieses Dojos wurde die Frage diskutiert, wie der übliche TDD-Cycle Red – Green – Refactor auszulegen sei. Stein des Anstoßes war, dass einige Teilnehmer den Schritt Refactor als optional angesehen haben und ihn daher im konkreten Fall außen vor lassen wollten – was bei anderen Teilnehmern wiederum für Unmut sorgte.

Ich selbst habe die Meinung vertreten, dass der Schritt Refactoring keineswegs optional sei, denn stellt man diesen in Frage, öffnet man seinem gänzlichen Ausschluss Tür und Tor – dem verführerischen Weg zur Brownfield-Anwendung wird damit Vortrieb geleistet.

Einige Teilnehmer des Dojos – allen voran Stefan Lieser – haben argumentiert, dass ein Refactoring am Ende des TDD-Cycles keinen Sinn machen würde – sondern dass es vielmehr an den Beginn dieses Zyklusses verschoben werden sollte, schließlich sei Refactoring auf ein Ziel und somit auf einen Plan angewiesen – sonst wisse man nicht, in welche Richtung das Refactoring zu treiben sei.

Stefan hat dies in seinen Blogeinträgen Refaktorisieren im TDD Prozess und TDD 2.0 dargelegt – allerdings bin ich davon nicht überzeugt. Ein Refactoring zu Beginn des TDD-Cycles macht keinen Sinn: Erstens aus dem bereits genannten Grund, der Verschmutzung von Code Vortrieb zu leisten, zweitens weil ich direkt zu Beginn eines Projektes kein Refactoring betreiben kann.

Auch wenn es sich hierbei nur um eine einzige Ausnahme handelt, in der die von ihm vorgeschlagene Regel nicht greift – es ist eine Ausnahme, was ich persönlich nicht schön finde.

Für mein Empfinden gibt es zwei Arten von Refactorings: Einerseits kleine, kosmetische Korrekturen, andererseits grundlegende, Architektur-betreffende Änderungen. Stefan beschreibt diese Aufteilung ebenfalls – zieht für mein Empfinden aber die falschen Schlüsse.

Natürlich ist es – wenn überhaupt möglich – schwierig, grundlegende, Architektur-betreffende Änderungen durchzuführen, wenn man noch nicht weiß, in welche Richtung die Software weiterentwickelt werden soll.

Diese Art von Änderungen ist jedoch gar nicht das, was in der Regel von Refactoring betroffen ist: Ob ich Code in eine private Methode auslagere, um DRY umzusetzen, ist unabhängig von der Architektur. Ebenso, ob ich ein Literal in eine Konstante auslagere oder nicht.

Diese Art von Refactorings macht den bedeutend größeren Anteil aus – es wäre auch tragisch, wenn Entwickler und Architekten nach jedem Test beständig damit beschäftigt wären, die Architektur grundlegend anzupassen.

Es liegt auf der Hand, dass diese Art von kosmetischen Korrekturen direkt nach dem Schritt Green ausgeführt werden sollten – ganz so, wie TDD es in seiner Urform vorschreibt: Red – Green – Refactor.

Die Architektur-bezogenen Änderungen werden in diesem Schema aus drei Schritten also gar nicht berücksichtigt: Die logische Konsequenz daraus ist die Einführung eines vierten Schrittes, der getrennt von Refactor stattfinden kann.

Da dieser vierte Schritt wesentliche Änderungen behandelt, die das architektonische Grundgerüst des Codes betreffen, nenne ich diesen Schritt Rearrange – schließlich werden die einzelnen Komponenten und deren Verdrahtung zueinander in diesem Schritt neu arrangiert und komponiert.

Dieser vierte Schritt ist – naturgegeben – erst dann sinnvoll, wenn bekannt ist, in welche Richtung die Entwicklung laufen soll. Ihn aber direkt in den TDD-Cycle aufzunehmen, halte ich für unglücklich – schließlich wird er nicht nach jedem Durchlauf angewendet. Daher plädiere ich für zwei Zyklen, die einander enthalten:

TDD = Red – Green – Refactor

als klassischer TDD-Cycle für kosmetische Korrekturen und

TDD erweitert = TDD – TDD – … – TDD – Rearrange

als erweiterter TDD-Cycle für architektur-bezogene Anpassungen, Änderungen und Erweiterungen.

Den Schritt Rearrange habe ich bewusst am Ende des erweiterten TDD-Cycles untergebracht, denn vor der ersten Ausführung von TDD ergibt die Durchführung von Rearrange keinen Sinn – und da eine Software nie “fertig” ist und es daher stets einen weiteren TDD-Cycle geben wird, habe ich keinerlei Bedenken, Rearrange an die letzte Position zu schieben.

Der erweiterte TDD-Cycle hat in diesem Sinne nämlich keinen Anfang und kein Ende mehr, sondern stellt eher einen Fluss dar – welche Vorbedingungen für den jeweils nächsten Schritt erfüllt sein müssen, darüber wird keine explizite Aussage gemacht. Implizit jedoch erfordert Rearrange Planung, womit auch Stefans Wunsch nach mehr Planung berücksichtigt wäre.

Nachdem ich mich in der jüngeren Vergangenheit eher mit Scrum denn mit Extreme Programming (XP) beschäftigt habe, war nun wieder ein Buch zu XP an der Reihe – sogar eines, das sich dediziert mit Extreme Programming in Verbindung mit der .NET-Plattform beschäftigt: eXtreme .NET von Dr. Neil Roodyn.

Nach einer kurzen Einführung in die Thematik von XP beschäftigt sich das Buch in jedem Kapitel mit einer ausgewählten agilen Praktik und erläutert diese in der Theorie. Außerdem werden typische Real-World-Szenarien exemplarisch in einem fiktiven Team durchgespielt – was teilweise zwar ein wenig gestellt wirkt, dennoch aber einige gute Punkte thematisiert.

Besonders interessant wird das Buch dadurch, dass in jedem Kapitel zahlreiche Aufgaben zu der jeweiligen Praktik gestellt werden, die mit .NET und verwandten Technologien wie beispielsweise NUnit zu lösen sind.

Da eXtreme .NET bereits aus dem Jahr 2005 stammt, basieren die Beispiele zwar noch auf .NET 1.1, weshalb die Syntax teilweise etwas umständlich wirkt – dem Lerneffekt hinsichtlich agiler Methoden und XP tut dies jedoch keinen Abbruch.

Auf diese Art werden die agilen Praktiken Programmieren in Paaren, testgetriebene Entwicklung (TDD), Refaktorisieren, Spiking und kontinuierliche Integration vorgestellt und gelehrt, wobei auf testgetriebene Entwicklung besonders großen Wert gelegt wird – als einzigem Thema werden TDD zwei Kapitel zugestanden.

Abgerundet wird dieses Themenspektrum durch ein Kapitel, das sich mit der Frage beschäftigt, wie große Probleme in kleinere zerteilt werden können, und durch das abschließende Kapitel, das alle Praktiken wie auch deren Zusammenspiel in einem gemeinsamen größeren Rahmen präsentiert.

eXtreme .NET birgt für Entwickler, die sich bereits mit XP beschäftigt haben oder ein anderes Buch zu diesem Thema wie beispielsweise eXtreme Programming von Henning Wolf, Stefan Roock und Martin Lippert gelesen haben, wenig neues – für Entwickler, die auf Basis von .NET arbeiten und einen praxisnahen ersten Einstieg wagen wollen, bietet es aber eine gute Grundlage.

Da allerdings nicht alle Praktiken aus XP angesprochen werden – der Einsatz von Programmierrichtlinien, gemeinsame Verantwortlichkeit oder nachhaltiges Tempo fehlen beispielsweise – ersetzt das Buch auch nicht die Lektüre eines weitergehenden Buches.

Kurzum: Kurzweilige Lektüre für XP-Neulinge, bei der man sich aber eine neue Auflage wünschen würde, die zum einen auf einer moderneren Version von .NET basiert, und die zum anderen alle Praktiken aus XP abdeckt.

Nachdem ich vor einigen Monaten das ausgesprochen lesenswerte Buch Geschichten vom Scrum von Holger Koschek gelesen habe, habe ich mir in den vergangenen Tagen Agile Softwareentwicklung mit verteilten Teams von Jutta Eckstein als Lektüre vorgenommen.

Der Beschreibung nach richtet sich das Buch an

Entwickler und Manager, die auch in einer verteilten Umgebung die Vorteile agiler Entwicklung nutzen

möchten. Als Basis dient dem Buch dabei das Agile Manifest, auf das im Verlauf immer wieder Bezug genommen wird.

Agile Softwareentwicklung mit verteilten Teams führt als Grundlage zudem den Begriff des Featureteams ein, wobei ein solches derart definiert wird, dass ein Team nicht an Hand technischer Kompetenzen, sondern an Hand gemeinsam bearbeiteter Features domänenübergreifend gebildet wird.

Ausführlich beschreibt Jutta Eckstein im weiteren Verlauf dann, wie die Kommunikation von verteilten und verstreuten Teams gewährleistet werden kann, worauf dabei geachtet werden muss, und welche gemeinsame Infrastruktur erforderlich ist.

Zudem werden einige Praktiken aus dem Extreme Programming angesprochen, die für den erfolgreichen Einsatz im Rahmen von verteilter Entwicklung adaptiert werden müssen – wie beispielsweise Pair Programming und Collective Code Ownership.

Vieles von dem, was in dem Buch beschrieben wird, ist nachvollziehbar und entspricht letztlich naheliegenden und logischen Ideen, angewandt auf agile Methoden.

Einige Themen werden jedoch meines Erachtens überbewertet – so wird beispielsweise wiederholt darauf hingewiesen, wie wichtig es sei, über verschiedene Kontinente verteilte Teams regelmäßig vollständig zueinander zu bringen, um das Gemeinschaftsgefühl zu stärken.

Die Erfüllung dieses Vorschlags mag wünschenswert sein – in der Praxis ist dies jedoch absolut unrealistisch, da es schlicht und ergreifend zu teuer und zeitlich nicht möglich ist, alle paar Wochen komplette Teams zwischen verschiedenen Kontinenten hin- und herfliegen zu lassen.

Außerdem gibt es Themen, die das Buch höchstens anschneidet, im Großen und Ganzen aber ignoriert: So wird die Problematik von Teams, die sich in verschiedenen Zeitzonen befinden, zwar angesprochen und somit als existent anerkannt – wirkliche Lösungsvorschläge hierfür finden sich allerdings kaum bis gar nicht.

Alles in allem ist Agile Softwareentwicklung mit verteilten Teams damit vor allem zu lang – 240 Seiten sind schlichtweg zu viel für die wenigen nicht-naheliegenden Ideen, die vermittelt werden.

Außerdem fällt die schlechte Grammatik der Autorin sehr negativ auf – an zahlreichen Stellen fehlen Kommata, was den Lesefluss erheblich stört, da man auf diese Art etliche Sätze mehr als ein Mal lesen muss, um ihre eigentliche Bedeutung zu erfassen.

Kurzum: Die übrigen Bücher zu agilen Methoden aus dem dpunkt.verlag wie Extreme Programming oder Geschichten von Scrum sind bedeutend besser – auf weniger Seiten vermitteln sie mehr konkretes Wissen, sind fehlerfrei und nicht dermaßen trocken geschrieben und lesen sich insgesamt flüssiger.

Jeder, der sich mit der Konzeption und der Entwicklung von Software beschäftigt, kennt das Problem: Man ist so sehr in das Projekt oder den zu schreibenden Code vertieft, dass es nicht gelingt, die notwendige kritische Distanz zu bewahren, um Denkfehler frühzeitig aufdecken und Sackgassen vermeiden zu können.

Da Softwareentwicklung als Prozess selten nach außen kommuniziert wird, kommt Hilfe häufig spät oder gar zu spät – denn in der Regel wird erst dann um Hilfe gebeten, wenn das Kind schon in den Brunnen gefallen ist. Was fehlt, ist ein geeigneter, unabhängiger Sparringspartner, der eine zweite Sicht und einen anderen Standpunkt einbringen kann.

Deshalb biete ich am 25. Juni 2010 in München und am 28. Juni 2010 in Köln ebendies an: An beiden Tagen bin ich jeweils von 9 bis 17 Uhr in einem Café und setze mich mit Entwicklern, Architekten, Team- und Projektleitern zusammen, um deren Probleme zu besprechen und gemeinsam zu versuchen, nach bestem Wissen und Gewissen einen geeigneten Lösungsansatz zu finden – kostenlos, wobei ich gegen eine Einladung auf eine Cola nichts einzuwenden habe.

Thematisch wird es sich dabei um .NET, Codequalität und agile Methoden drehen: Ob es dabei um die Planung, die Architektur, die konkrete Entwicklung oder den Prozess geht, ob die Fragen eher genereller oder eher spezieller Natur sind, spielt keine Rolle – das entscheiden Sie, je nachdem, was Sie mitbringen!

Damit verschiedene Interessenten die Gelegenheit erhalten, sich mit mir zu besprechen, ist eine Sitzung auf 90 Minuten begrenzt – wobei sich in 90 Minuten häufig deutlich mehr besprechen lässt, als man zunächst vermuten würde: Wichtig ist nur, dass Sie das zu besprechende Thema in kompakter, aber vollständiger Form mitbringen, so dass mir genug Zeit bleibt, mich hineinzudenken.

Aus diesem Grund möchte ich auch darum bitten, dass sich Interessenten vorher bei mir per E-Mail anmelden – auch um auszuschließen, dass ich zu einem Thema nichts beitragen kann oder dass sich mehrere Interessenten zeitlich überschneiden, um die Diskretion zu wahren: Eine Sitzung ist also nicht öffentlich zugänglich für interessierte Zuhörer.

Wenn dieses Angebot Ihr Interesse geweckt hat, finden Sie abschließend noch die Termine und Lokationen im Überblick:

• München, 25. Juni 2010, 9 bis 17 Uhr, Forum Café
• Köln, 28. Juni 2010, 9 bis 17 Uhr, Café Feynsinn

Ich freue mich auf spannende Themen und interessante Diskussionen!

Foundations for Professionals – unter diesem Titel biete ich zukünftig Schulungen zu den Themen .NET, Codequalität und agile Methoden an. Das Konzept:

Fundiertes Wissen, akkurat und mit Liebe zum Detail aufbereitet, für alle Entwickler und Architekten, die Softwareentwicklung als ihre Berufung ansehen, der sie auf professionelle Art und mit Leidenschaft nachgehen.

Den Anfang macht vom 15. bis 17. September 2010 eine dreitägige Schulung zum Thema Extreme Programming (XP), in der so wohl theoretisch wie auch praktisch die Werte und Praktiken dieser agilen Methode vermittelt werden.

Veranstaltungsort ist das Vier-Sterne-Hotel Windenreuter Hof in Emmendingen, das in schönster Panoramalage mit Blick auf den Kaiserstuhl, den Breisgau und die Vogesen liegt und eine ruhige und konzentrierte Schulungsatmosphäre in modern ausgestatteten Tagungsräumen ermöglicht.

Die Agenda umfasst derzeit die folgenden Themen:

• Teambuilding und Setup
• XP aus 10.000 Meter Höhe
• Agile Anforderungen
• Planen, schätzen und messen
• Design und Code
• Entwickler vs Team
• Testen, testen, testen, …
• Review und Retrospektive
• XP im Rahmen von Scrum
• Die Scrum-Stunde
• … und wie weiter?

Die Schulung richtet sich an Entwickler, Architekten wie auch Team- und Projektleiter, unabhängig von der zur Entwicklung verwendeten technischen Plattform.

Um dem Ziel, fundiertes Wissen akkurat und mit Liebe zum Detail zu vermitteln, gerecht zu werden, bedarf es einer persönlichen Atmosphäre, in der jeder Teilnehmer intensiv und individuell geschult werden kann. Daher ist die Teilnehmerzahl auf 10 begrenzt.

Da die Schulung einschließlich Übernachtung und Verpflegung als all-inclusive angeboten wird, wird den einzelnen Teilnehmern die Gelegenheit geboten, auch abseits der Schulung ihre Gedanken auszutauschen und miteinander zu diskutieren – und sich bei Bedarf auch zurückziehen und entspannen zu können.

Für die ersten fünf angemeldeten Teilnehmer gilt der ermäßigte Early-Bird-Preis pro Person von 1.799 Euro zuzüglich Umsatzsteuer, für alle weiteren Teilnehmer gilt der reguläre Preis pro Person von 1.999 Euro zuzüglich Umsatzsteuer.

Eines der grundlegenden Prinzipien in der Softwareentwicklung ist das KISS-Prinzip: In der Formulierung Keep it simple, stupid ist im roten Grad von Clean Code Developer (CCD) enthalten, Extreme Programming propragiert Einfachheit als Regel und auch im Agilen Manifest ist Einfachheit als essenzielles Prinzip enthalten.

Softwareentwicklung soll sich also an Einfachheit orientieren – doch was bedeutet das? Was gilt als einfach und was nicht?

Eine eindeutige und allgemein akzeptierte Definition erscheint schwierig, entsprechend verschieden fallen die jeweiligen Erklärung auch aus. Während es auf der CCD-Webseite zunächst

Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert.

heißt, was sich mit dem im blauen Grad enthaltenen YAGNI-Prinzip überschneidet, wird dann im weiteren Text jedoch erläutert, es sei

für die Evolvierbarkeit des Codes zwingende Voraussetzung, dass der Code verständlich sei.

Zwar ist verständlich ein ebenso subjektiver Begriff wie einfach, deutet aber schon eher in die gewünschte Richtung. Verständlichkeit war auch das Ziel, das ich in meinem Blogeintrag Anmut und Eleganz verfolgt habe – insofern ziehen CCD und ich hier an einem Strang.

Schön ist, dass CCD dabei auch auf Code zu sprechen kommt:

Wenn ein IEnumerable reicht, sollte kein ICollection oder sogar IList verwendet werden.

Auch das entspricht meiner Vorstellung und deckt sich mit dem, was ich als eine gelungene innere Form von Code bezeichne.

XP nennt ebenfalls Verständlichkeit, allerdings nur als einen von vier Aspekten, die gemeinsam Einfachheit definieren. Nach XP zählen hierzu noch die drei Aspekte Testbarkeit, Navigierbarkeit und Erklärbarkeit:

• Testbarkeit: Nur Code, der sich auf das Notwendige beschränkt, ist zugleich auch einfach zu testen – ansonsten müssen nämlich Spezial- und Sonderfälle wie auch die Auswirkungen von Seiteneffekten im Test berücksichtigt werden. Auch wenn weder CCD noch ich in Anmut und Eleganz die Testbarkeit explizit im Zusammenhang mit Einfachheit ansprechen – auch hier sind wir letztlich einer Meinung.
• Navigierbarkeit: Zur Einfachheit von Code zählt neben einer guten Verständlichkeit und einer guten Testbarkeit auch eine gute Navigierbarkeit: Das heißt, in einfachem Code findet man sich zurecht, und es fällt leicht, zwischen den beteiligten Klassen und Komponenten hin und her zu navigieren.
• Erklärbarkeit: Während die Testbarkeit in gewissem Sinne messbar ist, sind Einfachheit und Navigierbarkeit in höchstem Maße subjektiv: Negativ fällt dies vor allem dann auf, wenn ein Team eingespielt ist und bereits lange Zeit an einer Software arbeitet – in diesem Fall wird sich jeder Entwickler des Teams im Code zurechtfinden und ihn verstehen. Aus diesem Grund muss Code für Einfachheit zusätzlich auch einem Uneingeweihten einfach zu erklären sein.

Das Agile Manifest schließlich definiert Einfachheit als

the art of maximizing the amount of work not done.

Hier wird also letztlich nur der Effekt der Reduktion, des minimalen Codes betont – was jedoch für mein Empfinden nicht genügt. Sicherlich kann man argumentieren, dass in dieser Aussage implizit auch die Arbeit angesprochen wird, die zum späteren Verstehen von Code investiert werden muss – viele Entwickler werden diese Interpretation jedoch zunächst überlesen.

All zu oft wird Einfachheit ansonsten nämlich mit dem YAGNI-Prinzip gleichgesetzt – dabei handelt es sich jedoch um zwei verschiedene Konzepte: Das YAGNI-Prinzip empfiehlt, keine Funktionalität im guten Glauben auf die zukünftige Erforderlichkeit umzusetzen, ohne eine konkrete Anforderung dafür zu haben. Das ist dann auch genau das, was im Rahmen von CCD kritisiert wird:

Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert.

Einfachheit im Sinne des KISS-Prinzips läuft jedoch Gefahr, dass während der Entwicklung lediglich simple und naheliegende Sprachkonstrukte verwendet werden – obwohl ein fortgeschritteneres Konstrukt eventuell deutlich besser geeignet wäre. Ein typisches Beispiel hierfür ist das Schlüsselwort yield, das viel zu selten Verwendung findet.

Außerdem wird dabei häufig auf Design für zukünftige Erweiterbarkeit verzichtet, obwohl dies mit nur unwesentlich mehr Aufwand möglich wäre – so wird beispielsweise eher auf verschachtelte und zahlreiche if-Anweisungen statt auf besserpassende objektorientierte Konstrukte gesetzt.

Kurzum: Einfachheit bedeutet nicht zwingend, das Naheliegendste und mit möglichst wenig Aufwand umsetzbare zu implementieren, sondern erstens, keine Funktionalität zu entwickeln, für die keine Anforderung besteht, zweitens, der Verständlichkeit des Codes höheren Stellenwert einzuräumen als der Entwicklung, und drittens, die zukünftige Erweiterbarkeit nicht außer Acht zu lassen.

Schlussendlich kann man daher festhalten, dass der Begriff einfach nicht besonders glücklich gewählt ist: Häufig wird darunter nämlich die minimalistische Reduktion auf einfache Sprachkonstrukte und wenige Codezeilen verstanden – die Verständlichkeit und zukünftige Erweiterbarkeit bleiben hierbei außen vor.

Daher wäre es meines Erachtens sinnvoll, an Stelle von Einfachheit – oder zumindest zusätzlich – einen anderen, treffenderen Begriff zu propagieren, der Verständlichkeit und zukünftige Erweiterbarkeit einschließt. Am ehesten treffen dies meiner Meinung nach die Begriffe Anmut und Eleganz.