IT Project Management

Transcript

1 IT Project Management Lezione 3 Scope Management Federica Spiga federica_spiga@yahoo.it A.A

2 Identificare gli obiettivi di progetto pecific isurable cheivable ealistic Se gli obiettivi di progetto non rispettano queste caratteristiche difficilmente il progetto avrà successo: Se non sono specifici, non è possibile individuare uno scope preciso Se non sono misurabili, non è possibile stabilire se il lavoro è stato completato o no Se non sono realistici e raggiungibili, non è possibile fare un piano adeguato Se non ci sono dei limiti temporali, è impossibile portare a termine il lavoro Ime based 3

3 Scope del progetto REQUISITI TECNICI (requisiti funzionali, requisiti di performance, requisiti di affidabilità ecc ) DELIVERABLES ( prodotti output del progetto, es documentazione, report di test, release del prodotto, ecc) VINCOLI TEMPORALI VINCOLI DI RISORSE (sia per richieste del cliente, sia per mancanza di risorse da parte del fornitore, ecc) Definisce l ambito non solo tecnico del progetto. 4

4 Gestione dello Scope La comunicazione (interna e con il cliente) è fondamentale. Il Project Management è al 90% comunicazione Completare TUTTEle attività previste dal progetto e SOLOle attività previste dal progetto Fare enorme attenzione ai cambiamenti dei requisiti per gli impatti che hanno sul progetto Ogni cambiamento richiesto deve essere valutato e gestito 5

5 Gestione dello Scope 6

6 Gestione dello Scope Dividere il progetto in una serie di attività e task in modo da renderlo più gestibile. Si evita di dimenticare attività importanti Permette di associare agevolmente attività alle risorse 7

7 Work Breakdown Structure ork reackdown Strumentodisupportoalla scomposizione analitica di un progetto in tutte le sue parti. Facilita l attribuzione di responsabilità a persone e di budget a sottoprogetti, la tempificazione del progetto, la valutazione delle performance di progetto. tructure E la base per la stima dell effort e dei costi di progetto Per costruire una WBS occorre un criterio, un metodo di classificazione che deve valutare e dare risposta ai seguenti aspetti: Quale struttura? Quali criteri di scomposizione delle attività? Come descrivere i blocchi di attività scomposte? Quale livello di dettaglio? Quali modalità di aggregazione? 8

8 WBS Struttura: Struttura gerarchico piramidale Logica top-down: dal generale al particolare Le attività o gli obiettivi previsti ad un livello, dipendono da quelli situati al livello sottostante Deve contenere tutte le voci consegnabili (deliverables -prodotti del progetto, e milestones punti di controllo), e tutte le attività principali ad esse necessarie. Regola del 100% Non ci devono essere sovrapposizioni tra due o più elementi della WBS NON è una pianificazione del progetto e non è una lista in ordine cronologico 9

9 WBS: Regola del 100% IL PMI precisa che la WBS debba includere il 100% del lavoro definito dal progetto e includere TUTTO il necessario-interno, esterno e appaltato -alla realizzazione del progetto, inclusa la gestione del progetto stesso. La regola del 100% è una delle più importanti linee guida per lo sviluppo, la decomposizione e la valutazione della WBS. La regola si applica a tutti i livelli della gerarchia: la somma del lavoro dei livelli "figli" deve essere uguale al 100% del lavoro rappresentato dal loro "padre" e la WBS non dovrebbe includere alcun lavoro al di fuori dai limiti del progetto, ovvero non può includere più del 100% del lavoro. È importante ricordare che la regola del 100% si applica anche al livello di attività, Il lavoro rappresentato dalle attività in ciascun pacchetto di lavoro devono dare, sommate, il 100% del lavoro necessario per completare il pacchetto." (p. 8) 10

10 WBS 11

11 WBS Qual è il giusto modo di procedere? suddivisione in elementi troppo piccoli porterebbe a entrare in un dettaglio che nessuna fase preliminare potrà mai raggiungere. definizione di attività troppo ampia ci porterebbe a sottostimare il peso di un progetto. Elaborazione progressiva. (Rolling Wave Elaboration) ridefinire le attività mano mano che il lavoro inizia su ogni singolo elemento. Ci si concentra inizialmente sull aspetto generale del progetto e mano a mano dettagliare maggiormente. La WBS quindi non può essere considerata statica, ma dinamica e modificabile con l evoluzione del progetto. 12

12 Logiche di costruzione della WBS La suddivisione del progetto in attività e sottoattività può essere effettuata secondo diversi criteri, dipendenti dalla tipologia del progetto, il dominio del progetto e/o lo standard scelto CRITERIO PER FASI(o per PROCESSO): la scomposizione della attività viene effettuata in base al ciclo di vita del progetto CRITERIO PER DELIVERABLES: Il primo sottolivello è costituito da macroblocchi di attività legati alla produzione dei deliverable del progetto. Usato in progetti con un alta standardizzazione (Consigliato dal PMI) CRITERIO PER LOCALIZZAZIONE: la suddivisione gerarchica è connessa allo spazio fisico o paese dove l output del progetto verrà realizzato 13

13 Esempio WBS Criterio per obiettivi Progetto SW 1 Portale Back end Documento requisiti Architettura di Alto livello Documento Requisiti Architettura di alto livello Analisi requisiti Sviluppo Use Cases Definizione della Grafica Definizione Seqeunce Diagram Sviluppo WBS Task di supporto Progetto Esecutivo Piano di progetto Matrice responsabilità 14

14 Esempio WBS Criterio per fasi 1 Configuration Management Definire configuration Intem Quality Management Preparare piano di qualità Analisi Requisiti Sviluppo Use Cases Progetto SW 1 Progettazione Sviluppo Architettura applicativa Interaction Diagram & Class Diagram Task di supporto Sviluppo & Unit Test Integration & System Test Sviluppo caso d uso 1 Sviluppo caso d uso 2 Unit test Sviluppo WBS Project Management Piano di progetto Matrice responsabilità 15

15 Esempio WBS Criterio per fasi 2 Quality Management Preparare piano di qualità Inception Analisi Requisiti Sviluppo Use Case Raffinamento Use case Progetto SW 1 Elaboration Iteration 1 Iteration n Definizione Architettura (SAD) Definizione Modello di progetto Definizione modello dei dati Implementazione casi d uso Test Costruction Iteration 1 Siluppo caso d uso x Test Transiction Iteraction 1 Integration and System test 16

16 Esempio WBS Criterio per localizzazione Progetto 1 Deploy su Roma Installazione Configurazione Deploy su Milano Installazione 17

17 Descrizione delle attività Ciascun elemento della WBS deve essere identificato da una descrizione che deve essere al concisa, chiara e priva di ambiguità. Ogni elemento della WBS deve essere identificato da un codice numerico o alfanumerico che contiene un numero di item pari al numero di livelli presenti nella struttura gerarchica Progetto 1 Deploy su Roma 1 Installazione 1.1 Configurazione 1.2 Deploy su Milano 2 Installazione

18 Work Package La suddivisione per livello procede riducendo ampiezza e complessità fino a quando non perviene a una descrizione adeguata e inequivocabile della voce finale. Quest ultimo livello si definisce pacchetto di lavoro o work package e deve avere le seguenti caratteristiche: DEVE ESSERE DISTINTO DA OGNI ALTRO PACCHETTO DI LAVORO DEVE ESSERE PROGRAMMABILE IN TEMPI DI COSTI E RISORSE DEVE AVERE UN SOLO RESPONSABILE LA SUA DURATA DEVE ESSERE LIMITATA A PERIODI DI TEMPO DEFINITI Nella pratica, un limite effettivo della granularità della WBS può considerarsi raggiunto quando non è più possibile definire risultati di progetto pianificati, e i soli dettagli rimanenti sono azioni; a meno che queste azioni non possano essere ridefinite per conformarsi alla "regola del 100%", la WBS non dovrebbe essere ulteriormente suddivisa. 19

19 Livelli della WBS Generalmente la WBS ha circa 5-6 livelli. Non c è un limite ai livelli possibili, ma una WBS con più di 6 livelli rischia di essere troppo dettagliata. Rischio di micro programmazione Normalmente i primi 2/3 livelli rappresentano il Livello Manageriale Gli altri livelli sono i livelli tecnici dove è descritto un maggiore dettaglio delle attività 20

20 Tecniche di costruzione Top Down: Si parte dal livello più alto, e si scompone nei livelli inferiori. Usabile se Contesto e problema ben conosciuto Tecnologie e processo ben conosciuti Bottom Up: si parte da una serie di attività di dettaglio e si procede per astrazione fino ai livelli superiori Pro: molto dettagliata Contro: procedimento dispersivo, si rischia di perdere il focus Analogia: si parte da un progetto analogo al progetto che si deve analizzare e si procede per analogia Pro: veloce, si possono utilizzare template Contro: si deve aver eseguito almeno un progetto simile Rolling Wave: si suddivide il progetto in attività per successive iterazioni, man mano che aumentano le informazioni Operativamente si procede con una logica sia top down che bottom up. Nella scomposizione in livelli si procede top down, per la definizione di ciò che contiene il pacchetto di lavoro si procede invece bottom up. In quest ultimo caso si compila un elenco dettagliato delle attività che il progetto richiede le attività vengono poi aggregate in un pacchetto di lavoro gestibile da un solo responsabile e collocato nella struttura. 21

21 Matrice responsabilità Dopo aver scomposto il progetto in attività e sotto attività, fino ai workpackage, bisogna assegnare le attività ai singoli profili, stabilire chi è l owner del task e chi è a supporto Livello 1 Livello 2 Livello 3 Project Manager Analista Siluppatore Tester Test Manager Configuration Management Definire configuration x Owner Quality Preparare piano di qualità Analisi Requisiti Sviluppo Use Cases Owner Progettazione Sviluppo Owner Architettura applicativa Owner Interaction Diagram & Class Diagram Owner Sviluppo & Unit Sviluppo caso d uso 1 Owner Sviluppo caso d uso 2 Owner Unit test Owner Integration & x Owner Project Sviluppo WBS Owner x x Piano di progetto Owner x Matrice responsabilità Owner Configuration Manager Quality Manager Owner 22