In che modo un team Scrum tiene conto delle attività di infrastruttura nella riunione di pianificazione?

In realtà non sono storie di utenti. Sono storie di stakeholder. A meno che il software non venga pagato direttamente dagli utenti, è raro che una storia venga creata interamente a proprio vantaggio.

Ti fornisco un paio di esempi:

• articoli con parole chiave, che consentono agli inserzionisti di avere annunci più efficaci
• CAPTCHA, che servono per impedire ai moderatori di gestire lo spam manualmente.

La maggior parte delle storie tecniche in realtà fornisce un vantaggio aziendale, ma raramente per gli utenti. La loro traduzione in un modo diverso può aiutare. Io di solito uso il modello di Injection Feature di Chris Matts:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Questo riconosce esplicitamente tutti i tipi di stakeholder, incluso il team di sviluppo. Ora puoi anche esprimere le tue storie tecniche, richiamando il beneficio aziendale:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Ho scritto un paio di post sul blog su questo: Non sono User Stories e Iniezione di caratteristiche e gestione di storie tecniche . Spero che aiutino.

La velocità è una misura della capacità della squadra di fare un lavoro utile (al contrario di trascinare). Le attività infrastrutturali continuano a fornire valore per l'utente finale, anche se indirettamente, rendendo il team più efficiente a lungo termine. Non ho alcun problema a tenere traccia di queste cose come storie utente (l'utente è il team di sviluppo in questo caso) e le priorità in modo appropriato. Un Product Owner in buona comunicazione con il / i cliente / i dovrebbe essere in grado di capire dove tali attività possono essere adattate senza interrompere i risultati.

Fatelo gradualmente.

Se nessuna parte interessata lo desidera, non farne una storia. Prenditi cura di questo, un po 'alla volta. Ad esempio, la prima volta che si distribuisce manualmente. La seconda volta, ne automatizzi un po '. La terza volta, automatizzi un po 'di più. Alla fine, la tua build non è il problema più grande, quindi ti concentri su qualcos'altro.

Avrai più di questi compiti incentrati sullo sviluppatore all'inizio, e va bene; la tua velocità (misurata dalle storie) sarà solo più bassa. Questa è una rappresentazione corretta della situazione. Ma ne avrai sempre, quindi è importante che il team prenda l'abitudine di fare ciò che è necessario per migliorare il processo.

IMHO l'approccio ideale consiste nel collocare lo sforzo infrastrutturale come attività sotto la user story in cui inizialmente ha valore; come hai menzionato.

Prendendo il tuo esempio; costruendo e distribuendo manualmente implica che è uno sforzo continuo e non ha alcuna forma di completamento. Esiste indefinitamente.

Lo stesso potrebbe dirsi per il codice che automatizza qualsiasi porzione di sforzo in un'applicazione tipica che è stata precedentemente eseguita manualmente. Definire questo sforzo come un compito sotto una storia utente definisce completo; che per sua natura ha valore per l'utente finale.

Potresti sicuramente creare e distribuire l'applicazione ogni singolo sprint, ma questo diventerà parte delle attività giornaliere che non vengono tracciate formalmente tramite il backlog e quindi tutto diventa moot.

Le storie degli utenti definiscono un valore aziendale dal punto di vista dell'utente. A causa di tale infrastruttura, le attività sono generalmente considerate come "rifiuti". Ciò non significa che non siano necessari. Ciò significa che svolgere più attività di infrastruttura offrirà meno valore aziendale. A causa di questa infrastruttura le attività non dovrebbero essere considerate come un utente storie e non dovrebbero essere associate a storie di utenti.

In una riunione di pianificazione, il team deve considerare quali attività di infrastorntura saranno assolutamente necessarie durante il prossimo sprint. L'impegno sarà fatto tenendo conto di questi compiti infrastrutturali. Influirà sulla velocità della squadra, che è il risultato corretto perché la velocità misura il valore di business che il team può fornire.

Non ho mai equiparato le storie degli utenti a dover fornire valore all'utente finale. Potrebbe essere comune, ma non è come gestiamo le storie degli utenti. A volte, questi tipi di attività sono considerati picchi, ma abbiamo anche avuto storie di utenti regolari, il punto è stato stimato come qualsiasi altra storia utente.

Da quello che ho visto gran parte dell'infrastruttura è considerata un dato di fatto. Questo include cose come:

• Sistema di controllo della revisione;
• Sistema di compilazione automatizzato;
• IDE e altri strumenti di sviluppo;
• Server di sviluppo;
• Processo di distribuzione; e
• Processo e standard di progetto.

La maggior parte delle metodologie con cui ho lavorato non danno molta attenzione a loro. Questi formano ciò che chiamo Release 0. Queste cose dovrebbero essere in atto prima di iniziare lo sviluppo. Una volta che inizi a lavorare sulle storie, eventuali cambiamenti in queste cose potrebbero essere monitorati come miglioramenti del processo.

Sebbene il team di sviluppo possa avere input, la maggior parte di questi elementi dovrebbe essere gestita da un team di supporto del progetto. La standardizzazione di questi elementi in più progetti dovrebbe comportare un rimborso significativo per l'organizzazione.

Considera quanto segue:

• Scrum team che aggiunge funzionalità importanti a una suite di prodotti esistente.

• È necessario aggiornare la tecnologia / gli strumenti di sviluppo / le utilità di sviluppo rimanere aggiornati sulla base delle migliori pratiche di ingegneria.

• Ha senso caricare frontalmente una versione con questo lavoro in modo che finisca il corso del rilascio I problemi di Sprint possono essere risolti.

• Dal momento che l'azienda ottiene un valore indiretto da questi elementi suggerisco che nell'interesse della trasparenza si tratta di Product Backlog Articoli (PBI).

• Il team dimensiona questi articoli e li tratta come farebbe con qualsiasi PBI.

Questo problema per me si riduce al fatto che non voglio sprecare    tempo cercando di capire come nascondere questo lavoro come attività al di sotto    altri PBI più centrati sul business.

Non voglio che il dimensionamento del PBI sia distorto da questo tipo di lavoro infrastrutturale. Voglio vedere cosa si sta facendo e capire per cosa sto pagando.

Penso anche che sia importante che il team comprenda l'impegno che l'azienda sta facendo investendo nell'infrastruttura necessaria per fornire soluzioni di qualità.

XP raccomanda suggerisce di avere una "iterazione zero" in cui sono impostati tutti gli strumenti e l'infrastruttura. Scrivere storie per questi è facoltativo, ma probabilmente è una buona idea. Essere in grado di testare la tua infrastruttura (build incrementale, test automatizzato e distribuzione, notifiche, ecc.) È vantaggioso

Nel nostro team facciamo quanto segue:

1. Assumi un fattore di fuoco inferiore .
2. Prova a includere tali attività nelle storie degli utenti che effettivamente necessitano di implementarle.
3. Se alcune attività sono totalmente necessarie, ma non forniscono alcun valore commerciale diretto (come la migrazione dei test di unità da un framework a un altro), all'inizio dello sprint creiamo un elenco di "attività continue" . Queste sono attività legate allo sviluppo che non sono storie, ma il team di sviluppo le vuole fatte. Elenchiamo questi compiti sulla nostra lavagna, mantenendola sempre separata dalle storie. Durante lo sprint, in occasione di ogni riunione quotidiana rivediamo cosa è stato fatto per realizzarli.

Il passaggio 2 è il più importante. Come in una pratica agile, in Scrum cerchi di fare il meno possibile per portare a termine i tuoi compiti. Prendilo come un modo per non sprecare la tua vita a fare lavori inutili: la mia esperienza mostra che fino al 50% delle cose "sarebbe-cool" finiscono abbandonate e non mantenute a lungo termine.