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!

Professional Engineering

Ich möchte das Beispiel von Golo aufgreifen, in dem er die gute Zusammenarbeit zwischen ihm und Peter schildert:

“… Peter Bucher und ich sind ein solches Team. David Tielke und ich sind ein solches Team. Beide habe ich in meinem Leben noch nicht all zu oft getroffen – jeden von beiden höchstens fünf Mal. Und dennoch harmoniert die Zusammenarbeit in einem Ausmaß, das für Außenstehende nicht nachvollziehbar ist.

Auch wenn uns hunderte von Kilometern trennen, führen wir regelmäßig Programmieren in Paaren durch – per Skype und Teamviewer. Und die Zusammenarbeit funktioniert einwandfrei. Keiner von uns käme auf die Idee, zu sagen, dass wir effektiver oder effizienter sein könnten, wenn wir gemeinsam vor einem PC arbeiten würden.

Vermutlich wären wir dies noch nicht einmal, weil dann nicht jeder seine vertraute Arbeitsumgebung hätte, in der er sich rundum wohlfühlt…. “

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.

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.

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. Aber sie behaupten, dass sich spätestens mittelfristig die Produktivität & Effizienz eines Teams steigert, wenn sie an einem Fleck miteinander zusammenarbeiten. Diese Behauptung ist kein Wunschtraum, sondern messbar & belegbar.

Doch es gibt noch einen weiteren, ganz entscheidenden Aspekt der Forderung nach Teamnähe in der Agilität. Golo überspringt in seiner Betrachtung meines Erachtens die Interdisziplinarität agiler Teams. Das ist für mich besonders verwunderlich, zumal er in seinem gelungenen Artikel über die Feature-Orientierung in agilen Methoden sich selbst genug Indizien gibt, die interdisziplinäre Aufstellung von Teams zu fordern & zu fördern.

Agile Teams sind Interdisziplinär

Was heisst das? Das heisst, erst einmal, das Entwickler alleine kein Team sind. Zumindest mal in der agilen Software-Entwicklung nicht. Ein agiles Team ist ein Team, welches eigenständig dazu in der Lage ist, das geforderte Produkt bzw. deren Features ausliefern zu können. Manchmal – besser gesagt: eher selten – reichen dazu Entwickler. Doch meist braucht es mehr, viel mehr. Es braucht Produktmanager, Systemingenieure, Usability-Experten, Designer, Tester und manchmal sogar noch mehr, um ein Feature eines Produktes wirklich fertigstellen zu können.

Ein agiles Team ist ein Team, welches all diese Rollen und Aufgabenbereiche berücksichtigt und mit den Teammitgliedern umsetzen kann. Dass heisst nicht unbedingt, dass Designer ein “fester Bestandteil” des Teams sein muss, wenn er nur zwei Websites designen soll, das Produkt aber weitaus mehr darstellt (z.B. im Backend oder durch Dienste). Doch wichtig ist hier die Erkenntnis, dass ein agiles Team interdisziplinär ist; idealerweise sogar mit dem Kunden (oder Kundenvertreter) an seiner Seite.

Vor diesem Hintergrund macht die Forderung nach räumlicher Nähe von Teammitgliedern in einem Team noch viel mehr Sinn. Leider gibt es noch viel zu oft die Situation, dass Entwickler von der Marketing-Abteilung die Anforderungen über ein Feature (<Ironie>als “Story” natürlich, haha</Ironie>) in einem “agilen” Ticketsystem vorgesetzt bekommen. Die Entwickler “sprinten” dann und liefern das Ergebnis an die Testabteilung, um danach ein Paket der Infraktruktur bzw. Installation-Engineers “über den Zaun” zu werfen. In meinen Augen haben es solche Teams echt schwer, denn sie sind nicht agil, sondern fragil.

Keine Scheu vor Transparenz

Die Emergenz, die durch interdisziplinare Teams entsteht, ist nämlich erst dann wirklich mess- und spürbar, wenn die Kommunikationsmittel als auch die Kommunikationsbarrieren untereinander so gering wie möglich ist. 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.

Abschließend kann ich nur sagen, dass ich nicht nur ein Befürworter von räumlicher Nähe bin, sondern als Agilist versuche, so nah wie möglich an meinen Teammitgliedern und dem Kunden dran zu sein. Manchmal macht man es sich meiner Meinung nach zu einfach, wenn man Distanzen unter gemeinsam arbeitenden Kollegen als gegeben hinnimmt.

Be Agile!

Ich möchte in diesem Zusammenhang gerne nochmal an zwei Punkte des agilen Manifests erinnern: People over Process (and Tools), sowie Collaboration over Contracting. Für mich steht fest: wer von sich behaupten möchte, agile Software-Entwicklung zu betreiben, der wird früher oder später die Vorteile von räumlicher Nähe von Teams erkennen und versuchen, diese Nähe von Teams so gut wie möglich herzustellen. Alles andere sind in meinen Augen nur Lippenbekenntnisse und Halbwahrheiten über Agilität.

So oder ähnlich erging es auch dem ein oder anderen beim jüngsten Estimation Meeting, welches wir in einem Projekt durchgeführt haben. Für einige war es das erste Schätzmeeting, bei dem nicht einfach so Manntage herausposaunt wurden, sondern das von agilen Methoden wie XP oder Scrum bekannte schätzen in Relationsgrößen (z.B. Story Points) umgesetzt wurde.

Für den Anfänger ist der Zeitbezug im Schätzungsverfahren meist so manifestiert, dass er sich schwer tut, überhaupt anders denken und schätzen zu können. Die erste, wichtige Hürde hin zum relativen schätzen ist eine klare Vorstellung davon, was nun der Unterschied zwischen größenorientiertem Umfang und zeitorientiertem Aufwand ist. Um den Teilnehmern und Neulingen im agilen Schätzzirkus den Einstieg zu erleichtern, habe ich mich einer kleinen Metapher bedient:

Da ist er, der „Ratatouille Estimation Scale“. Klassisch, einfach. Fibonacci und am Ende Hightower-Zahlen. Das war’s. Doch es ist mehr dahinter als nur die blanken Zahlen. Es ist die Metapher, die Schätzen besonders geholfen hat.

Denn der Film „Ratatouille“ und die Liebe zu Gaumenschmaus ist ein schönes Beispiel, an dem sich größenorientiertes Schätzen erklären lässt. Bei der Menge der Köstlichkeiten geht es nämlich nicht darum, wie „schnell“ man diese Leckereien herunterwürgen kann. Es geht auch nicht darum, einfach wahllos seinen Hunger zu befriedigen. Nein, es geht darum, den Umfang und Wert der Köstlichkeiten zu erfassen ;-)

Nur ein Häppchen? Wohl eher eine 1 oder 2. Ein echtes Stück Käse? Eher die 5. Viel Käse und Trauben dazu? Lecker. An die 20. Kistenweise Käse, Gemüse, Obst und Wein? Wow. 50 oder mehr!

Die Besonderheit dabei: Es wird schnell deutlich, dass es nicht um die Zeit geht. Schließlich kann man ein Stück Käse sicherlich in ein paar Stunden „abfrühstücken“ – oder aber scheibchenweise über eine Woche lang genießen. Mit steigendem Umfang wird es allerdings schwerer. Denn jetzt kommen andere Lebensmittel hinzu, die vielleicht andere Haltbarkeitsmerkmale aufweisen oder aber besondere Behandlung bzw. Lagerung benötigen. Das ist ein relativ schönes Bild für den Begriff der “Komplexität im Umfang“.

Den Neulingen im Estimation Meeting hat diese Metapher sehr geholfen, denn schon nach den ersten paar Schätzrunden war die “Zeit” in der Besprechung der Features „wie verschwunden“ :-)

Und genau so ist es auch. Zumindest für mich. Ich habe lange Zeit Tests und Implementierung in separaten Projekten entwickelt. Bis ich bemerkt habe, dass es mir nicht hilft, sondern mich eher bei meiner Entwicklung stört. Seitdem halte ich Tests und Implementierung immer ganz nah beieinander, sozusagen „Seite an Seite“. Ich möchte in diesem Post meine Beweggründe & Konsequenzen für Side-by-Side-Specs (oder Near-Specs, wie ich es gerne nenne) schildern, und somit meine Antwort auf Stefan’s Frage geben.

Nun zunächst einmal beschränke ich mit bei den Near-Specs auf Unit Tests. Ganz klassisch im Sinne des TDD. Integrationstests sind bei mir nach wie vor Far-Specs, also separate Projekte. Doch es soll ja um die Unit Tests gehen, besser gesagt um Tests, die aus dem Test-First-Ansatz heraus entstehen. Das können Tests bei TDD oder aber auch Specs bei BDD sein. Ergo: Tests, mit denen ich meinen Code designe & entwickle, halte ich sehr nah am Code.

Verhalten greifbar formen

Doch wieso sind bei mir die Tests nun an der Implementierung dran? Es gibt einen ganz einfachen und für mich auch unschlagbar effektiven Grund: Die Tests sind greifbar. Sie sind dort, wo ich sie brauche, nämlich an dem Verhalten, für das ich sie zur Spezifikation gebraucht habe. Seit dem ich die Tests an der Implementierung habe, „forme“ ich auch mehr und öfter. Soll heissen: Ich führe öfter und effizienter Refactorings durch. Nicht nur vom SUT, sondern natürlich auch von den Tests selbst.

Überhaupt ist es mit den Tests im Implementierungsprojekt ein ganz anderes, viel effizienteres arbeiten. Wenn ich nach einiger Zeit wieder einmal in einem Projekt etwas zu tun habe, schaue ich mir die Tests an. Das Schöne bei den Near-Specs ist jetzt, dass ich sehr schnell zwischen Spezifikations- und Implementierungssicht wechsle und deutlich zügiger navigieren kann. Das fällt mir besonders bei Tests mit mehreren Abhängigkeiten / Mocks auf. Ich komme mit dieser Art von „Code lesen“ viel besser zurecht als vorher mit dem hin- und herspringen zwischen mehreren Projekten.

Zugegeben, anfangs tat ich mir noch ein wenig schwer, denn schließlich ist die Anzahl der Testklassen – genereller: die Menge an Testcode – für ein SUT meist deutlich mehr. Neben der Umgewöhnung des „nicht mehr über Assembly-Boundaries“ hinweg arbeitens hatte ich das Gefühl, dass mich der Testcode „stört“ oder mir „im Weg steht“. Doch dieses Gefühl war schnell wieder weg, als ich das Prinzip auf größere Projekte angewendet habe und immer wieder die Tests für die Spezifikation und das Codeverständnis gebraucht habe. Spätestens dann war bei mir die Erkenntnis da: Side-By-Side-Specifications Rule!

Doch mit dieser „Colocation“ der Tests an die Implementierung tauchen neue Fragen auf. Eine ganz besonders oft gestellte Frage ist die der Auslieferung der Tests in Release-Assemblies. Es ist schließlich erstrebenswert, nur das in ein Release einfliessen zu lassen, was auch wirklich vom Benutzer gebraucht wird: die Funktionalität. So stand ich auch vor dieser Aufgabe, welches sich aber sehr schnell und vor allem einfach bewältigen ließ.

Reduce to the Max

Die Idee ist denkbar einfach: Wenn ich Tests und Implementierung zur Entwicklungszeit nicht trenne, dann trenne ich sie eben später, undzwar zur Auslieferungszeit. In einfachen Worten: der Build muss diese Aufgabe erledigen. Da ich sowieso meinen Code über Build-Skripte bauen lasse, lag es sehr nah, diese Skripte einfach anzupassen. Für meine eigenen Projekte habe ich oft ein kleines Powershell-Skript. Bei größeren Projekten oder CI-Umgebungen ist der Aufruf eines eigenen Post-Clean-Events vor dem Build ein guter Extension-Point.

Als ich die Menge und den Inhalt der Kommentare bei Stefan’s Post gesehen habe, dachte ich mir nur: warum schreiben so viele darüber und finden es „schwierig“ oder „unsauber“, ohne es offensichtlich einmal probiert zu haben? Ich habe es probiert und ich fand es überhaupt nicht schwierig – ganz im Gegenteil. Jetzt ist das für mich eine viel angenehmere, effizientere und vor allem intuitivere Arbeitsweise. Das Build-Skript zum filtern der Testartefakte ist denkbar einfach, bei mir sind das meistens nur so 10 bis 20 Zeilen. Schließlich ist es ja auch „nur“ ein Release-Build. Ich rufe es nicht die ganze Zeit auf wie ein CI-Build, und CD mache bzw. brauche ich derzeit auch nicht.

„Soooo lange, wie ich brauche, diese Kommentare überhaupt zu lesen, brauche ich nicht einmal, wenn ich sogar das Build-Skript per TDD erstelle“ war mein Gedanke, als ich mit dem Lesen der Kommentare fertig war. Und da ich ein Freund von empirischen Erkenntnissen bin, dachte ich mir: „Auf geht’s, das machst Du jetzt!“. Gesagt getan. Das Ergebnis kann man sich auf github ansehen. Erkenntnis: Die Entwicklung des Build-Skripts (ohne TDD Framework und mit meinen „bescheidenen“ Powershell-Kenntnissen) hat etwas mehr als eine Stunde gedauert. So lange habe ich in etwa auch zum Lesen der Kommentare gebraucht ;-)

Separation of Concerns

Doch zurück zum Thema. Beim Lesen der Kommentare ist mir auch aufgefallen, dass man öfter das Argument der „Separation of Concerns“ (SoC) gegen die Zusammenführung von Tests und Implementierung anbringt. Es sei im Sinne der SoC, Tests von der Implementierung zu trennen. Auch gute Freunde von mir, wie z.B. Tehlike – für den ich im Übrigen diesen Post auch auf Englisch verfasst habe – entgegneten mir das gleiche Argument. Dazu mein Statement:

Tehlike, yanılıyorsun! ;-)
(Auf deutsch: Tehlike, Du irrst Dich!)

Ja, ich denke diejenigen irren sich, die SoC als Argument für eine Trennung von Tests & Implementierung anbringen. Sie irren sich meiner Meinung nach sogar gewaltig. Denn SoC ist in meinen Augen bei genauerer Betrachtung sogar ein Argument für die Zusammenlegung von Tests und Implementierung.

Separation of Concerns besagt nämlich, dass unterschiedliche Zuständigkeiten eines Objekts voneinander getrennt werden sollten. Zuständigkeiten sind im Sinne der Domänenmodellierung und Systemanalyse Aspekte von Verhalten und Funktionalität. Ergo: Unterschiedliche Zuständigkeiten eines Verhaltens sollten voneinander getrennt werden. Ein schönes Beispiel ist der Taschenrechner. Die Funktionalität des Addierens des Taschenrechners gestaltet sich aus dem Tastenfeld, der Recheneinheit, und der Anzeige. All das sind Aspekte der Funktionalität, die in eigenständige Zuständigkeiten münden. Im Sinne der „Separation of Concerns“ sind diese Aspekte zu trennen und damit die Komponentenorientierung und Wiederverwendbarkeit zu stärken.

Completeness of Concern

So weit, so gut. Doch Separation of Concerns bedeutet für mich im Umkehrschluß auch, dass man eine Zuständigkeit einer Funktionalität auch zusammenhalten sollte. Ein einziger „Concern“ sollte in sich geschlossen sein. „Das ist er doch automatisch“ denkt man sich. Naja, ganz so einfach ist es meiner Meinung nach nicht. Denn eine Zuständigkeit einer Funktionalität findet man in der Software-Entwicklung oftmals nicht als „ganze Einheit“ an einem Fleck, sondern überall verteilt.

So wird z.B. in der klassischen Softwareentwicklung die Zuständigkeit in den Requirements erfasst. Man findet sie in der Use-Case-Dokumentation und in UML-Diagrammen wieder, diesmal mit ein oder zwei Szenarien. Natürlich wird das Verhalten und dessen Aspekt auch in den Tests manifestiert – dazu sind sie ja da. Und – wer hätte das gedacht – die Funktionalität findet man auch im Code wieder. Resultat: Ein einziger Concern, der im Entwicklungsprozess an allen möglichen Stellen auftaucht. In einem solchen Szenario ist es für den Entwickler meistens wie ein Puzzle, bei dem die Puzzlestücke überall sind – nur nicht auf dem Tisch.

Es ist also für die „Vollständigkeit einer Zuständigkeit“ nicht hilfreich, Tests und Implementierung voneinander zu trennen. Weiterhin hat das Trennen von Tests und Implementierung nichts mit Separation of Concerns zu tun, denn schließlich geht es sowohl bei den Tests als auch bei der Implementierung um einen einzigen Concern – dem Aspekt der Funktionalität, die das SUT eben abbilden soll.

Es ist gerade die Fraktion der BDD-Anhänger, die genau diesem Umstand mit all Ihren Argumentationen und Prinzipien hervorheben möchten. Sie reden nicht von Tests, sondern von Spezifikationen, sie reden nicht über Verifikation, sondern über Verhalten. Ja, sie gehen sogar soweit und reden im Sinne der Context-Specifications von „Concerns“, also „Zuständigkeiten“. Das alles sind klare Hinweise, das die Spezifikation eines Verhaltens und deren Umsetzung als unzertrennliches Paar zu betrachten sind. Übrigens ist diese „Expressivität“ auch ein Grund, warum „BDD“ so gut geeignet ist für Einsteiger in TDD bzw. Test-First.

Feels just like it should

Wenn man mal eine gewisse Zeit per TDD/BDD entwickelt, dann fällt einem oft auf, dass man bei jeder Änderung mindestens zwei Dinge ändert. Man ändert oder erweitert die Tests und man ändert oder erweitert die Implementierung. Ein Verhalten, eine Zuständigkeit, doch zwei Perspektiven, zwei Änderungspunkte.

Das ist bei Far-Specs, (also getrennten Tests und Implementierung über Assembly-Boundaries) genauso wie auch bei Near-Specs (Tests & Implementierung Seite-An-Seite). Doch bei Near-Specs ist es einfacher, schneller und intuitiver, Änderungen am System durchzuführen. Darüber hinaus wird das Streben nach „Vollständigkeit eines Verhaltens und deren Zuständigkeit“ gestärkt. Das wiederum zahlt auf Lesbarkeit, Wartbarkeit und Flexibilität ein.

Seit nun seit knapp 3 Monaten entwickle ich Unit Tests, TDD & BDD ausschließlich per „Side-By-Side-Specifications. Diese „andere“ Art der Codeorganisation ist für mich äußerst angenehm und effektiv gleichermaßen. Für mich ist es ein stückweit näher dran am „TDD-Spirit“, dem test- bzw. spezifikationsgetriebenen designen und entwickeln von Software. Mit Tests & Implementierung nebeneinander fühlt es sich so an, wie es eigentlich sein sollte.

Also: Feels just like it should ;-)

It’s been something like a week since Stefan asked a provoking question in his blog (german): „Where to put the Tests?” He wrote that he’s strictly separating tests from their implementation in separate projects. However, motivated by a statement of me, he gave the idea of having tests & implementation in the same project a try. Wow, all code in one assembly. He as well as a punch of commentators on his blog came to the conclusion, that separating tests from implementation using separate projects is better. I argue the converse.

It’s simply old-fashioned style to separate tests & implementation with separate projects. I did separate my tests from implementation code for years. However, about half a year ago, I realized that this separation doesn’t help me much. Instead, it hinders my development process. Since then I keep tests & implementation together in one project. They are located as near to each other as possible. Let’s name this “side-by-side” residency. In this post I want to show and explain the main reasons, consequences and experiences in favor of “side-by-side specifications” or “near specs”.

Well, first of all, I reduce the practice of „near specs” to unit tests only. Just as in classical sense of TDD. Integration tests and verification-driven tests are located in separate projects (thus being “far specs”), as usual. For me, putting tests and implementation altogether in one project makes sense in test-first approaches. That is, TDD testing or BDD specifications. Ergo: It’s about tests I use to drive my implementation. Tests, which I’m using to design and develop the desired functionality.

The grip of behavior

So, what’s the point then to put tests and implementation side-by-side? In my opinion there’s a quite naive, yet effective reason: You get grip of your tests. The tests are simply there. They’re where I need them; they’re there where I expect them. They are right there where the behavior is. Since I keep tests next to my implementation, I’m just better able to “put them in shape”. Means: I do refactorings a lot more effective and frequent. Naturally not only on SUT, but tests as well.

Generally speaking, it’s a kind of different, more efficient style of development to work with implementation & tests right at hand. Coming back to projects after some time makes it a breeze. I just look and read the tests. Then, I navigate frequently between tests and implementation to understand the details. “Near specs” make it less painful and more pleasant to read the code. This is especially the case for tests where several dependencies / mocks exist. No jumps through projects, no loading of solutions here and there. Just reading, that’s it.

To put it candidly, it was hard at start. The number of test classes – or the amount of test code in general – is quite a lot compared to implementation code only. I had to get used to it somehow. From time to time, I had a strange feeling that my tests are distracting me. It was so unusual for me that I felt that my tests “messed up” my organization in my “production” project. It didn’t last long though. As I continued to keep my tests right where my implementation is, I more and more realized how cool and beneficiary it is to do so. Especially as I utilized this approach on a larger codebase. Since then, it’s clear for me: putting specifications/tests side-by-side rules!

Wait, the world’s not shining always. New questions arise with this new “colocation” of tests right where the implementation is. Probably the most often asked is how the release assemblies of such applications look like. Needless to say, it’s desirable to let release assemblies contain only what the customer actually needs: the functionality. However, with tests in same assembly, how would you achieve this?

Reduce to the Max

The solution is quite simple: If tests and implementation are no longer divided in design- or development-time, then the split-up needs to take place later on, at delivery-time! Simply put, the build needs to take care of this task. Since I’m used to use build scripts for my projects, it’s quite a common thing for me to adjust end enhance my scripts to filter out the test classes and test-related references. For my own tiny projects, I most often use powershell scripts. At larger contexts with CI and Buildsystems, a call to a cleanup extension is an obvious, handy task.

Back to Stefan’s post. As I read through comments, I thought to myself: Why do so many people write so much about it and judge this approach as “tricky” or “dirty” without obviously not having tried it once? I did give it a try and I’m feeling very fine with it. It’s neither difficult, not dirty at all. The contrary is the case. Now that I use „near specs“, my daily TDD and development life is more pleasant and effective than before. Building a filter for test-related artifacts is an easy task. In my scripts, I usually need about 10 lines for this. Moreover, it’s worth to keep in mind that filtering is “only” needed for release builds. No CI build whatsoever affected.

Once read through the whole thread, I just said to myself: „I even would build my build script test-first faster than reading all this”. As some of you know me as a friend of empiric results and measurement, it’s obvious that I needed to check if my statement really would turn out true. Just do it and see if it’s really that fast and easy. No sooner said than done! I pushed the results to my github repository. Brief summary: Even without test-framework and with my „limited“ powershell knowledge, I was able to build my test-artifact filtering in about the same amount of time I spent to read the blog. ;-)

Separation of Concerns

Another argument quite often rose against putting tests and implementation together is “Separation of Concerns” (SoC). “Partitioning tests and implementation in separate projects is following this principle”, it’s being said. Even good friends of mine, like Tehlike bring SoC onto the table against “near specs”. By the way, I specially write this article in English for Tehlike, and therefore:

Tehlike, yanılıyorsun! ;-)
(In english: Tehlike, you are mistaken!)

Yes, I think that those are mistaken who think that SoC is a reason to split tests and implementation. From my perspective, the opposite is the case. SoC is – once considered to look at it carefully – even a reason to put tests and implementation side-by-side.

The essence of Separation of Concerns is quite easy: diverse perspectives, say „concerns“, of a behavior of an object should be separated. „Concerns“, in context of domain modeling and system analysis, are aspects of behavior and functionality. Take the calculator example. The functionality of „addition“ of a calculator has different aspects. You need to enter the numbers through keys, the calculation unit needs to add the numbers, and the sum needs to be displayed. All concerns – better: different concerns – of one functionality. With respect to „Separation of Concerns“, those aspects need to be separated. In consequence, a component-oriented and reusable solution is fostered.

Completeness of Concern

So far, so good. But wait. For my understanding, Separation of Concerns means by implication, that a single concern should strive towards entirety. That is, one single concern ideally should aim completeness. „Isn’t this automatically the case?“ you might think. Mhh, not really, in my opinion. Most often, one concern is located on very diverse and unusual locations within a software development process.

Take the „classical“ software engineering scenario as an example. A behavior and its concern is described in requirements documentation. You can find different, mostly edgy details of the same concern in UML diagrams and Use Case documents. Of course, tests reflect the concern again. Well crafted, tests most likely specify the concern at its best. Naturally, the concern is in production code, implanted as final functionality of the system. And what’s the result now? Straight answer: The result is a mess. Most often, a developer finding himself in such a situation is faced with puzzle pieces everywhere – but not on the table.

Hence, for me it’s obvious that partitioning tests and implementation in separate projects is not helping me to strive towards „Completeness of Concern“. Moreover, splitting up tests an implementation is not related to Separation of Concerns. Both tests and implementation care about the same concern, that’s the simple truth.

BDD lovers in the wild will clap their hands. The abovementioned is more or less the same they proclaim over and over. They don’t talk about tests; they care about “specs”. They don’t talk about verification; they care about “behavior”. Yes, they even care about concerns, drivers and observations. Altogether, this is even for beginners quite a good hint towards a mindset, where tests and implementation build a chained, inseparable pair.

Feels just like it should

Let’s face it. Once developing a reasonable time in TDD/BDD style, you clearly realize one thing: Whenever you need to change or extend the system, you have at least two „changepoints“. First, you change tests. Right afterwards, you change your implementation. One single behavior, one single concern. But two perspectives, two edits. That’s the case for „far specs“ (that is, tests located in a separate project) as well as for “near specs” (that is, tests residing in the same project along with the implementation “side-by-side”).

The difference: With near specs, you change and develop the system faster, & easier. It’s simply more efficient and intuitive. Near specs foster „Completeness of Concern“. This essentially contributes to better readability, maintainability and flexibility of the overall system.

It’s been more than 3 months now since I started to structure my unit tests strictly side-by-side along to my implementation. For me, this “different” style of code organization is absolutely pleasant and effective. Right now, I can’t think of switching back. In my opinion, putting tests and implementation as near as possible is in favor of the “TDD spirit”. With tests and implementation being at the same place, for me TDD now more and more “feels just like it should” ;-)

Wie dem auch sei, am Ende des besagten Artikels hatte ich einen Ausblick darauf gegeben, dass ich nicht nur die Punkte nennen werde, die ich als Schwachstelle in Scrum sehe, sondern auch meine Ideen dazu beitragen werde, diese Schwachstellen zu stärken und damit Scrum als agile Managementmethode für mein Verständnis erfolgreicher zu implementieren. Das habe ich für das Thema “bessere Sprintdauer” schon getan, und damit widme ich mich heute einem ganz besonderen „Schwachpunkt“ – dem Scrum Master.

Die innere Handbremse

„Oh je, der Scrum Master ist ein Schwachpunkt von Scrum?“ werden sich nun viele stirnrunzelnd denken. Ja, genau so ist es, der Scrum Master ist meiner Meinung nach sogar eine richtig hinterlistige Schwachstelle in Scrum-Projekten. Das liegt viel weniger an dem Scrum Master als Person als am Scrum Master als Rollenimplementierung, wie er in vielen Büchern beschrieben wird und von Scrum-Trainern bei Unternehmen „antrainiert“ wird.

Viele Scrum Master in heutigen Organisationen sind „Vollzeit-Scrum Master“, die dediziert ein Scrum Team betreuen und sich tagtäglich mit den Sorgen, Nöten und Bedürfnissen Ihres Teams auseinandersetzen. Meiner Meinung nach ist hier schon der erste Schwachpunkt erkennbar. Obwohl die Rollendefinition in „Scrum-Bibeln“ nicht oft vom Scrum Master als institutionalisierte Position spricht, wird sie überall diskutiert, implementiert und implantiert.

Ein Scrum Master ist dazu da, sich überflüssig zu machen. Eines seiner größten Ziele ist es, sein Team in die Selbstorganisation zu führen und dort zu halten. Doch wie geht das bei einem Scrum Master, der eine Planstelle in einer Organisation ist? Mehr noch, hinter der Rolle Scrum Master verbirgt sich dann eine konkrete Person, ein konkreter Arbeitsplatz, ein konkretes Schicksal. Und diese Person soll sich jetzt überflüssig machen? Das wird wohl selbst der barmherzigste Mensch nicht tun. Jetzt könnte man diesen Vorwurf mit „don’t blame the tool“ abwiegeln, aber das wäre zu einfach. Die Schwachstelle liegt viel tiefer begraben als es auf der Oberfläche sichtbar ist.

Zwischen den Stühlen

Zumeist befindet man sich als Scrum Master innerhalb einer „agilen“ Organisation sowieso in der Zwickmühle. Einerseits sollte man das Team nicht führen, sondern begleiten. Andererseits bleibt das Management als „Chicken“ selten mehr als die ersten paar Sprints ruhig. Nicht selten trägt es „Erwartungen“ und „Strategische Leitlinien“ an den oder die Scrum Master heran. Schließlich ist der Scrum Master ja überzeugt von Scrum und der Idee, dass der Product Owner nun das Management betreiben soll. Die Kennzahlen über Team- und Projektperformance holt man dennoch beim Scrum Master ein, weil der „einfach näher dran am Geschehen ist“.

Viele Scrum Master fügen sich in diese organisatorische „Kneifzange“, anstatt sie mit Kraft zu durchbrechen. Wie soll man auch, wenn z.B. der eigene Job daran hängt oder die letzte (dicke) Auszahlung des Dienstleistungsvertrages mit dem Kunden noch aussteht?

Der Alleskönner

Viele eingefleischte Scrum-Experten und erfahrene Trainer stellen deshalb die Rolle des Scrum Masters auf ein hohes Podest. Der Scrum Master sei „eine Führungsrolle im Prozess“, es dauere tausende von Stunden, die Charakteristika und schwierigen Aufgaben eines Scrum Masters zu meistern. Ein Change Agent und Facilitator hat es eben nicht leicht.

Der Scrum Master als Rolle wird oft als Alleskönner dargestellt. Schließlich muss er die Grundlagen des Managements beherrschen, ein absoluter Teamplayer sein und obendrein auch noch ein feiner Kerl den jeder mag. Der Scrum Master ist der neue MacGyver in der agilen Software-Entwicklungslandschaft und kann selbst aus den schwierigsten und aussichtslosesten Situationen mit Einfallsreichtum, Know-How und Cleverness den Erfolg hin zur effektiven & profitablen Software-Entwicklung gestalten.

Eine schöne Vorstellung. Doch die Realität ist eine andere. In der Realität gibt es nur einen MacGyver, und den sogar nur im Fernsehen. Schade für die vielen Softwarefabriken und Weborganisationen, schade für die vielen Scrum Trainer und Berater, schade für die Tausenden von „Certified Scrum Master“. Doch Karten auf den Tisch: Es wäre auch zu schön gewesen, oder?
Mittlerweile ziehen sogar Alpha-Agilisten und Scrum-Kenner das „Scrum Is Always Better, Scrum Master Is Always Hero“-Gefühl durch den Kakao. Mit wunderbar leichtem und gleichzeitig nachdenklich stimmendem Humor schreitet seit einiger Zeit „Scrum Norris“ durch die geistigen Pfade der Agilität.

Quo Vadis Scrum Master?

Doch weder Humor noch Lamentiererei helfen einem dabei, diesen Schwachpunkt des „Scrum Master-Daseins“, nämlich die viel zu starke Fokussierung der Rolle und deren Implementierung, zu verbessern. Was tun? Wie kann man in einem Scrum-Team oder in einer Organisation mit Scrum-Teams diesen viel zu starken Fokus auf den Scrum Master mindern? Ich möchte hier einen konkreten Verbesserungsvorschlag und eine konzeptionelle Perspektivänderung als Diskussionsgrundlage vorstellen.

Dazu möchte ich ein Szenario aus der Entwicklung selbst voranstellen, um den Effekt der Maßnahme deutlicher hervorzuheben. Es wäre meines Erachtens sehr hilfreich für Team und Scrum Master, wenn die Abhängigkeiten zum Scrum Master zu allen anderen Rollen sowie zu der umgebenden Organisation so gering wie möglich sind. Um Abhängkeiten voneinander zu entkoppeln, gibt es in der Software-Entwicklung einige bewährte Methoden. Eine davon ist die sog. „Dependency Inversion“ oder „Inversion of Control“. Das hört sich doch genau nach dem an, was gebraucht wird, nämlich eine „Inversion of Control“ im wörtlichen Sinne. Nicht der Scrum Master organisiert das Team, das Team organisiert das Team.

Scrum Master in Bewegung

Übertragen auf den Prozess und die Rahmenbedingungen, die die Scrum-Methode vorgibt, ließe sich eine solche Indirektion mit einem einfachen Mittel erreichen: Die Rolle des Scrum-Masters wird im Team rotierend „durchgereicht“. Statt eines Scrum Masters, der sich dediziert um ein (oder noch schlimmer mehrere) Teams kümmert, kümmert sich das Team um die Erfüllung der Rolle des Scrum Masters. In der Praxis kann man den „Scrum Master-Hut“ z.B. sprintweise, monatsweise, oder quartalsweise von Team-Mitglied zu Team-Mitglied weiterreichen.

So ist jeder einmal mit der „Verantwortung“ des Scrum Masters konfrontiert und lernt obendrein eine weitere, wichtige Perspektive des Prozesses kennen. Dadurch erschließt sich sukzessive dem ganzen Team eine tiefere Kenntnis der Vorgehensweise. Es ergibt sich eine induktive Selbstorganisation: Man lernt die Probleme und Aufgaben der Scrum Master Rolle kennen und hilft sich gegenseitig im Team, dass es nicht zu Problemen kommt oder diese schnell ausgeräumt werden.

Aus Sicht des Prozesses mündet das Rotationsprinzip in mehrere Vorteile. Zunächst wird einmal wird nicht nur die Selbstorganisation gefördert, sondern auch das Know-How effektiv verteilt. Der Bus-Faktor wird im Kontext des Prozesses und der Methodensicherheit massiv erhöht.

Refokussierung der Kommunikation

Für den Product Owner ist der wechselnde Scrum Master ein regelrechter Segen: Statt sich die ganze Zeit auf den Scrum Master zu konzentrieren, kann (und muss) er sich nun mit dem ganzen Team auseinandersetzen – so wie es am effektivsten ist und sich auch „gehört“. Darüber hinaus lernt der Product Owner, seine geschäftlichen Anforderungen und Interessen mit der „Masse Team“ zu koordinieren, statt mit dem „Ansprechpartner“ Scrum Master, wenn es mal wieder Abstimmungsprobleme oder Missverständnisse gibt.

Nicht nur der Prozess, sondern auch die umgebende Organisation – also das Unternehmen – profitiert von dieser Maßnahme. Statt wieder neue Stellen oder Stufen in die Organisation zu implementieren, wird durch die Rotation der Scrum Master von „allen“ getragen. Ergebnis: Keine neue „Position“ Scrum Master, keine Kompetenz- und Verantwortlichkeitskonflikte mit Teamleads (Gruppenleiter) oder Head-Of’s (Abteilungsleiter), keine Skalierungsprobleme. Die Führungsmöglichkeiten sind klar und bei einem partizipativen Führungsstil höchst effektiv.

Die Rückkopplung zum mittleren Management und der strategischen Führung wird greifbarer, denn jetzt kann sich das Management nicht mehr den „Scrum Master“ als Mittelsmann für Mitarbeiterführung herauspicken. Der Fokus für wird stattdessen zum Product Owner gelenkt. Der wiederum wird – wie auch das Management selbst – realisieren und anerkennen müssen, dass sich eine Selbstorganisation nicht kommandieren lässt, sondern sich nach Bedürfnissen orientiert.

Scrum Master: Kein Platz für Projektleiter

Das Unternehmen wird schlanker, weil der „klassische“ Projektmanager nun nicht mehr in die für ihn äußerst angenehme „Scrum Master“-Schiene flüchten kann, sondern sie entscheiden muss: Entweder Product Owner oder Team!

Ich selbst dachte vor ein paar Jahren noch, dass der klassische Projektmanager nur die Wahl zwischen Scrum Master und Product Owner hat. Falsch! Heute darf ich die Lehre ziehen, dass ich damals auf den Scrum Master als Rolle viel zu Stark fokussiert gewesen bin. Team und Product Owner sind die “Key Player”, der Scrum Master ist nur Mittel zum Zweck, und das – wenn möglich – nur soviel wie unbedingt notwendig.

Mein Fazit: Mit einem rotierenden Scrum Master schafft man viele inherente Hürden aus dem Weg. Das Team, der Product Owner und die umgebende Organisation fokussieren sich deutlicher auf die Aufgabe. Der Prozess Scrum wird dadurch im Software-Entwicklungs-Theater wieder mehr zum Bühnenbild, das Team zu den Schauspielern und der Product Owner zum Regisseur. Damit ist dann auch eine gute agile Vorstellung wesentlich einfacher und schmerzfreier umsetzbar. Vorhang auf!

Vorne sitzt Ralf Westphal, der Architekt, der Wissenvermittler, der Konferenzorganisator – kurzum eine .NET Lichtgestalt. Er klickt und tippt noch schnell Dinge in sein Laptop. Die Teilnehmer warten. Komisch, üblicherweise macht man Witze und redet über einige interessante Blogposts, bevor es losgeht. Ich hätte z.B. erwartet, dass einer in die Runde „Null oder nicht null, Hauptsache Ergebnis!“ wirft und so ein wenig die Runde auflockert. Doch Nein. Es liegt Konferenzduft in der Luft. Alle starren und warten.

18:45 Uhr – Es geht los: Nach ein paar einleitenden Worten und dem lieben Dank an Jan, dem Hüteträger und Evangelisten für die super Organisation der Location geht es schon los. Ralf ist am Zug. Was danach genau im Münchener .NET Coding Dojo passiert ist, beschreibt Ralf akribisch und meiner Meinung nach ziemlich treffend in seiner Retrospektive für das Coding Dojo. Inhaltlich kann ich dem kaum etwas hinzufügen und möchte mich nochmals bei Ralf für diese gute Session bedanken.

Doch ganz so unkommentiert möchte ich es dabei natürlich nicht belassen. Steffen, der vor kurzem sehr erfolgreich das Hambuger .NET Coding Dojo initiiert hatte, hat in einem Tweet seine Bedenken über den „Community-Gedanken“ geäußert. Seiner Meinung nach ist ein Coding Dojo keine „One-Man-Show“ mit Musterlösung. Ich habe ihm per Twitter schon geantwortet, möchte aber hier noch ein wenig detaillierter auf meine Auffassung eingehen.

Das „Format“ Coding Dojo

Ich hatte schon vor über einem halben Jahr einmal über das Ziel von Coding Dojo’s gebloggt. Damals, in einem Coding Dojo mit Pete, habe ich im Nachhinein mir einige Gedanken über das „Format“ Dojo gemacht. In besagtem Coding Dojo lief nämlich alles – also wirklich alles – gerade nicht so, wie es sich Pete und ich vorgestellt hatten. Wir hatten uns mit ein paar Kata’s vorbereitet und den Ablauf schon ein wenig vorgedacht. Aber es kam alles anders. Warum?

Die Antwort ist einfach: Weil wir es zugelassen haben. Wir haben eine Sache beherzigt: Ein Coding Dojo ist eine Veranstaltung für die Teilnehmer. Jeder sollte nach einem Dojo mit dem Gefühl nach Hause gehen können, dass er etwas gelernt hat. Im Coding Dojo mit dem KataBlog war den Teilnehmern die Komponentenorientierung und das IOC nicht so wichtig wie grundlegendere Themen, wie z.B. MVC als Pattern oder die HTTP-Request-Response-Pipeline von ASP.NET. Das haben wir beachtet und unseren Plan zurückgestellt.

Aber warum ein Coding Dojo ohne Coding?

Adaptiert auf das Coding Dojo von letzter Woche von Ralf lässt sich folgendes hinzufügen: Wir als Münchener .NET Coding Dojo Crew haben Ralf eingeladen, weil es die Teilnehmer – also wir, die Coding Dojo Community – so wollten. Wir haben Ralf nicht eingeladen, damit er eine Show abzieht. Wir haben Ralf auch nicht eingeladen, weil er der Ralf ist.

In einigen vorangegangenen Coding Dojo’s kam als Feedback der Teilnehmer immer wieder „zuwenig Architektur“, „zuwenig Design“, „zuwenig Vorgabe“. Als ich mit Ralf auf der VSOne darüber geredet habe, schlug er ein „Architektur-Dojo“ vor. „Super!“ dachte ich mir und freute mich, den Dojo-Teilnehmern mit einer Einladung ihren „Wunsch“ erfüllen zu können.

Wer beim .NET Coding Dojo vergangenen Mittwoch dabei war, der wird mir beipflichten, dass diesmal wirklich über Architektur, Design, Anwendungsaufbau und Komponenten-Orientierung ausgiebig diskutiert wurde. Ralf hat sein Versprechen gehalten. Er kam, dachte, designte und diskutierte. Genau so, wie es oftmals in Feedbackrunden vorheriger Dojo’s angefordert wurde.

Coding Dojo ist kein Workshop

Trotzdem. Es war anders als die vorherigen Coding Dojo’s. Ganz anders. Keine Diskussionen über die Kata-Wahl, keine Diskussion über Anforderungsanalyse, keine Design-Strittigkeiten. Statt dessen Ralf. Ralf wie er leibt und lebt. Das ist die Aufgabe, das ist die Vorgehensweise, das ist EBC, das ist State-Of-The-Art, das ist Regelwerk & Konvention. Punkt. Natürlich mit fester und stichhaltiger Argumentation und der Erläuterung der Beweggründe.

Aber irgendwie war es kein Coding Dojo so wie ich es kannte. Es gab hier und da mal Rückfragen an Ralf, „wieso“ und „weshalb“. Aber aktiv mitgemacht – aktiv Architektur gemacht – das hat meiner Meinung nach mehrheitlich Ralf getan. Ralf hat schon ab und an probiert per Rückfrage die Teilnehmer einzubinden. Doch andererseits gab es für die Teilnehmer nicht wirklich viele Optionen. Besser gesagt: Es war ein geplante Session, mit strukturierter Vorgehensweise und festem Rahmen. Da bleibt nicht viel Luft und Platz für anderes.

Man kann mir „als Veranstalter“ jetzt natürlich alles mögliche vorwerfen. Z.B. dass ich ja hätte eingreifen können, wenn es mir zu „passiv“ und zu „vorgetragen“ erscheint. Oder man könnte mir den Vorwurf machen, dass ich in den vorangegangen Coding Dojo’s einfach nur chaotisch in die Tasten gehauen habe, anstatt strukturiert vorzugehen und damit praktisch immer wieder so ein „wir brauchen Architektur“-Feedback provoziert habe. Ok, dann soll man mir die Vorwürfe machen. Meine Antwort dazu ist: Ich habe es zugelassen, weil es wichtig ist, Dinge zuzulassen. Darüber sollte man nachdenken.

Coding Dojo und Community

Jetzt transportiere ich mal meine persönliche Auffassung etwas deutlicher, damit es nicht wieder heisst, ich wäre zu objektiv oder würde mich hinter geschnörkeltem Satzbau verstecken. Ich persönlich denke, dass das letzte Coding Dojo absolut kein Coding Dojo war. Es war ein Architektur-Workshop mit Ralf Westphal. Und wenn ich das so sagen darf: Es war ein guter Architektur-Workshop. Aber es war für mich mit Sicherheit kein Coding Dojo. Es gab keine aktive Einbindung der Teilnehmer, es gab keine lockere Atmosphäre, es gab kein Coding und keine großen Diskussionen. Ich finde, das war kein Coding Dojo, wie ich es mir wünsche und wie ich es auch gut finde.

Aber meine Meinung ist nicht wichtig – das habe ich nach nun mehr als 50 Coding Dojo’s gelernt. Es ist nicht wichtig, wie ich Probleme löse. Es ist auch nicht wichtig, welches Framework ich verwende. Und es ist schon garnicht wichtig, wie ich Analyse, Architektur, Design oder Entwicklung betreibe. Denn das einzige was zählt im Coding Dojo sind die Akteure. Die Akteure im Coding Dojo sind die Teilnehmer. Das ist entscheidend.

Dojo = Lernen?

Wenn also die Teilnehmer des „Coding-Dojo’s“ mit Ralf in der Feedback-Runde sagen „Ja, das hat mir gut gefallen, ich habe super mitgemacht & viel gelernt“ – dann, ja dann ist es wohl ein Dojo gewesen. Vielleicht kein „Coding“ Dojo, aber es war ein echtes Dojo. Aber wenn die meisten kommentarlos und höflich klatschend das Dojo beenden, dann, ja dann war es wohl kein Dojo. Wie gesagt: Für mich war das kein Dojo – schon garnicht ein Coding Dojo. Aber das Feedback am Ende von Ralf’s Session war durchaus positiv. Also scheint es für einige Teilnehmer ein Dojo gewesen zu sein.

Natürlich möchte ich an dieser Stelle noch ein paar weitere Dinge loswerden. Ich möchte nicht, dass man die Definition des „Coding Dojo“‘s auf „Hat es dir gefallen?“, “Konntest Du mitmachen?” oder „Hast du etwas gelernt?“ reduziert. Ein echtes Coding Dojo hat einige weitere Parameter, die entscheidend sind für den speziellen, magischen Charakter und den guten Erfahrungsaustausch. Der aufmerksame Leser wird z.B. erkannt haben, dass ich nicht ein einziges Mal TDD erwähnt habe. Wenn Interesse daran besteht, die Bestandteile und das Format „Coding Dojo“ aus meiner Perspektive genauer kennenzulernen, dann bitte sagt mir das (schreibt einen Kommentar oder eine Email), und ich werde es niederschreiben.

Fazit & Ausblick

Abschließend möchte ich zu „Ralf’s Coding Dojo“ noch folgendes loswerden. Es war der Wunsch der Community und ich (und Ralf) haben versucht, diesem Wunsch gerecht zu werden. Es war eine gute Erfahrung. Ich habe viel daraus gelernt und ich denke, dass auch die Teilnehmer etwas mitnehmen konnten. Es war ein guter Architektur-Workshop und Ralf hat viel investiert, um den Teilnehmern seine Sicht zu zeigen und Wissen zu transportieren. Danke, Ralf.

Doch eines steht heute schon fest: das nächste .NET Coding Dojo, welches im Übrigen wieder ein ganz besonderes Dojo ist, wird mit absoluter Sicherheit ganz anders ablaufen. Nicht nur, weil diesmal nicht der Ralf eine Aufgabe stellen wird. Nein. Es wird ganz anders, weil die Partizipation und das aktive teilnehmen exemplarisch exerziert werden. Das nächste Münchener .NET Coding Dojo findet am 22. Juni im Rahmen des dotnetpro.powerday’s statt und hat den treffenden Titel „.NET Coding Dojo Empowered!“. Sei dabei und erlebe, wie man gemeinsam Lernen & Lehren kann, wie man gemeinsam eine Problemstellung mit Logik & Spaß lösen kann, wie man professionelle Software-Entwicklungs-Methoden im Team einsetzt! Es wird wieder einmal einzigartig und sehr lehrreich werden. Zur Anmeldung!

Helfen ist schön, geholfen werden ist schöner!

Ich weiß es nicht genau, aber ich vermute es ein wenig, dass Thomas auch froh ist, wenn er durch Meinungsaustausch seine eigenen Herausforderungen besser einzuschätzen vermag. Ich persönlich empfinde diese „Kalibrierung“ als wichtigen Baustein zur Festigung der eigenen Meinung.

Thomas hat mit Null Verständnis gefragt, wie die Handhabung von NULL als Rückgabe von Methoden bei anderen Entwicklern umgesetzt und eingeschätzt wird. Viele haben kommentiert, einige haben auch Blog-Post-Antworten geschrieben. Ich habe das mit Kommentaren und dem Null Toleranz-Beitrag auch getan, der unermüdliche Ralf hat auch kräftig in die Tasten gehauen. Überraschenderweise mit mehreren Aussagen.

Ralf geht in seinem „Plädoyer für Regeln“ auch auf einige Punkte ein, die ich über die Handhabung von NULL in Anwendungsszenarien bemerkt hatte. Ralf hat so vieles geschrieben, dass es mir schwer fällt, wirklich alle Themen in einem oder mehreren Blog-Posts zu erwidern. Einen Überblick über meine Perspektive möchte ich dennoch geben.

Mind the Null!

Ralf stellt im Namen der Community die erste Null-Regel auf:

“Man darf Null benutzen und auch als Wert zurückgeben – aber Vorsicht! Erst prüfen, ob es nicht auch anders geht”

D’accord! Das hatte ich ja auch schon in Kommentaren und per Twitter erwähnt. Doch wann kann man Null verwenden, wann nicht? Gibt es dafür eine „kontextarme“ Regel? Kann man pauschal sagen: „Verwende es nicht!“. Meiner Meinung nach ist das nicht so einfach. Klar kann ich auch sagen, dass man Null einfach nicht anwenden soll, aber ich mache es mir nicht so einfach.

Wenn ich nämlich obige Regel einem Embedded-Entwickler entgegenbringe, dann lacht der mich mal gepflegt vor seinen Kollegen aus. In der Embedded-Entwicklung, wie auch bei sehr ressourcenintensiven Geschäftsanwendungen ist es nämlich durchaus erstrebenswert, oft NULL zurückzugeben, um damit z.B. eine leere Liste oder leere Suche zu signalisieren. Es mögen sich wenige daran erinnern, aber NIL (als Synonym für NULL) ist die Abkürzung für „Not-In-List“.

Null für Hacker

Ich selbst durfte schon mehrere serverseitige Komponenten von „Exception-Flut“ befreien, in dem ich sie in einigen Stellen durch NULL ersetzt habe. Danach lief der Service doppelt so schnell bei 25% weniger Ressourcenverbrauch. Bin ich jetzt ein Aussetziger, weil ich die Regel nicht befolgt habe?

Ich denke nein. Denn: In einigen Anwendungsszenarien ist es gang und gäbe NULL als Mittel einzusetzen. Mehr noch, es ist „normal“, soz. “die Regel”. Deswegen sage ich nach wie vor: Die Regel ist richtig, man sollte vorsichtig mit NULL umgehen und es mit bedacht einsetzen. Doch eine „Faustregel“ ist es für mich noch nicht, denn man kann es (noch) in bestimmten Anwendungsfällen vorteilhaft und stringent einsetzen.

CatastrophicFailureException ?? Null

Ralf schreibt:

„Null-Regel #2 (von Ilker; noch zu diskutieren): In Katastophenfällen darf Null zurükgegeben werden.“

Das ist keine Regel. Den Regelbedarf und die Kreativität zum Design eines Regelwerks wie Ralf habe ich (noch) nicht. Ich habe dafür aber Programme, die Probleme lösen. Bei einigen, wenigen Programmen habe ich NULL als Rückgabe für „katastrophale Fehler“ zurückgegeben.

Das hat mir bei der defensiven Programmierung geholfen, denn es ging um eine etwas kritischere Komponente, die an Schnittstellen sog. „Guards“ hatte, die alle möglichen Exceptions abgefangen haben. Im Nachhinein betrachtet hätte ich es wohl auch mit einer „CatastrophicFailureException“ oder mehreren, spezifischeren Exceptions lösen können. C’est ca!

Null nur bei „gleicher Kategorie“

Die dritte Regel von Ralf:

“Null darf nur Rückgabewert sein, wenn Null zur selben Kategorie gehört wie ein Nicht-Null Rückgabewert”.

Naja, streng genommen ist NULL ja nichts, und damit kann man es auch nicht kategorisieren. Antizipieren kann ich da nur, dass es um das Beispiel von Thomas mit der Liste gehen kann. Dem kann ich nur zustimmen. Hier ist ein Ausnahmefall zwar auch möglich, aber doch eher selten.

Dein Pflock ist mein Maibaum!

Ralf hatte mir zu viel “Rumgeeiere” in meinen Aussagen über NULL attestiert. Das will ich doch gerne versuchen besser zu machen und Ralf‘s „Pflock in Boden“ in meine triviale niederbayrische Welt übertragen und damit mal den „Maibaum ins Dorf“ stellen. Also, auf geht’s, Maderl & Buam – mein Maibaum im Dorf „Nullinger“!

Ilker’s Statement zu Null als Rückgabe von Methoden:

NULL ist gefährlich, meide NULL, außer es gibt triftige Gründe. Triftige Gründe können Performance, Speicher oder dynamische Datenstrukturen sein. Solltest Du NULL als „Indikator“ für etwas verwenden (z.B. „Nicht gefundener Benutzer“), ziehe eine Vermeidungsstrategie mit Exceptions oder ReturnCodes in Erwägung. Sei auf der Hut, NULL ist überall. Prüfe, ob deine Parameter oder deine Methoden NULL zurückgeben. Prüfe besonders, wenn Du parallelisierst oder wichtige Schnittstellen bedienst. Solltest Du ein NULL finden, versuche zunächst damit umzugehen. Geht das nicht mehr, signalisiere die Ausnahme. Achte darauf, dass ein NULL die Methode nicht verlässt.

So, ich hoffe das war konkret krass korrekt genug!

Immer diese Abhängigkeiten

Nachdem nun der Maibaum in Django Asül-Manier aufgestellt ist, möchte ich neben dem Ausgangsthema mich noch ein wenig den neuen Themen widmen, die Ralf in seinem Rules of Null-Post erwähnt hat. Ralf regt sich dabei ganz besonders über die „It depends“-Phrase auf. Ja, „It depends“, die allmächtige und einzige Antwort auf alles, was so im Leben an Fragen auf einen zukommen kann. Die Antwort „It depends“ ist kurz, erfüllt die Aufgabe und ist hochgradig flexibel bei gleichzeitig maximaler Wiederverwendbarkeit. Geradezu traumhafte Eigenschaften aus der „Nerd-Software-Entwickler“-Perspektive, oder nicht? Vielleicht ist es deshalb auch so beliebt in unserer Banche?

Spaß beiseite. „It depends“ ist eine Phrase, die mehr oder minder Inhalt liefern kann. Ich stimme Ralf zu, wenn er sagt, dass dieses „Es kommt drauf an“-Getue mit der Zeit nicht mehr auszuhalten ist. Deswegen kann ich die Reaktion von Ralf auch gut verstehen. Ich selbst finde es teilweise immer wieder erschreckend, wie oft auf diese Floskel zurückgegriffen wird, ohne darüber nachzudenken. Dennoch verwende ich es – ab und an zumindest, wenn ich es für erwähnenswert erachte.

Niemals ist niemals niemals

Fakt ist auch, dass „It depends“ nicht nur eine Bierdeckelweisheit ist, sondern auch als Abkürzung verwendet wird. Im Stile „ich erspare mir und Dir jetzt nähere Details“. Das kann gut und schlecht interpretiert werden. So oder so, es kommt darauf an :-) Genauer gesagt, auf den, der es interpretiert.

Womit wir bei der Quadratur des Kreises angelangt wären: Es ist nunmal so, dass wir Systeme vereinfachen und Abstraktionen schaffen, um es zu verstehen. Dabei geht auch Genauigkeit und Wahrheit verloren. Manchmal sogar so sehr, dass die aus der Vereinfachung abgeleitete Erkenntnis nicht mehr adequat bzw. erwartungsgerecht ist. Insofern ist „It depends“ nicht nur eine Fassade oder Ausrede, sondern eine zuweilen notwendige Mahnung, den Kontext und die Erkenntnis zu hinterfragen, sich bewußt mit der Lösung und Problemstellung auseinanderzusetzen. Für die Agilisten unter uns: „It depends“ ist ein auch ein Aufruf zum „Inspect & Adapt“.

Ich kann mich guten Gewissens Ralf anschließen, wenn es darum geht, Leitfäden und Empfehlungen über die Anwendung von NULL mit der Community zu erarbeiten. Meinungsaustausch ist Katalysator für Lernen, Entdecken, Erfahren und Bestätigen. Doch ein Regelwerk will ich nicht erstellen. Ich gebe meine Meinung und meinen Standpunkt gerne wieder. So wie ich es erfahren habe und so, wie ich es für gut empfinde.

Regeln habe ich auch. Ich habe meine eigenen Regeln, ich habe Teamregeln und ich habe noch eine Reihe weiterer Regeln, die ich für mich beachte und schätze. Regeln sind für mich wichtig. Ich möchte damit sagen, dass ich durchaus Ralfs Motivation nachvollziehen kann. Doch ich habe meine Beiträge nicht mit dieser Motivation mit der Community geteilt. Mein Ziel ist die Kommunikation und der Erfahrungsaustausch. Das wird auch so bleiben.

Thomas stellt zur Debatte, ob man aus Repository-Methoden ab und zu auch mal null zurückgeben darf/kann/soll. So z.B. bei so einer Methode:

User GetUserByName(string name);

Mache das Unmögliche möglich?!?

Einige Leute finden das garnicht besonders gut. Sie bevorzugen lieber soetwas wie einen “nicht-existenten” User zurückzugeben. Also eine Instanz einer Klasse, die eigentlich garnicht möglich wäre (weil sie ja die nicht exsistierende Instanz darstellt). Programmtechnisch ist das sicherlich recht einfach lösbar – oftmals mit einer statischen Property, die sich wiederum eines privaten Konstruktors bedient. In dem obigen Beispiel könnte eine derartige Implementierung ungefähr so aussehen:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return User.NotExistent;

  //user laden und zurückgeben
}

Eine zweite, nicht minder bevorzugte Alternative zur Rückgabe von NULL ist die beliebte Exception. Falls also kein Benutzer unter dem angefragten Namen existieren sollte, dann soll eine Ausnahme signalisiert werden. Ganz einfach implementiert:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    throw new UserNotFoundException(name);

  // user laden und zurückgeben
}

Beides sind sicherlich mögliche und sogar gute Alternativen zu der Implementierungsvariante, die Thomas zur Diskussion gestellt hat:

public User GetUserByName(string name)
{
  if (!repository.UserExists(name))
    return null;

  // user laden und zurückgeben
}

Um es kurz zu fassen: Alle drei Varianten sind möglich, alle drei Varianten sind gut, alle drei Varianten sind schlecht. Es kommt auf den Anwendungsfall an. Die beliebte “It-Depends”-Weisheit streckt das Thema mit geballter Kraft nieder. Dennoch ist es eine Untersuchung wert, denn ungewöhnlicherweise wird die NULL-Variante kategorisch als falsch und “böse” bewertet.

Nullbivalenz

NULL ist ein besonderer Wert. Er ist der Wert, der eigentlich nicht zugewiesen werden kann. Genauer genommen ist er kein Wert, sondern nichts anderes als die knapp in vier Buchstaben formulierte Aussage “Ein für eine bestimmte Werteklasse belegter Ort wurde mit keinem Wert belegt”. Ergo: Null ist kein Wert. Ja, aber ist das denn nicht genau das, was GetUserByName ausdrücken und zurückgeben muss, wenn es keinen Benutzer für den gegebenen Namen findet?

Schaut man sich die erste Alternative zu NULL an (also das User.NonExistent-Konstrukt), dann kann man sagen: Joa, ok – ist aber das Gleiche. User.NonExistent ist sicherlich expliziter als NULL. NULL ist aber schon da und genau für solche Dinge gedacht. Die Aufgabe von NULL ist ja genau die, keinen Wert darzustellen.

Und wie sieht es mit Alternative Zwei – der UserNotFoundException aus? Die Excpetion ist auch explizit. Mehr noch, die Exception ist flexibel und rigoros gleichermaßen. Flexibel, weil sie jederzeit aus dem Nichts auftauchen kann. Rigoros, weil sie eine Fülle von Informationen über den Kontext sammeln und mitgeben kann. Die Exception sagt hier klar und deutlich: “Es gibt keinen Wert, weil der Benutzer {name} nicht gefunden wurde.”. Scheinbar ein Vorteil gegenüber den anderen Varianten. Im Ergebnis ist es jedoch nicht wesentlich von den anderen Herangehensweisen unterscheidbar.

Null Sicherheit

Nun, offensichtlich ist die sprechendere Variante der Exception vorteilhaft und damit dem NULL vorzuziehen. Doch beim zweiten Blick entpuppt sich der Vorteil als nicht so deutlich als zunächst vermutet. Denn in der Praxis kann sich die “unklare” und “unexplizite” Art von NULL wieder als erwünscht erweisen.

So muss man bei Exceptions, um den Mehrwert zu kennen, auch deren Typ genau kennen. Man muss also Wissen, das es sich um eine UserNotFoundException handelt. Erst dann kann man auch erfahren, welcher ominöse Benutzer unauffindbar ist. Das kann durchaus problematisch werden, wenn man also im höheren Callstack wissen muss, um welche Exception es geht, denn schliesslich schafft man sich dadurch eine Abhängigkeit auf den niedrigeren Code.

Null ist also eine unsichere, uninformative, aber immer verfügbare und unabhängige Variante, dem Aufrufer zu sagen: “Es gibt keinen Wert für das, was Du von mir verlangst”. Wenn man sich mit der Anwendung von NULL jahrelang auseinandergetzt hat und auch ein wenig die ungeliebten Interna von Speichermanagement & Datenstrukturen hineinblickt, dann wird NULL schnell zu einer praktikablen Lösung für schwierige Situationen.

Doch vor Allem bei NULL stellt man immer wieder fest: praktikabel und elegant sind zwei verschiedene paar Schuhe. Denn NULL ist genauso nichtssagend wie vielseitig. NULL zwingt den Aufrufer zum Abwägen: Soll ich das Ergebnis gleich auswerten oder lieber überprüfen? Ein wunderbares Beispiel dafür ist sicherlich der “if (x != null)”-Check – die Null-Prüfung. Das wird vor Allem dann zum Problem, wenn man mit (gewollt oder ungewollt) unbekannten Komponenten arbeitet. Im Interface oder in der Typsignatur steht es jedenfalls sehr selten erkennbar drin, ob nun in Einzelfällen NULL zurückgeliefert wird oder nicht.

Null ist nicht gleich Null

Für mich gibt es beim Umgang und bei der Anwendung von Null keine Faustregel. Ich gebe in einigen Methoden NULL zurück. Meistens genau dann, wenn ich wirklich damit ausdrücken möchte, dass etwas katastrophales passiert ist. Ich finde es sehr schwerwiegend, NULL als Zuweisung oder Rückgabe stehen zu lassen – aber ich mache es manchmal ganz bewusst. In einer Anwendung, in der ich z.B. Benutzer über einen Authentifizierungsdienst identifizieren muss, bevor ich überhaupt etwas anderes machen kann, kann die folgende Signatur NULL zurückliefern:

interface IAuthenticationService
{
  Account SignIn(string user, string password);
}

Es kann alles mögliche passiert sein – keine Verbindung zum Server, falscher Server, Verbindungsfehler, Connection Timouts, Benutzer nicht gefunden, Benutzer gesperrt, Passwort abgelaufen, falsches Passwort – all dies würde ich versuchen über Exceptions oder Return-Codes zu erledigen. Die meisten der Exceptions gibt es ja schon frei Haus vom Framework. Aber für das mich Unbekannte und Unerwartete gibt es immer noch eine Rückgabe, und die heisst NULL.

Null-Summen-Spiel

Generell kann ich für mich nur sagen, dass ich gelernt habe mit NULL sehr vorsichtig umzugehen. Ich vermeide es so gut wie möglich. Exceptions sind ein gutes Mittel – allerdings setze ich sie auch nicht sehr oft ein. Die Bürde der Abhängigkeit ist schon da – obwohl es natürlich in der Contract-Assembly definiert ist. Bei Repositories habe ich (fast) immer Ergebnisse die nicht NULL liefern. Andererseits setze ich NULL als Rückgabe auch öfter ein, wenn ich nur eine “schwere” Ausnahme in meinem Code feststelle.

Im obigen Beispiel hätte ich wohl NULL als Rückgabe toleriert, vor Allem, wenn ich davon ausgehen kann, dass es oft – oder sehr oft – dazu kommen kann und diese Tatsache ein schwerwiegendes Problem darstellt. Ein schönes Beispiel sind immer wieder die Brute-Force und DOS-Attacken auf Webportale.

Ich hätte wahrscheinlich nicht NULL zurückgegeben, sondern eine Exception ausgelöst, wenn ich das Ganze als wiederverwendbare, allgemeine Kompontente entwickeln würde.

So oder so – beides ist machbar und beides hat seine Berechtigung. Klar und deutlich soll aber abschließend erwähnt sein: NULL zu vermeiden ist eine gute Sache. Es macht den Code expliziter, offensichtlicher und lesbarer.

NSpec ist einer der ersten – wenn nicht sogar das erste explizite – BDD-Framework für .NET. Mittlerweile wird es auch nicht mehr aktiv betreut. “Schade”, denkt man sich auf der einen Seite. Andererseits jedoch nicht sooo schlimm. Schließlich war der Autor mit dieser “finalen” Version offensichtlich zufrieden. Überdies ist die NSpec-Basis auch in andere Test-Frameworks eingeflossen – dazu aber später mehr. Bleibt auch noch anzumerken, dass man NSpec und MSpec nicht miteinander verwechseln sollte. Die Frameworks unterscheiden sich massiv, obwohl die Namensähnlichkeit das nicht vermuten lässt. Auch MSpec wird in meiner kleinen Serie sicherlich in der Zukunft noch seinen Platz finden. Doch nun zurück zu NSpec (N wie Nordpol) :-).

Bei NSpec dreht sich, wie nicht anders zu erwarten war, alles um Spezifikationen. Ich werde hier nicht näher auf die Gemeinsamkeiten oder Unterschiede zwischen TDD und BDD eingehen, werde auch nicht groß ausholen, wie und wieso BDD entstanden ist. Es sei nur kurz angerissen, dass bei BDD nicht das “testen” im Vordergrund steht, sondern die Spezifizierung des Verhaltens – Behavior Driven Design eben. Abgesehen von der Terminologie ergeben sich weitere Unterschiede, die auch am Beispiel von NSpec feststellbar sind. Genug Vorgeplänkel, auf geht’s zum Test-Training mit dem FizzBuzz-Kata!

Der Ton macht die Musik – das Wort macht die Geschichte

Visual Studio öffnen, Projekt anlegen, Referenz hinzufügen, los geht’s! Äähhh… wohl doch nicht… wie schreibt man eigentlich Spezifikationen im Code? Also Finger wieder weg von der Tastatur und überlegen, um was es eigentlich geht. Ok, es geht um FizzBuzz. FizzBuzz ist ein Spiel mit Spielregeln – das ist es im Endeffekt, worum es hier geht. So eine Spielregel ist recht einfach, denn es gibt zu einer bestimmten Spielsituation – sagen wir mal zu einem bestimmten Kontext – immer eine Regel, die man anwenden muss, damit man weiter im Spiel bleibt. Anders ausgedrückt ist bei einer Spielsituation zu prüfen, ob die Regel richtig angewendet wird – ob also die Erwartungen an das Spielverhalten erfüllt werden.

Aha – so ist das also. Hört sich vielleicht etwas abgedreht an, aber dieses kurze Repetitorium hilft beim Schreiben der ersten Spezifikation ungemein. Denn NSpec kennt zwei Attribute, namentlich [Context] und [Specification]. Mit der kleinen o.g. FizzBuzz-Geschichte macht das auch Sinn, wie man dann auch im Code sehen kann:

using NSpec.Framework;

namespace FizzBuzzNSpec.Specs
{
    [Context]
    public class when_a_number_is_a_multiple_of_three
    {
        [Specification]
        public void then_translation_should_return_fizz()
        {
            Specify.That(game.Translate(6)).ShouldEqual("Fizz");
        }

        private readonly FizzBuzz game = new FizzBuzz();
    }
}

Anderes Framework, andere Sitten

Die Konsequenz dieser Verbalisierung und Strukturierung ist zunächst einmal eine verbesserte Lesbarkeit. Weiterhin fällt auf, dass es nicht mehr eine einzige “Testklasse” gibt, sondern 4 verschiedene Spezifikationsklassen. Für jede Spielregel eine. Das Stukturierungssystem ist zwar mit klassischen Test-Frameworks auch möglich, wird aber nicht so offensichtlich “verlangt” wie es das BDD-Test-Framework NSpec hier tut.

Den Code für die anderen Spielregeln spare ich mir – es sieht dem o.g. Beispiel sehr ähnlich :-). Hat man erst einmal das “sprechendere” schreiben der Tests bzw. Spezifikationen verinnerlicht, geht es mit NSpec auch zügig voran. Schade ist hier die fehlende Integration und Unterstützung für Visual Studio und die üblichen Code-Assistenten. Mir blieb also nichts anderes übrig, als in der Konsole meine Tests auszuführen. Das hat mich beim implementieren schon gebremst.

Bewertung

• Dauer
  Naja, knapp 15 Minuten für FizzBuzz ist doch schon dreimal länger als mit NUnit. Die mangelnde Integration und die 4 Klassen machen schon etwas aus.
• Größe
  Statt wie bei den “Klassikern” 4 Methoden sind es nun 4 Klassen. Schon etwas mehr Code – hält sich aber noch “in Grenzen”.
• Tooling
  Schlecht. Der Runner ist dabei – das war’s.
• Usability
  Geht so. Die Assertions mit Specify reichen für die gröbsten Fälle aus.
• Support
  Die Entwicklung von NSpec ist eingestellt. Support damit auch. Zukunftssicherheit ist etwas anderes.

NSpec for a taste of BDD

NSpec – ein Vorreiter im .NET-Bereich was BDD angeht. Man merkt dem Framework deutlich an, dass es ein “erster Wurf” von der Adaption der BDD-Methodik ist. Nichtsdestotrotz ist as Framework schlank, stabil und gut anwendbar. Es zeigt schon in der Anwendung, wie das “System BDD” die Herangehensweise an die Spezifikation und Verifikation von Code ändert. Man beschäftigt sich automatisch mehr mit Kernaussagen und ist “gezwungen”, sich deutlicher und expliziter in der Domänensprache zu artikulieren. NSpec kann diesen systematischen Aspekt transportieren, ist aber mittlerweile auf Grund der mangelnden Integration und des fehlenden Supports nicht mehr für “Real-World”-Projekte ernstzunehmen. Trotzdem hat mir der Ausflug mit NSpec Spaß gemacht. Da bekomme ich glatt Lust & Laune mir schon das nächste Framework anzuschauen. Stay tuned!

Ein Bereich, den ich mir dabei näher angeschaut habe ist das Tooling. Ich wurde in der Vergangenheit schon öfters gefragt, welches Test-Framework ich denn einsetze. In letzter Zeit werde ich aber auch ab und an gefragt, welches Test-Framework denn jetzt besser sei. Als Hilfestellung zur Findung einer Antwort auf diese Fragen sowie einen Überblick über die gängigsten Test Frameworks soll dieser Artikel beitragen.

Die Kandidaten

Mit diesem Artikel beginnt die kleine Blog-Serie “Meta-Test”, die Stück für Stück die populärsten Test-Frameworks für .NET und C# unter die Lupe nimmt, sie bewertet und natürlich auch vergleichen wird. Bisher gab es schon folgende Tests:

• MS Test – Visual Studio On Board Test-Framework
• NUnit – All-Time-Hall-Of-Fame-Most-Valueable-Tester
• NSpec – der spezifizierende BDD-Veteran

Die Hypothese

Vorab möchte ich allerdings noch eine – für mich wichtige – Anmerkung äußern. Beim Test der Testframeworks habe ich mehrere Code Kata’s mit allen Frameworks geschrieben. Am häufigsten habe ich wohl FizzBuzz geschrieben, gefolgt von Replacer, LineCounter und ein paar Mal Minesweeper. Ich habe dabei schon deutliche Unterschiede nicht nur in den Frameworks, sondern auch in der Adaption selbst festgestellt. Für den hier gezeigten Vergleich gelten folgende Hypothesen:

• TDD & BDD sind gleichwertig.
• TDD & BDD sind prinzipiell das Gleiche, mit Unterschieden in Benennung und Teststruktur
• TDD & BDD wendet man für die selbe Aufgabe an, zum Software-Design

So, und jetzt der Disclaimer:
Achtung: Die genannten Hypothesen sind nicht meine Meinung über TDD bzw. BDD!

Ganz im Gegenteil. Ich habe zu TDD ein gefestigtes Meinungsbild. Ich habe auch Erfahrung mit BDD. Gerade deswegen bin ich sehr vorsichtig mit beiden Begriffen. Ich denke, TDD und BDD sind nicht das Gleiche. Doch eine weitere Vertiefung in das Thema lenkt nur von den Frameworks ab. Deswegen wieder schnell zurück zu den Test-Frameworks.

Die Anforderungen

Als Entwickler möchte man ein möglichst effektives und intuitives Test-Framework als Werkzeug, um testgestriebenes Softwaredesign durchzuführen. Beim programmieren mit Visual Studio zum Beispiel, wenn man die Tests für die gerade zu entwickelnde Klasse oder Methode formuliert, da gehört die Unterstützung von Tools wie Resharper, CodeRush oder Gallio heutzutage schon zum guten Ton.

Ebenso geht es bei dem Vergleich um die Anwendbarkeit und Effizienz. Also wie expressiv, wie deutlich kann ich meine Tests formulieren und wie intuitiv ist die Umsetzung der Tests. Die Umsetzungsgeschwindigkeit spielt dabei genauso eine Rolle wie die Lesbarkeit, Wartbarkeit und gutes Reporting. Dazu noch später mehr.

Das Ziel

Um auch eine konkrete, relativ faire Vergleichssituation zu erreichen, stelle ich alle Frameworks an einem einzigen Beispiel vor, nämlich dem KataFizzBuzz. FizzBuzz ist eine sehr einfache Kata, die gerade genug “Widerstand” bietet, um die Grundzüge des treibenden Software-Designs sowie des Test-First zu vermitteln. Ich habe mich bei der Programmierung der Kata sogar nur auf das Teilproblem der “Fizz”- und “Buzz”-Übersetzung konzentriert. Es gibt unzählige Implementierungen von FizzBuzz. Bei dem Vergleich der Test-Frameworks habe ich mich für die “triviale” und “zügige” Implementierung entschlossen. Konkretisiert bedeutet dies, das es mein Test-Ziel war, das ich mit allen Test-Frameworks ungefähr folgenden Code produziere:

    public class FizzBuzz
    {
        public string Translate(int number)
        {
            if (number % 15 == 0)
                return "FizzBuzz";

            if (number % 5 == 0)
                return "Buzz";

            if (number % 3 == 0)
                return "Fizz";

            return number.ToString();
        }
    }

Die Metriken

Um nun die einzelnen Frameworks untereinander vergleichen zu können, braucht es nicht nur einer gemeinsamen Basis & Ziels, sondern auch einer gemeinsamen Messmetrik. Um es nicht zu theoretisch zu gestalten, habe ich einige ganz einfache, aber wie ich finde dennoch aussagekräftige Metriken ausgewählt:

• Die Dauer der Implementierung
• Die Größe der Test-Artefakte (Klassen usw.)
• Das Tooling, also die Unterstützung durch VS / Frameworks / Codetools
• Die Usability, also handbuchnachschlagefreie Handhabung der API / Tools
• Der Support durch Hersteller, Community und User

Doch die wichtigste Metirk ist mit Abstand die Bewertung des Ergebnisses der Test-Frameworks – also der Tests ansich. Die Tests werden unter die vier Grundmerkmale Intuitivität, Expressivität, Lesbarkeit und Wartbarkeit gestellt. Natürlich bleibt da meine eigene subjektive Note an der ein oder anderen Stelle hängen, schließlich habe ich die Frameworks eigenständig getestet und habe auch keinen Anspruch auf gestelzte Objektivität :-).

So, damit sollten die Vorbereitungen und Rahmenbedinungen für den ultimativen Vergleich der Test-Frameworks für das .NET Framework & C# abgeschlossen sein. Dieser gigantische Vergleich von einer Unmenge an Test-Frameworks – für den ich keine Kosten und Mühen gescheut habe :-) – wird als Blog-Post-Serie in den nächsten Tagen veröffentlicht.

Stay tuned!

Um beim Bild der Rateshow zu bleiben, muss es natürlich auch eine Frage und vier Auswahlantworten geben.

Was verstehen Sie unter BDD ?

• A: BDD ist TDD, nur besser
• B: BDD ist etwas anderes als TDD
• C: BDD ist TDD, und noch viel mehr
• D: BDD ist der Bundesverband Deutscher Detektive

Ich bin gespannt auf die Bewertung des Publikums (gerne auch mit Begründung). Deine Meinung zählt! Ach ja, Frei nach Sigi Schwarz kann natürlich auch jede Antwort genannt werden, die nicht in der Auswahl genannt wurde (also ‘was zum Naschen!)

Nun, vor genau 10 Jahren (Frühjahr 2000) habe ich erstaunlich vielschichtiges getan. Da bin ich selbst schon überrascht. Ich habe z.B. einen HTML-Editor (versucht) in VB6 zu programmieren. Und habe ich einen PDF-Scanner in C geschrieben (um Bilder bzw. 2D-Polygone aus dem PDF zu “extrahieren”). Doch beides möchte ich hier nicht vorstellen, sondern ein ganz anderes Programm, mit vorerst letztem CVS-Commit am 15.03.2000: ScanDirNavian.

ScanDirNavian ist ein kleines Ameisenprogramm in VB6. Es durchforstet einen gesamten Verzeichnisbaum auf bestimmte Dateien (mit bestimmten Patterns im Dateinamen) und listet diese in einer Logdatei auf. Als Zusatzfeature kann es nicht nur die Dateiinformationen loggen, sondern auch einfache Transformationsaufgaben erledigen. Z.B. “Nehme die ersten 3 Zeichen des Dateinamens, falls es eine Zahl ist, stelle Sie an das Ende des Dateinamens.”

Ich bin mir nicht mehr sicher, welchen Zweck ich damit eigentlich bedient habe. Ich kann mich vage daran erinnern, dass ich tausende von Logdateien (von Linux, Raytracern und diversen anderen Programmen) irgendwie umstrukturieren bzw. in andere Verzeichnisstrukturen überführen wollte. Ein Codeschnipsel gefällig? Bitte gerne:

Private Sub CommandScan_Click()
    Dim StartDirectory As String
    Dim ScanTimeString As String
    AllFileCounter = 0
    AllScanTime = 0

    StartDirectory = DirSource.Path
    LabelInfo.Caption = "Scanning Directory" & vbCrLf & vbCrLf & _
        StartDirectory & vbCrLf & vbCrLf & _
        "Please wait until scan is complete."
    TabLog.Tabs(3).Selected = True
    FormMain.MousePointer = 11
    TimerScanDuration.Enabled = True
    DoEvents

    If InStr(TextHeader.Text, LogTypeCommand(7)) > 0 Then
        TextHeader.Text = _
            Left(TextHeader.Text, _
            InStr(TextHeader.Text, LogTypeCommand(7)) - 1) & _
            DirSource.Path & _
            Right(TextHeader.Text, Len(TextHeader.Text) - _
            InStr(TextHeader.Text, LogTypeCommand(7)) - _
            Len(LogTypeCommand(7)) + 1)
    End If
    If InStr(TextHeader.Text, LogTypeCommandShortCut(7)) > 0 Then
        TextHeader.Text = _
            Left(TextHeader.Text,
            InStr(TextHeader.Text, LogTypeCommandShortCut(7)) - 1) & _
            DirSource.Path & _
            Right(TextHeader.Text, Len(TextHeader.Text) - _
            InStr(TextHeader.Text, LogTypeCommandShortCut(7)) - _
            Len(LogTypeCommandShortCut(7)) + 1)
    End If

    If Len(TextLog.Text) = 0 And Len(TextHeader.Text) > 0 Then _
        TextLog.Text = TextHeader.Text & vbCrLf & _
        String(Len(TextHeader.Text), "-") & vbCrLf & vbCrLf

    ScanDirectory DirSource.Path, TextOutput.Text
    DirSource.Path = StartDirectory
    TimerScanDuration.Enabled = False

    FormMain.MousePointer = 0
    ScanTimeString = Trim(Str(AllScanTime / 10))
    If Left(ScanTimeString, 1) = "." Then ScanTimeString = "0" & ScanTimeString
    LabelInfo.Caption = "Scan complete !" & vbCrLf & vbCrLf & _
        "Successfully passed through " & Trim(Str(AllFileCounter)) & " files." & _
        vbCrLf & "Elapsed time: " & ScanTimeString & " seconds."
End Sub

Oh je, da habe ich mich nicht gerade mit Ruhm bekleckert :-) Funktioniert hat es – Ja. Aber lange zufrieden war ich auch nicht damit. Immerhin hat es seinen Zweck erfüllt.

In vielen Fachblättern und Artikeln wird eine Sprintdauer von 30 Tagen (4 Wochen) vorgeschlagen. Manchmal findet man auch 2-4 Wochen als empfohlene Sprintdauer. In jedem Fall aber sollte die Sprintdauer stabil über Sprints hinweg bleiben.

Mein Einwand: Die Sprintdauer ist eine Schwachstelle in Scrum. Besser gesagt: lange Sprintzyklen sind eine Gefahrenquelle für den Erfolg von Scrum-Teams. Denn gerade lange Sprintzyklen sind für die meisten Teams der erste große Fallstrick. Die meisten Teams, die mit Scrum beginnen, fangen mit langen Sprints von 4 Wochen und z.T. sogar mehr an. Schwierig in mehrfacher Hinsicht, denn dadurch berauben sie sich eigenmächtig der Vorteile agiler Verfahren. Die Flexibilität wird eingeschränkt, die Feedbackschleife des Inspect & Adapt wird verlängert und dem Team wird hohe Planungskompetenz bzw. -verantwortung aufgebürdet.

Was kann man tun um diesen Risiken entgegenzuwirken? Ganz einfach: Kurze Sprints! Mit kurzen Sprints meine ich auch kurze Sprints. Aus meiner Sicht ist die ideale Sprintdauer eine Woche lang. Ja, richtig gelesen, nur 5 Werktage! Jede Woche Planung, jede Woche Review, jede Woche Retro.

Daily Scrum, Weekly Sprint

Was erreicht man dadurch? Zunächst einmal schafft man durch so eine kurze Sprintdauer eine hohe Planungsfrequenz. Das ist für fast alle Beteiligten nur von Vorteil. Der PO hat hohe Flexibilität, während das Team einen sehr überschaubaren Planungszeitraum hat. Das Team geht genauer auf die Stories und das Design ein, bricht in der Planung genauer Tasks auf. Dadurch ergeben sich quasi automatisch verbesserte Schätzung und stabiles Commitment. Das wiederum stärkt die Vorausplanung und Releaseabstimmung auf der Product Owner-Seite.

Ein-Wochen-Sprints bedeuten aber auch schnelleres Inspect & Adapt. Jede Woche gibt es eine Retrospektive, das wichtigste agile Gremium in Scrum. Jede Woche eine Retrospektive zu haben ist ein wenig wie “und wöchentlich grüßt das Scrumeltier” – es kommen Anfangs immer wieder die gleichen Themen ins Gespräch. Das liegt vor Allem daran, dass es viel einfacher ist, wöchentlich “inspect” zu betreiben, als effektiv “adapt” durchzuführen. Doch genau das ist das schöne am schnellen, wöchentlichen Sprint-Puls. Es wird die Agilität förmlich “antrainiert”. Das Team lernt wesentlich schneller, wirklich zu adaptieren, anstatt es irgendwie auf die lange Bank zu schieben.

“Accelerate” für eine gute “Velocity”

Ein nicht ganz auf den ersten Blick erkennbarer Vorteil der Wochensprints ist der schnelle “Ramp-up” des Teams zur stabilen Velocity. Während ein Team mit 4-Wochen-Sprints nach den ersten 3-5 Sprints (also nach 3-5 Monaten!) erst so halbwegs stabile Produktivität und Schätzkompetenz aufweisen kann, gelingt einem Team mit Wochensprints nach der gleichen Sprintzahl (also nach 3-5 Wochen) noch mehr. Ergo: Ein zügiges Teaming wird erreicht.

Gerade Wochensprints haben meiner Meinung nach die Bezeichnung “Sprint” verdient. Denn wöchentliche Iterationen “fühlen” sich nicht nur wie ein Sprint an, sondern sind auch so intensiv und ergiebig wie ein Sprint. Das liegt nicht nur am höheren Takt, sondern auch an einer ganz lapidaren Tatsache: Die Arbeitswoche.

Unsere gesamte Lebens- und Arbeitskultur tickt in diesem “Wochentakt”. Viele denken, planen und organisieren in Wochenzyklen. Das kommt auch dem wöchentlichen Scrumsprint zu Gute. Teams mit Wochensprints kommen mit dem Wochentakt “einfach besser zurecht” – wissentlich oder unwissentlich. Höchstwahrscheinlich ist dies dem Fakt geschuldet, dass die gesamte Arbeitswelt sich an diesem Takt orientiert. Egal ob nun Scrum oder nicht, die Kalenderwoche ist und bleibt eine präsente Zeiteinheit, die für Planung, Vereinbarung und Organisation angewendet wird.

Kurz und Knackig

Bei all den Vorteilen, die eine kurze, nach meinem Ermessen am Besten wöchentliche Sprintdauer hat – es gibt auch hier wieder einige Dinge, die man vor der Einführung oder beim “Sprinten” beachten sollte. Ein allgemeiner Fallstrick kann es werden, die Planung des Sprints auf den Montag zu legen, und die Retrospektive auf den Freitag. So wie es bei klassischen Jour-Fixe Meetings zum guten Ton gehört Planungsgespräche an das Ende der Woche zu legen, ist das bei Wochensprints auch förderlich. Eine mögliche Variante wäre es, die Planung auf den Freitag zu legen und Review/Retro auf Montag.

Damit ist der nächste Achtungspunkt schon implizit genannt: Nicht versuchen, alle “Scrum-Meetings” in einen Tag zu quetschen. Ganz im Gegenteil, die Planung kann Freitag vormittags erfolgen. Der Nachmittag ist reserviert für Konzentrationsarbeit, Tageskommunikation, Vorbereitung des Boards und des Reviews / Retro’s.

Montag ist vormittags “Tabu” – denn genau dann befindet man sich in der “Twilight Zone”. Ende des letzten Sprints oder Anfang des nächsten Sprints – schon durch die Planung oder noch im Review – noch Montagsmüde oder schon im Tatendrang – ein Montag Morgen eben. Der späte Nachmittag kann dann nach dem üblichen Daily für die kurze Review/Retro investiert werden. Bei Wochensprints ist eine 4 stündige Planung angemessen, eine Review/Retro von einer Stundes komfortabel ausreichend.

Fazit: Kurz & Knackig – das ist die bessere Sprintdauer in Scrum!
Es gibt natürlich noch mehr Aspekte als die aufgeführten, um zu einer ausgewogenen Sprintdauer für sein Team zu kommen. Für mich bleibt jedoch die in den meisten Fällen zutreffende Erkenntnis: Kurz & Knackig ist besser als Lang & Weilig. Was denken Sie? Ihre Meinung ist gefragt!

Massiv Sportlich

Schon das letzte Münchener .NET Coding Dojo im Februar war wieder eine spannende und anregend erkenntnisreiche Veranstaltung. Das Lösen des KataTennis hat sich als eine wunderbare Übung für den überlegten, soz. “wohl bedachten” einsatz von Test-Driven-Design und -Development herausgestellt.

TDD kann viel im Design und in der Implementierung bewirken. Es fördert lose Kopplung, gestaltet aktiv die Trennung der Verantwortlichkeiten mit und unterstützt das minimalistische “DRY“-Denken. Es gibt auch frequentiven Feedback in der Entwicklung. Sei es nun, dass man sich auf dem grünen Pfad bestätigt fühlt – oder aber frühzeitig “riecht”, das da etwas nicht ganz ausgereift ist. In jedem Fall war KataTennis im Februar-Dojo eine schöne Aufgabe, die all diese Faktoren präsentierte. Mehr noch, das Dojo zeigte, dass es sich lohnt, die Analyse der Problemdomäne nicht außer Acht zu lassen. Der Code lässt sich wie immer auf dem Codeplex-Projekt einsehen.

Massiv Interessant

Doch das war noch lange nicht alles, was sich zum Thema .NET Coding Dojo im Februar getan hat! Vorreiter war schon im Januar die .NET User Group Karlsruhe mit einem .NET Coding Dojo der “Schwarzgurt-Klasse”. Es wurde KataPotter angegriffen. Die DNUG hat gespürt, dass ein Coding Dojo schweißtreibend ist – aber auch spannend und fesselnd. Denn schon einen Monat später gab es in professionell agiler Manier eine Retrospektive zum Coding Dojo. Die DNUG Karlsruhe bleibt also am Ball!

Auch ich konnte noch einen kleinen Beitrag zur Coding Dojo Idee leisten, in dem ich auf der diesjährigen VSOne das Format und die Ziele des .NET Coding Dojo vorgestellt habe. Doch bei der Vorstellung alleine bleibt es bei Dojojanern natürlich nicht – in der Session wurde demonstrativ ein “Mini-Dojo” mit KataFizzBuzz gestartet. Es war eine wunderbare Erfahrung, wie interessiert und motiviert unvoreingenommene Teilnehmer im Coding Dojo mitmachen. Danke für das zahlreiche Interesse!

Im Übrigen möchte ich dabei noch betonen, dass die diesjährige VSOne eine wirklich gelungene und qualitative Veranstaltung gewesen ist.

Last but not least: Die .NET Coding Dojo-Idee ist grenzübergreifend! Angespornt und motiviert durch die Events in Deutschland gab es im Februar auch ein eigenständig von Andreas organisiertes .NET Coding Dojo in Wien! Es wird also auch schon in Österreich kräftig trainiert. Kurzum: Massiv Interessant!

Massiv Im März

Natürlich steht auch schon das nächste Münchener .NET Coding Dojo vor der Tür. Am 10. März erwartet die Teilnehmer ein Coding Dojo der Extra-Klasse. Im März-Dojo werden die gebündelten Kräfte und Kompetenzen von .NET Enthusiasten, Software-Entwicklern & TDD-Interessierten gebraucht. Soviel sei schon vorab verraten: dieser Coding Dojo wird eine Herausforderung!

Im “Massiv-Im-März” Coding Dojo werden wir drei spannende Code Kata’s im Angebot haben, die wieder besondere Techniken sowie Praktiken fordern und fördern. Es geht dabei um Analyse, Design und Implementierung gangbarer, nachhaltiger, effektiver Lösungen zu einem kleinen Programmierproblem. Kurzum: Gemeinsam lernen & lehren von profesioneller Software-Entwicklung mit TDD, CCD und Design Patterns.

Was heißt das? Ganz einfach – auf geht’s zum Dojo! Anmeldung per Xing Event oder Facebook Event!

Übrigens, ein schöner Zufall will es, dass das Münchener .NET Coding Dojo parallel zu den Tagen des dotnetpro.powerday stattfindet. Wer es noch nicht weiß, in den dotnetpro.powerday zeigen Ralf & Stefan auf Ihre gewohnt einprägsame Weise, welche Werte, Prinzipien & Praktiken es bedarf, um nachhaltigen, wartbaren und erweiterbaren – also Clean Code zu schreiben. Die frisch gewonnen Erkenntnisse kann man dann natürlich bei uns im Coding Dojo einsetzen! :-)

1. Rahmenwerk, aber kein Werkzeug
2. Die Sprintdauer
3. Die Planung & Das Design
4. Der Scrum Master
5. Die Skalierung

Scrum ist ein wunderbares agiles Management-Framework. Ich mag Scrum. Um ehrlich zu sein ist Scrum als “Agile für Einsteiger” ein genauso geeignetes methodisches Rahmenwerk wie für den enthusiastischen Agilisten. Ich habe mittlerweile einige Jahre Scrum-Erfahrung und darf mich ja selbst als “Zertifizierter Scrum Master” bezeichnen. Trotzdem – oder gerade aus dieser Erfahrung heraus – ist Kritik an Scrum meines Erachtens angebracht. Die kritischen Stimmen zu Scrum werden immer deutlicher, allen voran die erst kürzlich von UncleBob aufgestellten 7 Thesen der Mängel von agiler Software-Entwicklung mit XP & Scrum. In diesem Artikel möchte ich dazu meine Sicht der Dinge wiedergeben.

Scrum ist nicht Perfekt. Ganz im Gegenteil. Mit steigender Erfahrung kann man z.T. gravierende Schwachpunkte in der Methodik feststellen. Das soll jetzt nicht heißen, daß Scrum für ein agiles Projekt zu schlecht oder ungeeignet wäre – Nein. Vielmehr sollte man bei der Anwendung von Scrum ein besonderes Augenmerk auf die Schwachpunkte der Methode legen – um so im Ergebnis weniger Stolpersteine auf dem Weg zum Projektziel zu haben.

Rahmenwerk, aber kein Werkzeug

Scrum ist ein Framework. Nicht für Software-Entwicklungs-Methoden, sondern für Projekt-Management. Doch als Framework für die Projekt-Management-Methodik ist Scrum in vielen Teilen zu unspezifisch. Natürlich ist Scrum gerade durch die wenigen Regeln & Rollen leicht verständlich und relativ zügig einsetzbar. Auf der anderen Seite jedoch ist die Eigenschaft von Scrum, eine “leichtgewichtige” Methodik des agilen Projektmanagements zu sein eine schwere Bürde – sei es inhaltlich oder praxisbezogen. Beispiele gefällig?

• Scrum verlangt Dailies am Scrum Board
  Scrum sagt aber nicht wie dieses Board denn verwendet werden soll, welches die primären Ziele des Boards sind und welche Mittel & Wege man hat mit dem Board umzugehen. Wie ist das mit dem Sprint Backlog auf dem Board? Wie werden die Stories abgearbeitet? Wie geht man mit Ausnahmen (z.B. Bugs) um? Scrum schlägt bei diesen Themen sehr leise Töne an.
• Scrum nennt Product & Sprint Backlogs
  Scrum verrät aber nichts über den Aufbau der Einträge der Backlogs. Ein Product-Backlog ist eine “Wunschliste”, ein Sprint-Backlog ist eine “Taskliste”. Pofessionelle Agilisten belächeln mittlerweile die flachen Scrum-Backlogs und deren mangelhafte Vorgaben.
• Scrum hat ein Sprint-Planungs-Meeting
  “Gut, daß man bei Scrum auch plant” mag es einem in den Sinn kommen. Doch in Scrum konzentriert sich die Planung zumeist auf ein einziges Meeting, in dem der gesamte, meist 4 Wochen lange Sprint und die in dieser Zeit zu erstellenden Features designed & geplant werden. Software-Entwickler mit gesundem Respekt gegenüber der Ingenieurskunst des “Software Engineerings” würden mit großer Wahrscheinlichkeit so eine Vorgehensweise als “unausgereift” bezeichnen.

Die Sprintdauer

Scrum baut auf Mikro-Organisation. Tägliche Einsatzbesprechung, Aufgabenverteilung und Updates. Scrum stützt dadurch Agilität. Anforderungen können sich ändern, unbedachte Situationen können eintreten. Darauf kann Scrum reagieren mit den Sprints, die die Gesamtleistung in viele kleine Schritte zerlegen. Hier, genau bei den Sprints (Iterationen) und deren Dauer ist die Methodik (bzw. die Umsetzung von Scrum) zumeist deutlich mangelhaft.

Wieso? Scrum schlägt eine Sprint-Dauer von 2-4 Wochen vor. Vorzuziehen sei eine kürzere Sprintdauer, maximal sollte sie jedoch 4 Wochen sein. Doch für ein Rahmenwerk, welches sehr stark auf die Mikro-Organisation fokussiert ist, sind 4 Wochen eine lange Zeit. Denn in der Praxis gibt es wenige Scrum-Projekte, die wirklich den 2-Wochen-Takt implementieren. Die Gründe dafür sind vielfältig. Einer der Hauptgründe ist wohl der Schwenk von einer “klassischen” Projektplanung hin zum agilen Management. In so einem Kontext tendiert man lieber zur 4 Wochen Zeitspanne, weil

• man angeblich mehr Zeit zum implementieren hat;
• angeblich alle 2 Wochen ein ganzer Tag Team-Meeting “ineffizient” ist;
• die wenigsten Anforderungen eines Produktes in 2 Wochen einsatzfähig fertiggestellt werden können.

Im Grunde mehr oder minder schwachbrüstige Argumentationen. Als Randnotiz: meine persönliche Ansicht ist bei diesem Thema ist noch fordernder als die der reinen Scrum-Lehre: 2-wöchige Sprints sind gut, Wochen-Sprints noch viel besser.

Lange Sprintzyklen wirken für agile Verfahrensweisen wie eine angezogene Handbremse. Einen 4-Wochen-Sprint in 4 Stunden Sprint-Planungs-Meeting zu planen ist gelinde gesagt tollkühn. Bei langer Sprintdauer ist die Zahl der Stories und Tasks auf dem Board meist unbeherrschbar. Mehr noch, bei 4 Wochen schleichen sich gerne andere, minder relevante Aufgaben wieder auf’s Board.

Die Releasefähigkeit wird stark eingeschränkt und das obere Management durch die langen Sprintzyklen implizit dazu aufgefordert, mehr “Termin-Management” und Koordinationsleistung zu betreiben. Die empirische Messung der Velocity und die Schätzgenauigkeit des Teams ist mit langen Sprints von deutlich geringerem Wert und Aussagekraft als bei (sehr) kurzen Sprints.

Die Planung & Das Design

In den vorangegangenen Punkten ist dieser Makel schon ein wenig angeklungen; Planung & Design in Scrum sind unfassbar – im wahrsten Sinne des Wortes. Wer schon einmal vor der Aufgabe stand, in einem Sprint-Planungs-Meeting mit den anderen dutzende Stories “implementierungsreif” zu planen & zu designen, der kann sich denken, worauf ich hinaus möchte.

Doch vor der Betrachtung und Kritik am “Planungs-Meeting” möchte ich die generell mangelhafte Planungssituation von Scrum nicht unerwähnt lassen. So sucht man in der Scrum-Methodik vergebens unterstützende Merkmale zu adequater Business-Analyse und der anschließenden Anforderungs-Analyse. “Ohh” – wird sich jetzt manch einer denken – “Ist dass denn dann noch agil?”. Antwort dazu: Es wäre für die Vertreter der agilen Software-Entwicklung schlichtweg ein Debakel, wenn eine wichtige Disziplin des Software Engineerings nicht agil betrieben werden könnte.

In der Praxis wird Scrum leichtsinnig und konzeptfrei mit allem möglichen “agilen Zubehör” bepackt. Da gibt es dann User Stories, Planning Poker, Story Points, Estimation Meetings, Business Value Estimations und vieles mehr. Aus Sicht der Prediger der Scrum-Fibel auch durchaus verständlich, schließlich sei “Scrum ja auch nur ein Rahmenwerk” (siehe 1. Schwachpunkt).

Doch zurück zum Thema Planung & Design von Software und Software-Entwicklung. Man mag wieder argumentieren, das habe nichts mit Scrum, dem Management-Rahmenwerk, zu tun. Dies wäre eine fadenscheinige, viel zu oberflächliche Argumentation, denn auch Management-Methoden sollten die Problemstellungen Ihrer Domäne (hier: Software-Entwicklung) stützen, fördern und verwalten können.

Scrum will dies mit dem Sprint-Planungs-Meeting erreichen. Bedauernswerter Weise in vielerlei Hinsicht inadequat. Was in den Lehrbüchern zu Scrum so einfach klingt, ist in der Praxis kaum durchführbar. Zum Einen ist es eine schier berzerrte Wahrnehmung der Realität anzunehmen, dass eine Gruppe von Software-Entwicklern innerhalb von 4-8 Stunden die meist dutzenden Anforderungen für die nächsten paar Wochen “durchdesignen” können. Zum Anderen soll in diesem Meeting so viel wie möglich an offenen Punkten bzgl. der Anforderungen geklärt werden (um der oft mangelnde Anforderungsanalyse entgegenzuwirken).

Bei aller Liebe zu “Embrace Change” – die Sprint-Planung stellt bei vielen Scrum-Teams mit langen Sprintzyklen eine unvollständige “Erstanalyse” der Geschäftsanforderung dar. Aus einer solchen Besprechung eine adequates und professionelles Software-Design zu verlangen, ist schlichtweg naiv. Für viele, angebliche “Agilisten” ist die Sprint-Planung ein Alibi für Design & Planung. “Ja, wir haben doch schon im Planning darüber nachgedacht – das reicht”. Andere wiederum kommen mit der hochkomprimierten, verlustbehafteten Planung wenig zurecht und lagern in der Planung noch kräftig Analyse-Tasks, Design-Tasks, Dokumentations-Tasks nach. Sogar Analyse-Stories bis hin zu ganzen Analyse-Sprints oder Refactoring-Sprints sind schon gesichtet worden. “Willkommen zurück im Wasserfall” kann man da nur sagen.

Der Scrum Master

Mit dem Scrum Master wird ein heikles Kapitel der Schwachpunkte von Scrum geöffnet. Denn der Scrum Master – als Rolle versteht sich – mag auf den ersten Blick alles andere als eine Schwachstelle in der gesamten Methode verstanden werden. Scrum versteht den Scrum Master als “Facilitator”, als “Change Agent”, als “Servant Leader” – was für lobenswerte Werte. Eine Hymne, die auf den Scrum Master gesungen wird. Er überwacht die (wenigen) Scrum-Regeln, er schafft “Impediments” aus dem Weg, er fördert “die gesunde Veränderung” und moderiert durch die Meetings. Ein smarter Typ, dieser Scrum Master.

Doch der Schein trügt. In der Realität ist der Scrum Master oft keines von all den genannten Dingen. In den meisten Unternehmen ist der Scrum Master Nachfolger des klassischen Projekt-Managers. Er schmückt sich mit der Feder des “Change Agents”, nimmt aber aktiven Einfluß auf Planung, verteilt Tasks & Aufgaben, zweifelt Entwicklungsaufgaben an, mahnt bei Refaktorisierungsaufgaben zur Beachtung des “Business Values” und erklärt sich selbst zum “Manager des Teams”.

Andererseits ist der Scrum Master oft V-Mann und Sklave des konservativen Managements. Er wird genötigt, Aussagen über Releasepläne zu geben, Executive Reports zu erstellen, die Zeiterfassung für die Bilanzierung zu erledigen und gleichzeitig (parallel zur “modischen, agilen Methode”) noch Projektpläne zu erarbeiten, in denen penibel Zeitabläufe, Ressourcen & Meilensteine durchgeplant werden.

Der Scrum Master kann auch ein Entwickler sein, der sich dann auserkoren fühlt und Review-Pate spielt. Er ändert Tasks, ist bei Estimations der Führende und setzt den anderen “seinen Programmierstil” (unbewußt) vor die Nase. Er ist meist zu unkooperativ gegenüber dem Product Owner und pocht auf die “Einhaltung von Abmachungen” (Contracting), anstatt den Aspekt für das Geschäft im Auge zu behalten.

All diese Dinge sind kontraproduktiv für das eigentliche Ziel – eine koordinierte, produktive, agile Software-Entwicklung. Es gibt ganz wenige, um nicht zu sagen äußerst selten anzutreffende Scrum Master, die Agilität & Professionalität in Einklang bringen und die überspitzten, gar realitätsfremden Scrum-Prädikate “Alles-Könner”, “Jeden-Versteher” und “Komplett-Überblicker” erfüllen.

Die Skalierung

Ein offensichtlicher Schwachpunkt von Scrum ist die Skalierung. Scrum in seiner ersten und “reinen” Form ist eher für ein einzelnes Team konzipiert – maximal ein paar Teams. Aber Scrum im Großen, “Scrum in the Enterprise” – das ist dann schon eine etwas andere Sache. Klar, es gibt “Scrum of Scrums” und “Company Backlogs”. Dennoch ist bei Scrum die Integration von ganzen Abteilungen, die Organisation von dutzenden Teams und Koordination zu einem größeren Produkt ein Punkt, der in den Lehrbüchern nur mit der magischen “unsichtbaren Tinte” zwischen den Zeilen geschrieben zu sein scheint.

Ominös umnebelt sind hierbei besonders die Themen Synchronisation und Team-Aufteilung. Sind die Teams jetzt funktional (z.B. ein B2B und ein B2C-Team) oder horizontal (z.B. UI-Team, DWH-Team) oder vertikal (z.B. CMS-Team, CRM-Team) oder kann doch jeder alles? Sprintet jeder synchron? Gibt es einen Release-Plan oder mehrere? Wie können die Ergebnisse zusammengeführt werden? Muss jedes Team einen eigenen Branch und eigenes Board haben? Kann ein Scrum Master drei Teams “betreuen”? Fragen über Fragen, auf die Scrum – wenn überhaupt – nur unscharfe Antworten gibt.

Das Dilemma

Es ist schon ein Dilemma. Scrum ist so verbreitet, weil es einfach ist. Es ist überschaubar und kann auf einem Bierdeckel zusammengefasst werden. Scrum ist so populär, weil es einen einfachen Start in die Agilität bietet. Scrum ist so erfolgreich, weil man damit Geschäfte machen kann. Scrum bringt dem Implementierenden auf mittlere Sicht mehr Produktivität und bietet den Unterbau für eine wesentlich flexiblere professionelle Software-Entwicklung. Nicht zuletzt profitiert auch die Unternehmens- und IT-Consulting-Branche von Scrum.

Doch Scrum ist weit mehr als das. Scrum ist unpräzise. Viele denken, sie praktizieren Scrum, dabei machen Sie kleine Wasserfall-Iterationen. Sie stehen an den Boards und berichten über Status und Aufwände, statt gemeinsam den “Einsatz des Tages” zu besprechen und zu planen. Einige verwalten Bugs am Board und haben eine “Ongoing-Tasks”-Zeile, andere wiederum Pochen auf Tickets, Zeiterfassung und “Live-Burndown-Charts”.

Scrum ist transparent. “Hört sich gut an” mag man denken. Das ist auch richtig, ist aber für prokrastinierende Entwickler-Veteranen und altgediente Unternehmens-Manager kein Spaß. Überwachungskultur und Big-Brother-Gefühle eingeschlossen. Politik und der staubige Filz von Konzern-Lobbyisten tragen dann dazu bei, daß “Agil” und “Scrum” mit “Planungslos” und “Chaotisch” substituiert und verunglimpft werden.

Scrum ist leider aber auch oftmals ein Ausreden-Paket für Entwickler. “Nein nein, das Board macht der Scrum Master”. Der Review? Macht der Scrum Master – der kann doch Powerpoint. Die Transparenz und die plötzliche Selbstorganisation schleudert so manchen festgefahrenen Entwickler aus seiner Bahn. Committed wird nur das nötigste. Ausserdem bestimmt ja das “Team” was gemacht wird oder nicht? “Bloß kein Stress” ist hier die Devise.

Die Qualitätsansprüche der modernen, agilen Software-Entwicklung werden oftmals mit dem Level-Of-Done wieder relativiert – wer braucht schon Dokumentation, Unit Tests oder Analyse? Im Übrigen, geplant wird mit einem Tag sowieso schon zu viel – ansonsten sei man “nicht agil”.

Um es etwas provokant auszudrücken: Scrum ist für Erwachsene.

Die oben genannten Mängel können gravierende Auswirkungen nach sich ziehen. Sie können Scrum-Projekte behindern. Ja, sie sind manchmal sogar Grund für das Scheitern von Scrum. Doch man kann diesen Schwachpunkten entgegenwirken. Und es sei nochmals daran erinnert: nur weil Scrum Schwachpunkte hat, heißt es nicht, daß es absolut ungeeignet ist, um agile Sotware-Entwicklung zu betreiben.

Konsequenterweise bleibt nach dieser mehr oder minder langen Kritikliste an Scrum eine große Frage offen: Was kann man tun, um diese Schwachpunkte zu eliminieren bzw. zu mitigieren? Die Antwort auf diese Frage ist – wie Scrum selbst – nicht so einfach wie es scheint. Dennoch würde ich eine Blog-Serie über Verbesserungsmöglichkeiten anstreben.

Haben Sie selbst die Erfahrung über die genannten Schwachpunkte gemacht? Gibt es Ihrer Meinung nach andere, schwerwiegendere Schwachpunkte? Wollen Sie mehr darüber erfahren, wie man den o.g. Schwierigkeiten entgegenwirken kann? Ihre Meinung ist gefragt!

Und das erste Münchener .NET Coding Dojo des Jahres startete wahrhaftig mit einem Paukenschlag! Erstmals überstieg die Teilnehmerzahl den Rahmen einer Dojo Session, so dass wir zwei Teams machen mussten (und wollten), die gegeneinander in einem “Dojo-Battle” antreten und ein Code Kata lösen sollten.

Nach einer kurzen Willkommens-Einwärm-Phase ging es auch schon zur Wahl des Code Kata’s für den Abend. Zur Auswahl standen KataBowling, KataMinesweeper und der KataLocCounter in der C# Variante. Nach der kurzen Vorstellung der Code Kata’s entschied sich die Dojo-Gemeinde für den KataLocCounter. Eine besonders erfrischende und spaßbringende Wahl, wie sich im Laufe des Abends herausstellen sollte.

Starke Teams denken, testen, zählen

Das Code Kata ist gewählt, die Aufgabe und Rahmenbedingungen erklärt, nun konnte es schon losgehen. Fast. Die Teams mußten noch formiert werden. Die wurden im Zählverfahren (wie denn sonst ;-)) aufgeteilt. Wie es der Zufall will, waren die Teamstärken gut verteilt.

Team 1 war stark besetzt mit der analytischen Expertise von Andre, den CCD- und .NET Guru’s Ralf und Stefan. Hinzu kamen erfahrene Dojojaner wie Thomas und Christina, gestärkt mit einem Dutzend weiterer .NET-Entwickler.

Doch wer nun dachte, Team 2 wäre schwächer aufgestellt, der irrte sich gewaltig. Christian, ein Dojo-Gänger der ersten Stunde und kraftvoll vorandesignender C# Architekt, der durch zahlreiche Dojo’s durchtrainierte Stefan, die geballte TDD/BDD-Erfahrung von Björn und ein starkes Dutzend .NET-Coder waren ein anspruchsvolles Lineup.

Die Teams waren aufgeteilt, das gedankliche Stretching und Warmup getan. Es konnte losgehen!

Jede Codezeile zählt

In einer ersten Phase wollten die Teams sich ein wenig detaillierter mit den Anforderungen an den Line-Counter auseinandersetzen, um eine “Design-Strategie” auszuarbeiten.

string code="Diese Zeile zählt!";
// Einzeilige Kommentare zählen nicht

// Dieser Kommentar und die leere Zeile davor zählen auch nicht
int count = 0; // Diese Zeile zählt natürlich!
bool countComments = false; /* Diese Zeile zählt auch */

/* So ein Kommentar
über mehrere Zeilen hinweg
zählt natürlich nicht als Code! */

Ein paar Kommentarbeispiele :-)

Interessante Erkenntnis hierbei: Man hat sich zwar mit den fachlichen Anforderungen und den daraus ergebenden Features bzw. Rahmenbedingungen auseinandergesetzt, dabei aber die Analyse und eine gemeinsame Implementierungsstrategie nicht wirklich erarbeitet. Geklärt war zumindest, dass es galt, Kommentare im Code zu erkennen und nicht mitzuzählen. Das Wie und eine gemeinsame Übereinkunft über die Strategie fiel bei beiden Teams “unter den Tisch”.

Doch das war offensichtlich zunächst nicht weiter schlimm, denn es schien erstmal wichtiger, das die Teams in den TDD-Rythmus kommen. Die ersten Tests gingen traditionell etwas schwerer vom Kopf in die Tastatur über, doch nachdem man sich auf den Happy-Pfad im Testing und eine inkrementelle Auslieferung des Programmes geeinigt hat ging es dann flotter.

Das Ergebnis innerhalb der Count-Methode des Team 1 war bis dato recht überschaubar:

            var lines = source.Split(new string[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries);

            return lines
                .Select(x => x.Trim())
                .Where(x => !String.IsNullOrEmpty(x))
                .Where(x => !x.StartsWith("//"))
                .Count();

Soweit so gut.

Stolperstein Block-Kommentare

Nach den einfacheren Fällen trafen beide Teams mit den mehrzeiligen Block-Kommentaren auf eine etwas härtere Nuss, die es zu knacken galt.

Wie sollte man denn die mehrzeiligen Kommentare erkennen? Vor Allem, wie sollte man dann mit besonders “außergewöhlichen” Kommentierungen umgehen?

int count = 1; /* mehrzeilige
kommentare können */ count++ /* herausfordernd sein */ ;

Außergewöhnliche Kommentare

An dieser Stelle holte die Teilnehmer die “zu kurze Analyse” zu Beginn wieder ein. Welche Strategie sollte man wählen? Die zeilenbasierte Verarbeitung aufgeben und zeichenbasiert arbeiten? Umschwenken auf schweißtreibende, aber mächtige Regular Expressions? Oder sogar eine Kombination von allem?

Das besondere und mich nicht überraschende: beide Teams wählten unterschiedliche Strategien. Während Team 1 die Eleganz des “Flows” der LINQ-Expression nicht aufgeben wollte und es mit Regular Expressions angereichtert hat, entschloss sich Team 2 für eine kleine Status-Maschine und einen Mix aus zeilen- und zeichenbasierter Verarbeitung.

Showdown

Nach knapp 3 Stunden war es dann soweit. Die Teams klopften die letzten Tests und Codezeilen ein, um sich dann im Schlußvoting dem gegnerischen Team zu stellen. Gespannt warteten die Teams auf den Code und die Resultate des Gegners.

Team 1 präsentierte zunächst das lauffähige Programm, danach das gute Dutzend Tests und den damit getriebenen Code. Auffällig: Der Code erschien dem Gegner auf den ersten Blick als kompakt und elegant.

Team 2 konterte prompt. Eine äußerst saubere Test-Suite, ein durch die differierende Implementierung etwas längerer Code und die Besonderheit, dass die Implementierung sogar (teilweise) Kommentar-Tokens innerhalb von Strings ignorieren konnte.

Ergebnis: Beide Lösungen waren unvollständig – aber gut vorangetrieben. Während Team 1 stärkeren Wert auf Auslieferbarkeit & Effizienz gelegt hatte, engagierte sich Team 2 mehr in den Bereichen saubere Tests & Funktionalität. Ausnahmsweise gab es beim ersten Dojo-Battle keinen Verlierer – beide Teams waren gleich stark. Die Ergebnisse von Team 1 und Team 2 lassen sich auf dem Dojo-Projekt bei Codeplex begutachten.

Fazit: Ein wirklich gelungener Abend mit engagierten Teams, die trotz der Herausforderungen und Schwierigkeiten eine gute Leistung abgeliefert haben! Danke an alle Teilnehmer! Chapeau!

Viele werden schon davon gehört haben, und viele werden es auch schon kennen: Code Contracts. Obwohl Code Contracts noch nicht offiziell veröffentlicht wurden, sind Code Contracts mittlerweile keine neue Sache. Im Gegenteil, Durch die massive, jahrelange Forschungsarbeit von Microsoft sind Code Contracts seit über einem Jahr sehr stabil und zuverlässig. Interessanterweise wurden Code Contracts nicht spezifisch erforscht, sondern sind als “Nebenprodukt” der Forschungen zu Boogie/Clousot (der statischen Verifikationskomponente von Spec#) entstanden.

Man findet mittlerweile sehr viele Beispiele und Casts zu Code Contracts und all den Features, die Code Contracts mit sich bringen. Ein aktuelles Video und eine wirklich sehenswerte, einfache Einführung in die Features ist die PDC09 Session über Code Contracts und PEX (dem automatisierten Unit Testing Tool). Es ist konsequenterweise nicht verwunderlich, dass Code Contracts seit über einem halben Jahr in den DevLabs zur Verfügung gestellt werden und mit .NET 4.0 in der mscorlib integriert sein werden (also in .NET 4.0 mit enthalten sein werden).

Parameterverifikation mit Stil

Eine besondere und herausstechende Eigenschaft der Code Contracts ist jedoch, dass es sich wunderbar einfach in eine existierende Code-Basis einführen lässt. Dadurch das Code Contracts viele Vorteile mit sich bringen, kann man eine stufenweise Integration anstreben. So ist es eine gangbare Methode, Code Contracts im ersten Schritt für die Dinge einzusetzen, die man sowieso schon jahrelang macht, wie z.B. Parameterprüfungen in Methoden (Vorbedingungen):

//...
public void ProcessOrder(IOrder order)
{
  if (order == null) throw new ArgumentNullException();
  //...
}
//...

Diese “Contracts” werden mittlerweile von Tools wie ReSharper oder CodeRush auf Wunsch automatisch generiert, um dem Entwickler den Tippaufwand zu ersparen. Es gibt in manchenvielen Anwendungen und API’s auch nette Hilfsklassen, die diese Prüfungen beschleunigen:

//...
public void ProcessOrder(IOrder order)
{
  Argument.MayNotBeNull(order);
  //...
}

public static class Argument
{
  public static void MayNotBeNull(object o)
  {
    if (o == null) throw new ArgumentNullException();
  }
}

Genau dieser, ich möchte schon fast sagen tagtägliche Anwendungsfall kann mit Code Contracts sofort umgesetzt werden:

public void ProcessOrder(IOrder order)
{
  Contract.Requires(order != null);
  //...
}

Lesbar, einfach und effektiv gesehen exakt das selbe, was man schon seit Jahren “per Hand” programmiert. Das Schöne ist hier allerdings, das es die Tür für die weiteren Tools (z.B. statische Verifikationsanalyse) öffnet. Mit der Zeit kann man auch nicht nur die Preconditions mit den Code Contracts umsetzen, sondern auch die Postconditions und Invariants einsetzen.

In einem späteren Schritt kann man zu den Prüfungen zur Laufzeit auch die statische Verifikation noch mit einführen, um kritische Anwendungsteile in der Stabilität zu stärken. Es gibt noch viele weitere Vorteile, die Code Contracts mit sich bringen (z.B. Verifikationsdefinitionen auf Schnittstellen), auf die ich hier nicht näher eingehen werde. Ich denke jedoch, dass jeder, der sich ein wenig mit den Code Contracts auseinandersetzt, die klaren Vorteile erkennen wird.

Weihnachten ohne Geschenke?

Die Frage ist nun: würde man Code Contracts in eine bestehende heute schon Codebasis integrieren wollen? Die aktuelle Version der Code Contracts muss man separat referenzieren, denn die Contracts werden erst mit .NET 4.0 ein fester Bestandteil der BCL sein. Man stelle sich nun ein agiles Projekt vor, in dem wöchtenliche Releases keine Seltenheit sind. Würde man in so einer Situation den Einsatz von Code Contracts befürworten oder eher abwarten, bis es .NET 4.0 veröffentlicht wurde. Lizenzteichnisch gäbe es keine Probleme, zumal die Code Contracts in der aktuellen Version schon über eine Going-Live-Lizenz verfügen.

Dafür spricht, dass die Code Contract API schon seit über einem Jahr stabil ist. Die Contract-Assembly wurde sehr sorgfältig über einige Jahre hinweg entwickelt. Ein weiteres Pro-Argument ist sicherlich die definitive Integration mit .NET 4.0. Schon heute steht fest, dass System.Diagnostics.Contracts eine fester Bestandteil der neuen .NET-Version sein wird. Die Vorteile, die die Code Contracts selbst mit sich bringen (also verbesserte Verifikation zur Laufzeit, statische Verifikation, erleichterter Einsatz von weiterführenden Tools wie z.B. PEX) erwähne ich nur nebenbei.

Dagegen würde wohl momentan nur die Tatsache sprechen, dass die Contracts noch nicht Final sind. Die API kann sich in den einigen Monaten bis zur Veröffentlichung von .NET 4.0 noch ändern (obwohl es lt. Aussage der Entwicklungsmannschaft wohl unwahrscheinlich ist). Ein weiteres Gegenargument für den sofortigen Einsatz ist wohl das Deployment. Abhängig vom Anwendungstyp muss man da einige Parameter berücksichtigen. Doch für den jetzigen Anwendungsfall möge man von einem agilen Software-Projekt mit frequentiven Releases ausgehen, z.B. ganz klassisch bei einer Web-Anwendung. Hier muss man abwägen, ob man die Contracts-Assembly auf den Webservern im GAC installiert oder mit den eigenen Assemblies mit ausliefert.

Nach dieser kurzen Pro-Contra-Gegenüberstellung würde mich Eure Meinung interessieren. Was meint Ihr? Wer setzt es heute schon ein? Wer möchte es noch vor dem .NET 4.0 Release einsetzen? Wer möchte lieber abwarten bis .NET 4.0?

Die Frage ist: Das Geschenk “Code Contracts” heute schon annehmen und einsetzen? Ja oder Nein?

Unit Tests & TDD machen Sinn!

Ganz ehrlich, Unit Tests & TDD machen sogar richtig viel Sinn. Unit Testing selbst macht schon sehr viel Sinn, weil eine Verifikation von Anforderungen (fachlicher und technischer Natur) ein wichtiger Bestandteil in der Beurteilung von Leistungsanforderungen an eine Software sind. Ha! Komischer Satz irgendwie, aber im Endeffekt einfach abkürzbar: Wer will ein Auto ohne getestete Bremsen fahren? Übrigens auch ein ziemlich netter Vergleich, denn “bremsen” ist das Feature, welches von verschiedensten Komponenten und Faktoren abgedeckt wird (Bremsflüssigkeit, ABS, Bremsscheiben, Bremsbacken, Bremsblöcke usw usf.). Naja, ich glaube da gibt es nicht viel mehr darüber zu sagen.

Darüber hinaus geht es beim Testing & Test-Driven-Development um die Entwicklung von stabiler Software. Stabil ist in diesem Sinne nicht nur die Verifikation der Funktionalität (”Im Werk wurde einmal auf die Bremse getreten, der Wagen blieb stehen – Passt.”), sondern um die Haltbarkeit der Funktionalität als Subsystem (die gesamte Bremsanlage) und innerhalb des Gesamtsystems (Auto). Kurz und bündig: Wer heutzutage stabile, wartbare und erweiterbare Software entwickeln möchte wird ernsthaft TDD einsetzen wollen.

TDD ist ein mächtiges Entwicklungswerkzeug

Wie Ralf es schon in seinem Post über TDD erklärt und in vielen Kommentaren wiederholt, darf man TDD nicht als das “Allheilmittel” ansehen, sondern als dediziertes, mächtiges Werkzeug. Mit TDD als Tool kann man viele Dinge sicherer und schneller gestalten. Mittlerweile kann ich behaupten, dass ich TDD in keinem Projekt außer acht lassen will und werde, weil es ein essentielles Werkzeug in meinem “Software-Entwicklungs-Baukasten” ist – wie z.B. eine gute IDE oder Patterns oder SCM oder CI… TDD ist einfach mit dabei.

Manch einer macht hierbei noch eine feine Unterscheidung. Es heisst: “Bei neuen Projekten TDD, ok. Aber bei den alten Dingern? Boa, nee”. Ehrlich gesagt habe ich das am Anfang auch so gesehen. Aber Mittlerweile sehe ich das ganz anders. Egal ob Green- oder Brownfield – TDD ist immer gut. Bei schon existierenden Projekten (die evtl. sogar wenig Tests haben) treibt TDD die Testbarkeit und die lose Kopplung voran, fördert die Effektivität der Arbeit an Erweiterungen und erleichtert vehement die Umstrukturierung und Wartung des Codes. Dort wo es machbar ist, sollte TDD auch gemacht werden, denke ich.

Jaaa, aber wo ist denn TDD nicht machbar? Klare Antwort: I/O und Parallelität / Multithreading. Alles was mit Ein- und Ausgabegeräten zu tun hat, eine Ressource für Ein- oder Ausgabe darstellt oder in einem asynchronen Verarbeitungskontext liegt. In der Praxis: Joystick, Komplexe Eingaben, User Interfaces, Datenbank. Das sind kritische Punkte, ja. Und gerade dort wünscht man sich TDD, obwohl genau dort die Grenzen früher oder später erreicht werden, weil man einfach keinen Einfluss mehr auf den Status, die Eingabe, die Ausgabe oder die Erwartung derer hat.

TDD im Grenzbereich

Dennoch darf man sich nicht durch diese “Schwierigkeiten” abschrecken lassen. Ich habe gerade bei diesen Situationen festgestellt, dass es enorm hilfreich sein kann, am “Grenzbereich” von TDD sprichwörtlich “bis zum geht nicht mehr” umzusetzen. Man stellt schnell fest, dass man an diesen “Nahtstellen” der Anwendung sauberer und klarer strukturiert, Verantwortlichkeiten besser aufteilt. Danach betrachtet man das Ergebnis mit anderen Augen. Man stellt fest, dass die UI wirklich nur noch das nötigste macht, absolut schlank ist und dass viele Dinge, die in der UI hilfreich sind (wie z.B. “Pagination”) auch komplett ohne UI wunderbar anwendbar werden. Da ist TDD ein wenig wie beim Autorennen: Im Grenzbereich ist es anstrengend, ist aber hocheffektiv und macht obendrein noch Spass.

Für die TDD-Stirnrunzler, die wirklich mal wissen wollen, wie sich das dann im Endeffekt anfühlen kann, denen lege ich wärmstens ein paar Code Kata’s an’s Herz. Zum Beispiel ist das populäre KataFizzBuzz im letzten Einsteiger-Dojo als Windows-Forms-Kata implementiert worden. Dort gab es viele, die sich gefragt haben, wie man überhaupt die UI testen kann. Doch statt sich mit der “Untestbarkeit” der GUI zufrieden zu geben, hat man konsequent das TDD ausgereizt und dadurch ein einfaches MVP-Pattern umgesetzt.

Für TDD-Neulinge empfehle ich auch das KataBlog. Es ist eine wunderbar einfache Programmieraufgabe, die sehr subtil zeigt, wie man über TDD Design & Entkopplung der Verantwortlichkeiten treibt und welche (anfangs ungeahnten) Vorteile man sich dadurch schaffen kann. Jedoch warne ich die Interessierten schon vor: KataBlog zeigt die Erkenntnisse subtil, zwischen den Zeilen.

Fazit: TDD & Unit Testing ist ein absolutes Muss in der modernen Software-Entwicklung!

Wir haben im Experten-Dojo uns einem neuen Code Kata gewidmet, dem KataMinesweeper. Anfangs waren wir noch am Grübeln, ob wir nicht das Taschenrechner Kata vom letzten Mal weiter lösen wollen, aber nach einer kurzen Abfragerunde war klar, wir werden uns Minesweeper “zur Brust” nehmen. Gut fand’ ich diesmal im Übrigen auch das wir uns gleich auf den Modus geeinigt haben. Wir haben uns für den Prepari Modus entschlossen – eine gute Entscheidung.

Das Minesweeper Kata ist ein besonders schönes und ergiebiges Kata, mit dem man wirklich viele Konzepte und Methoden trainieren kann. Überraschender Weise haben wir ziemlich lange für den “Ramp-Up” gebraucht. Einige Teilnehmer waren sich nicht im Klaren, welche Testing-Strategie angegangen werden soll. Nach einer kurzen Diskussion war aber wieder Einigkeit. Es sollte zunächst einmal die Einlese-Routine der Spielfeld-Definition getestet werden. Verdutzt war ich auch über den Fakt, dass es Schwierigkeiten bei der Vergabe der Namen für die Testmethoden gab. Schon hier war zu erkennen, dass die Teilnehmer des Dojo’s mit unterschiedlichen Grundkenntnissen umgehen mussten. Ich kann schon jetzt verraten, dass der Know-How-Transfer dem Experten-Team gut gelungen ist.

Nach über einer Stunde waren wir soweit, das Spielfeld war implementiert. In der 15-minütigen obligatorischen Pause wurde neben der Frischluft auch kräftig News über das .NET Open Space Leipzig und das BarCamp München Event vom Wochenende getankt.

In der “zweiten Halbzeit” des Dojo’s ging es an’s Eingemachte: der Minesweeper-Algorithmus sollte entwickelt werden. Auch hier wieder die Startschwierigkeiten: Während einige schon die Test-Strategie nach einem “zu erarbeitenden Algorithmus” ausarbeiten wollten, waren andere der Meinung, man solle die Tests das Design treiben lassen. Ich habe so gut wie möglich versucht, die erste Partei davon zu überzeugen, dass es beim TDD fundamental um das Design geht. Der “Verifikations-Gedanke” spielt im TDD eine untergeordnete (aber sicherlich angenehme) Rolle.

Wir haben es schlußendlich alle gemeinsam geschafft, mit Hilfe der Tests einen validen Algorithmus aufzubauen. Yea! Wir haben das Minesweeper Kata geschafft! Abschliessend haben wir uns noch darüber unterhalten, wie wir den Code weiter bearbeiten wollen würden und welche Strategien die geeigneten wären. Ich persönlich würde mich freuen, wenn wir im nächsten Dojo dort weitermachen könnten, wo wir diesen Mittwoch aufgehört haben. Auf der anderen Seite bin ich auch gespannt genug, welche Erkenntnisse wohl die anderen Kata’s mit sich bringen. Sei’s drum. Fakt ist – es war wieder mal erkenntnisreich und spannend gleichermaßen!

Ich freue mich schon auf das nächste Experten-Dojo am 28. November! Übrigens, besonders empfehlen kann ich auch das nächste Einsteiger-Dojo am 4. November, dort wird ein wunderbares Kata mit ASP.NET MVC angegangen!

Aber bevor man sich dem “Management” einer Sache annimmt, sollte man definieren was diese Sache – also das Projekt – überhaupt ist. Da wären zum einen eine Reihe von formalen, klassischen Definitionen. Die gängigste ist wohl die des PMI:

“Ein Projekt ist ein zeitlich begrenztes Vorhaben, das unternommen wird, um ein einmaliges Produkt, eine Dienstleistung oder ein Ergebnis zu erzeugen.”

Project Management Body of Knowledge (PMI)

Um es also in deutlicheren Worten zu sagen: Ein Projekt ist prinzipiell alles, um ein bestimmtes Ziel in einer bestimmten Zeitspanne mit bestimmten Mitteln zu erreichen. Aus der “Entwickler-Brille” betrachtet kann also ein Projekt alles mögliche sein: Ein Bug-Fix, ein Change-Request, eine Komponente, ein Mini-Tool, eine Website, ein Framework oder eine super-duper Mega-Anwendung. Das ist für meinen Geschmack (und den vieler anderer) etwas zu schwammig, denn wenn alles ein Projekt wäre, müsste man alles auch managen – das ist offensichtlich zuviel des Guten.

Also müssen weitere Kriterien herangezogen werden, um ein “Vorhaben” und die damit verbundenen Maßnahmen als “Projekt” zu rechtfertigen. In der Software-Entwicklung gibt es eine einfache Faustregel, um Vorhaben & Aufgaben nach einer bestimmten “Komplexität” für ein Projekt auszusieben:

Die “3 mal 1 Projekt-Regel”

Alle Vorhaben oder Aufgaben, die offensichtlich

• länger als einen Tag andauern können, oder
• mehr als eine einzelne Aktion erfordern, oder
• mehr als eine Person beschäftigt

sind Projekte.

Dieser sehr groben Faustregel ist natürlich nicht strikt zu folgen, sondern eher als richtungsweisende Orientierungsregel zu verstehen und hat sich eigentlich gut bewährt. Das Fatale an dieser Regel ist natürlich, dass es potenziell viele kleine Mini-Projekte verursacht – aber das sei für’s Erste mal ausser acht gelassen. Prinzipiell gilt: Ein Projekt hat eine Zielvorgabe, eine Zeitvorgabe und natürlich die Personen & Mittel, die diese Vorgabe in der “gegebenen” Zeit umsetzen sollen.

Hat man nun ein Projekt definiert – also sich ein Ziel gesetzt, welches man bis zu einem bestimmten Datum erreicht haben will, geht es um das Management des Projektes. Auch hier gibt es wieder eine Menge an trockenen Definitionen dafür, was Projektmanagement eigentlich ist. Hier die Definition nach DIN-Norm:

“Projektmanagement ist die Gesamtheit von Führungsaufgaben, -organisation, -techniken und -mitteln für die Abwicklung eines Projektes.”

DIN 69901

Eine in meinen Augen äußerst “harte” Defintion. Demnach braucht ein Projektmanager eigentlich nichts anderes zu tun, als alle Projektbeteiligten und das Projekt selbst zu “führen”. Ein Projektmanager ist also für ein Projekt eine Führungskraft. Meiner Meinung nach ist da mehr dahinter – oder besser gesagt, eigentlich etwas ganz anderes. Intuitiv stellt man sich dabei nämlich die Frage: Was muss man denn eigentlich bei einem Projekt alles “verwalten” ?

Was macht eigentlich ein Projektmanager ?

Genau hinter dieser Frage versteckt sich das eigentliche Dilemma des Projektmanagements. Abhängig von der Größe, der Dauer, der Inhalte, der Umsetzung, des Teams, der Investitionen und vielem Anderen mehr kann oder muss man besonders viele oder besonders wenige Verwaltungs- und Organisationsmaßnahmen durchführen. Das gesamte Betätigungsfeld eines Projektmanagers ist dermaßen variabel und abhängig vom Projekt, dass man es kaum greifen kann.

Trotz dieser ausgesprochen hohen Variabilität versucht man beim Projektmangament, alles mögliche zu organisieren, zu strukturieren, zu planen oder gar zu reglementieren. Das macht man natürlich nicht aus Spaß, sondern primär um die Zielvorgabe des Projektes zu realisieren – also ein Projekt erfolgreich durchzuführen. Im “klassischen” Projektmanagement gibt es da verschiedene Leitfäden, wie z.B. das Magische Dreieck, die Projektumfeldanalyse oder das sagenumwobene Teufelsquadrat.

Ich möchte noch ein klein wenig bei der bis dato sehr allgemeinen und abstrakten Betrachtungsweise des Projektmanagements bleiben, bevor ich die Dinge auf die Software-Entwicklung konkretisiere. Denn aus meiner Sicht kann man ganz allgemein unter Projektmanagement einfach die Aufgaben verstehen, allen Beteiligen

• die benötigten Informationen zu liefern,
• die notwendigen organisatorischen Maßnahmen (bzgl. Meetings, Listen, Dokumente) zu übernehmen,
• bei der Bewältigung von technischen, sozialen oder anderweitigen Problemstellungen zu helfen,
• den Überblick über das Projektgeschehen zu haben und zu vermitteln.

Betrachtet man meine obige “naive” Beschreibung des Projektmanagements näher, stellt man fest, dass die Aufgaben sich stark dem Aufgabenbereich z.B. eines Sekretärs oder einer ähnlicher Bürokraft annähern. Insofern ist die Aussage für mich zulässig, dass ein Projektmanager für ein Projekt und alle Beteiligten im positiven Sinne nichts anderes als eine Hilfskraft darstellt.

Ich möchte keineswegs den Berufsstand oder die Kompetenzen des “Projektmanagers” dadurch mindern – aber dennoch klar feststellen, das Projektmanagement in erster Instanz nichts mit Mitarbeiter- oder Teamführung zu tun hat.

Projektmanagement in der Software-Entwicklung

Vielmehr beschäftigt sich ein Projektmanager mit Kennzahlen, Analysen oder Rahmenbedingungen wie z.B. Zeit-, Ressourcen- und Budgetplanung. Das ist vor Allem in der Software-Entwicklung eine nicht zu unterschätzende Aufgabe, schließlich ist Software ein “weiches”, während der Konstruktion schwer greifbares Produkt.

Hier kommt ein in meinen Augen ganz wesentlicher Aspekt, den jeder Software-Projektmanager im Fokus haben sollte: Die Arbeit am Produkt und das Produkt so gut wie möglich “greifbar” zu machen. Greifbar nicht nur im Sinne von Metriken für Fortschritt, Dauer, Leistung, Fehlerquote oder ROI. Nein, ich meine überdies andere Dinge, wie z.B. die Visualisierung des Produktes in Form von Continuous Build / Integration, Test- oder Betaversionen, klare Anforderungs- und Informationskanäle mit geeignetem und auf das Team abgestimmten Toolset, leicht verständliche, einfache Prozesse zur Organisation der Arbeitsabläufe oder konkrete Koordinationsunterstützung mit Hilfe von Meetings, Zusammenfassungen und Dokumentationen.

Leider ist es oftmals der Fall, das Projektmanager aber auch andere Dinge tun. Ein besonderes Steckenpferd scheint dabei das Mitwirken bei technischen Entscheidungen zu sein. Manchmal geht das sogar soweit, das der Projektmanager die Richtung geradezu vorgibt. Man mag argumentieren, das in der Software-Entwicklung öfters Projektmanager schon eine “Entwickler-Vergangenheit” nachweisen können. Das alleine rechtfertigt eine technische Mitbestimmung meiner Meinung nach noch lange nicht.

Im Gegenteil, es wird dadurch für Entwickler und Manager nicht einfacher – während der Entwickler dem Manager mangelnde Detailkenntnisse entgegenwirft, entgegnet der Manager dem Entwickler seine Einschätzung zu Aufwendungen und Vorgehensweisen. Ich bin mir sicher, das viele Entwickler schon die Sätze “Der Bugfix dauert niemals so lange”, “Das kann man doch einfach runter programmieren” oder “In PHP ist das ganz easy” aus dem Munde des Projektmanagers gehört haben. Diese Aussage sollte nicht missverstanden werden – jeder Projektmanager darf und kann aus einer “Entwickler-Vergangenheit” Vorteile und Erfahrungen in seine jetzige Aufgabe einbringen – nur das “Wie?” ist entscheidend.

Abgesehen davon legen manche Projektmanager besonderen Wert darauf, die anstehenden Aufgaben den Entwicklern zuzuweisen und aktiv an der Arbeitsaufteilung mitzuwirken. Der Projektmanager hat zugegebenermaßen den “Überblick”. Aus seiner Perspektive ist er also im Idealfall wie ein Schachspieler, der das Spielfeld bzw. die Spielsituation überblickt und entscheidet, welche Spielfigur für den nächsten Zug eingesetzt wird und wie sich dadurch die Spielsituation verändert.

Die Fehleinschätzung dabei ist aus meiner Sicht schlicht und einfach die Tatsache, das man Software-Entwicklung nicht mit Schach vergleichen kann. Im Schach gibt es einen Gegner, kein Zeitdruck, keine Korrektur des Spielzugs, keine variable Leistung der Spielfiguren, keine äußeren Einflüsse und ein festes Reglement.

In der Software-Entwicklung jedoch gibt es all dies nicht. Dafür spielen andere Faktoren eine große Rolle. Das Know-How jedes einzelnen Entwicklers, die technologische Plattform, die Anforderungen und Wünsche des Kunden und vieler Abteilungen, die Altlasten, Fehler und Wartungsmechanismen, das Teamwork der Entwickler. Insofern ist es geradezu eine Überheblichkeit, das ein Projektmanager sich selbst zumutet, die Einschätzung über Aufgabenverteilung zu übernehmen oder zu steuern.

Aliges Software-Management: Rettung oder Untergang ?

Nun, mittlerweile ist in nahezu jeder professionellen Software-Entwicklung das Thema “Agile Software-Entwicklung” angekommen und wird auch schon breit praktiziert. Methoden wie Scrum oder Crystal bringen neue Denk- und Arbeitsweisen ins Management. Das interessante an den agilen Ansätzen ist die latente Ignoranz der klassischen Projektmanager-Rolle gegenüber. So ist z.B. in Scrum weit und breit kein Projektmanager in Sicht. Statt dessen gibt es Scrum Master und Product Owner. Es liegt die Schlußfolgerung nahe, das man ja eigentlich gar keinen Projektmanager benötigt.

Die Wahrheit liegt wie so oft in der Mitte. Obwohl es bei agilen Managementmethoden wie Scrum keine “echten” Projektmanager gibt, gibt es sie doch. Die “Reinkarnation” des Projektmanagers kommt dabei in vielschichtigen Formen. Der Scrum Master ist so eine Reinkarnation – er übernimmt klassische technische und soziale Teamaufgaben und hilft bei Koordination und Organisation. Der Product Owner kümmert sich um das “geschäftliche”, also Kunden, Anforderungen, Budgets und zeitliche Abläufe. Die übrigen Aufgaben des Projektmanagements werden auf das gesamte Team verteilt. Doch der Projektmanager als Person ist von der Bildfläche verschwunden.

Wenn man diese “reine Scrum-Lehre” in größeren Projekten oder Organisationen umsetzt und lebt, stellt man schnell fest, das Scrum kein einfaches Management-Modell ist. Die “Eliminierung” des Projektmanagers aus dem Vorgehensmodell bürdet den bleibenden Rollen automatisch Teilaufgaben eines Projektmanagers auf. Nach einigen Monaten spürt jeder in einem Scrum-Team, das das managen von Projekten keine leichte, erquickende Aufgabe ist. Obgleich es eine gute Idee ist, die Verantwortung des Projektes auf mehrere Schultern zu verteilen und das Team durch das gemeinschaftliche Verantwortungsbewusstsein zu stärken, ist deren Umsetzung ungleich schwerer.

Master oder Owner, das ist hier die Frage

An dieser Stelle möchte ich nicht zu tief in die Unwegsamkeiten und Potenziale von Scrum eintauchen und den Blick wieder auf den klassischen Projektmanager und dessen Aufgaben fokussieren. Einem Projektmanager bleibt in agilen Projekten und Modellen wie z.B. Scrum eigentlich nur die Wahl, sich für eine der Rollen (Scrum Master oder Product Owner) zu entscheiden. Die meisten wählen den Pfad des Scrum Masters – auf den ersten Blick scheint der Scrum Master mehr mit einem Projektmanager gemein zu haben als der Product Owner.

Die Entscheidung, ob der originäre Projektmanager ein Scrum Master oder Product Owner werden soll, ist meiner Meinung nach eine Frage des menschlichen Charakters und der Fähigkeiten. Die essentielle Entscheidungsgrundlage ist dabei die Erkenntnis eines wichtigen Unterschieds zwischen Scrum Master und Product Owner: Während der Scrum Master ein “Projektbegleiter” ist, ist der Product Owner ein “Projektführer”. Der eingangs erwähnte klassische Anspruch, das ein Projektmanager “Führungsaufgaben” übernimmt, wird in Scrum eher dem Product Owner zugeschrieben. Der Scrum Master allerdings ist der “Begleiter”. Er deckt die Sicht des Entwicklers auf den Projektmanager, worin dieser wie schon beschrieben nur “Miittel zum Zweck” oder eine Hilfskraft darstellt.

Ist also ein Projektmanager stark in den Disziplinen Kundenkontakt, Analyse, Steuerung, Budgetierung und hat das “Führungs-Gen”, dann sollte er sich mit der Rolle des Product Owners anfreunden. Ist er jedoch stark bei technischer Kenntnis, sozialem Umgang, Hilfsbereitschaft, Metriken und Dokumentation (siehe Servant Leadership), ist für Ihn wohl eher der Scrum Master ein geeignetes Tätigkeitsfeld.

Einsichten & Erkenntnisse

Aus all diesen Gedanken heraus erschließt sich für mich die Erkenntnis, das die klassische Rolle des Projektmanagers ausgedient hat – ja sogar mittel- bis langfristig zum Aussterben verurteilt ist. Denn für Software-Unternehmen ist es entscheidend, Projekte und deren Durchführung stetig zu verbessern – also besser steuern, kontrollieren und hervorsagen zu können. Die “Zertrümmerung” der Aufgaben, Wirkungsbereiche und Verantwortlichkeiten eines klassischen Projektmanagers in verschiedene, spezialisierte “Unter-Rollen” ist dabei für mich eine normale, evolutionäre Entwicklung. Die Dezentralisierung des Managements parallelisiert die Durchführung der Aufgaben, beschleunigt die Teilumsetzung bei gleichzeitiger Optimierung durch Spezialisierung.

Natürlich bleibt die Gefahr des Scheiterns bei diesem agilen Modell, ist aber durch die Diversifikation der Aufgaben auf die einzelnen Rollen im Vergleich zum klassischen Modell minimiert. Besonders herausfordernd sind die Bereiche Kommunikation und Koordination. Nur durch eine abgestimmte Kommunikation und einfache, prägnante Koordinationsregeln kann aus der Aufgabenteilung ein direkter positiver Effekt erreicht werden.

Für den “klassischen Projektmanager” heisst das nicht, das er schwere Zeiten vor sich hat. Im Gegenteil, Projektmanager können und sollten diese Entwicklung für sich nutzen und sich für die einzelnen Teilaufgaben spezialisieren. Zumindest gilt das für die operative Ebene. Für besonders kompetente und erfahrene Projektmanager tut sich ein neues Tätigkeitsfeld auf, denn durch die Dezentralisierung der Aufgaben entsteht der Bedarf des koordinierten Bündelns und Steuerns der operativen Teile aus der strategischen Ebene heraus.

Ich als Entwickler freue mich für meine Kollegen, denn für die Entwickler bedeutet dieser Schritt zur Optimierung des Managements mehr Verständnis und aktive, effektive Unterstützung auf Entwicklungsebene. Die Informationskanäle werden durch Konsolidierung geringer und man kann sich besser auf seine Aufgaben konzentrieren. Des Weiteren wird der Entwickler mehr in die Verantwortung für seine Tätigkeit genommen. In den meisten Fällen geht das einher mit einer gesteigerten Anerkennung der Leistung des Entwicklers bei gleichzeitiger Professionalisierung im Sinne von Mitwirkung, Kommunikation und Detailplanung.

Es bleibt spannend!

Jedoch fiel mir nach kurzem Einlesen in das Thema schnell auf, das man nicht einfach so “nur einen Bug Report” erstellen kann, sondern das auch bei Bug Reports ausgefeilte Methoden angewendet werden. Besonders interessant sind dabei die Zusammenhänge zum Anforderungsmanagement und zum Testing.

Meine Erkenntnisse über das Bug Reporting habe ich in dem Artikel Effektives & effizientes Bug Reporting zusammengefasst.

Happy debugging!

Scrum (engl. das Gedränge) ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Softwareentwicklung. Es ist ein Vorgehensmodell, das wenige Festlegungen trifft. Teams bzw. Entwickler organisieren sich weitgehend selbst und wählen auch die eingesetzten Methoden. Das Vorgehen und die Methoden werden fortlaufend aktuellen Erfordernissen angepasst.

Die o.g. Beschreibung aus Wikipedia trifft im Großen und Ganzen das, was Scrum ist und wofür es eingesetzt wird. Scrum ist eine relativ junge Verfahrensmethodik in der Software-Entwicklung. Nichtsdestotrotz wird es schon oft und gerne angewendet. Als “Interpretation” des Agilen Manifests gilt Scrum als ein agiles und sehr leichtgewichtiges Rahmenwerk für Management in der Software-Entwicklung.

Ein erster und leicht zu merkender Überblick über Scrum als agiles Framework lässt sich im Kern durch die “3×3″-Regel schaffen:

• Drei Gremien:
  • Daily Scrum – Die tägliche Einsatzbesprechung;
  • Sprint Planung – Planung eines Arbeitszyklusses;
  • Sprint Review – Der Abschluss einer Arbeitsphase und die Abnahme eines Arbeitspaketes.
• Drei Artefakte:
  • Product Backlog – Eine priorisierte Liste aller Anforderungen;
  • Sprint Backlog – Eine Liste von Aufgaben zur Erfüllung eines Arbeitspaketes;
  • Release Plan – Eine Prognose und Vorausplanung der Veröffentlichungsdaten des Produktes.
• Drei Rollen:
  • Product Owner – zuständig für den wirtschaftlichen Erfolg und das Produkt;
  • Scrum Master – wacht über die Methodik und die Produktivität des Teams;
  • Team – das selbst-organisierte, teilautonome Team.

Gremien

Die Hauptaufgabe allen Software-Managements ist unbestritten die Organisation, Koordination und Planung der
Software-Entwicklung. Wie auch bei anderen Management-Frameworks gibt es in Scrum wohldefinierte Ankerpunkte, die die Kommunikation fördern. Wie zuvor schon erwähnt, gibt es dazu in Scum drei wesentliche Gremien (oder Institutionen).

Daily Scrum

Das Daily Scrum (auch “Daily” oder “Huddle”) ist das essentielle Organisations-Element in Scrum. Hier ist die Empfehlung, ein komplettes Team-Meeting (das Daily) jeden Tag zur gleichen Zeit am gleichen Ort durchzuführen. Das Meeting sollte nicht länger als 15 Minuten dauern und dient dem täglichen Status-Austausch und Feedback innerhalb des Teams. Während des Meetings werden die drei sog. “Scrum-Fragen” an jeden Teilnehmer mit der bitte um zügige und kurze Antwort gestellt:

• Was hast Du gestern getan?
  “Bist Du gestern mit dem fertig geworden, was Du Dir vorgenommen hast?”
• Was wirst Du heute tun?
  “Welche Aufgaben wirst Du bis zum nächsten Meeting bearbeiten?”
• Alles ok?
  “Gibt es ein Problem, das Dich bei Deiner Aufgabe blockiert / hindert?”

Sprint Planung

Zu Beginn eines Sprints wird ein Planungsmeeting abgehalten, bei dem die Ziele und Aufgaben der gesamten Sprintdauer besprochen und geplant werden. Zunächst werden aus dem Product Backlog (der groben Anforderungsliste) die nächsten anstehenden Anforderungen besprochen und geklärt.

Daraufhin wird das sog. “Commitment” durchgeführt; es wird also eine Zusage über die zu erledigenden Dinge innerhalb des nächsten Sprints herbeigeführt. Anschließend wird das Commitment detailliert geplant und die einzelnen Aufgaben zur Erfüllung der Anforderungen abgeleitet. Diese Liste wiederum bildet das Sprint Backlog.

Review & Retro

Nach einem Sprint wird ein sog. Review (meist auch nur “Demo” genannt) durchgeführt. Das Sprint-Review dient vornehmlich zum Vorzeigen und Diskutieren der Ergebnisse des Sprints. Im Review-Meeting wird zumeist die neu geschaffene Funktionalität der Software dem Kunden und dem Team vorgeführt (Demo). Des Weiteren wird ein allgemeines Feedback abgefragt bzw. eine offene Diskussionsrunde abgehalten.

Ähnlich zum Review wird zum Ende eines Sprints auch eine “Retrospektive” abgehalten, in der explizit die Meinungen, Hürden und Verbesserungsmöglichkeiten im Team diskutiert werden. Diese werden festgehalten und für die nächste Sprint-Planung in Betracht gezogen. So können z.B. methodische oder arbeitstechnische Verbesserungen während der Entwicklung erkannt und durchgeführt werden.

Der Unterschied zwischen Review und Retro liegt in der Betrachtungsweise des Sprints: Während beim Review auf das “Was” geachtet wird, liegt der Schwerpunkt der Retro auf dem “Wie”. Nichtsdestotrotz werden Review und Retro öfters in ein Meeting zusammengefasst.

Es fällt deutlich auf, das Scrum wenige Vorgaben enthält und sich gegen definierte Prozesse und Arbeitsabläufe stellt. Der Kern dieser “Scrum-Ethik” bedründet sich durch das Argument, das Software-Entwicklung ein derart komplexer und variabler Prozess ist, dass es niemals in ein definiertes, prozessuales Korsett eingefasst werden kann. Vielmehr wird davon ausgegangen und akzeptiert, das der Prozess der Software-Entwicklung ein semi-chaotischer ist, dem man nur durch empirische Management- und Kontroll-Mechanismen Herr werden kann.

Artefakte

Dementsprechend ist auch das Planungs- und Aufgabenmanagement minimal. Scrum definiert nur drei essentielle Listen.

Product Backlog

Das Product Backlog ist eine Liste mit allen Anforderungen, Aufgaben, Features, Bugs und Problemstellungen für das Produkt. Die einzelnen Einträge in der Product Backlog-Liste werden nach kundenorientierter Priorität (z.B. Geschäftszweck, Benefit) und Komplexität sortiert. Dabei muss es für diese keine Kennzahlen geben, alleine die Sortierung des Product Backlogs ist entscheidend. Die Product Backlog-Liste ist öffentlich für alle Teammitglieder verfügbar und kann jederzeit geändert und erweitert werden. Jeder Eintrag bedarf auch einer ersten Schätzung des Aufwandes.

Sprint Backlog

Der Sprint Backlog ist eine Liste von Aufgaben, die innerhalb eines Sprints (i.d.R. eine 2-4 wöchige Iteration) durchgeführt werden soll. Der Sprint Backlog wird zu Beginn eines Sprints erstellt und innerhalb dessen abgearbeitet. Im Gegensatz zum Product Backlog ist hier die Sortierung nicht entscheidend, kann aber weitergeführt werden.

Viel wichtiger ist hier die Vorgabe, dass eine einzelne Aufgabe des Sprint Backlogs nicht länger als 3 Tage dauern sollte (je kürzer, desto besser). Ist dies dennoch der Fall, sollte die Aufgabe in Teilaufgaben zerlegt werden. Des Weiteren werden beim erstellen des Sprint Backlogs alle Aufgaben nochmals in der Schätzung verfeinert.

Release Plan

Der Release Plan ist eine Liste der definierten “Meilensteine” eines Software-Produkts, bei dem eine Veröffentlichung fachlich, strategisch oder unternehmerisch angebracht ist. Der Release Plan richtet sich nach der “Velocity” des Teams (also nach dem Produktivitätsgrad). Der Release Plan ist zumeist ein Prognose-Barometer und ein Kernelement der Integration des Scrum-Teams in die Organisation eines Unternehmens bzw. anderer Abteilungen.

Rollen

Scrum definiert drei unterschiedliche und klar getrennte Rollen: Den “Product Owner”, den “Scrum Master”, sowie das “Team”. Alle drei verfolgen während des Entwicklungsprozesses das gleiche Ziel, nämlich die “Vision” der zu entwickelnden Software.

Product Owner

Der Product Owner (oder auch nur “Owner”) ist derjenige, der die “geschäftliche” oder “fachliche” Seite der zu entwickelnden Software vertritt. Er ist also letztendlich der Kunde bzw. Kundenvertreter, der die fertige Software entgegennimmt und den Wert der Software ausschöpft. Innerhalb des Scrum ist der Product Owner eine einzelne Person (darauf legt sich das Scrum-Verfahren fest).

Er ist derjenige, der die Anforderungen an die Funktionalität der Software stellt und arbeitet dementsprechend die Anforderungen und Aufgaben mit den anderen Team-Mitgliedern in das Product Backlog ein. Er ist für die Priorisierung der Aufgaben zuständig und damit auch für das Zustandekommen des Sprint Backlogs.

Scrum Master

Der Scrum Master (im Alltag meist nur “SM” genannt) ist eine einzelne Person (auch hier eine Vorgabe von Scrum), die sich um die Einhaltung der Scrum-Regeln und Verfahrensweisen kümmert. Überdies hinaus ist der Scrum Master für “das Wohlergehen” des Teams zuständig – und zwar im Sinne von Problembehebung, Unterstützung, Motivation und Coaching.

Er ist quasi ein “Projekt-Manager-Ersatz”, allerdings ohne Weisungsbefugnis, disziplinarische oder fachliche Führung. Des Weiteren ist der Scrum Master faktisch weder ein Teil des Teams noch aus den Reihen des Product Owners – er hat also eine quasi “unparteiische” Rolle. Obwohl in Scrum oft empfohlen wird, dass der Scrum Master eine Person aus dem Team ist (z.B. ein Entwickler), ist in der Praxis der Scrum Master zumeist ein “klassischer” Projekt-Manager, der maßgebliche Verantwortungen an das Team und den Product Owner übergibt.

Trotz dieser “Verantwortungslosigkeit” ist der Scrum Master Dreh- und Angelpunkt des Scrum-Verfahrens. Er ist explizit dafür verantwortlich, das alles so gut wie nur möglich ablaufen kann.

Team

Das Team ist die einzige Rolle in Scrum, die mehrere Personen umfassen darf. Hier wird explizit auf Hierarchien und Verantwortlichkeiten verzichtet, jeder einzelne des Teams ist einfach “nur” ein Team-Mitglied. Das Team besteht meist aus Personen verschiedener Expertise oder Abteilungen, wie z.B. Entwickler, Architekten, Administratoren, Analysten und Testern.

Als Rolle ist das Team dasjenige mit der meisten Verantwortung und Wirkungskraft, denn es entscheidet eigenständig über Aufgabenverteilung und -organisation, regelt und steuert die Arbeitsweise und “kontrolliert” sich idealerweise selbst.

Scrum liefert zum Team eine Reihe von Empfehlungen, zu denen eine Teamgröße von ca. 7 (+/- 2) Mitgliedern zählt. In der Praxis ist dies bei größeren Projekten kaum machbar, dementsprechend baut man in diesem Fall N Teams mit N Scrum Mastern und N Product Ownern auf.

Metriken

Scrum als agiles Framework richtet sich nach den Maßgaben eines empirischen Managements. Es geht von vornherein davon aus, dass Schätzgrößen und Entwicklungsgeschwindigkeit im Laufe eines Software-Projektes immer tendenziell auf Basis von Erfahrungswerten ermittelt werden können. Dies wird in Scrum ermittelt, visualisiert und kontrolliert durch ein sog. “Burndown-Chart”.

Sprint Burndown Chart

Der Sprint Burndown Chart ist ein täglich aktualisiertes Diagramm, welches die Abarbeitung der einzelnen Aufgaben innerhalb eines Sprints messt und visualisiert. Er ist ein einfaches und zugleich zuverlässiges Mittel, die Entwicklungsgeschwindigkeit messbar zu machen und Problemstellungen während der Entwicklung oder der Anwendung von Scrum zu identifizieren. Der Sprint Burndown ist ein essentielles Werkzeug von Scrum.

Product Burndown Chart

Ergänzend zum Sprint Burndown erstellt man des öfteren ein Release/Product Burndown Chart, der aus der Sicht der Product Backlog Einträge und deren Abarbeitung ein Diagramm darstellt. Er ist besonders für die Sprint-Übersicht und die Voraussage von Sprintanzahl bzw. übergreifenden Terminen hilfreich.

Kickstart: Einsatz & Durchführung

Bevor ein Software-Projekt mit Scrum überhaupt durchgeführt werden kann, muss – wie bei jedem Projekt – ein Projektziel und eine “Vision” des Projektes greifbar sein.

Es gibt viele klassische und agile Methoden, die bei dieser ersten Phase des Projektes helfen, eine Projektziel zu erfassen. Generell aber gilt: Es sollte von Anfang an eine klare Fokussierung eines Ziels möglich sein. Dies umfasst nicht nur die “visionäre” Zielsetzung, sondern auch geschäftliche Faktoren (Nutzen, Markt, Einsatz) sowie einen grundlegenden Umfang der zu erstellenden Software.

Fundament: Team & Rollen

Sind diese grundlegenden Bausteine des Projektes geklärt, kann man zur Bildung des Scrum-Teams übergehen. Grundsätzlich sollten in dieser Phase schnellstmöglich alle Scrum-Rollen besetzt werden. Hierbei hilft oft das sog. “Best-Match”-Prinzip, deren Kernaussage es ist, eine bestmögliche Besetzung der Rollen anzustreben.

Product Backlog: Die Anforderungsliste

Sind Product Owner, Scrum Master sowie das Team formiert, kann quasi sofort “losgelegt” werden. Doch bevor es so “richtig losgeht”, muss der Product Owner initial das Product Backlog mit dem für Ihn wichtigsten Anforderungen befüllen. Die Einträge im Product Backlog sind nach geschäftlicher (kundenorientierter) Priorität aufgelistet, so dass immer gewährleistet ist, dass das Team an den “richtig wichtigen” Aufgaben arbeitet. Die wichtigsten Anforderungen im Product Backlog werden auch genauer und ausführlicher beschrieben und definiert. Das Team hilft dem Product Owner bei dieser Aufgabe und schätzt gleichzeitig grob die Aufwände jedes Product Backlog Eintrages.

Sprint-Planung: Das Versprechen des Teams

Nach erfolgreicher Befüllung des Product Backlogs kann “gesprintet” werden. Das Team wird also sofort produktiv. Doch bevor es an die Abarbeitung der Aufgaben geht, wird der bevorstehende Sprint im Sprint Planungs-Meeting geplant. Dabei wird die wichtige Entscheidung getroffen, wieviele Product Backlog Einträge das Team im Sprint abarbeiten kann. Die Entscheidung des Sprint-Volumens obliegt einzig und allein dem Team.

Sprint Backlog: Die Aufgabenliste

Um diese Entscheidung qualifiziert herbeiführen zu können, wird ein Product Backlog Eintrag (Anforderung) analysiert und in einzelne, kleine Aufgabenpakete granularisiert. Diese Aufgabenstellungen werden möglichst genau geschätzt und in das Sprint Backlog eingetragen. Hier wird auch die Grundregel angewendet, dass eine Sprint Backlog-Aufgabe nicht länger als 3 Tage andauern darf.

Als Ergebnis der Sprint-Planung liegt ein befülltes Sprint Backlog vor, welches zugleich das sog. “Commitment” (feste Absichtserklärung) an den Product Owner ist, dass alle diese Aufgaben zum Ende des Sprints erledigt sein werden.

Sprint: Daily Scrum & Work

Von nun an werden alle Sprint Backlog-Einträge vom Team abgearbeitet. Dabei organisiert sich das Team selbst – legt also eigenständig fest, wer an welcher Aufgabe arbeitet. Auch hier wird eine besondere Faustregel angewendet, nämlich dass jedes Teammitglied nur eine einzige Aufgabe im Sprint Backlog übernehmen darf.

Diese Selbstorganisation während des Sprintverlaufs wird durch das “Daily Scrum”, also die tägliche kurze Einsatzbesprechung des Teams gestützt und gefördert. Im Daily Scrum werden Aufgaben aktualisiert und verteilt sowie grundlegende Status-Informationen an alle Teammitglieder mitgeteilt.

Sprint-Review: Das Ergebnis

Neigt sich der Sprint dem Ende zu, werden zum Abschluß zwei Meetings durchgeführt. Das erste Meeting ist das sog. “Sprint-Review”, in dem die Ergebnisse des Sprints dem Product Owner präsentiert werden und zur Abnahme vorliegen. Im Review entscheidet der Product Owner, ob das zu Beginn des Sprints gegebene “Versprechen” des Teams eingehalten wurde und ob er mit den Arbeitsergebnissen zufrieden ist. Sollten (Teil-)Ergebnisse unzufriedenstellend sein, werden diese vom Product Owner abgelehnt und werden automatisch zur “Nachbesserung” in den nächsten Sprint mit eingeplant.

Sprint-Retrospektive: Immer besser & besser

Nach dem Review des Sprints folgt sofort die sog. “Sprint-Retrospektive”. In diesem Meeting setzt sich das Team und der Product Owner zusammen um festzustellen, welche grundlegenden Probleme es beim Sprint gab bzw. um herauszufinden, wie man in den Sprints besser arbeiten kann. Die Retrosüektive kümmert sich also um die Verbesserung des Teams, der Methoden und Prozesse. Als Ergebnis werden Verbesserungsvorschläge und Maßnahmen in das Product Backlog eingearbeitet.

Nochmal, nochmal

Nach erfolgreichem Abschluß des Sprints geht “das Spiel wieder von vorne los”, d.h. es wird sofort wieder der nächste Sprint geplant und umgesetzt.