Preparazione per il workshop

Completato

In genere, la conduzione del workshop sulle prestazioni della soluzione richiede 2-4 ore circa. Il tempo può variare in base al livello di dettaglio disponibile per la revisione e all'ampiezza della soluzione complessiva. L'architetto di soluzioni collaborerà con la dirigenza del team di implementazione per pianificare il workshop in base alle specifiche della soluzione che saranno oggetto di revisione.

Prima del workshop sulle prestazioni della soluzione, i partecipanti dovrebbero avere la massima familiarità possibile con la struttura del workshop e con i tipi di argomenti e prerequisiti trattati. L'architetto di soluzioni fornirà un ordine del giorno con argomenti e requisiti prima del workshop.

Nota

Essenzialmente, il workshop sulle prestazioni della soluzione è una discussione; non è concepito come un questionario che può essere completato ed esaminato offline. Sebbene i prerequisiti siano definiti e forniti in anticipo, non è possibile sintetizzare tutti gli argomenti a cui potrebbe condurre la conversazione.

L'architetto di soluzioni si preparerà in anticipo per il workshop esaminando prima gli artefatti del progetto esistenti. Ecco alcuni degli artefatti del progetto utili:

  • Revisione del progetto iniziale della soluzione: il completamento di un workshop sulla revisione del progetto iniziale della soluzione è un prerequisito per il workshop sulle prestazioni della soluzione. Le informazioni acquisite in relazione ad aree come il piano del progetto, il diagramma dell'architettura della soluzione, i processi di business, la strategia di integrazione, la strategia per gli ambienti, il numero di utenti, la strategia di migrazione dei dati e altre informazioni sulla soluzione possono tradursi direttamente in questo workshop.
  • Piano/programmazione del progetto: documento o diagrammi di Gantt che illustrano la pianificazione generale e la dipendenza delle fasi chiave del progetto e delle attività associate.
  • Profili di utilizzo del sistema: pianificazioni dei processi operativi e picchi di volumi transazionali per tipo di carico di lavoro.
  • Strategia per gli ambienti: diagrammi a blocchi o di flusso che delineano i tipi di ambienti distribuiti, come e quando verranno usati e il flusso del codice e della configurazione attraverso di essi.
  • Posizioni della distribuzione: diagrammi o registri che indicano le posizioni fisiche in cui verrà distribuita la soluzione insieme ai requisiti di lingua e localizzazione.
  • Registro dell'interfaccia: elenchi di interfacce con requisiti non funzionali e modelli di progettazione che ne documentano l'ambito e l'approccio all'implementazione.
  • Diagrammi del flusso dei dati: in una soluzione con più app Dynamics 365 o servizi e componenti legacy ed esterni, è utile poter identificare l'origine dei dati e il modo in cui vengono spostati e usati nella soluzione.
  • Strategia di migrazione dei dati: documenti o registri che riportano le entità da migrare, con le fonti da cui proverranno, i volumi, i tempi e le modalità di migrazione. Nella fase di progettazione iniziale della soluzione, è fondamentale assicurarsi di conoscerne l'ambito (entità e origini dati).
  • Strategia di test delle prestazioni: qualsiasi documentazione preesistente sulla strategia di test delle prestazioni che descriva aree quali obiettivi prestazionali, KPI, strumenti di test, ambiente da usare e altri fattori coerenti con i test delle prestazioni.

Questo non è un elenco esaustivo dei risultati finali del progetto, ma è un buon punto di partenza per il workshop sulla revisione delle prestazioni della soluzione. I formati, la composizione e i nomi di ciascun documento possono variare da un progetto all'altro. L'elemento più importante non è il formato, ma le informazioni disponibili e concordate in tutto il team.

Quando si conduce una revisione delle prestazioni della soluzione all'inizio del progetto, molti di questi documenti non saranno del tutto sviluppati, il che è accettabile nella maggior parte dei casi. La cosa più importante è che sia stato definito l'ambito del progetto e che sia presente un piano concettuale per il modo in cui la soluzione supporterà tale ambito. Se sono definiti l'ambito e l'approccio concettuale alla soluzione, la revisione delle prestazioni della soluzione può concentrarsi sull'approccio concettuale e poi sul completamento, mentre i workshop più approfonditi potranno concentrarsi sui dettagli quando saranno disponibili.

È accettabile che, per gestire o tener traccia delle informazioni di progetto, il progetto applichi metodi diversi da quanto mostrato dall'elenco precedente. In genere, il formato non è un aspetto critico se le informazioni sono subito disponibili per i membri del progetto. Se le informazioni dell'elenco precedente non sono documentate sul progetto o se sono documentate in un modo che le rende non facilmente accessibili, è necessario dare la priorità alla produzione degli artefatti rilevanti.

Suggerimento

Si consiglia di usare diagrammi e rappresentazioni visive per fornire riepiloghi complessivi nell'implementazione, quando possibile. Tali diagrammi e grafici forniscono un rapido mezzo di comunicazione su piani e progetti all'interno del team e con la dirigenza.