Agile Metriken für Teams und Projekte

Teilen!

Vor ein paar Wochen hatte ich eine Videokonferenz mit jemandem über die Leitung großer, verteilter, multidisziplinärer Teams. Vor ein paar Jahren prägte ich den Begriff "Beweglichkeit für Erwachsene"Dies zeigt, dass die Herausforderung der Agilität, die darauf abzielt, große Dinge zu erreichen, darin besteht, eine große Organisationsstruktur zu mobilisieren, um Initiativen oder Leistungen höherer Größenordnungen zu vollenden. Während dieses Gesprächs kam die folgende Frage auf: Wie erstellen wir agile Indikatoren und Metriken, um den Betrieb zu überwachen? agile Metriken, die es uns wirklich ermöglichen zu sehen, wie gut wir sind oder wie gut wir in unseren Projekten abschneiden? welche agilen Metriken ermöglichen es uns, besser informierte Entscheidungen zu treffen?

Kodierung und hervorgehobener Text im Editor

Für die Zwecke dieses Artikels möchte ich jedoch klarstellen, dass ich ein Liebhaber des Programmierens oder der Softwareentwicklung bin - ich bin kein Softwareentwickler. Kodierung. Mein berufliches Leben hat mich in die Bereiche Team- und Projektmanagement geführt, aber ich habe nie aufgehört, Code zu "schreiben". Niemals für mehr als ein Jahr. Manchmal mache ich das als Hobby. Ich besuche regelmäßig Kurse auf einer Online-Plattform, um mich auf dem Laufenden zu halten, oder ich unterstütze Entwicklungsprojekte, indem ich ein paar Zeilen Code beisteuere. Von dem unterschätzten PHP auch leistungsstark Weiter. Programmieren ist etwas, das mich begeistert. Dank dieser Kombination aus Menschenführung und dem Schreiben bunter Briefe. [1] In den gängigsten Quellcode-Editoren ist es üblich, eine Funktion namens Syntaxhervorhebung die Schlüsselwörter, Anweisungen und Symbole hervorhebt und so die Unterscheidung des Codes und seiner Struktur erleichtert. Ich hatte das Glück, an Projekten mit wenigen, vielen oder Hunderten von Menschen teilzunehmen, sie zu koordinieren und zu leiten, von der Konzeption über die Entwicklung bis hin zu Tests und Betrieb.

Dieser Artikel ist eine kurze Zusammenfassung der Kennzahlen, Indikatoren und Dashboards, mit denen ich im Laufe der Jahre erfolgreich gearbeitet habe und die ich heute in meiner Rolle als Berater gerne mit den Teams, die ich betreue, einsetze.

Maßnahmen, Metriken und Indikatoren

Lange Zeit dachte ich, dass Maß, Metrik und Indikator im Wesentlichen dasselbe sind. Mit der Zeit entdeckte ich feine Unterschiede, und mit zunehmender Erfahrung wurde mir klar, wie groß der Abstand zwischen ihnen ist.

Was ist also der Unterschied zwischen Maßnahmen, Metriken und Indikatoren? Sehen wir uns einige Definitionen und ein Beispiel für gute Definitionen an.

DefinitionBeispiel
MessungSie ist das Ergebnis des Vergleichs einer Größe (das, was wir messen wollen) mit einer Konstante oder einem Standardreferenzwert (Meter, Byte, Kilogramm).10 Anforderungen
5 Mängel mit niedriger Priorität
3 Lieferungen
4 Iterationen
MetrischDie Kombination von zwei oder mehr Messungen, um Verhältnisse oder Beziehungen herzustellen.100 Kilometer pro Stunde
50 Gigabyte pro Sekunde
30 Story-Punkte pro Iteration
IndikatorEs ist ein Rating oder ein Bewertungswert, der uns etwas in Bezug auf ein Ergebnis sagt.100% Konformität
3% Leistung
A+ in einer Prüfung

Vergleichsbeispiel zwischen Maß, Metrik und Indikator

Um den Unterschied in einem Beispiel zu verstehen, in dem wir Maßnahmen, Metriken und Indikatoren verwenden, möchte ich das folgende Beispiel anführen.

Joanna hat einen Test mit 100 Fragen gemacht und 50 richtig beantwortet.

Subjektive Bewertung der Daten

Wie hat Joanna Ihrer Meinung nach abgeschnitten? Schauen wir mal.

  • Joanna machte einen Test mit 100 Fragen (Messung).
  • Nach Angaben der Ersteller des Tests hat Joanna 50 Fragen richtig beantwortet (Messung). Diese Messung ergibt sich aus dem Vergleich jeder Frage und ihrer Antwort mit der erwarteten Frage und Antwort (Standard).
  • Joanna erhielt 50% der richtigen Fragen (metrisch). Diese Kennzahl ist das Verhältnis von Gesamtfragen zu richtigen Fragen.

Erfahrungen und Werturteile

Jetzt sagen Sie wahrscheinlich: "Joanna hat versagt". Die Wahrheit ist, dass Sie eine Kennzahl als Indikator verwenden. Sie tun dies, indem Sie annehmen, dass das Ziel des Tests darin bestand, 100% der richtigen Antworten zu erhalten. Das mag in der Schule und an der Universität richtig sein, aber im geschäftlichen Kontext sind es nur Werturteile - sehr subjektive Meinungen.

Um einen Indikator zu definieren oder zu identifizieren, müssen wir dem Beispiel noch ein paar weitere Informationen hinzufügen.

Nach der Auswertung von mehr als 15.000 Tests, die an der gleichen Anzahl von Personen durchgeführt wurden, stellten wir fest, dass Joanna eine der höchsten Punktzahlen erreichte und mehr als 99% der getesteten Personen übertraf (Indikator).

Moment, ich bin langsam! Es wurde interessant. Obwohl Joanna nur 50% der Fragen richtig beantwortet hat, liegt sie mit 1% in der Spitzengruppe. Was denken Sie jetzt? Haben Sie einen Einblick in Joanna und ihre Leistung? Haben Sie das Gefühl, dass 99% Ihnen etwas sagt? Können Sie eine objektivere Meinung über Joanna und ihren Test abgeben?

Das ist es auch. Der 99% sagt uns, dass Joanna zu den besten 150 von 15.000 gehört. Und natürlich können wir sicher sein, dass Joanna zu den Guten gehört - oder zu den weniger Schlechten, wenn man sich über die Tatsache hinwegsetzt, dass sie nur 50% richtig beantwortet hat. In beiden Fällen ist diese Nummer (99%) ein Indikator. Wenn 50% eine kalte Metrik war, die aufgrund von Vorurteilen oder Paradigmen als Indikator angenommen wurde, sagt uns 99% etwas und verringert die Objektivität unseres Urteils.

Wie definiert man agile Indikatoren und Metriken richtig?

Nachdem nun der Unterschied zwischen Messung, Metriken und Indikatoren klar ist, werde ich im Folgenden Beispiele für Indikatoren und Metriken für Agilität nennen. Es ist jedoch nicht möglich, Metriken und Indikatoren zu definieren, die für jeden Kontext gelten. Um den Artikel einfach und unterhaltsam zu halten, werde ich zwei verschiedene Ziele setzen:

  1. Messung der Leistung agiler Teams mit Indikatoren und Metriken
  2. Messung der Leistung und des Fortschritts eines Projekts bis zum Abschluss

Obwohl viele der Messungen gleich sind, versuchen die Messgrößen und Indikatoren, unterschiedliche Beziehungen und Hinweise zu ermitteln. Ich darf die Zeitlichkeit von Projekten nicht vergessen, d.h. sie haben von ihrer Konzeption her einen Anfang und ein Ende.

Wenn Sie beispielsweise für den IT-Bereich eines Unternehmens verantwortlich sind, würden Sie unter normalen Umständen nicht daran denken, das Team willkürlich aufzulösen. Wenn wir jedoch von Projekten sprechen, denken wir unweigerlich an ein Team, das mit absoluter Sicherheit aufgelöst werden muss - und genau das ist es, worüber wir hier sprechen. Vertagung würden die Kenner sagen.

Was sind Story Points?

Dies ist ein Artikel über agile Metriken. Bevor ich fortfahre, möchte ich noch ein Konzept erläutern, nämlich das der Story Points. Story-Punkte o SP. Das heißt aber nicht, dass ich ausschließlich über Scrum. Um zu verstehen, wie agile Team-Metriken funktionieren, müssen wir den Kontext definieren und bestimmen:

  1. Ein Messzeitraum, wie z. B. Sprints in Scrum, Iterationen - allgemein für alle agilen und hybriden Modelle, oder Programminkremente in SAFe.
  2. Definieren Sie eine Maßeinheit für den Aufwand, die hoffentlich auch die Komplexität und das Risiko mit einschließt. Stellen Sie sich vor, Sie müssten ein Dashboard für mehrere Teams mit Personenstunden, Funktionspunkten und SPs konsolidieren - der blanke Wahnsinn!

Die erste ist einfach: Sie definiert einen festen Zeitraum - eine Woche, eine Iteration, einen Monat, ein Quartal oder ein Jahr. Die zweite Frage bedarf weiterer Erörterung. Die gebräuchlichsten Maßeinheiten, die wir zur Messung des Aufwands verwenden, sind:

  1. Personenstunden - wie viele Stunden es dauert, eine Aufgabe zu erledigen oder eine Leistung zu erbringen.
  2. Ideale Tage Person - wie viele ideale Tage, d. h. ohne Unterbrechungen oder Aufgabenänderungen, jemand für die Erledigung einer Aufgabe oder Leistung benötigen würde. Ideale Tage sind fast immer von einem Produktivitätsfaktor begleitet. D.h. 3 ideale Tage mit einem Faktor von 50% bedeutet, dass es 6 Tage dauern wird, bis die Arbeit abgeschlossen ist.
  3. Funktionspunkte - schwer zu erklären, wenn man kein Programmierer ist, aber ich lasse eine Link für die Neugierigen.
  4. Geschichte Punkte

Aber was sind Story Points eigentlich? Lassen Sie mich dies an einem einfachen Beispiel erläutern.

Historische Punkte definieren

Die Geschichte zeigt - Story-Punkte o SP - sind eine Maßeinheit, um eine relative Schätzung des Aufwands auszudrücken. Diese Schätzung geht von einem einzigen Wert aus:

  • Anstrengung
  • Komplexität
  • Risiko

Um das Konzept zu verstehen, hier ein Beispiel.

Eine Person muss 20 Fenster in ein 10-stöckiges Gebäude einbauen. Alle sind gleich, haben die gleichen Abmessungen und sind mit den gleichen Mechanismen verankert. Das Gebäude weist keine baulichen Veränderungen auf, die eine Änderung des Installationsprozesses erfordern würden.

Ein Planer könnte davon ausgehen, dass die Installation aller 20 Fenster insgesamt 400-600 Minuten dauert, wenn die Installation eines Fensters 20-30 Minuten dauert.

Wenn man jedoch bedenkt, dass sich nicht alle Fenster auf derselben Etage befinden und dass aufgrund der Höhe ein zusätzliches Risiko besteht, könnte man davon ausgehen: [2] Das Beispiel der Fenster ist natürlich stark vereinfacht, um zu verdeutlichen, dass die Dauer einer Tätigkeit nicht die einzige Variable ist, die bei der Berechnung der SP berücksichtigt wird. :

  • Die Fenster in den ersten 3 Stockwerken haben einen relativen Wert von 1SP
  • Die Fenster in den Stockwerken 4 bis 8 haben einen relativen Wert von 2SP - erhöhte Risiken und Komplexität
  • Und die Fenster in den Stockwerken 9 und 10 haben einen relativen Wert von 3.SP - viel größeres Risiko und größere Komplexität

Wie Sie sehen, sind die SP der Ansicht, dass die Komplexität oder das Risiko umso größer ist, je höher die Höhe ist. Wir bewerten nicht nur die zeitliche Dauer von Aktivitäten, sondern berücksichtigen auch andere Dimensionen wie das Risiko oder die Komplexität.

Story Points sind eine relative Maßeinheit, die nur sinnvoll ist, wenn Sie mehr als eine Anfrage haben. Feststellung, dass ein aus dem Zusammenhang gerissener ABC-Antrag ein Gewicht von 3SP, 5SP o 20SP macht keinen Sinn. Zu sagen, dass ABC 3 ist, ist jedochSP und XYZ ist 5SPsagt uns, dass Y fast doppelt so viel SP (Aufwand + Komplexität + Risiko) bedeutet wie X.

Metriken für ein agiles Team

Jenseits von Projekten gibt es ein Managementuniversum, in dem wir Arbeit als kontinuierlich und unbestimmt betrachten können. Ich weiß, niemand lebt ewig, und in unserer Zeit halten viele Menschen nicht einmal zwei Jahre in ihrem Beruf durch. Die Art und Weise, wie wir die Leistung eines Teams verstehen, ist jedoch kontinuierlich.

Welche Metriken sind in einem Team nützlich? Hier sind die häufigsten

Kapazität: Wie viel können wir wohl schaffen?

Arbeitsfähigkeit des Teams

Meine bevorzugte Definition von Kapazität - Kapazität - ist: die Menge an Arbeit, die wir schätzen, oder das Projekt, das wir in einer bestimmten Zeitspanne abschließen können.

Die Fähigkeit wird in Personenstunden, Funktionspunkten oder Story Points gemessen (Metrik). Wir haben nicht immer die Informationen, um die Messung in einer bestimmten Einheit festzulegen, und ein Teil der Aufgabe eines Scrum Masters oder eines Moderators in Rollen wie RTE oder DASSM besteht darin, zu validieren, dass die definierten Metriken und Messungen den Kontext der Organisation unterstützen und nicht eher "Kopfschmerzen" als eine "Erleichterung" darstellen. [3]In der agilen Welt wird die relative Schätzung bevorzugt. Zu den beliebtesten Praktiken der relativen Schätzung gehört Planning Poker - Poker planen. Ebenso sind Story Points die am häufigsten verwendete Einheit, aber sie sind nicht die einzige Option.

Geschwindigkeit: Wie hoch ist die Kapazität und wie viel haben wir schon geschafft?

Geschwindigkeit ist ein Konzept, das sich auf die Menge an Arbeit bezieht, die ein Team in einer bestimmten Zeitspanne durchführen oder abschließen kann. Ursprünglich wurde er entwickelt, um die "individuelle Produktivität" in eXtreme Programming (XP)-Teams zu messen - was einige Leute nicht sehr glücklich gemacht hat. Ursprünglich wurde es für die Geschwindigkeit verwendet -Geschwindigkeit- um die "Belastungsfaktor" eines Teams. Der Belastungsfaktor war ein verworrenes Konzept, das durch die History Points abgelöst wurde.

Heute ist Velocity eine Anzahl von Punkten - von relativem Aufwand, wie SPs - in einem bestimmten Zeitraum. Wir können sie in folgende Kategorien einteilen:

  • Geplante GeschwindigkeitAnzahl der Punkte, die ein Team voraussichtlich in einem Zeitraum erreichen wird.
  • Echte Geschwindigkeit: Anzahl der Punkte, die ein Team in einem Zeitraum tatsächlich abgeschlossen hat - Es ist zu beachten, dass in Scrum der Begriff "abgeschlossen" die Arbeit des Entwicklungsteams und die Genehmigung des PO einschließt, d.h. abgeschlossen und genehmigt.

Compliance: Was haben wir erfolgreich abgeschlossen?

Metriken am Ende einer Iteration

Erfüllung kann definiert werden als die Menge (Messung) der Arbeit, die innerhalb einer bestimmten Zeitspanne (andere Messung) effektiv geliefert oder erledigt wurde. In Kontexten mit hoher Variabilität möchte ich diese Metrik jedoch in zwei Teile aufspalten oder zerlegen:

  1. Einhaltung des Plans: Was von dem, was wir uns vorgenommen hatten, konnten wir erfolgreich umsetzen?
  2. Erfüllung statt Anstrengung: Wie viel von dem, was wir glauben, erledigen zu können, wurde erledigt?

Obwohl man auf den ersten Blick meinen könnte, dass es sich um ein und dasselbe handelt. Und sicherlich einige Scrum-Verrückter ist davon auszugehen, dass innerhalb einer Sprint können wir keine zusätzliche Arbeit aufnehmen. Dies ist jedoch nicht immer der Fall[4]Der Begriff "Scrum-Maniac" steht für blinde Liebe und Ignoranz gegenüber den Realitäten eines akademischen Managementmodells. Ich bin überrascht über die politische Korrektheit meiner Definition. .

Wenn es der Zeitraum oder der Umfang der Arbeit zulässt - Umfang - extrem variabel ist, ist es sehr wahrscheinlich, dass wir neue Elemente finden oder sogar einige austauschen werden, die wir für ähnlich groß halten. In diesem Zusammenhang sind die zu Beginn des Zeitraums geplanten Aufgaben nicht unbedingt ein guter Gradmesser für die Einhaltung der Vorschriften.

Variabilität: Wie stabil ist unser Plan?

Variabilität und Anpassungsbedarf im Team

Wenn also die Einhaltung der Vorschriften ein Verständnis dafür erfordert, wie sehr sich der ursprüngliche Plan - oder der zu Beginn des Zeitraums definierte Plan - geändert hat, kann eine Kennzahl, die bewertet, wie stark sich der ursprüngliche Plan geändert hat, sehr nützlich und aufschlussreich für das Team sein.

Die Berechnung der Variabilität kann schwierig sein und erfordert viel Disziplin. Was wir vermeiden wollen, ist, an Dingen zu arbeiten, die dann in keiner Weise zu unseren Metriken beitragen. Daher sollte jede neue Aktivität oder Aufgabe innerhalb eines Zeitraums als Teil des ursprünglichen Plans oder als neu und unerwartet gekennzeichnet oder klassifiziert werden.

Qualität: Wie gut machen wir unsere Arbeit?

Qualitätsmetriken für Teams

Nun, wir konnten die Qualität nicht außer Acht lassen. In diesem Fall betrachte ich die Qualität als ein Verhältnis zur Quantität der geleisteten Arbeit. Viele Teams "zählen" einfach Fehler oder Vorfälle. Das ist, wie Sie vielleicht schon wissen, ein Fehler. Die Messung ist keine Metrik und schon gar kein Indikator.

Das Wörterbuch definiert Qualität als:

Eigenschaft oder eine Reihe von Eigenschaften, die einer Sache innewohnen und die es ermöglichen, ihren Wert zu beurteilen.

Wörterbuch der spanischen Sprache

Ein Qualitätsmaßstab, den ich gerne verwende, wird von einigen Autoren so bezeichnet, FehlerquoteWie hoch ist der Prozentsatz der Lieferungen, die in irgendeiner Weise durch Qualitätsprobleme beeinträchtigt werden?

Eine ähnliche Metrik - und mein Favorit - ist die Fehlerdichte. Diese Kennzahl ist ein Verhältnis zwischen der Anzahl der Mängel und der Lieferung.

Metriken für agile Projekte

Natürlich können auch Projekte von Team-Metriken profitieren. Im Gegensatz zum Team streben sie jedoch eine bestimmte Fertigstellung oder einen Abschluss an. In ähnlicher Weise können Projektmetriken bei der Verfolgung einer Veröffentlichung verwendet werden - und sie können dazu dienen, den Fortschritt eines Projekts zu verfolgen. Freigabe.

Fortschritt: Wie weit sind wir gekommen?

Durch die Festlegung eines Ziels ist es möglich, einen Maßstab für den Fortschritt festzulegen. Um dies zu erreichen, brauchen wir eine der folgenden Möglichkeiten - obwohl ich persönlich versuche, beides einzustellen:

  1. Ein Datum - Meilenstein
  2. Ein spezifisches Ziel - je nach dem zu entwickelnden Produkt oder Dienst

Wenn ein Limit oder ein Ziel festgelegt ist, können wir eine Fortschrittskennzahl definieren, die auf dem Umfang der abgeschlossenen Arbeit und ihrer Auswirkung auf das Ziel basiert - oft als Wert bezeichnet, im Gegensatz zur geplanten Gesamtkapazität, um den Meilenstein zu erreichen.

Gefahr! Fortschritt bis zur Fertigstellung über einen variablen Bereich

Die größte Schwierigkeit bei der Messung der Fortschritte in einem "anpassungsfähig "Kontext ist das ständige Bestreben, den Spielraum zu schließen. Es ist schwierig, und für manche sogar lästig, die Fortschritte bei einem beweglichen Ziel zu verfolgen. Im agilen Kontext ist das Konzept der Zielsetzung o Wert und wird bevorzugt gegenüber Umfang. Der Umfang kann also je nach dem zu erreichenden Ziel variieren.

Beispiel für ein festes Ziel mit variabler Reichweite

Nehmen wir ein anderes Beispiel, aber dieses Mal lassen wir Joanna in Ruhe.

Es ist Freitagabend und Pedro, ein Junggeselle, der bald 30 wird, möchte ausgehen und sich amüsieren. Allerdings hat er nicht viel Geld und morgen, am Samstag, hat er ein Mittagessen mit seinen Eltern, an dem er teilnehmen möchte.

Peter hat also definiert:

  1. Ein klares Ziel
  2. Ein geschätztes Budget - eine Begrenzung der Ressourcen
  3. Eine Frist - sagen wir, Sie wollen beim Mittagessen mit Ihren Eltern nicht verkatert sein - oder zumindest die Fähigkeit haben, Ihren Kater zu verbergen.

Peter hat jedoch keinen Plan und ist sich nicht im Klaren darüber, wie er "Spaß haben" soll. Schauen wir uns also an, wie der Anwendungsbereich im Hinblick auf das Ziel variabel ist.

Erstes Szenario

Pedro hat beschlossen, seine Freunde anzurufen und sich mit ihnen in einem ihrer Häuser zu treffen. Wenn Pedro so ist wie ich, werden sie wahrscheinlich ein paar Bier trinken, in Erinnerungen schwelgen, vielleicht ein paar Videospiele spielen und irgendwann am Abend eine Pizza essen. Gegen 3 oder 4 Uhr morgens ist Pedro zu Hause und freut sich, dass er wieder mit seinen Freunden zusammen ist und eine Nacht voller "Freundschaft" hinter sich hat.

Zweites Szenario

Peter hat beschlossen, in seine Lieblingsbar zu gehen. Dort hat er eine Person kennengelernt, die er sehr mag und mit der er eine tolle Nacht verbringen könnte. Es ist ein Moment des "Flirtens", der Romantik, ein Moment der Eroberung. Pedro beschließt, sich zu nähern und es zu versuchen. Am nächsten Tag ist Peter glücklich und hat das Gefühl, eine "romantische Nacht" verbracht zu haben, ohne viele Details zu nennen.

Drittes Szenario

Pedro hat beschlossen, in seine Lieblingsbar zu gehen, aber er erkennt niemanden. Er fühlt sich ein wenig einsam, sieht aber die Gelegenheit, mit neuen Leuten zu sprechen. Bei ein paar Drinks und guter Musik findet er neue Freunde. Am Ende des Tages ist er zu Hause, lernt neue Leute kennen und hat das Gefühl, dass er unerwartet in seiner Lieblingsbar war.

Jedes der Szenarien stellt unterschiedliche Aktivitäten und Verhaltensweisen innerhalb eines gemeinsamen Ziels und mit denselben Einschränkungen dar - im Projektjargon als ZwängeHalten Sie es nun für möglich, die Reichweite je nach Ziel zu variieren? Ich habe nicht gesagt, dass es einfach oder schnell ist, aber es ist in bestimmten Kontexten möglich.

Kreditaufnahme: Wie viel haben wir in den ursprünglichen Plan aufgenommen oder ausgehandelt?

Nun, wenn wir eine Fortschrittsmetrik haben und wissen, dass der Umfang variabel ist, ist es eine sehr gute Idee, den Grad der Projektverschuldung gegenüber dem Plan zu messen und zu verfolgen. Das heißt, welcher Prozentsatz der ursprünglich geplanten oder projizierten Arbeit liegt jetzt außerhalb der Möglichkeiten des Teams für das festgelegte Datum und Ziel.

Was passiert, wenn Peter an einem Tisch mit neuen Freunden sitzt und in diesem Moment die Person erscheint, die er mag? Es ist unvermeidlich, dass er für dieselbe Nacht und dasselbe Budget Entscheidungen treffen muss. Jede Entscheidung ist mit Kosten verbunden, und einige Aktivitäten werden Ihre Kapazitäten übersteigen - für den betreffenden Zeitraum.

Beispiele für agile Metriken

Ich stelle nun einige Beispiele vor und begleite sie mit einigen Erklärungen, von denen ich hoffe, dass sie dazu beitragen werden, die Konzepte zu einem Abschluss zu bringen. Schauen wir mal.

Metriken eines engagierten Teams

Metrisch Zeitraum 1 Zeitraum 2 Zeitraum 3
Geplante Geschwindigkeit 35 31 31
Echte Geschwindigkeit 29 28 31
Einhaltungsplan 82% 90% 100%

Auch wenn das Gerät nie die Planerfüllung von 100% erreicht - was meiner Erfahrung nach der beste Fall ist - können wir feststellen, dass es eine wirklich stabile Geschwindigkeit von etwa 30SP. Man könnte meinen, dass sich ein Planungsteam an 100% halten sollte, doch in Wahrheit gefährdet diese Praxis ehrliche und transparente Schätzungen.

Bitte beachten Sie, dass ich das Wort "Periode" und nicht "Sprint" verwende, weil es keine Verpflichtung ist, Scrum mit diesen Metriken zu verwenden - obwohl es gut funktioniert.

100% eines Sprint- oder Periodenplans erfüllen

Das ist eine sehr schlechte Idee, und ich werde erklären, warum.

Stellen Sie sich vor, Sie sind Teil eines agilen Teams und haben sich während der Iterationsplanung darauf geeinigt, die Anforderungen für insgesamt 100SP. Während der Iteration ist einer Ihrer Kollegen erkrankt und kann nicht an der Iteration teilnehmen, und einige der Anforderungen werden durch Abhängigkeiten mit einem Lieferanten blockiert. Was bedeutet das?

  1. Es ist klar, dass das Team nicht in der Lage sein wird, sein Ziel von 100 % zu erreichen.SP.
  2. Wenn es nicht die Schuld des Teams ist, würden wir es nicht gleich als "schlechte Planung" bezeichnen - dies ist ein häufiger Fehler derjenigen, die glauben, dass Menschen Maschinen sind und dass Pläne buchstabengetreu befolgt werden müssen.
  3. Die schwerwiegendste der 100SPDas Team hat keine zusätzlichen Elemente mehr, die es übernehmen und umverteilen muss, um Zeitverluste zu vermeiden.

Was sollten wir tun, sollten wir die Iteration aussetzen, eine Notfallplanung vornehmen, wie sieht es mit dem Engagement und den agilen Metriken aus?

Das Team ist nicht nur blockiert, es hat auch keine anderen Elemente, um sein Ziel von 100 % zu erreichen und "neu zusammenzusetzen".SP. Für diejenigen, die Spaß an Mathematik haben, sollten Schätzungen Spannen und nicht absolute Punkte sein. Wenn die voraussichtliche Kapazität eines Geräts 100 % beträgtSPDas Team sollte sich auf einen Wert von etwa 110SP o 115SPVerständnis dafür, dass es Tage mit hoher Leistung geben kann. Ebenso hat der PO für den Fall, dass etwas mit negativen Auswirkungen eintritt, einen "Plan B", um das Team umzuorganisieren, damit wir daran arbeiten können.

Agile Metriken "in Schwierigkeiten", was ist da los?

Metrisch Zeitraum 1 Zeitraum 2 Zeitraum 3 Zeitraum 4 Zeitraum 5 Zeitraum 6
Geplante Geschwindigkeit 35 31 31 33 25 20
Echte Geschwindigkeit 29 28 31 25 20 18
Einhaltung der Vorschriften 82% 90% 100% 75% 80% 90%

Auf den ersten Blick hat sich ab Periode 4 etwas getan, aber was ist passiert, und warum sinkt die "reale Geschwindigkeit"?

Die einfache Lösung besteht natürlich darin, gemeinsam mit dem Team einen Raum zum Nachdenken zu nutzen, die Ursachen zu ermitteln und Lösungen zu finden. Auf der Managementebene kann es jedoch nützlich sein, die Vorgänge in Daten auszudrücken. Manager stehen nicht immer in ständigem Kontakt mit agilen Teams und beschränken sich auf Berichte und Metriken. Schauen wir uns also einige weitere Informationen zu diesem Fall an.

Metrisch Zeitraum 1 Zeitraum 2 Zeitraum 3 Zeitraum 4 Zeitraum 5 Zeitraum 6
Geplante Geschwindigkeit 35 31 31 33 25 20
Echte Geschwindigkeit 29 28 31 25 20 18
Ungeplante Lieferung 0 0 0 5 6 4
Aufwand für die Einhaltung der Vorschriften 82% 90% 100% 75% 80% 90%
Einhaltungsplan 82% 90% 100% 60% 56% 80%
Variabilität 0% 0% 0% 20% 30% 22%

Nun, diese erweiterte Tabelle spricht Bände. Aus irgendeinem Grund wurde dem Team innerhalb desselben Zeitraums ungeplante Arbeit zugewiesen - zum Beispiel Anpassungen an bestehenden Funktionen, Änderungen oder Verbesserungen. Niemals Mängel.

Wie viele Punkte sollte ich für Mängel vergeben? Keine

Dies ist ein Diskussionspunkt: Soll ich den Aufwand für die zu behebenden Mängel oder Vorfälle quantifizieren oder nicht? Ja und nein. Meiner Erfahrung nach können agile Metriken manipuliert werden, wenn die Vorfälle oder Defekte in den Team-Metriken ein Gewicht haben. Allerdings:

  1. Es ist gut, sie zu quantifizieren, um den relativen Aufwand zu bestimmen.
  2. Es ist schlecht, sie zu quantifizieren, um die Geschwindigkeit des Geräts zu bestimmen.

Wenn ein Team einen Großteil seiner Zeit und Kapazität für die Behebung von Fehlern aufwenden muss - also von Dingen, die nicht so funktionieren, wie wir es vereinbart haben -, dann ist meiner Meinung nach die beste Kennzahl, um dies widerzuspiegeln, ein "Kapazitätsverlust". Andernfalls könnten Sie Teams mit hohen relativen Punktzahlen haben, die nichts weiter als behobene Mängel liefern.

Zusammenfassend lässt sich sagen, dass ein Team, das seine Zeit mit Korrekturen verbringt, seine Geschwindigkeit verringern sollte.

Wie lässt sich die Qualität der in einem agilen Team geleisteten Arbeit messen?

Sehen wir uns einige weitere Informationen von unserem agilen Team an.

Metrisch Zeitraum 1 Zeitraum 2 Zeitraum 3 Zeitraum 4 Zeitraum 5 Zeitraum 6
Geplante Geschwindigkeit 35 31 31 33 25 20
Echte Geschwindigkeit 29 28 31 25 20 18
Ungeplante Lieferung 0 0 0 5 6 4
Aufwand für die Einhaltung der Vorschriften 82% 90% 100% 75% 80% 90%
Einhaltungsplan 82% 90% 100% 60% 56% 80%
Variabilität 0% 0% 0% 20% 30% 22%
Assoziierte Defekte 3 3 5 7 8 7

Das Zählen von Mängeln auf einfache Weise ist eine schlechte Idee. Ein Fehler ist nicht gleich ein Fehler. Einige Mängel erfordern mehr Arbeit als andere, daher ist es eine gute Idee, relative Werte zu verwenden, um Mängel zu quantifizieren - denken Sie daran, dass ich "Die Mängel eines Mangels" geschrieben habe.Es ist gut, sie zu quantifizieren, um den relativen Aufwand zu bestimmen.".

Daher ist es eine gute Idee, sie nach Größen zu sortieren oder etwas Ähnliches wie SP zu verwenden.

Am besten ist es jedoch, ein Verhältnis zwischen den gelieferten SPs und den in einer Periode injizierten Defekten herzustellen - richtig, injizieren klingt seltsam.

Metrisch Zeitraum 1 Zeitraum 2 Zeitraum 3 Zeitraum 4 Zeitraum 5 Zeitraum 6
Geplante Geschwindigkeit 35 31 31 33 25 20
Echte Geschwindigkeit 29 28 31 25 20 18
Ungeplante Lieferung 0 0 0 5 6 4
Aufwand für die Einhaltung der Vorschriften 82% 90% 100% 75% 80% 90%
Einhaltungsplan 82% 90% 100% 60% 56% 80%
Variabilität 0% 0% 0% 20% 30% 22%
Assoziierte Defekte 3 3 5 7 8 7
Defekt-Dichte 0.15 0.10 0.16 0.28 0.40 0.38

Bei dieser zweiten Gelegenheit steigt die Fehlerdichte - die Anzahl der injizierten Fehler pro geliefertem SP - an. Es ist möglich, dass Sie durch die Einführung neuer Anforderungen in diesem Zeitraum den Plan oder die Auswirkungen dieser Anforderungen nicht richtig festlegen. Dies wirkt sich natürlich auf die Fähigkeit zur Lieferung aus. niedrigere reale Geschwindigkeit - und die Qualität der Lieferung - höhere Defektdichte.

Maßstabsmodelle und Programminkremente

Nun, bisher haben wir nur über Metriken auf Teamebene gesprochen. Jede einzelne der vorgestellten Metriken kann für mehrere Teams - bei entsprechender Normalisierung - und für verschiedene Zeiträume wie Iterationen, Monate und Programminkremente (PI) verwendet werden.

Wenn Sie sich immer noch an der "Variabilität" stören, sollten Sie Folgendes bedenken:

  1. Sie können innerhalb derselben Iteration entscheiden, etwas nicht zu akzeptieren.
  2. Was zusätzlich oder neu ist, kommt in die nächste Iteration - Iterationsvariabilität 0%
  3. Diese Iteration ist jedoch Teil eines UZ, und daher ist es ratsam, die Variabilität der Iteration zu messen, um die Messungen und Projektionen während der nächsten UZ-Planung zu verbessern.

Überlegungen

Wie Sie sehen, lassen sich agile Metriken auf agile Projekte, agile Teams und groß angelegte Projekte anwenden. Wenn Sie nur Metriken für das Team aufbewahren, verlieren Sie die Möglichkeit der Skalierung. In großen Organisationen mit Hunderten oder Tausenden von Mitarbeitern sind Retrospektiven und eine einfache Kommunikation der Gründe und Maßnahmen nicht möglich. Deshalb kann die Festlegung von Kennzahlen und die Förderung des Lesens und Verstehens dieser Kennzahlen dazu beitragen, dass Sie die notwendige organisatorische Unterstützung erhalten. In einer großen Organisation braucht jeder "politische" Unterstützung, und der erste Schritt, um diese zu erhalten, besteht darin, sichtbar zu machen, was vor sich geht.

Teilen!

Kommentare und Anmerkungen des Autors[+]

Standardbild
Alberto Dominguez
Führung von Teams von der Theorie bis zur tatsächlichen und nachhaltigen Bereitstellung innovativer IT-Produkte und -Dienstleistungen.
Artikel: 33

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

de_DE