Usability im Fokus

Business-driven Development – mehr als nur Business!
Kommentare

Mit Business-driven Development (BDD) bezeichnet man das Entwickeln von IT-Lösungen, die direkt auf den Bedarf bzw. die Anforderungen von Unternehmen zugeschnitten sind. Häufig kommt beim BDD ein modellbezogener Ansatz zum Einsatz, der zunächst an der Business-Strategie, der Nachfrage und den Zielen anknüpft. Soweit die allgemeine Definition des Begriffs. Doch wie lassen sich diese theoretischen Prinzipien in die Praxis umsetzen? Einige Gedanken dazu aus dem Entwickleralltag.

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 und 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 schlimmem Hacking und schwergewichtigen Lasten- und Pflichtenheften. Wir sind ja agil!

Mehr als nur Business!

Dem Wikipedia-Artikel zu Business-driven Development, dessen erste Version aus dem Jahr 2006 stammt, 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 dieser 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.

Usability im Fokus

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 Stakeholder 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 fest steht: ohne dieses Sicherheitsnetz für jedes noch so kleine Feature ist diese Art von Vorgehen in der Softwareentwicklung lebensgefährlich und fahrlässig.

BDD vereint Vorteile

Ich behaupte also: Business-driven Development vereint die vielen Vorteile verschiedener Entwicklertypen, und zwar indem es sie in die Lage versetzt, schnell Funktionen anbieten zu können, ohne große Projekte akquirieren zu müssen. Auch der Aufwand im Pre-Sales wird reduziert, was dazu führt, dass diese Mittel später in den Feinschliff der Software gesteckt werden können. Außerdem können somit Probleme, die üblicherweise während der Softwareentwicklung auftreten, durch schnelles Ausprobieren (Trial-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. Deshalb meine Frage an Sie, liebe Leser: Wie verstehen Sie Business-driven Development? Wie und mit welchem Erfolg setzen Sie es in Ihren Projekten ein? Ich freue mich auf Ihre Kommentare!

 

Aufmacherbild: Illustration of business and chasing more business via Shutterstock / Urheberrecht: KPG Ivary

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -