Test Driven Development (TDD) mit dem Visual Studio .NET

Mit dem Visual Studio 2008 (Version 9) wird eine Unit Test Komponente bereits mitgeliefert. Dennoch wird oft NUnit als Komponente hinzu installiert und mit dem Add-in TestDriven.net ergänzt.

Der Microsoft Unit Test Wizard erstellt je existierender Methode das Gerüst einer Testmethode. Das dient jedoch eher Entwicklern, die ihre Tests im Nachhinein schreiben, um der Firmenvorgabe zu folgen. Um den designbestimmenden Aspekt der testgetriebenen Entwicklung zu nutzen, müssen auch bei Altanwendungen die Tests vor der Funktionserweiterung geschrieben werden.

Da Unit Tests nur auf öffentliche Klassen und Methoden zugreifen können, eignen sie sich als Test der Schnittstellen. Ein Black Box Test also. Gerät der Unit Test bei einer umfangreichen Klasse mit vielen privaten Methoden zu aufwändig, ist das ein Hinweis, dass Funktionalität in Hilfsklassen ausgelagert werden können. Dort sind die Methoden dann öffentlich und lassen sich so über einen Unit Test abdecken.

Anwendungsfälle (Use Cases) oder sehr kleine User Stories eignen sich aber grade wegen dieser Einschränkung hervorragend als Testfälle.

Auch wenn es bei TDD sehr verlockend ist, sofort drauflos zu coden, lohnt es sich vorher ein paar Minuten über das Design der Schnittstelle nachzudenken. Das deckt oft schwammige Punkte in der Anforderungsbeschreibung auf. Diesem lokalen Modell kann man sich dann mittels TDD sehr schnell nähern.

Agiles Projektcontrolling

Agilität bedeutet nicht, dass man orientierungslos vor sich her entwickelt. Durch folgende Praktiken haben die verschiedennen Interessengruppen einen guten Einblick in das Projekt.

  • Tägliche Teammeetings
  • Burndown (oder -up) Grafiken je Iteration (Sprint) und für das gesamte Release
  • Echte Fortschrittsmessung mit der Definition von DONE
  • Anzahl der entdeckten Fehler nach DONE Meldung
  • Review Meetings am Ende einer Iteration
  • Grad der Testabdeckung

Daneben natürlich die üblichen Klassiker:

  • Zeit
  • Kosten

Anleitung, Muster (Pattern) oder Rezept?

Eine Anleitung ist eine Abfolge von Anweisungen, zur Bewältigung einfacher und komplizierter Situationen.

Muster hingegen sind Vorlagen zur Bewältigung komplexer Situationen.

Ein Rezept ist etwas zwischen einer Anleitung und einem Pattern.
Obwohl ein Kochrezept die Umwelt auf eine Untermenge beschränkt (Zutaten und Kochutensilien) und eine mehr oder weniger detaillierte Anleitung gibt, schmeckt das Resultat doch immer anders. Gleichzeitig erkennt man in den Ergebnissen Gemeinsamkeiten, also Muster.

Richtiges Anwenden einer guten Anleitung erbringt in der Regel das gewünschte Ergebnis. In komplexen Situationen gibt es hingegen viele Einflussfaktoren, die nicht dem Ursache-Wirkungs-Prinzip folgen. Ein Muster beschreibt eine Situation daher niemals komplett.

Siehe auch:
http://de.wikipedia.org/wiki/Entwurfsmuster
Linda Risiungs Pattern Almanac http://www.smallmemory.com/almanac/

Ein Weg zu Scrum: Karteikarten statt Software

Ausgangssituation:
Tasks mit Karteikarten übersichtlich und effizient zu planen ist für lokal arbeitende Teams zwar möglich, wird aber dennoch nicht überall mit offenen Armen angenommen. Das Team oder das Management ist es nicht gewohnt oder hat kein Vertrauen in diese lapidaren Karten.

Prinzip:
Mit der Einfachheit der Karten kann man den grundlegenden Ablauf der Zusammenarbeit und auch den Fortschritt wesentliche besser sehen, als mit einer Softwarelösung (ein häufiger Vertreter sei hier Bugzilla genannt).

Lösungsweg:
Die ersten 2-3 Iterationen mit Karteikarten beginnen und entsprechend des Feedbacks aus den Retrospektiven kann man mit einer Software den Prozess ergänzen. Zum Beispiel mit einem Ablagesystem für Detailinformationen wie einem Wiki.

Falls es wirklich nötig ist kann man die Karteikarten dann auch mit einer Software ersetzen. Das Team kann die Erkenntnisse und Erfahrungen über dem Planungsprozess mit den Karten dann besser auf das Softwaresystem übertragen.

Warum dauert die Sprintplanung so lange?

Gegebenheiten:
– Die Anforderungen im ProduktBacklog werden in idealen Personentagen abgeschätzt (GF-Beschluss).
– Die Anforderungen sind am Sprintende sehr oft nicht vollständig umgesetzt (Muss zusätzlich untersucht werden!).

Effekt:
Im ersten Sprintplanungs-Teil, in dem sich das Team die Anforderungen auswählt, zu denen es sich committed, wird der Restaufwand in idealen PT abgeschätzt. Über mehrere Iterationen hinweg werden also immer wieder die gleichen Anforderungen neu abgeschätzt. Das kostet Zeit und ist ermüdend. Dadurch wird der zweite Sprintplanungs-Teil, in dem die Anforderungen in Tasks herunter gebrochen und auf Stundenbasis geschätzt werden nur mühsam und wird nur unvollständig gelebt.
Vor allem die Entwickler, die es nicht gewohnt sind große Aufgaben in kleine aufzuteilen haben damit Schwierigkeiten.

Lösungsmöglichkeit:
Wenn die Anforderungen ohnehin schon in idealen Personentagen geschätzt werden, kann SP1 und SP2 zusammengefasst werden.
Dabei werden direkt die (restlichen) Aufgaben je Anforderung ermittelt, in Stunden abgeschätzt und notiert.
Lediglich neue Anforderungen könnnen vorab grob in PT geschätzt werden.
Das Sprint Burndown Chart kann somit ggf. auch ohne Aufteilung der Anforderungen in Aufgaben mit der Summe der Anforderungsaufwände auf der Y-Achse gestartet und bei vollständiger Erledigung abgetragen werden.