Operazione: Definizione dell'organizzazione del progetto e ricerca del personale
Questa attività riporta la necessità di determinare le esigenze del personale di un progetto e come il personale sarà organizzato.
Discipline: Gestione del progetto
Scopo
  • Per definire una struttura organizzativa per il progetto.
  • Sulla base delle stime di impegno, per definire i requisiti di personale, in termini di numero, tipi e livelli di esperienza, per la successiva iterazione (con un elevato grado di confidenza) e per le susseguenti iterazioni, sebbene con un grado di confidenza inferiore, per consentire l'attività di acquisizione del personale, nel caso esista un rischio.
Relazioni
Passi
Definizione dell'organizzazione del progetto
Scopo Per definire la struttura organizzativa del progetto in termini di posizioni, team, responsabilità e gerarchia. 

La scelta della struttura organizzativa del progetto dipende dalle caratteristiche del progetto e dai vincoli esterni, come il criterio organizzativo esistente. Pertanto è difficile essere prescrittivo su strutture di questo tipo, poiché ciò che è valido (o anche realizzabile) dipenderà molto dalla circostanza. Le problematiche che vanno indirizzate sono esaminate nella sezione   Linea guida: Piano di sviluppo software, che inoltre riporta la struttura predefinita di un progetto che può essere adattata alle particolari necessità di un progetto. La struttura predefinita suggerisce anche una mappatura dei ruoli (Rational Unified Process) alle posizioni nell'organizzazione. La struttura e dimensione dell'organizzazione del progetto varierà durante le vari fasi e il piano di sviluppo software, un documento attivo, sarà aggiornato per rispecchiare queste modifiche.

Definizione dei requisiti del personale
Scopo Per definire il numero, tipo (skill, dominio), esperienza e qualità del personale richiesto per il progetto 

In base alle stime dell'impegno per il progetto, alla tempificazione richiesta, alla struttura organizzativa scelta e alla mappatura dei ruoli, il responsabile di progetto determina il profilo del personale (il numero di risorse oltre l'orario normale e l'insieme di skill) necessario per il progetto. La stima dell'impegno lavorativo per un progetto non è ovviamente indipendente dalle dimensioni di un team, dall'esperienza, dagli skill e dalla qualità; in tutta probabilità, il responsabile di progetto avrà fatto delle supposizioni circa la capacità del personale, ecc. durante la realizzazione della stima dell'impegno. Nel modello di valutazione COCOMO (consultare Compito: Pianificazione delle fasi e dell'iterazioni), la capacità e l'esperienza del personale sono i principali vettori dell'impegno. Pertanto, selezionando un impegno totale accettabile (ottimizzando i diversi programmi di impegno COCOMO) e una tempificazione realizzabile determinerà il profilo del personale.

In alcuni casi, il responsabile di progetto potrebbe conoscere in anticipo il numero e gli skill del personale che saranno disponibili.  In questi casi, con gli skill e il numero del personale definiti, solo la pianificazione è variabile, supponendo che l'ambito del progetto resti costante.

Il responsabile di progetto deve prestare attenzione anche ai danni provocati dall'eccessiva rapidità di scalata dei livelli di personale e il potenziale effetto catastrofico sulla produttività per tentare radicali riduzioni di pianificazione, mediante un aumento considerevole del numero di risorse.

Personale nelle fasi di inizio e di elaborazione

Durante la fase iniziale, l'attenzione si concentra sulla definizione e delimitazione dell'obiettivo e sullo sviluppo di uno scenario di business per il progetto Di conseguenza, la dimensione del team è alquanto piccola: un responsabile di progetto, un architetto di software e probabilmente uno o due sviluppatori, soprattutto dove è richiesto un prototipo POC (proof of concept) per chiarificare i requisiti o il supporto di build per il prodotto.

Durante la fase di elaborazione, l'attenzione si concentra principalmente sull'architettura e sul prototipo strutturale. Di conseguenza, le attività di progettazione nella fase iniziale di elaborazione si concentrano sugli aspetti strutturali; poca attenzione viene attribuita ai dettagli delle classi e dei relativi attributi, che sebbene identificati non sono significativi secondo l'architettura. Durante queste iterazioni, la maggior parte dell'impegno proviene dal team di architettura e da un team per la realizzazione dei prototipi assegnato. Quest'ultimo team viene di solito formato da programmatori molto esperti. A questo punto si dispone di un team di progettazione molto piccolo che si concentrerà sulle tecnologie e sui meccanismi generici. Il gruppo di test si dedicherà alla realizzazione dell'ambiente di test e alla verifica dei primi casi d'uso.

La scelta dei membri del team di architettura deve essere effettuata con attenzione: non solo devono possedere degli skill di progettazione e di analisi superiori, ma anche delle qualità di leader. Per poter comunicare l'architettura al team più grande durante la fase di costruzione, una buona prassi è distribuire i membri del team di architettura nel team di costruzione. I membri del team di architettura devono anche avere acquisito un'elevata esperienza nella progettazione del software: implementazione e progettazione del software, ottimizzazione delle prestazioni, gestione del database, gestione della rete e della configurazione sono i principali skill richiesti nel team di architettura.

Personale nella fase di costruzione

La fase di costruzione punta alla conservazione dell'integrità strutturale del sistema mentre viene realizzata una funzionalità crescente all'interno del sistema. Ciò richiede un perfezionamento strutturale (da qui la "creazione di una linea di base" e non il "blocco" dell'architettura seguente alla fase di elaborazione) e un team di architettura che controlla i progettisti e le loro progettazioni.

Il personale del team di architettura tenderà ad integrarsi con i team di sviluppo, assumendo la funzione di responsabili tecnici e coordinando le problematiche interne al gruppo con gli altri responsabili tecnici. Anche il personale dei team di costruzione deve avere funzioni trasversali, sia con esperienze di progettazione che di sviluppo, dal momento che è responsabile per la progettazione e l'implementazione della relativa funzionalità assegnata. Tipicamente, un team di costruzione è responsabile per uno o più sottosistemi con interfacce ben definite; le modifiche a queste interfacce o l'aggiunta di nuovi sottosistemi determinano una modifica strutturale e rendono necessario un attento esame. All'interno del sottosistema, il team è relativamente libero di progettare e implementare secondo le proprie vedute, ma è richiesta comunicazione tra i team per evitare che si realizzino in parallelo gli stessi meccanismi di implementazione.

Tipicamente, i team di costruzione hanno un'organizzazione orizzontale, lungo le linee dei livelli. Un team può essere responsabile delle interfacce di database o dell'infrastruttura di comunicazione, mentre gli altri team si concentrano sulla funzionalità stessa dell'applicazione. I team di livello "superiore" di conseguenza necessitano di una maggiore esperienza nel dominio del problema mediante la progettazione dell'interfaccia utente o interfacciando con i sistemi esterni. I team di livello "inferiore" hanno più dimestichezza con la tecnologia di implementazione. La composizione di questi team deve rispecchiare le seguenti diverse richieste di skill.

Personale nelle attività di test

La prima domanda nell'ambito dei test è quante verifiche formali sono richieste? Inoltre, quanto tempo si può dedicare a questa attività per poter soddisfare gli obiettivi di qualità e tuttavia essere ancora nei limiti ragionevoli da un punto di vista economico e di pianificazione. E' raro che i progetti abbiano il budget necessario per effettuare tutti i tipi di test. Tipicamente, i progetti devono selezionare un livello di test possono permettersi. Tenere presente che ciascuna specifica di test deve essere esaminata e sostenuta. E' controproducente perlo stato d'animo del team di progetto se esistono dei piani per creare molte specifiche di test, ma poi non è possibile implementarli perché si ha poco tempo.

Creare uno specifico team di test. Almeno una persona nel team di test deve provenire dal team di acquisizione dei requisiti. Il team di test è responsabile per:

  • Test black-box. Eseguire il test dei casi d'uso dall'esterno del sistema sulla base del flusso di eventi del caso d'uso (consultare Prodotto di lavoro: Caso d'uso).
  • Test white-box. Eseguire il test dell'invio effettivo dei messaggi nel caso d'uso sulla base delle viste sequenza per gli scenari.
  • Test di sistema. Sollecitare il sistema per rivelarne la vera natura.

Tenere presente che la verifica non si limita solo all'esecuzione dei test - l'attività include anche la preparazione dell'ambiente di test e la scrittura e il controllo delle specifiche.

Un gruppo indipendente deve eseguire il test dei casi d'uso e dell'intero sistema. I componenti devono eseguire i test e scrivere anche i report del test. L'attività di verifica dei casi d'uso deve essere organizzata in modo che vi sia una persona responsabile per la verifica di ciascun caso d'uso.

Se non è possibile per un gruppo indipendente eseguire il test dei casi d'uso, poiché impegnato su un piccolo progetto, occorre almeno essere certi che la persona responsabile della progettazione di un caso d'uso non esegua il test del caso d'uso.

La verifica automatizzata della regressione deve essere effettuata su progetti medi e grandi. Il team di test richiederà alcuni programmatori per supportare questa funzionalità. Ciò è anche più importante durante uno sviluppo interattivo, dove non si intende impegnare troppe risorse rieseguendo le suite di test più volte.

Personale nella fase di transizione

Nella fase di transizione, l'attività di sviluppo è completata. Viene condotta la fase di verifica beta e preparata un rilascio finale. Se è stato fatto un buon lavoro nella fase di costruzione, il team di progetto può iniziare a ridimensionarsi, riducendo il numero di sviluppatori e di tester. La composizione del team inizierà a cambiare con l'inserimento di istruttori e di esperti nella logistica d'infrastruttura che sono responsabili per la distribuzione del prodotto nella comunità di utenti.

L'architetto di software o il team di architettura lavora in una "modalità supplementare": contribuisce ad ordinare i report dei problemi, assegnare una priorità alle proposte di modifica e cambiare gli ordini per accertarsi che i problemi non siano corretti per un motivo di convenienza in un modo che possa danneggiare l'architettura. Le attività di progettazione tendono a ridursi durante la fase di transizione e sono limitate alla risoluzione dei problemi o all'introduzione dei miglioramenti dell'ultimo minuto.