Ich nutze Kanban für den Gründungsprozess eines Unternehmens. Es kann etwas falsch sein, da ich sowohl der Product Owner als auch das Entwicklungsteam bin. Aber ich denke es funktioniert, die User Stories werden gut. Aber als Product Owner (Eigentümer des Unternehmens) muss ich verschiedene Dinge tun, die nicht in das Format der User Story passen. Ist das „Task“-Konzept für neue Issues nur vom Entwicklungsteam zu erstellen? Oder kann ich als Product Owner auch Aufgaben hinzufügen, die ich als Product Owner erledigen kann?
Wie mache ich das richtig? Muss ich ein anderes Projekt, Board, ... erstellen?
Als ich in meinem vorherigen Unternehmen Kanban machte, konnte jeder eine Aufgabe, eine Story oder ein Epic auf unserem Board erstellen. Allerdings kann nur der PO Prioritäten setzen.
In meinem aktuellen Scrum-Unternehmen erstellt nur der PO Epics und Features und erstellt normalerweise die User Storys. Das Dev-Team erstellt Aufgaben und einige "technische" User Stories.
Ist das „Task“-Konzept für neue Issues nur vom Entwicklungsteam zu erstellen? Oder kann ich als Product Owner auch Aufgaben hinzufügen, die ich als Product Owner erledigen kann?
In beiden Situationen war es für einen Product Owner immer möglich, Aufgaben zu erstellen, die er selbst erledigen sollte. Möglicherweise stellen Sie in Ihrem Kanban-Board fest, dass die PO-Aufgaben nicht demselben Prozess folgen wie die Entwicklungsaufgaben. dh PO-Tasks können einen Pfad von haben
Zu erledigen ___ In Bearbeitung ___ Überprüft ___ Erledigt
Wobei die Dev-Aufgaben eher ähnlich sein können
Rückstand ___ Überprüfung ___ Entwicklung ___ Komponententest ___ Systemtest ___ Installation auf Prod ___ Geschlossen
Wenn dies Ihr Fall ist, ist ein zweites Board zur Darstellung des zweiten Prozesses der richtige Weg. Wenn der Prozess derselbe ist, dann ist das gleiche Board in Ordnung.
Es können auch verschiedenfarbige Karten verwendet werden, um die Aufgaben zu visualisieren, die für die verschiedenen Rollen gelten, wenn Sie möchten.
Grüße
Tolle Frage. Die Begriffe Backlog Item (PBI), User Story und Task werden oft unterschiedlich verwendet und das kann verwirrend sein.
Die einfache Antwort auf Ihre Frage lautet, dass Sie auf einem Kanban-Board (insbesondere außerhalb von Scrum) normalerweise eine Elementebene haben, die User Storys, Aufgaben, Tickets, Anfragen oder was auch immer Ihr Team benötigt, sein kann. Wenn Sie diese Dinge also auf „Aufgaben“ verallgemeinern möchten, anstatt zu versuchen, Benutzergeschichten zu verwenden, ist daran nichts auszusetzen. Sie können sogar eine Mischung aus verschiedenen Arten von Gegenständen verwenden – sie befinden sich einfach alle auf derselben Ebene.
Mit der einfachen Antwort aus dem Weg, hier ist etwas mehr Komplexität:
In Scrum sehen wir üblicherweise zwei Ebenen auf dem Board: Backlog Items und Tasks. Der Grund dafür ist, dass es uns ermöglicht, zwischen dem wertschöpfenden Element (dem Backlog-Element – oft eine User Story) und der diskreten kleinen Sache zu unterscheiden, die nur ein Schritt zur Lieferung des größeren Elements ist. Denn in Scrum wollen wir das Board für das Team nutzen, um seine Arbeit (Aufgaben) zu organisieren, aber auch im Auge behalten, wie das Team Fortschritte macht, um dem Produkt wertvolle Funktionen hinzuzufügen und das Sprint-Ziel (PBI) zu erreichen.
Bei einem reinen Kanban-Board mache ich mir nur Sorgen um den Arbeitsfluss, daher gibt es normalerweise nicht mehrere Ebenen von Aufgaben. In den meisten Fällen ist alles in einem Kanban-Board wertschöpfend und die Schritte zur Bereitstellung kommen in den Spalten des Boards heraus.
Anforderungen an das Schreiben: Benutzergeschichten stellen „Wünsche“ auf außergewöhnlich hohem Niveau dar, die aus der Sicht der Endbenutzer geschrieben wurden, um den geschäftlichen Wert im Gegensatz zu technischen Details hervorzuheben. Geschichten werden verfeinert, wenn das nächste Sprint-Planungsmeeting näher rückt. Schließlich zerlegt das Entwicklerteam die Geschichten, indem es granulare Aufgaben hinzufügt. Denken Sie daran, dass es auch andere Formate wie User Journeys, Use Cases und so weiter gibt. User Stories funktionieren zum Beispiel nicht gut mit nicht-funktionalen Anforderungen. Warum sich und Ihr Team also mit User Stories einschränken? Allerdings sollten die meisten Ihrer Backlog-Elemente im Story-Format geschrieben werden, es sei denn, Sie arbeiten an einem Produkt, das nicht viel mit Benutzern interagiert.
Wer macht was: Der Product Owner sollte die User Stories auf hohem Niveau schreiben. Das Entwicklerteam fügte dann während der Backlog-Refinement-Sitzungen und der Sprint-Planung die erforderlichen Aufgaben hinzu, um die User Story fertigzustellen. Dies ist die natürliche Arbeitsteilung, aber keine strikte Regel. Da Sie auch Entwickler sind, hindert Sie nichts daran, Aufgaben zu schreiben. Ähnlich,
Ein Hinweis zu Kanban und Scrum: Unabhängig davon, ob Sie ein Online-Tool oder ein Board mit Haftnotizen verwenden, ist es sehr sinnvoll, verschiedene Arten von Aufgaben zu unterscheiden. Wenn Ihr Tool Aufgabentypen oder das Hinzufügen von Unteraufgaben nicht unterstützt, verwenden Sie eine Beschriftung oder Farbcodierung. Selbst die einfachsten/kostenlosen Tools wie Trello bieten diese Funktion. Ihre Storys wären also gelb und alle ihre Unteraufgaben orange. Andere Farben repräsentieren andere Dinge. Das geht auch ganz einfach mit Haftnotizen, die es in verschiedenen Formen und Farben gibt :).
Das kann das Team gemeinsam entscheiden. Finden Sie die verschiedenen Arten von Arbeiten heraus (neue Story, Fehlerbehebung, Ops-Änderungen usw.) und einigen Sie sich darauf, wie und von wem neue Arbeiten in jeder Kategorie in den Stream eingeführt werden.
Ich vermute, Sie werden den größten Wert darin finden, die gesamte Arbeit für ein bestimmtes Produkt auf demselben Board zu halten. Das Trennen von Arbeitsarten führt zu voreingenommenen Unteransichten; Sie möchten das ganze Bild visualisieren.
Andreas
Andreas
Andreas
Daniel