Priorisierung sowohl funktionaler als auch nicht funktionaler Anforderungen in Agile

Es gibt zwei Ansätze, die ich dafür gesehen habe.

1. Das Entwicklungsteam besitzt Engineering-Qualität

Bei diesem Ansatz konzentrieren sich die nicht-technischen Stakeholder (und der Product Owner, wenn Scrum verwendet wird) ausschließlich auf die funktionalen Anforderungen. Das Entwicklungsteam besitzt die nicht funktionale Seite der Dinge, legt seine eigenen nicht funktionalen Standards fest und fügt dem Backlog seine eigenen Arbeitselemente hinzu, um diese Standards zu erfüllen.

Zum Beispiel könnte ein Entwicklungsteam so etwas sagen wie:

• Die Seitenantwortzeit auf einem repräsentativen Server ist nicht schlechter als 4 Sekunden
• Alle wichtigen Funktionen werden überwacht
• Alle Daten werden gesichert und können in 8 Stunden oder weniger wiederhergestellt werden

Das Team würde dann an funktionalen Anforderungen arbeiten, aber die ganze Zeit sicherstellen, dass ihre technischen Standards erfüllt werden.

2. Erstellen Sie User Stories für nicht-funktionale Anforderungen

Bei diesem Ansatz werden nichtfunktionale Anforderungen im Backlog dargestellt. Dazu können Geschichten gehören wie:

Als Benutzer möchte ich, dass Webseiten in weniger als 4 Sekunden zurückkehren, damit ich mein Surferlebnis genießen kann

Als Benutzer möchte ich sicher sein, dass meine Daten im Falle eines Serverausfalls nicht verloren gehen, sodass ich mir keine Gedanken über Datenverlust machen muss

Als Benutzer möchte ich sicher sein, dass mein Produktbericht korrekt ist und die Zahlen übereinstimmen, damit ich die Daten im Bericht vertrauensvoll verwenden kann

Diese User Stories werden neben funktionalen im Product Backlog priorisiert.

Scrum basiert auf den Prinzipien und Grundlagen der agilen Methodik.

Ein Schlüsselprinzip ist die Erkenntnis, dass Kunden ihre Meinung ändern können und wahrscheinlich auch ändern werden (was sie wollen, wie sie es wollen und wann sie es wollen). Diese Volatilität bedeutet, dass Anforderungen nicht einfach auf herkömmliche vorausschauende oder geplante Weise angegangen werden können.

Der Product Owner (PO) ist eine von drei Rollen, die innerhalb der Scrum-Methodik definiert sind. Er ist normalerweise jemand mit einem soliden Verständnis des Geschäfts, der Organisation und des Marktes, der die Interessengruppen des Projekts vertritt.

PO ist dafür verantwortlich, eine priorisierte Liste von Anforderungen zu erstellen, die als Product Backlog bezeichnet wird (kann direkt mit einem Produktmanager zusammenarbeiten, um die Product Backlog-Anforderungen bewerten zu können). Diese Anforderungen sind nach Themen (Aggregation der Anforderungen), Epics (große Anforderungen, die detailliert werden müssen) und Stories (detaillierte Anforderungen aus Sicht des Produktbenutzers) organisiert.

Diese Anforderungen werden dann vom Team mithilfe von Techniken wie Planungspoker geschätzt.

Während der Sprintplanung beschreibt der PO die vorrangigen Anforderungen des Teams. Diese Beschreibung ermöglicht eine detailliertere Planung der Aktivitäten, die zur Entwicklung der prioritären Anforderungen erforderlich sind.

Um Ihre Frage zu beantworten, erfolgt die Priorisierung der Anforderungen in zwei verschiedenen Phasen

• Beim Erstellen des Product Backlogs. Hier haben wir die Stakeholder mit PO. Die Priorisierung hängt hier stark von den Zielen ab, die die Stakeholder zu erreichen versuchen. Nehmen wir an, wir entwickeln zwei Anwendungen (eine für Android und eine für iOS) und die Beteiligten veranstalten eine Konferenz (aus welchen Gründen auch immer), auf der sie das Produkt einem Publikum präsentieren möchten, das hauptsächlich iPhones verwendet. Sie möchten iOS den Vorrang geben App.

• Während der Sprintplanung. Hier haben wir PO und Team. Diese Phase findet nach der oben genannten statt, sodass den Anforderungen bereits eine bestimmte Priorität zugeordnet und von den Interessengruppen vereinbart wurde. Nichtsdestotrotz kann sich die Priorität für den bevorstehenden Sprint aufgrund von Einschränkungen ändern. Ich habe zum Beispiel als Entwickler mit einem Team gearbeitet, das bestimmte Prioritäten neu ordnen musste, weil die Mockups noch genehmigt werden mussten (es war ein sehr ungewöhnlicher Fall, wo die Lösung für gestern gemacht werden musste, die User Stories wurden ohne erstellt viele Informationen und vordefiniertes Design, aber die Dinge mussten sich bewegen).

PS Sie mögen vielleicht die folgende Frage, die ich gestellt habe .