In agile, in che modo le attività di infrastruttura di base all'inizio di un progetto sono pianificate e allocate utilizzando quadri di gestione rigidi come TFS online?

Mi piacciono le altre risposte che dicono di inserire il codice "tooling" che è possibile in Iteration 0. Tuttavia, a volte, questi tipi di strumenti vengono visualizzati dopo che il progetto è già stato avviato. Forse in Iteration 3 ti rendi conto che hai bisogno di un widget parser XML generalizzato da utilizzare su varie storie future.

In questo caso, la prima User story che fa affidamento su questi pezzi architettonici interni è quella a cui appartengono . Se stai lavorando su Story # 345, e dipenderà dal tuo parser XML prima che possa essere contato come 'fatto', il tuo parser riutilizzabile sarà allegato come lavoro per quella storia da completare.

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

Se si tratta di un'infrastruttura, in genere viene inserita in Iteration Zero. Cos'è l'iterazione zero? Di solito è il momento tra il calcio d'inizio e la 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 un'integrazione continua, configurare un repository di controllo del codice sorgente, configurare script di compilazione e distribuzione automatizzata, ecc. Gli utenti non si preoccupano molto di questi, ma ne abbiamo bisogno a prescindere.

Quindi, quel lavoro sarebbe stato fatto in iterazione 0. All'istante in cui è iniziata l'iterazione 1, ci sarebbe già una nuova shell di progetto che compilerebbe, avrebbe uno script di compilazione automatizzato e sarebbe stata distribuita. Ora, nessuna delle funzionalità utente sarebbe lì, ma è pronta per andare.

Tracciare e pianificare questo lavoro come parte dell'iterazione 0 funziona.

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

Dipende dall'infrastruttura.

Se l'infrastruttura è molto significativa o deve rispettare regole di conformità complicate, è possibile che si disponga di un team di infrastruttura separato, che potrebbe avere un proprio programma. Potrebbe essere Agile, potrebbe essere cascata. In questo caso, la costruzione dell'infrastruttura sarà gestita nel tuo progetto come dipendenza esterna .

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

Se la configurazione dell'infrastruttura richiederà diverse iterazioni (ad es. forse si configurerà il server di build ora, ma i server QA e preprod verranno creati un po 'più tardi), il loro buildout potrà essere gestito come PBI non funzionali. I PBI funzionali possono avere certe dipendenze su questi, che puoi codificare in TFS usando il link "predecessore".

E ovviamente puoi combinare tutto quanto sopra. Ad esempio, non è possibile fare molto senza un server di build continuo, quindi è possibile inserirlo nell'iterazione 0. Nel frattempo i server di preprod potrebbero essere definiti come attività per le iterazioni 2 e 3 e potrebbero avere dipendenze esterne dal proprio team DBA ( chi non è Agile) che assegnerà le istanze DB nel tuo data center. O forse devi aspettare che vengano rilasciati certificati SSL per determinate funzionalità; possono andare in iterazione 4 e tutti gli elementi funzionali che si basano su questi certificati devono essere collegati a loro con una relazione predecessore / successore.

In tutti i casi, ricorda:

1. Definisci sempre chiari criteri di accettazione. I ragazzi dell'hardware hanno una fastidiosa tendenza a stare su un server e chiamarlo fatto quando non è stato affatto convalidato.
2. Durante il kickoff di iterazione della tua squadra, il team dovrà esaminare le dipendenze e la loro disponibilità prima di impegnarsi in qualsiasi PBI o elemento di lavoro.