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” ;-)

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!

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!

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.

Reflector
Wohl eine der bekanntesten und ebenso hilfreichen Tools. Verwende ich besonders gerne und oft, wenn ich schnell sehen möchte, wie manche Interna des Frameworks funktionieren. Zu Reflector gibt es weitere, in manchen Situationen hilfreiche Add-Ins.

Sandcastle
Die Inline-Dokumentation is um einiges übersichtlicher, wenn sie auch entsprechend visualisiert wird. Sandcastle ist dafür das richtige Werkzeug. Die Handhabung von Sandcastle wird durch die Sandcastle Help File Builder vereinfacht.

NUnit
Obwohl Microsoft schon mit VS2005 ein Test-Framework mitliefert und dieses mit VS2008 sogar verbessert hat, finde ich nach vie vor das NUnit immer noch angenehmer, schneller und funktionsrecher ist. Abgesehen davon, dass man für seine Tests keine dicke VS-Version benötigt.

TestDriven.NET
Das kleine aber feine VS-Add-In, mit dem man auf einen schnellen Rechtsklick wichtige Tools wie NUnitRunner und Reflector griffbereit hat.

Expresso
Regular Expressions kommen immer wieder mal als Tagesordnungspunkt in Projekten vor. Hier habe ich mit Expresso eine gute Unterstützung gefunden.

So, das war’s dann auch mit den Tools. Es bleibt mir noch hinzuzufügen, dass ich natürlich auch versuche, die Fülle an Features, die Visual Studio mit sich bringt, auszuschöpfen. Alleine die wichtigsten Shortcuts zu kennen und anzuwenden beschleunigt das Arbeiten mit Visual Studio ungemein. Des Weiteren sind z.B. die Code-Snippets eine feine Sache – mir fällt es schwer nachzuvollziehen, warum sie von manchen Entwicklern stiefmütterlich behandelt werden. Zumal es obendrein noch die Möglichkeit gibt, eigene Snippets zu erstellen. Auch sollten die Debug-Visualizer bzw. noch allgemeinder der Debugger ansich nicht unerwähnt bleiben. Entwickler, die z.B. von Conditional Breakpoints noch nichts gehört haben, empfehle ich wärmstens eine nähere Beschäftigung mit dem Debugger. ;-)

Um diese Fragen besser beantworten zu können, habe ich meine eigene Art & Weise der Projekt-Dokumentation mit Wikis in einem kurzen Artikel niedergeschrieben. Zugegeben, es ist ein recht minimalistischer Artikel geworden. Trotzdem möchte ich es nicht vorenthalten wissen. Bei Zeiten werde ich mich der Thematik etwas ausführlicher widmen und den Artikel dementsprechend erweitern.

Ich hoffe, das trotz des kurzen Abrisses Rund um dieses Thema meine Arbeitsweise – zumindest das notwendigste – verständlich rüberkommt. Viel Spaß damit!