Wir haben da erstmal ein Framework geschrieben ...

Wenn ich in ein Projekt komme, bei dem ich zuerst diesen Satz höre, bekomme ich regelmäßig eine Gänsehaut. Warum?

Für ein erfolgreiches Projekt ist es wichtig, sich zuerst einmal damit zu beschäftigen, was mit dem Projekt bewirkt werden soll. Man muß das Vokabular der fachlichen Anforderung lernen und herausarbeiten, welche Eigenschaften der zu erstellenden Software den eigentlichen Wert für den Kunden ausmachen. Nachdem das verstanden ist, werden riskante Technologien betrachtet.

Wird aber damit begonnen, ein Framework zu erstellen, bedeutet das immer nur das eine: Angst vor den fachlichen Anforderungen. Diese sind unklar und nicht verstanden. Anstelle dem Kunden solange zu fragen oder sich aus anderen Quellen zusätzliche Information zu besorgen, die die Anforderungen klären würden, zieht man sich auf das Feld zurück, von dem man meint, etwas zu verstehen. Es werden reihenweise Entwurfsmuster zusammengebastelt, bis etwas entsteht, daß deutlich zeigt, welche technologischen Interessen die Ersteller haben, aber der Lösung des eigentlichen Problems nur im Wege steht.

Hier zeigt sich auch die dunkle Seite der Entwurfsmuster. Viele scheinen heutzutage der Meinung zu sein, daß nur hinreichend viele Entwurfsmuster aneinandergereiht werden müssen, um eine sinnvolle Architektur zu erreichen. Natürlich ist die Kenntnis von Entwurfsmustern extrem hilfreich. Nur darf das Muster nicht am Anfang stehen, sondern muß das Ergebnis sein. D.h. ich beginne mit einer Anforderung, betrachte mir eine mögliche Umsetzung, erkenne eine unerwünschte Kopplung und dann fällt mir ein, daß es ein Entwurfsmuster gibt, mit dem sich die Kopplung elegant auflösen läßt.

Gute Frameworks entstehen nie auf der grünen Wiese. Die besten werden aus erfolgreichen Projekten "geerntet" (die Formulierung habe ich von Erik Dörnenburg, ThoughtWorks geklaut). Wenn eine Architektur sehr gut geraten ist, lohnt es sich manchmal, anschließend das technische Framework von der konkreten Fachlichkeeit zu befreien und für die Wiederverwertung aufzubereiten.

Dies kann auch im kleinen erfolgen. Wenn ein Projekt viele technisch ähnliche Dinge (Masken, Schnittstellen ...) zu implementieren hat, sollte zuerst eine konkret realisiert werden und dann bei der nächsten darauf geachtet werden, daß nichts mit Kopieren und Einfügen übernommen wird, sondern gemeinsam nutzbare Teile entstehen. Das geeignete Framework entsteht so ganz von alleine.

Es ist jedenfalls ein sicherer Weg ins Desaster, wenn man ein Framework baut, daß alle Fragen beantwortet, die niemand gestellt hat, während man die eigentliche Frage noch nicht kennt.

Raus aus dem Hamsterrad

In vielen Projekten gibt es ineffiziente Arbeitsabläufe, die viel Zeit kosten. Häufig ist die Abhilfe offensichtlich. Wenn man dann nachfragt, warum nichts gemacht worden ist, wird gewöhnlich auf den engen Terminrahmen hingewiesen. "Wenn wir mal etwas mehr Ruhe haben, werden wir uns darum kümmern."

Das Problem hier ist, daß die Zeit, wenn mehr Ruhe herrscht, erst dann kommen wird, wenn das Projekt eh zu Ende ist. Der Grund ist, daß durch all die vielen Dinge, die man aus Zeitnot nicht in Ordnung bringt, genau die Zeit verloren geht, die man brauchte, um die nötigen Verbesserungen durchzuführen.

Das Problem hier ist ein fehlendes unternehmerisches Denken der Projektbeteiligten. Eine Verbesserungsmaßnahme ist zunächst einmal eine Investition. Es muß also abgeschätzt werden, was die Maßnahme vermutlich kosten würde und was das Einsparpotential nach der Umsetzung ist.

Häufig werden solche Entscheidungen durch Prozesse erschwert, die sehr kleinteilige Projektfortschrittsberichte erfordern und bei nicht direkt sichtbarem Projektfortschritt langwierige Diskussionen mit Vorgesetzten nach sich ziehen. Diese Diskussionen erhöhen dann die Kosten für Verbesserungsmaßnahmen signifikant.

Wenn man persönlich von einer Maßnahme überzeugt ist, hilft da ein wenig Unaufrichtigkeit. Dann wird halt mal schon bei der Fortschrittsmeldung ein wenig Kredit auf die Zukunft aufgenommen. Wenn dann die Verbesserungsmaßnahme greift, wird der Kredit sehr schnell wieder abzulösen sein.

Die ordentliche Umgangsweise mit dem Problem sieht aber so aus:

1. Es wird eine Liste angelegt, in die alle vom Team vorgeschlagenen Verbesserungsmaßnahmen aufgenommen werden.

2. Es wird eine Menge an Zeit für die Umsetzung des Maßnahmen festgelegt, die jede Woche eingeplant wird.

3. Die Maßnahmen werden nach Aufwand und Einsparpotential bewertet, gegebenenfalls auch Risiko und zusätzliche Ergebnisse wie erhöhte Qualität.

4. Es wird immer eine Maßnahme nach der anderen umgesetzt.

5. Nach der Umsetzung wird die Liste aktualisiert und die nächste Maßnahme in Angriff genommen.

Nach kurzer Zeit sollten erste Erfolge sichtbar werden und die Situation sich entspannen.

Wie man Arbeit im Schlaf erledigt

Mancher hat das Neue Jahr mit guten Vorsetzen begonnnen. Vielleicht war ja auch der Vorsatz dabei, künftig mehr Zeit für andere Dinge zu haben als die Arbeit. Für Entwickler gibt es einen kleinen Trick, wie man das leicht erreichen kann - sofern das Ziel ist, die Arbeit zu erledigen und nicht Anwesenheit zu zeigen.

1. Ein Schritt nach dem anderen

Rom ist nicht an einem Tag erbaut worden und auch ein Softwaresystem entsteht Stück für Stück. Um sich nicht zu verzetteln, sollte man sich immer auf genau eine Anforderung konzentrieren und alles übrige zunächst außer acht lassen. Eine Anforderung ist hierbei so elementar zu verstehen, daß daraus ein Entwicklungsaufwand von nicht mehr als einem Tag entsteht. Wenn die Anforderungen noch nicht so vorliegen, muß der Entwickler diese Aufgabe übernehmen.

2. Klare Ziele

Eine Anforderung muß so formuliert sein, daß klar ist, welche beobachtbare Eigenschaft an dem System sich ändern muß, um sie zu erfüllen. Ist keine meßbare Eigenschaft bekannt, an der festgestellt werden kann, ob die Anforderung erfüllt ist, so ist auch nichts zu tun. Vielmehr ist alles schädlich, was aufgrund einer solchen Pseudoanforderung implementiert wird, da dieser Code kein später nachvollziehbares Ziel verfolgt und bei der weiteren Wartung unnötige Aufwände erzeugt.

Wenn ein meßbares Ziel definiert ist, so kann auch ein kleiner Test geschrieben werden, mit dem ebendiese Messung automatisch durchgeführt wird.

3. ... und jetzt der Trick

Die Schlafforschung hat ergeben, daß das Gehirn während des Schlafes, insbesonders während der sogenannten REM-Phasen, die neuen Eindrücke aus dem Kurzzeitgedächtnis verarbeitet. Lernt man etwas und schläft danach, so werden die Lerninhalte wesentlich besser verarbeitet, als wenn man wach bleibt. Die Softwareentwicklung ist ein ständiger Lernprozeß. Erst muß ich die Anforderung lernen, damit ich sie dann umsetzen kann.

Der Trick besteht nun darin, die Arbeit so zu organisieren, daß das letzte, was man vor Feierabend macht, für eine Anforderung zu bestimmen, welche Verhaltensänderungen für die Software daraus folgen und möglichst auch einen Test dafür zu schreiben. Die Implementierung wird auf den nächsten Morgen verschoben. Meine Erfahrung mit dieser Vorgehensweise ist, daß ich bei Arbeiten an einem System mit dem ich mich gut auskenne, dadurch im Durchschnitt ca. eine halbe Stunde pro Tag einsparen kann.