Tipps und Tools gegen Zeitverlust

7 Zeitfresser in der Software-Entwicklung – und was man dagegen tut

Christoph Ebert

© Shutterstock/Jason Salmon

An welchen Stellen verlieren Entwicklerteams die meiste Zeit? Denn schon wieder ist die eine Situation eingetreten, die man doch unbedingt verhindern will: die Deadline wird verpasst.

Jetzt hat das Projekt Verspätung – und das Ende der Entwicklungsphase ist noch nicht in Sicht. Folglich wird sogar der Kunde langsam nervös und der Termindruck auf das Entwicklungsteam wächst mit jedem weiteren Tag. Die Konsequenz ist klar: Um die nächste Deadline zu halten, wird man jede Menge Überstunden machen müssen und viel technische Schuld auf sich nehmen. Ergo geht das Team auf dem Zahnfleisch.

Doch was sind eigentlich die großen Zeitfresser? Warum verlieren Entwicklungsteams immer wieder wichtige Zeit? Und wenn man die Faktoren identifiziert hat: Welche Maßnahmen müssen ergriffen werden, um die Zeitachse zu kürzen? Welche Tools können dabei helfen?

Martin Ruprecht, JavaScript- und PHP-Architekt sowie Product Owner bei Mayflower, erzählte in seiner Session „Wie manage ich Zeitfresser in Softwareprojekten?“ von eigenen Projekterfahrungen und den Learnings, die er und seine Kollegen daraus abgeleitet haben.

Was sind also die potenziellen Zeitfresser? Die üblichen Verdächtigen sind meist das lockere Treffen an der Kaffeemaschine, eine gediegene Runde Kicker, E-Mails abarbeiten oder Meetings.

Doch betrachtet man die Prozessabläufe in der Softwareentwicklung, stellen sich die oben genannten Faktoren als nicht besonders zeitfressend heraus. Sicher, Meetings, vor allem ungeplante, können Zeitpläne durchaus durcheinander bringen. Aber es sind vor allem die folgenden sieben Faktoren, die einen viel größeren Einfluss auf das Zeitmanagement haben. Sie sind der „waste“, den man aus dem Weg räumen muss. Entfernt man solch „unbrauchbare“ Prozessabläufe, entschlackt und verbessert man automatisch den Prozess.

Nr. 1: halbfertige Arbeit

Zeitfresse Nummer eins ist halbfertige Arbeit. Sie entsteht, wenn man die funktionalen Anforderungen an eine User Story nicht erfüllt, denn nicht abgeschlossene Arbeit kann so nicht an den Kunden ausgeliefert werden. Diese Situation entsteht, wenn man beispielsweise nach dem Prinzip des Test Driven Development arbeitet (TDD), aber kein Refactoring durchführt. Die Arbeit ist dann nur halb fertig, weil das Refactoring irgendwann später nachgeholt werden muss, denn der Code ist nicht (ausreichend) getestet.

Doch wie kann es überhaupt soweit kommen? Laut den Erfahrungen von Martin Ruprecht führt beispielsweise Schlampigkeit beim Aufstellen von Subtask (nicht alle Subtasks wurden identifiziert), das Nicht-Beenden einer existierenden, halbfertigen Story und das Nachziehen einer neuen Story in den Sprint. Oft wird auch die technische Komplexität im Sprint Planning nicht richtig eingeschätzt.

Dagegen steuern kann man mithilfe verschiedener Ansätze. Einerseits kann man Komplexität durch einen Spike evaluieren. Darüber hinaus sollte Koordination und Kolloboration im Fokus stehen. Denn Diskussionen mit dem Product Owner helfen dem Team User Stories und die Priorisierung richtig zu verstehen. So lassen sich auch etwaige Blocker identifizieren und sichtbar machen.

Nr. 2: Extra-Features

Die Umsetzung von nicht abgesprochenen Features oder das Over-Engineering von einfachen Tasks erweisen sich im Alltag ebenfalls als großer Zeitfresser. Das sogenannte „Gold Plating“ durch Entwicklerteams, unbekannte oder nicht konkret definierte Zielgruppen sowie ein falsches Feature-Verständnis sind die Gründe.

Ein Ausweg aus dieser Over-Engineering-Misere ist bspw. Pair-Programming. Auch das Strukturieren der Arbeit in sogenannte „Baby Steps“, eine klare Priorisierung durch den PO und die Bekanntmachung derselben sowie Prinzipien wie KISS („Kepp it simple stupid“) oder YAGNI (You ain’t gonna need it) helfen dabei, Zeitprobleme durch Extra-Features zu vermeiden.

Nr. 3: Relearning

Relearning bedeutet, dass das bereits vorhandene Wissen nicht im gesamten Team bekannt bzw. verbreitet ist. Dabei können die Gründe hinter Relearning ganz verschieden sein. Manch ein Mitarbeiter mag eventuell eine „hidden agenda“ haben und beispielsweise für sich entschieden haben: „Ich will auch mal ein ORM bauen!“. Oder es gibt keinen fest etablierten Prozess, um Wissen im Team zu verteilen – vielleicht weil es zu wenig Kommunikation gibt. Alle voran resultiert Relearning aber vor allem aus Unwissen. Unwissen der Teammitglieder darüber, welches Wissen überhaupt im Team vorhanden ist.

Vorgehen lässt sich dagegen beispielsweise, indem stets alle Teammitglieder an den Teammeetings teilnehmen. Auch das kontinuierliche Teilen von Wissen durch Pair Programming ist von Vorteil. Nutzt man ein Wissensmanagement-Tool wie Confluence kann man alle relevanten Informationen sind für alle Teammitglieder einsehbar machen. Baut man ferner noch eine allgemeine Knowledge Base bzw. eine Knowledge Backlog auf, ist bestens gegen Zeitverluste durch Relearning gerüstet.

Nr. 4: Übergaben

Man kennt den Fall: Ein Kollege geht in den Urlaub und niemand weiß, an was er gearbeitet hat. Damit das nicht passiert, gibt es Übergaben. Doch eine an sich simple Sache wie eine Übergabe kann durchaus Probleme nach sich ziehen. Zu Schwierigkeiten kommt es gerne mal, wenn das Team an verschiedenen Standorten arbeitet oder wenn der Aufbau der User Story keinen anderen Ablauf zulässt.

Deshalb gilt es die Daily Scrum, Sprint Planning und Sprint Refinement Meetings ganz gezielt zum Wissensaustausch zu nutzen. SO lässt sich sicherstellen, dass Aufgaben fertiggestellt werden können und dass Ablaufdiagramme und Wireframes an allen Standorten bekannt sind.

Nr. 5: Verzögerungen

Auf den ersten Blick entziehen sich Verzögerungen oftmals dem eigenen Einflussbereich. Egal ob Wartezeiten für Requirements, Übersetzungen, Tests, Wartungsfenster, Änderungen an Servereinstellungen oder Reviews von Pull-Requests – es handelt sich meist um vermeintlich unvermeidliche externe Abhängigkeiten. Schaut man auf die Gründe, erscheint vieles jedoch nicht mehr unvermeidlich. So resultieren die Abhängigkeiten bspw. aus einem falschen Verständnis von Value, aus generell unerwünschten Prozessen oder aus der Tatsache, dass es zu viele „Works in Progress“ (WiP) gibt.
Umgehen lassen sich solche Verzögerungen, in dem man die externe Abhängigkeiten früh abklärt, mit einplant und sichtbar macht. Außerdem sollte man den WiPs unbedingt ein Limit setzen und sie im Daily Blocker identifizieren.

Nr. 6: Kontextwechsel

Springen Teammitglieder von einer Aufgabe zur anderen oder werden ständig durch ungeplante Suppport-Aufgaben während des Sprints abgelenkt, werden sie aus ihrer Konzentration heraus gerissen. Auch die sogenannten „Hey Joes“, also die “Nachbarschaftshilfe” (Peer Support) im IT-Support sind problematisch, das sie den vorgesehenen Arbeitsprozess (Workflow) umgehen. Auch zu wenig Abstimmung zwischen PO und Entwicklern oder das Beackern zu vieler Projekte zur selben Zeit führt zu Kontexwechseln.
Um dem gegenzusteuern, sollte der PO eine klare Reihenfolge für die Abarbeitung der User Stories im Sprint vorgeben. Ferner sollten Support-Aufgaben geplant, zu einem definierten Zeitpunkt abgearbeitet werden und im Sprint Planning sichergestellt sein, dass alle Tasks zu einer Story detailliert genug sind.

Nr. 7: Fehler in der Funktionalität

Fehler in der Funktionalität entstehen natürlich vor allem durch Fehler im Produkt. Aber auch der Ausfall einer Servicedienstleistung kann sich zum Zeitfresser entwickeln. Die Gründe für solche Fehler sind vielfältig: fehlende Akzeptanzkriterien, fehlende (automatisierte) Tests oder die Tatsache, das Tester erst zu spät ins Projekt gekommen sind. Auch falsch verstandene User Stories oder fehlendes TDD bzw. Refactoring können Fehler in der Funkionalität auslösen.

Als Gegenmaßnahme empfiehlt sich, nicht mit der Entwicklung zu starten, bevor das Team die User Story nicht komplett verstanden hat. Die Einführung von TDD, Pair Programming und Refactoring von bestehendem Code sind Pflicht, das Aufsetzen einer automatisierten Test Suite ratsam.

Halbfertige Arbeit, Extra-Features, Relearning, Übergaben, Verzögerungen, Kontextwechsel und Fehler in der Funktionalität – das sind die sieben großen Faktoren, die zu Zeitfressern in der Entwicklung werden können. Alle sieben immer und in jedem Projekt auszuschalten ist eine schwere Aufgabe. Doch mit richtiger, vorausschauender Planung und der Beachtung bestimmter Prinzipien lassen sich die Zeitfresser weitestgehend eindämmen und aus den Prozessabläufen heraushalten.

Aufmacherbild: individual businessperson trying to perform via Shutterstock / Urheberrecht: Jason Salmon

Geschrieben von
Christoph Ebert
Christoph Ebert
Christoph Ebert stieß im Juli 2011 zum Online-Team von Software & Support Media. Als Redakteur kümmert er sich um das Portfolio von entwickler.press und ist verantwortlich für das Entwickler Magazin und entwickler.de. Davor betreute er die Portale WebMagazin.de, CreateOrDie.de und mobile360.de. Vor seiner Zeit in Frankfurt arbeitete der studierte Amerikanist und Tech-Geek als Redakteur für ein Heimkinofachmagazin im Süden Deutschlands.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: