Priorisierung von Anforderungen in traditionellen vs. agilen Projekten

Ich bin wirklich neu in der Priorisierung von Anforderungen in agilen Projekten. Was sind die unterschiedlichen Aspekte der Priorisierung von Anforderungen in einem traditionellen Ansatz im Vergleich zu einem agilen Ansatz?

Nach der Bearbeitung ist es nicht mehr zu breit, obwohl es vielleicht zu meinungsbasiert ist; Ich bin mir ehrlich gesagt unsicher. Ich werde für die Wiedereröffnung stimmen und wir werden sehen, was die Community denkt.
Hier ist ein Artikel Agile vs Waterfall: Requirement Gathering . Vielleicht hilft dir das beim Einstieg. Wenn Sie danach spezifischere Fragen haben, können Sie Ihre Frage bearbeiten oder eine andere stellen.
Die Priorisierung von Anforderungen findet bei vielen traditionellen (PMI-basierten) Bemühungen nicht statt; alles ist einfach im Rahmen.
Nicht so viel Unterschied. Anforderungen haben Attribute, die in beiden Fällen zutreffen und sollten vollständig, konsistent, eindeutig, priorisiert, notwendig, modifizierbar, nachvollziehbar usw. sein. Die Priorisierung sollte eine kollaborative Aktivität sein, an der verschiedene Stakeholder beteiligt sind; Überprüfen Sie beim Sortieren den Bedarf, das Timing, die Kosten usw. MoSCoW ist ein Priorisierungsschema, suchen Sie es. Erfahren Sie auch mehr über Story Points, siehe pm.stackexchange.com/questions/4251/…
Es könnte auch nützlich sein zu beachten, dass viele traditionelle Projekte Anforderungen nicht wirklich einordnen; Sie filtern einfach Spezifikationen in oder aus dem Projekt heraus. Es gibt sicherlich Priorisierungstechniken, die mit jedem Framework verwendet werden können, aber ordinale Rankings werden nur von Scrum AFAIK benötigt.

Antworten (4)

Unterschiede bei der Priorisierung von Anforderungen zwischen Wasserfall und Scrum

Der vorherrschende Softwareentwicklungsprozess vor dem Erscheinen von Agile war der Wasserfallprozess. Scrum ist der beliebteste agile Prozess. Ich werde versuchen, einige wesentliche Unterschiede zwischen Wasserfall und Scrum aufzulisten, wie ich sie sehe:

  1. Der Kompromiss zwischen Kosten und Nutzen ist ein Schlüsselaspekt von Agile : Im agilen Prozess schätzen die Teams die Story-Größe in Story Points, und dies gibt dem Product Owner die Möglichkeit, sie zu priorisieren, da sie ihre relativen Kosten kennen. In Waterfall werden selten, wenn überhaupt, individuelle Anforderungen geschätzt. Auf jeden Fall gibt es kaum Gelegenheit für eine Kosten-Nutzen-Abwägungsdiskussion.

  2. In Agile ändern sich die Anforderungen ständig : In Waterfall ist es sehr schwierig, Anforderungen zu ändern – Sie müssen einen schmerzhaften Änderungskontrollprozess durchlaufen. Agile nimmt sich ändernde Anforderungen an. Wie Sie im Scrum Guide sehen können :

    Das Product Backlog ist dynamisch; es ändert sich ständig, um zu ermitteln, was das Produkt braucht, um angemessen, wettbewerbsfähig und nützlich zu sein.

  3. In Waterfall werden die Anforderungen typischerweise in 3 oder 4 Buckets gruppiert : Einige Leute gruppieren sie in Hoch, Mittel und Niedrig, andere verwenden die MoSCoW-Methode . Aber in Agile werden alle Geschichten in fortlaufender Reihenfolge aufgelistet. Dies hilft dem Entwicklerteam, sich in der Liste nach unten zu arbeiten.

  4. Agile hat eine einzige Autorität für die Priorisierung : Agile benennt den Product Owner als die einzige Autorität für die Priorisierung. In Waterfall gibt es keine solche benannte Behörde. Oft ist es eine Entscheidung des Komitees.

  5. Viele Agile-Teams verwenden den Begriff eines MVP : Viele Agile-Teams arbeiten eine Teilmenge von Anforderungen in ein MVP (Minimum Viable Product) aus. Das MVP wird häufig einer Stichprobe von Benutzern bereitgestellt, um frühzeitig Feedback zu erhalten.

Keine kanonische Antwort

Auf diese Frage gibt es keine wirklich kanonische Antwort. Im Allgemeinen ist die Priorisierung von Arbeit spezifisch für die Geschäftsziele der Organisation, die Zuordnung von Arbeitsergebnissen zu angestrebten Veröffentlichungsterminen und die Abhängigkeiten von Arbeitspaketen. Dies gilt normalerweise unabhängig davon, ob die Methodik agil ist oder nicht.

Die pragmatische Sicht

Pragmatisch folgen agile Methoden im Allgemeinen einem warteschlangenbasierten oder ordinalen Priorisierungsschema, bei dem jeder Arbeitsstrom zu jedem Zeitpunkt eine (und nur eine) „Priorität Nr. 1“ hat. Dies steht im Gegensatz zu vielen traditionellen Methoden, bei denen keine strenge Reihenfolge der Prioritäten erzwungen wird.

Nicht agile Projekte verwenden in der Regel ein zeitplanbasiertes System, das auf vom Management definierten Lieferzielen basiert, und die Zeitpläne basieren häufig auf Ertragswert- oder Kapitalwertberechnungen. In der realen Welt führt dies oft dazu, dass viele konkurrierende Anforderungen alle undifferenziert „höchste Priorität“ für das Unternehmen haben. Ihre Laufleistung kann jedoch sicherlich variieren.

Beispieltechniken

Unabhängig von der Methodik kann die Priorisierung eine beliebige Anzahl von Techniken verwenden, die weitgehend durch Ihre organisatorische Vorstellungskraft begrenzt sind. Einige Beispiele sind:

Viele Techniken sind nicht von Natur aus agil oder nicht agil. Einige funktionieren gut, wenn sie zusammen verwendet werden, und die meisten sind so konzipiert, dass sie den Projektplanungsprozess unterstützen, anstatt ihn zu ersetzen. Auch hier kann Ihr Kilometerstand variieren.

Um Aufgaben zu priorisieren, müssen Sie einige Techniken kennen:

  1. Moskau
    Welche sind Muss, Soll, Könnte und Wird nicht
  2. Minimale marktfähige Funktionen
    Funktionen werden in die kleinsten marktfähigen Einheiten mit nützlichem, lieferbarem Geschäftswert zerlegt, um in kurze Iterationen zu passen und sicherzustellen, dass kritische Funktionalität zuerst implementiert wird
  3. Return on Investment (ROI)
    Zeigt, wie viel Rendite ein Unternehmen durch Investitionen in Prozent erzielt
  4. Interne
    Rendite Eine Möglichkeit, den Gewinn als verdienten Zinssatz auszudrücken.

Und es gibt noch viele andere, aber ich denke, das sind die wichtigsten.

Aber die Priorisierung übernimmt in der Regel der Kunde.

Der Unterschied zwischen Agile und dem traditionellen Ansatz besteht darin, dass bei Agile der Kunde die Priorisierung vornimmt, da er das Ergebnis sehr bald sehen muss, aber bei den traditionellen Projekten sieht er das Ergebnis am Ende, sodass Sie sich nicht um die Reihenfolge kümmern müssen die Aufgaben.

Technisch getrieben vs. wertorientiert

Es ist oft wahr, dass Anforderungen beim Wasserfall einfach innerhalb oder außerhalb des Umfangs liegen und der Kunde nichts bekommt, bis es erledigt ist. Aber die Arbeit wird oft trotzdem priorisiert, weil sie seriell passiert. In diesem Fall können die Anforderungen rein technisch priorisiert werden: Wie geht man mit Blick auf das Gesamtprojekt am effizientesten vor? und/oder wie geht man am wenigsten riskant vor?

Bei Agile ist die Priorisierung wertorientiert, und die inkrementellen Releases gehen oft an den Kunden. Während technische Überlegungen und Risikoüberlegungen mit dem Kunden besprochen werden sollten, damit er fundierte Entscheidungen treffen kann, sieht die Priorisierung des Kundennutzens normalerweise nicht wie die technisch sinnvolle Priorisierung aus. So kann es zum Beispiel oft der Fall sein, dass eine minimale Infrastruktur frühzeitig erstellt wird, um relativ einfache, aber sehr wertvolle Funktionen zu unterstützen; und dass es später herausgerissen und durch eine robustere Infrastruktur ersetzt wird, um komplexere, aber weniger wertvolle Funktionen zu unterstützen.