Agile, cascata e modifiche ai requisiti

10

Qualcuno ha avuto questo problema di un progetto definito come 'Agile' superato da cambiamenti di requisiti? Lavoro a un progetto di sviluppo che viene eseguito in Sprint per 4 settimane ma ci sono sempre cambiamenti tra questi Sprint. Allora è ancora definito come Agile? Sento che è una sorta di processo sub Agile - I requisiti di un processo Agile dovrebbero essere definiti all'inizio di uno sprint e rivisti verso la fine. Ho ragione in questo? Per favore fatemi sapere le vostre esperienze in questo.

agile requirements

— Aravind A
fonte

"Modifica dei requisiti" è un termine generico. La modifica è dovuta al fatto che il cliente ha effettivamente cambiato idea su un requisito approvato? Cosa ha innescato quel cambiamento? Se ciò accade, è necessario riesaminare il modo in cui vengono raccolti i requisiti. Nessuna metodologia SE potrebbe soddisfare la mancanza di un'adeguata raccolta dei requisiti.

— NoChance,

@Emmad Le modifiche ai requisiti si verificano durante l'UAT quando gli utenti ritengono che l'usabilità possa essere migliorata con determinati mezzi. Ciò provoca un accumulo di problemi pre-produzione. Questo certamente non è Agile.

— Aravind,

@Aravind A: UAT accade alla fine dello sprint, vero? Quindi eventuali nuove idee / modifiche che emergono durante l'UAT dovrebbero normalmente diventare storie per lo sprint successivo (se si utilizzano gli sprint).

— sleske,

Forse ciò che suggerisce @sleske funziona per te, ma anche la facilità di usabilità può essere prototipata in anticipo se l'utente ha requisiti eccezionali. A volte, nei progetti vincolati da risorse, è necessario controllare le ambizioni degli utenti.

— NoChance,

9

I requisiti di un processo Agile dovrebbero essere definiti all'inizio di uno sprint e rivisti verso di esso. Ho ragione in questo?

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

Esistono alcuni modelli di sviluppo agili in cui i requisiti devono essere fissati durante uno sprint e dovrebbero cambiare solo per lo sprint successivo (un esempio importante è Scrum).

Tuttavia, ci sono anche processi in cui i cambiamenti possono avvenire quasi in qualsiasi momento (purché il cliente accetti i ritardi e il lavoro extra che provoca il cambiamento). Kanban viene spesso utilizzato per gestire questi flussi di lavoro (anche se Kanban può anche essere combinato con Scrum).

Quale modello segui dipende dai dettagli di ciascun progetto.

Quindi sì, se il cliente ritiene di aver bisogno della possibilità di cambiare costantemente i requisiti, allora un processo agile può adattarlo. Tuttavia, il cliente dovrebbe essere consapevole delle conseguenze di cambiamenti costanti e comprendere che rallenterà il progetto.

Questo si riduce ai principi del manifesto agile : "Individui e interazioni su processi e strumenti" e "Rispondere al cambiamento seguendo un piano".

— sleske
fonte

Il processo non rende apertamente agile? Voglio dire, quanto lontano può arrivare l'agilità? Se uno sviluppatore soddisfa un requisito per la prima volta, ci sarà sicuramente una domanda la volta successiva. Penso che questo sia uno dei tanti problemi che causano il lancio della qualità del codice.

— Aravind,

@AravindA La qualità del codice dovrebbe essere una preoccupazione separata e indipendentemente da quante volte il codice cambia, il team dovrebbe concentrarsi sempre sugli stessi standard di qualità del codice. In effetti, la qualità del codice è più importante perché i requisiti e il codice cambiano costantemente.

— maple_shaft

2

@maple_shaft ha ragione: la qualità è (almeno per lo più) orthagonal rispetto alla modifica del requisito. Fammi una domanda: inizio a scrivere un buon codice. Se ho finito, ricevo un nuovo req, o mezzo lavoro e ottengo una modifica, inizio (ri) scrivendo un buon codice. Dopo aver evidenziato l'impatto sull'attuale programma / impegno / ecc.

— sabato

Le modifiche ai requisiti che hanno una grande influenza sul modo in cui il sistema è progettato causeranno notevoli ritardi o compromessi di qualità. Ecco perché dovresti fare qualche buona analisi a cascata (può anche essere iterativa) in cui provi a ridurre il rischio del loro aspetto "improvviso".

— MaR

@sles Grazie per la spiegazione. Penso di averlo capito adesso. Penso che dovrò conoscere meglio Agile.

— Aravind,

12

Penso che la domanda che dovresti porre sia: perché sei invaso dalle modifiche ai requisiti? Le cause più comuni includono:

Gli sviluppatori non hanno (abbastanza) contatti con gli utenti finali, quindi non possono 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 es. Dal marketing) sta aggiungendo requisiti che non hanno alcun senso per l'utente finale (ma ad es. Suona bene su una brochure). Quindi c'è una battaglia tra requisiti "reali" e requisiti "altri" che si combattono sul retro degli sviluppatori
L'ambito del progetto non è definito ("Beh, se stai implementando un word processor, non potresti semplicemente aggiungere un piccolo modulo che fa la nostra contabilità dei salari? Oh, e Bill dell'altro team di sviluppo ha chiesto quanto sarebbe difficile far compilare anche il codice C ++ nell'elaboratore di testi? ")

Qualunque sia il problema alla radice, è necessario risolverlo. Annegarlo sotto strati di "Agile" (o qualsiasi altra metodologia) non funzionerà.

— nikie
fonte

@nike Grazie. Questo è proprio quello che pensavo. Il tuo terzo punto rientra nel mio scenario. Alcuni clienti approfittano del lavoro "Agile" pensando che sia un proiettile d'argento per svolgere il lavoro più velocemente.

— Aravind,

9

Almeno in Scrum, che sembra essere il processo Agile più popolare tra i tipi di gestione in questi giorni, l'ambito di uno Sprint è fisso. Se il tuo Sprint Backlog sta cambiando durante lo sprint, non è Scrum, è il caos. Lo Sprint Backlog deve 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 nuove opere prioritarie, stimate e selezionate come qualsiasi altro requisito per il prossimo sprint. Se i requisiti cambiano così tanto che il Product Owner deve annullare lo sprint su base regolare, tuttavia, hai problemi con una "T" maiuscola.

Forse hai bisogno di sprint più brevi?

— Adam Jaskiewicz
fonte

+1 per gli sprint più brevi. Ridimensiona a 2 settimane e vedi se aiuta.

— Giovanni,

1

In effetti, 4 settimane sembrano piuttosto lunghe per uno sprint, specialmente su un progetto che soffre di instabilità.

— Carson63000,

7

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

Nella tua situazione, ci sono due opzioni ovvie:

sprint più brevi
indurre il cliente a concordare di non modificare i requisiti durante una revisione / sprint a meno che l'intera revisione / sprint non venga annullata e riprogrammata

Consiglio vivamente entrambi .

— Steven A. Lowe
fonte

3

Il problema principale è che credi di usare Scrum ma non lo fai. Soprattutto il proprietario del prodotto non lo segue. In Scrum uno sprint è una zona sicura e non è possibile apportare modifiche alle user story impegnate se lo sprint corrente non viene annullato. È responsabilità del maestro Scrum imporre questo. Se questo non funziona nel tuo ambiente, si tratta di un problema di processo = non stai usando Scrum.

La modifica più semplice che puoi fare (se vuoi seguire Scrum) è ridurre lo sprint, ad esempio una settimana. Gli sprint di 4 settimane sono stati considerati come opzione nei primi giorni di Scrum, ma oggi comune è 1 - 2 settimane e 3 settimane sono considerate come limite superiore. 4 settimane sono tempi molto lunghi per cambiare l'ambiente.

— Ladislav Mrnka
fonte