Gestione di progetti

È possibile utilizzare la sezione Project Management delle linee guida di MSF for CMMI Process Improvement per ottenere tutte le informazioni su come gestire, pianificare e coordinare lo sviluppo e la manutenzione di prodotti software. Per ulteriori informazioni su CMMI, vedere Informazioni generali su CMMI.

Il gruppo di aree di processo Project Management in CMMI include Project Planning, Project Monitoring and Control, Supplier Agreement Management, Integrated Project Management, Risk Management e Quantitative Project Management. Tutte le aree ad eccezione di Quantitative Project Management fanno parte dei livelli di modello 2 e 3. Quantitative Project Management è un'attività di livello di modello 4 che indica il modo in cui organizzazioni di maturità elevata utilizzano dati quantitativi, obiettivi e statisticamente sicuri per adottare decisioni di gestione e produrre risultati positivi e prevedibili per i progetti.

Le attività di gestione del progetto rappresentano costi economici nelle attività di compilazione con valore aggiunto. Queste attività sono necessarie e importanti per gestire i rischi, coordinare in modo corretto le attività di compilazione e definire in modo appropriato le aspettative del cliente. È tuttavia necessario ridurre gli sforzi spesi in tali attività. " Poco e spesso" è un concetto che è consigliabile adottare a questo scopo. Batch minori riducono i costi correlati a complessità e coordinamento. Quando si definisce e personalizza la definizione del processo, è necessario ricordare che le attività di gestione del progetto devono essere minime, ma soddisfare il profilo di rischio del progetto.

Sviluppo iterativo

Team Foundation utilizzato con il modello di processo MSF for CMMI supporta lo sviluppo iterativo. Lo sviluppo iterativo consente di gestire i rischi fornendo software dimostrabile e testato a intervalli regolari durante tutto il progetto.

La pianificazione del progetto è organizzata in una serie di iterazioni che durano in genere da quattro a sei settimane. Ogni iterazione termina con una dimostrazione di software utilizzabile e testato. Per ulteriori informazioni, vedere Creare e modificare i percorsi di area o di iterazione.

• Nel piano del progetto vengono dichiarati i requisiti relativi alla funzionalità che verranno sviluppati in ogni iterazione. Il piano del progetto viene sviluppato nell'iterazione 0 e rivisto all'inizio di ogni iterazione. È possibile visualizzare il piano del progetto in diversi modi, ad esempio tramite il dashboard del progetto. Per ulteriori informazioni, vedere Requisito (CMMI) e Dashboard del progetto (CMMI).

• In ogni piano di iterazione vengono dichiarate le attività che verranno eseguite durante l'iterazione. La maggior parte delle attività sono attività di sviluppo e test necessarie per completare i requisiti relativi alla funzionalità pianificati per l'iterazione. È possibile visualizzare il piano di iterazione tramite il dashboard di stato. Per ulteriori informazioni, vedere Attività (CMMI) e Dashboard di stato (CMMI).

Lo sviluppo iterativo non gestisce automaticamente i rischi. Per ridurre i rischi, è necessario organizzare il piano del progetto in incrementi. Le iterazioni iniziali devono fornire un'"esigua porzione end-to-end", ovvero una versione minima dei comportamenti più importanti del prodotto. Le iterazioni successive aggiungono altre funzionalità.

Al contrario, sarebbe molto meno utile pianificare tutta la parte di vendita di un sito Web di acquisti online per il primo terzo del progetto, tutto il sistema del magazzino nel secondo terzo e tutto il sistema dei pagamenti nell'ultimo terzo. Una pianificazione di questo tipo rischierebbe di produrre un sito Web dall'aspetto accattivante e ricco di funzionalità, ma privo di qualsiasi mezzo che consenta all'azienda di ricevere il denaro dovuto. Si tratterebbe infatti di uno sviluppo iterativo, ma non incrementale.

Lo sviluppo incrementale comporta i vantaggi seguenti:

• Consente di soddisfare gli effettivi requisiti. Le parti interessate hanno l'opportunità di provare il prodotto, un approccio che produce nuovi miglioramenti per i requisiti dichiarati.

• Consente di ottimizzare l'architettura. Consente al team di sviluppo di individuare e risolvere qualsiasi difficoltà relativa alla piattaforma o i possibili miglioramenti alla progettazione.

• Garantisce risultati. Le parti interessate sanno che, anche nel caso di tagli alle risorse del progetto, quanto compiuto fino a quel momento non andrà sprecato. Ciò vale anche nel caso in cui le stime di sviluppo si rivelino ottimistiche e sia necessario rinunciare alle funzionalità meno importanti.

Per ulteriori informazioni su come esprimere i requisiti in una forma appropriata per lo sviluppo incrementale, vedere Sviluppo di requisiti.

Cicli maggiori e minori

Il progetto e l'iterazione non costituiscono gli unici aspetti ciclici dello sviluppo software. In un'iterazione, ad esempio, i membri del team avviano e completano attività e archiviano il codice. Il sistema di compilazione compila il prodotto con frequenza continua o notturna. Il team conduce una breve revisione giornaliera dello stato delle attività dell'iterazione.

Progetti di grandi dimensioni

Un progetto in cui un team procede attraverso una serie di iterazioni può far parte di un progetto o di un programma di dimensioni maggiori. Un progetto di grandi dimensioni prevede il lavoro in parallelo di diversi team. Ogni team include in genere da 4 a 16 persone.

Aprire un ramo del controllo della versione separato per ogni team. Ogni team deve essere integrato nel ramo principale alla fine di ogni iterazione. Per ulteriori informazioni, vedere Creazione di un ramo e unione.

Riservare il ramo principale a integrazione e test. Il computer di compilazione deve eseguire un set completo di test dopo un'integrazione.

Assegnare un'area a ogni team in modo che gli elementi di lavoro possano essere separati facilmente dagli altri. Per ulteriori informazioni, vedere Creare e modificare i percorsi di area o di iterazione.

Benché non sia sempre necessario, i team possono condividere una serie di integrazioni. Se i team non sincronizzano le integrazioni, ogni team dovrà disporre di un prefisso proprio per i nomi delle iterazioni.

In questa sezione

Vedere anche

Concetti

MSF for CMMI Process Improvement v5.0