In modo agile, come vengono pianificate e assegnate le attività di base dell'infrastruttura all'inizio di un progetto utilizzando rigorosi framework di gestione come TFS online?

Eccomi nel processo di scoping e stima di un nuovo progetto di sviluppo software relativamente piccolo. Ho esaminato le storie degli utenti suggerite dal cliente e ho posto le attività su ognuna di esse, con un preventivo e alcune brevi note su come verrà eseguita l'attività. Ci sono criteri di accettazione. Tutto dovrebbe essere buono con il mondo.

Guardando il lavoro che avevo pianificato, mi sono reso conto che mancava qualcosa. Ci sarà un esborso iniziale nella semplice impostazione di cose in cui possiamo imbullonare la funzionalità. Cose che appartengono a tutte le storie utente, non a una particolare storia utente.

Ad esempio, parte di questa applicazione è un servizio che analizza XML. Dal punto di vista dell'utente ci sono storie specifiche in cui dovranno essere fatte cose diverse a seconda del contenuto dell'XML. In realtà scrivere un parser XML - i bit che cercano un file, leggerlo ed estrarre i dati rilevanti prima di decidere cosa fare del contenuto - fa parte di tutte queste storie. Come lo sta avvolgendo in un servizio Windows con un programma di installazione ecc. È un'attività incentrata sugli sviluppatori senza alcuna rilevanza diretta per un utente.

Un altro esempio pertinente di questa particolare applicazione è prendere e riscrivere un blocco di codice legacy scadente che è utile per le funzioni di questa app. Ancora una volta, questo non ha esiti immediati per l'utente ma è un lavoro necessario. Dove "vive" la pianificazione e l'esecuzione di questo lavoro in un piano di progetto incentrato sulle storie degli utenti?

Ho visto persone risolvere questo problema scrivendo storie utente "Come sviluppatore, voglio ..." ma come è stato discusso altrove questa non è una storia utente . È uno sviluppatore.

Sto cercando una risposta concreta a questo, per aiutare me (e gli altri) a pianificare progetti usando quadri di gestione rigorosi come TFS online. Questi non tendono ad avere la funzione di creare "storie di parti interessate" o altre vaghe meta-soluzioni menzionate nelle risposte a In che modo un team Scrum tiene conto delle attività infrastrutturali nella riunione di pianificazione?

Mi piacciono le altre risposte che dicono di inserire quanta più codice "tooling" possibile in Iterazione 0. Tuttavia, a volte, questo tipo di strumenti viene fuori dopo che il progetto è già iniziato. Forse in Iterazione 3 ti rendi conto di aver bisogno di un widget parser XML generalizzato da utilizzare su varie storie future.

In tal caso, la prima User Story che si basa su questi pezzi architettonici interni è quella a cui appartengono . Se stai per lavorare su Story # 345, e dipenderà dal tuo parser XML prima che possa essere conteggiato come 'fatto', allora il tuo parser riutilizzabile verrà allegato come lavoro per il completamento di quella storia.

Il mio team ha utilizzato l'approccio sopra indicato e sembrava funzionare bene per noi.

Se si tratta di un'infrastruttura, viene in genere inserito in Iteration Zero. Cos'è Iteration Zero? In genere è il tempo che intercorre tra kickoff e pianificazione prima dell'inizio delle iterazioni effettive.

Un esempio, diciamo che abbiamo bisogno di un nuovo servizio web. Quindi, ho bisogno di creare il progetto, impostare l'integrazione continua, impostare un repository di controllo del codice sorgente, impostare script di compilazione e distribuzione automatizzata, ecc. Agli utenti non importa davvero di questi, ma ne abbiamo bisogno a prescindere.

Quindi, quel lavoro verrebbe svolto nell'iterazione 0. Al momento dell'inizio dell'iterazione 1, ci sarebbe già una nuova shell di progetto che dovrebbe essere compilata, avere uno script di compilazione automatizzato e distribuire. Ora, nessuna delle funzionalità dell'utente sarebbe lì, ma è pronta per l'uso.

Tracciai e pianificherei ancora questo lavoro come parte dell'iterazione 0.

Il refactoring sembra una storia tecnica che può andare in qualsiasi iterazione.

Dipende dall'infrastruttura.

Se l'infrastruttura è molto significativa o deve aderire a complicate normative di conformità, è possibile che si disponga di un team di infrastrutture separato, che può avere un proprio programma. Potrebbe essere Agile, potrebbe essere una cascata. In questo caso, la costruzione dell'infrastruttura sarebbe gestita nel progetto come dipendenza esterna .

Se l'infrastruttura sarà gestita dal tuo team e configurata una sola volta, puoi utilizzare la tecnica iterazione 0 descritta da Jon.

Se l'installazione dell'infrastruttura richiederà diverse iterazioni (ad esempio, forse hai configurato il tuo server di build ora, ma i server QA e pre-produzione verranno creati un po 'più tardi), il loro buildout può essere gestito come PBI non funzionali. I PBI funzionali possono avere determinate dipendenze da questi, che è possibile codificare in TFS utilizzando il collegamento "predecessore".

E ovviamente puoi mescolare e abbinare tutto quanto sopra. Ad esempio, non puoi fare molto senza un server di build continuo, quindi puoi inserirlo nell'iterazione 0. Nel frattempo i tuoi server di preprod potrebbero essere definiti come attività per le iterazioni 2 e 3 e potrebbero avere dipendenze esterne sul tuo team DBA ( che non sono Agili) che assegneranno istanze DB nel data center. O forse devi aspettare che vengano rilasciati certificati SSL per determinate funzionalità; possono andare nell'iterazione 4 e tutti gli elementi funzionali che si basano su tali certificati dovrebbero essere collegati a essi con una relazione predecessore / successore.

In tutti i casi, ricorda:

1. Definire sempre chiari criteri di accettazione. I ragazzi dell'hardware hanno la fastidiosa tendenza ad alzare un server e chiamarlo fatto quando non è stato validato affatto.
2. Durante il calcio d'inizio dell'iterazione del team, il team dovrà esaminare le dipendenze e la loro disponibilità prima di impegnarsi in qualsiasi PBI o oggetto di lavoro.