„Lassen Sie uns ein Zykluszeit-Diagramm erstellen" wird schnell zu einem kleinen Projekt für sich. Azure DevOps zeichnet ein solches nicht von Haus aus, sodass der übliche nächste Schritt darin besteht, Power BI mit dem Analytics-OData-Feed oder einer Analytics-Ansicht zu verbinden, einen Bericht zu erstellen und einen Ort zum Hosten und Teilen zu finden: zuzüglich eines Power-BI-Pro-Platzes für alle, die ihn öffnen müssen. Das ist ein durchaus guter Weg, wenn Sie Power BI bereits für anderes Reporting nutzen oder Azure-DevOps-Daten mit Zahlen aus einer anderen Quelle kombinieren müssen. Das ist jedoch viel Aufwand, wenn Sie eigentlich nur sehen wollten, wie lange die Arbeit Ihres Teams dauert.
Was ein Zykluszeit-Diagramm wirklich braucht
Auf das Wesentliche reduziert, braucht eine nützliche Zykluszeit-Ansicht vier Dinge: einen Start- und Endzeitstempel für jedes Element, basierend auf der eigenen Workflow-Stufenzuordnung Ihres Teams (nicht auf einer allgemeinen Vermutung darüber, was „in Bearbeitung" bedeutet); eine Aufteilung nach Arbeitstyp, denn ein Bug und ein mehrwöchiges Feature gehören nicht in dieselbe Zeile; ein Gespür für die Streuung, nicht nur einen Durchschnitt: einen Median und ein höheres Perzentil, damit ein einzelnes sehr langsames Element die Kennzahl nicht unbemerkt verzerrt; und eine Möglichkeit zu erkennen, ob die Zahl bei kleiner Stichprobe noch ehrlich ist. Nichts davon erfordert ein allgemeines BI-Tool. Es erfordert, den Arbeitselement-Verlauf zu lesen, den Azure DevOps bereits hat, und dieselbe Berechnung konsistent bei jedem Öffnen der Ansicht durchzuführen.
Die Zykluszeit-Ansicht
Genau das leistet die Zykluszeit-Ansicht von Agile Gauge: ein Punkt pro geliefertem Element über die letzten sechs Sprints, aufgeteilt in geplante Arbeit, Bugs und Exploration, mit Referenzlinien für Median und 85. Perzentil. Wenn ein Bucket nicht genügend gelieferte Elemente enthält, um diese Linien aussagekräftig zu machen, werden sie gar nicht erst gezeichnet, statt sie stillschweigend aus drei Datenpunkten hochzurechnen und so darzustellen, als hätten sie Aussagekraft.
Jeder Punkt ist ein echtes Arbeitselement
Ein Streudiagramm, das die Frage „welches Element war das?" nicht beantworten kann, nützt in einem echten Gespräch wenig. Klicken Sie auf einen beliebigen Punkt, eine Zeile in der Tabelle neben dem Diagramm oder eine der Perzentillinien, und ein gemeinsames Element-Panel öffnet sich, das genau zeigt, welche Arbeitselemente dahinterstehen: einschließlich des tatsächlichen Wegs jedes Elements durch die zugeordneten Stufen Ihres Teams: wo es lag und wie lange. Die Tabelle neben dem Diagramm existiert aus demselben Grund: Ein Streudiagramm lässt sich allein per Tastatur nicht zugänglich navigieren, daher ist die Tabelle keine Höflichkeit, sondern die Antwort auf dieselbe Frage, die das Diagramm stellt.
Warum Median und 85. Perzentil statt eines einzelnen Durchschnitts
Ein einzelner Durchschnittswert der Zykluszeit verdeckt genau das, was am meisten zählt: wie konsistent das Team tatsächlich arbeitet. Zwei Teams können denselben Durchschnitt aufweisen und sich dennoch in völlig unterschiedlichen Situationen befinden: das eine liefert fast alles in einer engen Bandbreite, das andere liefert die meisten Elemente schnell und zieht eine Handvoll über Wochen hinweg in die Länge. Der Median zeigt, wie ein typisches Element aussieht; das 85. Perzentil zeigt, worauf Sie sich bei den nicht reibungslos verlaufenden Elementen einstellen sollten. Keine der beiden Linien wird gezeichnet, solange nicht genügend gelieferte Arbeit in diesem Bucket vorliegt: ein Team mit drei in diesem Zeitraum gelieferten Bugs sieht die Punkte und die Tabelle, aber keine aus drei Punkten erfundene Perzentillinie, die als stabile Messung dargestellt wird.
Den Sprint lesen, nicht nur die Punkte
Über dem Diagramm zeigt eine Lesezeile dieselben Werte mit ihren Deltas gegenüber dem vorherigen Zeitraum, dazu eine Vertrauenslinie, die offen benennt, wie sehr den aktuellen Zahlen angesichts der zugrunde liegenden Stichprobengröße zu trauen ist. Bucket- und Zeitraumfilter grenzen die Ansicht auf einen bestimmten Arbeitstyp oder einen anderen Sprintzeitraum ein: wenn Sie den Bucket-Filter allein auf „Bugs" umstellen, beantwortet das zum Beispiel die Frage „sind unsere Bugs tatsächlich schneller als unsere Features, oder fühlt es sich nur so an", ohne dass jemand zu einer Tabelle greifen muss. Eine Schaltfläche „CSV exportieren" steht für den Moment bereit, in dem jemand die Rohdaten wirklich an jemand anderen weitergeben möchte: auch, falls es darauf hinausläuft, an einen eigenen Power-BI-Bericht.
Wo das Power BI nicht ersetzt
Diese Ansicht versucht nicht, ein allgemeines Reporting-Tool zu sein, und sollte es auch nicht sein. Wenn Sie Azure-DevOps-Daten mit Zahlen aus anderen Systemen kombinieren, vollständig individuelle projektübergreifende Berichte erstellen müssen oder Ihre Organisation bereits auf eine bestehende Power-BI-Präsenz setzt, ist der native Analytics-und-Power-BI-Weg weiterhin die richtige Wahl: genau dafür ist er gebaut. Wofür die Zykluszeit-Ansicht von Agile Gauge gedacht ist, ist die viel häufigere Anfrage: „zeig mir die Zykluszeit unseres eigenen Teams, jetzt sofort, ohne dass jemand dafür ein Reporting-Projekt aufsetzen muss."
Der Weg dorthin
Es gibt keine OData-Verbindung zu konfigurieren und keinen Bericht zu erstellen, bevor Sie etwas sehen. Sobald die Workflow-Stufenzuordnung Ihres Teams in der Konfiguration festgelegt ist: ein einmaliger Schritt, auf den jede Ansicht im Hub angewiesen ist, liest die Zykluszeit-Ansicht Ihre letzten sechs Sprints und zeichnet das Diagramm. Wenn Sie die Konfiguration noch nicht angefasst haben, sagt Ihnen der Bildschirm das, statt eine Zuordnung zu erraten und Ihnen Zahlen auf Basis einer Vermutung zu zeigen.
Agile Gauge liest direkt aus Ihrer eigenen Azure-DevOps-Organisation: nichts wird auf einen von uns betriebenen Server kopiert. Starten Sie eine 14-tägige Testversion, mit vollem Funktionsumfang, keine Kreditkarte erforderlich.