Panoramica di Microsoft Solutions Framework (MSF)

Microsoft Solutions Framework (MSF) è un approccio adattabile che consente di fornire più rapidamente soluzioni tecnologiche, avvalendosi di un minor numero di persone e riducendo i rischi, pur offrendo risultati di migliore qualità. MSF aiuta i team a gestire direttamente le cause più comuni di errori dei progetti tecnologici, migliorando gli indici di successo, la qualità della soluzione e l'impatto sull'azienda.

MSF è incentrato sugli aspetti seguenti:

  • Allineamento degli obiettivi aziendali e tecnologici

  • Definizione di obiettivi, ruoli e responsabilità di progetto chiari

  • Implementazione di un processo iterativo, basato su attività cardine e checkpoint

  • Gestione attiva dei rischi

  • Risposta efficace ai cambiamenti

Gli elementi chiave di MSF esaminati i questo articolo sono i seguenti:

  • Principi fondamentali e modelli mentali di MSF che forniscono ai membri del team orientamento e indicazioni su come collaborare per fornire una soluzione

  • Il modello di team MSF consente la scalabilità dei progetti, garantisce ai team la possibilità di soddisfare le varie esigenze delle parti interessate e definisce responsabilità e ruoli in base agli obiettivi

  • Il modello di controllo MSF, in precedenza denominato modello di processo MSF, produce risultati veloci e di alta qualità tramite un ciclo di vita comprovato del progetto che ne identifica le attività chiave

Principi fondamentali e modelli mentali di MSF

Al centro di Microsoft Solution Framework (MSF) ci sono principi e modelli mentali che rappresentano anni di esperienza. Sintetizzati in concetti applicabili ai vari modelli e processi e alle varie discipline MSF, tali principi e modelli mentali sono alla base di MSF. Nonostante siano concetti comuni, può essere difficile comprenderli e implementarli correttamente. Tuttavia, una volta compresi, il team può, attraverso la collaborazione, creare prodotti di qualità.

Principi fondamentali

I principi e i concetti MSF seguenti consentono a un team di progetto di fornire una soluzione di qualità. Ogni membro del team deve comprendere e applicare tali principi nelle proprie interazioni con altri membri del team, con la propria organizzazione e con le parti interessate. Al centro di MSF ci sono nove principi fondamentali:

  1. Promuovere comunicazioni aperte. Affinché il team sia efficace ed efficiente, è necessario che condivida livelli appropriati di informazioni tra i propri membri e nell'azienda. Il team deve comprendere la natura delle attività da svolgere e le modalità di comunicazione dei propri membri con i contatti esterni. La difficoltà risiede nella determinazione del livello appropriato per ogni relazione e delle informazioni da condividere.

  2. Collaborare per raggiungere una visione comune. Avere una visione condivisa conferisce potere ai membri del team e offre la flessibilità necessaria per prendere rapidamente decisioni informate in una prospettiva di raggiungimento di una visione. Una visione condivisa consente inoltre ai membri del team di colmare le mancanze di requisiti man mano che queste vengono rilevate.

  3. Empowerment dei membri del team. Oltre a essere una delle numerose modalità di sopravvivenza in un ambiente in continuo cambiamento, l'empowerment consente ai membri del team di imparare a svolgere proficuamente la propria attività in modo creativo e ad aiutarsi reciprocamente. Se ai membri del team non è consentito esprimere al meglio le proprie potenzialità, ne risente non solo la loro creatività, ma anche il morale, con conseguenze negative sulla capacità di creare un team ad alte prestazioni.

  4. Definire responsabilità chiare e condivise. I membri del team empowered spesso si sentono più responsabili delle proprie decisioni e disposti a condividere le responsabilità di un progetto. Una maggiore responsabilità dei membri del team determina una qualità più elevata. Se, ad esempio, un membro del team sostiene di aver completato un'attività ma questa, tuttavia, non risulta essere del livello di qualità richiesto, tale membro ha la responsabilità di correggere l'attività in modo da raggiungere i livelli di qualità stabiliti. Incoraggiando la crescita positiva e la responsabilità invece di punire tali errori, il membro del team condivide la responsabilità della soluzione complessiva e dei risultati finali. Ciò rafforza la motivazione dei membri del team, inducendoli a collaborare per raggiungere risultati ottimali rispetto alle loro possibilità.

  5. Fornire valore incrementale. L'offerta di valore incrementale presenta due aspetti:

    1. Verificare che i risultati finali forniti offrano un valore ottimale alle parti interessate.

    2. Determinare gli incrementi ottimali in cui fornire valore, ovvero la "frequenza della fornitura".

  6. Restare agili, prevedere il cambiamento ed essere pronti a gestirlo. Poiché il cambiamento può verificarsi spesso e nei momenti meno opportuni, avere a disposizione un modo agile per gestirlo può contribuire a ridurre al minimo le interruzioni più frequenti che esso causa. Per un'organizzazione restare agile significa essere pronta e in grado di adattarsi agevolmente al cambiamento.

  7. Investire in qualità. Molte organizzazioni abbracciano il concetto di qualità, un termine spesso definito in modo generico, ma non hanno le conoscenze necessarie per quantificarla. La qualità è un elemento da integrare in modo attivo nel ciclo di vita di fornitura delle soluzioni; non è un risultato innato.

  8. Imparare da tutte le esperienze. Se tutti i livelli di un'organizzazione non traggono una lezione dagli aspetti positivi e negativi dei progetti precedenti, come ci si può aspettare che migliorino in futuro? I membri del team devono comprendere che l'apprendimento avviene a tutti i livelli:

    • Al livello di progetto, ad esempio perfezionando un processo esteso all'intero progetto

    • A livello individuale, ad esempio imparando a migliorare le interazioni con gli altri membri del team

    • A livello di organizzazione, ad esempio modificando le metriche di qualità da raccogliere per ogni progetto

  9. Collaborare con i clienti interni ed esterni. La possibilità di successo di un progetto aumenta quando il cliente collabora con il team di progetto. Ciò non significa che i clienti debbano svolgere il lavoro del team. Tuttavia, quando i clienti collaborano a stretto contatto e in modo incrementale con un team di fornitura, la soluzione ottenuta soddisfa meglio le loro aspettative. La collaborazione con i clienti è reciprocamente vantaggiosa perché contribuisce a ridurre le incertezze e il tempo di risoluzione delle domande sui requisiti, nonché ad aumentare da parte del team la comprensione delle proposte di valore della soluzione attraverso interazioni costanti.

Modelli mentali

Mentre i principi fondamentali discussi in precedenza forniscono indicazioni su come orientare un team allo scopo di ottimizzare i risultati, l'orientamento dei singoli membri del team per ottimizzarne il successo è definito modello mentale. Ogni modello mentale aiuta i membri del team a definire una propria specifica fornitura della soluzione. Su un piano ideale, i membri del team acquisiscono una tale familiarità con questi modelli mentali da usarli sia al lavoro sia nella vita personale. Ecco alcuni modelli mentali che ogni membro del team dovrebbe fare propri:

  • Promuovere un team di pari. Se l'organizzazione è in grado di incarnare i principi fondamentali di MSF, in particolare l'empowerment e la responsabilità, ha davvero senso condurre un progetto con una struttura gerarchica? Se tutti comprendono sia la missione sia gli obiettivi in modo da avere una visione condivisa e contribuire con il proprio ruolo e le proprie responsabilità alla fornitura di una soluzione, tutti agiscono in qualità di pari e possono essere trattati equamente. Questo non significa lavorare in anarchia o gestire per comitati, ma fare in modo che tutti condividano la responsabilità della fornitura efficace di una soluzione. Ogni ruolo è singolarmente responsabile dei propri aspetti di un progetto e allo stesso tempo tutti i ruoli sono congiuntamente responsabili del progetto come insieme. Come si vedrà, il ruolo di responsabile di programma continua a esistere, ma è incentrato sulla fornitura di un progetto nell'ambito dei vincoli di progetto, non sulla gestione dei membri del team.

  • Concentrarsi sul valore aziendale. Il successo si misura in termini di valore aziendale offerto. Questo significa non solo offrire un prodotto di cui i clienti hanno bisogno, ma anche fornire ciò che i clienti vogliono e apprezzano. Per fornire valore, tutti i membri del team devono capire che cosa è importante per i clienti. L'incapacità di fornire valore aziendale ai clienti espone il progetto al rischio di andare fuori rotta, di sprecare una notevole quantità di tempo, impegno e risorse male indirizzate e perfino di essere annullato.

  • Mantenere la prospettiva della soluzione. A causa della dimensione e della complessità della maggior parte dei progetti, quando una soluzione viene esaminata nei suoi singoli elementi usabili, i membri del team a volte si concentrano eccessivamente sui dettagli e trascurano il quadro complessivo della soluzione finale. Ecco perché viene posto l'accento sul principio della visione condivisa. Man mano che i membri del team contribuiscono per la propria parte, devono riesaminare la missione complessiva, gli obiettivi e la visione della soluzione. Troppo spesso accade che un sub-team ottimizzi la propria area, nella convinzione di agire per il bene comune, ma scopre di dover rielaborare gli aspetti principali per riportarli in linea con la soluzione; restano intrappolati nei dettagli e perdono di vista la soluzione.

  • Essere orgogliosi della propria abilità. Non solo il team dovrebbe investire in qualità, ma anche i membri dovrebbero capire che la qualità è una responsabilità propria quanto degli altri membri del team e non deve essere delegata o trasferita ad altre persone. Al contrario, la qualità rientra nell'ambito delle responsabilità di ogni persona nel corso dell'intero ciclo di vita relativo alla fornitura della soluzione. Questo modello mentale non include solo la possibilità di una maggiore qualità dei risultati finali raggiunti da un membro del team, ma anche il miglioramento della qualità dell'attivazione dei processi e del controllo del progetto. Questo modello mentale incoraggia inoltre ogni membro del team ad ampliare la propria conoscenza delle competenze necessarie per raggiungere la missione complessiva. Monitorando la propria qualità e fornendo risultati ottimali commisurati alle proprie possibilità, i membri del team possono favorire il miglioramento continuo del prodotto finale.

  • Apprendere continuamente. A volte essere orgogliosi delle proprie competenze e di quelle del team non è sufficiente per raggiungere l'obiettivo finale. I membri del team devono apprendere nuove competenze per migliorare il grado di collaborazione all'interno del team. Poiché la maggior parte dei progetti, dei team e degli ambienti presenta caratteristiche specifiche, ogni progetto offre l'opportunità di apprendere, sperimentare e perfezionare competenze, processi e procedure. Per sfruttare queste opportunità, l'apprendimento e l'adattamento continui devono esistere a tutti i livelli di un'organizzazione, non essere limitati ai membri del team.

  • Fare proprie le qualità del servizio. Le qualità del servizio (QoS) definiscono le caratteristiche operative previste di una soluzione, quali il livello previsto di disponibilità di una soluzione. È essenziale che le parti interessate e i membri del team, non solo gli architetti, comprendano la QoS e in che modo il suo raggiungimento influisce sui risultati finali. Diversamente, le parti interessate e i membri del team faranno probabilmente supposizioni implicite sul comportamento presunto di una soluzione. Poiché queste supposizioni sono raramente allineate, ogni membro del team deve prendere decisioni di progettazione esplicite sin dall'inizio per garantire il soddisfacimento della QoS. In questo modo, i presupposti impliciti vengono convertiti in requisiti QoS espliciti. Inoltre, la QoS è esplicitamente progettata in una soluzione sin dall'inizio e non gestita come una considerazione successiva.

  • Mettere in pratica la buona cittadinanza. Dal punto di vista dello sviluppo software, per buona cittadinanza si intende affidabilità, onorabilità, responsabilità e rispetto in tutti gli aspetti del proprio lavoro. Sono inclusi, a titolo di esempio:

    • Le interazioni con gli altri membri del team, con l'organizzazione e con le parti interessate

    • La partecipazione a un progetto e il contributo alla fornitura di una soluzione, che include la capacità di occuparsi in modo affidabile delle risorse aziendali, di progetto e di elaborazione, nonché la condivisione aperta e consapevole di risorse, informazioni e conoscenze. I "buoni cittadini" agiscono in vista del raggiungimento di un bene superiore.

  • Fornire risultati commisurati ai propri impegni. Nonostante i numerosi controlli e correttivi integrati, MSF si basa sulla fiducia e sull'empowerment, che i membri del team acquisiscono, in parte, fornendo risultati commisurati agli impegni assunti. MSF stabilisce un ambiente in cui i membri del team e le parti interessate possono fidarsi del fatto che gli altri membri del team terranno fede agli impegni assunti in termini di risultati da fornire. Poiché un progetto è un insieme di attività interdipendenti, quando un membro del team non adempie ai propri impegni, crea uno squilibrio all'interno del progetto, mettendolo a repentaglio.

Il modello di team MSF

Il modello di team MSF segmenta le attività e le responsabilità tipiche della fornitura di una soluzione in sette gruppi di sostegno che sono interdipendenti e multidisciplinari. Come indicato nella tabella seguente, per contribuire a un approccio bilanciato, ciascuno di questi ruoli introduce una prospettiva specifica su ciò che è necessario, su ciò che deve essere supportato e su quali siano gli obiettivi associati alla fornitura di una soluzione. Questi ruoli possono essere combinati per situazioni che coinvolgono team di piccole dimensioni e ampliati per situazioni che coinvolgono team di grandi dimensioni.

Non implicano né suggeriscono alcun tipo di organigramma o insieme di qualifiche perché variano notevolmente in base all'organizzazione e al team. La maggior parte delle volte i ruoli vengono distribuiti tra diversi gruppi all'interno di un'organizzazione IT e a volte nell'ambito di una comunità di utenti aziendali, nonché tra consulenti e partner esterni.

Ruolo

Obiettivi

Aree funzionali

Gestione dei prodotti

  • Verificare che la soluzione fornisca valore aziendale

  • Definire la soluzione all'interno dei vincoli di progetto

  • Garantire il soddisfacimento delle esigenze e delle aspettative dei clienti

  • Comunicazioni di marketing/aziendali

  • Analisi aziendale

  • Pianificazione dei prodotti

Gestione dei programmi

  • Fornire la soluzione all'interno dei vincoli del progetto

  • Definire gli strumenti con i quali le esigenze e le aspettative dello sponsor vengono soddisfatte

  • Gestione progetto

  • Gestione dei programmi

  • Gestione delle risorse

  • Garanzia dei processi

  • Gestione della qualità dei progetti

  • Operazioni relative ai progetti

Architettura

  • Progettare una soluzione per soddisfare gli obiettivi aziendali nell'ambito dei vincoli di progetto

  • Architettura della soluzione

  • Architettura tecnica

Sviluppo

  • Compilare la soluzione in base alle specifiche

  • Sviluppo della soluzione

  • Consulenza tecnologica

Esperienza utente

  • Ottimizzare l'usabilità della soluzione

  • Migliorare la conformità e l'efficacia dell'utente

  • Garantire il soddisfacimento delle esigenze e delle aspettative dell'utente

  • Accessibilità

  • Internazionalizzazione

  • Comunicazioni di supporto tecnico

  • Formazione

  • Usabilità

  • Progettazione dell'interfaccia utente

Test

  • Approvare il rilascio della soluzione solo dopo aver verificato che tutti gli aspetti della soluzione soddisfino o superino i rispettivi livelli di qualità definiti.

  • Test di regressione

  • Test funzionali

  • Test di usabilità

  • Test di sistema

Versione/Operazioni

  • Implementazione e transizione alle operazioni prive di problemi

  • Garantire il soddisfacimento delle esigenze e delle aspettative dell'IT/delle operazioni aziendali

  • Release Management

  • Infrastruttura della fornitura

  • Operazioni

  • Gestione della compilazione

  • Amministrazione degli strumenti

Modello di controllo MSF

Il modello di controllo, in precedenza definito modello di processo, è progettato per fornire le giuste indicazioni alle persone appropriate al momento opportuno. È strutturato per consentire a un team di fornire i componenti chiave di una soluzione in tempi più rapidi rispetto a quanto sarebbe possibile se si concentrassero prima sulle funzionalità a priorità più elevata e spostassero quelle meno cruciali alle versioni successive. Il modello è strutturato in modo da portare rapidamente un team a prendere scelte condivise su come fornire i vari aspetti di una soluzione. Il modello di controllo è un componente flessibile di MSF che è stato usato proficuamente per migliorare il controllo dei progetti, ridurre al minimo il rischio, migliorare la qualità delle soluzioni e aumentare la velocità di sviluppo. Poiché MSF è completamente personalizzabile, ci si aspetta che le organizzazioni adattino il modello di controllo ai propri processi aziendali e agli approcci esistenti per la fornitura delle soluzioni.

Il modello di controllo MSF unisce il controllo del progetto con l'attivazione dei processi. Il controllo dei progetti è incentrato sull'ottimizzazione di un processo di fornitura di una soluzione e sull'uso efficiente ed efficace delle risorse di progetto. L'attivazione dei processi è incentrata sulla definizione, compilazione e implementazione di una soluzione che soddisfi le esigenze e le aspettative delle parti interessate.

Gli aspetti chiave del modello di controllo MSF includono tracce di attività sovrapposte, sincronizzazione dei checkpoint e un approccio incrementale alla fornitura di valore per il cliente.

Tracce

Il modello di controllo MSF facilita il controllo dei progetti e l'attivazione dei processi usando tracce di attività sovrapposte. Da un lato le tracce sono raggruppamenti sovrapposti e coordinati di determinate attività volte alla produzione di risultati finali rilevanti per ogni traccia. Le tracce MSF, tuttavia, non si limitano a queste funzionalità; ciascuna di esse presenta una missione distinta e rappresenta un cambiamento nella tempistica e nell'obiettivo di un progetto. Ciascuna traccia usa le revisioni e punti di sincronizzazione definiti checkpoint (che verranno esaminati successivamente) per stabilire più facilmente se si stanno raggiungendo gli obiettivi della traccia. Inoltre, i checkpoint principali vengono usati per completare ogni traccia, consentendo un passaggio delle responsabilità per la direzione di numerose responsabilità e invitando il team ad adottare una nuova prospettiva più adeguata agli obiettivi della traccia successiva.

Il modello di controllo MSF è costituito da cinque tracce di attivazione sovrapposte e da una traccia di controllo permanente che si estende lungo le tracce di attivazione.

Diagramma della traccia di controllo

Diagramma con le sei tracce del modello

Traccia di controllo

La traccia di controllo è incentrata sul bilanciamento tra l'uso efficiente ed efficace delle risorse di progetto e la fornitura di una soluzione nel rispetto di un insieme di vincoli di progetto potenzialmente dinamici. Inoltre, la traccia di controllo supporta il miglioramento continuo dei processi.

Un buon controllo di progetto fornisce un livello di supervisione, processi, informazioni aggiuntive e rigore tale da consentire l'uso efficiente ed efficace delle risorse di progetto, fornire una soluzione e gestire le decisioni di compromesso bilanciando al contempo la conformità a un insieme di vincoli di progetto che potrebbero subire cambiamenti. La traccia di controllo MSF mira a fornire, e a migliorare continuamente, un buon controllo del progetto. È costituito da attività specifiche e persistenti eseguite nel corso dell'intero progetto.

Gli obiettivi della traccia di controllo sono i seguenti:

  • Guidare le attività di attivazione per fornire una soluzione con risultati ripetibili e affidabili

  • Ottimizzare e migliorare continuamente le prestazioni del team e la velocità effettiva, la qualità della soluzione e il miglioramento dei processi

  • Ottenere l'approvazione da:

    • Utenti che garantiscono che una soluzione soddisfa le proprie esigenze ed è sufficientemente usabile

    • Operazioni che garantiscono che una soluzione è pronta per l'implementazione

    • Cliente che garantisce che un progetto è completo

Tracce di attivazione

L'attivazione dei processi è la sequenza dettagliata dei passaggi con i quali una soluzione viene definita, compilata e implementata. Essenzialmente, le tracce di attivazione aiutano un team a raggiungere un accordo di livello elevato su quanto previsto e creano opzioni di approccio per la fornitura in base a tale visione (traccia di previsione), valutano tali opzioni e pianificano l'opzione selezionata (traccia di pianificazione), compilano la soluzione (traccia di compilazione), verificano che la soluzione fornita sia conforme alle previsioni (traccia di stabilizzazione) e, infine, implementano tale soluzione (traccia di implementazione).

Gli obiettivi di ogni traccia di attivazione sono i seguenti:

Previsione

  • Sviluppare una comprensione chiara di ciò che necessario nel contesto dei vincoli di progetto.

  • Predisporre il team necessario per prevedere le soluzioni con opzioni e approcci che rispondono al meglio a tali esigenze e al contempo soddisfano in modo ottimale i vincoli.

Piano

  • Sviluppare la soluzione concettuale nelle progettazioni e nei piani concreti in modo che possa essere integrata in una traccia di compilazione.

Compila

  • Compilare i vari aspetti di una soluzione in base ai risultati finali della traccia di pianificazione, come le progettazioni, i piani, le pianificazioni e i requisiti.

Stabilizzazione

  • Migliorare la qualità della soluzione per rispondere ai criteri della versione per l'implementazione in produzione.

  • Convalidare la conformità della soluzione alle esigenze e aspettative delle parti interessate.

  • Convalidare l'usabilità della soluzione dalla prospettiva dell'utente.

  • Massimizzare il successo e ridurre al minimo i rischi associati all'implementazione della soluzione e alle operazioni negli ambienti di destinazione della soluzione.

Distribuzione

  • Integrare correttamente una soluzione in produzione all'interno degli ambienti definiti.

  • Trasferire la responsabilità per la parte restante della fornitura della soluzione da un team di progetto ai team di produzione e di assistenza nel modo più agevole e rapido possibile.

Checkpoint

I checkpoint, che rappresentano un tema centrale in MSF, consentono di pianificare e monitorare lo stato di avanzamento del progetto e richiamare il completamento dei risultati finali e delle attività. I checkpoint vengono usati per fornire a un team e ai clienti opportunità esplicite di riconfermare l'ambito del progetto o di modificare l'ambito del progetto in modo da riflettere cambiamenti del cliente o dei requisiti aziendali oppure per risolvere i rischi e i problemi che potrebbero emergere nel corso di un progetto. I checkpoint vengono usati per diversi motivi, ad esempio:

  • Contribuire a sincronizzare gli elementi di lavoro.

  • Fornire visibilità esterna dello stato di avanzamento e della qualità.

  • Rendere possibili le correzioni in corso d'opera.

  • Concentrare le revisioni su obiettivi e risultati finali.

  • Fornire punti di approvazione del lavoro prima di procedere alle fasi successive.

MSF distingue tra due tipi di checkpoint: checkpoint principali e checkpoint provvisori. I checkpoint principali indicano il completamento delle attività e dei risultati finali principali, inclusa la fine delle attività pianificate per una data traccia. I checkpoint provvisori sono definiti dal team per indicare lo stato di avanzamento all'interno di una traccia e per segmentare attività di grandi dimensioni in parti più facilmente gestibili.

Approccio iterativo

Una soluzione non fornisce valore aziendale fino a quando non viene implementata in produzione e usata in modo efficace. Per questo motivo, il ciclo di vita del modello di controllo MSF include attività incrementali di sviluppo e implementazione di una soluzione in produzione, garantendo quindi la realizzazione del valore aziendale nonché della visione strategica e degli obiettivi complessivi del team. MSF assicura che i progetti soddisfino la promessa in termini di tecnologia combinando una forte rappresentanza aziendale multidimensionale in un team con un'esplicita attenzione verso l'impatto sull'azienda nel corso dell'intero processo.

La prassi di sviluppo iterativo è un tema ricorrente in MSF. I documenti, le progettazioni, i piani e altri risultati finali vengono sviluppati in modo iterativo. Come si può immaginare, il modello di controllo MSF è un approccio iterativo.

Microsoft Solutions Framework può essere uno strumento efficace per le organizzazioni che vogliono sviluppare rapidamente soluzioni tecnologiche di qualità elevata e valide per l'azienda. Grazie alla sua flessibilità può essere adattato facilmente alla maggior parte dei progetti di tecnologia, aiutando i team a comunicare in modo efficace e a coordinare le attività cruciali.

Bibliografia

Si noti che le parti del contenuto provengono dai Microsoft Solutions Framework Essentials (ISBN 9780735623538). Microsoft Press. Tutti i diritti sono riservati.

Vedere anche

Concetti

Verificare il lavoro con Visual Studio ALM e TFS

Utilizzare elementi del progetto team, scegliere un modello di processo