Come si traccia la configurazione del progetto in un ambiente Scrum?

Se stai chiedendo cosa dice la guida alla mischia, non dice nulla. La guida alla mischia non distingue tra i tipi di lavoro gestiti da scrum. Tutti i lavori sono semplicemente articoli del backlog del prodotto.

Mentre le storie degli utenti sono una manifestazione utile degli articoli del backlog di prodotti, non c'è nulla di particolarmente speciale in loro. Scrum riguarda la visibilità e l'adattamento ai cambiamenti e puoi (e dovresti) farlo per tutto il lavoro, non solo per le storie degli utenti.

Tutte le cose che hai menzionato - Crea scheletro del progetto, Crea sistema di integrazione continua, ecc. - sono gli elementi del backlog del prodotto che devono essere fatti dal team per raggiungere gli obiettivi di sprint e rilascio.

Se sei preoccupato di come fatturarli, la soluzione più semplice è aggiungere un flag "fatturabile" a tutti gli elementi del backlog fatturabile. Ad esempio, utilizza schede di storie colorate diverse o configura il tuo software per aggiungere un tag o un altro segno di identificazione. Oppure, semplicemente prefisso elementi non fatturabili con "NB" nel titolo dell'oggetto o nel nome se non hai altre opzioni.

TL; DR: I tre pilastri del processo di mischia sono "trasparenza, ispezione e adattamento", non "trasparenza, ispezione e adattamento solo per le ore fatturabili".

In Scrum, il lavoro tutto svolto dal team dovrebbe essere tracciato sul backlog. Questo assicura che ci sia trasparenza sul lavoro che deve essere fatto per consegnare un prodotto.

Il backlog non contiene solo storie di utenti, ma può anche contenere altri tipi di elementi del backlog, come debito tecnico, bug, miglioramenti e quelle attività di impostazione del progetto che hai menzionato.

Se vuoi differenziare tra i diversi tipi di elementi del backlog, puoi usare diversi colori di carte se stai usando una lavagna fisica, o usi diversi tipi di ticket se usi una scheda elettronica.

La nostra azienda segue la mischia e ci sono alcune pratiche comuni che aiutano davvero nella fase iniziale:

• Sprint 0 significa impostare il tuo ambiente abbastanza per funzionare
• Sprint 1 è dove inizi ad aggiungere valore
• Le attività sono per il lavoro di infrastruttura
• I picchi sono per la ricerca necessaria per perfezionare la progettazione o scoprire una causa alla radice di un insieme di bug

In genere, un'azienda ha un modo standard di mettere insieme le applicazioni, a meno che l'azienda non sia una start up che lavora sul primo progetto. Sprint 0 significa mettere in quella strada sterrata in modo da poter iniziare ad aggiungere valore. Avrà compiti come l'impostazione dell'ambiente di sviluppo, l'inizializzazione del repository con lo scheletro del progetto, i picchi per aiutare a perfezionare la prima serie di user story, ecc. Essenzialmente, per quanto si possa fare in uno sprint.

I primi sprint di coppia potrebbero avere una velocità ridotta mentre si assegnano priorità a entrambe le funzionalità dell'applicazione e si migliora l'infrastruttura. Potresti finire con l'aggiungere risorse aggiuntive per aumentare la capacità di accumulare pezzi mancanti (ad esempio, l'integrazione, la demo e gli ambienti di pre-produzione).

La linea di fondo è che il proprietario del prodotto è coinvolto nella conversazione e tutto il lavoro è tracciato nel backlog. Tutto il lavoro è prioritario nelle stesse cerimonie di sprint (toelettatura e pianificazione). A volte esiste una chiara dipendenza di un'attività che deve essere eseguita prima di una funzione. Questo viene documentato e tracciato nel backlog in modo tale che l'aumento della priorità della funzione aumenti anche la priorità del task predecessore.

Hai un paio di opzioni qui, ma tutte funzionano allo stesso concetto di sprint zero, adeguatamente coperte in altre risposte.

Se devi dimostrare valore dal di fuori, tutte le storie possono essere inquadrate dal punto di vista dell'utente. Ci vuole un po 'di fare, ma solo il più inerte dei clienti non riuscirebbe ad accettare che vorrete dire, un server di compilazione e un po' di lavoro di base messo a punto dall'inizio. Non ti aspetteresti che un pittore dica, che si alzi e inizi a gettare vernice sui muri senza alcuna preparazione.

Se hai un regno libero, puoi inquadrare le storie dal punto di vista dei vari stakeholder, ad es. Come sviluppatore voglio un server di build in modo da avere un ambiente di compilazione pulito

I dadi e i bulloni sono gli stessi in entrambi i casi, è solo una chiamata gestionale in generale su come viene incorniciato il lavoro.

Questa è una domanda eccellente e una risposta che afferma "Ecco cosa dice la religione SCRUM in modo che tu abbia torto a fare altrimenti" è davvero di nessun aiuto. Questo è doppiamente vero nello scenario classico in cui il Product Owner è un Project Manager rinominato e SCRUM Master è l'ingegnere considerato il più amichevole nella gestione (o l'ingegnere capo non voluto inserito nel ruolo). In questo scenario c'è la tendenza a spingere il team il più rapidamente possibile a definire qualcosa / qualsiasi cosa che può essere stimata per fornire una lunghezza del progetto piuttosto che esaminare sensibilmente il dominio del problema utilizzando Picchi di lunghezza fissa e mettendo anche in atto l'infrastruttura.

L'approccio a questa parte di un progetto software che ha più senso per me è avere una fase di Inception. Questo è meglio descritto nel modello Agile disciplinato . Questo consiste in una fase di pre-Sprint (simile a uno zero di Sprint) in cui il proprietario di architettura e gli ingegneri di piombo si incontrano con l'ordine di acquisto e quindi risolvono problemi grandi e nebulosi di definizione del progetto. Il resto del team può affrontare il lavoro di progetti precedenti o intraprendere esercizi di apprendimento per un breve periodo di tempo in modo che il tempo delle persone non venga sprecato.

Tuttavia classificherei qualcosa di simile alla pipeline di consegna continua in modo diverso. Non hai necessariamente bisogno di una pipeline completa prima di iniziare a lavorare. Potresti assegnare il 30% del tuo primo paio di Sprint per metterlo in atto e nel frattempo definire un processo di consegna documentato, ad es. costruire su una casella pulita, eseguire test di codice e copiare in un'area di gestione temporanea in cui è possibile verificare manualmente le "funzionalità".

Probabilmente queste attività non fanno parte del progetto. Non aggiungerei:

• affitta un ufficio
• acquista computer
• acquista macchina da caffè

Anche se sono compiti necessari che contribuiscono a portare a termine il progetto, si presume che siano già in atto. Non qualcosa che verrà ripetuto per ogni sito web che realizzi.

Le parti interessate saranno annoiate se vedono questo tipo di attività nel backlog. Mette in evidenza che stanno pagando per cose che potrebbero non aver fatto se fossero andati con un altro fornitore che ha già configurato il proprio server CI

Ritarda l'inizio del progetto fino al completamento delle attività di installazione. Gestiscili con Scrum o qualsiasi altro metodo di tua scelta.