adesso BLOG

Menschen wollen wissen, wo es langgeht. Deshalb basteln wir in Softwareprojekten Roadmaps. Auch, wenn die gar nichts mit dem Verlauf des Projektes zu tun haben.

Apache Camel ist ein Open Source Framework, das häufig zur Integration von Softwaresystemen auf der Basis von Messaging verwendet wird. Es ist eine Library mit sehr wenigen Abhängigkeiten, sodass diese problemlos in beliebigen Java-Applikationen ausgeführt werden kann. Mit seinen unzähligen Komponenten (>150) können Schnittstellen zu beliebigen Protokollen oder Messaging-Modellen erstellt werden. Für eine einfache Integration implementiert Apache Camel die meisten Enterprise Integration Patterns aus dem Buch von Gregor Hohpe und Bobby Woolf.

Es gibt Unternehmen, die schreiben agile Projekte “zum Festpreis” aus. Der billigste Anbieter erhält den Zuschlag. Wer den Fehler in dieser Logik findet, darf ihn behalten. Ich werde immer wieder um Rat gefragt, wenn es darum geht, für solche Projekte einen Velocity Forecast zu machen. Man will es ja richtig machen. Das verstehe ich. Also den Willen, es richtig zu machen, nicht den Willen, es zu machen.

Als ich letztens im Zug saß, las ich ausnahmsweise kein Buch, sondern schaute mir ein Interview mit Steve Jobs aus dem Jahr 1995 an. Steve Jobs soll hier aber gar nicht im Fokus stehen, sondern nur seine Gedanken zu Fahrrädern. Über diese erzählt er nämlich in dem Interview.

Was sorgt für schlanke Software? Wie können alle Beteiligten auf dieses Ziel verpflichtet werden? Shared-Pain-/Shared-Gain-Modelle sind die Antwort. Das sind Modelle, die die genannten Mechanismen umsetzen und den Gesamtfokus auf die oben geforderte schlanke Software legen.

Agile Softwareentwicklung lässt viel Spielraum für Entscheidungen – auch spät im Projekt. Das ist inhaltlich sinnvoll und in gewissen Maßen unvermeidbar, denn viele Softwaresysteme sind – abstrakt betrachtet – soziotechnische Systeme: Sie können als organisierte Menge von Menschen und Technologien verstanden werden, die in einer bestimmten Weise strukturiert sind, um ein spezifisches Ergebnis zu produzieren. Und sie sind nicht vollständig beschreibbar. Selbst der Versuch einer möglichst weitgehenden Vorab-Spezifikation ist, zumindest für Informationssysteme ohne ausgeprägte Risiken, unwirtschaftlich. Vieles lässt sich erst während der Entwicklung festlegen, direkt umsetzen und notfalls neu bewerten. Gerade das ist der Charme der agilen Entwicklung.