Projektmanagement Telemetrie für agile Software-Teams

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Agile Softwareentwicklung verspricht häufig eine Effizienzsteigerung und kürzere als auch schnellere Entwicklungszyklen. Aber woran lässt sich das messen? An welchen Metriken lässt sich festhalten, dass ein agiles Team auch wirklich flüssig und effizient arbeitet?

Telemetrie ist im Rennsport unerlässlich. Ferraris Elektronikchef Andrea Beneventi sagt: „Keine andere Form des Motorsports nutzt Telemetrie so effizient wie in der Formel Eins“. Drehmoment, Kupplungsverhalten, Richtungskräfte, Vibration, Reifenverschleiß. Über 150 Sensoren messen mit einer Frequenz von über 100 mal pro Sekunde. In ähnlicher Weise verwenden NFL-Teams RFID-Tags, um ihre Teams zu optimieren, indem sie in Echtzeit die Geschwindigkeit und Beschleunigung für jeden Spieler, bei jedem Spiel und auf jedem Zentimeter des Feldes messen.

Wie sieht es aber dazu in Vergleich mit der Softwareentwicklung aus? Wie gut verstehen und optimieren wir unsere agilen Prozesse? Was messen wir und welche Einblicke haben wir in unsere Entwicklungskapazitäten? Sehen wir, wo unsere Engpässe sind und wie wir dieses beheben können?

Oftmals ist die Telemetrie in der Softwareentwicklung nicht vorhanden oder sehr rudimentär. Wir arbeiten entweder aus Bauchgefühl heraus oder mit vereinfachten KPIs wie der Anzahl der gelösten Tickets, der Zahl der erstellten Codezeilen oder der Anzahl der bestandenen Tests. Dieses gibt uns aber wenig Einblick in den eigentlichen Entwicklungsmotor und wie flüssig Teams arbeiten.

Das ist, als würde man einen Rennwagen fahren und nur Rundenzeiten messen: „Nun, das letzte Mal war unsere Rundenzeit 2:43 Minuten, mal sehen, ob wir nicht darunter kommen können.“ Aber in Wirklichkeit verstehen wir die Leistung des Motors nicht, ob das Getriebe reibungslos schaltet, oder ob es gewisse Materialermüdungen gibt. Wir wissen noch nicht einmal sicher, ob wir in einen Ferrari oder einem Fiesta unterwegs sind.

Infolgedessen gibt es viel Druck, Frustration und manchmal unerklärliche schlechte Leistung, wenn unsere Erwartungen und die Realität nicht übereinstimmen. Was uns fehlt, ist der Einblick in den Motor: Laufen die Prozesse reibungslos ablaufen, sind die Teams frei von Blockern, oder sind einzelne Teammitglieder überlastet? Gerade aus dem Home Office bekommen wir diese Signale oft nicht direkt mit, und es ist wichtig, hier in Echtzeit einen besseren Einblick zu bekommen.

Telemetrie und Metriken

Die Softwareentwicklung erzeugt große Datenmengen. Gerade agile und DevOps Prozesse ermöglichen uns, mit jedem Code-Commit und jedem Schritt durch den Software-Lebenszyklus hilfreiche Daten zu erfassen. Zum Beispiel, jede Codeänderung (Pull Request) erzählt eine Geschichte darüber, was sich geändert hat, wo sich etwas geändert hat, wie lange die Änderung gedauert hat und wer in welchem Schritt involviert war. Die Metadaten der Pull Requests beinhalten Details, ob dieser Pull Request reviewed wurde, wer daran beteiligt war und wie viele Iterationen es dauerte, bis dieser genehmigt und gemerged wurde. Darüber hinaus bekommen wir leicht zusätzliche DevOps Informationen: die Dauer und der Erfolg eines Builds, Details zur Testabdeckung und die Resolutionszeiten von Feature- oder Bugtickets.

Der DevOps-Prozess ist unser Produktionsmotor. Wenn dieser Produktionsmotor stottert, führt das zu langsameren Entwicklungen, Desorganisation und Frustration des gesamten Teams.

Ein Metrik Beispiel ist die Zykluszeit von einem Feature Anfang bis zum Release. Es ist bekannt, dass sehr gut laufende agile Team oft Zykluszeiten von weniger als 24h haben. Dieses bedeutet, dass es weniger als 24 Stunden dauert, um ein Stück Code zu schreiben, ihn zu reviewen und im Produkt auszuliefern.

Bild 1 zeigt die gemessenen Zykluszeiten bei einem agilen Team. über die letzten Wochen, Darüber hinaus sieht man, welchen Stufen besonders lange gedauert haben. Dieses kontinuierlich auf Teamebene oder Produktebene zu messen, hat sich als sehr hilfreich erwiesen, um einen besseren Einblick in Reibungen in der Entwicklungsgeschwindigkeit aufzudecken.

Eine bekannte Gefahr ist es jedoch, sich zu sehr auf eine einzelne Metrik zu fokussieren. Geschwindigkeit ist gut, aber nicht alles. Ein häufiges Problem ist, dass die 24-Stunden-Zyklen als der heilige Gral angesehen werden. Im Gegenzug wird oft der Prozess vernachlässigt, Reviews werden nicht mit Sorgfalt gemacht oder Teammitglieder werden überlastet.

Es ist daher wichtig, verschiedene Aspekte zu messen, um einen informierten Überblick zu haben. Einige Kernmetriken neben den Zykluszeiten sind dabei:

• Prozentsatz der unreviewten PRs/Tickets (Qualität),

• Typische Kapazitätsgrenzen des Teams (Durchsatz),

• Maximal Last von einzelnen Teammitgliedern (Team Health), und

• Verzögerungen die sich aus unterschiedlichen Gründen angesammelt haben (Risiken).

Ein Beispiel für Prozessverletzungen ist in Bild 2 dargestellt. Man sieht in dem lilafarbenen Fluss, dass nur ein geringer Anteil des Codes reviewed wurde. Der meiste Code wurde direkt gemerged. Hier ist es wichtig herauszufinden, warum das der Fall ist. Sind die Teammitglieder überlastet? Gibt es keine klaren Richtlinien? Wie sieht das im Vergleich zum Rest des Unternehmens aus?

Als technische Leiter haben wir oft eine Vorstellung davon, was vor sich geht, aber meistens nicht die datengestützten Einsichten, um die richtigen Entscheidungen zu treffen. Wichtig ist es, Teams im Rhythmus und Fluss zu behalten, auf Abweichungen aufmerksam zu werden, und nur dort steuernd einzugreifen, wo ist wirklich notwendig ist.

Datengestütztes Softwaremanagement

Das datengestützte Softwaremanagement ist eine entstehende Kategorie, die die oben beschrieben DevOps Daten automatisch abgreift und technischen Leitern hilft, verteilte Teams effizient auch aus dem Home Office zu führen. Die Daten werden dabei in Analyseplattformen zusammengeführt, die Dashboards und Drill-Downs zu Evidenzen bereitstellen.

Technisch sammelt das datengestützte Softwaremanagement die Telemetriedaten automatisch durch Konnektoren, die sich mit der vorhandenen Infrastruktur verbinden. Beispiele hierfür sind die Quellcode-Repositories, das Ticketsystem, und die Build- und Delivery-Pipeline. Der Vorteil der integrierten Konnektoren ist, dass sie den Entwicklungsfluss nicht unterbrechen und niemand zeitaufwändige Berichte manuell erstellen muss.

Ein Beispiel einer solchen Plattform ist Logilica Insights wie in Bild 3 dargestellt. Basierend auf Big-Data-Prinzipien und proprietären Deep-Analytics-Lernprozessen erfasst und verschmelzt Logilica verschieden Datenquellen. Die gewonnen Einsichten werden in einem intuitiven Interface bereitgestellt, das technischen Führungskräften ein 360-Grad-Überblick in die Entwicklung gibt.

Die aus dieser Telemetrie gewonnenen Erkenntnisse können dann mit dem gesamten Team geteilt werden und in den Retrospektiven für den nächsten Zyklus zur Planung verwendet werden.

Fazit: Bessere Einsichten, besseres Management

Je mehr Einsichten wir über die Zeit erlangen, desto besser können wir Teams leiten und uns auf das Wesentlich fokussieren. Es geht hier nicht darum, individuelle Metriken oder Teammietglieder zu optimieren, sondern den Fluss und die Entwicklung ganzheitlich im Überblick zu behalten. Gerade die ganzheitliche Ansicht ergibt einen deutlichen Mehrwert. Kosten können auf Prozesseben gesenkt werden, und Teamprobleme können leichter identifiziert und abgestellt werden.

Erfolge stellen sich schnell ein, wenn man übergreifend Zykluszeiten und deren Engpässe im Auge behält, die Kapazitätsgrenzen kennt, und Standards für die Review-Prozesse beachtet.

Indem wir diese Signale im Auge behalten, lassen sich Fristen besser vorhersagen, Unzufriedenheiten im Team reduzieren und Projektüberschreitungen vermeiden.

Investitionen in diesem Bereich zahlen sich schnell zahlt sich aus, da bestehende Historien gleich beim Onboarden analysiert werden und sich die ersten Erkenntnisse am Tag Eins einstellen. Längerfristig bedeutet das weniger schlaflose Nächte für Entwicklungsleiter und mehr Vertrauen in die eigenen Teamfähigkeiten zum erfolgreichen Durchführen neuer Projekte.

Dieser Artikel stammt ursprünglich von unserem Partnerportal Embedded-Software-Engineering.de.

* Ralf Huuck ist Gründer und CEO von Logilica.

(ID:48083421)