Mir wurde diese Frage in einem Interview gestellt und ich konnte die Lösung nicht finden, also dachte ich, ich werde hierher kommen.
Im Grunde arbeitete ich hauptsächlich als Entwickler und hatte meine eigenen Unit-Tests für die Aufgaben, die ich fertigstellte. Aber wenn ich ein Product Owner oder Scrum Master wäre, wie stelle ich dann sicher, dass das Entwicklungsteam genügend Komponententests erstellt oder den Code ordnungsgemäß getestet hat?
Ich denke, wir können Akzeptanztests durchführen oder die Fehler sogar als Teil des nächsten Sprints berücksichtigen. Es gibt eine weitere Möglichkeit, Product Owner und Scrum Master während Sprint-Meetings eine Reihe grundlegender Tests erstellen zu lassen. Aber das wird dazu führen, dass das Sprint-Meeting Stunden dauert. Dies sind die zwei möglichen Ideen, die ich vorschlagen könnte.
Gibt es eine andere Möglichkeit, wie ein Product Owner die Qualität sicherstellen kann?
Die Durchsetzung der Definition of Done (DoD) ist der primäre Mechanismus des Product Owners zur Gewährleistung der Produktqualität. Das DoD definiert die Qualität für das Projekt. Sicherzustellen, dass Arbeit, die hinter dem DoD zurückbleibt, in das Product Backlog zurückgeführt wird, ist die Projektkontrolle, um zu verhindern, dass bekannte Fehler dem Sprint entkommen.
NB: Da die Kapazität des Teams begrenzt ist, steuert der Product Owner die Qualität, indem er die Kapazität gegen explizite Backlog-Elemente und implizite Aufgaben im Zusammenhang mit dem DoD abwägt.
In agilen Frameworks erfolgt das Qualitätsmanagement über die „Definition of Done“. Dies ist eine formale Definition aller Quality Gates, die ein potenziell auslieferbares Inkrement durchlaufen muss, um am Ende eines Sprints als erledigt zu gelten. Da Scrum erfordert, dass sich das Produkt am Ende jedes Sprints immer in einem potenziell freigabefähigen Zustand befindet, umfasst das DoD auch Akzeptanztests, Regressionstests und andere Qualitätskriterien, um zu validieren, dass das Produkt selbst (und nicht nur das aktuelle Arbeitsinkrement) die definierten Qualitätskriterien erfüllt.
Da die Arbeit am Ende jedes Sprints entweder erledigt oder nicht erledigt ist, gilt Arbeit, die die DoD nicht erfüllt, als „nicht erledigt“ und muss zur Neupriorisierung und Neuplanung an das Product Backlog zurückgegeben werden. Teilweise fertiggestellte Product Backlog Items gelten nie als erledigt und werden nie automatisch vorgetragen. Dies ist eine Schlüsselkontrolle für das Scrum-Framework.
Da Scrum ein iteratives Framework ist, kann sich das DoD im Laufe der Zeit weiterentwickeln. Der Product Owner kann die Qualität des Produkts optimieren, indem er mit dem Rest des Scrum-Teams zusammenarbeitet, um den Umfang und die Granularität des DoD auf der Grundlage der aus den Sprint-Retrospektiven gewonnenen Erkenntnisse und Informationen zu bestimmen.
Ein Team mit einem sehr komplexen oder zeitaufwändigen DoD muss seine Kapazitätsprognosen entsprechend reduzieren, da mehr Teamkapazität darauf verwendet wird, Arbeitsinkremente „fertig“ zu machen. Andererseits kann die Steigerung der Feature-Entwicklung auf Kosten einer angemessenen DoD zu einer technischen Verschuldung oder einer erhöhten Fehlerrate führen, was auch die Geschwindigkeit der Feature-Entwicklung verringern kann.
Hinweis: Die Arbeitsgeschwindigkeit wird nicht reduziert, da das Fehlermanagement auch Arbeit ist.
Kurz gesagt, der Product Owner und das Scrum-Team müssen eine DoD finden, die ausreichend , aber nicht übertrieben ist. Zu viel Prozessaufwand und Funktionsentwicklung leidet darunter. Zu wenig und die Qualität leidet. Es ist ein Balanceakt, weshalb es keinen allgemeingültigen Standard für die Definition of Done gibt.
Diese Frage muss nicht agil orientiert sein, sondern kann agnostisch beantwortet werden, da sie alle Methoden, Produkte und Branchen gleichermaßen betrifft.
Die Antwort lautet: Sie können eine fehlerfreie Freigabe Ihres Produkts nicht gewährleisten .
Diese beiden kursiv gedruckten Wörter implizieren einen Grad an Perfektion, der uns nicht zugänglich ist.
Stattdessen verringern Sie die Gefahr von Fehlern durch Inspektionen, um das Fehlerniveau sowohl auf eine Menge als auch auf einen Schweregrad zu bringen, die innerhalb eines definierten Spezifikationsniveaus liegen.
Das bedeutet, dass das Leitungsgremium diese Definition der Spezifikation für das Produkt als Teil der Definition des Projekts während der Initiierung erstellen muss, und es bedeutet, basierend auf Ihrer Branche zu definieren, was Inspektion bedeutet.
Es bedeutet auch, dass Sie die Gefahr von Fehlern proaktiv mindern, indem Sie Ihre Build-Prozesse und -Methoden ausreifen lassen, bewährte Tools verwenden, qualifiziertes Personal einsetzen und Metriken zur Leistungsmessung verwenden. Metriken können eine zunehmende Gefahr von Fehlern aufdecken, noch bevor ein Fehler im Produkt später im Prozess bemerkt wird.
Die entscheidende Rolle, die ein Product Owner bei der Sicherstellung der Qualität spielt, wird oft übersehen.
Es spielen eine Reihe von Faktoren eine Rolle, darunter:
Der Product Owner trägt zu all diesen Faktoren bei, indem er Folgendes tut:
jitendragarg
Todd A. Jacobs