Microsoft Solutions
Framework
Ing. Lorenzo Barbieri
MCT, MCSD.NET, MCDBA
2
Me.About()



Sono un Senior Trainer/Consultant in ObjectWay SpA, specializzato
in architetture Microsoft .NET, Windows, SQL Server.
Ho scritto articoli per ioProgrammo, Dev, Network News.
Ho scritto le guide su www.cramsession.com per i seguenti esami di
certificazione Microsoft:
 Visual Basic .NET, Visual C#, Visual C++, BizTalk Server, Commerce
Server, e altri


Sono specializzato sul Microsoft Solutions Framework, su cui ho
scritto alcuni articoli e mantengo una lista di tutte le risorse
disponibili.
Per contattarmi o per maggiori informazioni potete visitare il mio
BLOG:
www.geniodelmale.info
3
Agenda della giornata

Introduzione

Composizione di un team Microsoft Solutions Framework

Processo di sviluppo





4
Fasi, Iterazioni, e Milestone
Zero difetti
Daily Build (uso e strumenti)
Gestione dei rilasci
Deployment

Gestione del progetto

Gestione dei rischi

Gestione delle competenze

Integrare MSF con altre metodologie

Conclusioni su MSF 3.0

MSF 4.0 e Visual Studio Team System
Introduzione a MSF 3.0
Stato di salute dei progetti IT
2000
1998
Failed
Challenged
Succeeded
23%
49%
28%
28%
1995
1994
46%
40%
31%
26%
33%
53%
27%
16%
This chart depicts the outcome of the 30,000 application projects in large, medium,
and small cross-industry U.S. companies tested by The Standish Group since 1994.
Source: The Standish Group International, Extreme Chaos, The Standish Group
International, Inc., 2000
6
Obiettivi per il successo di un progetto
Sintomi di un progetto
problematico
7
Obiettivi per avere
successo
Chi se ne
occupa
“Il progetto è in ritardo e fuori
budget”
Consegnare entro i limiti
del progetto
?
“Quello che è stato realizzato non
è quello che volevamo...”
Implementare quello che
c’è nelle specifiche
?
“Funziona male - Continuiamo a
scoprire nuovi problemi...”
Identificare e risolvere i
problemi aperti
?
“Non si integra nel nostro
ambiente”
Il Deploy deve avvenire senza
problemi
?
“E' troppo difficile da usare”
Più usabilità e efficacia
?
“Non soddisfa le nostre
aspettative”
Soddisfare i
customer
?
“Non abbiamo ricevuto le
informazioni richieste...”
Stabilire buone comunicazioni
all’interno del team
?
Quali sono gli ostacoli principali?

Separazioni di obiettivi e ruoli

Separazione del business dalla tecnologia

Mancanza di un linguaggio comune e di un processo
 Obiettivi poco chiari
 Gestione dei cambiamenti caotica
8

Incapacità di comunicare e di agire come un team

Si sta adottando un processo poco flessibile
Le origini di MSF



Nel 1994 usciva MSF, una raccolta di best practice, principi e
modelli.
MSF si è evoluto nel tempo e la versione attuale, la “3.0” è del 2003.
MSF fornisce una guida su come organizzare le persone e i progetti
nel pianificare, realizzare e distribuire soluzioni IT di SUCCESSO!!!
Microsoft
Worldwide
Products
Groups
Microsoft
Consulting
Services
Proven
Practices
Microsoft
Microsoft
Information
Partners
Technology
Group
 La versione 4.0 uscirà assieme a Visual Studio Team System nel
2005, in due versioni: “Formal” e “Agile”
9
MSF: Modelli e discipline
Modelli
Process
Team
Model
Model
Discipline
Project
Management
Discipline
10
Risk
Management
Discipline
Readiness
Management
Discipline
Concetti fondamentali

Foundational Principles
 Sono i principi fondamentali su cui si basa il framework

Key Concepts
 Idee che supportano i principi e le discipline di MSF

Proven Practices
 Tecniche, metodi e processi che hanno funzionato in progetti VERI!
11
MSF Foundational Principles
12

Clear accountability, shared responsibility

Empower team members

Focus on business value

Shared project vision

Stay agile, expect change

Foster open communications

Learn from all experiences

Invest in quality
Qual'è il ruolo di MSF nel ciclo di vita del
software?
Microsoft Solutions Framework
Microsoft Operations Framework
13
Composizione di un team
MSF
MSF Team Model
Realizzare la soluzione
rispettando i vincoli
Program
Management
Soddisfare
il cliente
Product
Management
Implementare la
soluzione
Development
Comunicazione!
User
Experience
Aumentare la
soddisfazione
degli utenti finali
Test
Release
Management
Effettuare il deployment
e mantenere gli ambienti
di sviluppo e test.
15
Approvare la release solo
se i problemi sono stati
identificati e risolti.
Altri partecipanti al progetto – Ruoli esterni




16
Project sponsors – Chi richiede il progetto e ne approva i risultati
Customers (business sponsors) – Chi ottiene “business value” dalla
soluzione
End users – Chi interagisce direttamente con la soluzione
Operations – Chi è responsabile del mantenimento in funzione della
soluzione dopo la consegna
Team di progetto “esteso”
Business Focus
Users
Help
Desk
Product
Management
User
Experience
Customer
Test
Project Team
Operations
and
Support
Groups
Development
Release
Management
Technology Focus
17
Program
Management
Project
Sponsor
Technology Architects and
Steering Committees
Gestire team grandi o piccoli

Per gestire team grandi si possono utilizzare due soluzioni:
 Feature Teams
 Function Teams


In caso di team piccoli si possono assegnare più ruoli ad una stessa
persona, evitando “conflitti d’interesse”.
Per maggiori approfondimenti si veda:
http://www.geniodelmale.info/articles/MSF_TeamGrandiEPiccoli.aspx
18
Gestione del progetto
Project Management




“Il Project Management rappresenta l’applicazione di conoscenze,
capacità, strumenti e techinche alle attività di progetto, per
realizzarne i requisiti” (PMI – Project Management Institute)
Non significa “SONO IL CAPO E COMANDO IO!”
E’ una componente critica specialmente in progetti di medie e grandi
dimensioni.
Project Management in MSF:
 MSF non è una metodologia per il project management, ma è un
framework che comprende anche elementi di project management,
allineati al PMIBOK
 Il PMIBOK è il Project Management Institute Body of Knowledge

20
Se si sono adottate altre discipline per la gestione del progetto,
queste possono essere tranquillamente essere usate assieme ad
MSF
Chi gestisce effettivamente il progetto





21
In progetti piccoli (1 persona per ruolo o meno) il Program Manager
si occupa della gestione del progetto
Se alcuni o tutti i team sono “Function Team”, i Team Leader
partecipano alla gestione del progetto assieme al Program Manager
Il ruolo del Program Manager è in ogni caso critico per la gestione
del progetto.
Se il progetto lo richiede, il ruolo di Program Management può
essere scisso nelle due componenti, Project Manager e Solution
Architect, attraverso l’uso di un”Function Team”
Nei progetti più piccoli, queste due attività possono tranquillamente
coincidere.
Processo di sviluppo
Fasi, Iterazioni, e Milestone
Zero difetti
Daily Build (uso e strumenti)
Gestione dei rilasci
Deployment
MSF Process Model – Fasi e Milestone
Deployment
Complete
Release Readiness
Approved
Vision/Scope
Approved
MSF
Scope
Complete
23
Project Plans
Approved
Distribuzione dei compiti

Tutti i ruoli sono rappresentati in tutte le fasi

Ogni ruolo deve “produrre qualcosa” in ogni fase

Non tutti i ruoli sono ugualmente attivi in ogni fase

Ogni fase è guidata particolarmente da “un ruolo”





24
Envisioning -> Product Management
Planning -> Program Management
Developing -> Development, User Experience
Stabilizing -> Testing, Release Management
Deploying -> Release Management
Milestone




Ogni fase è divisa in più Milestone, specifiche per la singola fase.
Le Milestone servono per vedere e far vedere all’esterno
l’andamento del progetto
Le Milestone devono sempre produrre dei “deliverables” che vanno
“approvati”
I benefici dati dalle Milestone sono:





Maggiore sincronizzazione tra le varie parti del Team
Visibilità esterna dello stato del progetto e della qualità del prodotto
Permettono di adottare dei “cambiamenti in corsa”
Permettono di revisionare obiettivi e risultati
Ci sono due tipi di Milestone in MSF:
 Major Milestone – marcano la fine di una fase
 Interim Milestone – permettono di dividere il lavoro di una fase in parti
più gestibili
25
Envisioning

Milestone
 Core Team Organized
 Vision/Scope Baselined
 Vision/Scope Approved

Deliverabiles
 Vision/scope document
 Project structure document
 Initial risk assessment document

La fase di Envisioning serve anche per dare un’identità al progetto

Per approfondire il la gestione dei trade-off:
 http://www.geniodelmale.info/articles/MSF_TradeOff.aspx
? !
26
Envisioning
Features
Planning

Milestone







Technology validation complete
Functional specification baselined
Master project plan baselined
Master project schedule baselined
Developments/test environment setup
Project Plans Approved
Deliverables
 Functional specifications
 Master project plan
 Master project schedule
27
Developing

Milestone
 Proof of concept complete
 Internal Release 1..n
 Scope complete

Deliverables





28
Solution code
Buil images
Training materials
Documentation
Updated master plan, schedule and risk document
Zero Difetti!



E’ una mentalità!
Bisogna ottenere il livello di qualità più elevato, in funzione dei limiti
imposti dal progetto
I membri del team devono capire il livello di qualità richiesto al
proprio lavoro

Il lavoro non è finito se non raggiunge il livello di qualità richiesto

Per ottenerla ci sono vari aiuti:
 Daily Build
 Focalizzarsi sui rilasci
 Gestire i Bug
29
Daily Build


Ogni giorno il progetto deve poter essere “compilabile” e
“installabile”
Una Daily Build “pubblica” è:
 Un indicatore che il team funziona (produce qualcosa)…
 Un modo per rendere visibili gli avanzamenti del progetto
 Il “battito cardiaco” del processo di sviluppo


Se il progetto non compila o non è installabile a causa di una
modifica, è meglio scoprirlo il giorno dopo, invece che un mese dopo…
Se la Daily Build fallisce, il responsabile dell’anomalia deve
interrompere quello che sta facendo e correggere il problema
 E’ inutile avere una feature nuova se il progetto non funziona…
30
Internal Release


Avere un processo di Daily Build facilita la realizzazione
delle Internal Release (o Alpha Release)
In questo modo ci sono dei momenti in cui il lavoro del Team è
focalizzato a rendere “facilmente” installabile e utilizzabile il
prodotto

Non ci si riduce a fare il setup alla fine del progetto!!!
Internal
Release
Feature
n
Development
Daily Builds
31
Testing and
Stabilizing
Internal
Buffer Release
n+1
Time
Ma si può veramente farlo ogni giorno?


32
In un tipico progetto di 4/6 mesi, non si può fare la Daily build per i
primi 3/5 giorni… al massimo.
Poi SI PUO’!
Suggerimenti per semplificare la Daily Build





Usate sistemi per la gestione del codice (SourceSafe, ClearCase,
CVS, etc…)
Ogni sviluppatore lavora in locale
Ogni giorno il codice viene preso, compilato e reso disponibile, e
possibilmente testato per vedere che funziona (se possibile)
Ogni giorno gli sviluppatori dovrebbero lavorare sull’ultima base di
codice che compilava.
Bisogna automatizzare il tutto:
 Batch files
 Sistemi di build automatici (Ant, NAnt, Build It!, MS Build)
 Sistemi di integrazione continua (il progetto viene ricompilato ad ogni
check-in da parte degli sviluppatori
33
Stabilizing

Milestone






Deliverables




34
Bug convergence
Zero bug bounce
Release candidates
Pilot compete
Release Readiness Approved
Pilot review
Release ready version of everything
Testing and bug reports
Project documents
Gestione dei rilasci
Beta
Bug Convergence
Zero-Bug Release
Release Candidate
Active
Bugs
0
35
Golden Release
Time
Release
Readiness
Approved
Ricapitolando...
Release
Golden Release/RTM
Release Candidates
Release
Readiness
Zero-Bug Bounce
Test Specification
Complete/Alpha
Scope
Complete
Internal Release n (Alpha, Pilot)
Product Stability
Betas
Internal Release ...
Internal Release 2
Project Plan
Approved
Internal Release 1
Test Plan
36
Gestione dei Bug




37
Bisogna valutare i Bug e dargli una priorità, per poterli gestire in
maniera appropriata
Generalmente si adotta un gruppo di review per dare la priorità ed
eventualmente assegnare i Bug a chi li deve risolvere
Bisogna sempre bilanciare la stabilità del prodotto rispetto alle
richieste del cliente
La funzionalità incriminata potrebbe essere eliminata in questa
versione se non si riesce a stabilizzarla.
Deploying

Milestone





Core technology deployed
Site deployments compete
Deployment stabilized
Deployment complete
Deliverables
 Operations and support information system
 Repository of every document, code, configuration, etc...
 Project closeout report
38
Deployment



Un prodotto non è finito fino a quando non è stato consegnato e gli
utenti messi in grado di lavorare.
MSF è focalizzato alla CONSEGNA del prodotto, quindi la fase di
Deployment non è marginale, ma è una delle fasi principali.
La fase di Deployment viene conclusa quando:
 Il customer inizia a ricevere “valore” dal progetto
 Bisogna fare in modo che il customer “firmi” la fine del progetto e la
presa in carico del prodotto
 Lo scopo è stato raggiunto!
 BISOGNA FESTEGGIARE!!!
39
MSF Process Model - Iterazioni
Versione 3
Versione 2
Versione 1
40
Adattare il Process Model


Il Process Model non va preso così com’è, ma va adattato al
progetto, al team e agli elementi esterni
Ogni team deve decidere quali Interim Milestone sono necessarie
usando alcune linee guida:




41
Decidere in base al tipo di progetto
Considerare anche gli eventi e i rischi esterni
Evitare lunghi periodi senza Milestone
Le Milestone devono “sempre” produrre dei Deliverables
Gestione dei rischi
Gestione dei rischi

Rischio
 Possibilità di perdita o danno
 Non è qualcosa che c’è già (“problema conosciuto”) ma qualcosa che
potrebbe avvenire in futuro e “danneggiare” il progetto

Gestione dei rischi
 Processo di identificazione, analisi e gestione dei rischi che possono
impattare più o meno gravemente sul progetto
43
MSF Risk Management Discipline
Identify
Risk
Statement
Analyze and
Prioritize
Control
Risk
Knowledge Base,
Concepts,
and Processes
44
Learn
Risk
Assessment
Document
Top n
Risks
Track and
Report
Plan and
Schedule
MSF Risk Management Discipline
1.
Identificare i rischi, scrivendone la descrizione e il possibile
impatto sul progetto
2.
Analizzare l’impatto dei rischi, calcolandone la probabilità, e il
possibile danno (in termini numerici).
 A quel punto si può calcolare l’esposizione al rischio, data dalla
probabilità moltiplicata per il danno.
 In base al rischio e all’esposizione calcolata si può assegnare la priorità.
45
3.
Pianificare gli interventi da eseguire per mitigare i rischi, e
schedularli in base alla priorità
4.
Tracciare l’andamento dei rischi, e mantenerne sempre aggiornata
la documentazione, compreso il top risk document
5.
Applicare gli interventi e controllarne i risultati, aggiornando i
documenti
6.
Documentare i rischi, i piani di intervento e i risultati ad uso di
future iterazioni o futuri progetti
MSF Risk Management Discipline

La gestione dei rischi deve essere:
 Completa – deve includere tutti gli aspetti del progetto (persone,
processi, tecnologie)
 Sistematica – il processo a sei passi comprende tutte le fasi di gestione
 Continua – bisogna applicarla durante tutta la durata del progetto
 Proattiva – bisogna agire in anticipo per minimizzare gli impatti
 Flessibile – bisogna individuare e gestire opportunamente vari tipi di
rischi
 Orientata al futuro – lo scopo è anche quello di imparare dai progetti
passati per migliorarsi nei progetti futuri
46
Gestione delle competenze
MSF Readiness Management Discipline

Utilizzate un approccio proattivo, non reattivo

Trattate la mancanza di competenze come rischi


La prontezza e competenza del team deve essere valutata per tutta
la vita del progetto
Identificate e gestite le conoscenze del team come conoscenze
dell’organizzazione
Define
Assess
Evaluate
Change
Knowledge
Skills
Abilities
48
Conclusioni su MSF 3.0
Ma MSF funziona davvero?

SI!
 A patto di adattare MSF alle proprie esigenze e non adottarlo
ciecamente.

Progetti di alto livello che hanno adottato MSF:




50
www.nasdaq.com
www.marriot.com
Visual Studio
Windows XP, 2003, …Longhorn
Implementare MSF in sette passi




Scegliete un gruppo e un progetto pilota (6-10 persone, 4-6 mesi, il
progetto deve essere nuovo)
Formate il team su MSF (ad es. Corso MOC1846)
Opzionalmente – prendete un consulente che periodicamente
fornisce lo “stato di salute” del progetto (meglio se MSF
Practitioner)

Portate a termine il progetto con successo! :-)

Rivedete e customizzate MSF secondo le vostre esigenze

51
Selezionate i responsabili senior e presentate MSF attraverso
un”executive summary” (ad esempio, parti di questa presentazione e
Q&A)
Opzionalmente – pianificate e ristrutturate l’organizzazione se il
successo del progetto vale lo “sforzo” di usare ancora MSF
E se i team sono misti (interni e del cliente)?

Insegnate MSF al team del cliente PRIMA di far partire il progetto,
in un corso a porte chiuse
 Si fideranno di più
 Le probabilità di successo aumentano se il team del cliente “capisce”
come lavorate

Fate in modo di mantenere il controllo del progetto in ogni ruolo, non
dividete le responsabilità in modo completo, ad esempio Program
Manager interno e Product Manager del cliente
 Conflitto di interessi!!!
52
MSF 4.0 e Visual Studio
Team System
MSF si evolve: “Formal” e “Agile”

Al TechEd 2004 a San Diego è stata annunciata la nuova release di
MSF, la 4.0, che vedrà la luce in due versioni distinte:
 MSF “Formal” – è l’evoluzione di MSF 3.0, per le realtà che necessitano
un processo più formale e strutturato
 MSF “Agile” – è una nuova incarnazione di MSF, che cerca di avvicinarsi
alle metodologie Agili

Di MSF “Formal” si sa poco, mentre MSF “Agile” è disponibile in
beta sul workspace GotDotNET:
http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=b6973c97-2af8-4681a585-9ec387ee0688
54
MSF “Agile”


55
Sono state rilasciate due release, la
prima (dalla quale è stata presa
l’immagine del ciclo di vita) e la
seconda, che è stata ritirata dal
sito per essere revisionata dopo
aver ricevuto una marea di critiche
da parte dei sostenitori delle
metodologie agili, che sostengono
che MSF “Agile” non è poi così agile
come Microsoft vuole far credere.
Conviene quindi aspettare la
prossima release “revisionata”,
prima di avventurarsi nello studio di
MSF “Agile”...
Visual Studio Team System




56
Lo vedrete nella presentazione di Francesco Albano alle 17.00
Per quanto riguarda MSF, Visual Studio Team System lo supporterà
direttamente in entrambe le versioni, attraverso template,
strumenti e workflow customizzati.
Visual Studio Team System però non sarà esclusivamente legato a
MSF, in quanto il processo sottostante al tool è completamente
customizzabile.
Visual Studio Team System è stato realizzato anche con la
collaborazione di BrightWork, che già ha realizzato l’unico tool che
supporta MSF 3.0: http://www.brightwork.com/solutions/
Domande?
Preparatele che ormai ho finito ;-)
Risorse

Ho raccolto una lista di risorse su MSF:
 MSF 3.0 Resources list:
• http://www.lorenzobarbieri.info/articles/MSF_Resources.aspx
 MSF 4.0 Resources list:
• http://www.lorenzobarbieri.info/articles/MSF4_Resources.aspx

In particolare volevo segnalare un post di un blog che ha scatenato
un putiferio dopo essere stato linkato da SlashDot ma che contiene
un sacco di informazioni utili:
 21 Rules of Thumb – Come Microsoft sviluppa i suoi software:
• http://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx
58