Un mio amico in un altro dipartimento ha avuto un problema ed è venuto da me con una domanda che non ero sicuro su come aiutarlo. Recentemente è stato promosso architetto e gli è stato affidato il compito di progettare e guidare un team di sviluppatori di qualità discutibile e con poca o nessuna esperienza nel seguire un piano di progetto. Questo team ha preso l'abitudine di iniziare lo sviluppo il prima possibile prima ancora di valutare le esigenze aziendali, e quindi di hackerare il software in pezzi quando i requisiti sono finalmente diventati chiari verso la fine della scadenza. Per questo motivo hanno provato a formulare standard di progettazione in passato, ma non si sono mai presi la briga di seguirli più avanti nel progetto quando è stato acceso il calore.
Ha intenzione di cambiare questo e mi ha chiesto il modo migliore per gestire queste sfide. Il mio punto di vista è che il progetto è condannato prima di iniziare perché la gestione stabilisce una scadenza molto stretta prima che i requisiti siano chiaramente noti o compresi. Il dithering da parte del cliente esaspera ulteriormente il problema. Gli ho detto che Agile è stato REALIZZATO per questo tipo di problemi, ha formulato le storie degli utenti in base ai requisiti del cliente, come te ne rendi conto ora, e poi quando più user story o come cambiano si aggiungono all'arretrato e riadattano di conseguenza il tuo piano di sprint .
Ma poi ho pensato a quale sia davvero il modo migliore per gestirlo? Il cliente non ha modo di sapere esattamente cosa vogliono dal software ora, ma sa che lo vuole e sono disposti a pagare per questo e vogliono almeno una qualche forma di rilascio lavorativo entro una data specifica. Viene data una quotazione con una ripartizione di ciò che verrà consegnato (è un'ipotesi sia per il venditore che per il cliente), il prezzo è concordato.
Quando si formula la citazione, deve esistere una scadenza di qualche tipo, anche se a questo punto è morbido. Le storie degli utenti non sono nemmeno note e certamente non sono attività e la capacità di fornire una stima ragionevole. Come ti avvicini a questa sfida?
Quando questa citazione è presa e concordata è normale usare i risultati grezzi come indicato nella citazione come base per la formulazione delle storie degli utenti?
Inoltre, hai qualche consiglio su come "mantenere vivi i modelli di progettazione e i documenti" durante tutto il progetto quando i requisiti cambiano drasticamente?
EDIT: sembra che molte persone credano che il cliente coinvolto dovrebbe essere quello che fornisce le storie degli utenti come se fosse un dato. Non ho alcuna esperienza personale con un cliente disposto a impegnare questo tipo di impegno nel processo di sviluppo. A causa di ciò, sembra logico che a causa della loro mancanza di input nel processo di sviluppo, non siano un ottimo stakeholder per il progetto stesso. Le parti interessate a questo punto diventano gli analisti di business e i gestori di applicazioni che dovrebbero spremere qualsiasi informazione di cui possono ottenere dal client e trasformarla in informazioni utilizzabili per gli sviluppatori. Questo chiaramente non funziona, quindi forse l'UNICO modo in cui Agile o Kanban possono funzionare è avere un coinvolgimento diretto del cliente nelle storie degli utenti oppure il progetto è destinato a fallire?