Warum enthalten Kanban Boards nur eine Bereitstellung?

TL;DR

Es gibt hier keine richtige oder falsche Antwort in Bezug darauf, welche Aktivitäten, Spalten und Swimlanes zu einem bestimmten Kanban gehören. Es ist jedoch wahrscheinlich, dass Ihr Prozess von der Wahl eines Softwaretools bestimmt wird, anstatt die tatsächlichen Arbeitsabläufe und Arbeitsvereinbarungen in Ihrem Prozess widerzuspiegeln.

Sie sollten sorgfältig prüfen, ob Sie die richtigen Abstraktionen für Ihren Prozess erfasst haben. Sie sollten auch sicherstellen, dass Ihre Kanban-Warteschlangen effektiv den Ablauf und die kontinuierliche Verbesserung für jedes Team verfolgen und nicht die Arbeit, die von anderen Teams geleistet wird .

Analyse & Empfehlungen

Kanban basiert auf Warteschlangen und Abläufen, aber es basiert auf Ihren Warteschlangen und Abläufen. Es ist wohl ineffizient, Vor- und Nachwarteschlangen oder mehrere Zustandsübergänge für jede Aktivität zu haben, so dass viele erfahrene Praktiker sie weglassen, wenn sie keinen messbaren Mehrwert bringen.

Darüber hinaus tun dies viele Kanban-Anwender heute in einem agileren Kontext. Kanban-the-Framework (im Gegensatz zu verschiedenen Kanban-Praktiken, Artefakten und Methoden, die weiter verbreitet sind) ist oft eher auf Lean Manufacturing ausgerichtet als auf agile Frameworks für kleine Teams wie Scrum. Infolgedessen sind die Spalten eines einzelnen Boards im Allgemeinen auf Aktivitäten ausgerichtet, die direkt vom Team durchgeführt werden, anstatt alle möglichen Zustände zu halten, die dem internen Fluss des Teams fremd sind.

Wenn Ihr Team UAT, Staging und Produktionsbereitstellungen direkt handhabt, sollten Sie diese Abläufe auf jeden Fall in Ihrem Kanban widerspiegeln. Wenn es sich bei diesen Aktivitäten jedoch um Externalitäten handelt, die von anderen erledigt werden, sollte die Arbeit in das entsprechende Kanban (z. B. nicht Ihres) verschoben werden, wenn das Team damit fertig ist. In solchen Fällen ist es oft angemessener, die Arbeit vom Team als „erledigt“ zu markieren und dann kleinere Elemente, wie z um Arbeit zu verfolgen, die außerhalb des durch das Kanban des Teams repräsentierten Ablaufs ausgeführt wird.

Bei Kanban passt eine Größe definitiv nicht für alle. Ohne zu wissen, warum Sie die Abstraktionsebene für Ihre Workflows ausgewählt haben, und ohne alle Metriken zu verstehen, die Sie verfolgen, um festzustellen, ob diese Abstraktion für Sie nützlich ist oder nicht , macht es keinen Sinn, Ihre Abstraktionen damit zu vergleichen von jemand anderem.

Alle Modelle sind falsch; Es ist nur so, dass einige nützlich sind . Was Sie sich fragen müssen, ist, ob Ihr Modell nützlich ist. Wenn dies nicht der Fall ist, ist es sinnvoll, die Inspektions- und Anpassungsschleife Ihres Teams zu nutzen, wenn Sie sich auf Unwirtschaftlichkeiten zwischen Prozessen konzentrieren (anstatt alle Aktivitäten als intern zu behandeln, insbesondere wenn dies nicht der Fall ist).

Viele Unternehmen kümmern sich heutzutage nicht mehr um den Bereitstellungsschritt, weil er zu trivial ist . Mit dem Aufkommen von Continuous Delivery ist es für viele von uns nur noch ein Klick auf eine Schaltfläche.

Auch Just-in-Time (Kanban) impliziert, dass Sie Ihre Bestandskosten (unerledigte Arbeit) niedrig halten – so dass die Anzahl der Aufgaben, die auf die Freigabe warten, 1 (im besten Fall) oder mehrere davon ist – was nicht schwer zu verfolgen ist. Wenn Ihre Tester also mit dem Testen fertig sind, wissen sie, dass sie zwei Aufgaben freigeben müssen – sie fahren einfach fort und stellen sie auf PRD bereit. In einem solchen Schema gibt es keine "große Liste von Aufgaben, die zur Freigabe anstehen".

Wenn Ihr Prozess komplizierter ist (es gibt Aktivitäten nach Funktionstests), dann haben Sie wahrscheinlich eine Spalte für diese Aktivitäten und Tester verschieben die Aufgabe in diese Spalte. Auch hier ist die Bereitstellung in der jeweiligen Umgebung nur ein Klick auf eine Schaltfläche, sodass selten eine zusätzliche Spalte erforderlich ist.