Wie geht man mit dem Overhead von QA-Protokollierungsfehlern um, an deren Behebung POs nicht interessiert sind?

Ich habe oft beobachtet, dass Fehler in bestimmten Storys protokolliert wurden, was Product Owner viel Zeit für die Sichtung kostete, die am Ende nicht wichtig genug waren, um sie zu beheben. Entweder ist es ein akzeptables Verhalten, das keine wesentlichen Auswirkungen auf den Kunden hätte, oder es ist einfach etwas, das Product Owner nicht für so wichtig halten wie etwas anderes im Backlog. Wie kann diesem Phänomen begegnet werden, damit Teams in Bewegung bleiben?

Es klingt wie eine Trennung zwischen QA und PO in Bezug auf die Akzeptanzkriterien. Sie sollten sich beide darauf einigen, was „erledigt“ ist.

Antworten (3)

Das klingt nach einem guten Thema für die Retrospektive des Teams. Es gibt viele mögliche Herangehensweisen, aber das Team sollte für sich selbst entscheiden.

Einige Dinge, die Sie in Betracht ziehen könnten:

  • Die QA zeigt dem Product Owner Fehler, bevor sie diese protokollieren
  • Wenn ein Fehler vom Product Owner nicht als wichtig angesehen wird, beheben Sie ihn als "wird nicht behoben".
  • Besprechen Sie im Team die Arten von Fehlern, die möglicherweise nicht protokolliert werden müssen
+1. Standardmäßig immer "das Team fragen". Wenn sie zurückdrängen und trotzdem Fehler protokollieren möchten, erinnern Sie sie daran, dass der Product Owner für die Verwaltung des Rückstands verantwortlich ist und dass die Entscheidung des PO respektiert werden muss. Letzte Nuance, das Entwicklerteam besitzt die Qualität. Wenn Fehler also wichtig genug sind, sind sie verpflichtet, ihr Bestes zu geben, um den PO von ihrer Wichtigkeit und Aufnahme in das Produkt-Backlog zu überzeugen.

Ich würde vorschlagen, dass Sie alle Probleme für neue Storys beheben, ohne überhaupt zum Product Owner zu gehen. Wenn Sie ständig Fehler erstellen und diese nicht beheben, ist dies ein Zeichen für ein Qualitätsproblem. Es tut mir leid, das sagen zu müssen, aber wenn Sie dies lange genug tun, werden Sie in große Schwierigkeiten geraten.

Wäre es nicht traditionell Sache des Product Owners, zu entscheiden, ob es sich um einen Fehler handelt oder nicht? In vielen dieser Fälle sehen der Product Owner (und die Ingenieure) die Probleme überhaupt nicht als Fehler.
Nicht unbedingt @BrianDavidBerman. Einige Teams verfolgen eine „Null bekannter Fehler“-Richtlinie und behandeln dies als eine Frage der Technik und Qualität.
@RubberDuck Irgendwelche Lektüre zu diesem Thema in der Agile-Community? Meine gesamte Forschung/Praxis hat gezeigt, dass der Product Owner der Torwächter für das ist, woran das Team arbeitet. Sie berücksichtigen die Meinungen des restlichen Teams, aber am Ende liegt es an ihnen.
@BrianDavidBerman Ich würde vorschlagen, dass Sie "Null Fehler" zu einem Teil Ihrer Definition of Done machen ( agilealliance.org/glossary/definition-of-done ). Auf diese Weise müssen Sie nicht zum PO gehen, um zu entscheiden, ob ein Fehler behoben werden soll oder nicht.
„Meine gesamte Forschung/Praxis hat gezeigt, dass der Product Owner der Torwächter für das ist, woran das Team arbeitet.“ -- dies gilt, soweit es um neue Funktionen geht. Das Team ist dafür verantwortlich, Qualitätsprodukte zu liefern, was nicht unbedingt die Bestellung beinhaltet.
@MitaKa - Ich mag die Idee, der Definition of Done "Null Fehler" hinzuzufügen, aber ich denke, in vielen Fällen, die ich beschreibe, ist es nicht nur die Bestellung, die nicht einverstanden ist, ob etwas ein Fehler ist oder nicht. es ist der gesamte Rest des Teams. Wenn unsere Kapazität plötzlich mit Bugfixes gefüllt ist, die nicht vom PO validiert wurden, könnten wir technisch gesehen an Problemen arbeiten, die das Unternehmen nicht als wertvoll ansieht, und das Management könnte diese Entscheidungen in Frage stellen. Ich frage mich, ob es bei meinem Problem nur darum gehen könnte, zu definieren, was ein Fehler ist und was nicht.

Aus Sicht der QA ist es sehr wichtig, dass jeder Fehler irgendwo aufgezeichnet wird (entweder im Backlog oder an einer anderen Stelle). Während des Testens ist es sehr unpraktisch, wenn Sie für jeden Befund zuerst analysieren müssen, ob er wichtig genug ist oder nicht - das verlangsamt den Testprozess und Sie riskieren, wesentliche Fehler zu übersehen (weil Sie sie mit ähnlichen Fehlern mit unterschiedlichen Ursachen verwechseln).

In unserem Team haben wir einige Diskussionen zu diesem Thema geführt, und am Ende haben wir uns für Folgendes entschieden:

  1. Stellen Sie sicher, dass den Testern klar ist, was die Stakeholder erwarten (Anforderungen, Dinge, die außerhalb des Umfangs liegen, Qualitätsniveau usw.)
  2. Die Testaktivitäten werden von einer Produktrisikobewertung geleitet – die wichtigsten Teile (hohe Ausfallwahrscheinlichkeit oder hohe Auswirkungen) erhalten die meiste Aufmerksamkeit (dadurch werden bereits viele nicht wesentliche Fehler herausgefiltert).
  3. Jedes Problem wird beim Testen aufgezeichnet.
  4. Nach jedem signifikanten Testaufwand werden Probleme geclustert und analysiert. Die Tester bereiten das Meeting vor, der Product Owner entscheidet über die Priorität (blockierende Probleme haben die höchste Priorität)
  5. Probleme mit hoher Priorität erhalten auch einen hohen Rang im Rückstand
  6. Probleme mit niedriger oder niedrigster Priorität werden selten einzeln behoben; Stattdessen werden sie gelöst, wenn verwandte Arbeiten im selben Bereich ausgeführt werden

So sind die Grenzen zwischen den verschiedenen Prioritätsklassen für alle transparent (und können sich im Laufe der Zeit verschieben). Tester können jeden Fehler protokollieren, während der Product Owner eine Zusammenfassung seiner Ergebnisse hört und sich auf die wichtigsten konzentrieren kann.

Wie geht man mit dem Overhead von QA-Protokollierungsfehlern um, an deren Behebung POs nicht interessiert sind?
AntwortenHierDatenschutz-Bestimmungen1y, 0v