Ich habe Scrumban erfolgreich implementiert. Ich setze das Daily Scrum Meeting und die Retrospektive um. Ich finde es toll, wie einfach das Kanban-Board ist, dass es dem gesamten Team hilft, zu wissen, wo wir uns gerade befinden, und auch zu wissen, wie weit wir sind, bevor wir den Meilenstein erreichen.
Es gibt etwas, das mich fragen lässt, ob ich ein Ticket habe, das aus einer Spalte namens „Backlog“ stammt und es in die Spalte „Doing“ gesteckt hat, nachdem mein Team bereits daran gearbeitet hat.
Verschieben sie das Ticket direkt von „Doing“ auf „Done“? Oder wir als Team tun es während des täglichen Stand-up-Meetings? Dann werden wir von dort aus alle Tickets verschieben?
Einige Scrum-Teams haben zwischen „Doing“ und „Done“ eine Spalte „Bereit zur Diskussion“. Sie legen fertige Karten in diese Spalte, besprechen sie während des täglichen Treffens, und wenn die Diskussion beendet ist, verschieben sie sie auf erledigt. Ich glaube, diese Art von Kolumne kann Ihnen helfen.
Wenn Sie keine neue Spalte einführen möchten, vergrößern Sie die „Doing“-Spalte und platzieren Sie die laufenden Arbeitselemente auf der linken Seite der Spalte und die fertigen Elemente auf der rechten Seite. Hier können Sie mehr darüber lesen .
Ich würde das Team tun lassen, was für sie bequem ist, und sie dann während der Retrospektive herausfordern und danach fragen. Die Retrospektive ist der perfekte Ort, um dem Team zu helfen, seine aktuellen Praktiken und mögliche Verbesserungen zu bewerten.
Für mich hört es sich so an, als ob das eigentliche Problem hier lautet: "Warum arbeiten und beenden wir Probleme, die nicht in unserer Doing-Kolumne stehen?" Kanban und Scrum funktionieren beide nur, wenn ihre Boards/Karten/Probleme/was auch immer korrekt und sichtbar sind. Als Scrum Master liegt unsere Stärke darin, Situationen zu beleuchten. Wenn das Team dieses Licht umgeht, können Sie ihm nicht helfen, sich an die geltenden Regeln zu halten.
Ich würde empfehlen, die Story in „doing“ als „ready to pull“ zu markieren, vorausgesetzt, dass das Verschieben der Karte auf „done“ bedeutet, dass Teile der Story die Team-Definition of Done oder Akzeptanzkriterien erfüllen. Viele Kanban-Teams haben eine Pull-Spalte oder -Unterspalte, um Arbeit anzuzeigen, die erledigt ist, aber noch nicht in den nächsten aktiven Status gezogen wurde. Dies kann einen Puffer schaffen und auch eine gewisse zusätzliche Granularität bieten, wenn Engpässe zwischen aktiven Zuständen auftreten.
Die Person oder Personen, die die Geschichte zu Ende bringen, validieren dann, dass die Karte "erledigt" ist, im Gegensatz zu der Person / den Personen, die die Karte geliefert haben und sagen, dass sie fertig ist.
Dies erzwingt eine Feedback-Schleife zwischen den Personen, die die Arbeit liefern, und denen, die sie konsumieren, um sicherzustellen, dass alle auf derselben Seite sind. Wenn die Produzenten die Verbraucher sind, kann es vorteilhaft sein, während des Aufstehens Karten vor dem gesamten Team zu ziehen, um sicherzustellen, dass das Team ausgerichtet ist.
Wie die vorherigen Antworten gesagt haben, sollte die Geschichte nicht von Doing zu Done übergehen, bis Sie zufrieden sind, dass sie Ihre gewonnene DOD , dh Definition of Done, erfüllt hat.
Als Beispiel dafür ist hier unser aktuelles DOD aus einem unserer Projekte. Sie können Ihren eigenen erstellen und so wenig oder so viel hinzufügen, wie Sie möchten, aber es ist hilfreich, eine vereinbarte Definition zu haben, damit jeder am Projekt weiß, in welchem Zustand der Code vor der Veröffentlichung erwartet wird.
Im wahren Sinne von Kanban, angewendet auf Scrum, würde ich sagen, Sie sollten -
Was für das Team und die Stakeholder, für die das Team arbeitet, sinnvoll ist, sollte Ihnen bei der Entscheidung helfen, wie die Arbeit auf dem Kanban-Board verwaltet werden soll. Schauen Stakeholder beispielsweise tagsüber auf die Tafel und fragen sich: „Ist meine Arbeit erledigt?“? Wenn ja, ist es vielleicht sinnvoll, dass das Teammitglied das Ticket auf „Fertig“ setzt, sobald es damit fertig ist. Während des Standups am nächsten Morgen kann das Teammitglied einfach ein Update dazu geben - oder was auch immer sie sonst noch tun müssen.
Warten andererseits die Teammitglieder oder die Stakeholder auf das Ergebnis des Standups, um ihre Updates zu erhalten? Wenn ja, (fahren Sie mit der Übung fort und) aktualisieren Sie den Kartenstatus während des Aufstehens.
Ist es wichtig, eine genaue Messung Ihrer Zykluszeit zu erhalten? Wenn ja, ist es vielleicht am besten, das Ticket in dem Moment, in dem es fertig ist, in die Spalte „Fertig“ zu verschieben, anstatt es über Nacht in der Spalte „In Bearbeitung“ warten zu lassen. Abhängig von der Art Ihrer Arbeit können Tickets in eine „Kundenakzeptanz“-Spalte oder eine Staging/Demo-Spalte verschoben werden, wo dem Kunden/Produkteigentümer eine Demo gegeben werden kann.
Vor einiger Zeit hatte ich einen Blogbeitrag zu einem verwandten Thema geschrieben – „ Spiegelt Ihr Kanban-Board den Prozess wider, den Sie tatsächlich haben? “ Vielleicht finden Sie ihn interessant.
Letztendlich hängt es wirklich nur von Ihren Prozessen ab und davon, was Sie messen und verbessern möchten.