Consigli per formalizzare le procedure di gestione dello sviluppo software

Si applica a questa raccomandazione della checklist di eccellenza operativa ben progettata: Power Platform

Questa guida descrive i consigli per la gestione delle procedure di sviluppo del carico di lavoro in conformità con gli standard stabiliti. La capacità del tuo team di produrre software di alta qualità si basa su un approccio strutturato e collaborativo alla pianificazione dello sviluppo. I team addetti al carico di lavoro devono comprendere e comunicare chiaramente alle parti interessate il lavoro che stanno svolgendo Fatto. Più precisamente, i team addetti al carico di lavoro dovrebbero avere una visione chiara del lavoro da svolgere in un ciclo di sviluppo e assicurarsi che tutte le parti interessate siano allineate sul "perché" di tale lavoro. Gli standard stabiliti definiscono come dovrebbero essere eseguite le procedure di sviluppo e consentono al team del carico di lavoro di collaborare in modo efficace, riducendo il rischio di confusione su obiettivi e aspettative.

Strategie di progettazione chiave

Formalizza le procedure di sviluppo del carico di lavoro per garantire una comprensione comune degli obiettivi e delle aspettative.

Non trattare i carichi di lavoro con poco codice come a bassa complessità. Puoi comunque trarre vantaggio dalla formalizzazione dello sviluppo e della gestione dei carichi di lavoro Fatto. Impara da altri team di sviluppo software. Avere una matrice decisionale che stabilisca il livello di formalizzazione richiesto in base alla complessità e alla criticità del carico di lavoro.

Standard per la pianificazione dello sviluppo

I seguenti standard possono aiutarti a progettare una strategia completa di pianificazione dello sviluppo.

• Definizione delle priorità: per pianificare l'ordine e l'ambito del lavoro è necessario comprendere il vero impatto e il valore delle funzionalità del carico di lavoro sull'azienda. Include anche la valutazione di tali impatti rispetto ad altre richieste di lavoro e la roadmap complessiva per il tuo prodotto o programma. Un modo per dare priorità ai carichi di lavoro è la valutazione del valore aziendale dell'intero carico di lavoro. Potrebbe anche essere utile valutare le singole caratteristiche del carico di lavoro in termini di valore aziendale.

• Categorizzazione: stabilire processi che garantiscano che le applicazioni critiche abbiano le protezioni necessarie per supportarle. Allo stesso tempo, assicuratevi che gli scenari di produttività non siano rallentati o soffocati da troppi processi rigorosi.

• Collaborazione: il processo di definizione delle modifiche proposte al carico di lavoro dovrebbe essere uno sforzo collaborativo. La maggior parte delle modifiche al carico di lavoro interessa più funzioni e componenti, pertanto coinvolgere il maggior numero possibile di membri del team addetto al carico di lavoro aiuta a garantire che non vengano trascurate considerazioni importanti e che tutti siano consapevoli dell'impatto sul proprio specifico dominio. La collaborazione aiuta anche a definire chiaramente la portata di un cambiamento e a suddividere le attività necessarie in elementi di lavoro ben definiti. Un gruppo più ampio con competenze in diversi settori è in grado di fornire stime basate sull'esperienza per lo sforzo richiesto.

• Strumenti: utilizzare strumenti e processi consolidati e collaudati nel settore, come Agile, Scrum e Kanban board.

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

• Distribuzione: pianificare l'utilizzo di distribuzioni iterative frequenti, di piccole dimensioni, anziché distribuzioni grandi e poco frequenti.

• Termini: standardizza la definizione dei cicli di sviluppo terminati per garantire che le funzioni di supporto, tra cui test, documentazione e funzionalità con poco codice, vengano completate con successo.

• Comunicazione: definire i protocolli standard per i proprietari dei prodotti e i project manager per le prossime versioni alzare di livello.

• Storie utente: standardizzare un modello per le storie utente. Le storie degli utenti ben scritte dovrebbero seguire l'approccio INVEST:

  • I-Indipendente: ogni storia dell'utente dovrebbe essere indipendente dalle altre, consentendo al team di fornire risultati in piccoli passaggi incrementali.
  • N–Negoziabile: le storie degli utenti dovrebbero essere negoziabili e aperte alla discussione e al cambiamento.
  • V–Valore: le storie utente devono fornire valore al cliente.
  • E–Stimabili: le storie degli utenti dovrebbero essere stimabili e avere una chiara definizione di fatto.
  • S-Small (piccolo): le storie degli utenti dovrebbero essere piccole e focalizzate su una singola funzionalità.
  • T-Testabili: le storie degli utenti dovrebbero essere testabili e avere criteri di accettazione chiari.

• Criteri di accettazione: standardizzare un modello per i criteri di accettazione. Verifica che i criteri di accettazione si riferiscano specificamente alla storia dell'utente e possano essere dimostrati in modo inequivocabile utilizzando uno o più test di accettazione.

• Tracciabilità: garantire che il processo di sviluppo sia tracciabile. È consigliabile tracciare chiaramente lo stato del carico di lavoro di produzione e del codice associato fino ai test di garanzia della qualità, ai criteri di accettazione, alle storie degli utenti e alle funzionalità. In alcuni casi, come ad esempio nell'assistenza sanitaria, la tracciabilità dettagliata potrebbe anche essere un requisito normativo.

• Revisione: eseguire regolarmente audit interni delle proprie pratiche di sviluppo attraverso retrospettive e post-mortem del ciclo di sviluppo. La riflessione sul processo dovrebbe essere irreprensibile e dovrebbe concentrarsi sull’apprendimento che può essere applicato come miglioramento. Verifica che il team rifletta sull'efficacia della storia dell'utente e delle attività nel definire le attività necessarie e sull'accuratezza delle stime dei tempi.

• Report: standardizzare i report per le parti interessate che forniscono metriche utili incentrate sul cambiamento. Concentrarsi sul cambiamento consente di monitorare l'accelerazione e la decelerazione del prodotto. Le metriche utili possono includere modifiche in:

  • Tasso di crescita mensile di adozione
  • Prestazioni
  • Tempo di training
  • Frequenza degli incidenti

  La creazione di report non deve essere utilizzata come strumento per valutare il lavoro dei singoli utenti, quindi evita metriche come punti della storia o righe di codice per ciascun tecnico.

Facilitazione di Power Platform

Sebbene non esistano prodotti che facilitino direttamente questa raccomandazione, è possibile utilizzare altri strumenti nello stack. Power Platform Microsoft Azure Boards è un servizio basato sul Web che consente ai team di pianificare, monitorare e discutere il lavoro durante l'intero processo di sviluppo.

GitHub Projects è uno strumento di gestione progetti personalizzabile che consente di organizzare progetti e di integrarsi con i problemi e le richieste pull in GitHub.

Informazioni correlate

• Le migliori pratiche per la gestione agile dei progetti
• Tavole azzurre
• Strategia di supporto all'utente
• Misurazione del valore aziendale delle soluzioni Power Platform
• Pianificazione di un progetto di intelligenza artificiale conversazionale
• Kit di strumenti per il valore aziendale

Passaggi successivi