Neulich traf ich Emil, den erfahrenen Entwickler. Weil er überarbeitet aussah, fragte ich ihn, was denn los sei. Als hätte er darauf gewartet, sprudelte er los: „Es geht nicht mehr, es geht einfach nicht mehr, wir kommen nicht weiter.“
Ich erfuhr, dass die Weiterentwicklung in seinem Projekt seit Wochen stagniert. Das Team versucht, eine selbstregulierende Steuerung für Ampelsysteme zu entwickeln, doch es kämpft täglich mit Unzulänglichkeiten, wenn nicht Unzumutbarkeiten, ihrer Entwicklungssoftware. Die Entwickler arbeiten modellbasiert. Klingt fortschrittlich. Ist es aber nicht immer, wenn das Modellierungstool nicht zum Projekt passt – und genau das ist in Emils Projekt der Fall.
Er und seine Kollegen arbeiten mit einem in anderen Projekten bewährten Modellierungstool, schimpfen aber ständig darüber, dass der Code, den sie aus ihrem Statechart-Modell generieren, schlecht konfigurierbar sei. Der Codegenerator unterstütze nur C++03. Sie brauchen aber C++11 und C++14, erläutert Emil. Gleichzeitig gibt es keine Schnittstelle, um den Generator anzupassen. Sie ver(sch)wenden viel Zeit in umständlichen Workarounds, um nutzbare Ergebnisse zu erhalten. Immerhin hat Emil erkannt, dass es so nicht weitergehen kann – und Einsicht ist bekanntlich der erste Schritt zur Besserung. Doch was nun?
Rückbesinnung auf die wirklich wichtigen Fragen
In solchen Phasen erweist es sich häufig als hilfreich, zu stoppen und innezuhalten, um Abstand von der alltäglichen Arbeit zu bekommen. Für das Projektteam kann das bedeuten, sich einen Labday zu gönnen und sich auf die folgenden Fragen zu besinnen:
- Welche Funktionen unseres Tools benutzen wir – und welche brauchen wir? Besitzt das Tool diese Funktionalitäten?
- Entsprechen die vorhandenen Funktionen unseren Anforderungen?
- Welche Anforderungen haben wir eigentlich an so ein Tool?
- Welche Alternativen gibt es, die besser zu uns passen?
Diese Fragen bauen zum Teil aufeinander auf – und ihre Beantwortung kann und sollte im Zweifel zu einem Toolwechsel führen. Parallel kann das Team natürlich schon nach alternativen Tools suchen.
Um sich für das richtige Werkzeug zu entscheiden, sind die Anforderungen entscheidend: Welche Funktionen sind uns wirklich wichtig und auf welche können wir gegebenfalls auch verzichten? Diese Anforderungen ergeben sich idealerweise auch aus den Unzulänglichkeiten des aktuellen Werkzeugs. So ist dieses dann doch noch zu etwas zu gebrauchen ;)
Auch wenn die Entscheidung sicher nicht einfach ist und (vorerst) eine Menge zusätzlicher Arbeit mit sich bringt: Auf lange Sicht ist es nicht zielführend, mit einem Tool zu arbeiten, das weder den Ansprüchen des Teams noch den Anforderungen des Projektes gerecht wird.
Tauscht das Team das Werkzeug aber aus, wird die Werkzeugkette wieder fit für die aktuelle Entwicklung – so wie Refactorings auch Code oder Modelle fit halten. Auf lange Sicht wird das Team mit einem passenden Werkzeug produktiver und sowohl Zeit- als auch Kostenaufwände werden reduziert.
Doch wie finden Entwickler wie Emil heraus, welches Modellierungswerkzeug das richtige für ihr Projekt ist?
Kommentare