Aumentare le modifiche / i requisiti degli utenti nella metodologia Agile

Sembra che il tuo manager non comprenda veramente in Agile, ma piuttosto cerca di mettere un pasticcio Agile in uno stampo 'data fissa'.

È possibile eseguire un progetto Agile con una data di scadenza fissa, ma tutte le parti devono comprendere che verranno consegnate solo le funzionalità completate fino alla data di fine. Non è possibile concordare preventivamente una data e un set di funzionalità e quindi consentire al cliente di apportare modifiche a piacimento senza conseguenze per la consegna finale.

Un modo per combinare un team di sviluppo Agile con un progetto a data fissa è avere un proprietario del prodotto strong e in-house che protegga attentamente l'ambito del progetto e mantiene le negoziazioni sulle richieste di modifica con il cliente reale lontano dal team di sviluppo. Il proprietario del prodotto è quindi responsabile di evitare di perdere la scadenza dovuta allo scorrimento dell'oscilloscopio. Ciò presuppone che il programma originale fosse realistico in primo luogo.

Sfortunatamente, la situazione in cui ti trovi è probabilmente una delle più comuni. Agile sta ottenendo l'adozione in molti mercati a causa del buzz, e non a causa della comprensione. Gli stessi vecchi problemi esistono ancora: desiderio di ambito fisso, data fissa e costo fisso. Se il triangolo di ferro è fisso, nessun processo di sviluppo ti salverà.

Quando incontri il triangolo di ferro, sarà necessario un compromesso con il cliente. Nel tuo caso, il tuo cliente potrebbe essere il tuo manager. Il cliente deve scegliere tra i seguenti (o un saldo di tutti):

1. Regolazione dell'ambito. Elimina alcune funzioni per consentire lo spazio per le modifiche. Alcune modifiche alle funzionalità già fornite sono davvero più importanti per creare quindi nuove funzionalità che potrebbero ancora essere presenti nel tuo backlog. Il tuo Product Owner (o chi sta aiutando a determinare la priorità) può risolvere questo problema con il cliente in modo che non chieda una modifica e perdano una funzionalità che in realtà desiderava di più, o viceversa.
2. Adeguamento del programma. Consenti una data di consegna successiva o consenti più date di consegna in cui un set iniziale di funzionalità viene consegnato in tempo e successivamente il team consegna una seconda versione con il nuovo ambito in un secondo momento. Va bene consegnare in data e avere quel cambiamento 2 settimane dopo? Questo è uno sviluppo iterativo, quindi le cose dovrebbero poter essere continuamente pubblicate in molti scenari.
3. Aggiustamento del budget. Questo è probabilmente il più difficile da fare, poiché la maggior parte dei clienti ha budget fissi per i progetti. Se la data è davvero importante (i piani go-to-market sono a posto e manca la data non è un'opzione) e l'ambito non può essere ridotto per adattarsi alla timeline, è possibile utilizzare una richiesta di budget aggiuntivo per aumentare le dimensioni di la tua squadra per permetterti di fare di più in una determinata iterazione.

Il pezzo più importante è che il cliente ha bisogno di capire l'impatto di ciò che sta chiedendo. Quando chiedono una modifica, perdono una funzionalità, mancano la data o aumentano il costo del progetto. Essere sicuri che il cliente comprenda l'impatto della loro richiesta è fondamentale, e uno dei motivi per cui hai davvero bisogno che qualcuno svolga il ruolo di Product Owner con il cliente per mantenere le aspettative.

Nel tuo caso, il tuo team ha bisogno di un team leader che si interfaccia con il tuo manager e stia discutendo con loro sull'impatto. Il tuo manager non vuole che tu fallisca, ma a volte è solo una mancanza di comprensione da qualche parte lungo la catena. È possibile che il tuo manager possa avere qualcuno che si avvicina a loro in merito al programma, quindi dare al tuo manager le munizioni per risalire la catena e lottare per più tempo, budget o riduzioni dell'ottimizzazione aiuterà te e te.

Se hai veramente una pianificazione fissa per il completamento di un progetto, devi utilizzare un processo meno agile.

Se la tua cronologia è fissa, anche i requisiti (ovvero le caratteristiche, le storie degli utenti) devono essere corretti o almeno riparati. Per rispettare un programma fisso, è necessario inclinare di più verso "seguire un piano" piuttosto che "rispondere al cambiamento".

È necessario disporre della gestione delle modifiche: se qualcuno richiede più funzionalità, i responsabili devono decidere come adattare la richiesta senza allungare la pianificazione. La risposta di Jay espone gli obiettivi / pianificazione / compromessi di bilancio della gestione tradizionale del progetto.

La mia esperienza è che spesso non ci sono buone opzioni per pagare soldi per ottenere più funzionalità entro un periodo di tempo limitato. In tal caso, le scelte si riducono a

1. Rifiuta la nuova funzione
2. Annulla un'altra funzione meno importante per creare spazio per la nuova funzione
3. Accetta un'implementazione più economica di alcune funzionalità. (esempio: le cifre di vendita trimestrali sono visualizzate come testo, ma non in un grafico a barre interattivo 3d)

Il problema è che lo sviluppo del software è fatto e gestito da persone e persone (in particolare persone di gestione) non amano dire no al cliente perché dire no è difficile. I clienti curiosi tendono ad accettarlo meglio di quanto pensino le persone. Nel loro cuore, sanno che le nuove funzionalità richiederanno tempo e denaro, ma sono state addestrate a pensare di poter chiedere la luna alle persone che lavoreranno 90 ore alla settimana per soddisfare le richieste che avrebbero dovuto essere rimandate a più tardi.

Se stai facendo agile o cascata è irrilevante, il problema è che la persona che sta comunicando con il cliente non ha il coraggio di dirgli la verità. Se chiedi nuove funzionalità, costano $ X in più e impiegano ancora X ore per farlo e la scadenza si sposterà.

Il meglio che puoi fare è respingere quando accade con una nuova stima dei costi, una nuova stima delle ore di lavoro e una nuova scadenza o un suggerimento che la nuova funzionalità sia inclusa nella prossima iterazione o un suggerimento di ciò che verrà lasciato cadere per lasciare spazio alla nuova funzione. Questo deve accadere per iscritto e deve succedere ogni volta che si verifica uno scorrimento del raggio.

Come sviluppatore, quando ti viene chiesto di aggiungere una nuova funzionalità, fai notare le caratteristiche in questa iterazione che non sono ancora state avviate o che sono per lo più incomplete (non vuoi che ne elimini uno completato o che sia quasi pronto) e poi chiedere quale vuole eliminare per accettare la nuova funzione o quale è la nuova scadenza. Non accettare mai più lavoro senza un cambio di scadenza o altri lavori incompiuti spostati in una futura iterazione. Tuttavia, questo funzionerà solo se ne avrai a bordo un buon risultato. Una persona che accetta questo tipo se il creep dell'oscilloscopio comprometterà il resto di voi. Una volta accettare questo cambiamento semplice minerà le tue possibilità di spingere un cambiamento complesso in fondo alla strada. Tu e i tuoi collaboratori dovete essere disciplinati su questo.