Agile, Cascata e modifiche dei requisiti

The requirements of an Agile process should be defined at the beginning of a sprint and reviewed towards its . Am I right in this?

No, questo dipende dalla natura del progetto (e dal processo).

Ci sono alcuni modelli di sviluppo agili in cui i requisiti devono essere corretti durante uno sprint e dovrebbero essere modificati solo per il prossimo sprint (un esempio importante è Scrum).

Tuttavia, ci sono anche processi in cui i cambiamenti possono accadere quasi in qualsiasi momento (a condizione che il cliente accetti i ritardi e il lavoro extra che il cambiamento comporta). Il Kanban è spesso usato per gestire questi flussi di lavoro (anche se Kanban può anche essere combinato con Scrum).

Il modello che segui dipende dai dettagli di ciascun progetto.

Quindi sì, se il cliente sente di aver bisogno della possibilità di cambiare continuamente i requisiti, allora un processo agile può adattarsi a questo. Tuttavia, il cliente deve essere consapevole delle conseguenze dei cambiamenti costanti e dovrebbe capire che rallenterà il progetto.

Questo si riduce ai principi del manifesto agile - "Individui e interazioni su processi e strumenti", e "Rispondere al cambiamento nel seguire un piano ".

Penso che la domanda che dovresti porre sia: perché sei invaso dai cambiamenti dei requisiti? Le cause comuni includono:

• Gli sviluppatori non hanno (abbastanza) contatti con gli utenti finali in modo che non possano capire le esigenze degli utenti. Invece trattano i requisiti come un cubo di Rubik astratto - seguono le lettere dei requisiti senza nemmeno cercare di capire il loro spirito
• Qualcuno (ad esempio dal marketing) sta aggiungendo requisiti che non hanno alcun senso per l'utente finale (ma, ad esempio, suona bene su una brochure). Quindi c'è una battaglia tra requisiti "reali" e "altri" requisiti combattuti alle spalle degli sviluppatori
• L'ambito del progetto non è definito ("Beh, se stai implementando un word processor in ogni caso, non potresti semplicemente aggiungere un piccolo modulo che fa la contabilità delle retribuzioni? Oh, e Bill dell'altro team di sviluppo ha chiesto come sarebbe difficile far sì che anche il word processor compilasse il codice C ++? ")

Qualunque sia il problema di root, devi risolverlo. Affogarlo sotto strati di "Agile" (o qualsiasi altra metodologia) non funzionerà.

In Scrum almeno, che sembra essere il processo Agile più popolare con i tipi di gestione in questi giorni, l'ambito di uno Sprint è stato risolto. Se lo Sprint Backlog sta cambiando durante lo sprint, quello non è Scrum, è il caos. Lo Sprint Backlog dovrebbe essere creato all'inizio dello sprint e rimanere fisso fino alla fine dello sprint (a quel punto si crea un nuovo Sprint Backlog per lo sprint successivo).

Se il tuo Product Backlog sta cambiando durante uno sprint, non è un grosso problema. Le modifiche diventano solo un nuovo lavoro che viene definito come prioritario, stimato e selezionato come qualsiasi altro requisito per il prossimo sprint. Se i requisiti cambiano così tanto che il Product Owner deve annullare lo sprint regolarmente, però, hai problemi con una "T" maiuscola.

Forse hai bisogno di sprint più brevi?

Per la sanità mentale dei programmatori è meglio che i requisiti non cambino durante una revisione / sprint.

Nella tua situazione, ci sono due opzioni ovvie:

1. sprint più brevi
2. consente al cliente di accettare di non modificare i requisiti durante una revisione / sprint a meno che l'intera revisione / sprint sia cancellata e riprogrammata

Consiglio vivamente entrambi .

Il problema principale è che credi di utilizzare Scrum, ma non lo fai. Soprattutto il proprietario del tuo prodotto non lo segue. In Scrum uno sprint è una zona sicura e non è possibile apportare modifiche agli user story impegnati a meno che lo sprint corrente non venga annullato. È responsabilità dello Scrum master far rispettare questo. Se questo non funziona nel tuo ambiente, allora è un problema di processo = non stai usando Scrum.

Il cambiamento più semplice che puoi fare (se vuoi seguire Scrum) è rendere il tuo sprint più breve - una settimana per esempio. Sprint di 4 settimane sono stati considerati come opzione nei primi giorni di Scrum, ma oggi è comune 1 - 2 settimane e 3 settimane è considerato come limite superiore. 4 settimane sono molto tempo nel cambiare ambiente.