Was sind die Artefakte in Kanban?

Meine Antwort lautet: Es gibt keine vordefinierten Artefakte in Kanban .

Scrum hat vordefinierte Rollen, Ereignisse und Artefakte, Kanban jedoch nicht. Kanban beschreibt nur 4 Prinzipien und 5 Praktiken:

1. Beginnen Sie mit dem bestehenden Prozess;
2. Stimmen Sie zu, inkrementelle, evolutionäre Veränderungen anzustreben;
3. Respektieren Sie den aktuellen Prozess, Rollen, Verantwortlichkeiten und Titel;
4. Ermutigen Sie Führungsakte auf allen Ebenen;

---

1. Visualisieren Sie den Arbeitsablauf;
2. Work-in-Progress begrenzen;
3. Arbeitsabläufe überwachen, messen und optimieren;
4. Machen Sie Prozessrichtlinien explizit;
5. Gemeinsam verbessern.

(Sie können zum Beispiel hier mehr lesen ).

aber nichts über Rollen, Ereignisse oder Artefakte.

PS Wie ich in einem Kommentar geschrieben hatte , ist ein Burn-Down-Diagramm kein Scrum-Artefakt. Sie können ein Burn-Down-Diagramm innerhalb von Scrum verwenden, es ist jedoch kein Teil von Scrum.

Scrum-Artefakte: Burn-Down-Diagramme sind nicht vorgeschrieben

Bevor Sie Ihre Frage beantworten, sollten Sie beachten, dass Burndown-Diagramme keine erforderlichen Artefakte in Scrum sind. Während die Verwendung solcher Diagramme weit verbreitet ist, erfordert das Framework selbst sie nicht. Sie sind daher zusätzliche Artefakte, die von bestimmten Implementierungen generiert werden, und keine Artefakte, die direkt vom Scrum-Framework generiert werden.

Kanban-Artefakte

Per Definition hat ein Kanban -System nur zwei definierte Artefakte:

1. Das Kanban selbst, das ist das Board, an das jeder denkt, wenn es um die Kanban-Methodik geht.
2. Die Kanban-Karten, die sich auf dem Brett bewegen.

Die Implementierung der Kanban-Methode führt jedoch im Allgemeinen zu einer Vielzahl zusätzlicher Artefakte, darunter Backlogs, Karten, Richtlinien, Diagramme und Berichte . Obwohl keines dieser Artefakte ausdrücklich vom Framework gefordert wird, ist es schwer vorstellbar, dass eine effektive Kanban-Implementierung nicht zumindest einige Metriken und Grafiken generiert, um die Zykluszeit, die Durchlaufzeit und andere wichtige Leistungsindikatoren zu überprüfen, um den Zustand des Kanban zu überwachen Projekt oder Prozess.

NB: Die Methode von David J. Anderson erfordert, dass Sie Ihren Workflow visualisieren, schreibt aber nicht die Implementierung eines Kanban-Systems mit Boards und Karten vor. Der Mechanismus (und damit die Artefakte) zur Visualisierung bleibt der Implementierung überlassen.

Zusammenfassend lässt sich sagen, dass alles, was während der Implementierung des Kanban-Systems oder der Kanban-Methode generiert wird, ein Artefakt ist. Das typische System erfordert nur das Brett und die Karten, während das Verfahren nur ein Mittel erfordert, um die Arbeit visuell darzustellen. Alles andere ist Übung oder Nebeneffekt.

Anstatt zu wiederholen, was andere bisher beigetragen haben (und ich stimme der Vorstellung zu, dass alles, was während der Implementierung/Anwendung von Kanban generiert wird, ein Artefakt von CodeGenome ist ), möchte ich das Konzept der Theory of Constraints hervorheben , das über die allgemeine Verwendung von hinausgeht Kanban von der Visualisierung des Flusses bis zur Ausnutzung von Engpässen, was zu einer Steigerung des Durchsatzes (oder "der Produktionsrate oder des Inkrements") führt.

Bei richtiger Konfiguration wird Engpass zum Artefakt des verwendeten Systems (Anmerkung: Artefakt könnte auch "das nicht wahre Merkmal des beobachteten Objekts als Ergebnis externer Einwirkungen" bedeuten). Um den Engpass aufzudecken, muss man das bestehende System überprüfen (z. B. Zykluszeit, WIP usw., hier spielt Gemba Walk eine sehr große Rolle), den Fokus auf den Engpass legen, ihn ausreizen und kontinuierlich verbessern, bis er nicht mehr begrenzt der Durchsatz des Systems.

Der Durchsatz des Systems und die Prozessqualität sind ebenso wichtig wie der Output Ihrer Arbeit und deren Qualität. Ich empfehle Ihnen, Kapitel 7 von Kanban in Aktion von Marcus Hammarberg und Joakim Sundén zu lesen.