29.10.
Das Projekt startet, der Kunde nennt das auch "Kick-Off". Fünf sehr erfahrene Entwickler sind versammelt und bekommen einen schicken HTML-Prototyp vorgestellt. Das Design gefällt allen, in Gedanken macht man hier und da schon kleine Änderungen, ist aber im Großen und Ganzen wirklich sehr zufrieden. Es herrscht Aufbruchstimmung – wir können die Welt beherrschen und Berge versetzen! In dieser wundervollen euphorischen Stimmung kommen bei uns Entwicklern die ersten Zweifel. Der Prototyp lässt sich durchklicken, und nun tut der Kunde so, als ob das ganze System schon fertig ist. Und dabei ist noch keine einzige Zeile Code geschrieben. Wir sind erfahrene Java-Entwickler. Groovy und Grails basieren zwar auf Java, und wir haben auch alle eine Schulung gemacht, aber trotzdem werden wir bestimmt noch über das eine oder andere Problem stolpern. Sollen wir deswegen die gute Laune verderben?
31.10.
Weiterhin hoch motiviert arbeiten wir Entwickler an der Infrastruktur für die Anwendung. Das Framework Grails erleichtert uns sehr viel Arbeit, denn das meiste ist als Konvention schon vorgegeben. Die Anbindung an den E-Mail-Server bereitet unerwartet Probleme. Außerdem haben wir den Anspruch, das Projekt kontinuierlich zu integrieren und einen Build-Server zu benutzen. Jede Änderung am Sourcecode im Repository führt zur Ausführung aller Tests. Nicht nur die Unit-Tests werden automatisch ausgeführt, sondern auch die Akzeptanztests gestartet. Hier stolpern wir über viele kleine technische Fallen. Warum ist es z. B. so kompliziert, mit SSL und Java per IMAP E-Mails abzurufen? Die Probleme bekommen wir in den Griff, sie kosten aber viel Zeit. Wir haben eine hohe Anfangsinvestition in unsere Infrastruktur, die der Kunde einfach nicht zur würdigen weiß ("Hä? Was ist denn SSL und IMAP?")! Ungefähr die Hälfte aller Seiten können wir modellieren und stolz vorzeigen. Dem Kunden ist die Enttäuschung anzusehen. Wir können ihm versichern, dass wir mit den Investitionen in unsere Test- und Build-Struktur an Geschwindigkeit zulegen werden.
02.11.
Wir sind fleißig, arbeiten Feature für Feature ab. Jedes Feature muss dabei durch unsere Akzeptanztests beschrieben werden. Für die Akzeptanztests benutzen wir erfolgreich Canoo-Webtests. Trotzdem brauchen wir manchmal sehr viel Zeit, um ein Feature durch einen Webtest richtig zu beschreiben und um unsere Webtests zu organisieren. Auch bei den Akzeptanztests wollen wir dem DRY-Prinzip (Don’t repeat yourself) folgen und eine Information nur an einer Stelle beschreiben und nicht an mehreren warten müssen. Der Kunde wird anscheinend durch unsere technischen Begriffe wie "XPath", "JavaScript", "prototype" und "DOM" nur verwirrt und sieht die kleinen Erfolge nicht. Der Kunde hat unsere Anwendung getestet und ist nicht mit allem zufrieden. Er bezeichnet sogar manche der fehlenden Features als "Bugs" und behauptet etwas von "Selbstverständlichkeitsanforderungen" ...
