Im letzten Blogartikel „Effizienz als Vermeidung von Verschwendung“ habe ich mich an eine neue Definition von Effizienz im Sinne eines Maßes für die „Sparsamkeit bezüglich des eingesetzten Aufwands zur Erreichung der Vorhabensziele“, anders gesagt als Maß für die Vermeidung von Verschwendung gewagt. Eine ganz ähnliche Definition wird in der Produktion von Gütern verwendet. Das Thema Verschwendung ist in diesem Bereich schon sehr gut untersucht. Zur Vermeidung von Verschwendung hat sich unter dem Schlagwort „lean“ eine ganze Schule von Konzepten und Maßnahmen entwickelt. Toyota ist in diesem Bereich ganz vorne mit dabei. Bereits in den 1940er Jahren untersuchte der Autobauer, welche die häufigsten Quellen von Verschwendung sind und identifizierte die „7 wastes in manufactoring“ [1]:
- Vorräte: Unfertige Produkte („Work in Progress“ oder WiP)
- Überproduktion: Mehr zu erzeugen, als der Bedarf tatsächlich benötigt
- Zusätzliche Verarbeitungsschritte: Zusätzliche Schritte im Prozess, die nicht wirklich notwendig sind
- Transport: Güter von einem Ort an einen anderen bringen
- Wartezeit: Pausen zwischen Prozessschritten
- Bewegung: Herumbewegen von Gütern im Prozess
- Defekte: Fehler im Produkt, die dessen Funktionen einschränken
Diese 7 Arten von Verschwendung kosten nur Zeit und Geld, ohne direkt oder indirekt etwas zur Wertschöpfung beizutragen.
Auch in der Softwareentwicklung kann man immer wiederkehrende Arten von Verschwendung identifizieren. In Anlehnung an die 7 Wastes von Toyota sehe ich folgende 8 Arten von Verschwendung in der Softwareentwicklung:
- WRONG PRODUCT - Wir bauen das falsche Produkt: Das erstellte Produkt deckt nicht den Bedarf des Kunden, es löst sein Problem nicht oder nur unzureichend, und bringt ihn seinem Ziel nicht näher. Hier passen oft die Requirements nicht. Wir verstehen nicht, was der Kunde eigentlich braucht, zum Teil weiß er es auch selbst nicht. Wir spezifizieren das falsche Produkt. Oft brauchen wir viele Iterationen, bis das Produkt tatsächlich einsetzbar ist. Dabei wird vieles gebaut, was schlussendlich entweder wieder ausgebaut oder verändert werden muss, nachdem der Kunde es gesehen hat.
- MISLEADING SPECIFICATION - Die Spezifikation passt nicht als Input für die Entwicklung: Selbst wenn wir als Requirements Engineer richtig verstanden haben, was der Kunde möchte, schaffen wir es oft nicht, diese Information so zu den Entwicklern zu transportieren, dass diese auf Anhieb verstehen was gewünscht wird, um es richtig umsetzen zu können. Wir spezifizieren das richtige Produkt auf falsche Art und Weise. Wiederum sind mehrere Iterationen nötig, bis das gebaute Produkt mit den Anforderungen übereinstimmt und einsetzbar ist.
- WRONG METHODS AND TOOLS - Wir setzen ineffiziente Entwicklungsmethoden ein: In vielen Fällen sind die eingesetzten Methoden und Werkzeuge veraltet oder für das Produkt nicht passend. Beispielsweise wird viel Aufwand in nachgelagertes Testen zum Finden von Fehlern gesteckt, obwohl es nachweislich effizienter wäre, mehr Aufwand vorab in die Code-Qualität zur Vermeidung von Fehlern, z.B. durch Code-Reviews, zu stecken. Auf der Toolseite wird überraschend oft mit veralteten Entwicklungsumgebungen bis hin zu Text-Editoren programmiert, obwohl es neue Entwicklungsumgebungen gibt, die wesentlich effizienteres Arbeiten ermöglichen. Die Gründe sind mannigfaltig und gehen von Nicht-Hinterfragen historisch gewachsener Strukturen und Gewohnheiten bis hin zu fehlendem Know-how und fehlendem Budget.
- INEFFICIENT USE OF METHODS AND TOOLS - Wir haben zwar gute Methoden, setzen sie aber ineffizient ein: Diese Verschwendung sieht man sowohl in klassisch plangetrieben ar-beitenden Organisationen als auch in „agilen“ Entwicklungsteams. Die Methoden werden schlampig, teilweise unvollständig, oder fehlerhaft eingesetzt. In Scrum beispielsweise wird allzu oft auf den Scrum Master verzichtet, die Retrospektive am Ende des Sprints wird nicht gemacht, obwohl gerade sie dazu da wäre, Verschwendung aufzudecken und abzustellen, und Daily Standup und Review verkommen zu mechanischen Übungen ohne Sinn und Nutzen.
- ORGANISATION AS IMPEDIMENT - Die Organisation behindert effizientes Arbeiten: In vielen, gerade größeren Unternehmen, wo mehrere Teams und Abteilungen an einem Produkt arbeiten, geht sehr viel Zeit für die Abstimmung der Teams untereinander verloren. Es werden Dinge mehrfach entwickelt, Schnittstellen passen nicht zusammen und Teams müssen auf die Ergebnisse anderer Teams warten. Dies führt zu Wartezeiten, Fehlern und viel Stress am Ende vor dem Release.
- LACK OF AUTOMATION - Wir machen Dinge händisch, die automatisiert werden könnten: Mittlerweile kann in der Softwareentwicklung vieles automatisiert werden: Automatisierte Prüfung der Anforderungsqualität, Code aus Modellen generieren, Codequalität durch statische Analysetools prüfen, Testautomatisierung auf unterschiedlichen Ebenen (Unit-Tests, Integrationstests, UI-Test, Akzeptanztests mittels Behaviour-Driven-Development, …), Generierung von Testdaten, Automatisiertes Build und Depolyment, u.v.m. Durch Automatisierung sinkt langfristig der Gesamtaufwand. Bei der Testautomatisierung beispielsweise ist im Schnitt nach 7 Iterationen der Break-Even zur manuellen Testausführung erreicht. Dennoch wird in vielen Unternehmen manuell getestet, keine statische Analyse durchgeführt etc.
- REEINVENTING THE WHEEL - Wir bauen Dinge selbst, die es bereits gibt: Als Softwareentwickler sind wir ein Volk von Selberbauern. An jedem Tool oder Framework finden wir etwas auszusetzen, irgendeine Kleinigkeit, wegen der wir es nicht verwenden und stattdessen von Null weg selber machen müssen. Dabei bauen wir auch alle Funktionen nach, die das existierende Framework in guter Qualität bereits bietet. Schlimmer noch, wir machen auch viele Fehler erneut selbst, die die Hersteller des bestehenden Tools schon gemacht und ausgemerzt haben.
- DEFECTS - Wir machen Fehler: Stichwort Fehler. Jeder Fehler, der gemacht wird, kostet Zeit und Geld. Natürlich ist es wichtig, Fehler machen zu dürfen und wir müssen ein Klima schaffen, in dem niemand Angst davor haben muss, einen Fehler zu machen. Aus Effizienzsicht betrachtet gilt aber, je weniger Fehler wir machen, desto effizienter sind wir.
Im letzten Blog zum Thema Effizienz habe ich mit einer einfachen Checkliste mit 4 Grundfragen geendet, welche helfen, die Effizienz zu steigern. Die oben postulierten 8 Arten von Verschwendung können verwendet werden, um diese Checkliste auszubauen und die letzten beiden Fragen für die eigene Entwicklungsorganisation zu beantworten:
- Was sind denn eigentlich wirklich die Ziele, die wir in unserem Projekt verfolgen? Welche Ziele kommen von der Gesamtorganisation dazu?
- Wie hoch ist der minimal mögliche Aufwand? Wieviel Aufwand brauchen wir selbst unter optimalen Bedingungen mindestens, um diese Ziele erreichen zu können?
- Was haben wir an Verschwendung in unseren Prozessen? Was hält uns auf?
- Bauen wir das richtige Produkt? Wissen wir von Anfang an, was der Kunde braucht?
- Passt die Spezifikation für unsere Entwickler? Spezifizieren wir richtig, detailliert genug und verständlich, sodass bereits der erste Wurf gut ist?
- Setzen wir effiziente Entwicklungsmethoden und Tools ein?
- Verwenden wir unsere Methoden und Tools richtig?
- Ist unsere Organisation optimal aufgestellt? Vermeiden wir Wartezeiten, Abhängigkeiten und Bottlenecks?
- Automatisieren wir alles, was möglich und sinnvoll ist? In der Entwicklung? Beim Testen? Im Deployment? Im Betrieb?
- Kaufen wir gute Komponenten zu? Nutzen wir Wissen und Produkte von anderen?
- Liefern wir hohe Qualität bereits beim ersten Mal? Finden wir Fehler möglichst früh? Wie gut gelingt es uns, Fehler gar nicht erst zu machen?
- Was können wir weglassen? Was können wir verbessern, um effizienter zu werden, also um uns dem minimal möglichen Aufwand anzunähern?
Diese Checkliste ist ein guter Startpunkt für eine Positionsbestimmung in Bezug auf die eigene Effizienz. Sie ist auch ein guter Ausgangspunkt für die Entwicklung gezielter Maßnahmen zum Abstellen von Verschwendung und Verbessern der Effizienz in der Softwareentwicklung.
