Vorlaufzeit: Schnellere Bereitstellung von Software für Kunden

Was ist Vorlaufzeit?

Bei FloQast definieren wir die Vorlaufzeit als die Gesamtzeit, die ein Ticket von „In Bearbeitung“ bis „Erledigt“ verbringt. Anders ausgedrückt: „Sobald wir in einem Sprint mit der Arbeit an einem Ticket beginnen, wie lange brauchen wir, um diese Änderungen in der Produktion umzusetzen und einem Kunden einen tatsächlichen Mehrwert zu bieten?“

Wie verfolgen wir die Vorlaufzeit?

Wir verfolgen unsere Vorlaufzeit in verschiedenen Intervallen — 14 Tage, 30 Tage und drei Monate — in einem Google-Sheet wie folgt:

All diese Daten werden über den „Control Chart“ -Bericht aus Jira abgerufen. Wir verwenden einen Schnellfilter für die „Vorlaufzeit“, um sicherzustellen, dass wir die Vorlaufzeit nur für die entsprechenden Tickets verfolgen. So schließen wir beispielsweise alle SPIKE-Tickets von der Vorlaufzeit aus oder andere Aufgabentickets, die nicht dazu führen, dass Anwendungscode in der Produktion bereitgestellt wird.

Warum ist uns das wichtig?

In Ordnung, wir wissen also, welche Vorlaufzeit ist und wie kann man es verfolgen, aber was soll's? Wie bei den meisten Initiativen in der Softwareentwicklung gewinnen sie nicht an Bedeutung, wenn die verantwortlichen Parteien nicht verstehen warum sie machen was sie sind. Nun, schauen wir uns ein paar gute Gründe an, warum die Vorlaufzeit wichtig ist.

Eine geringe Vorlaufzeit ermöglicht uns:

Schnelle Behebung von Fehlern mit hoher Priorität

• Wenn unser Entwicklungs- und Release-Prozess frei von Engpässen ist, werden wir in der Lage sein, Fehler schnell zu beheben und die Kunden zufrieden zu stellen.

Praktizieren Sie Continuous Delivery und pflegen Sie eine enge Feedback-Schleife mit Ihren Kunden

• Der volle Nutzen von Continuous Delivery würde den Rahmen dieses Beitrags sprengen, aber einfach ausgedrückt, dies ermöglicht es uns, wendig in Bezug auf unsere Roadmap. Wenn wir den Code schneller versenden können, können wir schneller Kundenfeedback erhalten und daher bei Bedarf Mikrokorrekturen in der Roadmap vornehmen.

Seien Sie ein leistungsstarkes Softwareunternehmen

• Recherche aus dem Buch Accelerate zeigt, dass leistungsstarke Softwareunternehmen eine geringe Vorlaufzeit haben.

Hinweis: Die Definition der Vorlaufzeit in dieser Grafik ist „Zeit von der Codeübergabe bis zur Bereitstellung“, was unsere Definition bei FloQast umfasst.

Das Verhalten von Teams ändern

Das Streben nach einer kurzen Vorlaufzeit fördert auch andere wertvolle Verhaltensweisen in unseren Teams, wie zum Beispiel:

Betonung kleiner Chargengrößen

Es ist sinnvoll, dass Releases mit kleinerem Umfang mit einer geringen Vorlaufzeit einhergehen. Sie lassen sich einfacher und schneller entwickeln und testen. Die Konzentration auf kleine Chargengrößen an sich ist aus einer Reihe von Gründen hilfreich:

• Kleinerer Umfang = geringeres Regressionsrisiko pro Version (auch bekannt als niedrige „Change Failure Rate“ in der obigen Grafik)
• Wenn ein Fehler auftritt, ist es viel einfacher, das Problem in einer PR mit 5 Dateien aufzuspüren als in einer Änderung mit 50 Dateien in 4 Repos
• Auch hier gilt: Wenn ein Defekt auftaucht, wird weniger Code für den Versand gesperrt, als wenn er Teil einer großen PR/Veröffentlichung wäre.Stellen Sie sich vor, wir haben zwei Funktionen, die wir gerne veröffentlichen würden, Feature A und Feature B, und nehmen wir an, wir beschließen, beide Funktionen in einem einzigen Ticket in Angriff zu nehmen. Nehmen wir nun an, dass Feature A voller Bugs ist, Feature B aber einwandfrei funktioniert. In jeder Phase der Entwicklung (im Gange, Code-Review, QE-Testing usw.) verzögern wir jedes Mal, wenn wir ein Problem mit Feature A finden, auch die Veröffentlichung von Feature B! Hätten wir diese in kleinere Chargen aufgeteilt und parallel entwickelt, hätte Feature B ausgeliefert und einen Mehrwert bieten können, während wir Probleme mit Feature A gelöst haben.

Berechenbarkeit

Im Allgemeinen kann eine Gruppe von fünf 1-Punkte-Tickets weitaus vorhersehbarer geliefert werden als ein einzelnes 5-Punkte-Ticket. Dies ist ein weiterer positiver Nebeneffekt kleiner Chargengrößen. Parallel kann mehr Arbeit geleistet werden, sodass die Entwicklung Die Anzahl der Funktionen nimmt von Anfang bis Ende weniger Zeit in Anspruch.

Kritisches Denken über unseren Prozess

Bei FloQast wird von unseren Ingenieuren erwartet, dass sie über den Code hinaus denken. Während der Engineer Manager für den Prozess verantwortlich ist, ist das gesamte Team (einschließlich des EM) an der Verbesserung unseres Prozesses beteiligt. Wenn wir ständig darüber nachdenken, wie wir eine niedrige Vorlaufzeit erreichen können, werden wir auch unseren Prozess kontinuierlich verbessern.

Schwarmmentalität

Warte... Was ist das?„Schwarmen“ und all seine Vorteile zu erklären, würde den Rahmen dieses Beitrags sprengen — und wenn Sie ein Entwickler sind, weiß ich, dass Sie ein Experte im Googeln sind — aber kurz gesagt, dies ist ein Merkmal leistungsstarker agiler Softwareteams, bei denen sie konsequent zusammenarbeiten, um ein gemeinsames Ziel zu erreichen (z. B. das Sprintziel). Wenn ein Entwickler beispielsweise mitten im Sprint Zeit hat, anstatt immer „das nächste Ticket“ abzuholen, fragt er sich stattdessen: „Was ist das Beste, was ich jetzt tun kann, um uns unserem Ziel zu nähern?“Okay, das ist toll, aber was hat das nochmal mit der Vorlaufzeit zu tun?Wenn sich ein Team darauf konzentriert, die Vorlaufzeit niedrig zu halten, sind Entwickler eher geneigt, bei laufenden Arbeiten zu helfen, bevor sie neue Arbeiten in Angriff nehmen; das ist quasi ein Schwarm! In meinen Teams bei FloQast haben wir ein sehr einfaches Framework für unsere Sprint-Prioritäten entwickelt, das den Schwerpunkt auf dem Sprint-Board darauf legt, „von rechts nach links zu gehen“, was bedeutet, dass wir das Schieben von Tickets über die Ziellinie priorisieren, die bereits am nächsten an „erledigt“ sind. Prioritäten sehen so aus:

• Arbeiten Sie bei Bedarf mit QE zusammen, um Tickets bis zur Produktion weiterzuleiten. Dies könnte bedeuten, dass die Anforderungen geklärt und/oder die Szenarien für das Ticket getestet werden
• Überprüfung des Codes
• Wir schauen bei Teamkollegen vorbei, ob sie Hilfe bei Tickets für „In Bearbeitung“ gebrauchen könnenDas könnte ihnen helfen, etwas zu debuggen, Programme zu koppeln oder eine Gelegenheit zur parallelen Entwicklung dieses Tickets zu finden, das wir während des Groomings verpasst haben.
• Beginne mit der Arbeit an einem neuen Ticket von TODO

Wie Sie sehen können, holen Sie sich ein neues Ticket ist der letzte auf dieser Liste. Der Rahmen ermutigt Teamziele wichtiger als individuelle Leistung, durch Schwärmen.

Abschließende Gedanken

Falls Sie es noch nicht bemerkt haben, viele dieser Konzepte — geringe Vorlaufzeiten, kleine Chargengrößen, kontinuierliche Lieferung, Vorhersagbarkeit, Schwarmbildung usw. — sind wunderbar miteinander verknüpft, und jeder ermutigt den anderen; ich glaube, wenn man sich auf einen von ihnen konzentriert, konzentriert man sich effektiv auf alle. Bei FloQast erkennen und begrüßen wir jeden Einzelnen, aber wir orientieren uns in erster Linie an der Vorlaufzeit als Kennzahl für den Zustand unserer technischen Abteilung. Viel Glück an alle Softwareteams da draußen und möge Ihre Vorlaufzeit immer kurz sein!