Mitarbeiterbericht KFO

Dieser Projektbericht ist von den drei Hauptentwicklern im Projekt geschrieben worden und gibt ihre subjektive Wahrnehmung wieder. Er soll potenziellen neuen Mitarbeitern bei akquinet it-agile einen möglichst realistischen Einblick in ihre zukünftige Arbeit erlauben.

Das Projekt KFO war ein Festpreisprojekt mit einem Umfang von 140 Personentagen. Herausfordernd war vor allem die enge Deadline. Der Auftraggeber hatte uns als Auftragnehmer auch deshalb ausgewählt, weil er sich von unserer Erfahrung mit agilen Projekten eine höhere Erfolgschance versprach.
Da das Projekt sehr plötzlich begann, war zuerst nur Christoph im Projekt. Es folgten dann Nico und Stefan. Formell war Stefan der Projektleiter. Weil Christoph aber viele der Gespräche mit den Projektbeteiligten beim Kunden geführt hat, lief auch später noch viel Kommunikation über ihn.

In der ersten Woche war nur Christoph im Projekt. Er hat viele persönliche Gespräche mit den Ansprechpartnern beim Kunden geführt und so die Eckdaten des Projektes fixiert. Er etablierte mit dem Kunden ein gemeinsames Verständnis über die fachlichen Anforderungen. Diese lagen zwar auch als Lastenheft vor, waren aber wie immer interpretationsbedürftig. Außerdem hat Christoph den Kunden dazu gebracht, eine Priorisierung zu definieren für den Fall, dass nicht die gesamte Funktionalität zum Termin vorliegt. Als primäres Mittel zur Fortschrittskontrolle im Projekt hat er mit dem Kunden wöchentliche Testreleases vereinbart. Nicht zuletzt hat Christoph für den Aufbau der Infrastruktur beim Kunden gesorgt. Denn das war für uns von Anfang an klar: Wir arbeiten direkt beim Kunden, um möglichst schnelle und kurze Abstimmungswege zu erreichen.

Trotz des Zeitdrucks haben wir Entwickler uns zu dritt erst mal zwei Tage Zeit genommen, um ein gemeinsames Verständnis über die einzelnen Features, das fachliche Kernmodell, die eingesetzten Technologien und den Entwicklungsprozess zu etablieren. Wir haben mit der Modellierung des fachlichen Kernmodells begonnen. Stefan hatte in seiner Weiterbildung gerade Color Modeling kennen gelernt und war davon ganz begeistert. Also haben wir es damit probiert. Wir haben Klassen entsprechend ihrer Archetypen auf farbige Haftnotizen geschrieben und diese auf Flipcharts geklebt. So konnten wir Änderungen an den Modellen sehr leicht vornehmen und mit verschiedenen Varianten spielen. Das Modell, das sich entwickelte, wirkte auf uns sehr ungewohnt - bisher hatten unsere fachlichen Modelle immer anders ausgesehen. Formal konnten wir aber keine guten Gründe finden, die gegen das Modell sprachen. Also haben wir beschlossen, dem Modell eine Chance zu geben. Wir haben bei der Modellierung allerdings schon gemerkt, dass es nicht 100% Modeling in Color entsprach. Es schien uns aber gut genug zu sein, um damit zu beginnen.
Als Komponentenarchitektur wählten wir Quasar, mit dem Stefan in seinem vorigen Projekt bereits gute Erfahrungen gesammelt hatte. Welche Komponenten welchen Typs es geben würde, haben wir ähnlich wie beim fachlichen Klassenmodell mit farbigen Haftnotizen auf Flipcharts modelliert. Jede Komponente bekam ihr eigenes Eclipse-Projekt. Ansonsten haben wir keine Komponenten-Infrastruktur verwendet.

Technologisch haben wir den Technologiestack weiterentwickelt, mit dem Stefan in seinem vorigen Projekt gearbeitet hatte. Heraus kam eine Standard-Web-Architektur mit Spring, Spring Web MVC und Hibernate. Nicht verwendet haben wir EJB und viele andere komplizierte JEE-Technologien.
Stefan hatte bei der Beschreibung der Features in seinem vorigen Projekt sehr gute Erfahrungen mit dem Beschreibungsschema aus FDD (Feature Driven Development) gemacht. Jedes Feature wird in einem Satz in der Form <Aktion> <Ergebnis> <Objekt> beschrieben. Also haben wir auf der Basis des Lastenheftes und des fachlichen Modells Features in diesem Schema definiert. Wir haben zuerst nur die Features für das erste Release definiert. Jedes Feature wurde in der FDD-Form auf Flipcharts geschrieben. Im Ergebnis hing die ganze Wand voll mit Feature-Flipcharts.

Die Features waren dabei so feingranular gewählt, dass wir davon ausgingen, für keines länger als einen Tag zu benötigen. Im Projektverlauf hat sich herausgestellt, dass das eine sehr gute Wahl war: Es war extrem motivierend jeden Tag mindestens ein Feature auszustreichen. Abends hatte man so immer das Gefühl, wirklich etwas geschafft zu haben. Daneben wurde durch die kleinen Features auch das Tracking angenehm vereinfacht: Da alle Features etwa die gleiche Größe hatten, reichte es, die Anzahl der erledigten und offenen Features zu zählen. Das war extrem einfach und schnell erledigt.

Gleich am ersten Tag des Projekts haben wir gemeinsam die Regeln und Konventionen festgelegt, nach denen wir arbeiten wollten. Da das ganze Team beteiligt war, fiel das Commitment auf diese Regeln nicht schwer, und der Entwicklungsprozeß gehörte von Anfang an wirklich dem ganzen Team. Diesen ersten Satz an Regeln haben wir dann während des weiteren Projektfortschritts immer dann gemeinsam angepasst, wenn es uns sinnvoll erschien. Tatsächlich funktionierten die Regeln und Konventionen aber sehr gut, so dass nur wenige Anpassungen nötig waren. Die festgelegten Konventionen waren sehr unterschiedlich: Sie reichten von der Kleidungsvorschrift, dass jeder in einem Oberhemd erscheinen muss, über die Festlegung, wann Retrospektiven stattzufinden haben, bis hin zur Regelung der Code-Ownership. Insgesamt sind wir mit weniger als 10 Regeln ausgekommen.

Da der Zeitplan extrem knapp bemessen war, hatten wir uns zu Projektbeginn als Team dazu entschieden, dass jeder bis auf weiteres so viele Überstunden macht, wie er erbringen kann, ohne dass darunter die Qualität seiner Arbeit leidet. Wir haben uns davon erhofft, dass wir durch diesen "Sprint" zu Projektbeginn den drohenden Stress kurz vor der Abgabe ersparen können und bis zuletzt handlungsfähig bleiben. Das klappte auch tatsächlich sehr gut. Wir haben über einen Zeitraum von 2 Monaten hinweg Überstunden geleistet, hatten aber gleichzeitig das gute Gefühl, dass es sich gelohnt hat, weil wir gut vorankamen und letztlich unsere Termine halten konnten. Auch die Stimmung im Team war zu jeder Zeit gut und litt nicht unter der zusätzlichen Belastung. Angemerkt sei hier, dass Überstunden in unseren Projekten eher die Ausnahme sein sollen und auch sind. In diesem Projekt haben wir uns gemeinsam explizit darauf committed, um in einem attraktiven Projekt einen anspruchsvollen Termin zu halten.
Wie lief ein typischer Tag in dieser Zeit ab? Die Kernarbeitszeit begann um 8:30 Uhr, obwohl eigentlich immer einige bereits früher da waren. Wir begannen den Tag mit einem etwa 5 minütigen Standup-Meeting. Dabei standen wir im Kreis und berichteten uns nacheinander, welche Features wir gestern bearbeitet hatten, ob wir auf Probleme gestoßen waren und welche Features wir heute erledigen wollten. Dann ging jeder an seinen Arbeitsplatz und begann zu entwickeln. Dabei sind wir testgetrieben vorgegangen, was sicherlich maßgeblich zu der hohen Qualität und dem guten Design der Software beigetragen hat. Die Testabdeckung war durch die testgetriebene Entwicklung erwartungsemäß recht hoch.

Wenn ein Entwickler bei der Arbeit auf Probleme stieß, fragten wir einfach über den Tisch hinweg um Rat. Häufig kam es auch vor, dass man einen Kollegen um Hilfe beim Bearbeiten eines aufgetretenen Problems bat. Dann arbeiteten wir für einige Zeit zu zweit ("im Pair") an einem Rechner, bis der Widerstand überwunden war.

Entscheidend war für unsere Arbeitsweise, dass wir alle in einem Raum arbeiteten. Das half uns, durch ständige Kommunikation auch ohne viele Dokumente ein gemeinsames Verständnis des Systems aufrechtzuerhalten. Es kam nicht selten vor, dass beispielsweise Christoph Stefan eine Frage stellte und Nico, der das Gespräch während der Arbeit mithörte, dann die Antwort lieferte. Ebenso hörte durch die räumliche Nähe jeder die Telefonate und Gespräche der Anderen mit den Kunden mit, so dass hier kaum Aufwand für die Informationsübermittlung im Team nötig war und sich jeder immer auf dem neuesten Stand befand.

Um 17:00 endete dann die Kernarbeitszeit. Meistens blieben in dieser Zeit aber noch einige bis 19:00 oder 20:00 Uhr.

Auch wenn es für uns nichts Besonderes mehr darstellt, war es für die Kunden offensichtlich sehr überraschend, wie wir unser Büro ausgestalteten: Vom wöchentlichen Tracking, über die Featurelisten und Regellisten, bis hin zu Fachmodellen und Architekturmodellen - die Wände waren übersäht mit Flipchartseiten. Tatsächlich verzichteten wir nahezu vollständig auf elektronische Dokumente, selbst unser wöchentliches Tracking (dauer maximal 5 Minuten) verewigten wir auf handgemalten Burn-Down Charts. Der Effekt war, dass wir kaum Overhead für die Projektverwaltung hatten und dass jeder zu jedem Zeitpunkt alle wichtigen Informationen von seinem Platz aus sehen konnte, ohne dafür den Arbeitskontext auf seinem Bildschirm wechseln zu müssen.

Nach Projektende haben wir nochmal eine längere Post-Mortem-Retrospektive durchgeführt, um das Gelernte zusammenzutragen und für folgende Projekte nutzbar zu machen. Schließlich wollen wir uns nicht nur innerhalb eines Projektes, sondern firmenweit kontinuierlich verbessern.

Da nach Projektende die Teammitglieder bereits in neuen Projekten an unterschiedlichen Standorten tätig waren, haben wir eine verteilte Retrospektive mit den Online-Tools Skype und Card-Meeting durchgeführt.

Die interessantesten Aspekte der Retrospektive waren das Weak-Code-Ownership und das Pair-Programming. Obwohl wir der Meinung waren, dass Pair-Programming produktiver ist als Singe-Programming, haben wir doch relativ selten davon gebraucht gemacht. Wir führen das auf das Weak-Code-Ownership zurück. Das Ownership-Modell beförderte die Konzentration auf die eigenen Aufgaben zu Lasten des Pair-Programmings. Trotz des reduzierten Pair-Programmings waren wir der Meinung, qualitativ hochwertigen Code abgeliefert zu haben. Allerdings gibt es eine Stelle im Code, die nur einer von uns sehr gut beherrscht. Weiterhin wären einige Entwürfe im Paar wohl noch besser gelungen.