Eines vorweg:
Dependencies sind ein Bugaboo; …
… ein Schreckgespenst.
Dependencies – zu deutsch Abhängigkeiten – sollten vermieden oder zumindest reduziert werden, wo immer möglich!
Dependencies bergen Risiken, schränken Freiheiten ein und resultieren oftmals in der Nichteinhaltung von Plänen.
Werden WIR nicht rechtzeitig fertig, können die ANDEREN nicht weitermachen und der Plan fällt womöglich ins Wasser. Zusagen an Dritte werden nicht eingehalten und das Time-to-Market eines Produktes verzögert sich. Ist das der Regelfall, so kann das keinesfalls als gut befunden werden, oder?
Siehe dazu auch:
Das Dependency Board, …
oftmals sichtbares Zeichen dafür, dass da etwas nicht stimmt.
Lässt sich aus der Summe der Wollfäden, die auf dem Dependency Board die Abhängigkeiten aufzeigen ein Pullover samt Unterwäsche stricken, liegt der Verdacht nahe, dass da etwas am Setup des Agile Release Trains (ART) suboptimal ist.
Vermeidung / Reduzierung von Dependencies durch Optimierung des ART
Ein ART ist für die Entwicklung eines Products oder einer Solution zuständig. Was das genau ist und was es alles umfasst – in Scope / out of Scope – wird über eine Value Stream Analysis erarbeitet. Bestandteile dieser Analyse ist auch, die Systeme und Experten zu benennen, die für die Entwicklung des Products – respektive der Solution – erforderlich sind. An die Value Stream Analysis fügt sich unmittelbar die ART
Identification an.
Ziel ist es, einen Agile Release Train zu definieren, der möglichst unabhängig das Product oder die Solution entwickeln kann. Denn wie wir alle wissen, Abhängigkeiten machen das Leben schwer.
Agile Release Trains werden in Scrum Teams unterteilt, die jeweils für Teilbereiche des Products / der Solution verantwortlich sind. Auch hier gilt es einen Setup zu finden, der möglichst wenig Abhängigkeiten zustande bringt. Je autarker jedes Team entwickeln kann, desto besser.
Value Stream Analysis und ART Identification können übrigens jederzeit durchgeführt werden. Wann auch immer man das Gefühl hat, dass Dependencies einem das Leben zu schwer machen. Üblicherweise stehen sie aber am Anfang eines jeden ARTs.
Vermeidung / Reduzierung von Dependencies durch Feature Toggling
Abhängigkeiten – also Dependencies – entstehen dort, wo der eine auf den anderen angewiesen ist. Umgangssprachlich: “Ich kann erst weitermachen, wenn du mir das lieferst.”
Dabei kann die Partei, die etwas zu liefern hat, als Server oder Provider bezeichnet werden und die Partei, die darauf angewiesen ist, als Client oder Consumer.
Entweder müssen Daten, durch einen Provider zur Verfügung gestellt vorliegen, damit ein Consumer sie nutzen kann oder ein Consumer richtet seine Anfrage direkt in Form eines Funktionsaufrufes oder Rest Calls an einen Provider. Wie dem auch immer sei, es besteht eine Abhängigkeit; eine Dependency.
Programmiertechnisch lässt sich solch eine Abhängigkeit für den Zeitraum der Entwicklung und vor Produktivschaltung durch
- Feature Toggling
- Mocking
entschärfen
Wenn der Consumer (Client) seinen Anteil der Kundenanforderung umsetzt, simuliert er den noch nicht vorhandenen Provider (Server) mittels eines sogenannten Mocks. Ein Mock (von englisch to mock‚ etwas vortäuschen‘) simuliert das Vorhandensein all der Dinge, die von außen – einem Provider (Server) – zu liefern sind. Das funktioniert natürlich auch andersherum, für das Team, das den Provider (Server) zu programmieren hat. Die jeweils “andere Seite” wird simuliert. So kann unabhängig voneinander entwickelt werden.
Zugleich baut man in den Programmcode einen Schalter – einen sogenannten Feature Toggle – ein, mittels dessen man die Verwendung der noch nicht ganz fertigen Funktionalität unterbinden kann. So ein Toggle schaltet damit beispielsweise die Sichtbarkeit eines Links oder eines Buttons auf der Benutzeroberfläche aus, weil vielleicht noch nicht alle Bestandteile der Programmierung fertig sind.
Leider wird allzu oft auf die Verwendung von Mocks und Feature Toggles verzichtet, was die Problematik von Abhängigkeiten unnötig verschärft.
Vermeidung / Reduzierung von Dependencies durch Contract-driven Development
Das ist die Königsklasse der Softwareentwicklung.
Contract-Driven Development is a new approach to systematic software construction combining ideas from Design by Contract, from Test-Driven Development, from work on formal methods, and from advances in automatic testing as illustrated for example in our AutoTest tool. Like TDD it gives tests a central role in the development process, but these tests are deduced from possibly partial specifications (contracts) and directly supported by the development environment. This talk will explain the concepts and demonstrate their application.1„
Dazu mehr ein andermal.
Conclusio
Es ist erstaunlich, dass Dependencies zwar aufgezeigt werden, aber scheinbar niemandem die eine, naheliegende Frage in den Sinn kommt: “Wie beseitige ich dieses Chaos?” Passende Methoden gibt es lange genug.
Wollen Sie Dependencies minimieren und den ART optimieren, dann
1. Meyer, B. (2007). Contract-Driven Development. In: Dwyer, M.B., Lopes, A. (eds) Fundamental Approaches to Software Engineering. FASE 2007. Lecture Notes in Computer Science, vol 4422. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-540-71289-3_2
↩
