Gibt es einen Prozess, der die anfänglichen WIP-Zahlenentscheidungen für Kanban-Board-Spalten leitet, abgesehen davon, dass Sie eine grobe Zahl auswählen und sehen, wie sie funktioniert?
Zweitens, welche Metrik(en) überwachen Sie, um festzustellen, ob WIP-Limits zu hoch oder zu niedrig eingestellt sind? Wenn sich beispielsweise die Anzahl der Personen in einem Team ändert, müssen die WIP-Zahlen möglicherweise angepasst werden, um die Änderung im Team widerzuspiegeln. Oder ... könnte ein Team seinen WIP zu hoch ansetzen, nur um das Limit nicht zu überschreiten ... Gibt es also Metriken, die überwacht werden können, um festzustellen, ob der WIP eines Teams korrekt ist?
Nach meinem besten Wissen gibt es keine kanonische Formel zur Bestimmung der Work-in-Progress (WIP)-Limits. Es gibt jedoch einige empirische Best Practices.
Die Ziele von WIP-Limits sind im Allgemeinen:
Wie man WIP-Grenzwerte optimiert, hängt stark von einer Reihe von Faktoren und einer Vielzahl von Prozessanalysen vor Ort ab . Eine gute Faustregel ist jedoch, WIP auf die Monotasking-Kapazität des Teams zu beschränken. Mit anderen Worten, Ihr grundlegendes WIP-Limit sollte die Anzahl der Aufgaben sein, die gleichzeitig ohne Leerlauf ausgeführt werden können.
Wenn Sie beispielsweise sechs Teammitglieder haben, deren Verantwortlichkeiten sich nicht überschneiden, sollte Ihr WIP-Limit 6 über alle Spalten im Kanban nicht überschreiten, da dies die maximale Anzahl von Aufgaben ist, an denen gleichzeitig ohne Aufgabenwechsel oder Multi gearbeitet werden kann -Aufgabe. Darüber hinaus können bestimmte Spalten WIP-Limits für diese Spalte als Teilmenge des Limits für das Kanban als Ganzes weiter einschränken.
Aus praktischen Gründen sollten funktionsübergreifende Teams, Teams, die Paarprogrammierung praktizieren, und Frameworks, die das „Schwärmen“ des Teams über Stories fördern, ihre WIP-Limits jedoch entsprechend senken. Beispielsweise würde ein WIP von N-1 (wobei N die Anzahl der Teammitglieder ist) mehr Flexibilität bei der Koordination von Storys innerhalb einer Iteration ermöglichen, während ein WIP von N/2 für ein Team optimal sein könnte, das für Pair Programming optimiert ist .
Unabhängig von der tatsächlichen numerischen Grenze ist es wichtig, den „Irrtum der 100-prozentigen Auslastung“ zu vermeiden und sicherzustellen, dass der Prozess über genügend Spielraum verfügt, um einen konstanten Durchsatz im Laufe der Zeit zu gewährleisten. Das bedeutet, dass Sie im Allgemeinen einen Fudge-Faktor anwenden möchten, um Ihre WIP-Limits zu senken, aber die Besonderheiten variieren von Projekt zu Projekt.
Vielleicht entgegen der Intuition wird das Reduzieren der WIP-Limits unter die maximale Kapazität des Teams Ihren Durchsatz im Allgemeinen verbessern. Dies liegt meistens daran, dass bei einer Kapazität von 100 % Hindernisse oder unerwartete Probleme zu Engpässen führen können, die sich auf den gesamten Pull-Warteschlangenzyklus auswirken. Indem sichergestellt wird, dass im Prozess ausreichend Spielraum vorhanden ist, kann das Team kleinere Prozessprobleme lösen, sobald sie auftreten, ohne dass die Linie vollständig angehalten werden muss. Diese Fähigkeit, sich anzupassen, ohne jedes Mal die Linie anzuhalten, ist Teil dessen, was einen Prozess agil macht.
Kanban ist ein Pull-Queue-System. Jede Spalte ist im Wesentlichen eine separate Warteschlange, in die Arbeit aus der vorherigen Spalte gezogen wird, wenn das WIP-Limit dies zulässt.
Wenn beispielsweise zwei Ihrer Spalten „Codierung“ und „Regressionstest“ sind, würde man fertige Storys aus der Spalte „Codierung“ ziehen, wenn die Spalte „Regressionstest“ ihre Kapazität unterschritten hätte.
Als weiteres Beispiel: Wenn Ihr Kanban-WIP-Limit 6 beträgt, Sie aber nur eine Person für Regressionstests haben, dann sollte Ihr WIP-Limit für die Regressionstest-Spalte höchstwahrscheinlich 1 sein; nicht unbedingt ein Test, sondern eine einzige Geschichte.
Ausnahmen gibt es immer. Wenn Regressionstests halbautomatisch sind und sechs Jobs parallel ohne Multitasking durch die für die Spalte verantwortlichen menschlichen Agenten ausgeführt werden können, können Sie das WIP-Limit für diese Spalte auf sechs festlegen. Das optimale WIP-Limit für jede Warteschlange ist definitiv ein Problem der Überprüfung und Anpassung, das vom Team konsequent überprüft und im Laufe der Zeit bei Bedarf angepasst werden muss.
Letztendlich ist die Methodik zur Optimierung der WIP-Grenzwerte für Spalten dieselbe wie die Optimierung für das Board als Ganzes: Ihr WIP-Grenzwert für eine Spalte darf ihre Monotasking-Kapazität nicht überschreiten und sollte niedrig genug sein, um für ausreichend Spielraum im Prozess zu sorgen Produktionsstillstand bei kleineren Problemen verhindern.
Die kurze Antwort ist nein, es gibt keine feste Regel. In der Tat, der einzige Artikel, den ich gelesen habe, der eine vorgeschlagene Anfangszahl anbot, sagte, dass er mit 2 Geschichten pro Teammitglied als WIP-Limit beginnen sollte. Das ist wahrscheinlich fair.
Was Metriken betrifft, ist es wahrscheinlich am besten, kumulative Flussdiagramme zu verwenden. Dies ist ein wirklich guter Artikel darüber:
http://brodzinski.com/2013/07/cumulative-flow-diagram.html
und das kann Ihnen zeigen, ob Sie irgendwelche Bereiche des Entwicklungsprozesses straffen müssen.
Danach hat mir die Idee immer gefallen, bei Stand-ups von rechts nach links auf dem Brett zu arbeiten. Stellen Sie sicher, dass jemand, der in der Lage ist, Aufgaben beispielsweise in einem Test voranzutreiben, keine neuen Geschichten auf der linken Seite einbringt. Diese Vorgehensweise kann den Betrag reduzieren, den Sie zur Durchsetzung des WIP-Limits benötigen. Im Idealfall konzentrieren Sie sich darauf, den Workflow reibungslos aufrechtzuerhalten, und das WIP-Limit wird nie erreicht.
Denken Sie daran, dass eines der Kanban-Prinzipien lautet : „Starte dort, wo du bist“ . Eine gute Möglichkeit, die anfänglichen WIP-Limits zu bestimmen, besteht also darin, einfach zu zählen, wie viele Tickets sich derzeit in der Spalte befinden oder wie viele Sie normalerweise bei Ihrem aktuellen Prozess erwarten würden . Dann reagieren Sie auf das, was passiert.
Denken Sie dann daran, dass die beiden Hauptfunktionen von WIP-Limits darin bestehen , Flow zu erzeugen und Kaizen-Ereignisse zu erzeugen . Das heißt, wenn Sie Ihre WIP-Grenzen nie überschreiten oder wenn sie Sie nie dazu zwingen, darüber zu diskutieren, wie Sie anders arbeiten können, damit sie funktionieren, sind die Grenzen wahrscheinlich zu hoch. Wenn sie Sie ständig dazu zwingen, Ihre Arbeit zu verschieben und dadurch den Arbeitsfluss zu verringern, ohne zu einer Prozessverbesserung zu führen, sind sie möglicherweise zu niedrig (oder Sie müssen Ihren Prozess verbessern).
Optimale WIP sind Grenzen, die stark von der Größe Ihres Teams abhängen. Niedrigere WIP-Limits weisen auf kürzere Vorlaufzeiten hin, aber wenn Sie die WIP-Limits zu niedrig einstellen, verlängert sich Ihre Gesamtprojektdauer. Wenn Sie die WIP-Limits zu hoch ansetzen, entstehen Engpässe.
Ich habe ein kleines Simulationstool erstellt, in dem Sie mit Wip-Limit, Teamgröße, Schwimmbahnen usw. spielen können. Das Tool ist Open Source und kostenlos.
Strahl