Erhöhung der Vorhersagbarkeit von Softwareschätzungen

In jeder Abteilung für Softwareentwicklung wird eine häufig gestellte Frage lauten: „Ist es technisch machbar, [diese Sache zu tun]?“ Die Folgefrage lautet dann: „Nun, wie lange wird das dauern?“ Zuvor hatte ich darüber geschrieben, wie FloQast verwendet relative Größen für Epics um die Roadmap eines Teams zu verstehen. Leider liefert die T-Shirt-Größe kein genaues Datum, sodass Daten im Auge des Betrachters liegen können, was zu Verwirrung führen kann. Was passiert dann, wenn diese Daten falsch sind? Und warum sind sie falsch gelaufen?

Eine Fahrt machen

Wenn ich die Straße entlang fahren würde, in der ich wohne, würde es ungefähr 1 Minute dauern. Wenn ich von West Los Angeles nach East 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 unterwegs das Auto eine Panne hat und ich das Getriebe des Autos wechseln müsste (Tech Debt Refactor), einen Stopp in Arizona einlegen, um mehr Gegenstände in den Kofferraum des Autos zu legen (Änderungen am Umfang), zu einem anderen Fahrer in Kansas wechseln (Personalwechsel) und meine Freundin abholen müsste, sobald sie ihr Abendessen in Pennsylvania beendet hat (cross-org Zusammenarbeit)?

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

Schätzung, Vertrauen

Man kann mit Sicherheit sagen, dass die Zuversicht, ob ein Epos abgeschlossen wird, gegen Ende höher ist als zu Beginn. Es ist erinnert an eine Asymptote; aber anstatt nie Null zu erreichen, Das Selbstvertrauen erreicht nie 100, bis es abgeschlossen ist. Wenn ich mir das für ein Epos vorstellen würde, das etwa ein Viertel dauert, könnte es ungefähr so aussehen:

Am ersten Tag ist das Vertrauen Null. Wenn wir uns dem Ende nähern, wird der Konfidenzwert (eine erfundene Metrik zur Veranschaulichung dieses Punktes) immer höher.

Berechenbarkeit

Eines der Dinge, an denen wir in FloQast Engineering arbeiten, ist herauszufinden, wie wir unsere Vorhersagen verfeinern können, um sie zu verbessern und Teams vorhersehbarer zu machen. Was ist Vorhersagbarkeit? Wir wie diese Definition von Simon Noone, das ist:„Berechenbarkeit bedeutet, etwas zu liefern, wenn Sie sagen, dass Sie es tun werden.“Teams haben zwei Vorteile, wenn sie besser vorhersagbar sind: Die Verantwortung für Zeitpläne auf Teamebene und Einblick in zukünftige Funktionen auf Unternehmensebene. Aber um einen Schritt zurückzugehen, was bewirkt, dass sich die Zeitschätzungen ändern? Normalerweise fällt es in eine der folgenden Kategorien:

• Änderungen des Umfangs
  • Entweder auf Produkt- oder Konstruktionsebene sind wir am Ende mit etwas überrascht, das wir zuvor nicht berücksichtigt haben. Das kann Kundenfeedback zu einer neuen Funktion sein, die noch mehr zu tun hat, ein Teil des Codes, der in einem schlechten Zustand war, oder etwas anderes.
• Gesundheit des Teams
  • Probleme mit Menschen, Prozessen oder Technologie. Das kann ein Teammitglied sein, das nicht mehr im Team ist, eine Verlangsamung in unserer Release-Warteschlange, ein gemeinsames Abhängigkeitsproblem oder etwas anderes.

Auf der Grundlage dieses Wissens war es sinnvoll, einen Weg zu finden, dies in iterativen Feedback-Schleifen über das Team für sich selbst und für die Stakeholder anzuwenden.

Gesundheitschecks für Teams

Ein Team-Gesundheitscheck ist ein Tool zur Selbsteinschätzung, das Teams im Rahmen ihrer Agile-Zeremonien durchführen können, um ein Gefühl dafür zu bekommen, wie sich die Arbeit entwickelt. Während sich ein Retro-Test darauf konzentriert, was gut gelaufen ist und was verbessert werden kann, konzentriert sich ein Team-Gesundheitscheck mehr auf bestimmte Aspekte und fordert das Team auf, sich selbst in diesen Facetten zu betrachten. Stellen Sie sich vor, Sie gehen zum Arzt, wo Gewicht, Blutdruck und Temperatur überprüft werden. Wenn es Fieber gibt, ist das ein Indikator dafür, dass etwas untersucht werden muss.Atlassian stellt eine Vorlage für Team-Gesundheitschecks zur Verfügung das hat einige großartige Achsen, um einen Überblick über die Zeit eines bestimmten Projekts zu machen. Wenn eines der zu lösenden Probleme darin besteht, das Warum eines Projekts anhand von Schnappschüssen zu verstehen, fühlte sich diese Vorlage wie das richtige Tool für das Problem an, das wir lösen wollten. Genau wie wir verwenden Redux für den Zustand unseres Frontends, Team-Gesundheitschecks erfassen den Zustand unserer Teams bei Epen.

Asymptotische Schätzung

Wir verwenden die Team-Gesundheitschecks als Momentaufnahme und fügen inkrementelle Zeitschätzungen auf Teamebene hinzu. Um die vorherige Grafik zu verwenden:

• Prüfpunkt 1 — Produkt- und Technikforschung
  • Gesundheitscheck und Schätzung des Teamzustands
• Prüfpunkt 2 — Dokument mit technischen Anforderungen
  • Gesundheitscheck und Schätzung des Teamzustands
• Checkpoint 3 — ~ 50% abgeschlossen
  • Gesundheitscheck und Schätzung des Teamzustands
• Checkpoint 4 — ~ 75% abgeschlossen
  • Gesundheitscheck und Schätzung des Teamzustands
• Checkpoint 5 — ~ 90% abgeschlossen
  • Gesundheitscheck und Schätzung des Teamzustands
• Checkpoint 6 — ~ 95% abgeschlossen
  • Gesundheitscheck und Schätzung des Teamzustands

In jeder Pause gibt das Team einen Bauchcheck ab, wann das Epos seiner Meinung nach abgeschlossen sein wird. In den Checkpoints 1—3 kann es in der Schätzung für die Monate sein, in den Checkpoints 4—5 kann es in der Schätzung für die Wochen und am Ende in der Schätzung für die Tage sein. Wenn beispielsweise während der Veröffentlichung einer neuen Funktion ein Marketing-Push erforderlich ist, können Informationen aus den Checkpoints 4-6 hilfreich sein, um den Überblick über die Veröffentlichungszeiten zu behalten. Außerdem entscheidet das Team an jedem Checkpoint, welcher Bereich rot oder gelb ist, um sich iterativ zu verbessern und in Richtung Grün zu bewegen.

Schätzungen mit Kontext

Am Ende des Epos sollten wir eine vollständig ausgefüllte Tabelle haben, die der folgenden ähnelt, und die Schätzungen, die das Team zu diesem Zeitpunkt abgegeben hat.

Was passiert, wenn ein Epos einfach nicht so groß ist und diesen Overhead nicht für etwas benötigt, das ein paar Wochen dauern kann? Dann großartig! Dies kann zu viel kosten für den Vorteil. Aber wenn wir größere Epen haben, sollte das allen Beteiligten eine iterative Feedback-Schleife und ein rückblickendes Dokument geben, bevor mit dem nächsten Epos begonnen wird.

Messung der Vorhersagbarkeit

Wenn Berechenbarkeit etwas bringt, wenn Sie sagen, dass Sie es tun werden, wie können wir das messen? Wir schauen uns das derzeit so an: Wie oft ändert ein Team sein Enddatum für ein Epic? Aber es gibt einen Vorbehalt: Wenn am Checkpoint 6 die Schätzung vom nächsten Mittwoch auf Donnerstag um 13 Uhr geht, ist das eine gute Sache. Es ist tatsächlich ein noch genaueres Timing. Wenn die Schätzung vom nächsten Mittwoch auf nächstes Jahr - nicht so toll.

Wir schauen uns also wirklich an, wie oft ein Team sein episches Enddatum ändert von xDas heißt, es ist nicht nur so, dass sich das Datum geändert hat - sondern es ist so, dass sich das Datum geändert hat um eine gewisse Standardabweichung mehr oder weniger als zuvor. Da wir gerade mit diesem Prozess experimentieren, berechnen wir eine Standardabweichung für jedes Team, indem wir eine Basislinie über 3 Epen erstellen. Sobald wir diese Ausgangsbasis haben, können wir uns iterativ weiter verbessern.

Das Warum mit dem Wann

Die richtigen Schätzungen für ein großes Epos zu treffen, ist eine Herausforderung. Indem wir Team-Gesundheitschecks in den Mix aufnehmen, wollen wir bei epischen Zeitlinien neben dem „Warum“ auch das „Warum“ hinzufügen, um unsere Teams im Laufe der Zeit berechenbarer zu machen.