Raccolta delle metriche
Scopo
|
Raccogliere le informazioni sulla qualità e sull'avanzamento del progetto per lo stato ed i
miglioramenti
|
Questa fase riguarda il seguente lavoro, basato sul piano di misurazione del progetto:
-
Raccolta delle metriche primitive
-
Calcolare, verificare e convalidare le metriche
-
Includere le metriche nel report di valutazione dello stato
Durante una valutazione di iterazione, vengono esaminate le metriche e decise tutte le azioni che potrebbero riguardare
una nuova pianificazione, l'utilizzo di nuovi strumenti, l'addestramento, la riorganizzazione, ecc... includendo la
rivisitazione del piano di misurazione. In modo analogo alla fine di un ciclo, una "revisione post mortem" può
assicurare che alcune delle metriche raccolte siano esaminate per migliorare il processo o per motivi di valutazione.
Per maggiori informazioni sulle metriche, consultare Guida del prodotto di
lavoro: Metriche.
Per le iterazioni che durano settimane o anche mesi, la raccolta e la notifica delle metriche saranno delle attività
continue, con processi periodici indicati nella sezione Prodotto di lavoro: Valutazione dello stato che catturano i risultati
intermedi.
|
Valutazione dei risultati dell'iterazione
Scopo
|
Per confrontare i risultati effettivi e previsti dell'iterazione.
|
Verso la fine di ciascuna iterazione, è richiesto un incontro delle risorse assegnate al team del progetto principale
per valutare l'iterazione, concentrando l'attenzione su quanto segue:
-
L'iterazione è stata conseguita raggiungendo gli obiettivi?
-
Sono stati ridotti o eliminati i rischi?
-
Il rilascio ha soddisfatto gli obiettivi sulla funzionalità e qualità? Gli obiettivi sulle prestazioni e
sulla produttività?
-
Sono richieste modifiche al progetto e ai piani futuri di iterazione?
-
E' stata invalidata una qualsiasi delle conclusioni catturate nella sezione
Prodotto di lavoro: Valutazione dell'organizzazione di sviluppo
da modifiche durante l'iterazione (come conseguenza che richiede modifiche ad altri prodotti di lavoro, come il processo di sviluppo del progetto)?
-
Si sono verificate delle difficoltà con il processo di sviluppo del progetto durante l'iterazione?
-
Quale parte del rilascio corrente sarà confrontata con la linea di base? Rilavorata?
-
Sono stati identificati nuovi rischi?
-
Si sono verificate modifiche esterne (modifiche al mercato, alla comunità di utenti oppure ai requisiti)?
Valutare i risultati dell'iterazione relativi ai criteri di valutazione che sono stati stabiliti per il piano di
iterazione: misurazioni della funzionalità, delle prestazioni, della capacità e qualità. Utilizzare le metriche
risultanti dalle attività di verifica e la procedura Raccolta di metriche come base,
quando disponibile, per quantificare la valutazione; le misurazioni qualitative sono adeguate per la fase iniziale e
probabilmente per le iterazioni anticipate, mentre le elaborazioni successive, la costruzione e transizione devono fare
affidamento sulle specifiche misurazioni di test per valutare la qualità, le prestazioni, la capacità, ecc.. Indicare
altre problematiche non risolte che sono state catturate dalle valutazioni sullo stato eseguite durante l'iterazione e
altre presenti nell'elenco delle problematiche del responsabile di progetto.
Se tutti i rischi sono stati ridotti a livelli accettabili, è stata implementata tutta la funzionalità e sono stati
raggiunti tutti gli obiettivi di qualità, il prodotto è completo. Una buona pianificazione ed esecuzione sono
fondamentali affinché si ottenga questo risultato alla fine della fase di transizione.
|
Considerazioni su modifiche esterne
Scopo
|
Per essere certi che il progetto resti collegato con il "mondo esterno"
|
E' molto facile che il team di progetto sia molto concentrato sulla propria organizzazione interna tale da non essere
attento ai cambiamenti che avvengono nel mondo esterno. Il business potrebbe cambiare, con l'aggiunta, modifica o
rimozione di requisiti chiave. Oppure, che un concorrente si presenti sul mercato con un prodotto simile, causando un
cambiamento ai requisiti di tempificazione del mercato, alle funzioni o al costo finale del prodotto.
Avendo fornito lo stato corrente dell'ambiente esterno, il piano del progetto (inclusi i punti cardine) è ancora
valido? I rischi sono cambiati, forzando una revisione dei piani di iterazione? Si sta realizzando il prodotto giusto e
la visione è ancora valida? Il team del prodotto è in tempo a consegnare quel prodotto? Le modifiche al processo sono
necessarie a causa delle circostanze esterne cambiate?
Utilizzare i risultati di queste argomentazioni per generare le richieste di modifica per la Visione, l'elenco rischi, il
Piano di sviluppo software, il Piano di
iterazione o il Processo di sviluppo del progetto.
|
Controllo dei criteri di valutazione
Scopo
|
Per accertarsi che i criteri di valutazione siano realistici.
|
Talvolta un'iterazione può venire meno alle previsioni poiché gli obiettivi sono stati fissati troppo alti.
L'impostazione di obiettivi alti è importante, ma a volte vi è una linea sottile tra l'aggressivo e il non realistico.
I team di progetto sono motivati dagli obiettivi, che stimolano e sviluppano le loro capacità, ma tendono a diventare
demoralizzanti se gli obiettivi sono troppo lontani dalle possibilità di raggiungimento. Definire gli obiettivi in modo
che il team di progetto si senta stimolato senza essere sopraffatto richiede a volte alcune iterazioni, dal momento che
il team impara a lavorare in gruppo e riconosce i propri limiti.
Controllare i criteri di valutazione per determinare se sono stati realistici. Talvolta il vantaggio dell'iterazione
nel scoprire che un particolare requisito non è così importante come immaginato originariamente assume un elevatissimo
valore. I progetti sono frequentemente schiacciati da requisiti complessi ma di basso valore imposti da utenti
esigentissimi e affascinati dall'ultima tecnologia; una o due iterazioni possono ridurre le loro aspettative e
riportare la loro attenzione sulla funzionalità che fornisce un valore reale.
A volte l'iterazione rivelerà che una particolare funzione è troppo costosa da implementare o che creerà
un'architettura ingestibile. Lo scenario business per questa funzione deve essere ricontrollato per capire se tale
funzione deve restare nell'ambito progettuale oppure essere revisionata al fine di rendere il requisito raggiungibile
in modo economicamente possibile.
|
Creazione delle richieste di modifica
|