Hilfe! Zu viele Vorfälle! - Politik der Kapazitätszuweisung in agilen Teams

Als Agile Coach, Scrum Master, Product Owner oder Teammitglied waren Sie wahrscheinlich schon einmal in der Situation, dass mehr Arbeit auf das Team zukommt, als das Team bewältigen kann. Im Falle von Arbeit, die bereits bekannt ist, handelt es sich im Grunde um ein Planungsproblem, bei dem es darum geht, die optimale Reihenfolge zu bestimmen, in der das Team die Arbeit erledigt, um den Geschäftswert und das Ergebnis zu maximieren. Dies trifft typischerweise auf den Fall zu, dass ein Team an der Entwicklung oder Erweiterung eines neuen Produkts arbeitet. Der andere interessante Fall sind z.B. operative Teams, die an Objekten arbeiten, die ad hoc eintreffen. Ein Beispiel dafür sind Produktionsvorfälle. Die Arbeit trifft ad hoc ein und der Product Owner muss dem Team eine bestimmte Kapazität für bestimmte Arten von Vorfällen zuweisen. Soll das Team z.B. an Datenbankproblemen oder an Problemen im Zusammenhang mit dem Frontend arbeiten? Wenn das Team mehr als genug Kapazitäten hat, ist die Antwort einfach: Lösen Sie sie alle! In diesem Blog erfahren Sie, wie Sie feststellen können, welche Kapazität des Teams für welche Art von Vorfällen am besten geeignet ist.

Was versuchen wir zu lösen?

Bevor wir ins Detail gehen, lassen Sie uns definieren, welches Problem wir lösen wollen. Nehmen wir an, dass das Team verschiedene Arten von Vorfällen kennt, z.B. datenbankbezogene, GUI-bezogene und vielleicht noch einige mehr. Jede Art von Vorfall hat eine entsprechende durchschnittliche Lösungszeit. Außerdem trifft jede Art von Vorfall mit einer bestimmten Rate, der Input-Rate, beim Team ein. Beispielsweise treffen datenbankbezogene Vorfälle 3 Mal pro Monat ein, während GUI-bezogene Vorfälle 4 Mal pro Woche auftreten. Schließlich werden jeder Art von Vorfällen unterschiedliche Betriebskosten zugewiesen. Datenbankbedingte Vorfälle können dazu führen, dass 30 Benutzer nicht arbeiten können. GUI-bezogene Vorfälle betreffen z.B. nur einen Teil der Anwendung und betreffen nur wenige Benutzer. Das Team hat jederzeit einen Rückstand an zu lösenden Vorfällen. Dieser Rückstand ist mit Betriebskosten verbunden. Diese operativen Kosten wollen wir minimieren. Das Interessante an diesem Problem ist, dass wir diese Kosten unter der Bedingung minimieren wollen, dass wir nur eine begrenzte Anzahl von Ressourcen bzw. Kapazitäten haben. Der Produktverantwortliche möchte vielleicht absichtlich GUI-artige Vorfälle ignorieren und das Team an datenbankbezogenen Vorfällen arbeiten lassen. Oder 20% der Kapazität für GUI-bezogene Vorfälle und 80% der verfügbaren Kapazität für datenbankbezogene Vorfälle einsetzen?

Arten von Arbeit

Für jede Art von Arbeit definieren wir die Inputrate, die Produktionsrate, die Kostenrate, die Wartezeit und die durchschnittliche Lösungszeit: Î "_i = durchschnittlicher Inputsatz für den Typ 'i', _Ci = Betriebskostensatz für den Typ 'i', _xi = durchschnittliche Lösungszeit für den Typ 'i', _wi = durchschnittliche Wartezeit für den Typ 'i', _si = durchschnittliche Zeit, die der Typ 'i' im System verbringt, _μi = durchschnittlicher Produktionssatz für den Typ 'i' Einige Posten werden gelöst und verbringen die Zeit si = xi + wi im System. Andere Artikel werden nie gelöst und verbringen Zeit si = wi im System. Im vorherigen Blog Little's Law in 3D werden die durchschnittlichen Gesamtbetriebskosten wie folgt ausgedrückt: Durchschnittliche Betriebskosten für Typ 'i' = ½ λi Ci 〈Si(Si+T)〉 Um die Zielkosten zu erhalten, müssen wir diese für alle Arbeitsarten 'i' addieren.

System

Der Prozess für Arbeitsaufgaben sieht vor, dass sie in das System (Team) aufgenommen werden, sobald sie gefunden oder entdeckt werden. Wenn sie gefunden werden, tragen sie sofort zu den Gesamtbetriebskosten bei. Das hört auf, sobald sie behoben sind. Bei einigen entscheidet der Product Owner, dass das Team mit der Arbeit daran beginnen soll. Zu dem Zeitpunkt, an dem das Team mit der Arbeit an einem Problem beginnt, ist die Wartezeit wi bekannt und im Durchschnitt verbringt das Team eine Zeit xi bis zur Lösung des Problems. Da das Team über begrenzte Ressourcen verfügt, kann es nicht an allen Problemen arbeiten. Mit der Zeit wird die durchschnittliche Zeit, die im System verbracht wird, steigen. Wie im vorigen Blog Warum Little's Law funktioniert...Always gezeigt, gilt Little's Law auch dann, wenn wir ein endliches Zeitintervall betrachten. Dieser Prozess wird unten dargestellt:

〈M〉= feste Team-Kapazität, _{〈Mi〉=}Team-Kapazität für die Bearbeitung von Problemen des Typs 'i', 〈N〉= Gesamtzahl der Elemente im System Die Gesamtzahl der im 'grünen' Bereich erlaubten Elemente wird durch die Team-Kapazität begrenzt. Das Team kann ein WiP-Limit festlegen, um dies zu erzwingen. Im Gegensatz dazu ist die Anzahl der Artikel im 'orangen' Bereich nicht beschränkt: Vorfälle fließen in das System ein, wenn sie gefunden werden, und verlassen das System erst, wenn sie gelöst wurden. Ohne ins Detail zu gehen, können die gesamten Betriebskosten in Form von xi und wi umgeschrieben werden: (1) Durchschnittliche Betriebskosten für Typ 'i' = ½ λi Ci 〈wi(wi+T)〉 + μi Ci 〈xi〉 〈wi〉 + ½ μi Ci 〈xi(xi+T)〉

Was versuchen wir zu lösen? Noch einmal.

Nun, da ich das System gezeigt und genau definiert habe, was ich mit den Variablen meine, werde ich präzisieren, was genau wir zu lösen haben.

Finden Sie_Mi so, dass dies (1) unter der Einschränkung, dass das Team eine feste und begrenzte Kapazität hat, minimiert wird.

Wichtiger Hinweis Das System, das wir betrachten, ist nicht stabil. Daher müssen wir bei der Anwendung und Nutzung des Little'schen Gesetzes vorsichtig sein. Um die notwendigen Bedingungen für die Gültigkeit des Littleschen Gesetzes zu umgehen, werde ich die durchschnittlichen Gesamtbetriebskosten über ein endliches Zeitintervall betrachten. Das bedeutet, dass wir den Durchschnitt der Kosten über das Zeitintervall vom Start bis zu einem bestimmten Zeitpunkt minimieren werden. Da die kumulierten Kosten im Laufe der Zeit zunehmen, ist der Durchschnitt nicht mit den Kosten am Ende des Zeitintervalls identisch. Anmerkung: Damit unser Optimierungsproblem Sinn macht, muss das System instabil sein. Bei einem stabilen System folgt aus dem Little'schen Gesetz, dass die durchschnittliche Inputrate für Typ i gleich der durchschnittlichen Produktionsrate für Typ 'i' ist. In diesem Fall gibt es keine Optimierung, denn wir können nicht wählen, dass diese unterschiedlich sind. Die Möglichkeit, sie unterschiedlich zu wählen, ist der Kern unseres Optimierungsproblems.

Littlesches Gesetz

An dieser Stelle liefert Little's Law einige Beziehungen zwischen den Variablen M,_Mi, N,_wi, _xi, _μi, Î "_i. Diese Beziehungen können wir nutzen, um herauszufinden, welche Werte von_Mi die durchschnittlichen Gesamtbetriebskosten minimieren. Wie im vorigen Blog Little's Law in 3D beschrieben, liefert Little's Law Beziehungen für das System als Ganzes, für jeden Work Item-Typ und für jedes Teilsystem. Diese Beziehungen sind: 〈Ni〉= λ〈si〉 〈Ni〉 - 〈Mi} = λ〈wi〉 〈Mi〉 = μi 〈xi〉 M1 + M2 + ... = M Die letztgenannte Beziehung ist nicht aus dem Little'schen Gesetz abgeleitet, sondern besagt lediglich, dass die Gesamtkapazität der Mannschaft feststeht. Beachten Sie, dass das Little'sche Gesetz auch die obige Beziehung (1) liefert.

Ergebnis

Ohne auf die sehr interessanten Details der Berechnung einzugehen, werde ich nur das Ergebnis nennen und zeigen, wie Sie damit die Kapazitäten berechnen, die Sie bestimmten Workitem-Typen zuweisen können. Bestimmen Sie zunächst für jeden Workitem-Typ das Produkt aus der durchschnittlichen Inputrate (Î "_i) und der durchschnittlichen Lösungszeit (_xi). Dies ist die durchschnittliche Anzahl neuer Vorfälle, die eintreffen, während das Team an der Lösung eines Vorfalls arbeitet. Geben Sie das Ergebnis in einen Zeilenvektor ein und nennen Sie ihn 'V': (2) V = (λ1 x1, λ2 x2, ...) Als nächstes addieren Sie alle Komponenten dieses Vektors und bezeichnen ihn als ||V||. Zweitens multiplizieren Sie das Ergebnis des vorigen Schritts für jedes Element mit dem Quotienten aus der durchschnittlichen Lösungszeit (_xi) und dem Kostensatz (_Ci). Geben Sie das Ergebnis in einen Zeilenvektor ein und nennen Sie ihn 'W': (3) W = (λ1 x1 frac{x1}{C1}, λ2 x2 frac{x2}{C2}, ...) Addieren Sie wiederum alle Komponenten dieses Zeilenvektors und nennen Sie dies ||W||. Dann ist die Kapazität, ein Element des Typs 'k' zuzuweisen, proportional zu: (4) frac{Mk}{M} ∼ Wk - frac{1}{M} (Wk ||V|| - Vk ||W||) Hier bezeichnet Vk die k-te Komponente des Zeilenvektors 'V'. V1 ist also gleich λ1 x1. Gleiches gilt für Wk. Da sich diese Werte zu 1 addieren sollten, wird (4) durch die Summe aller dieser Werte dividiert.

Beispiel

Wenn Ihnen das kompliziert vorkommt, lassen Sie uns eine echte Berechnung durchführen und sehen, wie die Formeln des vorherigen Abschnitts angewendet werden. Zwei Arten von Vorfällen Nehmen wir als erstes Beispiel ein Team, das Daten zu allen Vorfällen und Arten von Arbeit sammelt. Die im Laufe der Zeit gesammelten Daten umfassen die Lösungszeit, das Datum, an dem der Vorfall auftrat, und das Datum, an dem das Problem behoben wurde. Der Product Owner weist jedem Vorfall einen Geschäftswert zu, der dem Kostensatz des Vorfalls entspricht, der in diesem Fall an der Anzahl der betroffenen (Geschäfts-)Anwendungen gemessen wird. Jede andere Art der Zuweisung eines Kostensatzes ist ebenfalls möglich.Das Team besteht aus 6 Teammitgliedern, so dass die Kapazität M des Teams 12 beträgt, wobei jedes Mitglied an maximal 2 Vorfällen arbeiten darf.Anhand der Daten stellen sie fest, dass es 2 Haupttypen von Vorfällen gibt. Siehe das sogenannte Zykluszeit-Histogramm unten.

Die obige Abbildung zeigt zwei Arten von Vorfällen mit typischen durchschnittlichen Lösungszeiten von etwa 2 Tagen und 2 Wochen. Die Analyse zeigt, dass diese mit der grafischen Benutzeroberfläche bzw. den Datenbankkomponenten zusammenhängen. Anhand der Daten stellt das Team fest, dass sie eine durchschnittliche Inputrate von 6 pro Woche bzw. 2 pro Monat haben. Der durchschnittliche Kostensatz für jeden Typ beträgt 10 pro Tag bzw. 200 pro Tag.Das heißt, die Datenbankprobleme haben: , , und die Lösungszeit . Während die GUI-bezogenen Probleme: λ = 6 per week = 6/5 per day, C = 10 per day, und die Lösungszeit x = 2 days. Der Zeilenvektor 'V' wird (Produkt aus Î" und x): V = (1/10 10, 6/5 2) = (1, 12/5), ||V|| = 1 + 12/5 = 17/5 Der Zeilenvektor 'W' wird: W = (1/10 10 10 / 200, 6/5 2 2 / 10) = (1/20, 12/25), ||W|| = 1/20 + 12/25 = 53/100 Daraus ergibt sich, dass ein Prozentsatz der Kapazität des Teams für die Lösung von Datenbankproblemen verwendet werden sollte, der dem entspricht: Mdatabase/M ∼ 1/20 - 1/12 (1/20 17/5 - 1 53/100) = 1/20 + 1/12 36/100 = 1/20 + 3/100 = 8/100 = 40/500 und ein gewisser Prozentsatz sollte für die Arbeit an GUI-bezogenen Elementen zugewiesen werden. MGUI/M ∼ 12/25 - 1/12 (12/25 17/5 - 12/5 53/100) = 12/25 - 1/12 9/125 = 12/25 - 3/500 = 237/500 Wenn wir diese beiden addieren, erhalten wir die Summe 277/500. Das bedeutet, dass wir 40/277 ~ 14% und 237/277 ~ 86% der Teamkapazität für Datenbank- bzw. GUI-Arbeitsaufgaben verwenden. Kanban-Teams können für jeden dieser Vorfallstypen eine Serviceklasse definieren und ein WiP-Limit für die datenbankbezogene Vorfallspur von 2 Karten und ein WiP-Limit von 10 für die Anzahl der Karten in der GUI-bezogenen Spur festlegen. Scrum-Teams können auf der Grundlage der oben berechneten Prozentsätze einen Teil der Teamgeschwindigkeit für User Stories zuweisen, die sich auf Datenbank- und GUI-bezogene Aufgaben beziehen.

Fazit

Ausgehend von dem Ausdruck für die durchschnittlichen Gesamtbetriebskosten habe ich gezeigt, dass dies zu einem interessanten Optimierungsproblem führt, bei dem wir die optimale Aufteilung der Kapazität eines Teams auf die verschiedenen Workitem-Typen so bestimmen müssen, dass die durchschnittlichen Gesamtbetriebskosten im System minimiert werden. Die Aufteilung der Kapazität des Teams auf die verschiedenen Workitem-Typen wird durch die durchschnittliche Inputrate, die Lösungszeit und den Kostensatz der Workitem-Typen bestimmt und ist proportional zu (4) Mk/M ∼ Wk - 1/M (Wk ||V|| - Vk ||W||) Die Daten, die für diese Berechnung benötigt werden, können von den Teams leicht gesammelt werden. Teams können ein Zykluszeit-Histogramm verwenden, um geeignete Workitem-Typen zu finden. Weitere Informationen finden Sie in diesem Artikel über Regelkarten.