In Scrum, le attività come l'ambiente di sviluppo e lo sviluppo delle capacità devono essere gestite come attività secondarie all'interno di storie utente reali?

Abbiamo pensato a questo problema parecchio nell'ultimo anno.

Mentre sono d'accordo sul fatto che dovrebbe esistere una struttura di base prima che il progetto inizi, nell'uso pratico può essere parte del progetto stesso. Quindi devi gestire in qualche modo.

Sebbene il mixaggio della configurazione del progetto con le storie degli utenti possa avere senso, a volte ci siamo basati su semplici attività che possono essere aggiunte al backlog del prodotto e ottenere la stessa attenzione delle storie degli utenti. Sappiamo che questi compiti tecnici sono necessari a volte, ma devono essere comunque giustificati. Se la squadra pensa che siano assolutamente necessari per raggiungere un determinato obiettivo, faranno parte di uno sprint.

È difficile dire cosa funzioni meglio per te, quindi experiment ! Un picco potrebbe essere sufficiente per ora, ma penso che finirai con lo stesso problema in seguito, quindi pianifica in anticipo. Esegui attività che fungono da segnaposto per tali attività. Per separare i compiti dalle storie due, li confronterò rapidamente in base alla mia esperienza con loro.

Attività: un'attività è una necessità tecnica. Potrebbero essere cose per la gestione della configurazione o l'impostazione generale del progetto, come l'impostazione di un repository per i commit o l'aggiunta dello strumento di revisione del codice più caldo che abbia mai visto nel processo di sviluppo. Le attività devono essere considerate nella pianificazione, come in una storia utente. Se il team è in grado di convincere il proprietario del prodotto che disporre dello strumento di revisione del codice più recente e più efficace aumenta le prestazioni e la comunicazione del team eliminando sessioni di programmazione a coppie di lunga durata o revisioni di codice di persona, otterrà l'attenzione del proprietario del prodotto.

Storie : focalizzati esclusivamente sulla prospettiva aziendale, le storie producono sempre un valore visibile per il cliente. La qualità interna è qualcosa che va di pari passo con la produzione di valore aziendale.

Assegniamo persino punti storia alle attività e talvolta lavoriamo con loro come faremmo con le storie.

Alla fine, opterei per questa soluzione nel tuo caso (che potrebbe essere applicata anche in generale):

1. Separa "setup" e materiale tecnico in attività (cose che non producono direttamente valore di business per il proprietario del prodotto).
2. Forse fare un picco prima della configurazione del progetto per mettere in atto gli strumenti più importanti (SCM, strumenti di sviluppo, definizione dei processi, standard di codifica ecc.)
3. Accettate che queste attività compaiano per tutta la durata del progetto e pianificate per questo avendo un "tipo" separato di attività diverse dalle storie.

Fai ciò che ha più senso nella tua azienda. Non lasciare mai che il modo in cui gli altri fanno le cose sia un ostacolo al buon senso.

Ma dirò che tutte queste attività sembrano qualcosa che dovrebbe accadere molto prima di iniziare lo sviluppo. Quindi mi chiedo se Scrum sia anche rilevante per questi compiti. Sono in corso alcuni interventi di manutenzione, come il controllo del codice sorgente e i database, ma questi non dovrebbero essere programmati, dovrebbero solo essere le cose che accadono e influire sulla velocità.

Ci saranno momenti in cui devi selezionare un framework o qualsiasi cosa durante un progetto, ma quando dico che intendo un framework come nHibernate, non un framework come .NET. In questi casi, la ricerca dovrebbe essere spiked e timeboxed, per non dire abbastanza breve. Prova a gestirlo come se avessi uno sviluppatore malato per un paio di giorni.

Il trasferimento delle conoscenze è un altro processo continuo che deve essere gestito al di fuori della velocità di sviluppo generale.

C'è un nome per prendere tutte le decisioni di progettazione possibili in anticipo prima dell'avvio "ufficiale" del tuo progetto. Si chiama cascata. Non c'è niente di sbagliato in storie di utenti come: "Come sviluppatore, ho bisogno di selezionare un framework, quindi abbiamo un punto di partenza per il sito web." Se è troppo grande per rientrare in una iterazione, prova a scomporla come, "Come sviluppatore, ho bisogno di implementare una home page di base in Drupal, quindi sapremo se si adatta alle nostre esigenze."

One option is to make them all part of first user story e.g. make the homepage for application.

Interrompe la "user story" come concetto. Quale utente è coinvolto in questo? Nessuna. Questo è un lavoro che avresti dovuto già fare.

Another option is to do a spike for this.

Non male.

Third option is to make task part of an Issue (e.g. Development environment not selected yet) rather than a user Story.

Circa lo stesso di un picco per quanto riguarda la pianificazione e le spese generali.

L'installazione è non una user story.

È ciò che dovresti avere prima ancora di aver avviato questo progetto.

Non puoi realmente avviare il progetto a meno che tu non abbia la configurazione framework / tool e server e sia pronto per partire.

Sono ben consapevole del fatto che molte organizzazioni non esistono realmente fino a quando dopo il contratto è firmato. Sono anche consapevole del fatto che molte organizzazioni non scelgono una tecnologia fino a quando dopo non viene firmato il contratto. Queste sono tutte cose inefficienti che sono al di fuori di qualsiasi user story.

Al lavoro usiamo un compito per preparare l'ambiente. Potrebbe essere fonte di confusione per alcune persone, ma l'attività che usiamo è molto simile a quella di un utente. L'attività non appartiene a un utente ma è stimata in ore e deve essere concordata dal proprietario del prodotto per completare uno specifico sprint.

Usiamo anche l'attività per il lavoro di architettura che non ha un valore aziendale "apparente" ma che aggiunge qualità al prodotto in particolare per un prodotto esistente con una base di codice estesa.

Potrebbero non essere applicabili nel tuo ambiente di lavoro ma hanno funzionato bene per noi.

Penso che tu stia mescolando due cose indipendenti. Una user story non dovrebbe includere dettagli tecnici.

La scelta del framework, la configurazione di repository e server e altre attività dovrebbero andare nell'iterazione iniziale.

Recentemente ho frequentato un corso Scrum e l'istruttore mi ha suggerito di utilizzare uno sprint speciale chiamato Sprint 0 per risolvere esattamente questo tipo di problemi. C'erano persone nel corso con vari gradi di esperienza in Scrum e praticamente tutte le persone esperte erano d'accordo, dicendo che facevano la stessa cosa. In alcuni casi, le aziende hanno utilizzato Sprint 0 per valutare il progetto e deciso se fosse fattibile o meno.

Per qualcuno nuovo della metodologia Scrum come me, sembra una soluzione fantastica perché ti tiene libero dalle storie degli utenti e da tutti gli altri aspetti di uno sprint normale come il feedback degli utenti.

Poiché Sprint 0 è lo stesso periodo di tempo dei tuoi altri sprint, è un modo per assicurarti di non perdere troppo tempo a configurare le cose perché possono essere sempre ottimizzate in seguito. Il punto principale è entrare in uno stato in cui puoi effettivamente iniziare a sviluppare il prodotto.

on exploring 2-3 alternate framework/tool

A volte questo può accadere se hai dei requisiti speciali devi fare dei POC per scegliere lo strumento migliore per risolvere il requisito. Questo è il motivo per cui lo spike è perché, senza sapere quale framework utilizzerai, probabilmente non è possibile stimare la storia e il negozio senza stima non può essere pianificato e diviso in attività.

then on learning the framework we select for the project

Bene. Questo è abbastanza pericoloso. Quando il cliente ti paga per un SW, si aspetta che tu sia un professionista che già sa come usare i suoi strumenti. Il cliente non ti paga per l'apprendimento o per l'approccio di sviluppo trial / fail. È responsabilità dello sviluppatore apprendere nuovi strumenti nel suo tempo libero o in un momento speciale dedicato pagato dal suo dipendente non dal cliente. Spendere i soldi dei clienti per l'apprendimento senza informare il cliente non è professionale.

Se davvero devi usare qualcosa di speciale (ad esempio l'API di un cliente o il cliente di uno strumento selezionato) che non hai mai usato prima devi informare il cliente che il prezzo sarà aumentato di tempo necessario per imparare come usare l'API. Forse il cliente cambierà idea se l'aumento del prezzo sarà troppo grande.

Certo, non intendo la situazione in cui devi cercare qualche particolare nuovo problema nel framework che hai usato molte volte. Intendo la situazione in cui inizi a utilizzare nuove API o framework senza spendere un tempo significativo (al di fuori del progetto) per l'apprendimento.

Se violi questo sarà comunque visibile nella tua velocità perché fornirai una quantità molto piccola di valore commerciale per ogni iterazione. Se il cliente non è a conoscenza del motivo, molto probabilmente cancellerà il progetto.

Questo è ancora valido in caso di progetti interni - devi informare il tuo manager / azienda sul tempo necessario per l'apprendimento di nuove API o strumenti. Di solito ha conseguenze molto negative se il gestore conta sulla tua normale produttività e la tua produttività è solo una frazione a causa della nuova API che stai cercando di apprendere durante le tue attività. Ovviamente è anche peggio se alcuni addetti alle vendite calcolano con normale produttività quando hanno firmato un contratto con il cliente.

on setting up the servers (SVN, Databases, etc)

Questa è la tua infrastruttura e i costi interni. Quando avvii il progetto, è previsto che tu abbia preparato la tua infrastruttura. La configurazione del tuo ambiente di sviluppo non ha valore per il cliente e non dovrebbe far parte di alcun indicatore relativo al progetto, ad esempio velocity in Scrum. L'ho visto implementato come speciale iterazione pre-progetto utilizzata solo per configurare l'ambiente, creare un'infrastruttura di base, ecc.