Condividi tramite

Suggerimenti per formalizzare lo sviluppo e la gestione del software

  • Articolo

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, favorire 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 articolato in modo chiaro agli stakeholder il lavoro svolto dagli sviluppatori 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.

Standard per la pianificazione dello sviluppo

  • 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 non vengano perse considerazioni importanti e che tutti sappiano l'impatto sul proprio dominio specifico. La collaborazione consente inoltre di definire chiaramente l'ambito di una modifica e come suddividere 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.

  • Strumenti: 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 dedicati al carico di lavoro. I tecnici e i proprietari di prodotti DevOps più esperti hanno familiarità con questi tipi di strumenti e processi, quindi la curva di apprendimento nell'adozione di tali strumenti deve essere minima. Analogamente, il processo di onboarding per i nuovi assunti trarrà vantaggio anche dall'uso di strumenti e processi standard, in quanto probabilmente avranno una certa esposizione agli stessi strumenti e processi.

Compromesso: la metodologia Agile può diventare troppo rigida se è eccessivamente prescrittiva. Cercare un equilibrio tra standard ben definiti e innovazione.

  • Distribuzione: pianificare l'uso di distribuzioni iterative di piccole dimensioni 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.

  • 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 versioni future. 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.

  • 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 scritte correttamente devono avere le caratteristiche seguenti:

    • Ogni storia utente deve essere completamente indipendente l'una dall'altra. Mantenere indipendenti le storie utente l'una dall'altra evita 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 definire le priorità.

    • Ogni storia utente è negoziabile. Le prospettive dei membri del team dell'utente finale e 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 elevato 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 di scadenze mancanti aumenta, causando potenzialmente effetti a catena su altri lavori pianificati.

    • Le storie utente ben 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 poter testare che sia stata fornita una funzionalità, 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 che possano essere dimostrati senza ambiguità usando uno o più test di accettazione.

  • 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.

  • Revisione: eseguire regolarmente controlli interni delle procedure di sviluppo tramite analisi retrospettive e postmortem 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 dell'adozione.

    • Prestazioni.

    • Tempo di allenamento.

    • 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.

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. È particolarmente adatto per le procedure di sviluppo basate su Agile.

GitHub Projects è uno strumento personalizzabile di gestione dei progetti in grado di organizzare i progetti e integrarsi usando problemi e richieste pull in GitHub.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa