Governance di co-sviluppo

La creazione di un efficace framework di governance di co-sviluppo è una parte importante per garantire coerenza e ripetibilità nei Fusion Teams e nei progetti definiti dall'autore. Questo articolo descrive un approccio alla definizione di un diagramma di flusso di governance.

Definizione del processo end-to-end

Puoi utilizzare il seguente processo come esempio e personalizzarlo in base alle procedure consigliate della tua organizzazione. Non è necessario completare ogni singolo passaggio, purché si raggiunga il risultato richiesto.

Aggiungere funzionalità al backlog

I backlog consentono di pianificare il progetto aggiungendo funzionalità che guidano l'esperienza complessiva. Il backlog fornisce anche la roadmap generale che il team intende fornire.

Quando si aggiunge una nuova funzionalità al backlog, l'obiettivo è descrivere l'ambito generale. Ciascuna funzionalità definisce quindi il valore aziendale, crea titoli bozza delle storie, l'ambito e le modifiche del modello di dati che guidano le attività di sviluppo del codice.

Inoltre, quando si aggiunge una funzionalità business-critical, è consigliabile identificare eventuali scenari critici per automatizzare i test. Dopo aver aggiunto le funzionalità, puoi pianificare la riunione di allineamento dell'ambito.

Riunione di allineamento dell'ambito

L'obiettivo di questa riunione dovrebbe essere limitato alla revisione di ogni nuova funzionalità proposta, quindi alla verifica di eventuali app, scenari o modelli di dati esistenti che già forniscono questa funzionalità per evitare la duplicazione degli sforzi. Questa riunione offre anche l'opportunità di discutere l'impatto su altre app. Infine, è consigliabile controllare se questa funzionalità richiede una revisione dell'esperienza.

Aggiungere storie e storyboard al backlog

Dopo la riunione di allineamento dell'ambito, è possibile aggiungere qualsiasi bozza dei titoli per le storie utente nella funzionalità. A questo punto, i dettagli non sono richiesti e lo stato della storia dell'utente è "Nuovo". Puoi visualizzare le storie nel backlog o nella visualizzazione della scheda.

La figura seguente mostra una storia utente di esempio aggiunta a un backlog.

A questo punto, è fondamentale mantenere la qualità organizzando il lavoro per flusso di lavoro e applicazione. Questo approccio aiuta a tenere insieme gli elementi di lavoro correlati e consente agli esperti in ogni flusso di lavoro di sviluppare e mantenere una comprensione approfondita della funzionalità e dell'utilizzo dei dati all'interno di ciascuna app.

Revisione dell'esperienza

Le revisioni dell'esperienza dovrebbero concentrarsi sull'esperienza dell'utente finale e garantire che il team segua le migliori procedure consigliate. Questa coerenza garantisce che tutte le tue app offrano un'esperienza affidabile e ripetibile per gli utenti finali e i team di supporto.

Aggiungere i dettagli della storia

L'aggiunta di una tipica storia dell'utente può includere le seguenti informazioni:

1. Titolo: in quanto <persona>, posso <do something> in modo che <impact/priority/value>
2. Descrizione: la descrizione include (sebbene non sia limitata a) alcuni dettagli chiave, come ad esempio:
   • Breve descrizione dello scenario che riepiloga il risultato desiderato
   • Narrativa: descrive le azioni che gli utenti intraprenderanno per esplorare e realizzare lo scenario
   • Narrativa alternativa: descrive altri modi in cui gli utenti possono ottenere lo stesso risultato
   • Note di progettazione: registra l'entità, i campi, le visualizzazioni, le schermate di mockup e le regole aziendali associate alla storia dell'utente
   • Ruoli di sicurezza interessati: elenca tutti i ruoli di sicurezza interessati o rilevanti per la storia dell'utente.

Dopo aver aggiunto tutti questi dettagli, dovresti cambiare lo stato della storia dell'utente in "Pronto per la revisione". Nella maggior parte dei casi, il team delle funzionalità e il team aziendale (se applicabile) esaminano le storie degli utenti.

Revisione della storia

Le revisioni della storia in genere si verificano all'interno del fusion team per garantire che tutti i dettagli siano richiamati nella storia e che non ci siano ambiguità. Dopo il completamento di tutte le revisioni, la raccomandazione è di assegnare la storia dell'utente a un membro del team. Garantire che il tuo team rimanga allineato durante il processo di sviluppo è fondamentale per raggiungere i tuoi obiettivi generali.

Aggiungere attività e test case

Dopo aver esaminato le storie, i membri del team creano attività in Azure DevOps. Il processo generale per l'aggiunta di attività e test case è il seguente:

1. Apri uno sprint backlog. In alternativa, crea un nuovo sprint.
2. Aggiungi elementi di lavoro esistenti allo sprint. Se hai già aggiunto elementi di lavoro che non vengono visualizzati nello sprint, dovresti controllare la loro area e i percorsi di iterazione. Ricordati di assegnare eventuali attività senza genitori agli elementi di lavoro pertinenti.
3. Aggiungi attività agli elementi del backlog. Se non hai elementi di backlog assegnati al tuo sprint, fallo ora. Imposta inoltre le date di inizio e fine dello sprint.
4. Compila il modulo di attività. Come regola generale, il completamento delle attività non dovrebbe richiedere più di un giorno. Le attività più grandi di questa scala temporale dovrebbero essere suddivise.
5. Tieni traccia o integra qualsiasi attività senza genitori. Puoi tenere traccia delle attività senza genitori proprio come le altre attività o trascinarle su un elemento del backlog esistente per controllarle.

Dopo aver aggiunto attività e test case, puoi quindi impostare la capacità dello sprint.

Per ulteriori informazioni sull'aggiunta di attività, vedi gli elementi Aggiungi di attività al backlog a supporto della pianificazione dello sprint.

Preparare le soluzioni

Un aspetto importante per un co-sviluppo di successo è un processo strutturato di gestione dei rilasci. Le soluzioni sono il meccanismo per l'implementazione del ciclo di vita delle applicazioni (ALM); utilizzi le soluzioni per distribuire i componenti negli ambienti tramite le attività di esportazione e importazione. Un componente rappresenta un artefatto utilizzato nella tua applicazione e qualcosa che puoi potenzialmente personalizzare. Tutto ciò che può essere incluso in una soluzione è un componente, come tabelle, colonne, canvas e app basate su modello, flussi Power Automate, chatbot, grafici e plug-in.

Distribuzioni

I componenti possono richiedere più sprint per essere completati a seconda della complessità e della velocità del team. I componenti devono essere aggiunti a una soluzione in un ambiente di sviluppo man mano che le attività vengono completate. Le soluzioni vengono quindi importate in un ambiente di produzione dopo essere state testate. È consigliabile di mantenere anche un ambiente di test per eseguire test end-to-end e provare la distribuzione della soluzione prima di passare alla produzione.

Ambienti Power Platform

Gli ambienti sono uno spazio in cui archiviare, gestire e condividere dati aziendali, app e processi aziendali dell'organizzazione. Fungono inoltre da contenitori per separare le app in base ai diversi ruoli, requisiti di sicurezza o destinatari.

Se la tua organizzazione ha una configurazione con più tema di fusione in cui ogni team sta sviluppando le proprie soluzioni, è importante coordinare la durata degli sprint e dei rilasci. Gli sprint non devono essere di lunghezza costante lungo una sequenza temporale del progetto e possono variare in durata tra i team, in base alle preferenze di ciascun gruppo. Tuttavia, la cadenza dei rilasci non può essere inferiore alla durata dello sprint più breve in tutti i team.

Controllo del codice sorgente

Prendi in considerazione l'adozione di un sistema di controllo del codice sorgente come Azure DevOps. Azure DevOps fornisce servizi di sviluppo per team di supporto per pianificare il lavoro, collaborare allo sviluppo di codice e creare e distribuire applicazioni.

Esportare una soluzione dall'ambiente di sviluppo contenente app e personalizzazioni, decomprimere la soluzione e archiviare i componenti nel sistema di controllo del codice sorgente.

Argomento avanzato: revisioni delle richieste Pull (PR)

Devi creare PR solo per le storie attive e le cui funzionalità sono state riviste e approvate. È consigliabile assicurarsi che il controllo delle versioni della soluzione sia accurato, seguendo le linee guida per lo sprint e lo sviluppo definite in Implementare le pratiche di Scrum per il tuo team in Azure Boards. I risultati dei test delle PR possono essere screenshot o video che descrivono la funzionalità in fase di creazione.

L'automazione del processo di governance delle PR aiuta a garantire la qualità del codice senza richiedere una revisione manuale dei controlli di base come le versioni delle soluzioni.

Modelli e standardizzazione

I modelli e la standardizzazione offrono efficienza contribuendo a promuovere la coerenza all'interno del team. Tutti gli aspetti delle operazioni del team— che si tratti di attività di onboarding, presentazioni di revisione della storia o modelli di elementi di lavoro che aiutano a risparmiare tempo e forniscono indicazioni ai team quando si definiscono storie utente, funzionalità, bug o attività— traggono vantaggio dalla standardizzazione e dalla semplificazione.

Implementazione di un modello di supporto efficace

Un modello di supporto efficace è essenziale per il successo a lungo termine di un'applicazione dopo la sua distribuzione, come evidenziato nella sezione precedente sulla generazione di una matrice di supporto. Bug e interruzioni sono inevitabili, quindi è fondamentale che il team abbia un approccio strutturato per affrontare questi eventi e la matrice di supporto fornisca il framework necessario.

Creazione del contratto di servizio

Un fattore chiave in qualsiasi modello di supporto è la definizione del contratto di servizio. Il contratto di servizio dovrebbe essere un documento formale redatto dal team che contiene sezioni che trattano i seguenti elementi:

• Interruzioni – quale livello di interruzione del servizio è accettabile, chi informare, quali azioni intraprendere, conferma della ripresa del servizio e azioni per evitare che si ripeta. Qualsiasi procedura di test automatizzata utilizzata dal team deve essere allineata alla tolleranza di interruzione prevista e al contratto di servizio applicabile.
• Bug – chi può notificare, assegnazione dei livelli di gravità, classificazione, azioni di rilevamento, chi è responsabile della risoluzione e della chiusura.
• Escalation – livelli di escalation, assegnazione del personale ai livelli, responsabilità a ciascun livello, liste di distribuzione per ogni livello e così via.

Il contratto di servizio deve essere archiviato nel portale della documentazione del team e aggiornato secondo necessità.

Distribuzione del supporto per l'applicazione

L'approccio migliore per fornire il supporto dell'applicazione specificato nel contratto di servizio è che anche il team che ha creato la soluzione sia responsabile del supporto. I vantaggi di questo sistema sono:

1. Incoraggia uno sviluppo di qualità migliore, perché coloro che hanno creato l'app sanno che dovranno supportarla.
2. I creatori saranno in grado di trovare e correggere i bug più rapidamente di un team di terze parti, semplicemente perché conoscono meglio l'app.
3. Delegare la correzione di software potenzialmente mission-critical a un altro gruppo può essere demoralizzante e richiedere molto tempo per quel gruppo. Come per altre fasi di creazione, sviluppo e distribuzione delle applicazioni, il fusion team dovrebbe collaborare con l'IT per ricevere assistenza quando necessario.

Monitoraggio della soddisfazione e dell'usabilità delle applicazioni

La parte finale delle attività di supporto consiste nel monitorare e valutare la soddisfazione e l'usabilità dell'app distribuita. Le metriche sono utili qui, insieme a metodi più tradizionali, come sondaggi e questionari. Per ulteriori informazioni sul monitoraggio dell'utilizzo dell'app, vedi Analisi dell'amministratore per Power Apps.

In definitiva, se i clienti non utilizzano un'app pubblicata, l'app non soddisfa il suo scopo. Riunioni di revisione regolari possono verificare queste metriche di soddisfazione e usabilità per creare un ciclo di feedback positivo che può modificare o aggiungere storie al backlog per generare e quindi distribuire una versione aggiornata dell'app.

Riepilogo

Lo sviluppo di strumenti senza utilizzo o a basso utilizzo di codice come Power Apps ha ampliato la gamma di opzioni a disposizione di esperti di tecnologia o autori per creare, sviluppare e distribuire app. Questo sviluppo funziona meglio all'interno di un ambiente di fusion team, che comprende un proprietario del prodotto, un esperto di dominio, uno sviluppatore professionista e un amministratore, con questo team che apporta altre risorse come richiesto.

L'integrazione degli approcci di sviluppo agile e Scrum all'interno dei fusion team si traduce in uno sviluppo di app più rapido e in una maggiore probabilità di successo dell'implementazione con un set di funzionalità che fa una differenza significativa per l'azienda. Applicando queste procedure consigliate, linee guida e raccomandazioni, il tuo fusion team sarà in grado di utilizzare Power Apps per affrontare le sfide della trasformazione digitale della tua organizzazione.