Definizione di Azure Boards
Azure Boards è uno strumento di Azure DevOps per aiutare i team a pianificare il lavoro da eseguire. Il team di Tailspin userà questo strumento per ottenere un'idea migliore del lavoro da eseguire e di come classificarlo in ordine di priorità.
Mara ha creato il proprio progetto in Azure Boards usando il processo Basic. Illustra i problemi nel processo di compilazione che lei e Andy hanno individuato. Mara riunisce il team per fare una breve presentazione.
Mara: Ciao a tutti. Ho configurato Azure Boards e volevo illustrarvi alcuni elementi di lavoro che ho individuato.
Andy: Che cos'è un elemento di lavoro?
Mara: Gli elementi di lavoro ci consentono di pianificare e gestire un progetto. Un elemento di lavoro può tenere traccia di tutti i tipi di attività. Può essere un'attività da eseguire, un bug da correggere o qualche altro problema. È possibile assegnarli a diverse persone e tenere traccia del loro avanzamento.
Forse è più semplice se ve li faccio vedere. Questo è Azure Boards che usa il processo Basic:
Amita: Parlaci del processo Basic, ci sono altre opzioni?
Mara: Esistono quattro processi tra cui scegliere. È possibile usare:
- Capability Maturity Model Integration (CMMI): Ciò riguarda in realtà le organizzazioni di grandi dimensioni ed è piuttosto complicato. Quindi non l'ho usato.
- Scrum: Scrum dipende da un master Scrum che guida il team Scrum. Il master Scrum si assicura che tutti capiscano i concetti, le procedure e le regole di Scrum. Non abbiamo un master Scrum. È qualcuno che generalmente riceve una certa formazione e certificazione, quindi non ho scelgo nemmeno questo.
- Agile: Questa sembra essere la scelta più ovvia visto che parlo sempre di Agile ma presenta alcuni altri aspetti da considerare rispetto all'opzione più semplice.
- Basic: Basic, lo dice il nome, è l'opzione di base. È semplice, ma ha tutto ciò che ci serve per avviare subito una pianificazione efficace. Ecco perché l'ho scelto. Nel flusso di lavoro Basic si spostano le attività da Da fare a In corso a Completate.
Amita: OK, usiamolo per cominciare. Poi possiamo passare a qualcos'altro, giusto?
Mara: Esatto. Scegliamo quindi qualche elemento di lavoro che pensiamo di poter sistemare in un paio di settimane.
Andy si ritrova nelle problematiche individuate, ma il resto del team ha delle domande.
Tim: Questi sono principalmente problemi di sviluppo. Ma visto che siamo in argomento, altri team discutono di vulnerabilità del codice. Mi è stato chiesto di dimostrare che il nostro codice è sicuro. È possibile aggiungere anche questo?
Mara: So che l'elenco non è completo. I problemi che vedete sulla lavagna sono quelli di cui abbiamo discusso io e Andy in precedenza. Alcuni di questi problemi in realtà devono essere suddivisi in attività più piccole. Capisco il problema della vulnerabilità del codice. Andy, che cosa ne pensi?
Andy: Attualmente è già difficile consegnare una build. Cominciamo con problemi di base. Mi piace l'idea di avere un punto unico in cui tenere traccia di tutti problemi. Possiamo aggiungerne altri al backlog e stabilire le priorità quando siamo pronti per farlo.
Mara: Prima di aggiungere altri problemi, analizziamo un po' meglio quello a cui ognuno di noi sta lavorando.
Ogni membro del team condivide ciò a cui sta lavorando e le proprie preoccupazioni. Come attività di brainstorming, attaccano dei memo su una lavagna. La lavagna si riempie rapidamente.
Alla fine il team individua sette problemi principali. Andy si offre volontario per aggiungere attività a Azure Boards mentre gli altri guardano. Al termine, la lavagna ha l'aspetto seguente:
Amita: Wow, i problemi sono parecchi. Come facciamo a risolverli tutti?
Mara: Non dobbiamo risolverli tutti subito. Per ora, abbiamo individuato un backlog, o un elenco di lavoro da cui possiamo scegliere. Quando si pianifica il lavoro, dobbiamo scegliere cosa è più urgente o più importante.
Dopo un altro po' di discussione, il team decide di affrontare i tre problemi che Mara aveva proposto in origine:
- Stabilizzare il server di compilazione.
- Creare un flusso di lavoro basato su Git.
- Creare unit test.
Mara: Questi sembrano i problemi più semplici da affrontare e si riferiscono ad alcune recenti sfide che sono emerse. Ora configuriamo un progetto, un team e uno sprint. Poi possiamo decidere chi fa cosa.
Tim: Cos'è uno sprint?
Mara: Ottima domanda. Lo sprint è la quantità di tempo che abbiamo per completare le attività. Lo sprint ci aiuta a rimanere concentrati. Alla fine possiamo fare una breve riunione per condividere i risultati. Poi possiamo passare alla pianificazione successiva.
I membri del team sembrano un po' tesi.
Mara: Stiamo ancora imparando. Uno sprint è in genere lungo da due a quattro settimane. Diciamo due settimane e vediamo come va. Queste sono quasi tutte attività di cui possiamo occuparci io e Andy. Condivideremo l'avanzamento del lavoro a mano a mano che procede. E poi possiamo trovare il modo di includere tutti.
Mara e il team sono partiti con il piede giusto. Successivamente, sarà l'utente a dover configurare il progetto, il team e alcune attività in Azure Boards.