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

23

A volte nei progetti dobbiamo dedicare tempo ad attività come:

esplorare framework e strumenti alternativi
apprendere il quadro e gli strumenti selezionati per il progetto
impostazione dei server e dell'infrastruttura di progetto (controllo versione, ambienti di costruzione, database, ecc.)

Se stiamo usando User Stories, dove dovrebbe andare tutto questo lavoro?

Un'opzione è di renderli tutti parte della storia del primo utente (ad esempio creare la homepage per l'applicazione). Un'altra opzione è quella di fare un picco per queste attività. Una terza opzione è rendere l'attività parte di un Problema / Impedimento (ad esempio un ambiente di sviluppo non ancora selezionato) piuttosto che una Storia utente.

— Asim Ghaffar
fonte

ho cambiato un po 'la domanda per renderlo più chiaro .. la domanda ora ha come compiti secondari nelle storie degli utenti reali invece che come storie

— Asim Ghaffar,

12

Abbiamo riflettuto molto su questo problema nell'ultimo anno.

Mentre sono d'accordo che dovrebbe esistere un quadro di base prima dell'inizio del progetto, in pratica può far parte del progetto stesso. Quindi devi gestirlo in qualche modo.

Mentre mescolare la configurazione del progetto con le storie degli utenti a volte potrebbe avere senso, a volte abbiamo optato per 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 giustificati in ogni caso. Se la squadra ritiene che siano assolutamente necessari per raggiungere un determinato obiettivo, faranno parte di uno sprint.

È difficile dire cosa funzioni meglio per te, quindi sperimenta ! Un picco potrebbe essere sufficiente per ora, ma penso che finirai con lo stesso problema più tardi, quindi pianifica in anticipo. Eseguire attività che sono un segnaposto per tali attività. Per separare i compiti dalle storie due, li confronterò rapidamente in base alla mia esperienza con essi.

Compito: un compito è una necessità tecnica. Potrebbero essere cose per la gestione della configurazione o l'impostazione generale del progetto, come impostare un repository per commit o aggiungere lo strumento di revisione del codice più caldo che tu abbia mai visto al processo di sviluppo. Le attività dovrebbero essere considerate nella pianificazione, come nella storia di un utente. Se il team è in grado di convincere il proprietario del prodotto che avere l'ultimo e più grande strumento di revisione del codice aumenta le prestazioni e aumenta la comunicazione del team eliminando sessioni di programmazione di coppie di lunga durata o revisioni del codice di persona, attirerà l'attenzione del proprietario del prodotto.

Storie : incentrate solo sulla prospettiva aziendale, le storie producono sempre un valore visibile per il cliente. La qualità interna è qualcosa che accompagna la produzione di valore aziendale.

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

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

Separare "installazione" e elementi tecnici in attività (elementi che non producono direttamente valore commerciale per il proprietario del prodotto).
Forse fare un picco prima della configurazione del progetto per mettere in atto gli strumenti più importanti (SCM, strumenti di sviluppo, definizione del processo, standard di codifica ecc.)
Accetta il fatto che questi compiti vengano visualizzati per tutta la durata del progetto e pianificali avendo un "tipo" di attività diverso dalle storie.

— Malte
fonte

Quindi quello che stai chiamando TASK è fondamentalmente un oggetto di lavoro come User story o Bug? .. Non è TASK come nelle attività all'interno di user story come codice, test, deploy ecc.

— Asim Ghaffar,

2

Sì, per distinguere tra quelli che chiamiamo sotto-compiti delle storie "Attività".

— malte,

Quello che chiami Task è quindi sostanzialmente un problema come da MSF per Agile 5.0

— Asim Ghaffar,

Se fai riferimento a questa descrizione qui: msdn.microsoft.com/en-us/library/dd997897.aspx - Potresti chiamarlo un problema come è stato descritto lì, penso che sia appropriato. Quindi sarebbe l'opzione numero 3.

— malte

2

Il punto 3 "Accetta che queste attività vengano visualizzate durante la durata del progetto" è particolarmente importante. Il processo unificato Agile ha un'ottima immagine che lo dimostra: i.stack.imgur.com/CUVFI.jpg . Si noti che la loro disciplina "ambientale" non scompare mai veramente. Si noti inoltre che la maggior parte del lavoro ambientale è in anticipo. Quindi, se improvvisamente scopri che stai facendo un sacco di lavoro ambientale in una fase successiva, potrebbe esserci qualcosa che non va.

— Michael,

4

Fai tutto ciò che ha più senso nella tua azienda. Non lasciare mai che altre persone facciano un ostacolo al buon senso.

Ma dirò che tutti questi compiti sembrano qualcosa che dovrebbe accadere molto prima che inizi lo sviluppo. Quindi mi chiedo se Scrum sia persino rilevante per questi compiti. C'è un po 'di manutenzione in corso e simili al controllo del codice sorgente e ai database, ma questi non dovrebbero essere programmati, dovrebbero essere solo cose che accadono ed influenzare la tua velocità.

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

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

— pdr
fonte

quando ho detto framework .. era come dovremmo andare per JSF o Spring .. o quando ho detto tool .. era come dovremmo andare per Jboss o Glassfish ..

— Asim Ghaffar,

1

Non so cosa significhi "molto prima di iniziare lo sviluppo" .. quando inizia il progetto, non dovresti sprint 1 iniziare APPENA POSSIBILE ad es. Entro 2 settimane dalla data di inizio del progetto ... e nello sprint 1 c'è una vera codifica.

— Asim Ghaffar,

1

@AsimGhaffar: non penso che dovrebbe, no. Se inizi a scrivere codice prima ancora di aver preso decisioni come quale server delle applicazioni utilizzare, prenderai almeno una decisione che richiede di riscrivere la maggior parte di quel codice. E non riesco a immaginare di iniziare un progetto al giorno d'oggi senza il controllo del codice sorgente impostato. Voglio dire ok, se hai sviluppatori in giro, trova loro qualcosa di produttivo da fare, come i prototipi. Ma non andare a capofitto nel progetto fino a quando non hai preso le decisioni chiave.

— pdr,

"non dovrei sprint 1 inizio al più presto, ad es. entro 2 settimane dalla data di inizio del progetto". Corretta. Ciò significa che il tuo ambiente è pronto e pronto all'uso. Sei già abile nell'uso degli strumenti, eseguendo build e implementazioni. Se non sei già esperto in queste cose e l'ambiente non è configurato, allora non sei pronto per iniziare.

— S. Lott,

@ S.Lott hmm Ho pensato che si ottengano le competenze richieste SUL LAVORO, cioè mentre si lavora sul progetto e non ci sono prerequisiti per l'apprendimento dello sprint 1.

— Asim Ghaffar

2

C'è un nome per prendere il maggior numero possibile di decisioni di progettazione in anticipo prima dell'inizio "ufficiale" del progetto. Si chiama cascata. Non c'è niente di sbagliato nelle storie degli utenti come "Come sviluppatore, devo selezionare un framework, quindi abbiamo un punto di partenza per il sito web". Se è troppo grande per essere inserito in un'iterazione, prova a scomporlo come "Come sviluppatore, devo implementare una home page di base in Drupal, quindi sapremo se si adatta alle nostre esigenze".

— Karl Bielefeldt
fonte

1

Un'opzione è di renderli tutti parte della storia del primo utente, ad esempio creare la homepage per l'applicazione.

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

Un'altra opzione è quella di fare un picco per questo.

Non male.

La terza opzione è quella di rendere l'attività parte di un Problema (ad esempio un ambiente di sviluppo non ancora selezionato) piuttosto che una User story.

Più o meno come un picco per quanto riguarda la pianificazione e le spese generali.

L'installazione non è una storia utente.

È quello che dovresti avere in atto prima ancora di iniziare questo progetto.

Non puoi davvero avviare il progetto se non hai il framework / tool e i server configurati e pronti per partire.

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

— S. Lott
fonte

il problema non è lo stesso di Spike .. Pensa al problema come elemento di lavoro programmato nello sprint normale ma non ha punti trama. Esempio di problema: SVN non è selezionato. Sto prendendo in prestito la parola problema da MSF per Agile 5.0

— Asim Ghaffar,

"il problema non è lo stesso di un picco". Per le definizioni delle parole, hai ragione. Ma quando pensi di pianificare un lavoro extra prima dello sprint 1, non importa se lo chiami un problema o un picco. Sceglierne uno. Lancia una moneta. Teste.

— S. Lott,

Ancora una volta intendevo programmare problemi insieme a storie all'interno di Sprint 1 - non prima di Sprint 1. Quindi per Sprint 1 diciamo che scegliamo 2 storie utente e 1 problema. Nessun punto della storia per Issue però. Spike infatti sarà prima dello sprint 1 ..

— Asim Ghaffar,

Spike o Issue non importa. È tutto lavoro che non fa parte di una user story. È tutto il lavoro che deve essere fatto prima del primo sprint. Puoi chiamarlo un picco o un problema, qualunque cosa ti renda felice. Ma è non è una storia utente.

— S.Lott

1

Al lavoro utilizziamo un'attività per preparare l'ambiente. Potrebbe essere fonte di confusione per alcune persone, ma l'attività che utilizziamo è molto simile all'attività di una user story. L'attività non appartiene a una user story ma è stimata in ore e deve essere concordata dal proprietario del prodotto per completare in un determinato sprint.

Usiamo anche l'attività per lavori di architettura che non hanno un valore commerciale "apparente" ma che aggiungono qualità al prodotto, in particolare per un prodotto esistente con una base di codice di grandi dimensioni.

Questi potrebbero non essere applicabili nel tuo ambiente di lavoro, ma ha funzionato bene per noi.

— Chris Chou
fonte

0

Penso che stai mescolando due cose indipendenti. Una user story non dovrebbe includere alcun dettaglio tecnico.

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

— BЈовић
fonte

hai ragione e non sto suggerendo di averli nella descrizione della storia .. quello che volevo dire era avere compiti come "installare MySQL", "valutare il framework" come parte della prima vera storia dell'utente .. cioè come utente che voglio una homepage in modo da avere un rapido accesso alle funzionalità essenziali.

— Asim Ghaffar,

@AsimGhaffar Questo può essere fatto nell'iterazione iniziale. Non come una storia utente, dal momento che gli utenti non hanno bisogno di sapere (né dovrebbero preoccuparsene) quale tecnologia hai usato per soddisfare le loro esigenze.

— BЈовић,

0

Di recente ho seguito 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 sul corso con diversi gradi di esperienza in Scrum e praticamente tutte le persone con esperienza erano d'accordo, dicendo che avevano fatto la stessa cosa. In alcuni casi, le aziende hanno utilizzato Sprint 0 per valutare il progetto e hanno deciso se fosse fattibile o meno.

A qualcuno che non conosce la 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 ha lo stesso periodo di tempo degli altri tuoi sprint, agisce come un modo per non perdere troppo tempo a configurare le cose perché possono sempre essere modificate in seguito. Il punto principale è metterti in uno stato in cui puoi effettivamente iniziare a sviluppare il prodotto.

— Stuart Leyland-Cole
fonte

3

Citando Alistair Cockburn Ho la vaga sensazione che qualcuno sia stato pressato riguardo al suo uso di Scrum quando ha fatto qualcosa che all'inizio non aveva alcun valore commerciale evidente e ha inventato "Oh, quello era Sprint Zero!" per allontanare i contadini con i picconi dalla sua porta.

— Asim Ghaffar,

0

sull'esplorazione di 2-3 framework / tool alternativi

A volte questo può accadere se si hanno requisiti speciali, è necessario eseguire alcuni POC per scegliere lo strumento migliore per risolvere il requisito. Questo è lo scopo di Spike, perché senza sapere quale framework utilizzerai molto probabilmente non è possibile stimare la storia e archiviare senza stima non può essere pianificato e suddiviso in attività.

quindi imparando il framework che selezioniamo per il progetto

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

Se devi davvero utilizzare qualcosa di speciale (ad esempio alcune API del cliente o uno strumento selezionato dal cliente) che non hai mai usato prima, devi informare il cliente che il prezzo verrà aumentato in base al tempo necessario per imparare a utilizzare l'API. Forse il cliente cambierà idea se l'aumento dei prezzi sarà troppo grande.

Certo, non intendo la situazione in cui devi cercare qualche nuovo particolare 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 lo violerai, sarà comunque visibile nella tua velocità perché fornirai una quantità molto piccola di valore aziendale per iterazione. Se il cliente non è a conoscenza del motivo, molto probabilmente annullerà il progetto.

Ciò è ancora valido nel caso di progetti interni: è necessario informare il proprio responsabile / azienda in merito al tempo necessario per l'apprendimento di nuove API o strumenti. Di solito ha conseguenze molto negative se il manager conta con la tua normale produttività e la tua produttività è solo una frazione a causa della nuova API che stai cercando di imparare durante le tue attività. Ciò è ovviamente ancora peggio se alcuni addetti alle vendite calcolano con normale produttività quando firmano un contratto con il cliente.

sulla configurazione dei server (SVN, database, ecc.)

Questa è la tua infrastruttura e i costi interni. Quando si avvia il progetto, è prevista la preparazione dell'infrastruttura. L'impostazione dell'ambiente di sviluppo non ha alcun valore per il cliente e non dovrebbe far parte di alcun indicatore relativo al progetto, ad esempio la velocità in Scrum. Ho visto questo implementato come iterazione speciale pre-progetto utilizzata solo per configurare l'ambiente, creare infrastrutture di base ecc.

— Ladislav Mrnka
fonte

Ci occupiamo dello sviluppo del prodotto e non dei progetti dei clienti :).

— Asim Ghaffar,

Ok. In tal caso, dovresti comunque tenere traccia separatamente del tempo dedicato all'apprendimento e all'infrastruttura per vedere quali costi generali hai. Nascondersi questa volta all'interno delle attività corromperà la visibilità del processo di sviluppo.

— Ladislav Mrnka,