Agile, Wasserfall- und Anforderungsänderungen

10

Hat jemand dieses Problem eines als "Agil" definierten Projekts durch Anforderungsänderungen überlaufen lassen? Ich arbeite an einem Entwicklungsprojekt, das in 4 Wochen Sprint ausgeführt wird, aber es gibt immer Änderungen zwischen diesen Sprints. Ist es dann immer noch als agil definiert? Ich denke, es ist eine Art subagiler Prozess - Die Anforderungen eines agilen Prozesses sollten zu Beginn eines Sprints definiert und gegen Ende überprüft werden. Habe ich recht damit? Bitte teilen Sie mir Ihre Erfahrungen damit mit.

agile requirements

— Aravind A.
quelle

"Anforderungsänderung" ist ein loser Begriff. Liegt die Änderung daran, dass der Kunde seine Meinung zu einer genehmigten Anforderung tatsächlich geändert hat? Was hat diese Veränderung ausgelöst? Wenn dies weiterhin geschieht, müssen Sie erneut prüfen, wie Sie Anforderungen erfassen. Keine SE-Methodik könnte den Mangel an angemessener Anforderungserfassung berücksichtigen.

— NoChance

@Emmad Die Anforderungsänderungen treten während der UAT auf, wenn Benutzer der Ansicht sind, dass die Benutzerfreundlichkeit auf bestimmte Weise verbessert werden könnte. Dies führt zu Problemen vor der Produktion. Dies ist sicherlich nicht agil.

— Aravind A

@Aravind A: UAT passiert am Ende des Sprints, nicht wahr? Dann sollten alle neuen Ideen / Änderungen, die während der UAT auftauchen, normalerweise zu Geschichten für den nächsten Sprint werden (wenn Sie Sprints verwenden).

— Sleske

Vielleicht funktioniert das, was @sleske vorschlägt, für Sie, aber auch die Benutzerfreundlichkeit kann im Voraus als Prototyp erstellt werden, wenn der Benutzer außergewöhnliche Anforderungen hat. In Projekten, die an Ressourcen gebunden sind, müssen Sie manchmal Ihre Benutzerambitionen kontrollieren.

— NoChance

9

Die Anforderungen eines agilen Prozesses sollten zu Beginn eines Sprints definiert und auf seine überprüft werden. Habe ich recht damit?

Nein, dies hängt von der Art des Projekts (und dem Prozess) ab.

Es gibt einige agile Entwicklungsmodelle, bei denen Anforderungen während eines Sprints festgelegt werden sollen und die sich nur für den nächsten Sprint ändern sollten (ein prominentes Beispiel ist Scrum).

Es gibt jedoch auch Prozesse, bei denen Änderungen fast jederzeit auftreten können (sofern der Kunde die Verzögerungen und die zusätzliche Arbeit akzeptiert, die durch die Änderung verursacht werden). Kanban wird häufig zum Verwalten dieser Workflows verwendet (obwohl Kanban auch mit Scrum kombiniert werden kann).

Welches Modell Sie verfolgen, hängt von den Details jedes Projekts ab.

Ja, wenn der Kunde der Meinung ist, dass er die Möglichkeit benötigt, die Anforderungen ständig zu ändern, kann ein agiler Prozess dies berücksichtigen. Der Kunde sollte sich jedoch der Konsequenzen ständiger Änderungen bewusst sein und verstehen, dass er das Projekt verlangsamen wird.

Dies läuft auf die Prinzipien des agilen Manifests hinaus - "Individuen und Interaktionen über Prozesse und Werkzeuge" und "Reagieren auf Änderungen nach einem Plan".

— sleske
quelle

Macht der Prozess nicht offen agil? Ich meine, wie weit kann die Beweglichkeit gehen? Wenn ein Entwickler eine Anforderung zum ersten Mal erfüllt, besteht beim nächsten Mal zwangsläufig eine Anforderung. Ich denke, dies ist eines der vielen Probleme, die dazu führen, dass die Codequalität beeinträchtigt wird.

— Aravind A

@AravindA Die Codequalität sollte ein gesondertes Anliegen sein. Unabhängig davon, wie oft sich der Code ändert, sollte sich das Team stets auf dieselben Codequalitätsstandards konzentrieren. In der Tat ist die Codequalität wichtiger, da sich Anforderungen und Code ständig ändern.

— maple_shaft

2

@maple_shaft ist richtig - Qualität ist (zumindest meistens) orthagonal zur Anforderungsänderung. Geben Sie mir eine Anfrage: Ich fange an, guten Code zu schreiben. Wenn ich fertig bin und eine neue Anforderung erhalte oder halb fertig bin und eine Änderung erhalte, beginne ich, guten Code (neu) zu schreiben. Nachdem die Auswirkungen auf den aktuellen Zeitplan / die Verpflichtung / etc. Hervorgehoben wurden.

— SDG

Anforderungsänderungen, die einen großen Einfluss auf die Architektur des Systems haben, führen zu erheblichen Verzögerungen oder Qualitätseinbußen. Aus diesem Grund sollten Sie eine gute alte wasserfallähnliche Analyse durchführen (kann auch iterativ sein), bei der Sie versuchen, das Risiko ihres "plötzlichen" Auftretens zu verringern.

— MaR

@sles Danke für die Erklärung. Ich glaube, ich verstehe es jetzt. Ich denke, ich muss Agile besser kennenlernen.

— Aravind A

12

Ich denke, die Frage, die Sie stellen sollten, lautet: Warum werden Sie von Änderungen der Anforderungen überrannt? Häufige Ursachen sind:

Die Entwickler haben nicht (genug) Kontakt zu Endbenutzern, sodass sie die Bedürfnisse der Benutzer nicht verstehen können. Stattdessen behandeln sie Anforderungen wie einen abstrakten Zauberwürfel - sie folgen den Buchstaben der Anforderungen, ohne zu versuchen, ihren Geist zu verstehen
Jemand (z. B. aus dem Marketing) fügt Anforderungen hinzu, die für den Endbenutzer keinen Sinn ergeben (z. B. in einer Broschüre gut klingen). Es gibt also einen Kampf zwischen "echten" Anforderungen und "anderen" Anforderungen, der auf dem Rücken der Entwickler ausgetragen wird
Der Umfang des Projekts ist undefiniert ("Wenn Sie sowieso ein Textverarbeitungsprogramm implementieren, können Sie dann nicht einfach ein kleines Modul hinzufügen, das unsere Lohnbuchhaltung übernimmt? Oh, und Bill vom anderen Entwicklungsteam fragte, wie schwierig es wäre soll das Textverarbeitungsprogramm auch C ++ - Code kompilieren? ")

Was auch immer das Grundproblem ist, Sie müssen es beheben. Das Ertrinken unter "Agile" (oder einer anderen Methode) funktioniert nicht.

— Nikie
quelle

@ Nike Danke. Genau das habe ich mir gedacht. Ihr dritter Punkt passt in mein Szenario. Einige Kunden nutzen einfach die Arbeit 'Agile' und denken, es sei eine Silberkugel, um die Arbeit schneller zu erledigen.

— Aravind A

9

Zumindest in Scrum, dem Agile-Prozess, der heutzutage bei Managementtypen am beliebtesten ist, ist der Umfang eines Sprints festgelegt. Wenn sich Ihr Sprint-Backlog während des Sprints ändert, ist das nicht Scrum, sondern Chaos. Das Sprint-Backlog sollte zu Beginn des Sprints erstellt werden und bis zum Ende des Sprints fixiert bleiben (an diesem Punkt erstellen Sie ein neues Sprint-Backlog für den nächsten Sprint).

Wenn sich Ihr Product Backlog während eines Sprints ändert, ist das keine große Sache. Die Änderungen werden zu neuen Arbeiten, die wie jede andere Anforderung für den nächsten Sprint priorisiert, geschätzt und ausgewählt werden. Wenn sich die Anforderungen so stark ändern, dass der Product Owner den Sprint regelmäßig abbrechen muss, haben Sie Probleme mit einem Großbuchstaben "T".

Vielleicht brauchst du kürzere Sprints?

— Adam Jaskiewicz
quelle

+1 für kürzere Sprints. Skalieren Sie auf 2 Wochen zurück und prüfen Sie, ob es hilft.

— John

1

4 Wochen klingen für einen Sprint in der Tat ziemlich lang, insbesondere bei einem Projekt, das unter Anforderungsinstabilität leidet.

— Carson63000

7

Für die Vernunft der Programmierer ist es am besten, wenn sich die Anforderungen während einer Revision / eines Sprints nicht ändern.

In Ihrer Situation gibt es zwei offensichtliche Optionen:

kürzere Sprints
Lassen Sie den Kunden zustimmen, die Anforderungen während einer Revision / eines Sprints nicht zu ändern, es sei denn, die gesamte Revision / der Sprint wird abgebrochen und neu geplant

Ich kann beides nur empfehlen .

— Steven A. Lowe
quelle

3

Das Hauptproblem ist, dass Sie glauben, dass Sie Scrum verwenden, dies aber nicht. Insbesondere Ihr Produktbesitzer folgt ihm nicht. In Scrum ist ein Sprint eine sichere Zone und es können keine Änderungen an festgeschriebenen User Stories vorgenommen werden, es sei denn, der aktuelle Sprint wird abgebrochen. Es liegt in der Verantwortung von Scrum Master, dies durchzusetzen. Wenn dies in Ihrer Umgebung nicht funktioniert, handelt es sich um ein Prozessproblem = Sie verwenden Scrum nicht.

Die einfachste Änderung, die Sie vornehmen können (wenn Sie Scrum folgen möchten), besteht darin, Ihren Sprint zu verkürzen - beispielsweise eine Woche. 4-wöchige Sprints wurden in den frühen Tagen von Scrum als Option in Betracht gezogen, aber heute sind es 1 - 2 Wochen und 3 Wochen als obere Grenze. 4 Wochen sind eine sehr lange Zeit in einer sich verändernden Umgebung.

— Ladislav Mrnka
quelle