Agile: punte e tempistica generale

Il team sta iniziando il loro primo progetto in maiuscolo-A Agile, e il progetto sembra che si adatterà perfettamente alla metodologia (cioè probabilmente potremo semplicemente prendere un libro agile e seguirlo come una ricetta), con un po 'di confusione:

Il progetto prevede tre cose con cui nessuno del team ha alcuna esperienza: integrarsi con il Foo Payroll System, essere in grado di gestire il tipo di file XYZ89 (dove "XYZ89" = un tipo di file di cui non si è mai sentito parlare) e convertire alcuni altri file in modo che possano essere gestiti da Frobnobdicator.

A quanto ho capito, la pratica Agile standard sarebbe quella di pianificare picchi per ciascuno di questi, dopo di che possiamo determinare quanto tempo impiegheranno (non sono sicuro che il cliente decida di non fare loro, dato che sono praticamente requisiti solidi del progetto)

Quindi le mie domande sono:

1. Facciamo tutti i picchi nella prima iterazione per ottenere una migliore stima del tempo che ci vorrà per farli e / o ottenere uno "scheletro ambulante" attivo e funzionante?

2. Altrimenti, il programma totale del progetto non sarebbe in balia di uno di questi picchi che tornano con i dati che questa storia particolare impiegherà molto più tempo di quanto abbiamo messo in campo?

Qual è il modo migliore per gestire picchi multipli quando sono requisiti sostanzialmente non negoziabili di un progetto?

Il modo in cui ho gestito queste oscure incognite nel mio piano di progetto in precedenza è quello di provare e impostare il tempo per il team di sviluppo di realizzare prima i prototipi della funzionalità sconosciuta. Ciò offre il vantaggio di far conoscere chiaramente ciò che sarà necessario per svolgere i compiti specializzati, dimostra che questi sono tecnicamente fattibili ed educa il resto del team sulle possibili insidie ​​da evitare quando inizia lo sviluppo attivo.

Questo è il motivo per cui molti progetti Agile di solito iniziano con un, quello che mi piace chiamare, Sprint 0 .

Pensa a come allacciare le scarpe da corsa, allungare e mettere i cerotti sui capezzoli proprio prima di iniziare una maratona. Questa volta può essere utilizzato per eseguire la pianificazione iniziale del progetto e la creazione della storia dell'utente, l'implementazione della progettazione e dell'architettura, la creazione della struttura del software e gli sviluppatori possono lavorare su qualsiasi prototipo e prova di concetti per qualsiasi nuova tecnologia o sfide tecniche sconosciute che possano rendere la storia dell'utente stima molto più semplice.

Dovresti fare le cose nell'ordine della priorità impostata dal proprietario del prodotto (o dal cliente). Non ha senso ammazzarti per qualcosa che è stato davvero bello da avere. L'idea è che se si esaurisce il tempo e qualcosa non viene fatto, dovrebbero essere gli elementi con la priorità più bassa.

Se non daranno la priorità a ciò che vogliono, avrai difficoltà.

Se le cose sono relativamente uguali, non iniziare con l'oggetto più difficile: inizia con una vittoria facile, che darà al team la possibilità di abituarsi a lavorare insieme utilizzando la nuova metodologia e il cliente con la certezza di poter consegnare cose in questo modo. Una volta stabilito, affrontare qualcosa di difficile. Misura la complessità dell'elemento difficile rispetto alla complessità delle cose più semplici che hai appena fatto e inizierai a farti un'idea di quanto tempo può impiegare per superarlo.

Gli oggetti complessi non sono in realtà "punte". Sono semplicemente cose che richiedono uno sforzo maggiore per capire. Suddividili in compiti più semplici il più possibile.

Una possibile soluzione è quella di creare un compito per fare una prova del concetto per capire come risolvere il problema e impostarlo, quindi aggiungere quella storia a uno sprint con altre storie.

Stai davando valore e un prodotto alla fine dello sprint, anche se si tratta di un'app console di hacking. L'idea è che non stai sprofondando la produttività dell'intero team, se sei a corto di tempo, aggiungi un'altra attività simile allo sprint successivo.