So verwalten Sie das Board in Scrumban

Sowohl Scrum als auch Kanban haben gut definierte Prozesse und Einschränkungen.

ScrumBan ist jedoch nicht so klar definiert. Es ist, salopp gesagt, „etwas zwischen Scrum und Kanban“.

Wenn Sie ein mögliches Beispiel wollen, wäre ein Ansatz, dass es dasselbe wie Kanban ist, außer mit Sprints. Ganz links befindet sich die Spalte „Backlog“ und ganz links die Spalte „Zur Entwicklung ausgewählt“. Bei jedem Sprint wählst du X Storys aus und verschiebst sie von der ersten Spalte in die zweite.

Da das Mandat von Ihrem Unternehmen kommt, ist die beste Antwort natürlich, dass Sie sie fragen sollten, was sie wollen/erwarten.

FWIW, lassen Sie mich hier eine weitere Antwort hinzufügen.

Ich hätte die Frage etwas anders als Sarov beantwortet, indem ich gesagt hätte: "... ein Ansatz wäre, es wie Scrum zu haben, außer mit einem Visualisierungsboard im Kanban-Stil und Kanban-Konzepten von WIP-Limits und Pull."

Kanban ist keine Software oder Projektmanagementmethode an sich. Es ist eine Visualisierungs- und Verbesserungsmethode, die nur auf eine bestehende Methode angewendet werden kann, sei es Wasserfall oder Scrum oder andere, einschließlich Nicht-Software-, Nicht-IT-Prozesse. Sie könnten also sogar erwägen, Kanban einfach auf Ihren aktuellen Wasserfallprozess anzuwenden, um die Vorteile von Kanban zu nutzen.

Ich habe gerade auf eine ähnliche Frage geantwortet, also werde ich diesen Link hier posten - hoffentlich ist das mit den StackExchange-Kräften in Ordnung :)

https://pm.stackexchange.com/a/22628/8132

Nur um unsere eigene Geschichte mit Ihnen zu teilen – wir sind ein Softwarehaus, das jetzt Kanban für unsere gesamte Produktentwicklung verwendet. Wir waren früher ein „Wasserfall-Unternehmen“ – wir haben Scru nie eingeführt und sind direkt zu Kanban gewechselt.

Wir haben auch Änderungen an unseren Engineering-Praktiken vorgenommen, indem wir einen TDD-Ansatz für die Entwicklung und Testautomatisierung und jetzt zunehmend Continuous Integration/Continuous Deployment-Praktiken übernommen haben.

Wir haben 3-4 Jahre gebraucht, um uns weiterzuentwickeln - und unser Kanban-Board - das mehrere Überarbeitungen durchlaufen hat - sieht so aus -

Doch nachdem wir im Jahr 2009 zwei kleinere und eine größere Veröffentlichung im Jahr 2009 waren, sind wir jetzt eine Organisation, die „monatliche Veröffentlichungen wie ein Uhrwerk“ durchführt. Wir stellen sowohl auf SaaS als auch bei unseren On-Prem-Kunden bereit, sodass es möglich ist, beide zu unterstützen.

Wir haben erhebliche geschäftliche Vorteile erfahren, da unsere Kunden sehen, dass wir sehr auf ihre Bedürfnisse reagieren (aufgrund häufiger Veröffentlichungen auf der Grundlage von Kundenfeedback und -vorschlägen), unser CEO ist zufrieden, da wir regelmäßig liefern, so dass die Angst, „eine größere Veröffentlichung oder Veröffentlichung zu verpassen Datum" gibt es nicht mehr, und die Mitarbeiter sind glücklich, da niemand sie dazu drängt, zu viele Dinge gleichzeitig zu erledigen (Kanbans Fokus auf die Reduzierung von Multitasking) und sie für Schätzungen usw.

Ich bin mir nicht sicher, ob ich Ihren Eifer, Sprints zu haben, nicht nur aufgrund des Wunsches, häufiger an den Markt zu liefern, oder weil Sie auch Fehlerbehebungen richtig planen möchten, vollständig verstehe. Das IST jedoch eine wichtige Überlegung, ob Sie Sprints machen oder nicht.

Kanban hilft Ihnen, diese Realität widerzuspiegeln, mit der viele Softwareteams konfrontiert sind - sowohl an der "Wertanforderung" (neue Funktionen/Benutzergeschichten) als auch an der "Fehleranforderung" (Defekte) zu arbeiten, indem Sie sie entweder mit verschiedenen Farben oder in verschiedenen Swim-Lanes visualisieren ( wie Sie auf dem Bild oben sehen, obwohl wir Swim Lanes für verschiedene Produkte verwenden; für uns sind die Kartenfarben die Möglichkeit, zwischen Arbeitselementen verschiedener Typen zu unterscheiden). Das Interessante ist, dass, während unsere User Stories von einem vorgelagerten, separaten Kanban-Board stammen, das wir für unsere Roadmap-Planung verwenden (das ist also unser Rückstand), die Fehler (sowohl vom Kunden gemeldet als auch intern gefunden) direkt zur Spalte „Bereit“ hinzugefügt werden Schwimmspur und erhalten normalerweise eine höhere Priorität als alles andere. Sobald ein Entwickler frei ist, der an einem Fehler arbeiten kann,

Wir machen Releases ungefähr in einem monatlichen Rhythmus, aber wir haben auch eine „weiche“ Richtlinie, eine Release zu machen, wenn wir genug Wert getan haben und bereit für die Bereitstellung sind (z. B. 15-20 Benutzergeschichten und Fehlerbehebungen).

Zusätzlich zu den oben genannten grundlegenden Kanban-Tools befolgen wir auch gewissenhaft einige der Kanban-Praktiken – das zweiwöchentliche Replenishment-Meeting, um zu priorisieren, was als nächstes in unseren kommenden Veröffentlichungen passieren wird, und eine monatliche Retrospektive für gewonnene Erkenntnisse und ein vierteljährliches Strategieüberprüfungs-Meeting Stellen Sie sicher, dass alle Beteiligten mit dem, was das Produktteam tut, einverstanden sind. Natürlich ist das Daily Standup das grundlegende Meeting auf Teamebene.

Ich hoffe, das hilft - ich bin mir nicht sicher, ob Sie zu dieser Antwort aufgefordert werden, da Sie bereits eine andere Antwort als die richtige Antwort markiert haben :-) Sie können hier mehr über Scrumban lesen . Und bei Bedarf beantworte ich gerne Ihre Fragen rund um Ihren Übergang – viel Erfolg dabei!