Wann ist es endlich fertig? Wie du die Frage in Softwareprojekten nicht pauschal, sondern professionell beantwortest

Nach meinem Studium arbeitete ich als Softwareentwickler. Dabei wurde mir schnell eines klar:

Es gibt zwei extreme Typen von Arbeit.

Extrem 1: Einfache Feature-Entwicklung

Eines meiner ersten Projekte war die Entwicklung von Software zur Steuerung von Haushaltsgeräten.

Da viele Basisfunktionen der Software bereits entwickelt waren, bestand eine meiner Aufgaben darin, diese zu erweitern. Ich fügte der bestehenden Funktionalität eine Log-Funktion hinzu, die es ermöglichte, die Software im Testbetrieb detailliert zu überwachen.

Die Integration der Log-Funktion gestaltete sich jedes Mal gleich:

• Einbindung des Aufrufs der Log-Funktion in das Feature.
• Übergabe der relevanten Variablen an dieses Feature.
• Setzen der passenden Compiler-Flags.
• Überprüfung, ob die Variablen mitgeschrieben werden.
• Abschließende Anpassung der Dokumentation des Features.
• Begutachtung meiner Arbeit durch einen Kollegen.
• Zusammenführung der Änderungen in den aktuellen Branch.

Die Erweiterung eines Features um eine Log-Funktion dauerte etwa einen Tag. Das konnte ich garantieren. Denn anders als in vielen Frameworks ist eine Log-Funktionalität in der Programmiersprache „C“ zwar nicht enthalten, aber die Implementierung ist so weit verbreitet, dass die Umsetzung in Entwicklerforen nachzulesen ist. Stieß ich dennoch auf ein Problem, konnte ich mich jederzeit an meine Kollegin wenden, die die Log-Funktionalität nicht nur entwickelt, sondern auch dutzendfach in andere Software integriert hatte.

Neben der Erweiterung von Features arbeitete ich auch an:

Extrem 2: Fehlerbehebung

Manchmal bearbeitete ich auch Tickets, die aus dem Systemtest zurückkamen.

Bevor die Software für die Nutzung durch Kunden freigegeben wurde, musste sie den Systemtest bestehen. Im Systemtest wurde die Software im echten Betrieb getestet: Nasse Wäsche wurde in die Maschinen gegeben und Programm für Programm getestet; diese Schritte wurden mehrmals wiederholt. Scheiterte der Systemtest, wurde ich mit einem Ticket darüber informiert.

Dieses Ticket konnte alles bedeuten.

Was auch immer das Problem lösen würde, konnte ich nirgends nachlesen. Da nur eine Handvoll Unternehmen weltweit in diesem Bereich produzieren, fand ich auch dazu nichts in Entwicklerforen. Und obwohl viele meiner Kollegen schon lange Software entwickelten, kannten sie die neuesten Features, die häufig das Problem verursachten, meistens noch nicht.

Auf mich allein gestellt ging ich so vor:

• Versuch, den Fehler auf meinem Rechner mit einem Prototyp nachzustellen.
• Konnte der Fehler nicht reproduziert werden, versuchte ich, den Fehler im Labor zu simulieren.
• Gelang mir das nicht, bat ich die Kollegen aus dem Dauerlauf um Hilfe, in der Hoffnung, den Fehler unter realen Bedingungen nachstellen zu können. Diese Bedingungen entsprechen dem Systemtest.
• Konnte ich den Fehler immer noch nicht finden, musste ich mich direkt an den Systemtest wenden.

Die Fehlersuche kann sehr zeitintensiv sein:

Während die Simulation am Rechner eine Sache von Stunden ist, nimmt der Test im Labor einige Tage in Anspruch. Ein erneuter Systemtest bedeutet einen Aufwand von mehreren Wochen, da viele der Systemtests im Ausland durchgeführt werden. Und das sind nur die Zeiten, um den Fehler zu finden; die Zeit zur Behebung des Fehlers kommt noch hinzu. Was und wie viel Code angepasst werden muss, konnte ich erst einschätzen, wenn der Fehler gefunden war.

Wie lange es am Ende dauerte, ließ sich niemals vorhersagen, wenn das Ticket in meinem Posteingang auftauchte.

Einsicht, welche Extreme die Softwareentwicklung annehmen kann

Ich habe diese beiden Beispiele gewählt, da sie die beiden Extreme beschreiben, die die Arbeit in der Softwareentwicklung annehmen kann.

Zusammenfassend beschreibe ich sie wie folgt:

Die Erweiterung von Features bezeichnen wir als komplizierte Arbeit.

Diese komplizierte Arbeit zeichnet sich durch folgende Punkte aus:

• Ich hatte die Expertise, um die Arbeit durchzuführen.
• Die Arbeit wurde bereits von Kollegen erfolgreich erledigt.
• Nachdem ich das Problem analysiert hatte, entwarf ich eine Lösung und setzte diese Schritt für Schritt um.
• Diese drei Punkte machten die Arbeit planbar und ich konnte gut abschätzen, wann ich fertig sein würde.

Die Fehlerbehebung würden wir hingegen als komplexe Arbeit bezeichnen.

Diese komplexe Arbeit zeichnet sich durch folgende Punkte aus:

• Ich war nicht sicher, ob meine alleinige Expertise ausreichen würde, um das Problem zu lösen.
• Ich konnte niemanden um Hilfe bitten, der mir die Lösung des Problems erklären konnte.
• Da mir viele Informationen fehlten, konnte ich das Problem nicht zerlegen und in seinen Details analysieren. Ich musste versuchen, die Situation selbst nachzustellen. Ich musste verschiedene Ansätze probieren, um mehr über die Bestandteile zu erfahren.
• Diese drei Punkte machten die Arbeit nicht planbar. Da ich nicht vorhersagen konnte, welche Überraschungen noch auf mich warteten, konnte ich nicht abschätzen, wann ich fertig sein würde.

Die meiste Arbeit, die Softwareentwickler erledigen, spielt sich wahrscheinlich irgendwo zwischen diesen Extremen ab. So liegt die Neuentwicklung eines Features etwa irgendwo zwischen der Erweiterung eines bestehenden Features und dem Aufspüren eines völlig unbekannten Fehlverhaltens der Anwendung.

Möchtest du verstehen, wo zwischen den beiden Extremen die Arbeit angesiedelt ist, hat sich eine einfache Skala bewährt.

Eine Skala zur Klassifizierung der Softwareentwicklung

Diese einfache Skala geht meines Wissens auf Liz Keogh zurück.

Du verwendest sie wie folgt: Möchtest du die Arbeit, die dein Team zu erledigen hat, klassifizieren, dann bitte dein Team, dem Eintrag im Product Backlog eine Zahl von 1 bis 5 zuzuordnen.

Hierbei bedeutet:

1. Wir alle wissen, wie man das macht.
2. Jemand in unserem Team weiß, wie es gemacht wird.
3. Jemand in unserem Unternehmen hat es bereits gemacht oder wir haben Zugang zu Fachexperten.
4. Jemand auf der Welt hat dies bereits gemacht, aber nicht in unserem Unternehmen (und wahrscheinlich bei einem Konkurrenten).
5. Wir glauben, dass niemand auf der Welt dies jemals zuvor gemacht hat.

Mein Beispiel der Weiterentwicklung eines Features entspricht einer Eins auf der Skala. Und die Behebung eines Fehlers entspricht eher einer Drei oder Vier.

Vorhersagen in der Softwareentwicklung: Wann ist das Feature fertig?

Mit dieser Skala erkennst du sofort, dass es keine pauschale Antwort auf folgende Fragen gibt:

• Wie lange dauert die Umsetzung?
• Wann ist das Feature fertig?
• Wann kann ich dem Kunden sagen, dass der Fehler behoben sein wird?
• Was ist der Zeithorizont dieses Softwareprojekts?
• Werden wir die Deadline für dieses Projekt einhalten können?

Die Antwort auf diese Fragen hängt davon ab, wie wir die Arbeit klassifizieren.

Pauschal können wir nicht sagen:

• „Softwareentwicklung lässt sich nicht schätzen. Sie ist fertig, wenn sie fertig ist.“
• „Für die Umsetzung benötigen wir 165 Tage.“
• „Das erledige ich sofort, es geht in einer Stunde live.“

In bestimmten Situationen treffen diese Antworten zu, in anderen entsprechen sie eher Wunschdenken oder Fantasie. Es hängt davon ab, welche Art von Arbeit wir meinen. Die Antwort „Das erledige ich sofort, es geht in einer Stunde live.“ ist wahrscheinlich zutreffend, wenn wir von Arbeiten der Klasse Eins sprechen. Hingegen trifft die Antwort „Softwareentwicklung lässt sich nicht schätzen. Sie ist fertig, wenn sie fertig ist.“ bei Product-Backlog-Einträgen der Klasse Vier zu.

Wenn wir die Vorhersagegenauigkeit steigern und damit das Vertrauen der Stakeholder in unser Team stärken wollen, sollten wir alle Product-Backlog-Einträge keinesfalls als gleichwertig betrachten und pauschale Aussagen darüber treffen, wann etwas fertig sein wird.

Stimmst du damit überein, findest du im Folgenden drei unterschiedliche Ansätze, die du je nach Klassifikation von Einträgen im Product Backlog verwenden kannst, um Vorhersagen zu treffen.

Unterschiedliche Arbeiten erfordern unterschiedliche Schätzmethoden

Schätzmethode 1: Absolute Schätzung

Für Einträge im Product Backlog, die die Entwickler des Scrum Teams mit „Eins“ bewerten, könnte eine absolute Zeitschätzung verwendet werden. Etwa: Für die Umsetzung dieses Eintrags benötigt Tom ungefähr 7 Stunden. Diese Arbeit entspricht meinem Beispiel für die Erweiterung eines bestehenden Features, das ich bereits mehrfach umgesetzt habe. Bei solchen Arbeiten ist es durchaus wahrscheinlich, dass die Prognose zutrifft, wann der Eintrag abgeschlossen sein wird.

Befindet sich die Arbeit eher an der Grenze zu „Jemand in unserem Team weiß, wie es gemacht wird“, dann ist es sinnvoll, die Prognose um einen Risikozuschlag zu erweitern, wie etwa geschätzte Arbeitszeit plus 25 %.

Schätzmethode 2: Relative Schätzung

Für Einträge im Product Backlog, die die Entwickler des Teams mit „Zwei“ bewerten, sollte eine relative Schätzung verwendet werden. Bei relativen Schätzungen wird nicht die absolute Zeit als Schätzung angegeben, sondern die Einträge werden in Relation zueinander gestellt und einem Referenzeintrag zugeordnet. Die Größe, in der dann geschätzt wird, ist häufig eine fiktive Größe wie Story Points, Gummibären, Same-Sizing oder T-Shirt-Größen.

Das relative Schätzen erlaubt es, den Grad an Unsicherheit und Nicht-Wissen bei Arbeiten der Klasse Zwei einzubeziehen und in der Schätzung zu kommunizieren.

Schätzmethode 3: Timeboxing

Bei Arbeiten, die die Entwickler des Scrum Teams als Klasse Drei oder höher einstufen, liefern auch relative Methoden zur Schätzung nur noch wenig verlässliche Prognosen.

Diese Arbeit zeichnet sich dadurch aus, dass nur noch wenig bekannt ist und die Expertise — falls sie existiert — nicht mehr im Team liegt. Hier sollte nicht mehr geschätzt, sondern budgetiert werden.

Budgetierung bedeutet, dass das Team eine feste Zeit bestimmt, die es investieren will, um an diesem Problem zu arbeiten. Dies mag zunächst befremdlich klingen. Wir sollten jedoch nicht vergessen, dass es keine Garantie gibt, dass Arbeit, die ein Problem der Klasse Fünf angeht, jemals zu einem lieferbaren Ergebnis führt. Es ist durchaus wahrscheinlich, dass die Zeit nur investiert wird, damit das Team lernt, dass dieser Ansatz nicht funktioniert. Und diese zeitliche Investition sollte begrenzt werden. Wir tun dies, indem wir uns eine Timebox setzen, die wir investieren wollen, um mehr über die Problemstellung zu lernen, auszuprobieren, welcher Lösungsweg funktionieren kann, oder zu erfahren, ob der Ansatz die Nutzer begeistert.

Die bekannteste Timebox ist wohl der Sprint. Er begrenzt die Arbeit, die ein Scrum Team unternimmt, auf maximal einen Monat. Spätestens nach einem Monat muss ein Scrum Team mit den Stakeholdern des Produkts zurückblicken und reflektieren, ob die Arbeit das Team einen Schritt weiter bei der Erreichung des Produkt-Ziels gebracht hat.

Bei der Schätzung von Arbeiten ab Klasse Vier kann es bedeuten, dass das Scrum Team einen Sprint investiert, um bei einer aktuellen Herausforderung Resultate zu erzielen. Diese Herausforderung kann dann in Form eines Sprint-Ziels mit den Stakeholdern geteilt werden. Im Review wird der Fortschritt bei der Erreichung dieses Ziels besprochen, und zusammen mit den Stakeholdern entscheidet der Product Owner, ob das Ergebnis ausreicht, ob noch ein weiterer Sprint investiert werden soll, oder ob sich das Team lieber einem anderen Problem widmen sollte.

Darin besteht der Sinn von Sprints: Sie beschränken das Investitionsrisiko, welches ein Unternehmen eingeht, auf einen Monat.

Natürlich muss die Investition nicht immer einen ganzen Sprint betragen. Bei Arbeiten der Klasse Drei ist dies wahrscheinlich nicht nötig. Deshalb finden wir die Idee, komplexe Arbeit zeitlich zu begrenzen, auch noch in anderen Methoden — etwa in Design Sprints, Spikes oder UX-Research-Projekten. Der Zweck dieser Methoden ist es, etwas zu lernen, dafür aber nur eine festgelegte Zeit zu investieren.

Appell: Pauschalität ist kein Werkzeug für Profis

Für Menschen, die nur einen Hammer kennen, sieht alles aus wie ein Nagel. Sie merken erst, dass es nicht funktioniert, wenn sie das Gewinde der Schraube kaputtgeklopft haben.

Einen Profi zeichnet aus, dass er für jedes Problem das richtige Werkzeug zur Hand hat. In der Softwareentwicklung bedeutet professionelles Handeln, keine pauschalen Antworten zu geben, sondern innezuhalten und die Situation einzeln zu betrachten, die richtigen Werkzeuge auszuwählen und dann eine glaubhafte Vorhersage darüber zu treffen, wann die Arbeit abgeschlossen sein kann. Profi zu sein bedeutet auch, den Mut zu haben dies zu tun, auch wenn die Antwort deinem Gegenüber zunächst nicht zusagen wird.

Bist du ein Profi? In welchen Situationen fällt es dir schwer?