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

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

A prima vista, non sembrano storie di utenti poiché non forniscono valore all'utente finale.

Tuttavia, allegarli come attività a una particolare storia utente a volte non ha nemmeno senso. Ad esempio, supponiamo che l'attività sia: "Setup Bamboo". Tale attività non è richiesta per completare la user story poiché il team potrebbe creare e distribuire manualmente. Pertanto, allegarlo a una user story non ha senso poiché questa attività non è richiesta per completare la user story.

Quindi, questo suggerisce che queste attività diventano storie utente. Ma poi, se la storia del team li indica, allora questo cambia la velocità che è strana dal momento che il Product Owner vuole conoscere la velocità contro il suo backlog, non contro il suo backlog con un mucchio di storie di utenti tecnici ad esso collegate.

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

Ti do un paio di esempi:

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

La maggior parte delle storie tecniche in realtà offre un vantaggio commerciale, ma raramente è per gli utenti. La loro frase in un modo diverso può aiutare. Normalmente utilizzo il modello di Iniezione funzioni 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 vantaggio 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 di blog su questo: non sono User Story , e Feature Injection e gestiscono storie tecniche . Spero che aiutino.

La velocità è una misura della capacità della squadra di fare un lavoro utile (al contrario di Drag). Le attività relative alle infrastrutture continuano a fornire valore all'utente finale, anche se indirettamente, rendendo il team più efficiente a lungo termine. Non ho problemi a rintracciare queste cose come storie utente (in questo caso l'utente è il team di sviluppo) e assegnarle le priorità in modo appropriato. Un Product Owner in buona comunicazione con il / i cliente / i dovrebbe essere in grado di capire dove possono svolgersi tali compiti senza interrompere i risultati finali.

Fateli gradualmente.

Se nessun stakeholder lo desidera, non trasformarlo in una storia. Prenditi cura di esso, 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 queste attività incentrate sullo sviluppatore all'inizio, e va bene; la tua velocità (misurata dalle storie) sarà solo inferiore. Questa è una rappresentazione corretta della situazione. Ma ne avrai sempre alcuni, quindi è importante che il team abbia l'abitudine di fare ciò che è necessario per migliorare il processo.

IMHO l'approccio ideale sta ponendo lo sforzo infrastrutturale come attività nella storia dell'utente in cui ha valore per la prima volta; come hai già detto.

Prendendo il tuo esempio; la costruzione e la distribuzione manuale implica che si tratta di uno sforzo continuo e non ha alcuna forma di completamento. Esiste indefinitamente.

Lo stesso si può dire per il codice che automatizza qualsiasi porzione di sforzo in un'applicazione tipica che è stata precedentemente eseguita manualmente. Definire questo sforzo come un'attività in una user story definisce completo; che per sua stessa natura ha valore per l'utente finale.

Potresti certamente costruire e distribuire l'applicazione ogni singolo sprint, ma questo diventa parte delle attività quotidiane che non vengono tracciate formalmente tramite il backlog e quindi tutto diventa discutibile.

Le storie utente definiscono un valore commerciale dal punto di vista dell'utente. A causa di ciò, le attività infrastrutturali sono generalmente considerate "rifiuti". Ciò non significa che non siano necessari. Significa che svolgere più attività infrastrutturali offrirà un valore commerciale inferiore. A causa di ciò, le attività di infrastruttura non devono essere considerate storie utente e non devono essere associate a storie utente.

In una riunione di pianificazione, il team deve considerare quali attività di infrasturcture saranno assolutamente necessarie durante il prossimo sprint. L'impegno sarà fatto tenendo presenti questi compiti infrastrutturali. Interesserà la velocità del team, che è il risultato corretto perché la velocità misura la quantità di valore aziendale che il team può offrire.

Non ho mai equiparato le storie degli utenti a dover fornire valore all'utente finale. Può essere comune, ma non è il modo in cui gestiamo le storie degli utenti. A volte, questi tipi di attività sono considerati picchi, ma abbiamo anche avuto storie utente regolari, punto 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 di revisione;
• Sistema di compilazione automatizzato;
• IDE e altri strumenti di sviluppo;
• Server di sviluppo;
• Processo di distribuzione; e
• Processo e standard del progetto.

Molte metodologie con cui ho lavorato non prestano molta attenzione a loro. Questi formano ciò che chiamo Release 0. Queste cose dovrebbero essere a posto 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 deve essere gestita da un team di supporto del progetto. La standardizzazione di questi elementi in più progetti dovrebbe comportare un significativo rimborso per l'organizzazione.

Considera quanto segue:

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

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

• Ha senso caricare anticipatamente una versione con questo lavoro in modo che nel corso della versione i problemi di Sprint possano essere risolti.

• Poiché l'azienda ottiene un valore indiretto da questi articoli, suggerisco che, nell'interesse della trasparenza, si tratti di articoli di backlog di prodotto (PBI).

• Il team dimensiona questi elementi e li tratta come se fossero qualsiasi PBI.

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

Non voglio che il dimensionamento di PBI sia distorto da questo tipo di lavoro infrastrutturale. Voglio vedere cosa viene fatto e capire per cosa sto pagando.

Penso anche che sia utile far comprendere al team l'impegno assunto dall'azienda investendo nell'infrastruttura necessaria per fornire soluzioni di qualità.

XP consiglia di avere uno "zero di iterazione" 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 e distribuzione automatizzati, notifiche, ecc.) È utile

Nel nostro team facciamo quanto segue:

1. Assumi un fattore di messa a fuoco più basso .
2. Cerca di includere tali attività nelle storie degli utenti che devono effettivamente essere implementate.
3. Se alcune attività sono totalmente necessarie, ma non forniscono alcun valore commerciale diretto (come la migrazione di unit test da un framework all'altro), all'inizio dello sprint creiamo un elenco di "task continui" . Si tratta di attività legate allo sviluppo che non sono storie, ma il team di sviluppo le vuole svolgere. Elenchiamo questi compiti sulla nostra lavagna, mantenendola comunque separata dalle storie. Durante lo sprint, ad ogni incontro quotidiano esaminiamo ciò che è stato fatto per realizzarli.

Il passaggio 2 è il più importante. Come in una pratica agile, in Scrum provi a fare il minor numero possibile per svolgere i tuoi compiti. Prendilo come un modo per non sprecare la tua vita nel fare un lavoro inutile: la mia esperienza mostra che fino al 50% delle cose "sarebbe bello" finiscono per essere abbandonate e non mantenute a lungo termine.