Erhöhte Vorhersagbarkeit für Software-Schätzungen

In jeder Softwareentwicklungsabteilung lautet eine häufige Frage: "Ist es technisch machbar, [dies zu tun]?" Die Folgefrage lautet dann: "Und wie lange wird das dauern?"

Zuvor hatte ich darüber geschrieben, wie FloQast relative Größenangaben für Epics verwendet, um die Roadmap eines Teams zu verstehen. Leider liefert das T-Shirt-Sizing kein genaues Datum, so dass Daten im Auge des Betrachters liegen können, was zu Verwirrung führt. Und was passiert, wenn diese Daten falsch sind? Und warum sind sie dann falsch?

Eine Fahrt unternehmen

Wenn ich die Straße, in der ich wohne, hinunterfahre, dauert das etwa 1 Minute. Wenn ich von West-Los Angeles nach Ost-Los Angeles fahren würde, könnte es eine Stunde dauern. Vielleicht mehr, vielleicht weniger - es kommt darauf an.

Was wäre, wenn ich von Los Angeles nach New York fahren müsste und auf dem Weg dorthin das Auto eine Panne hätte und ich das Getriebe des Wagens wechseln müsste (Tech Debt Refactor), einen Zwischenstopp in Arizona einlegen müsste, um weitere Gegenstände in den Kofferraum des Wagens zu legen (Scope Changes), in Kansas den Fahrer wechseln müsste (Personnel Changes) und in Pennsylvania meine Freundin abholen müsste, sobald sie mit dem Essen fertig ist (Cross-Org Collaboration)?

Es würde viel länger dauern, als ich ursprünglich dachte.

Vertrauen in die Schätzung

Man kann mit Sicherheit sagen, dass die Zuversicht, dass ein Epos zu Ende gebracht wird, gegen Ende größer ist als zu Beginn. Das erinnert an eine Asymptote, nur dass die Zuversicht bis zur Fertigstellung nie den Wert 100 erreicht, sondern immer bei Null liegt.

Wenn ich mir das für ein Epos vorstelle, das etwa ein Vierteljahr dauert, könnte es etwa so aussehen:

Am ersten Tag ist das Vertrauen gleich null. Wenn wir uns dem Ende nähern, wird der Vertrauenswert (eine erfundene Kennzahl, um diesen Punkt zu veranschaulichen) immer höher.

Vorhersehbarkeit

Bei FloQast Engineering arbeiten wir unter anderem daran, unsere Vorhersagen zu verfeinern, um sie zu verbessern und die Teams berechenbarer zu machen.

Was ist Berechenbarkeit? Uns gefällt diese Definition von Simon Noone, die lautet:

"Vorhersehbarkeit bedeutet, dass man etwas liefert, wenn man es verspricht.

Die bessere Vorhersagbarkeit von Teams hat einen doppelten Nutzen: die Verantwortung für die Zeitpläne auf Teamebene und die Transparenz der anstehenden Funktionen auf Unternehmensebene.

Um einen Schritt zurückzutreten: Was sind die Ursachen für die Veränderung von Zeiteinschätzungen? In der Regel handelt es sich um eine der folgenden Ursachen:

• Änderungen des Geltungsbereichs
  • Entweder auf Produkt- oder auf technischer Ebene werden wir von etwas überrascht, das wir vorher nicht bedacht haben. Dabei kann es sich um Kundenfeedback zu einer neuen Funktion handeln, die zusätzliche Aufgaben mit sich bringt, um einen Teil des Codes, der in schlechtem Zustand war, oder um etwas anderes.
• Team Gesundheit
  • Probleme mit Menschen, Prozessen oder Technik. Dabei kann es sich um ein Teammitglied handeln, das nicht mehr im Team ist, um eine Verlangsamung in unserer Warteschlange, um ein Problem mit gemeinsamen Abhängigkeiten oder um etwas anderes.

Auf der Grundlage dieses Wissens war es sinnvoll, einen Weg zu finden, dieses Wissen in iterative Feedbackschleifen über das Team für sich selbst und für die Stakeholder einzubringen.

Team-Gesundheitschecks

Ein Team Health Check ist ein Selbstbewertungsinstrument, das Teams in ihren agilen Zeremonien einsetzen können, um ein Gefühl dafür zu bekommen, wie sich die Arbeit entwickelt. Während sich ein Retro auf das konzentriert, was gut gelaufen ist und was verbessert werden kann, konzentriert sich ein Team Health Check eher auf bestimmte Aspekte und fordert das Team auf, sich selbst in diesen Aspekten zu betrachten. Stellen Sie sich vor, Sie gehen zum Arzt und lassen Gewicht, Blutdruck und Temperatur messen. Wenn man Fieber hat, ist das ein Hinweis darauf, dass man sich etwas ansehen sollte.

Atlassian bietet eine Vorlage für den Team-Gesundheitscheck an, die einige großartige Achsen enthält, um eine Momentaufnahme eines bestimmten Projekts zu erstellen. Wenn eines der zu lösenden Probleme darin besteht, das Warum eines Projekts in Momentaufnahmen zu verstehen, dann war diese Vorlage das richtige Werkzeug für das Problem, das wir zu lösen suchten.

So wie wir Redux für den Zustand unseres Frontends verwenden, erfassen Team Health Checks den Zustand unserer Teams während Epics.

Asymptotische Schätzung

Anhand der Team-Gesundheitsprüfungen, die eine Momentaufnahme darstellen, schichten wir inkrementelle Zeitschätzungen auf Teamebene ein. Um die vorherige Grafik zu verwenden:

• Prüfpunkt 1 - Produkt- und Technikentdeckung
  • Gesundheitscheck und Einschätzung des Teams
• Prüfpunkt 2 - Technisches Anforderungsdokument
  • Gesundheitscheck und Einschätzung des Teams
• Kontrollpunkt 3 - ~50% abgeschlossen
  • Gesundheitscheck und Einschätzung des Teams
• Kontrollpunkt 4 - ~75% abgeschlossen
  • Gesundheitscheck und Einschätzung des Teams
• Kontrollpunkt 5 - ~90% abgeschlossen
  • Gesundheitscheck und Einschätzung des Teams
• Kontrollpunkt 6 - ~95% abgeschlossen
  • Gesundheitscheck und Einschätzung des Teams

In jedem Intervall gibt das Team eine Einschätzung ab, wann das Epos seiner Meinung nach fertig sein wird. Bei den Checkpoints 1-3 kann es sich um die Schätzung von Monaten handeln, bei den Checkpoints 4-5 um die Schätzung von Wochen und zum Schluss um die Schätzung von Tagen. Wenn z. B. eine neue Funktion veröffentlicht werden soll und gleichzeitig ein Marketingschub ansteht, können die Informationen aus den Checkpoints 4-6 hilfreich sein, um den Zeitplan für die Veröffentlichung im Auge zu behalten.

Außerdem entscheidet das Team an jedem Kontrollpunkt über einen roten oder gelben Bereich, den es iterativ verbessern und zu einem grünen Bereich machen will.

Schätzungen mit Kontext

Am Ende des Epos sollten wir ein vollständig ausgefülltes Diagramm haben, das ähnlich wie das folgende aussieht, und die Schätzungen, die das Team zu diesem Zeitpunkt abgegeben hat.

Was passiert, wenn ein Epos einfach nicht so groß ist und nicht diesen Aufwand für etwas benötigt, das vielleicht ein paar Wochen dauert? Dann ist das toll! Das könnte zu viel Aufwand für den Nutzen sein. Aber bei größeren Projekten sollte dies allen Beteiligten eine iterative Feedbackschleife und ein retrospektives Dokument ermöglichen, bevor das nächste Projekt in Angriff genommen wird.

Messung der Vorhersagbarkeit

Wenn Vorhersagbarkeit bedeutet, dass man etwas zu dem Zeitpunkt liefert, zu dem man es verspricht, wie könnten wir das dann messen? Die Art und Weise, wie wir dies derzeit betrachten, ist - wie oft ändert ein Team sein Enddatum für ein Epos? Aber es gibt einen Vorbehalt: Wenn sich die Schätzung bei Checkpoint 6 von Mittwoch auf Donnerstag um 13 Uhr ändert, ist das eine gute Sache. Das ist sogar ein noch genaueres Timing. Wenn die Schätzung von nächsten Mittwoch bis nächstes Jahr geht - nicht so toll.

Was wir also wirklich suchen, ist: Wie oft ändert ein Team sein episches Enddatum? um x

Das heißt, es geht nicht nur darum, dass sich das Datum geändert hat - sondern darum, dass sich das Datum um eine Standardabweichung mehr oder weniger als zuvor geändert hat.

Da wir mit diesem Prozess gerade erst experimentieren, werden wir für jedes Team eine Standardabweichung ermitteln, indem wir eine Basislinie über 3 Epen erstellen. Sobald wir diesen Ausgangswert haben, können wir mit der iterativen Verbesserung fortfahren.

Das Warum mit dem Wann

Die richtige Schätzung eines großen Epos ist eine Herausforderung. Durch das Hinzufügen von Team-Gesundheitsprüfungen wollen wir zusätzlich zum "Wann" von epischen Zeitplänen auch das "Warum" berücksichtigen, um unsere Teams mit der Zeit berechenbarer zu machen.

Vinoj Zacharia

Vinoj Zacharia ist ein Entwickler, der sich in eine technische Führungspersönlichkeit verwandelt hat, die mit Einfühlungsvermögen datengesteuerte, befähigte und kollaborative Teams von Grund auf aufbaut. Er ist Director of Engineering bei FloQast.