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! :-)

Zügiger als es mir selbst lieb gewesen ist stellte ich durch meine Tests fest, daß der TagBuilder beim Element-Namen sowie allen Attribut-Namen Groß- und Kleinschreibung beachtet:

[Test]
public void Cms_Tag_With_Invalid_Slot_Returns_Div_Only()
{
  CmsTag cmsTag = new CmsTag();
  int invalidSlot = 0;

  string cmsContainer = cmsTag.GetContainer(invalidSlot);
  Assert.AreEqual("<div></div>", cmsContainer);
}

Der Test sieht ja ganz passabel aus. Aber als ich dann die Methode dazu implementiert habe, ungefähr so:

public string GetContainer(int slot)
{
  TagBuilder tagBuilder = new TagBuilder("DIV");

  if (slot < 1)
    return tagBuilder.ToString();

  // ab hier geht es mit dem echten slot weiter...
}

machte es mich stutzig, dass mein Test immer noch rot war. Wieso? Na klar, ich hatte im Konstruktor des TagBuilders den Element-Namen groß geschrieben ("DIV"), während ich es im Test klein schrieb ("<div></div>"). Hmm. Ich musste überlegen. Warum habe ich denn im Test das DIV klein erwartet?

Na Klar! Meine Gewohnheit hatte mich eingefangen. Denn ich bin es gewohnt, alle Tags und Attribute klein zu schreiben. Nicht nur etwa, weil mir es so besser gefällt - sondern aus einem ganz praktischen und gleichermaßen wichtigen Grund: XHTML.

XHTML verlangt alle Element-Namen und Attribut-Namen explizit kleingeschrieben. Also soetwas wie <DIV ID="test"> ist schon mal grundsätzlich nicht XHTML-konform.

Nach dieser lapidaren Feststellung, dass der Tagbuilder Tags und Attribute so annimmt, wie man sie angegeben hat, machte ich mit Gedanken über das "Wieso". Der Fix hin zur XHTML-Konformität ist ja schließlich trivial. Statt des großgeschriebenen "DIV" im Konstruktor des TagBuilders einfach ein kleingeschriebenes "div" - das sollte es gewesen sein. Doch damit wollte ich mich nicht zufrieden geben. Denn mir war klar, die gleiche Konvention gilt schließlich auch für Attribute. So etwas wie:

TagBuilder builder = new TagBuilder("div");
builder.Attributes.Add("Title", "This is strange.");

würde das Problem wieder hervorrufen. Im Übrigen ist das Problem gerade bei dem schönen "Syntactic Sugar" mit der Kombination Anonymer Typ + Objekt-Initialisierer wirklich mehr als unschön - ich würde sogar sagen absolut störend.

Konsequenterweise kann das nicht der Weisheit letzter Schluß sein. Nach ein paar Minuten gründlicher Überlegung und der Durchsicht des Source-Codes des TagBuilders kam ich zur unweigerlichen Einsicht, dass der TagBuilder nicht (oder nur halbherzig) für XHTML-konforme Dokumente entwickelt wurde. Schade, denn deutliche Hinweise gibt es ja (z.B. mit dem TagRenderMode). Das führt dann unweigerlich zur Frage, ob man generell den TagBuilder umschreiben sollte, oder um einen "XHTML-Konformitätsmodus" erweitern sollte. Im Raum stünden dann drei wesentliche Varianten:

// variante 1 - der existierende tagbuilder wird intern umgeschrieben
TagBuilder builder = new TagBuilder("DIV");
string tag = builder.ToString();

// variante 2 - der tagbuilder wird um einen xhtml-modus erweitert
TagBuilder builder = new TagBuilder("DIV");
string tag = builder.ToString(TagRenderConvention.XHtml);

// variante 3 - es gibt einen speziellen (warscheinlich von tagbuilder geerbten) builder
TagBuilder builder = new XHtmlTagBuilder("DIV");
string tag = builder.ToString();

Auf den ersten Blick würde ich mich persönlich wohl für die erste Variante entscheiden. Denn schließlich bedeutet XHTML-Konformität ja nicht, dass man nicht mehr HTML-Konform ist. Eine "abwärts"- bzw. "schlechtwärts"-Kompatibilität ist also gegeben. Überdies muss man auch bedenken, daß die meisten Websites heutzutage sowieso sich in Richtung XHTML bewegen (müssen). Ein weiterer Aspekt ist sicherlich die Zukunft mit HTML5, welche XHTML als Grundlage hat.

So, nach dem ich jetzt so viele Worte über ein Problem geschrieben habe, welches mit einem einfachen ToLower() lösbar ist, möchte ich noch ein wenig zur Lösung dieser kleinen Schwierigkeit mit Code beitragen. Doch wer jetzt denkt, ich würde ASP.NET MVC patchen, der hat sich getäuscht. Statt dessen habe ich ein kleines Set von Tests zur XHTML-Konformität geschrieben. Wenn alle Tests grün sind, dann ist der TagBuilder auch XHTML-Konform :-).

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!

Für alle, die nicht nur still und leiste in ihrem Kämmerchen Code Kata’s üben möchten. Für alle, die wissen wollen, mit welchen Tricks und Kniffen man mit Design Patterns, Methoden & TDD zu sauberem Design und Code kommt. Für alle, die sich selbst und andere in Punkto professionelle Softwareentwicklung weiterbringen möchten!

Am Mittwoch, den 20.01. werden im .NET Coding Dojo wieder .NET Enthusiasten, Software-Entwickler und System-Analytiker ein Programmierproblem annehmen, in Einzelteile zerlegen und es nach eigener Architektur und Bauplan kunstvoll wieder zusammenführen. Sei dabei!

Event-Details & Anmeldung über das Xing-Event bzw. die Xing-Gruppe.

Phase 1:

Momentan befindet sich der Umbau in Phase 1. In dieser ersten Phase baue ich Wordpress als Blog/Site-Tool ein wenig aus. Der Works-Bereich wird dabei immer noch mit Mediawiki betrieben. Dieser erste Schritt dient der Umgestalung der Website ansich sowie der Vorbereitung im Hintergrund auf die gesamte Verwaltung der Site mit Wordpress.

Phase 2:

In der  zweiten Phase wird der Protierung des Contents von Mediawiki nach Wordpress vorangetrieben, Durch den massiven Content, der im Mediawiki entstanden ist, wird diese Phase wohl etwas länger dauern. Hier möchte ich insbesondere die einzelnen Versionen und die Datumsinformationen beibehalten. Das wird sicher eine kleine Herausforderung.

Phase 3:

Die dritte und letzte Phase ist das sog. “Polishing”. Hier werde ich Mediawiki abschalten und den alten Content archivieren. Darüber hinaus wird die Website noch mit einigen kleinen Features und Gimmicks angereichert werden. Es wird wohl auch so sein, dass das Layout der Website nochmals überarbeitet werden wird.

Ich werde über den Status der Umbauarbeiten natürlich berichten ;-)

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?

Danke nochmals an Gregor & die DNUG für die Organisation und das nette Geschenk! Diese Woche scheint sowieso die “Dojo-Woche” zu werden, denn Morgen geht es schon wieder weiter mit einer neuen Herausforderung im Experten Dojo in München.

Die Anforderungen

• Das Spiel ist zu Ende, wenn alle Felder belegt sind
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Reihe belegt hat
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Spalte belegt hat
• Das Spiel ist zu Ende, wenn ein Spieler eine gesamte Diagonale belegt hat
• Ein Spieler kann ein freies Feld belegen
• Die Spieler belegen so lange ein freies Feld, bis das Spiel beendet ist

Auch die .NET Experten im Coding Dojo München hatten Ihren Spass an dem kleinen Spiel. Es musste natürlich kräftig überlegt und entwickelt werden – ohne Anstrengung geht’s eben nicht :-).

Summa summarum ein gelungenes und nettes KataTicTacToe. Auch zu empfehlen für TDD-Einsteiger. Es gibt jedem die Möglichkeit, eine eigene Lösung zu entwickeln und zeigt dabei die Grundprinzipien des TDD auf. Das Ergebnis der Profis lässt sich im Übrigen auf dem Codeplex-Projekt-SVN begutachten.

Achso, wer Lust hat, nicht nur die ganze Zeit über TDD zu lesen und zu reden, sondern auch mal “hautnah” TDD mit C# und professionellen Softwareentwicklungsmethoden live erleben und mitmachen möchte, für den sind schon die nächsten Sessions im Kalender markiert.

Wie immer sind am Anfang des Monats, genauer am 2. Dezember, die Einsteiger im Dojo gefordert. Zwei Wochen später, am 16. Dezember sind die .NET Experten gefordert, im Coding Dojo ihre gesamte Expertise einzubringen, um die sich selbst gestellte Aufgabe zu meistern.

TDD im Rampenlicht

Naja, das nur nebenbei. Mir geht es eigentlich um ein anderes Thema. Mir geht es um etwas Generelles. Als Pete und ich mit den .NET Coding Dojos angefangen haben, gab es positive Resonanz. Es wurden Dojo’s veranstaltet und Code Kata’s exerziert. Super! Meiner Ansicht nach kam TDD dadurch ein kleines Stück mehr in’s Rampenlicht als es schon durch Clean Code Developer bereits war. In zahlreichen Posts gab es Diskussionen um die Sinnhaftigkeit von Unit Tests, die Kata Berichte und grundlegender Erkenntnisse über TDD. Eine besonders positive Sache, denn Weiterentwicklung und Entdeckung sind schöne Dinge.

Doch eine Sache stört mich. Manchmal stört es mich sogar gewaltig. Dieses Trara und Tamtam um TDD und Beeinflussung des OO-Designs durch Tests und das Entkoppeln von Zustand. Bei dem einen oder anderen Post kann ich mir das Kopfschütteln während des Lesens einfach nicht verkneifen. Die Spitzfindigkeit und unnötige Verkomplizierung einfacher Sachverhalte geht mir zuwider. Für manch einen mag es Anspruch sein, über ein Feuerwerk an Eloquenz einfachste Dinge mit fesselnden Trapezschwüngen der Rhetorik auf das Hochseil des Softewareentwicklungszirkusses zu katapultieren. Die lufterhitzenden Spots, der nervöse Trommelwirbel, der adrenalisierende Schweiß der Konzentration inklusive. Für manch einen. Für mich jedenfalls nicht.

Im Gegenteil. Es stört mich. Es irritiert mich. Denn mich interessiert das Thema selbst. Ich denke es Bedarf keines jonglierens mit DIP, SRP, YAGNI, DRY, um wirklich im Alltag der Software-Entwicklung gut bestehen zu können. Man darf mich hier nicht falsch interpretieren. Auch ich finde es wichtig, sich mit “Dependency Inversion”, “Single Responsibility”, “Decisions on Last Responsible Moment” und “Repetition Avoidance” auseinanderzusetzen, damit umzugehen und täglich einzusetzen.

TDD ist keine “Rocket Science”

Doch man kann es übertreiben. Die ständige, gestelzte und wie ein Ritus sich selbst auferlegte “Tagesreflexionsprogramm” ist meines Erachtens nicht förderlich. Überspitzt betrachtet ist es genau dasselbe wie das Bart-Simpson-Einhämmerungs-Ritual “Ich werde keinen Zustand testen!” – repetitiv, jedoch nicht kognitiv. Wer’s mag, kann ruhig jeden Tag nicht nur Selbstreflexion betreiben, sondern auch jeden Tag ein Code Kata lösen, damit die Entwicklerseele rein wird. Ich jedenfalls werde das nicht tun.

Ich arbeite auch nach Prinzipien, löse Probleme auch mit Patterns und programmiere neben dem Tagesgeschäft ab und an auch mal Code Kata’s. Aber ich bin mir gleichermaßen bewußt, das ich jedes Mittel und Werkzeug richtig einordnen und im richtigen Maß anwenden muss, damit es mich langfristig weiterbringt.

Gleiches gilt für mich auch beim Thema TDD. Ich arbeite nun seit etwas mehr als einem halben Jahr stringent mit TDD. Zuvor habe ich es immer ab und an eingesetzt, aber nie “ernsthaft” betrachtet. Ich finde TDD (und auch BDD) sind eine besonders gute Methodik, um das V in EVA groß schreiben zu können. Es stärkt wunderbar die logischen Bestandteile der Anwendung und fördert mit der granularen Testanforderung lose Kopplung und komponentenorientiertes Design. Mittlerweile ist TDD für mich fester Bestandteil jeder Entwicklungsaufgabe.

Während der ersten Phase, in der ich TDD konsequenter eingesetzt habe, habe ich auch einiges darüber gelesen und durch das “Doing” auch vieles gelernt. So ist es z.B. überhaupt nicht schlimm, wenn man statusbehaftete Tests an den Enden der Datenverarbeitung macht. Konkret: Auch statusbasierte Tests sind ok, vor allem in Richtung DB oder UI. Ein schönes Beispiel dafür ist KataFizzBuzz als WinForms-Anwendung oder KataBlog. Natürlich ist interaktionsbasiertes Testen “schöner”, fördert die lose Kopplung und die isolierte Verifikation. Doch hier gibt es kein Schwarz oder Weiß. Es geht um den Einsatzbereich. Am Rand des Datenstroms ist man mehr statusbasiert, in der mitte eben mehr interaktionsbasiert. Außerdem ist das Thema Statustests vs. Interaktionstests ein relativ “alter Hut”. Schon mit Mocks Aren’t Stubs hat Fowler klar gemacht, dass beides in Ordnung ist.

Diese Zustands-Geschichte ist jedoch nur ein Beispiel. Es gibt da noch einige andere Klassiker: Kapselung, Verkettung, Referentielle Transparenz. Doch ungeachtet dieser Dinge, ist TDD keine Rocket Science. Im Gegenteil, TDD ist in der Kernaussage und Grundregeln so einfach, das sich die anderen “Problemstellungen” automatisch ableiten und auflösen. Gerade deswegen ist es meiner Meinung nach so wichtig, die Dinge einfach zu erklären und und diese “Leichtigkeit” auch zu transportieren. Die Code Kata’s von Dave sind ein Beispiel. Sie sagen nicht “Mach dies! Beachte das!”. Nein, sie sind eigenständige Probleme, auf deren Lösungsweg man individuell und für sich eine gute Lösung findet. Daraus ergeben sich automatisch mit der Zeit Verbesserungen und Erkenntnisse.

Fazit: Beim Verständnis und der Anwendung von Test-Driven-Development gilt, obgleich TDD ein bis Dato empirisch betrachtetes, jedoch theoretisch nicht ausreichend erforschtes Vorgehensmodell ist, das Prinzip von Ockhams Rasiermesser. Der praxisorientierte, frequentive Einsatz sowie das Erkennen der Grundtheoreme der TDD-Methodik sind das Fundament für den erfolgreichen Einsatz.

Und wenn ich das für alle diejenigen, die wie ich auch in der Kommunikation Wert auf Einfachheit legen, mal übersetzen darf:

TDD ist keine Wissenschaft!

Man kann viel darüber Lesen. Das ist auch gut. Besser ist es jedoch, TDD zu machen! Nicht viel über “dies und das” nachdenken. Die Devise lautet: “Mach es einfach, aber nicht einfacher“. Es wird von alleine gut und mit der Zeit sogar besser werden.

Kurz zum KataBlog: Das Kata ist logisch gesehen eine unfassbar einfache Aufgabe. Doch genau das macht das Kata so besonders und zum Teil auch besonders “herausfordernd”. Ein Blog mit ASP.NET MVC im vollen TDD zu lösen ist für Einsteiger eine nicht zu unterschätzende Aufgabe. Ebenso würden wahrscheinlich auch TDD Skeptiker sich mit diesem Kata schwer tun und sich auf den ersten Blick in Ihrer Meinung auch bestätigt fühlen. Doch KataBlog ist wohl (nach KataFizzBuzz) der nächste große Schritt für Neulinge. Die Erkenntnisse aus dem Blog möchte ich dem passionierten Dojo- und Kata-Freund nicht gleich verraten – schließlich ist Selbsterkenntnis eine schöne Sache. ;)

Nun, wie dem auch sei: Im gestrigen Dojo waren wieder einmal gut aufgelegte und aktive Teilnehmer dabei. Zu meiner Überraschung interessierten sich die Teilnehmer sehr viel mehr über grundlegende Technologien wie HTTP, ASP.NET und das ASP.NET MVC als über die eigentliche Aufgabenstellung. Pete reagierte gut, indem er alle nochmals darauf hinwies, dass ein Coding Dojo ein einziges Ziel verfolgt: Die erfolgreiche Vermittlung von nutzbaren Lerneffekten – für jeden Teilnehmer. Er sagte dass ein Dojo keine feste, durchgeplante Veranstaltung mit fixem Programm oder Paradigma sei, sondern dass das Dojo primär die Teilnehmer und den Lerngedanken im Fokus hat. Er stellte die Einsteiger vor die Wahl: Wollen sie mehr über “das Handwerkszeug” ASP.NET & ASP.NET MVC erfahren, oder mehr über die Lösung der Aufgabe per TDD und professionellen Entwicklungs-Prinzipien?

Die Teilnehmer überlegten eine Weile, bevor man sich dann einhellig für eine tiefere Behandlung der Technologie entschied. Pete & ich gingen auf diesen Wunsch ein und erklärten die Technik. Anfangs noch ein wenig theoretisch. Es wurden Fragen beantwortet wie z.B. “Was ist MVC?” oder “Was ist der Unterschied zu Web Forms?”. Nach einem kurzen Theorie-Exkurs am Flipchart ging es dann endlich Hands-On mit ASP.NET MVC auf zum Blog.

Pete zeigte die ASP.NET Templates, die Einbindung der Unit-Test Frameworks NUnit und xUnit in diese und die einzelnen Wizards für den Controller und die Views. Gelöst haben wir dann das Blog indem wir und Stück für Stück mit den Views an die Grundfunktionen “Anzeigen”, “Editieren”, “Erstellen”, “Löschen” und “Auflisten” herangewagt haben. In Anbetracht der Tatsache, dass es so viele Fragen zu MVC gab (Stichwort: Routes, Convention over Configuration, Partial Views usw usf.) ging es auch relativ flüssig durch. Nach knapp 3 Stunden waren wir soweit und hatten den Blog am laufen.

Ich kann jedem empfehlen, der sich mit TDD ernsthaft auseinandersetzen möchte, sich (nach den Erkenntnissen von KataFizzBuzz), die nächste Stufe Richtung sauberen Code und erweiterbarem Design zu erklimmen und das Kata zu lösen. Die Fortgeschrittenen TDD’ler werden schnell sehen, worum es bei dem Kata geht. Ich finde es besonders mutig und gut, dass Pete so eine technisch wie auch methodisch herausfordernde Aufgabe im Einsteiger-Dojo vorgestellt hat. Noch bewundernswerter war allerdings das aktive “erfassen & erkennen” der Teilnehmer, die sich keineswegs davor gescheut haben, sondern die ganzen 3 Stunden über mit voller Konzentration dabei waren. Ich kann nur sagen: Hut ab & Danke!

Was soll ich sagen, mein Fazit wird langsam eintönig, aber es ist nun mal so: In zwei Wochen ist schon wieder Experten-Dojo (18.11.2009 18:00 Uhr) und ich freue mich jetzt schon wahnsinnig. Es wird sicherlich wieder eine erkenntnisreiche, spannende und spassige Sache!

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!

Ich möchte gleich mal eine provokante Aussage in den Raum werfen: Bugtracking für Software-Projekte ist sinnlos. Jedenfalls in den meisten Fällen. Mehr noch, Bugtracking sollte soweit wie nur irgend möglich vermieden werden!

Was will ich damit sagen? Man betrachte einmal das mittlerweile so “selbstverständliche” Tooling bei Software-Projekten: Man nehme ein SCM (z.B. SVN oder git), ein CI-System (z.B. TeamCity oder CruiseControl) und einen IssueTracker (z.B. Bugzilla oder Trac). Man kann das ganze natürlich auch als Gesamtpaket haben, z.B. mit TFS. So, damit hat man die Eckpfeiler einer Software-Entwicklungsumgebung parat und kann frisch und fröhlich programmieren. Ich denke allerdings das dieses Toolset nicht ganz so glücklich gewählt ist.

Bugtracking ist Zeitverschwendung

In einer Zeit, in der viel getan wird, um einen sauberen Code zu produzieren ist meiner Meinung nach die jetzige “Methodik des Bugtrackings” nicht mehr adequat. Entwickler versuchen mit agilen Methoden (teilweise krampfhaft) mehr Qualität und Stabilität in ihre Produkte zu bringen. Ein aktuelles Beispiel ist die Beachtung und Anwendung der Prinzipien der Clean Code Developer Bewegung, die Ihre Kernaussage aus der Craftsmanship-Ideologie von UncleBob schöpft. Darüber hinaus beschäftigt sich die gesamte Softwareentwicklungsindustrie seit Jahren mit Themen wie z.B. Continuous Integration oder Test-Driven-Development, die mitunter das Ziel haben, die Qualität des Softwareproduktes schon während der “Produktionsphase” stetig hoch zu halten. Flankiert wird das ganze auch noch mit agilen Managementmethoden wie z.B. Scrum oder Kanban, die auch einen besonderen Anspruch auf stetige, hohe Qualität legen.

Nichtsdestotrotz findet man in jedem Tool-Setup den altbekannten “Bugtracker” wieder. Wieso? Auf der einen Seite strebt man nach dem “Zero-Defect”, nach hochqualitativer Software. Aber mit dem gleichen Atemzug gibt man sich dennoch geschlagen, indem man von vornherein mit Bugs rechnet. Denn einen Bugtracker zu betreiben ist in den allermeisten Fällen nichts anderes als ein Geständnis. Undzwar das Geständnis sich selbst gegenüber, doch nicht alles “hundertprozentig” zu machen. Es ist ein Widerspruch in sich. Jaaaa, Clean Code, TDD, BDD, DDD und noch eine handvoll anderer bewährter Methoden, von mir aus noch Pair Programming, Continuous Integration / Deployment und Scrum. Aber: Ein Bugtracker muss auf jeden Fall auch her.

Bugtracker ist nicht gleich Liste und schon garnicht Archiv

Man mag mir entgegenbringen, dass mit einem “Issue Tracking”-System nicht nur Bugs verwaltet werden, sondern auch Feature-Requests und ähnliches. Featurelisten sind eine wunderbare Sache, vor Allem wenn man sie priorisieren kann. Aber dazu braucht man keinen Bugtracker. Im Allgemeinen reichen einfachere Tools aus.

Das am meisten erwähnte Gegen-Argument ist wohl, das man mit dem Bugtracker die Bugs “verwalte”, um sie ja nicht zu vergessen und Ihnen angemessene Priorität zu geben. Lächerlich! Eine Farce, denn in der professionellen (wirtschaftlich orientierten) Softwareentwicklung ist solch ein Ansatz absolut kontraproduktiv. Erstens schafft es einen weiteren Verwaltungs- und Organisationsapparat, den es erst mal zu bewältigen gilt. Zweitens mutiert es mit der Zeit zu einer Halde (ich will schon fast sagen Müllhalde) von unwichtigen Bugs und Feature-Requests, die man irgendwann einmal angehen will. Drittens stellt es automatisch und implizit ein Konkurrenzsystem zur Roadmap dar. Warum?

Na ganz einfach: wenn ein Bug wirklich ein wichtiger Bug ist, dann wird er sofort gefixed. Alles andere ist entweder nicht wichtig oder wird dann erst wichtig, wenn die wichtigeren Dinge schon erledigt sind. So einfach ist das.

Außerdem: Gefühlt implementiert nahezu jeder, der was auf sich hält seine Software mit agilen Methoden und Praktiken. Scrum und XP sind schon längst angekommen; und mit TDD und Clean Code wir bewegen uns auf einem hohen Niveau, oder nicht? Unsere Grundmotivation ist es doch, fehlerfreie Software auszuliefern, oder nicht? Ok, 100%ig gibt es nie, aber wir streben doch zumindest die three nines der “High Quality” an, oder nicht? Ich denke schon – zumindest ist das mein Verständnis. Wenn dem so ist, warum brauchen wir dann ein Bugtracking-Tool?

Bugreporting ist wichtig, Bugtracking jedoch unwichtig

Ich möchte mit meiner provokanten Aussage nicht erreichen, das man grundsätzlich das Issue Management anzweifelt. Es ist eher das Gegenteil der Fall. Ich stärke sogar die Wichtigkeit & Effizienz, zumal nach wie vor ein richtiges Bugreporting und eine Bug Triage entscheidend sind, um die richtige Entscheidung treffen zu können. Mein Augenmerk gilt der Bugverwaltung an sich, also der zentralisierten Auflistung, Verwaltung und Archivierung von Fehlerprotokollen. Im Lean Management sind zentrale Prozesspunkte ein “rotes Tuch”. Statt dem sternförmigen Kommunikations- und Prozessmodell wird dort das, Netzmodell favorisiert. Dieser Ansatz ist meiner Meinung nach besonders auf das Issue Management anwendbar.

Natürlich kann ich nicht generell sagen, dass ein Bugtracking-Tool sinnlos ist. Es gibt immer wieder Situationen und Rahmenbedingungen, die auch ein Bugtracking-Tool und eine zentrale Fehlerverwaltung rechtfertigen. So ist es z.B. bei einem Produkt, bei dem die User-Gemeinde aktiv die Bugs berichten und einsehen kann sicherlich sinnvoll, ein Bugtracking-System einzusetzen. Allerdings ist es nur in den seltensten Fällen wirklich notwendig.

Man könnte ein Bugreporting auch derart gestalten, dass man sich beim Reporter für den Bericht bedankt und ihm verspricht, das Problem zu analysieren. Dann schaut man sich den Fehler an. Ist er wichtig genug, wird er sofort gefixed – und der Benutzer ist glücklich. Ist er nicht wichtig genug (also ist entweder ein anderer Bug oder ein anstehendes Feature wichtiger), so wird der Report weggeworfen. Der Benutzer wird benachrichtigt dass der Fehler momentan nicht korrigiert wird. Ehrlich, sachlich, klar. Der Berichterstatter kann nun nochmals (mit Vehemenz) darauf pochen, den Fehler behoben zu wissen. So kann man z.B. bei benutzerorientierten Produkten auch ein Voting einsetzen (wie z.B. bei Codeplex). Erhöht sich das Voting (die Priorität) nicht, wird der Bug nicht gefixed und weggeworfen. That’s it.

Es gibt nur ein Go oder Nogo für einen Bugfix

Ich bin der festen Überzeugung das diese Verfahrensweise vor Allem dann effizient ist, wenn man in der Software-Entwicklung agile Methoden anwendet. Für mich sind Software Craftsmanship, TDD, XP und all die weiteren modernen Methoden einfach nicht mit dem veralteten Zentralverwaltungs-Muff “Bugtracking” vereinbar. Statt dessen sollte man ein leichtgewichtiges Bugreporting etablieren und die Entscheidung über den Fix oder No-Fix des Bugs schnell herbeiführen. Nur so kann man sich selbst dazu erziehen, von Anfang an in der Software-Entwicklung das Qualitätsbewusstsein zu schärfen und die Qualität konstant adequat hoch zu halten. Denn nur mit dieser “KO-Entscheidung” über den Fix eines Bugs kommt man (leidend, aber relativ schnell) zu der Erkenntnis, dass man wenn man wirklich das Produkt stetig weiterentwickeln möchte auch immer sich zum Ziel setzen muss, ein möglichst fehlerfreies Produkt auszuliefern.

Die Erkenntnis, Bugs nicht zu verwalten und sofort zu entscheiden, ob es gefixed werden soll oder einfach ignoriert werden soll ist meiner Meinung nach ein wichtiger Bestandteil für qualitative, agile Software-Entwicklungs-Methoden.

Ergo: Bugtracking ist sinnlos!

Dabei hatte das Münchner Dojo viel “Event-Konkurrenz”: Der Joint-Launch von Microsoft, der Twittwoch und das unnachahmliche Herbstwetter mit 25 Grad!. Um so erfreulicher, das sich die Teilnehmer nicht davon abhalten liessen mit mir zur Feierabendzeit noch eine geistige Trainingseinheit im Dojo hinter sich zu bringen. Ich bin als Master kurzfristig für den erkrankten Pete eingesprungen – an dieser Stelle Gute Besserung! Ich hoffe ich konnte einen adequaten Ersatz darstellen.

Zum Dojo: es gab drei Code Kata’s zur Auswahl: Minesweeper, der im Experten-Dojo gelöste Taschenrechner und das mittlerweile beliebte FizzBuzz, jedoch reinkarniert als Windows-Forms-Anwendung.

Die Teilnehmer entschieden sich für FizzBuzz im Windows-Forms-Gewand. Vorlage für diese Übung war die iPhone-Implementierung. Eine gute und herausfordernde Wahl, wie sich im Nachhinein herausstellen sollte.

Zum “Warmwerden” haben wir zunächst das klassische Kata gelöst. Diesmal ging es etwas zügiger von der Hand als beim ersten Mal, was unter Anderem auch an den Wiederkehrern lag. Anschliessend ging es an die UI.

Test-Driven UI-Entwicklung. Geht das überhaupt?

Doch Halt! Wie soll denn das jetzt mit purem Test-Driven-Development gehen? Die Einsteiger waren ein wenig vor den Kopf gestossen, denn die Frage im Raum war klar: Wie kann ich Test-First eine UI für ein Programm entwickeln? Die Antwort war jedoch alles andere als deutlich.

Tom – der als einziger Experte im Einsteiger-Dojo mit dabei war, was mich besonders gefreut hat – half den Einsteigern ein wenig, indem er sagte: “Eine UI ist nicht ohne Weiteres testbar.” Die Teilnehmer vertrauten der Aussage des Profis und zuckten mit den Schultern, als es darum ging, eine Testklasse für das Windows-Form zu schreiben. Nach der von Tom im Kern korrekten Anspielung auf UI-Tests habe ich versucht, den Fokus etwas zu verschieben.

Ich stellte folgenden provokanten Satz in den Raum: “Die Benutzeroberfläche ist nicht testbar. Gut. Aber ist denn wirklich nichts testbar? Ich meine, wie ist es z.B. mit der Interaktion? Ist die Interaktion testbar?”

Dazu habe ich nochmal die Referenz-Anwendung gestartet und gezeigt, mit der Bitte, sich die Interaktionselemente der Anwendung – vielmehr die Interaktion mit der Benutzeroberfläche – nochmals genau anzusehen.

Im Wesentlichen besteht das “Spiel” aus drei Eingabefeldern (Buttons). In der Mitte wird die Zahl dargestellt, für die es die “FizzBuzz-Frage” zu beantworten gilt. Klickt man auf die Zahl, ist die Zahl die Antwort. Oben drüber und unten drunter werden die Antwortmöglichkeiten “Fizz” und “Buzz” dargestellt. Klickt man darauf, so ist selbiges die Antwort.

Abstraktion der Benutzeroberfläche zu Interaktionsanforderungen

Am Anfang war deutlich zu spüren, dass es schwer ist, eine konrektes User Interface soweit zu abstrahieren, dass man nur noch in “Interaktionen” zwischen dem Benutzer und dem Programm denkt. Auf die Frage wie denn die erste Testmethode heissen soll, “verirrten” sich einige Male ein paar Teilnehmer wieder in die konrekte UI (z.B. mit Antworten wie “ClickOnFizzButtonWhenThreeIsDisplayed”).

Doch mit ein paar kleinen Hilfen und gemeinschaftlicher Denkleistung konnten die Teilnehmer aus o.g. Interaktionsanforderungen heraus tatsächlich Tests formulieren. Genau diese Momente waren es, der dem Dojo die richtige Würze in Sachen Lerneffekt gab. So schreibten wir ohne die UI oder etwas anderes implementiert zu haben z.B. folgende Tests:

        [Test]
        public void IncrementsNumberWhenAnswered()
        {
            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();

            fizzBuzzGame.Start();
            fizzBuzzGame.Answer("1");

            Assert.AreEqual(2, fizzBuzzGame.CurrentNumber);
        }

        [Test]
        public void CorrectAnswerReturnsTrue()
        {
            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();

            fizzBuzzGame.Start();
            bool isCorrect = fizzBuzzGame.Answer("1");

            Assert.AreEqual(true, isCorrect);
        }

Deutlich erkennbar ist natürlich, dass nach wie vor die UI ansich (also das WinForm, die Buttons etc) natürlich nicht testbar sind. Aber das ist ja auch nicht der Sinn der Sache! Denn das Ziel und der Zweck von Test-Driven-Development ist nicht die Verifikation, sondern die eigentliche Entwicklung des Codes! Schnell fand die Gruppe heraus, dass die Implementierung der FizzBuzzGame-Klasse sich um ganz andere Verantwortlichkeiten kümmert, als die FizzBuzz-Klasse (der eigentliche Algorithmus).

Die Abstraktion der Interaktionen führte zur Implementierung einer Klasse mit der Eigenschaft CurrentNumber sowie den Methoden Start und Answer. Schnell waren die wichtigen Tests geschrieben und die Klasse implementiert, so dass man sich der Verknüpfung der “Interaktionsklasse” zur eigentlichen UI widmen konnte. Das Verbinden erwies sich als wunderbar einfach:

        private void buttonFizz_Click(object sender, EventArgs e)
        {
            bool isCorrect = this.game.Answer("Fizz");

            if (!isCorrect)
            {
                MessageBox.Show("Wrong answer", "Ooops!", MessageBoxButtons.OK);
            }

            this.buttonNumber.Text = this.game.CurrentNumber.ToString();
        }

        private void buttonBuzz_Click(object sender, EventArgs e)
        {
            bool isCorrect = this.game.Answer("Buzz");

            if (!isCorrect)
            {
                MessageBox.Show("Wrong answer", "Ooops!", MessageBoxButtons.OK);
            }

            this.buttonNumber.Text = this.game.CurrentNumber.ToString();
        }

Natürlich kann man hier noch wunderbar refaktorisieren und den überschüssigen doppelten Code eliminieren. Aber für’s erste soll das Mal genügen, denn jeder wollte ja sehen, ob das Spiel denn wirklich auf Anhieb spielbar war. Also schnell kompiliert und gestartet.

Tatsächlich! Es funktioniert! Die Begeisterung der Teilnehmer war förmlich aus den Gesichtern zu lesen, als wir fröhlich das FizzBuzz-Spiel Zahl für Zahl spielten… “Zwölf ist Fizz”… “Dreizehn ist Dreizehn”… “Vierzehn ist Vierzehn”… Oh! Halt. Für die Fünfzehn muss ich ja “FizzBuzz” antworten, wie soll denn das gehen?

Schnell wurde wieder die IPhone-Referenz-Anwendung gezückt und durchgespielt… “Zwölf ist Fizz”… “Dreizehn ist Dreizehn”… “Vierzehn ist Vierzehn”… und “Fünfzehn ist Fizz und Buzz”. Aha! Die “FizzBuzz” Antwort besteht also aus einem Klick auf “Fizz” gefolgt von einem Klick auf “Buzz”! Klar. Doch wie lässt sich das in unserer Anwendung lösen?

Verwirrung machte sich breit: “Wieso ist uns das beim ersten Mal nicht aufgefallen!?!” fragte man sich. Nun sei’s drum, die Beantwortung mit Hilfe von zwei aufeinanderfolgenden Klicks ist das derzeitige Problem das es zu lösen gilt. Unter anderem kam der Vorschlag, man müsse einen Timer im Form einführen, der bei dem Klick auf “Fizz” gestartet wird und auf den nächsten Klick wartet, so dass man die “FizzBuzz”-Antwort abgeben kann. Viele Teilnehmer konzentrierten sich darauf, diese Besonderheit in der UI bzw. im Code-Behind des Forms zu lösen.

Test-Driven-Development als Wegweiser

Nach einigen Minuten angeregter Diskussion kam ein Einwand von Kai: “Wir haben für die ersten Interaktionen doch Tests geschrieben, dann sollten wir das doch für diesen Fall auch können oder?”. Der Vorschlag fand sofortige Zustimmung. Also auf in die Testklasse und kräftig überlegt, wie man diese Interaktion testen kann. Das Ergebnis waren eine Reihe von Tests, die sich um den “zweistufigen” Antwort-Prozess kümmerten. Auszug:

        [Test]
        public void FizzBuzzIsAnsweredInTwoSteps()
        {
            FizzBuzz fizzBuzz = new FizzBuzz();
            Dictionary values = fizzBuzz.Count();

            FizzBuzzGame fizzBuzzGame = new FizzBuzzGame();
            fizzBuzzGame.Start();

            for (int i = 1; i <= 14; i++)
            {
                fizzBuzzGame.Answer(values[i]);
            }

            fizzBuzzGame.Answer("Fizz");
            fizzBuzzGame.Answer("Buzz");

            Assert.AreEqual(16, fizzBuzzGame.CurrentNumber);
        }

Es folgte die Implementierung der Anforderung in der FizzBuzzGame-Klasse - so wie es davor auch der Fall war. Die Lösung der Problemstellung war an und für sich trivial: Es wurde in der Klasse ein Antwort-Status eingeführt, mit dessen Hilfe man erkennen konnte, ob eine zweistufige Antwort notwendig ist und natürlich ob die zweistufige Antwort korrekt gegeben wurde.

Doch das entscheidende an dieser Herausforderung war nicht die Implementierung selbst, sondern wiederum die Erkenntnis, das uns TDD wieder einmal den Weg in die richtige Richtung gezeigt hat. Statt der ad-hoc Vorschläge, einen Timer im Form zu haben oder irgendwie den Status innerhalb des Codebehinds des Forms zu implementieren, half uns TDD, die Anforderung gekapselt in der FizzBuzzForm-Klasse umzusetzen.

Das Resultat: Keine einzige Änderung im Codebehind des Forms! Und trotzdem eine Änderung des Interaktions-Verhaltens des Spiels! Ergo: eine rundum saubere Sache: klare Verantwortlichkeiten, eine jederzeit austauschbare View (das Form), ein vollends getesteter Presenter (die FizzBuzzGame-Klasse) sowie das ebenfalls in TDD entwickelte Model (die FizzBuzz-Algorithmus-Klasse). TDD hat es den Einsteigern (wohlgemerkt keine langjährigen Entwicklungsprofis!) ermöglicht, ein gängiges und äußerst hilfreiches Pattern in der Windows-Forms-Entwicklung anzuwenden, ohne jegliche Kenntnis vom Design Pattern zu haben.

Fazit: Ein Super Dojo! Ich war wirklich begeistert, dass es uns im Einsteiger-Dojo gelungen ist, das Fundament von TDD zu vermitteln: Nicht testen um zu verifizieren, sondern testen um zu entwickeln! Gleichzeitig war das Windows-Forms-Kata ein Paradebeispiel für Seperation of Concerns und der "intuitiven" Entwicklung der Grundzüge des MVP-Patterns. Vielen Dank an alle Teilnehmer, es war Klasse!

Ich freue mich schon heute auf das nächste .NET Coding Dojo für Experten am 21. Oktober!. Das wird bestimmt wieder ein besonderer Spass. Seid dabei!

Ich hatte mir für das erste Experten-Dojo zwei Dinge auf der Agenda. An erster Stelle stand nochmals die Implementierung des FizzBuzz-Katas auf dem Programm. Nach dem Dojo hatte ja auch schon Ralf das FizzBuzz Code Kata implementiert. Also dachte ich mir, zum aufwärmen ist das bestimmt eine gute Aufgabe.

Wir haben uns an die Aufgabe im Modus “Randori” herangewagt. Ich muss sagen, für diesen allerersten Versuch, eine Code Kata per Randori zu lösen lief es erstaunlich gut. Schnell haben alle Teilnehmer festgestellt, dass es eine Übereinstimmung über die Herangehensweise der Implementierung geben muss. Die Tests waren trivial und dementprechend weniger Gegenstand der Diskussion.

Darüber hinaus war es interessant zu beobachten, dass auch bei der geballten Ladung an Kompetenz und Erfahrung die Implementierungsgeschwindigkeit sich nicht daramatisch verkürzt. (Zum Vergleich: Im Einsteiger-Dojo wurde FizzBuzz in ca. 2 Stunden gelöst, die Experten Runde hat knapp 1 Stunde gebraucht). Der Grund dafür sind vorrangig weiche Faktoren wie Teamfindung und -bildung. Aber auch fachliche Bremsspuren waren zu beobachten: Die Teilnehmer haben sich z.T. bei der Implementierung um Designfragen gekümmert – wohl mit den Gedanken der Wierderverwendbarkeit und Generalisierung im Hinterkopf. Dieser Hauch von “Design-Upfront” wurde aber schnell erkannt und ausgeräumt.

Nach einer kurzen Denk- und Verschnaufpause haben wir uns an das zweite Code Kata “RPN Calculator” herangewagt. Dabei geht es um die Simulation eines Taschenrechners, welches mit umgekehrt polnischer Notation arbeitet.

Nach der Vorstellung des Kata und der dazu gehörigen Akzeptanzkriterien ging es wieder mit Schwung los. Unterschied zum ersten Mal: Es wurde nicht sofort mit den Tests losgelegt, sondern in der Runde eine grundsätzliche Einigung über das Verständnis der Aufgabe und damit “grobe” Design der Implementierung herbeigeführt. Erst dann ging es los mit dem klassischen TDD. Test – Rot – Implementieren – Test – Grün – Refaktorisieren – Test – Grün.

Nach der Implementierung der Grundfunktionalität (die Addition und Subtraktion waren funktional korrekt), ging es ans Refaktorisieren. Hier wurden zur Beseitigung von Code-Redundanz in mehreren Methoden einer Klasse zwei Lösungsansätze verfolgt.

Template Methode

Der zweite Lösungsweg war im Gegensatz zum ersten ein ein äußerst effektiver: Die Übergabe einer Lamda-Funktion auf eine private “Template Methode”. Im Endeffekt die selbe Lösung, halt funktional statt orientiert an der “reinen” OO-Lehre:

...
public void Add()
{
    this.Calculate((x, y) => x + y);
}

private void Calculate(Func<decimal, decimal, decimal> op)
{
   /* get x somewhere */
   /* get y somewhere */

   decimal result = op(x, y);

   /* put result somewhere */
}
...

Ich möchte jetzt nicht zu sehr ins Detail eingehen – jedoch war deutlich erkennbar, dass die Teilnehmer für beide Lösungswege offen waren – abhängig vom gegebenen “realen” Kontext würde man die eine oder andere Verfahrensweise bevorzugen.

Abschliessend kann ich nur sagen, war dieser erste .NET Coding Dojo für Experten ein gelungenes Event – nicht zuletzt wegen der regen und aktiven Beteiligung der Teilnehmer. Ich finde diese Art des Lernens, Informationsaustausches und “Networkings” zunehmend attraktiv und spannend. Das macht Lust auf mehr!

Ich freue mich schon auf das nächste .NET Coding Dojo! Hier nochmal die nächsten Termine für die Dojo’s in München: am 7. Oktober das .NET Coding Dojo für Einsteiger und am 21. Oktober das .NET Coding Dojo für Experten! Auf geht’s: jetzt anmelden via Ning oder Xing! Ich bin dabei!

Ich (als @ilkerde) bin ja mittlerweile auch “auf den Zug” aufgesprungen und möchte hier mal meine Eindrücke wiedergeben.

Zunächst einmal denke ich das der Hype um das Gezwitschere nicht berechtigt ist. Abgesehen von der trivialen Idee & Technologie ist Twitter für mich grundsätzlich kein neues Kommunikationsmedium. Es ist eine Symbiose aus Broadcast-SMS, Blog (RSS-Feed) und Chat. “Microblogging” als neues digital-soziales Sprachrohr – “Nein”, würde ich sagen. Wohl eher eine weitere Trendform der invertierten Informationsbeschaffung.

Eine Form der invertierten Informationsbeschaffung

“Ich suche nicht mehr die Information, die Information kommt zu mir” – sagt Heiko Ditges, wohl mit einer der wichtigsten Social Media Experten Deutschlands. Naja, das mag ja schön und gut sein. Aber Twitter ist längst kein Kommunikationmittel mehr, mit dem soziale Kontakte gepflegt werden. Twitter ist auch ein weiterer Schritt in Richtung Vermarktung der sozialen Lebensbereiche. Das mag für den einen oder anderen erschreckend wirken – ist aber meiner Meinung nach nicht so schlimm, wie es aussieht.

Der Kommerz hat uns in vielen Lebensbereichen längst eingeholt – sei es “klassisch” im Flimmerkasten, dem Handy, dem Computerspiel oder eben auch bei sozialen Aktivitäten. Es gilt mit den Medien, in die der “Kommerz” zu uns dringt, richtig umzugehen. Die oft besagte und mystische “Medienkompetenz” ist der entscheidende Schlüssel, um Community-Plattformen wie XING, Facebook oder StudiVZ effektiv und in geordnetem Maß zu nutzen. Meiner Meinung nach gilt das selbe auch für “neue” Kommunikationsformen wie Twitter.

Wir werden Omnimedial, alle gemeinsam

Meidenkompetenz hin oder her, es schlägt sogar mir als aufgeschlossenen, omnimedial kommunizierenden auf den Magen wenn ich alle paar Tage Spam-Follower blockiere, ausschliesslich Retweets lese oder sehe, wie mittlerweile nahezu jedes Unternehmen tweetet und dies sogar akribisch – in gewissem Maße auch “strategisch” – für die Vermarktung der eigenen Produkte nutzen möchte. Der Twitterzug ist nun mal am Rollen und jeder möchte mitfahren. Buzzwords wie Enterprise 2.0 und Social Media Awareness sind kaum mehr aus Marketing Jour-Fixe’s wegzudenken.

Wichtig ist hierbei die Erkenntnis, das “Medium Microblogging” nicht für o.g. Kommerzialisierungsbewegungen verantwortlich zu machen. Medien werden immer Zielscheibe der Vermarktung sein und bleiben. Radiowerbung, Fersehwerbung, Onlinewerbung und eben auch “soziale Werbung”. Twitter ist trotzdem für mich und andere interessant, genauso wie Millionen von Menschen “Wer wird Millionär” gucken, obwohl sie alle 10 Minuten mit Werbung berieselt werden.

In genau diesem Maße macht es auch Sinn, zu zwitschern und aktiv an der digitalen Gesellschaft teilzunehmen Das erst kürzlich stattgefundene Twestival in München ist ein Paradebeispiel für die effektive Nutzung der Twitterei. Natürlich ist auch hier der unaufdringliche Duft des Kommerz, des viralen Vermarktens und Networkings in der Luft. Aber – und das ist entscheidend – es ist eine maßvolle, sowohl für die Sache, für die Gesellschaft und für den einzelnen Teilnehmer verwertbare Aktion.

Darüber hinaus denke ich wird das Microblogging in absehbarer Zeit wieder an Attraktivität verlieren. Es ist kein Medium der Neuzeit, sondern eine einfache, in meinen Augen zu einfache Drehscheibe für Nachrichten. Keine Semantik, eine unscharfe Selektion der Information und die mehrheitliche Fokussierung auf den “Anreiz” zum Klick auf die durch bit.ly und Konsorten gekürzten Links machen Tweets zu einem Trend – aber nicht zu einer ernst zu nehmenden Kommunikationsplattform. Twitter: Interessante Menschen, Interessante Themen – aber keine soziale und mediale Revolution.

Besonders gut fand’ ich persönlich das Pete am Anfang besonderen Wert auf die Unit Tests gelegt hat. Dies hat allen gezeigt, wie gut und produktiv testgetriebene Entwicklung funktionieren kann. Ein weiterer dicker Pluspunkt war die Offenheit der Teilnehmer – alle waren von Anfang an bei der Lösungsfindung dabei. Es war wirklich interessant festzustellen, wie verschiedene Ansätze zum lösen der Aufgabe gesucht und gefunden wurden.

Nachdem die Grundfunktionalität des “FizzBuzz”-Generators implementiert war, hat Pete den 2. Gang eingelegt und uns alle zu ein wenig mehr OO-Design aufgefordert. Die Anforderung, “schreibe den Generator so, dass beliebig viele Bedinungen hinzugefügt werden können” hat am Anfang schon ein wenig Kopfschmerzen verursacht. Dennoch war das Team schnell auf der richtigen Fährte und hat die einzelnen Bedingungen in eigene Filter-Klassen refaktorisiert.

Ach was soll ich sagen, es war ein gelungener Coding-Abend, vor allem weil die Atmosphäre gestimmt hat und das Thema immer spannend blieb.

Danke an alle Teilnehmer, er hat wirklich Spass gemacht! Hoffentlich auf Bald in einem der nächsten Dojo’s, am 23. September 2009 Meijin für Experten oder am 07. Oktober 2009 Shinzan für Einsteiger! Ich freue mich schon auf das erste Experten-Dojo.

Let’s Code In Dojo!

Dabei sind es meist die Unternehmen, die sich schon bei der formalen Prozessadaption schwer getan haben. Eine kleine Matrix verdeutlicht dieses Dilemma:

Sowohl agile Propzesse als auch geführte Prozesse liefern gute Projektergebnisse, wenn sie verstanden sind und nicht ad-hoc oder bürokratisch umgesetzt werden. Das Problem ist hierbei allerdings, das gerade Unternehmen, die die “neuen” agilen Prozesse adaptieren, in der Transitionsphase besonders unter der limitierten Prozessfähigkeit leiden.

Genau in dieser Phase empfindet man beide Vorgehensmodelle als nicht zielführend. die Arbeitsabläufe sind chaotisch & bürokratisch gleichermaßen. Abhilfe schafft da nur die Konzentration auf ein Vorgehensmodell und die konsequente Stärkung der Prozesskenntnisse. Nur dadurch erreicht man die gewünschte Qualität & Effizienz.

Steve Sanderson beantwortet diese Fragen in seinem Unit Test Best & Worst Practices Artikel äußerst anschaulich. Ich möchte hier dennoch einen kurzen Abriss über die Fragestellung und seine Antworten geben.

Zunächst einmal sollte die Eingangsfrage geklärt werden: Wozu Unit Tests? Ganz einfach: Um konsequent stabile Software entwickeln zu können. Bei Unit Tests geht’s also nicht um Fehlerfindung (jeglicher Art), sondern um eine Entwicklungsmethode, von vornherein Komponenten einer Software funktional korrekt und technisch stabil zu entwickeln. Unit Tests helfen auch deutlich bei der Verwaltung und Veränderung von Komponenten (z.B. durch Extensions oder Refactoring), um Instabilitäten während Refactorings zu erkennen und zu beheben.

Gute und schlechte Unit Tests

Damit kommt man auch unweigerlich zur nächsten Problemstellung. Wie kann ich Unit Tests anwenden, dass Sie mir dabei helfen, stabile Software zu entwickeln? Einfacher grafragt Was sind “gute”, und was sind “schlechte” Unit Tests? Steve beantwortet diese Frage aus der TDD-Sicht. Für ihn sind Unit Tests besonders dann gut, wenn sie ausschliesslich eine funktionale Beschreibung der Software-Komponente abbilden. Das kann man natürlich besonders dann gut machen, wenn man nichts über die Art und Weise der Implementierung der Funktionalität kennt, also klassisches TDD Test-First betreibt.

Ein ebenso guter Test (welches man mit Unit Testing Werkzeugen abbilden kann) ist ein echter Integrations-Test. Bei dieser Art von Tests wird nicht die Software in ihren einzelnen Bestandteilen (Klassen, Komponenten) betrachtet, sondern als Ganzes aus der Sicht des Benutzers. Es werden funktionale Bereiche getestet, ohne die Implementierung der Software zu kennen. Diese Integrations-Tests sind besonders hilfreich Regressionen des Systems festzustellen.

Damit ist auch beantwortet, welche Unit Tests nun schlechte sind: alle anderen. Im Alltag spiegelt sich das durch Tests wieder, die zu sehr auf die Implementierung eingehen (z.B. ein *Returns_Not_Null Test), auf die technischen Elemente (z.B. ein *Db_User_Created Test) oder eine komische Mischung aus reinem Unit Test und Integrations-Test sind.

Unit Tests sind Katalysator für komponenten-orientierte Software

Die Beurteilung über schlechte und gute Unit Tests ist im täglichen Einsatz von Unit Tests immer wieder in den Vordergrund zu rücken, denn dadurch lässt sich auch einiges über das System-Design und die Software-Architektur sagen. Ein System, welches das schreiben und verwalten von Unit Tests leicht ermöglicht, bei dem die Unit Tests reine Funktionalitäten testen, bei dem Unit Tests nicht von anderen Tests oder sogar der Laufzeitumgebung abhängig sind ist ein deutlich auf den Grundkonzepten der Objekt- und Komponentenorientierung aufgebautes System. Die Kohäsion ist im Mikro-System sehr hoch, um Makro-System sehr niedrig. Ein Austausch einer Komponente ist problemlos, aber funktional immer wirkend.

Sind die Symptome jedoch, dass man für die Erstellung der Unit Tests schon Zielbereiche suchen muss, das Unit Tests nur rudimentäre fachliche Aussagen treffen oder das Verwalten der Test Suite mit zunehmender Test-Anzahl immer aufwendiger und schwieriger wird, dann kann man daraus ableiten, dass das System-Design der Software tendenziell nicht auf Komponentenorientierung ausgelegt ist. Überdies lässt sich weiter schlußfolgern, dass das System mit hoher Wahrscheinlichkeit die Prinzipien “Single Responsibility” und des “Divide & Conquer” missachtet.

Schmerztherapie Unit Tests

Besonders bei existierenden Systemen, bei denen die Weiterentwicklung strategisch wichtig ist und die ökonomische Effizienz gesteigert werden soll, sind echte, gute Unit Tests ein mittelfristig starkes Werkzeug, um das gesamte System effizienter und stabiler zu gestalten. Damit ist nicht nur die Funktionalität (Integrity) oder Defekt-Quote (Defect Rate) gemeint, sondern im Besonderen der Verwaltungsaufwand (Maintenance), die Weiterentwicklungskosten (Features) und die hochgelobte niedrige Reaktionslatenz zum Markt (Time To Market). Manchmal ist es schwer Unit Tests zu schreiben, weil man grundlegende Systemkomponenten anders aufbauen und strukturieren muss, um diese testbar zu machen.

Manchmal ist es schwer, Tests für Dinge zu schreiben, deren Implementierung nicht bekannt ist. Manchmal ist es schwer, die geänderte Grundfunktionalität in dutzenden Tests nochmals zu adaptieren. Doch am Ende wird man belohnt mit schnellerer Feature-Entwicklung und einer besonders vertrauenswürdigen, stabilen Software.

Unit Testing tut gut, auch wenn es weh tut.

Der Hands-On-Aspekt – also wenn es um das klassische “Learning by Doing” geht – ist hier leider nicht immer gegeben. Besonders .NET Einsteiger tun sich schwer und probieren Sachen zu Hause so lange aus, bis es für sie zu passen scheint. Aber auch eingefleischte .NET Cracks brauchen den Austausch mit anderen, um ihr Toolset und den Methodenraum zu erweitern.

Nach einigem hin und her, Gesprächen mit Freunden und Kollegen haben wir uns nun entschlossen, die .NET Community mit einem .NET Coding Dojo zu bereichern. Wir werden ab September jeden 1. und 3. Mittwoch von 19-21 Uhr Coding Dojos für .NET – im speziellen mit C# – veranstalten. Dabei wird der erste Mittwoch des Monats zugeschnitten sein für “Learners”, also Leute mit wenig C# und .NET Erfahrung. Der dritte Mittwoch im Monat ist der “Masters” Dojo, in dem komplexere Themen, Patterns und Toolsets behandelt werden. Bei beiden Dojos geht es natürlich um die Entwicklung in .NET und C#, halt nur auf einem anderen Level.

Übrigens, die Dojo’s wurden von uns absichtlich für extreme Levels ausgelegt. Wir sind der Meinung das gerade Anfänger die praktische Erfahrung brauchen, um sich mit der Sprache und den Tools auseinanderzusetzen und Sicherheit im Umgang mit dem .NET Framework zu haben. Gleichermaßen denken wir, dass besonders hocherfahrene .NET Entwickler den gleichen “Bedarf” an praktischem Austausch haben, um sich mit Ihren Tools und Methoden im Exzellenz-Bereich zu verbessern.

Die Dojo-Veranstaltungen werden in den Räumen von AutoScout24, Rosenheimer Strasse 143d, durchgeführt. Vielen Dank an dieser Stelle nochmal an Matthias Patzak von AutoScout24, der uns die Räume und organisatorischen Grundlagen zur Verfügung stellt.

Die erste Veranstaltung findet am 9. September statt und ist das erste Beginners Dojo, geleitet von Pete. Für Anmeldung zu den Veranstaltungen, Kontakt, Austausch von Code & Anregungen einfach zur MucNetDojo Group oder eine Email an die Gruppe schicken.

Auf einen Blick, Fragen & Antworten

F: Was ist ein Coding Dojo?
A: Ein coding Dojo ist eine Session, in der alle gemeinsam eine Programmieraufgabe lösen. Siehe: http://codingdojo.org

F: Wann findet das .NET Coding Dojo in München statt?
A: Jeden 1. und 3. Mittwoch. Der 1. Mittwoch für “Starter” (Unerfahrenere), der 3. Mittwoch für “Master” (Experten)

F: Wo kann ich mich anmelden?
A: Viele Wege führen zum Ziel

• Einfach Kommentar auf diesen Artikel schreiben, oder
• über die Google Gruppe http://groups.google.com/group/mucnetdojo (Gruppenverteiler), oder
• über die XING-Event Liste
  Starter: https://www.xing.com/events/net-coding-dojo-munchen-starter-386036
  Master: https://www.xing.com/events/net-coding-dojo-munchen-master-386038

F: Wo und wann ist die erste Coding Dojo
A: Mi, 9. September 2009, AutoScout24, Rosenheimer Strasse 143d

Also, Spread the word und auf geht’s!

Wäre interessant zu wissen wie der eigene Code sich so entwickelt hat? Kein Problem, Code Swarm ist Open Souce.

World Science Festival 2009: Bobby McFerrin Demonstrates the Power of the Pentatonic Scale.

Einfach nur faszinierend!

Dark-G-Blue

Am Arbeitsplatz verliere ich leider die Settings immer wieder durch das Hopping von Rechner zu Rechner. Da hilft nur eines – konsequent nachinstallieren bzw. die Settings immer griffbereit haben.

Letztens war es wieder einmal soweit – das grell-weisse Visual Studio hat meine Augen zu sehr penetriert. Also Farbschema laden und – endlich! Ruhe am Screen. Kurzerhand habe ich gleich mal ein paar kleine Optimierungen an den Farben vorgenommen – so habe ich auch das Highlighting und debugging verbessert.

Das Farbschema zum Download: Dark-G-Blue Visual Studio 2008 Color Scheme.

PS: Jep, nach langen Wochen wieder ein Blog-Eintrag. Ich habe mir eine etwas längere Pause gegönnt – schliesslich sind Geeks auch Menschen. Die Pause ist vorbei und ich freu’ mich schon wieder auf .NET, Entwicklung, Architektur und die restlichen digitalen Finessen :-)