Mülltrennung in der Softwareentwicklung

Wussten Sie, dass es jetzt auch den „grünen Punkt“ in der Softwareentwicklung gibt? Ja, das Trennen nach recycelbaren Entwicklungsergebnissen macht Sinn. Andere wiederum müssen „entsorgt“ werden – die meisten Halden werden in unserer Industrie als Archive bezeichnet. Wenn Sie erfahren wollen, wie Sie die richtige Mülltrennung hinbekommen können, lesen Sie weiter …

Wenn wir von Müll sprechen, dann geht es um Rohstoffe. Aber was sind die Rohstoffe in der Softwareentwicklung? Die Software selber, Anwender-Handbücher, Release-Notes – darauf kommt man schnell. Und was ist mit Testfällen, Tasks, Defekts und Requirements? Und wie ist es mit den agilen Rohstoffen – hier gehört die Vermeidung von Waste fest zum Programm? Letztendlich zeichnen sich die Rohstoffe dadurch aus, dass Sie von Wissensarbeitern, in teilweise sehr kreativen Verfahren, gewonnen werden müssen. Diese Rohstoffe – oder auch Artefakte – sind also schon dadurch wertvoll, weil wir für ihre Erstellung knappe Güter wie Zeit und unser Wissen investieren müssen. Daraus ergeben sich für ressourcenschonendes Handeln folgende Schlüsse:

• Wir erzeugen nur Artefakte in der notwendigen Qualität, die wir aktuell – also in zuverlässig bewertbarer Zeit – benötigen. Dadurch reduzieren wir die Verschwendung.
• Wir recyceln die Artefakte, die wir in der Zukunft wieder brauchen werden, wenn deren Neuerstellung mehr Ressourcen bindet, als die Lagerung und Verwaltung. Auch hier gilt, je aufwendiger die Herstellung, desto nützlicher das Recycling. Dadurch schonen wir Ressourcen für die Artefakt Erstellung.
• Wir trennen in die Artefakte, die wir nur begrenzt nutzen. Diese werden typischerweise archiviert oder endgültig entsorgt. Dadurch reduzieren wir Lager- und vor allem Verwaltungskosten.

In Abbildung 1 sehen Sie einen Vorschlag, nach welchen Kriterien eine Trennung der Artefakte erfolgen kann. Die recycelbaren Entwicklungsergebnisse werden als „product items“ klassifiziert. Disjunkt dazu sind „project items“ Artefakte, die nach ihrer Verwendung entsorgt, oder aus Nachweisgründen archiviert werden müssen.

Die „project items“ könnte man also als Einweg-Artefakte bezeichnen. Hier ist es besonders wichtig, dass bei der Erstellung solcher Ergebnistypen keine Ressourcenverschwendung stattfindet. Denn der Nutzen kann nur einmal erzeugt werden. Beispielsweise sollten Artefakte wie die Tasks in kurzer Zeit und mit wenig Aufwand erstellt werden. Eine ausgefeilte Taskbeschreibung wäre hier Verschwendung.

Im Gegensatz dazu könnten die „product items“ als Mehrweg-Artefakte bezeichnet werden. Hier ist es besonders wichtig, dass bei der Erstellung solcher Ergebnistypen eine angemessene Qualität erzeugt wird. Dies erfordert meist eine sorgfältige und angemessene Arbeitsweise, was einer ressourcenschonenden Arbeitsweise bedeutet. Der Nutzen kann bei jeder Wiederverwendung erzeugt werden. Beispielsweise sollten Artefakte wie Source Code ihre Qualität zum einen in ihrer Struktur (erfolgreiche statische Code-Reviews) und ihrer Funktionalität (erfolgreiche Unit Tests und Build-Läufe) nachvollziehbar machen. Nur die angemessen Qualität der Entwicklungsergebnisse stellt deren effiziente Wiederverwendung sicher.

Abbildung 1: Unvollständige Klassifizierung von Entwicklungsergebnissen

Die oben beschriebenen Beispiele mit Task und Source Code sind sehr gut geeignet, das Gedankenmodell der Artefakt-Trennung zu veranschaulichen. Daneben gibt es aber auch so genannte „Verbundstoffe“. Ich meine damit Artefakte die nicht vollständig recycelt werden sollten, sondern nur ein definierter Teil der Entwicklungsergebnisse. In Abbildung 1 sind solche nicht-recycelbare Eigenschaften der Entwicklungsartefakte als „volatile property“ klassifiziert. Der Umgang mit solchen Eigenschaften ist gleich dem Umgang mit „project items“, was am Beispiel Requirement mit der Eigenschaft „Assigned To“ gut ersichtlich ist.

Wenn also ein Requirement wiederverwendet wird (ich unterstelle einen neuen Projekt-Kontext) muss die Zuweisung des Requirements zu einem „Empfänger“ neu definiert werden. Dieser Punkt ist auch dann essentiell, wenn die gleiche Person wie zuvor gewählt wird, um ein gemeinsames Verständnis über die Anforderung zu erreichen. Wenn wir bewerten und entscheiden, welche Lösung zu Realisierung der Requirements notwendig ist, muss dies immer im „neuen“ Projekt-Kontext erfolgen. Neben einer geänderten Fachlichkeit, können eben auch Änderungen im Projektteam eine andere Lösung nach sich ziehen. Deshalb muss die Entscheidung bewusst getroffen werden, wer „Empfänger“ ist. Natürlich ist die Erwartung, dass die wiederholten Abläufe entsprechend schneller abgearbeitet werden können.

Noch ein Blick zu den Beziehungen zwischen den Artefakten. Hier lassen sich die gleichen Regeln wie bei den Artefakten anwenden. Beziehungen zwischen „product items“ müssen eine angemessene Qualität besitzen und Beziehungen zwischen und zu „project items“ müssen, wenn sie denn Notwendig sind, minimale Aufwände verursachen.

Zum Abschuss will ich gerne noch eine Kontroverse anstoßen. Klassifizieren Sie jetzt nach dem vorgestellten Schema einmal die Artefakte, denen Sie in Ihrem Arbeitsumfeld begegnen. Identifizieren Sie Typen, bei denen Ihnen die Zuordnung schwer fällt? Was machen wir mit User Storys, Epics oder Themes? Gerade mit den User Storys wird die Idee verbunden weniger gegeneinander zu schreiben als mehr miteinander zu reden. Diesen Ansatz kann ich für alle „product und project items“ ausdrücklich unterstützen. Meine Kritik an dieser Stelle bezieht sich eher auf die Umsetzung dieser neuen Artefakt-Typen in den Arbeitsumgebungen der Entwicklerteams. Schwache Semantiken und unvollständige Lebenszyklen dieser Artefakte machen eine Mülltrennung eher schwierig (siehe Abbildung 2).

Abbildung 2: Schwache Semantik im Lebenszyklus einer User Story

Die Neigung zur Wegwerf-Entwicklung bereitet mir Unbehagen, weil ich gerade im industriellen Umfeld den nachhaltigen Umgang mit unserem Wissen und unserer Zeit vermisse. Hier sind wir gefragt, mit intelligenten Ansätzen gegenzusteuern. Damit wir unsere Projekte nicht so beenden müssen wie in Abbildung 3 mancherorts das Frühstück endet. 

Abbildung 3: Wegwerf-Gesellschaft

In diesem Sinne Ihr Waste-Watcher Jens Donig.

Jens Donig

Kontaktieren Sie Jens Donig

Jens Donig ist systemischer Coach (dvct) und Principal Consultant für Software- und Systems- Engineering. Die Schwerpunkte seiner Coaching- und Beratungstätigkeit liegen in den Bereichen Organisationsentwicklung, Teamentwicklung und der persönlichen Entwicklung seiner Kunden. Seit mehreren Jahren beschäftigt er sich mich intensiv mit der nachhaltigen Verankerung von Veränderungsprozessen in Organisationen verschiedener Branchen. Auf Basis des systemischen Coachings, von Transformationsprozessen und agiler Werte und Prinzipien, begleitet er seine Kunden erfolgreich auf ihrem persönlichen Weg der Weiterentwicklung und Veränderung.