Business-driven Development

Im Zuge der anstehenden Neuanstellungen bei uns im Betrieb und der damit verbundenen Vertragsgestaltungen, besonders in Bezug auf die neue Abteilungsform „DevOps“, habe ich mir einmal meinen Arbeitsvertrag aus dem Jahr 2010 angesehen. Darin stolperte ich über mein Einsatzgebiet und freute mich, dass es damals wie heute noch so treffend ist.

Im Wortlaut steht dort als eine von vielen Aufgaben: „Überarbeitung und ggf. Neukonzeption der bestehenden Systemarchitektur inkl. Schnittstellen und Modulen unter Aspekten der Wartbarkeit, Wiederverwendbarkeit, Sicherheit und Kosten-Nutzen-Verhältnis.“

Besonders der letzte Aspekt gefällt mir sehr gut: Kosten-Nutzen-Verhältnis. Was heißt das? Schlecht programmieren und schnell online gehen? Bestimmt nicht. Test-driven entwickeln, warten bis das System durch eine übergeordnete Prüfungskommission abgenommen und alle Sicherheitsstandards eingehalten sind? Eher auch nicht! Was also? Die Wahrheit liegt wohl dazwischen. Business-driven Development habe ich es vor Ewigkeiten getauft. Die Brücke zwischen schlimmen Hacking und schwergewichtigen Lasten- und Pflichtenheften. Wir sind ja agil!

Dem Wikipedia Artikel aus dem Jahr 2006 stimme ich allerdings nur bedingt zu. Dieser bezieht sich sehr stark darauf, dass der große Vorteil in der harten und direkten Verknüpfung der Geschäftslogik mit der zu erstellenden oder zu erweiternden Software liegt. Dies ist aber in meinen Augen kein neues Merkmal des Business-driven Development, sondern findet sich in vielen agilen Methoden wieder. Es charakterisiert viel mehr die Ansätze des Kanban und Scrum Prozesses, Projekte zu erstellen, zu planen und umzusetzen. Der Bezug zur Geschäftslogik wird also mehr auf der Projektplanungsebene gezogen. Auf der Softwareerstellungsebene muss dies dann in guten, wartbaren, nachhaltigen, sicheren und sauberen Programmcodes überführt werden. Genau an der Stelle scheiden sich die Geister. Clean-code Development ist für die meisten schon zum Standard geworden. Aber nur dieser Ansatz reicht bei weitem nicht aus. Die Strategie eines Teams, sich für eine Vorgehensweise zu entscheiden, ist essentiell für den Erfolg der Software und des Teams. Software muss nach der Erstellung unabhängig der Strategie wartbar bleiben.

Welcher der Ansätze für das Team am besten funktioniert, überlasse ich jedem selbst. Hier geht es darum, den Unterschied zu den, ich nenne sie mal klassischen Methoden, heraus zustellen. Im Gegenteil zu Test-driven Development, Behavior-driven Development, Design-driven Development, User-centered design oder einem der vielen anderen steht beim Business-driven Development die Anwendbarkeit im Vordergrund. Das bedeutet, neue Features sollen durch eingerichtete Test-Stages in der Produktion sofort mit dem Kunden abgestimmt werden können. Die Umsetzung muss aus bestehenden und etablierten Komponenten bestehen. Neue Technologien werden als early alpha Prototypen sofort auf Test- oder Produktions-Stages implementiert und in Abstimmung mit dem Steakholder ausprobiert. Ist ein Feature in diesem Zyklus noch interessant so wird die Implementierung reverse refactored. Das bedeutet, bis zu diesem Zeitpunkt gab es noch keinerlei Designentscheidungen. Diese werden jetzt getroffen und mit der neuen Technologie verbandelt oder in das bestehende System integriert. Im Unterschied zum Live-Hacking darf der Prototyp nicht in der Form im System bestehen bleiben. Nach der Implementierung muss die Zeit investiert werden, die wesentlichen Bestandteile neuer Software nach zu liefern. Diese sind Readme, Integrationstest und Changelog. Damit ist gewährleistet, dass andere Entwickler schnell den Einstieg in die Implementierung finden. Anhand des Changelogs werden Patches sowie Features schnell identifiziert. Die Readme (diese kann ein Wiki oder eine Textdatei sein) gibt den Überblick (bspw. Linksammlung) zur Technologie und der Designentscheidung für die Implementierung. Der Test gehört in das Continuous Integration. Denn ganz klar, ohne dieses Sicherheitsnetz für jedes noch so kleine Feature ist diese Art von Vorgehen in der Softwareentwicklung lebensgefährlich und fahrlässig.

Ich behaupte also, Business-driven Development vereint die vielen Vorteile verschiedener Entwicklertypen (8 different types of programmers http://david.elbe.me/programming/2015/05/25/different-types-of-programmers.html) in dem sie schnell Funktionen anbieten können, ohne große Projekte akquirieren zu müssen. Weniger Pre-Sales, was dazu führt, dass diese Mittel später in den Feinschliff der Software gesteckt werden können. Außerdem können somit Probleme, welche üblicherweise während der Softwareentwicklung auftreten, durch schnelles ausprobieren (try-and-error Prinzip) kostengünstig untersucht werden. Die schwerwiegenden Showstopper, welche oftmals große Softwareprojekte zum scheitern zwingen, werden frühzeitig erkannt. Der so oft auftretende teure Ausstieg nach einer langen Entwicklungsphase bleibt aus. Ein wesentlicher Punkt, warum Softwareprojekte scheitern, wird ausgehebelt. Hürden können nicht genommen werden und sorgen nach endloser Arbeit dazu, dass ein Produkt nicht den Anforderungen entspricht und daher nicht den gewünschten Kundenerfolg einbringt. Damit wird viel Geld und Zeit verbrannt. Business-driven Development löst dieses Problem. Um meine These zu untermauern und einen deutschsprachigen Wikiartikel dazu zu verfassen, benötige ich allerdings mehr Anhänger meiner Theorie.

Geschrieben im Jahr “2015”