Verschwendung von Zeit und Ressourcen ist eines der Grundübel in jedem Unternehmen, aber auch in Prozessen wie dem Testen von Software. Dabei ist die Verschwendung oft gar keine böse Absicht und kann mehrere Ursachen haben. In der Softwareentwicklung gibt acht besonders herausragende Gründe für Verschwendung

Effizienz kann man auch als Sparsamkeit bezüglich des eingesetzten Aufwands zur Erreichung der Ziele des Vorhabens definieren. Es ist damit auch ein Indikator für Verschwendung. In der Industrieproduktion ist die Verschwendung besonders umfangreich betrachtet worden. Statt der Verschwendung und ihrer negativen Besetzung hat sich das Wort Lean etabliert, das für die schlanke Produktion steht. Lean gibt es mittlerweile in vielen Branchen und Prozessen, sogar in Organisationen. Vorreiter war das Autounternehmen Toyota, das nach dem Zweiten Weltkrieg begann, aus der Rohstoffnot heraus Produktionsmethoden zu entwickeln, in denen es keine Verschwendung gab. Das Toyota-Produktionshandbuch wurde zur Lean Bibel und identifizierte sieben Hauptquellen der Verschwendung:

  • Vorräte: Unfertige Produkte („Work in Progress“ oder WiP)
  • Überproduktion: am Bedarf vorbei produzieren
  • Überflüssige Prozessschritte: Im Prozess gibt es Schritte, die Zeit, Geld und Ressourcen kosten, aber dem Produkt nicht helfen
  • Transport: Wenn Güter zu weit transportiert werden müssen
  • Warten: wenn ein Schritt auf den anderen warten muss
  • Bewegung: Transport von Gütern und Produktionselementen im Fertigungsprozess
  • Defekte: Fehler im Produkt oder Produktteilen, die dessen Funktionen und die Qualität betreffen einschränken

Diese Quellen der Verschwendung verursachen einen hohen Zeit- und Kostenaufwand, tragen aber nichts zur Wertschöpfung bei.

Mittlerweile hat diese Betrachtungsweise auch in die Softwareentwicklung Einzug gehalten. Man kann aus den Toyota-Richtlinien auch Verschwendungspotenziale in diesem Bereich ableiten.

Folgende acht Formen der Verschwendung kommen dabei in Frage:

Falsches Produkt: Das Produkt ist nicht das, was der Kunde erwartet, es erfüllt nicht seine Bedürfnisse und löst nicht seine Probleme. Man hat dem Kunden nicht zugehört, die Requirements nicht gelesen oder verstanden oder war zu fokussiert auf das eigene Angebot. Daraus resultieren – je nach dem, wann man den Fehler bemerkt – Verschwendungen durch unnötige Iterationen und Entwicklungsschritte. Es werden Funktionen programmiert, die am Ende unnötig sind und neu definiert werden müssen, weil der Kunde sie nicht abgenommen hat und nicht seiner Definition of Done entsprechen.

Probleme bei den Spezifikationen: Zwar kommen die Requirements bei den zuständigen Ingenieuren richtig an, sie haben aber Probleme, diese auch den Entwicklern verständlich zu machen. Das Produkt wird dabei falsch spezifiziert, und die Entwickler sind auf dem falschen Weg. Auch hier wird eine Zeitlang gearbeitet, ohne dass man das Produkt kundengerecht weitergebracht hat. Man muss dann wieder zurückgehen und neue Spezifikationen schreiben.

Falsche Methoden und Werkzeuge: Das alte Sprichwort, dass man, wenn man einen Hammer hat, jedes Problem als Nagel versteht, stimmt auch bei der Softwareentwicklung. Zu groß ist die Versuchung, seine bevorzugten Methoden und Entwicklungsumgebungen einzusetzen, statt zu schauen, was am besten für den Kunden passt. Manchmal sind die Methoden auch schlicht veraltet, weil man sich nicht auf den neuesten Stand gebracht hat. Ein Beispiel ist das Testen nach Fertigung von Softwareteilen, statt bereits bei der Codequalität auf Fehler zu achten und regelmäßige Reviews durchzuführen. Auch bei den Werkzeugen gibt es oft Verbesserungsbedarf, wenn mit alten Entwicklungsumgebungen gearbeitet wird. Manche Programmierer benutzen sogar noch reine Text-Editoren. Gerade hier wird die “Geht doch”-Mentalität als Grund sichtbar, warum man nichts verändern und modernisieren will. Andere Gründe sind fehlendes Wissen und nicht ausreichende Finanzmittel.

Ineffiziente Verwendung von Werkzeugen und Methoden: Sowohl im klassischen Projektmanagement als auch in Firmen, die agile Frameworks benutzen, werden immer wieder die vorhandenen Werkzeuge und Methoden nicht optimal ausgenutzt. Bei den Methoden wird nicht den Vorgaben entsprechend gearbeitet, es werden Fehler akzeptiert und Reviews vergessen. Bei Scrum kann es sogar vorkommen, dass man aus Kostengründen auf den Scrummaster verzichtet oder sich die Retrospektive schenkt. Gerade diese soll aber bei Scrum die Verschwendung aufdecken. Es kann auch eine gewissen Scrum-Müdigkeit geben, bei der dann die Stand-Ups und Reviews zu Pflichtübungen verkommen, ohne dass es konstruktiven Input gibt.

Organisation als Bremse: Gerade in großen Unternehmen können die internen Strukturen und Abläufe als eine Bremse wirken. Wenn mehrere Teams und Abteilungen zusammenarbeiten müssen, kann es durch langwierige Abstimmungsprozesse zu Zeitverlusten kommen. Aufgrund fehlender Kommunikation kann es sogar vorkommen, dass zwei Teams am gleichen Produkt arbeiten oder Schnittstellen nicht passen. Das verlangsamt die Entwicklung, andere Teams bekommen keine Arbeit und der Release-Termin kann nicht gehalten werden.

Keine Automatisierung: Viele Arbeiten werden aus Gewohnheit noch händisch durchgeführt, auch wenn es längst Werkzeuge dafür gäbe. So kann die Anforderungsqualität automatisch getestet werden, Code kann auch Modellen entnommen werden, die Qualität des Codes kann ständig im Hintergrund überwacht werden. Gerade beim Testen eliminiert die Automatisierung viele Fehlerquellen, wenn man sie bei Uni-Tests, Integrationstests, UI-Tests, Akzeptanz-Tests mit Behavior-Driven-Development, Generierung von Testdaten oder der Automatisierung von Build und Development einsetzt. Mit solchen Werkzeugen steigt nicht nur die Qualität, sondern man verringert auch Aufwand und Verschwendung. Ein Beispiel ist die Testautomatisierung: Schon nach sieben Iterationen ist diese dem manuellen Test voraus.

Das Rad neu erfinden: Wir neigen dazu, Dinge zu erschaffen die es eigentlich schon gibt. Programmierer wollen am liebsten den Code von Grund auf neu schreiben, weil vorgegebene Modelle und Bausteine nicht ihren Vorstellungen entsprechen. Während aber das Framework eigentlich gute und vor allem getestete Funktionen bietet, steigt beim Neu-Programmierern die Fehlerquote rasant an. Diese müssen dann gefunden und korrigiert werden, was eine große Verschwendung von Ressourcen darstellt.

Defekte: Jeder macht Fehler, die Frage ist nur, wie man damit umgeht. Aus Fehlern lernen heißt, ihnen auf den Grund zu gehen, die wahren Ursachen zu erkennen und dann solche Fehler in Zukunft zu vermeiden. Das braucht aber auch ein Klima, in dem Fehler als Teil der Entwicklung angesehen werden und Teil des Qualitätsmanagements sind. Mitarbeiter dürfen keine Angst davor haben, Fehler zu machen, sondern sie melden dürfen und müssen, um daraus die richtigen Lehren ziehen zu können.

 

Wir haben wichtige Fragen erarbeitet, die als eine Art Checkliste helfen können, um die Effizienz in einem Unternehmen zu steigern:

  • Welche Ziele verfolgen wir wirklich mit unserem Projekt, und welche Ziele sind uns von der Organisation gegeben?
  • Welchen minimalen Aufwand brauchen wir, und wie groß ist der Aufwand den wir brauchen, um unter besten Bedingungen unsere Ziele erreichen zu können?
  • Welche Verschwendung gibt es in unseren Prozessen? Was sind die Bremsen?
  • Sind unsere Produkte wirklich das, was der Kunde möchte? Haben wir ihn verstanden?
  • Stimmen die Spezifikationen, sind sie detailliert, verständlich für die Entwickler und so präzise, dass schon die ersten Prototypen erfolgversprechend sind?
  • Haben wir effiziente Methoden und Werkzeuge?
  • Sind wir optimal strukturiert, können wir Flaschenhälse und Wartezeiten vermeiden und abbauen und Abhängigkeiten reduzieren?
  • Automatisieren wir soweit es möglich ist, auf allen Ebenen wie Entwicklung, Testen und Deployment, aber auch im Unternehmen selbst?
  • Sind externe Leistungen optimal, bedienen wir uns dem Wissen und den Fähigkeiten anderer, um besser zu werden?
  • Versuchen wir von vorneherein beste Qualität zu bieten? Entdecken wir Fehler frühzeitig und sind wir in der Lage, Fehler zu vermeiden?
  • Auf was können wir verzichten, was können wir verbessern, wie können wir die Effizienz erhöhen und damit den Aufwand so gering wie möglich halten?

Diese Fragen sollen dabei helfen, den Ist-Zustand zu beschreiben, und daraus die entsprechenden Maßnahmen zur Effizienzsteigerung abzuleiten, aber auch die Verschwendung zu verringern und letztlich bessere Software zu entwickeln.