Ein Ring, um sie alle zu regieren
Jrtolkien
"Sie können nur steuern, was gemessen werden kann"
P. DruckerWenn es um Metriken geht, kommen Dutzende, wenn nicht Hunderte verschiedener Optionen in den Sinn.
Welche Messungen wurden nicht erfunden!
Aber das Problem ist, wenn man sich diese schönen Bilder ansieht, ist es oft völlig unverständlich, was sie bedeuten.
Und im Allgemeinen ist es völlig unklar, ob diese Metriken richtig gewählt wurden oder ob es sich lohnt, ganz andere zu betrachten?
Ich möchte eine Art Metrik, so dass ich aussah und alles sofort klar wurde.
Aber existiert es? Oder gibt es keine Magie?
Schauen wir uns ein konkretes Beispiel an ...
Oft haben wir nur einen bestimmten Satz von Eingabedaten, mit denen nicht klar ist, was zu tun ist.
Jira und ihre Aufgaben
Stellen Sie sich vor, Ihr Unternehmen verwendet den Jira Task Tracker und alle Entwickler sind verpflichtet, Ereignisse zu markieren, bei denen Aufgaben zur Arbeit gebracht werden, sowie deren Lösungen.
Sie können eine Entladung für Jira-Aufgaben erhalten, aber was ist als Nächstes zu tun?
In dieser Situation ist es eine gute Idee, genau darüber nachzudenken, was Sie verwalten und welches Ergebnis Sie erzielen möchten.
Lesen Sie zum Beispiel den Artikel "
Einblick in Metriken: Wie ich es verstehe, was sind Metriken und was ist ihr Hauptcharme? "
Und wenn wir hier auch die Bücher „Lean Analytics“, „Running Lean“ und Tao Toyota hinzufügen, wird klar, dass es im Fall von Jira am richtigsten ist, die Lieferzeit der entwickelten Funktionalität für den Abschlussball zu verwalten und zu messen.
Das Ziel ist also gewählt - wir möchten die Zeit der Softwarebereitstellung messen, aber Sie können dies auf hundert verschiedene Arten tun. Sie können beispielsweise die Länge jedes Entwicklungsschritts messen und zu dieser Messung auch den Zeitverlust für das Warten, das Beheben von Fehlern, die Wiederentdeckung usw. hinzufügen. Sogar vskidku kann als etwa 50-70 verschiedene Metriken im Zusammenhang mit der Softwareentwicklung bezeichnet werden.
Wie soll ich sein? Gibt es diese einzige Metrik, anhand derer ein Blick alles verstehen kann?
Wenn Sie diese Dutzende von Metriken, die oben besprochen wurden, mit eigenen Augen gesehen haben, dann kenne ich Ihre Antwort im Voraus - Sie werden sagen: Nein! Und so will ich ...
Ich hätte gerne eine solche Metrik, einen Blick, mit dem man verstehen könnte, wie erfolgreich die Entwicklung verläuft und ob es notwendig ist, etwas Zusätzliches damit zu tun.
Überraschenderweise scheint es eine würdige Metrik zu geben, die den Titel des Einzigen sicher beanspruchen kann.
Schauen wir es uns genauer an.
In Jira gibt es einen Bericht wie das "Total Flow Diagram" ...
"Stop-Stop-Stop ... Jeder kennt ihn - du sagst, ich werde hier nichts Neues finden"
Im Allgemeinen ist der Bericht ja allen bekannt, aber lassen Sie uns ihn dennoch etwas genauer betrachten. Ich versichere Ihnen, dass Sie einige "angenehme" Überraschungen finden werden.
So sieht es normalerweise aus:
Einige Streifen. Warum sind sie? Warum? Was meinen sie? Und hier ist was ...
Dunkelroter Balken - Die Anzahl der
periodengerecht erledigten Aufgaben. Blau ist die Anzahl der Aufgaben in der Arbeit und Gelb ist die neuen Aufgaben, die im Backlog registriert sind.
Die kumulierte Summe ergibt sich, wenn die erledigten Aufgaben immer zur Anzahl der zuvor erledigten Aufgaben addiert werden.
Stellen Sie sich zum Beispiel vor, Sie hätten vorgestern zwei Aufgaben erledigt. Auf der Karte vorgestern wird vermerkt: 2.
Gestern hast du 3 weitere Aufgaben erledigt. Der nächste Punkt auf dem Chart ist 2 (gestern) +3 (gestern) = 5.
Und heute haben Sie noch eine Aufgabe erledigt. Der heutige Punkt auf dem Chart ist gleich 2 (gestern) +3 (gestern) +1 (heute) = 6
Das heißt, Der Zeitplan wird ständig erhöht.
Wenn Sie also die Anzahl der erledigten Aufgaben, die Anzahl der Aufgaben in der Arbeit und neue Aufgaben in das Diagramm einfügen, können Sie die einzige Metrik extrahieren.
Betrachten wir ein reales Beispiel (Entladen von Kibana und Elasticsearch):
Sehen Sie?
Tatsächlich können wir die Geschwindigkeit (oder Produktivität) der Entwicklung berechnen. 200 neue Aufgaben in 17 Tagen erledigt. Von hier erhalten wir, dass die aktuelle Entwicklungsgeschwindigkeit 11,76 Aufgaben / Tag beträgt, d.h.
0,085 Tage pro
Aufgabe .
Sie werden nach dem Zeitplan beurteilt, die Anzahl der Aufgaben in Arbeit, der blaue Bereich ändert sich nicht (die Breite des Streifens ist fast überall gleich), d.h. Wir können davon ausgehen, dass die Entwicklungsgeschwindigkeit im Gegensatz zur Anzahl der neuen Aufgaben konstant ist.
Bei der aktuellen Entwicklungsgeschwindigkeit werden 800 neue Aufgaben, die am 17.06.2008 erstellt wurden, erst nach 68,03 Tagen abgeschlossen.
Ok? Meiner Meinung nach nicht wirklich.
Sprechen? Auf jeden Fall!
Hier ist ein weiteres Beispiel aus der Praxis (Jira-Bericht). Dies ist der Zeitplan für die Ticketausführung durch den technischen Support:
Auf die gleiche Weise berechnen wir die Produktivität des Support-Service - 2,7 Aufgaben / Tag.
Es gibt etwas zu streben
Es reicht nicht aus, die aktuelle Geschwindigkeit zu kennen. Sie müssen auch den Zielwert verstehen, d. H. sehen, was zu streben ist.
Wenn Sie die Geschwindigkeit einer Person kennen, können Sie berechnen, wie viele Personen der Support-Service benötigt, um die angestrebte Anzahl von Aufgaben zu realisieren oder die aktuelle Produktivität zu steigern.
Der Support-Service beschäftigt 15 Mitarbeiter. Es stellt sich heraus, dass es 0,18 Aufgaben / Tag pro Person gibt.
Angenommen, Sie möchten die Ausführungsgeschwindigkeit erhöhen und den Dienst in die Lage versetzen, nicht 2,7 Aufgaben pro Tag, sondern 10 (Zielwert) auszuführen.
Eine Person erledigt 0,18 Aufgaben pro Tag, was bedeutet, dass 56 Personen 10 Aufgaben erledigen.
Nun, oder als Option können Sie die Geschwindigkeit einer Person erhöhen.
Bei einer Geschwindigkeit von 1 Aufgabe pro Tag benötigen Sie für 10 Aufgaben nicht mehr 56 Personen, sondern nur noch 10.
Wir verwalten die Lieferzeit
Es stellt sich heraus, dass Sie mit der Metrik tatsächlich die Lieferzeit beeinflussen können.
Wenn Sie die aktuelle Leistung mit dem Zielwert vergleichen, können Sie nachvollziehen, wie oft Sie den Prozess beschleunigen müssen.
Durch Variieren der Parameter, aus denen sich die Produktivität zusammensetzt (Anzahl der Personen und Geschwindigkeit ihrer Arbeit), können Sie die Gesamtlieferzeit steuern.
Wo sonst ist das anwendbar?
In der Tat können Analoga der Metrik in vielen Bereichen gesehen werden.
Nehmen Sie zum Beispiel DevOps. DevOps wird verwendet, um das Zeitintervall zwischen dem Erstellen eines Distributionskits und dem Bereitstellen auf einem Abschlussball zu verkürzen, d. H. Hier müssen Sie wie in den obigen Beispielen die Lieferzeit steuern.
Natürlich ist die Metrik auch ideal für DevOps. Zählen Sie einfach, wie viele Distributionen (Assemblys) in einer bestimmten Zeit den Abschlussball erreicht haben, und erhalten Sie die aktuelle Leistung Ihrer Pipeline.
Grundsätzlich kann dieselbe Metrik in geldbezogenen Bereichen verwendet werden.
Beispielsweise könnte man für einen Online-Shop auf ähnliche Weise die Anzahl der Bestellungen für eine bestimmte Zeit berechnen. Die ganze Frage ist, brauchen Geschäfte das wirklich?
Fazit
Wie Sie sehen, hat die One Only Universal Metric immer noch das Recht auf Leben, zumindest im Bereich der Softwareentwicklung und in den Servicebereichen (technischer Support).
Es ist einfach zu berechnen, enthält Bedeutung und kann zum Vergleich mit dem Zielwert verwendet werden.
Natürlich kann es nicht gedankenlos verwendet werden. Denken Sie darüber nach, bevor Sie mit der Implementierung beginnen, aber Sie brauchen es wirklich.
Was denkst du über die universelle Metrik?
Welche Metrik verwenden Sie als universell?