Wann bespricht das Team die Anforderungen bei der Verwendung von Kanban?

Ich habe ein bisschen über Kanban gelesen und bin etwas verwirrt über das Thema Anforderungen.

In meinem aktuellen Projekt verwenden wir Scrum. Zu Beginn eines Sprints haben wir eine Sitzung, in der die BA einen Durchgang durch die Geschichte macht und sie so gut wie möglich beschreibt. Wir nehmen dann die Geschichte, überprüfen sie, diskutieren sie und bereiten Fragen an die BA für die nächste Sprint-Planungssitzung vor. In der nächsten Sitzung beantwortet der BA alle Fragen und die Sitzung endet damit, dass wir die Anforderungen verstanden haben (meistens).

Der nächste Schritt ist, dass wir dann ein technisches Design erstellen und die Lösung / Story entwickeln.

Mit Kanban deutet alles, was ich lese, darauf hin, dass es in Kanban keine Sprint-Planung gibt. Meine Frage ist, an welchem ​​Punkt (in Kanban) setzen sich die Technikfreaks und die Geschäftsleute zusammen, um die Anforderungen für die Geschichte zu besprechen? Bietet der Produktmanager oder BA nicht eine exemplarische Vorgehensweise für die Story in Kanban?

Mit Scrum ist der BA normalerweise während des gesamten Sprints verfügbar, um die Entwicklung zu unterstützen, und ich gehe davon aus, dass dies auch mit Kanban der Fall ist. Mir ist jedoch nicht klar, wie die Technikfreaks mit Kanban die Geschichte verstehen, wenn es keine Sprintplanung gibt.

Sie haben Recht, dass Kanban nicht das Konzept von Sprints oder Sprint Planning wie Scrum hat. Das liegt daran, dass es eine schlankere Methode ist . Weitere Dinge werden just in time erledigt .

Es liegt an Ihnen, zu entscheiden, wie Sie Planungsaktivitäten planen, aber ich würde empfehlen, diese so kurz wie möglich vor Arbeitsbeginn durchzuführen. Dies ist am effektivsten, wenn Vertreter aller wichtigen Stakeholder im Team eingebettet sind (dies macht Scrum auch effektiver).

Ich denke, dass dieses Diagramm, das auf Disciplined Agile Delivery basiert , eine gute bildliche Darstellung eines schlanken Softwareprozesses bietet:

Die Ereignisse der täglichen Standup- und Sprint-Planung werden während der Koordinierungssitzung und der Nachschubmodellierungssitzung erfasst. Das Koordinierungsmeeting ähnelt eher einem täglichen Standup von Scrum und eine Nachschubmodellierungssitzung ähnelt eher der Verfeinerung des Rückstands und der Sprintplanung. Es ist jedoch in Ordnung, einige Anforderungsdiskussionen in das Koordinierungsmeeting einzubeziehen, wenn dies für Ihr Team funktioniert.

Wie die meisten Dinge in einem schlanken Prozess geschieht dies just in time. Es gibt keine Zeitfenster und Ereignisse treten nicht in einer bestimmten Trittfrequenz auf, wie dies in Scrum der Fall ist. Sie erledigen die Arbeit, wenn sie den Wert für das Team und die Stakeholder erhöht.

Was Sie mit einer bildlichen Darstellung eines Prozesses vergleichen können, der auf Scrum basiert und im Kontext von Disciplined Agile Delivery modelliert wurde:

Anstatt sich auf Sprints von 2 bis 4 Wochen mit Planung zu Beginn, täglichen Stand-Ups und einer Überprüfung und Rückschau am Ende zu beschränken, werden schlankere Methoden Ihre Demonstrations-, Koordinierungs- und Rückblick-Meetings durchführen, wenn die Stakeholder dies für angemessen halten .

Kanban bietet Anleitungen für die Verwaltung Ihres Arbeits- und Arbeitsrückstands (WIP). Sie können sich für die genaue Implementierung anderer Aktivitäten anderen Techniken und Methoden zuwenden, da Kanban diese im Allgemeinen nicht erwähnt.

Sie stellen leicht falsch dar / verstehen falsch, was das Sprint Planning-Meeting in Scrum tut, was meiner Meinung nach die Ursache für Ihre Verwirrung ist. Ein Sprint-Planungsmeeting ist normalerweise der falsche Ort, um die Details von Geschichten zu erarbeiten. Abgesehen von einigen abschließenden Änderungen und einem kurzen Durchlauf, um sicherzustellen, dass keine offenen Bedenken bestehen, die die Schätzungen erheblich beeinflussen könnten, sollten die berücksichtigten Geschichten größtenteils einsatzbereit sein. Von dort aus macht die Sprint-Planung das, was sie verspricht: Sie plant, was im kommenden Sprint passieren wird. Wenn Sie keine Sprints haben, ist keine Sprint-Planung erforderlich.

Wann werden die Details der Geschichten konkretisiert? In der Regel über Backlog Grooming oder in der laufenden Kommunikation während früherer Sprints. Ziel ist es, genügend Klarheit zu schaffen, damit eine einigermaßen sichere Schätzung abgegeben werden kann. Dies erfordert nicht, dass jedes Detail im Voraus ausgearbeitet wird. Egal wie viel Sie versuchen, es werden immer Fragen auftauchen, die während der Implementierung auftauchen. Das Ziel in Scrum ist, dass die Fragen, die während der Implementierung auftauchen, relativ gering sind (im Wesentlichen so klein, dass sie keinen Einfluss auf die Schätzung haben).

In Kanban ist die Schätzung optional. Wenn Sie eine Schätzung vornehmen, werden Sie wahrscheinlich etwas Ähnliches wie Scrum in dem Sinne tun, dass vor der Aufnahme der Geschichte eine Schätzung erarbeitet wird. Wenn Sie keine Schätzung vornehmen, ist das tatsächliche Verhalten ähnlich, außer dass Sie eine Geschichte möglicherweise erst diskutieren, wenn sie gestartet wurde.

Nach meiner Erfahrung habe ich in der Regel in Teams gearbeitet, die für die Hauptentwicklung einen Scrum-ähnlichen Ansatz verwendet und dann für die Wartungsphase auf einen eher kanbanischen Ansatz umgestellt haben. Die Arbeiten in der Wartungsphase sind eher sporadisch und die Geschichten von Anfang an klarer und kleiner definiert. In der Hauptentwicklungsphase beginnen Geschichten oft auf hohem Niveau und müssen verfeinert und aufgeschlüsselt werden, um einen Punkt zu erreichen, an dem sie für einen Sprint akzeptabel wären. Das Starten solcher Geschichten in einem Kanban-Kontext macht wenig Sinn und würde Ihre Metriken absolut versenken.

Weder in Scrum noch in Kanban gibt es eine offizielle Rolle als "Business Analyst". Es ist das Team , das Geschichten analysiert und schätzt. Wenn Sprint Planning das Entwicklungsteam zum ersten Mal die Details der Storys hört, läuft etwas schief. Ich sage nicht, dass Sie keinen BA verwenden können oder dass jeder Entwickler an jedem Treffen zur Erfassung von Anforderungen teilnehmen muss, aber einigeDie Darstellung der Entwickler sollte irgendwann während der Anforderungserfassung vor der Sprint-Planung erfolgen. Ein BA ist normalerweise nicht gut genug über die Details der Implementierung informiert, um die Kosten der Dinge zu kennen oder welche Fragen einen signifikanten Einfluss auf die Kosten haben könnten. Dies bedeutet, dass es Details geben kann, die sich drastisch auf die Schätzungen auswirken können, die erst erkannt werden, wenn das Entwicklungsteam sie sieht. Darüber hinaus können die Entwickler möglicherweise Anleitungen zu kostengünstigeren Ansätzen geben oder Funktionen vorschlagen, die relativ einfach zu implementieren sind, aber für den Benutzer einen großen Mehrwert darstellen. Was ich vermute, könnte in Ihrem Fall passieren, dass Entwickler den BA bei der Erfassung von Anforderungen unterstützen (z. B. Beantwortung von Fragen an den BA oder Bereitstellung von Schätzungen in Größenordnungen). und dass dies ungefähr Backlog Grooming ersetzt. Alternativ erledigen Sie Arbeiten (z. B. Wartungsarbeiten), die natürlich in relativ kleinen Paketen eingehen. In diesem Fall ist Kanban möglicherweise ein geeigneterer Prozess.

Ich bearbeite meine Antwort basierend auf dem Feedback, das ich erhalten habe, um zu verstehen, wie und wann Sie an der Anforderungs- und Sprintplanungsphase Ihres Sprints arbeiten sollten. wie auch bei der Anwendung der Kanban-Methode auf Ihre aktuellen Prozesse. Für die Zwecke meiner Antwort verwende ich die Begriffe "Kanban" und "Kanban-Methode" synonym, womit ich die Empfehlungen der Kanban-Methode meine. Ich hoffe das hilft.

Erstens sollten Sie nichts an Ihrem Anforderungsentwicklungs- / Ausarbeitungsprozess "für Kanban" ändern - da Kanban dort keine Empfehlungen abgibt. Alles, was Kanban empfiehlt, ist, dass Sie Ihre aktuellen Prozesse visualisieren, einschließlich Anforderungsmanagement und Sprint-Planung, WIP-Limits implementieren und Flow verwalten. Nehmen Sie anschließend Änderungen an Ihrem Prozess vor, die auf den festgestellten Engpässen und Verbesserungsmöglichkeiten beruhen.

[Ich empfehle dringend, wenn Sie dies noch nicht getan haben, lesen Sie bitte das Buch " Kanban: Erfolgreicher evolutionärer Wandel für Ihr Technologieunternehmen " von David Anderson, dem Pionier der Kanban-Methode. (Vollständiger Haftungsausschluss - Ich bin Mitbegründer einer Kanban-Produktfirma. Ich bin auch ein von der Lean Kanban University zertifizierter Kanban-Coach und -Trainer.)

Kanban an sich ist keine Softwareentwicklungs- / Projektmanagementmethode. Ohne einen vorhandenen Prozess können Sie Kanban nicht anwenden / implementieren. Es ist eine Methode, mit der Sie sich unabhängig von Ihren aktuellen Prozessen evolutionär (schrittweise, unterbrechungsfrei) verbessern können. In Ihrem Fall ist das Scrum. Sie sollten Kanban also wirklich auf Ihre Scrum-Prozesse anwenden, um Ihrem Team zu helfen, die Softwarebereitstellung zu verbessern. Die Kombination davon ist im Volksmund als Scrumban bekannt.

Sie würden beginnen, indem Sie den 3 Grundprinzipien von Kanban folgen -

1. Beginnen Sie mit dem, was Sie jetzt tun
2. Stimmen Sie zu, evolutionäre, inkrementelle Veränderungen zu verfolgen
3. Respektieren Sie aktuelle Prozesse, Rollen, Titel und Verantwortlichkeiten

Mit diesen als Leitprinzipien implementieren Sie dann die Standardpraktiken der Kanban-Methode - die sind:

1. Visualisieren Sie Ihren aktuellen Prozess (und die laufende Arbeit)
2. WIP begrenzen (Work-in-Progress)
3. Flow verwalten
4. Machen Sie Prozessrichtlinien explizit

Beginnen Sie mit diesen 4 Übungen. In der Kanban-Methode sind zwei weitere Vorgehensweisen definiert, die Sie sich ansehen können, sobald Sie anfangen und einen Überblick haben. Dies sind (5) Implementieren von Rückkopplungsschleifen und (6) Verbessern und Entwickeln gemeinsam mithilfe der wissenschaftlichen Methode.

Dies ist eine kurze Zusammenfassung - das Buch wird Ihnen wirklich helfen, diese besser zu verstehen. Auf unserer Website finden Sie auch einen umfassenden Kanban-Leitfaden .]

Das Wichtigste, worauf Sie sich in Ihrer Situation konzentrieren müssen, ist, (auf einem Kanban-Brett) zu visualisieren, was Sie heute tun. Ihr aktueller Anforderungsprozess sollte während des Sprint-Planungsprozesses oder einiger Unterschritte, die Sie möglicherweise zur Visualisierung auswählen, befolgt werden. Ihr Kanban-Board sollte in der Tat die Sprint-Planung als eine bestimmte Phase des gesamten Entwicklungsprozesses widerspiegeln, gefolgt von technischem Design, Entwicklung und Test.

Während sich User Stories in der Sprint-Planungsphase befinden, befolgen Sie die darin enthaltenen Schritte, z. B. den BA, der Ihnen Details bereitstellt, Entwickler, die Fragen vorbereiten und beantworten, bevor die Story in die Tech-Design-Phase und darüber hinaus übergeht.

(Übrigens, wenn Ihr Anforderungsprozess vorgelagerte Aspekte enthält, die als Teil der Roadmap-Planung oder der Backlog-Pflege angesehen werden können, gibt es ein ganzes Thema von "Upstream-Kanban", mit dem Sie Upstream-Aktivitäten so detailliert wie möglich besser verwalten können Sie oder Ihr BA / PO könnten in Betracht ziehen, ein separates vorgelagertes Kanban-Board zu verwenden, um all diese Aktivitäten zu verwalten.)

Ihr Dev Kanban Board Flow könnte wie folgt aussehen:

Backlog -> Sprint Planning -> Tech Design -> Dev -> Test -> Integrieren -> Fertig

Jede der Phasen verfügt möglicherweise über eigene Unterspalten "In Bearbeitung" und "Fertig". Wenn jedoch ein einzelner Entwickler alle Phasen durchläuft, benötigen Sie diese Unterspalten möglicherweise nicht in jeder Phase. Wenn Sie der Meinung sind, dass dies wichtig ist, können Sie die Sprint-Planung in drei Unterabschnitte unterteilen: Story-Detaillierung, Erläuterungen und Fertig, sodass Sie möglicherweise Engpässe in jedem Aspekt der Arbeit untersuchen können. In unserem eigenen Entwicklerteam kann die Codeüberprüfung beispielsweise häufig ein Engpass sein!

Am Ende Ihres zwei- oder dreiwöchigen Sprintzyklus können alle abgeschlossenen User Stories gemeinsam gelöscht werden - und Sie beginnen mit den nächsten Storys aus dem Backlog.

Im Laufe der Zeit könnten Sie entscheiden, dass einige der Herausforderungen bei der Durchführung von Scrum (Story-Leakage, versäumte Sprint-Fristen usw.) behoben werden könnten, indem einige der Einschränkungen / Regeln von Scrum beseitigt werden - was möglicherweise der Fall ist für manche sakrilegisch. Wir selbst machen 4-6 Wochen Releases - und machen keine Sprints. Genauso gut können Sie aber auch weiterhin mit Sprints und Releases arbeiten. In unserem Beispiel hilft Ihnen Kanban bei der Entscheidung, was für Ihr Unternehmen oder Team richtig ist, und bei der Übernahme oder Änderung Ihrer Prozesse, die Ihnen helfen, Ihre Arbeit bestmöglich zu liefern, wodurch Fluss, Durchsatz / Geschwindigkeit maximiert und Lieferzeiten verkürzt werden ( Markteinführungszeit).

Unabhängig davon, ob Sie Sprints abschaffen und nur Releases erstellen, wenn eine ausreichende Anzahl von Funktionen erstellt wurde (oder Fehler behoben wurden oder eine Kombination aus beiden) - oder ob Sie Sprints beibehalten - Kanban sollte Ihrem Team helfen, reibungsloser zu arbeiten Engpässe und Verbesserung der Zykluszeitleistung. Wenn dies Ihnen hilft, häufigere Releases zu erstellen, was Ihnen wiederum hilft, schnelleres Kundenfeedback zu erhalten, bewegen Sie sich jetzt zu einem Zustand, den Sie als "agiler" bezeichnen könnten, der jedoch möglicherweise nicht unbedingt der klassischen Definition der Scrum-Methode entspricht.

Wenn jedoch die Geschäftsziele besser erreicht werden, die Kunden zufriedener sind und Ihr Team optimal funktionieren kann, hätten Sie Ihre Ziele bei der Implementierung von Kanban erreicht.

Hoffe das hilft. Wenn Sie Fragen haben, beantworte ich diese gerne.

Um Ihre Fragen gezielt zu beantworten ...

An welchem ​​Punkt (in Kanban) setzen sich die Technikfreaks und die Geschäftsleute zusammen, um die Anforderungen für die Geschichte zu besprechen? Bietet der Produktmanager oder BA nicht eine exemplarische Vorgehensweise für die Story in Kanban?

Die von David Anderson entwickelte Kanban-Methode enthält keine spezifische Praxis oder Empfehlung, wann diese Aktivitäten stattfinden. Die Antwort, die jeder Kanban-Praktiker geben würde, lautet, dass Sie diese Aktivität zunächst bei der Anwendung der Kanban-Methode auf die gleiche Weise ausführen sollten, wie Sie sie ausgeführt haben, bevor Sie sich entschieden haben, Ihre Arbeitsverwaltung weiterzuentwickeln. Wenn Sie es alle 2 Wochen durchführen, sollten Sie es weiterhin alle 2 Wochen durchführen.

Ihr Team wird feststellen, ob es eine Chance und einen Wert gibt, den Zeitplan zu ändern. Denken Sie daran, dass ein 1-Monats-Zeitplan agiler als 1 Jahr ist, ein 2-Wochen-Zeitplan agiler als 1 Monat und 1 Woche agiler als 2 Wochen. Dieses Denken bringt uns schließlich gerade noch rechtzeitig dazu, die agilsten zu sein . Da die meisten agilen sollte nicht das Ziel Zustand sein , bevor Sie selbst starten.

Mit Scrum ist der BA normalerweise während des gesamten Sprints verfügbar, um die Entwicklung zu unterstützen, und ich gehe davon aus, dass dies auch mit Kanban der Fall ist. Mir ist jedoch nicht klar, wie die Technikfreaks mit Kanban die Geschichte verstehen, wenn es keine Sprintplanung gibt.

Die Kanban-Methode als Denkweise und eine Reihe von Praktiken stellt keine Bedingungen oder Einschränkungen für die Existenz eines Sprints, eines Sprint-Planungsmeetings oder anderer Praktiken. Es ist absolut respektvoll gegenüber einem Scrum-Team und seinen Praktiken. Wenn Sie heute ein Meeting haben, in dem Techies die Geschichte besprechen, würden Sie dieses Meeting weiterhin nach demselben Zeitplan abhalten.

Ich konnte Ihnen nicht guten Gewissens sagen, wie der Zeitplan aussehen würde / sollte / könnte, ohne Ihr Team und die Organisation um ihn herum zu verstehen. Wenn Sie diese Aktivitäten heute nicht ausführen, gibt es viele andere Informationsquellen, die Ihnen zeigen, wie Sie diese Aktivitäten ausführen. Die Kanban-Methode kann Ihnen dabei helfen, herauszufinden, ob Ihre Entscheidungen gut sind.

Bitte lesen Sie die Blog-Beiträge in diesen beiden Serien. Einer von mir und einer von Steve Porter, Teammitglied bei Scrum.org.

Nichts in Kanban verhindert Scrum - Dave White - WesternDevs.com

Scrum und Kanban - gemeinsam stärker - Steve Porter - Scrum.org

Das meiste, was Mahesh Singh oben sagt, stammt aus dem veröffentlichten Schulungsmaterial von Lean Kanban Inc. Also, wirklich ... hier gibt es nichts zu streiten. Sprechen Sie mit einem AKT oder KCP und er / sie wird dasselbe sagen.

Für die ursprüngliche Frage, wo Sie Anforderungsklärungen vornehmen können, gibt es verschiedene Optionen:

1. Sie könnten das tun, was Sie heute tun, aber indem Sie diese Schritte visualisieren und in einen Wertstrom einfügen, identifizieren Sie Ihre Hindernisse. Nehmen Sie dann eine Änderung vor und sehen Sie, wie das funktioniert. Die Toyota Kata Community nennt dies als Einzelfaktorexperimente.

2. Erstellen Sie ein Upstream-Board für das Verfeinern, Zerlegen, Entwerfen von UX / Interaktionen usw. in unserem eigenen Team. In unserem eigenen Team unterteilen wir Themes in Epics, führen den gesamten UX-Entwurfszyklus durch und teilen ihn erst dann in Storys auf. Anschließend werden die Geschichten priorisiert, indem alle Beteiligten in ein Meeting einbezogen werden. Das Ende dieses Wertstroms führt zu verfeinerten, priorisierten Geschichten. Das ist unser Rückstand für das Entwicklungsteam. Tatsächlich nimmt dieser Ablauf viel Zykluszeit in Anspruch, hauptsächlich weil es Zeit braucht, um von einer Anforderung auf epischer Ebene zu Drahtmodellen in Sketch oder Zeppelin für das Entwicklerteam zu wechseln.

3. Wenn Sie keinen signifikanten Wertstrom oder keine signifikante Zykluszeit haben, um etwas von Anforderung in verfeinerte Storys umzuwandeln, können Sie einfach eine Phase in Ihrem Entwicklungswertstrom haben (z. B. Klärung von Anforderungen). Scrum erwartet jedoch ein hohes Maß an Klarheit für die Schätzung und Aufteilung in Aufgaben. Ob Sie also ein Meeting vor dem Sprint-Planungsmeeting oder ein erweitertes Sprint-Planungsmeeting durchführen, hängt von Ihrem Team und Ihrer Organisation ab.

Wenn wir uns an die Grundsätze erinnern und offen für die definierten Praktiken sind, wird der Inspektions- und Anpassungszyklus viel einfacher.