Was bedeuten Spalten – Workflow oder Teammitglieder – in Kanban?

Nehmen wir an, wir haben ein Team, das aus einem Entwickler und einem Tester besteht. Und wir haben ein Kanban-Board, das aus den Spalten „Development(WIP=1)“, „Testing(WIP=1)“, „Done“ besteht.

Wenn der Entwickler eine Aufgabe implementiert hat, verschiebt er sie in die Spalte „Testen“.

Alles ist soweit in Ordnung.

Tester können aber auch neue Tests schreiben. Sollte er diese Aufgabe in die Spalte "Entwicklung" stellen?

Wenn ja , dann kann der Tester trotz WIP = 1 an zwei Aufgaben gleichzeitig arbeiten (eine Aufgabe in der Spalte „Entwicklung“ und eine Aufgabe in der Spalte „Testen“).

Wenn nein , dann stellt ein Kanban-Board die Aufteilung eines Teams in Entwickler, Tester usw. dar, aber nicht den Arbeitsablauf eines Teams .

Spalten stellen den Zustand dar , nicht Personen oder Ressourcen.

Antworten (2)

Ich denke, es ist einfacher, Ihre Frage zu beantworten, wenn wir einige der Themen trennen.

Erstens stellen die Spalten auf der Tafel den Arbeitsablauf der Elemente dar. Wenn also die Schritte zum Bereitstellen eines Artikels Entwicklung und Test sind, befindet sich ein Artikel in der Entwicklungsspalte in der Entwicklung und ein Artikel in der Testspalte wird derzeit getestet. Aus Sicht des Kanban-Boards ist es völlig irrelevant, welches Teammitglied die Arbeit erledigt.

Lassen Sie uns als Nächstes über WIP sprechen. Wenn der WIP für beide Spalten 1 ist, kann es in keiner Spalte mehr als eine Aufgabe geben. Dies ist vom Strömungsstandpunkt aus gut. Etwaige Engpässe oder Hindernisse werden sofort sichtbar. Andererseits ist es sehr unflexibel. Ein Dauertest würde das System sofort blockieren. Es gibt jedoch andere Möglichkeiten, WIP anzuwenden. Sie könnten beispielsweise einen WIP von 2 auf den gesamten Prozess anwenden, was Ihnen etwas mehr Flexibilität verleiht.

Schließlich erwähnen Sie, dass der Entwickler, wenn er mit der Entwicklung fertig ist, die Karte in die Testspalte legen würde. Das ist eine subtile Sache, aber das ist falsch. Die Karte bewegt sich, wenn die Arbeit am nächsten Schritt beginnt, nicht, wenn der aktuelle Schritt abgeschlossen ist. Es mag wie Semantik erscheinen, aber es führt zu sehr unterschiedlichen Teamverhalten.

Danke, aber warum ist das irrelevant? Nehmen wir an, dass beide WIPs gleich 2 sind. Nehmen wir weiter an, dass ein Entwickler an einer Aufgabe arbeitet und ein Tester einen neuen Test entwickelt und zwei implementierte Aufgaben testet – der Tester arbeitet an drei Aufgaben gleichzeitig. Es scheint nicht gut zu sein. Stattdessen scheint es sinnvoller zu sein, die Anzahl der Aufgaben zu begrenzen, an denen eine Person arbeitet.
Sorry für die Unklarheit. Es ist im Gesamtgespräch über Teamarbeit nicht irrelevant, aber Kanban verbietet es nicht ausdrücklich. Eines der Kernprinzipien von Kanban ist, dass Sie die Arbeit verwalten, nicht die Menschen. In Kanban haben WIP-Limits für die Arbeit also nichts damit zu tun, welche Personen diese Arbeit erledigen. Trotzdem ist es natürlich wichtig, dass das Team gesunde Gespräche über die Arbeit führt, und es wird erwartet, dass andere Teammitglieder darauf hinweisen, dass sie der Engpass sind, und um Hilfe bitten, wenn jemand viele Aufgaben unter einen Hut bringt.

WIP-Limits werden auf Aufgaben und nicht auf Personen angewendet.

Wenn Sie das Schreiben neuer Tests als Entwicklungsaktivität betrachten, würde dies zum WIP für den Entwicklungsstand beitragen.

Wenn Sie das Schreiben neuer Tests als Testaktivität betrachten, würde dies zum WIP für den Teststatus beitragen.

Es spielt keine Rolle, welche Fähigkeiten die Person hat (dh ob sie ein „Entwickler“ oder ein „Tester“ ist).

Wichtig dabei ist, dass es dem Team überlassen bleibt zu definieren, welche Aktivitäten welche Zustände im Workflow darstellen .

Ich dachte, Kanban zwingt uns, unsere aktuellen Aufgaben zu erledigen, bevor wir neue übernehmen. Es klingt also seltsam, dass WIP-Limits für Aufgaben und nicht für Personen gelten.
Ich denke, Sie kombinieren hier zwei verschiedene Konzepte. Das erste Konzept ist, dass, wenn jemand eine Aufgabe teilweise abgeschlossen hat, der Wechsel zu einer anderen Aufgabe mit Kosten verbunden ist. Wir nennen das Kontextwechsel und versuchen, es auf ein Minimum zu beschränken. Das zweite Konzept sind WIP-Limits, die auf Phasen eines Workflows angewendet werden. Die Idee mit WIP-Limits besteht darin, Engpässe zu vermeiden, da dies tendenziell den Gesamtdurchsatz abgeschlossener Arbeit verringert. Es liegt an dem Team, wie und wann es diese beiden Konzepte anwendet, um den Durchsatz zu maximieren.