Gibt es einen Platz für das Prince 2-Mandatsdokument „Qualitätserwartungen“ in einer agilen Entwicklung?

Ich habe unsere IT-Methode formalisiert. Ziemlich ein Scrumban- Ansatz, aber ich muss noch dokumentieren, wo jedes Artefakt und jede Zeremonie produziert oder stattfinden soll.

Die Grundlagen sind

  • Vorschlag
  • Durchführbarkeit
  • Anstoß
  • Erfassung von Anforderungen
  • Sprints
  • Lieferung
  • Projekt Retrospektive

Einer der Business Analysten hat ein Projektauftragsdokument für die Angebotsphase vorgeschlagen. Dies erscheint mir für einen Vorschlag zu aufwendig, insbesondere für den Abschnitt Qualitätserwartungen

vis

Qualitätserwartungen Definieren Sie die Qualitätserwartungen des Kunden unter Bezugnahme auf die relative Bedeutung von Zeit, Kosten und Qualität des Produkts, damit zukünftige Entscheidungen darauf basieren können, welcher Faktor für den Erfolg des Projekts von größter Bedeutung ist.

Vermisse ich etwas, aber den Product Owner zu fragen, was seine Qualitätserwartungen sind, da meine ganze Philosophie darin besteht, keine Kompromisse bei der Qualität einzugehen, es sei denn, sie sind Teil eines verwalteten technischen Schuldenprozesses, bei dem die Amortisation selbstverständlich erfolgt, scheint eine lächerliche Behauptung zu sein .

Die Frage ist also...

Ist es akzeptabel, einen Product Owner zu fragen?

Welche Qualität erwarten Sie von dieser Lösung?

Antworten (1)

Qualität definieren durch eine agile „Definition of Done“

Welche Qualität erwarten Sie von dieser Lösung?

Obwohl es verlockend ist, ist es nicht sinnvoll, die Frage auf diese Weise zu stellen, da dies nicht zu umsetzbaren oder überprüfbaren Kriterien führt. Darüber hinaus ist Umfang (und damit bis zu einem gewissen Grad Qualität) die anpassbare Theory-of-Constraint-Dimension in den meisten agilen Implementierungen.

Stattdessen sollten Sie die agile „Definition of Done“ (DoD) verwenden, um Qualitätskriterien anhand quantifizierbarer Metriken zu definieren. Die Qualitätserwartungen an Ihr Projekt können beispielsweise folgende Dinge beinhalten (sind aber sicherlich nicht darauf beschränkt):

  1. Das Produktinkrement wurde innerhalb des Teams einer Peer-Review unterzogen.
  2. Das Produktinkrement hat den Akzeptanztest durch einen Endbenutzer oder eine UAT-Ressource bestanden.
  3. Physische Produkte wie Zahnräder und Widgets wurden als innerhalb der technischen/mechanischen Toleranzen liegend validiert.
  4. Der Code oder die Systeme wurden anhand der regulatorischen Compliance-Anforderungen validiert.
  5. Das Produktinkrement wurde entsprechend dokumentiert (z. B. Code ist kommentiert, oder Widget-Spezifikationen und Montageanleitungen wurden dem Produkthandbuch hinzugefügt).

Solange die Qualitätskriterien in Ihrer Definition of Done messbar sind, können Sie die Gründlichkeit der Kriterien anpassen, um die Qualitätsziele des Projekts zu erhöhen oder zu verringern. Denken Sie jedoch daran, dass sich Qualität auf andere Projektbeschränkungen wie Budget und Zeitplan auswirkt. Daher müssen Sie Qualitätsziele mit anderen Projektanforderungen (z. B. einem festen Liefertermin) abwägen, um das für eine erfolgreiche Projektabwicklung erforderliche Maß an akzeptabler Qualität zu finden.