Sollte ein Product Owner mit dem Testen beginnen, während sich ein Element in der Codeüberprüfung befindet

Die Antwort hängt davon ab, ob dies den Prozess verlangsamt oder beschleunigt.

Wie viele der von ihr gefundenen Fehler wurden während der Codeüberprüfungsphase entdeckt?

Wenn sie alle während der Codeüberprüfung entdeckt wurden, verschwendet sie vielleicht ihre (und die aller) Zeit. Obwohl wir immer noch fragen können:

Wie viele der von ihr gefundenen Fehler wurden vor der Code-Review-Phase behoben?

Wenn sie es alle wären, dann spart sie Ihnen Zeit, indem sie Sie korrigierten Code mit weniger Fehlern überprüfen lässt.

Und dann ist da noch die Art der Käfer, die sie findet, die einen Unterschied macht.

Ein Product Owner überprüft das Produkt normalerweise auf UI-Probleme, Formulierungen, Tippfehler und Ästhetik.

Diese "Bugs" werden von Code Reviews oder der QA-Abteilung nicht aufgegriffen, da sie hauptsächlich subjektiv sind. (Mit Ausnahme von Tippfehlern.) Je früher sie diese Probleme behebt, desto weniger Arbeit (des erneuten Testens) für alle Beteiligten.

Wenn sie andererseits nur schwer zu findende Fehler findet, die eine gute Codeüberprüfung in viel kürzerer Zeit aufgedeckt hätte, dann lohnt es sich vielleicht, sie darauf hinzuweisen, dass sie ihre Zeit verschwendet.

Ein letzter Gedanke: Wenn sie das Produkt nur für eine kurze Probefahrt mitnimmt und (seitdem sie es gefunden hat) alle Probleme meldet, die sie findet, dann brauchen Ihre Programmierer vielleicht eine bessere Arbeitsmoral; Wenn sie es vor der Veröffentlichung eine Minute lang getestet hätten, würden sie auch diese offensichtlichen Fehler finden und beheben.

Als allgemeine Regel würde ich sagen, je früher der Product Owner mit dem Testen beginnt, desto besser .

Der Grund dafür ist, dass viele Fehler aufgrund von Missverständnissen bei Anforderungen auftreten. Der Product Owner ist einzigartig gut positioniert, um ein Team zu überprüfen und ihm Feedback zu geben.

Bitten Sie PO zu warten, bis sich der Artikel in der Testphase befindet, und halten Sie sich an die Sprint-Timebox und werden Sie nicht zum Engpass

Wenn der Product Owner in der Testphase ein Problem entdeckt, kann eine Nacharbeit und eine Wiederholung des Code-Reviews erforderlich sein. Dies könnte als Verschwendung angesehen werden, wenn es dem Product Owner möglich wäre, das Problem früher im Entwicklungszyklus zu entdecken.

Einige Scrum-Teams, mit denen ich zusammengearbeitet habe, sind so weit gekommen, dem Product Owner während der Entwicklung Funktionen zu demonstrieren , ganz zu schweigen davon, auf den Beginn des Testzyklus zu warten.

Wenn das Team es derzeit als störend empfindet, frühes Feedback vom Product Owner zu erhalten, würde ich vorschlagen, nach Möglichkeiten zu suchen, den Entwicklungsprozess zu verbessern, um dies weniger problematisch zu machen.

Meine Empfehlung wäre, Ihren Entwicklungsprozess um einen flexiblen und frühen Feedback-Zyklus herum aufzubauen. Ein Ansatz, den ich gesehen habe, besteht darin, eine Umgebung speziell für den Product Owner zu haben. Wenn das Entwicklungsteam der Meinung ist, dass es einen stabilen Build hat, gibt es ihn für die Umgebung des Product Owners frei und teilt ihm mit, dass es neue Funktionen zu überprüfen gibt. Wenn es bekannte Probleme gibt, sollten diese klar kommuniziert werden und es liegt in der Verantwortung des Product Owners, keine Duplikate zu melden.

Kommunikation und Teamarbeit sind entscheidend, um diese Arbeit zu machen.

Um Verschwendung zu vermeiden, würde ich auch vorschlagen, zu warten.

Angenommen, die Zeit eines PO ist teurer/wertvoller als die eines Testers oder Entwicklers, einfach aufgrund von Angebot und Nachfrage, da es nur einen PO, aber mehrere Entwickler/Tester gibt, wäre Folgendes eine Verschwendung guter PO-Zeit:

• Melden von Fehlern, die ein Entwickler ohnehin gefunden hätte
• Melden von Fehlern, die von Testern ohnehin gefunden worden wären
• Wiederholtes Testen der gleichen Dinge , nachdem geplante Änderungen (Code Review) vorgenommen wurden

Außerdem könnten Entwickler ein wenig verärgert sein, wenn ihre Arbeit kritisiert wird, bevor sie sie für „erledigt“ erklärt haben. Man sagt einem Koch nicht, dass sein Gericht nicht schmeckt, indem man es aus dem Ofen holt, wenn der Koch darauf besteht, dass es nur halb gar ist und weitere 20 Minuten braucht. Sie sagen den Leuten nicht, dass sie wie Idioten parken, wenn sie sich noch auf der Straße bewegen. Mit anderen Worten, sagen Sie den Leuten nicht, dass sie Fehler gemacht haben, wenn sie noch nicht fertig sind. Es kann nur ein "Bug" sein, wenn es überhaupt funktionieren sollte .

Das Einreichen von Fehlertickets wird also später falsche Metriken generieren. Viele Fehlertickets bedeuten, dass die Entwickler besser arbeiten müssen. Aber in diesem Fall waren sie noch nicht einmal fertig. Ihre Metriken sind also verzerrt.

Aber wie immer bei Scrum: Besprechen Sie es mit dem Team, sehen Sie, was alle zu sagen haben, und finden Sie eine Lösung, die für alle funktioniert.

Akzeptanztests sind nicht die Rolle des Product Owners

Es ist gut, dass Sie einen Product Owner haben, der an der Produktentwicklung und dem QA/UAT-Prozess beteiligt sein möchte. Obwohl die Zusammenarbeit großartig ist, ist das Testen nicht Teil der Rolle des Product Owners in Scrum.

Der Scrum-Guide sagt:

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst:

• Produkt-Backlog-Einträge klar ausdrücken;
• Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen;
• Optimierung des Werts der Arbeit, die das Entwicklungsteam leistet;
• Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum-Team als Nächstes arbeiten wird; Und,
• Sicherstellen, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht.

Was Ihr Product Owner tut, tut an sich keines dieser Dinge und nutzt keine Framework-Prozesse und -Praktiken, um die Qualität sicherzustellen.

Was stattdessen zu tun ist

Der Product Owner sollte auf jeden Fall mit dem Entwicklungsteam zusammenarbeiten. Dazu gehört die Unterstützung des Scrum-Teams bei der Erstellung der Definition of Done, der Festlegung von Sprint-Zielen und der Teilnahme an Sprint-Reviews und Retrospektiven. Der Schwerpunkt des Product Owners liegt jedoch auf der Definition der Arbeit und der Optimierung des Werts, nicht auf der Durchführung von Qualitätssicherungs- oder Akzeptanztests.

Als Product Owner, insbesondere wenn ich Teil eines unausgereiften Scrum-Teams bin, kann ich das Entwicklungsteam bitten, kritische Funktionen, die der Definition of Done entsprechen, während des gesamten Sprints zu demonstrieren, anstatt bis zum Ende zu warten. Oder ich kann sie bitten, vor dem formellen Sprint Review eine „Vorbereitungsdemo“ innerhalb des Teams durchzuführen, um sicherzustellen, dass wir alle auf derselben Seite sind.

Als Product Owner kann ich die Arbeit nicht genehmigen . Stattdessen arbeite ich mich durch das Product Backlog, um die Arbeit zu definieren, und durch die Definition of Done, um Qualitätserwartungen festzulegen. Am wichtigsten ist, dass ich das Sprint-Ziel durcharbeite, um Erwartungen darüber festzulegen, was als geliefertes oder nicht geliefertes Arbeitsinkrement gilt.

Wenn mein Sprint-Ziel gemäß der Definition of Done erreicht wurde, wurde das Arbeitsinkrement erfolgreich geliefert. Wenn das Sprint-Ziel nicht erreicht wurde, wurde das Arbeitsinkrement nicht erfolgreich geliefert. Das bedeutet nicht, dass die Arbeit nicht erledigt wurde oder dass verschiedene Teile der Arbeit nicht richtig erledigt wurden; es bedeutet lediglich, dass die Iteration nicht den geplanten Umfang und Wert erreicht hat.

Als Scrum Master gehört es zu Ihrer Aufgabe, den Product Owner über die Verantwortlichkeiten der Rolle aufzuklären. Helfen Sie dem Product Owner, die Tools des Frameworks richtig zu verwenden und effektiv mit dem Team zusammenzuarbeiten.

Vertrauen aufbauen

Wenn der Product Owner das Produkt oder seine Funktionen in jedem Sprint routinemäßig testet , kann dies ein Hinweis darauf sein, dass der Product Owner ein anhaltendes Qualitätsproblem wahrnimmt oder dem Entwicklungsteam nicht vertraut. Dies ist eine Gelegenheit, die Kommunikation zu verbessern, die Definition of Done neu zu bewerten oder den Prozess auf andere Weise zu überprüfen und anzupassen, um das Vertrauen zwischen den wichtigsten Teamrollen zu stärken.

Wenn der Product Owner während des Sprints routinemäßig Feedback auf Implementierungsebene (und nicht auf System- oder Funktionsebene) gibt, ist dies ebenfalls ein Geruch der Framework-Implementierung, der auf eine schlechte Backlog-Verfeinerung, schlechte Sprint-Ziele und unzureichende User Stories hindeuten kann Kontext oder User Stories, die die INVEST-Kriterien nicht erfüllen. Wenn dies der Fall ist, führt die Zusammenarbeit mit dem Product Owner und dem Entwicklungsteam zur Verbesserung des Inhalts der Produkt- und Sprint-Backlogs und zur Verbesserung der Einhaltung der INVEST-Kriterien (insbesondere der Testable-Anforderung) häufig zu einer signifikanten Prozessverbesserung .

Darüber hinaus kann eine Nicht-Entwickler-Inspektion eines Inkrements an anderen Stellen als an Framework-Wendepunkten ebenfalls zu einem Scope Creep führen. Wenn der Product Owner beispielsweise ein Feature untersucht, das die Definition of Done erfüllt, aber In-Sprint-Änderungen anfordert, kann dies eine Änderung des Umfangs oder des Designs darstellen, die nicht Teil der Sprint-Planung der aktuellen Iteration war. Entwickler sollten aktiv mit dem Product Owner zusammenarbeiten, um Umfangs- und Designprobleme zu definieren, aber jedes Feedback, das den Umfang ändert oder das Sprint-Ziel gefährdet, muss sorgfältig ausgehandelt werden. Ein veraltetes Sprint-Ziel oder wesentliche Änderungen des Umfangs können es erforderlich machen, den Sprint abzubrechen und zur Sprint-Planung zurückzukehren.

In jedem dieser Beispiele besteht das Hauptziel des Scrum Masters darin, dem gesamten Scrum-Team dabei zu helfen, Vertrauen aufzubauen. Das heisst:

• Der Product Owner muss sich darauf verlassen können, dass der Prozess des Entwicklungsteams das Sprint-Ziel erfolgreich erreicht.
• Das Entwicklungsteam muss sich darauf verlassen können, dass es ein klares Problem mit angemessenem Kontext erhält und dass die Informationen ausreichen, um eine Lösung innerhalb einer einzigen Iteration zu identifizieren und zu implementieren.
• Das Entwicklungsteam braucht Spielraum, um das einfachste Design und die einfachste Implementierung zu finden, die das Sprint-Ziel erreichen.

Ihr Ziel als Scrum Master ist es, Vertrauen zu fördern, das durch Sichtbarkeit, Transparenz und offene Kommunikation aufgebaut wird. Nutzen Sie die Sprint-Retrospektive und andere Framework-Elemente so weit wie möglich, aber stellen Sie immer sicher, dass Sie wirklich zugrunde liegende Vertrauens- und Kommunikationsprobleme lösen, anstatt nur die Symptome anzugehen.

Ich verstehe nicht, wie das überhaupt ein Problem sein soll.

Wenn das Problem darin besteht, dass der PO nicht verfügbar ist, um Feedback zu geben oder Fragen zu beantworten, dann ist dies ein ganz anderes Problem. Wenn der PO Dinge testet und Fehler findet, spart er Ihrem Team Zeit und Mühe.
Wenn sie also noch verfügbar sind, um all die Dinge zu tun, die Sie von ihnen verlangen, lassen Sie sie alle Tests durchführen, die sie möchten, und seien Sie dankbar für ihren Beitrag.

Meine Idee ist, dem Product Owner zu raten, mit dem Testen der Benutzererfahrung und Funktionalität zu beginnen, sobald die Codierung und das Testen sowohl von Entwicklern als auch von Testern abgeschlossen sind. Die Hauptverantwortung des PO besteht darin, Unterschiede in der Funktionalität gemäß der User Story herauszufinden. So kann die kostbare Zeit der Bestellung effizient genutzt werden.

Todd A. Jacobs hat es auf den Punkt gebracht. Ich finde, wenn ein PO den Entwicklungs- und Testteams nicht vertraut, gibt es dort ein tieferes Problem, das gelöst werden muss. Dies könnte zu moralischen Problemen beim Personal führen sowie dazu, dass die PO ihre eigenen Funktionen und das Projekt als Ganzes schlecht verwaltet.