Suggerimenti per formalizzare lo sviluppo e la gestione del software
Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:
| OE:03 | Formalizzare i processi di ideazione e pianificazione del software. Trarre dagli standard di settore e organizzativi stabiliti. Usare un backlog comune e con priorità e specifiche sufficientemente dettagliate. In base ai risultati, promuovere miglioramenti continui nel processo di pianificazione. |
|---|
Questa guida descrive le raccomandazioni per la gestione delle procedure di sviluppo software in conformità agli standard stabiliti. La capacità del team di produrre software di alta qualità si basa su un approccio strutturato e collaborativo alla pianificazione dello sviluppo. I proprietari e i responsabili dei prodotti devono essere in grado di comprendere e articolare in modo chiaro agli stakeholder il lavoro che gli sviluppatori stanno facendo in qualsiasi momento in un ciclo di sviluppo. Al contrario, gli sviluppatori devono comprendere gli obiettivi del ciclo di sviluppo tramite funzionalità, storie utente e criteri di accettazione ben scritti. Gli standard stabiliti definiscono il modo in cui devono essere eseguite le procedure di sviluppo e consentono al team del carico di lavoro di collaborare in modo efficace, riducendo il rischio di confusione sugli obiettivi e sulle aspettative.
Strategie di progettazione chiave
Formalizzare le procedure di sviluppo software per garantire che i proprietari dei prodotti, i project manager e gli sviluppatori comprendano gli obiettivi di ogni sprint e forniscano qualità coerente agli stakeholder. Per esaminare le linee guida sulle procedure di sviluppo, vedere la guida all'integrazione continua.
Stabilire standard di collaborazione e comunicazione
Collaborazione: il processo di definizione delle modifiche proposte al carico di lavoro deve essere un impegno collaborativo. La maggior parte delle modifiche apportate al carico di lavoro influirà su più funzioni e/o componenti, quindi coinvolgere il maggior numero possibile di membri del team del carico di lavoro contribuirà a garantire che le considerazioni importanti non vengano perse e che tutti siano consapevoli dell'impatto sul proprio dominio specifico. La collaborazione consente anche di definire chiaramente l'ambito di una modifica e come dividere le attività necessarie per completare la modifica in elementi di lavoro ben definiti, in quanto un gruppo più ampio con competenze in tutti i domini sarà in grado di fornire stime basate sull'esperienza per il lavoro richiesto.
Comunicazione: definire i protocolli standard per i proprietari dei prodotti e i project manager per promuovere le prossime versioni internamente ed esternamente. Ad esempio, è possibile stabilire uno standard per le comunicazioni con parti esterne sulle prossime versioni. Lo standard potrebbe determinare che la comunicazione deve essere inviata due settimane prima del rilascio e un promemoria deve essere inviato 24 ore prima del rilascio.
Revisione: eseguire regolarmente controlli interni delle procedure di sviluppo tramite analisi retrospettive e postmorte del ciclo di sviluppo. La reflection del processo deve essere senza colpa e deve concentrarsi sull'apprendimento che può essere applicato come miglioramenti. Assicurarsi che il team rifletta l'efficacia della storia utente e delle attività nella definizione delle attività necessarie e sull'accuratezza delle stime temporali.
Report: standardizzare i report per gli stakeholder che forniscono metriche utili incentrate sul cambiamento. Concentrarsi sul cambiamento consente di tenere traccia dell'accelerazione e della decelerazione del prodotto. Le metriche utili possono includere modifiche in:
Tasso di crescita mensile di adozione.
Prestazioni.
Tempo di training.
Frequenza degli eventi imprevisti.
La creazione di report non deve essere usata come strumento per valutare il lavoro di singoli utenti, quindi evitare metriche come punti di storia o righe di codice per ogni tecnico.
Scegliere gli strumenti standard del settore
Usare strumenti e processi consolidati e collaudati del settore, ad esempio schede Agile, Scrum e Kanban. Lo sviluppo di strumenti e processi è un'impresa significativa, richiedendo tempo e cicli di sviluppo che altrimenti potrebbero essere spesi per il carico di lavoro. La maggior parte dei tecnici e dei proprietari di prodotti DevOps esperti ha familiarità con questi tipi di strumenti e processi, quindi la curva di apprendimento nell'adozione deve essere minima. Analogamente, il processo di onboarding per i nuovi assunti trarrà vantaggio anche dall'uso di strumenti e processi standard, poiché è probabile che abbiano un grado di esposizione agli stessi strumenti e processi già.
Compromesso: la metodologia Agile può diventare troppo rigida se è eccessivamente prescrittiva. Cercare un equilibrio tra standard ben definiti e innovazione.
Adottare uno standard per acquisire gli scenari degli utenti finali
Storie utente: standardizzare un modello per le storie utente. Assicurarsi che ogni storia utente sia un'unità di lavoro discreta, scritta dal punto di vista dell'utente finale. Le storie utente ben scritte devono avere le caratteristiche seguenti:
Ogni storia utente deve essere completamente indipendente l'una dall'altra. Mantenere le storie utente indipendenti l'una dall'altra evita qualsiasi confusione con il lavoro sovrapposto e aiuta il team a capire se lavorare su una determinata storia utente si basa sul lavoro su qualsiasi altro, che consente di pianificare e classificare in ordine di priorità.
Ogni storia utente è negoziabile. Le prospettive dei membri dell'utente finale e del team del carico di lavoro sono entrambe essenziali per acquisire storie utente realistiche che possono essere eseguite in un breve periodo di tempo.
Le storie utente sono utili per l'utente finale. Quando si scrivono storie utente dal punto di vista dell'utente finale, si acquisiscono le modifiche che sono interessate a visualizzare e che aggiungeranno valore alla loro esperienza. Mantenere questo stato attivo man mano che la storia utente viene suddivisa in elementi di lavoro consente di garantire che ogni distribuzione fornisca un'esperienza migliorata.
Lo sforzo richiesto per una storia utente è stimabile con un alto grado di fiducia. Senza essere in grado di avere una stretta approssimazione delle ore necessarie per una determinata storia utente, la pianificazione sarà difficile e il potenziale per le scadenze mancanti aumenta, causando potenzialmente effetti a catena su altri lavori pianificati.
Le storie utente scritte sono piccole, in modo che possano essere completate entro poche settimane. Le storie con ambito più piccolo aiutano a mantenerle stimabili e gestibili e a mantenere gli elementi di lavoro eseguibili.
Le storie utente devono essere testabili. Senza essere in grado di testare che una funzionalità è stata distribuita, l'utente finale non può avere la certezza che l'obiettivo sia stato raggiunto. Anche se un test non è già stato scritto per una determinata storia utente, dovrebbe esserci una chiara comprensione del modo in cui un test può essere sviluppato per dimostrare la distribuzione della funzionalità.
Criteri di accettazione: standardizzare un modello per i criteri di accettazione. Assicurarsi che i criteri di accettazione siano correlati in modo specifico alla storia utente e possano essere dimostrati senza ambiguità usando uno o più test di accettazione.
Standardizzare le procedure di distribuzione
Distribuzione: pianificare l'uso di distribuzioni di piccole dimensioni e iterative frequenti anziché distribuzioni poco frequenti. L'uso di questo approccio consente di mantenere gestibili le storie utente e gli elementi di lavoro dal punto di vista della gestione dei progetti e ridurre il rischio di problemi su larga scala quando le distribuzioni hanno esito negativo.
Termini: standardizzare la definizione dei cicli di sviluppo completati per garantire che le funzioni di supporto, inclusi test, documentazione e funzionalità di accessibilità, vengano completate correttamente.
Traccia: assicurarsi che il processo di sviluppo sia tracciabile. È necessario tracciare chiaramente lo stato del carico di lavoro di produzione e il codice associato ai test di controllo qualità, ai criteri di accettazione, alle storie utente e alle funzionalità. La traccia dettagliata può anche essere un requisito normativo in alcuni casi, ad esempio il settore sanitario.
Facilitazione di Azure
Azure Boards è un servizio basato sul Web che consente ai team di pianificare, tenere traccia e discutere del lavoro nell'intero processo di sviluppo. È ideale per le procedure di sviluppo basate su Agile.
GitHub Projects è uno strumento di gestione dei progetti personalizzabile che può organizzare i progetti e integrarsi usando problemi e richieste pull in GitHub.
Collegamenti correlati
Collegamenti della community
Elenco di controllo per l'eccellenza operativa
Fare riferimento al set completo di raccomandazioni.