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?
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:
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
Sarow
Ashok Ramachandran
Alan Larimer
KJ
Todd A. Jacobs