Wie können wir kontinuierlich neue Features integrieren, wenn der PO erst am Ende jedes Sprints feststellt, ob ein Feature „fertig“ ist?

Das Team sagt, die Geschichte sei fertig. Stellen Sie sich dies auf einem Storyboard vor, in dem das Team die Story als bereit markiert (fertig oder abgeschlossen) in den akzeptierten Status zu bringen.

Der Product Owner akzeptiert die Story (indem er sie in „Akzeptiert“ zieht), aber seine Akzeptanz zeigt nur an, dass die Story in Bezug auf die Geschäftsfunktionalität fertig ist.

Die Akzeptanz durch einen Product Owner bedeutet also nur teilweise, dass die Geschichte abgeschlossen ist. Done geht über die PO-Annahme hinaus, da es auch die nicht funktionalen Teile der Fertigstellung einer Geschichte umfasst. QA, Tech Debt usw.

Ein Modell für den Umgang mit Integration und fertigen Geschichten besteht darin, diese Geschichten in einer Inszenierungsumgebung zu landen. Staging ist ein Klon oder eine enge Kopie Ihrer Produktionsumgebung. Es ist auch der Ort, an den Integrationsteams gehen würden, um Code zu konsumieren. Ihr Product Owner verwendet diese Umgebung, um zu überprüfen, ob die funktionalen Anforderungen der Story erfüllt sind, und um die Story zu akzeptieren. Dies muss nicht während der Überprüfungszeremonie geschehen. Es kann jederzeit während der Iteration passieren, wird aber idealerweise kurz nach Abschluss der Iteration abgeschlossen (andernfalls halten Sie Ihre Bühnenumgebung als Geisel und können keine neuen Funktionen einchecken).

Um zum Staging zu gelangen, müssen bereits alle Ihre erledigten Kriterien (funktional und nicht-funktional) erfüllt sein.

Ich vereinfache ein wenig mit diesem Modell, da es bestimmte Kriterien gibt, die in einigen Situationen in der Produktion auftreten können. Aber die Mehrheit der erledigten Kriterien muss erfüllt sein, bis der Zeitcode auf die Bühne geht.

Von Scrum.Org:

Das DoD ist normalerweise eine klare und prägnante Liste von Anforderungen, die ein Software-Inkrement erfüllen muss, damit das Team es als vollständig bezeichnen kann. Bis diese Liste erfüllt ist, wird kein Produktinkrement durchgeführt . Während des Sprint-Planungsmeetings entwickelt oder bestätigt das Scrum-Team seine DoD , wodurch das Entwicklungsteam weiß, wie viel Arbeit es für einen bestimmten Sprint auswählen muss.

Der Schlüsselsatz dort ist für mich, dass das Scrum Team (insbesondere der Product Owner) das DoD entwickelt und bestätigt. Es ist ein vereinbarter Standard vor Beginn der Sprint-Arbeit.

Wenn der Product Owner der Ansicht ist, dass die Definition of Done nicht erfüllt wurde, hat das Scrum Team die Definition of Done technisch gesehen nicht erfüllt und der PO behält sich das Recht vor, die User Story(s) als nicht erledigt abzulehnen.

Bearbeiten zum Hinzufügen

Die Scrum Alliance hat ein praktisches Diagramm, um sicherzustellen, dass die Definition of Done einfach, transparent und konsistent ist. Bitte beachten Sie die beiden Kästchen

• Genehmigung des Product Owners
• Abnahmeprüfung

Ich weiß, dass einige in der Community ärgerlich auf meine strikte Parteinahme für den Product Owner reagieren werden, aber meiner Meinung nach ist es absurd zu glauben, dass die Entwickler entscheiden dürfen, wann sie Arbeit aufnehmen, was den Abschluss dieser Arbeit ausmacht, und diese Arbeit dann erzwingen unabhängig von den Erwartungen des Product Owners in die Done-Spalte.

Der Product Owner verwaltet die Stakeholder, die Geschäftsanforderungen und übernimmt das Risiko im Namen der Geschäftseinheit. Natürlich müssen sie unbedingt die Definition of Done besitzen.

Als Balanceakt besitzt das Scrum-Team die Definition of Ready, die es ihnen ermöglicht, User Storys vom Product Owner aufgrund unklarer Spezifikationen, technischer Probleme, Abhängigkeitsarbeit oder anderer berechtigter Bedenken abzulehnen.

Letztendlich könnten die Ergebnisse schrecklich sein, wenn wir Scrum-Teams erlauben, ihre eigenen Hausaufgaben zu markieren und Produkte ohne die Sorgfaltspflicht des Product Owners an ein Unternehmen weiterzugeben.

Darüber hinaus lässt sich dies nicht auf Scrum of Scrums skalieren, da sonst jedes Scrum-Team einfach erklären würde, dass seine Abhängigkeit „erledigt“ sei, ohne dass ein Product Owner berücksichtigt, dass das gesamte Produkt Fortschritte macht.

Persönliche Ansätze

Nebenbei dachte ich, es wäre hilfreich zu veranschaulichen, wie ich dieses Problem als Scrum Master kontrolliere.

• Wenn eine User Story eines Back-End-Entwicklers getestet wurde, geht sie in „Being Verified“, wo wir sie mit dem PO besprechen.
• Wenn die PO nicht einverstanden ist, bitte ich um die Geschäftsspezifikationen oder Anforderungen, die zeigen, dass sie nicht „erledigt“ ist.
• In 95 % der Fälle stehe ich auf der Seite des Entwicklers und veranlasse den Product Owner, entweder eine neue Karte für das Product Backlog zu erstellen oder die aktuelle Fertigstellung zu akzeptieren.
• Die Business-Intelligence-Front-End-Entwicklung in unserer Umgebung ist schwieriger, da viel mehr Tests erforderlich sind, einschließlich UX und Datenabgleich zwischen alten und neuen Ausgaben
• An diesem Punkt repräsentiert der PO den Endnutzer und fungiert als Kunde
• Wir geben dem Product Owner in dieser Phase viel mehr Möglichkeiten, Berichte abzulehnen

Wie bei allen Dingen bei Scrum (und Agile) muss ein Gleichgewicht gefunden werden, um Teamharmonie, Vertrauen und ein gut funktionierendes Team zu gewährleisten. Ich nehme die Teile von Scrum, die ich brauche, um das zu erreichen, und passe den Rest an.

Manche mögen sagen, dass ich kein Scrum mehr mache, aber die Wahrheit ist, ich brauche das Etikett nicht, was ich brauche, ist ein hochproduktives Business Intelligence Center.

Zum OP sage ich das -

Entspricht es Ihren Anforderungen, wenn der Product Owner User Storys ablehnt? Sei ehrlich. Wenn er/sie wirklich kompetent und gut in seiner Rolle ist, kann die Ablehnung von User Storys das Beste sein, was Ihrer Lieferung passieren kann, und erspart dem Team auf lange Sicht eine höhere Menge an Nacharbeit.

Die Hauptquelle Ihres Rätsels ist der Product Owner, der bis zum Ende des Sprints wartet, um Stories zu akzeptieren. Die Funktion des Sprint Reviews besteht nicht darin, dass der Product Owner die Arbeit des Teams überprüft und akzeptiert. Es ist Sache des Teams, sich selbst zu überprüfen und anderen Beteiligten zu präsentieren, was getan wurde. Zeit für Product Owner Review, Feedback und Iteration sollte in Ihren Sprint-Zeitplan eingebaut werden.

Lassen Sie uns vor diesem Hintergrund Ihre Hauptfrage beantworten: „Wann werden Funktionen per Pull in unseren Integrationszweig des Codes angefordert?“

Wann eine Integration erfolgen soll, kann eine knifflige Entscheidung sein. Es ist üblich, eine Staging-Umgebung zu haben, die als Umgebung sowohl für Integrations- als auch für Akzeptanztests dient. Es kann jedoch schwierig sein, sich von der Zusammenführung einer Funktion abzuwenden. Wenn der Product Owner erhebliche Probleme findet, haben Sie jetzt einen potenziellen Blocker für das Pushen in die Produktion und einen nicht vertrauenswürdigen Zweig, von dem aus andere Funktionen verzweigt werden können.

Wenn möglich, sollte der Product Owner jedes Feature isoliert prüfen und genehmigen, bevor es mit anderen Features zusammengeführt wird. Die Akzeptanz des Features in diesem Stadium bedeutet, dass es wie geplant realisiert wurde, obwohl möglicherweise mehr Arbeit erforderlich ist, um es lieferfähig zu machen. Die Genehmigung des Product Owners an dieser Stelle sollte grünes Licht geben, um mit der Integration und Bereitstellung der Funktion fortzufahren.

So können Integrations- und Zusammenführungskonflikte behandelt werden:

Nehmen wir an, zwei Funktionen, A und B, werden gleichzeitig entwickelt. Feature A wird zuerst überprüfbar und vom Product Owner akzeptiert. Es kann nun in den Integrationszweig gemergt werden. Alle anderen Funktionen sollten, wenn sie sich der Überprüfbarkeit nähern, auf den Fortschritt des Integrationszweigs achten und sich selbst aus dem Integrationszweig aktualisieren. Dies ist der Punkt, an dem Zusammenführungskonflikte entstehen und gelöst werden können. Jetzt liegt die Verantwortung beim Entwickler von Feature B, alle Konflikte zu lösen. Dies kann sogar Änderungen an Merkmal A erfordern. Sobald dies erledigt ist, kann nun Merkmal B zusammen mit den Änderungen an Merkmal A vom Product Owner überprüft werden. Nach der Annahme kann es ebenfalls mit dem Integrationszweig zusammengeführt werden.

TL;DR

Ihre Scrum-Implementierung weist einige Missverständnisse auf, die anscheinend darauf beruhen, wie die „Definition of Done“ in einer angemessen kollaborativen Weise implementiert werden kann. Wenn Sie diesen Kommunikationsfehler beheben, sollten Ihre kontinuierlichen Integrationsbemühungen viel reibungsloser ablaufen.

Darüber hinaus wird es Ihrem Team sehr helfen, sich auf die iterative Natur agiler Methoden zu konzentrieren; Agilität betont die Verfeinerung des Produkts im Laufe der Zeit und nicht die perfekte Ausführung von "Spezifikationen" innerhalb jedes Inkrements. Das Product Backlog ist ein lebendiges Dokument, und Storys im Backlog werden mindestens bei jeder Iteration hinzugefügt, geändert oder entfernt. Es handelt sich nicht um einen One-Pass-Satz von Anforderungen, und Ihr Team muss diese Flexibilität nutzen.

Wann ist etwas fertig?

In Scrum gilt eine User Story oder ein Inkrement als erledigt, wenn es sein erklärtes Ziel erreicht und alle bestehenden Kriterien erfüllt hat, denen das Scrum-Team als Ganzes (einschließlich des Product Owners) zuvor zugestimmt hat.

Betrachten Sie die folgende User Story:

Als Web-Browsing-Kunde
möchte ich alles auf der Seite in 300-Punkte-Schrift sehen
, damit ich nicht unter Augenbelastung leide.

Diese Geschichte wäre zu Ende, wenn:

1. Die Standardschriftart der Website war auf eine lächerliche Größe eingestellt.
2. Das Team ist sich einig, dass die Implementierung dem Ziel entspricht, Augenbelastungen zu vermeiden.

3. Die aktuelle „Definition of Done“, die für alle Storys im Projekt gilt, ist erfüllt. Diese Definition variiert von Team zu Team, kann aber Unit-Tests, Benutzerakzeptanztests, das Pushen auf einen Continuous-Integration-Server oder das gegenseitige Klatschen mit nassen Makrelen beinhalten. Wie auch immer.

   NB: Der Punkt hier ist, dass das Team (einschließlich des Product Owners) der Definition vorher zustimmt . Es gibt keine nachträgliche Neuverbindung von „Fertig“.

4. Jemand im Team markiert die Story im Sprint Backlog als „fertig“.

Das ist es. Die Geschichte ist jetzt fertig. Es kann richtig gemacht werden oder nicht , aber es wird für die Zwecke von Scrum als vollständig betrachtet. Der Product Owner hätte während des gesamten Sprints involviert sein sollen. Wenn also das Feature völlig aus dem Ruder gelaufen ist, ist die mangelnde Beteiligung des PO wahrscheinlich das Problem und sollte während der nächsten Sprint-Retrospektive angegangen werden.

Was ist mit Geschichten, die nicht richtig gemacht sind ?

Am Ende des Sprints sammelt das Team Punkte für alle Storys, bei denen das gesamte Team (einschließlich des Product Owners) der Meinung ist, dass sie gemäß der Definition of Done abgeschlossen wurden. Wenn die Stories damit abgeschlossen wurden, aber in irgendeiner Weise unbefriedigend sind, ist das Wasser auf die Mühlen während der Sprint-Retrospektive und für andere Inspektions- und Anpassungsmeetings. Es ändert nichts an der Tatsache, dass die Stories auf eine vereinbarte Weise erstellt wurden – eine Vereinbarung, bei der der Product Owner eine aktive Partei war – und daher gibt es keine „Akzeptanz“ der Stories.

Während der Sprint Review (meine Darstellung in Fettdruck) :

• Der Product Owner erklärt [den Stakeholdern], welche Product Backlog-Einträge „erledigt“ wurden und welche nicht „erledigt“ wurden. Dies ist ein Statusbericht, keine Gelegenheit, Geschichten anzunehmen oder abzulehnen.
• Das Entwicklungsteam demonstriert die Arbeit, die es „erledigt“ hat, und beantwortet Fragen zum Inkrement. Dies ist oft ein großartiger Ort, um Fehlfunktionen zu erklären, die dennoch „erledigt“ sind, und um Feedback von Stakeholdern darüber zu erbitten, wie sie in einer zukünftigen Iteration verbessert werden können.
• Der Product Owner bespricht das Product Backlog in seiner jetzigen Form. Er oder sie prognostiziert voraussichtliche Fertigstellungstermine basierend auf dem bisherigen Fortschritt (falls erforderlich). Dies ist ein weiterer Wendepunkt, an dem Stakeholder entscheiden können, ob ein unvollkommenes Feature „gut genug“ ist oder ob es überarbeitet oder unverändert zum Product Backlog hinzugefügt werden muss.
• Die gesamte Gruppe arbeitet gemeinsam daran, was als nächstes zu tun ist, sodass das Sprint Review wertvollen Input für die nachfolgende Sprint-Planung liefert. An dieser Stelle könnte eine begrenzte Diskussion über Fehlfunktionen stattfinden, aber die meisten Prozessprobleme sollten in der Sprint-Retrospektive angesprochen werden.

Dann kann der Product Owner während der Backlog-Verfeinerung oder der Sprint-Planung alle Storys nehmen, die abgeschlossen wurden, aber nicht den gewünschten Wert geliefert haben, und:

• Schreiben Sie neue Geschichten, um etwaige Mängel zu beheben.
• Setzen Sie Geschichten zurück in das Product Backlog, hoffentlich mit mehr Details oder einem besseren Verständnis der Ziele und Zielsetzungen der Geschichte mit dem Team.
• Entscheiden Sie, dass die bereitgestellten Features „gut genug“ sind oder nicht erneut iteriert werden müssen.

Fazit

Zusammenfassend kann der Product Owner nicht im Alleingang erklären, ob eine Story fertig ist oder nicht. Schließlich ist die „Definition of Done“ eine Zusammenarbeit aller Mitglieder des Scrum-Teams.

Der Product Owner (als alleiniger Verwalter des Product Backlogs) kann jedoch bestimmen, ob eine Story im Product Backlog als abgeschlossen markiert werden kann oder ob Elemente davon in einem anderen Sprint erneut durchgeführt werden müssen. Die ursprüngliche Story einfach wieder an die Spitze des Product Backlogs zu werfen, ohne die zugrunde liegenden Probleme mit der Story, dem Scrum-Prozess oder der Kommunikation des Scrum-Teams anzugehen, ist jedoch wahrscheinlich eine schlechte Idee, daher sollte der Scrum Master an diesem Punkt definitiv helfen.

Das ist eine gute Frage, mit der viele Teams zu kämpfen haben.

Der Product Owner trifft seine Entscheidung darüber, ob eine User Story am Ende des Sprints „fertig“ ist, während des Sprint Review Meetings.

Nö. Der Product Owner akzeptiert „erledigte“ User Storys während des Sprints.

Der gesamte Story-Lebenszyklus (To do – In progress – Done – Pushed to master) findet also vor dem Sprint Review statt. Und sobald Story zum Master-Branch gepusht wird, sollten andere Branches es einziehen und Konflikte beheben, falls vorhanden.

Die Annahme von User Storys kann einige Tage dauern, daher wird das Sprint-Review-Meeting nicht abgehalten, um User Storys zu akzeptieren. Es wird abgehalten, um Plan und Ist zu vergleichen und zu beurteilen, ob das Sprintziel erreicht wurde.