Hood Blog
zu HOOD Group
Mülltrennung in der Softwareentwicklung
Erstellt am 6 März 2013
von Jens Donig Schreibe einen Kommentar 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.
Veröffentlicht unter Fachlich, Modellierung, RE im Application Lifecycle, Requirements Engineering | Verschlagwortet mit: ALM, Modellierung, Requirements, User Story, Wiederverwendung
Authors: Jens Donig Früher Nächste Zeige alle Beiträge von Jens Donig
Kontaktieren Sie Jens Donig
jens.donig@hood-group.com Jens Donig ist Principal Consultant für Software- und Systems- Engineering bei der HOOD Group. Die Schwerpunkte seiner Beratungs- und Coaching Tätigkeit liegen in den Bereichen Organisationsentwicklung, agile Softwareentwicklungsprozesse und Requirements Engineering (RE). Seit mehreren Jahren beschäftigt er sich intensiv mit der nachhaltigen Verankerung von integriertem ALM (Application Lifecycle Management) in Organisationen verschiedener Branchen. Auf Basis der TOC (Theory of Constraints) – Methoden, modellbasierter Ansätze und Produktentwicklungsstrategien wie Produktlinien-, Baukasten- und Modulstrategien, ist ein erfolgreicher Ansatz zur Entwicklung dynamikrobuster Unternehmen entstanden. Er ist Mitbegründer der Value-oriented Practices und des ALM Solution Framework für TFS. Schreibe einen Kommentar Antworten abbrechen	Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.Vorname, Name
We are social, follow us on
Aktuellste Artikel	Die abgespeckte Sprint-Retrospektive
Projekterfolg erleben
Systems Engineering und Requirements Engineering – Gedanken aus dem Tag des Systems Engineering 2016
TdSE 2016 – Trends im Systems Engineering
Schwarmintelligenz – gemeinsam weiterhelfen
Kategorien	Allgemein (11)
Fachlich (26)
HOOD News (36)
HOOD Products (8)
Modellierung (27)
RE im agilen Umfeld (105)
RE im Application Lifecycle (42)
RE im Systems Engineering (38)
Requirements Definition (34)
Requirements Engineering (217)
Requirements Management (59)
RM Tools (17)
Testmanagement (5)
Textuelle Anforderungen (17)
Blick über den Tellerrand
HOOD GmbH
REConf 2016
Copyright © HOOD Group GmbH 2016 Diese Website benutzen Cookies. Wenn Sie die Website weiter nutzen, stimmen Sie der Verwendung von Cookies zu.Akzeptieren