Pianificare un progetto (CMMI)
Il risultato desiderato della pianificazione di un progetto è un piano che include un ambito, una pianificazione, un budget, un piano di gestione dei rischi, nonché l'impegno e l'approvazione da tutte le parti interessate. Dopo aver ottenuto un piano del progetto concordato, è necessario proseguire con l'analisi, la progettazione, lo sviluppo, il test e il recapito finale.
È possibile ridurre i rischi utilizzando un metodo di sviluppo iterativo. Le iterazioni consentono di dimostrare un prodotto parzialmente funzionante alla fine di ogni iterazione e agiscono sui commenti e i suggerimenti ottenuti da tale dimostrazione. Il piano fornisce pertanto una forma complessiva ed è soggetto a revisione e perfezionamento prima dell'inizio di ogni iterazione.
Raccolta e modellazione dei requisiti
Questa attività riguarda la discussione delle finalità del sistema con parti interessate all'interno dell'azienda, utenti potenziali ed esperti in materia. È importante definire il contesto aziendale. Se si è stati incaricati di scrivere un'applicazione per agenti di polizia, è importante comprenderne il gergo, le procedure e le regole.
I modelli UML sono un utile strumento per esprimere e concepire relazioni complesse. È possibile disegnare tali modelli in Visual Studio e collegarli ad altri documenti e a elementi di lavoro di Team Foundation. Per ulteriori informazioni, vedere Modellazione dei requisiti utente.
Aggiornare e perfezionare il modello dei requisiti in tutto il progetto. Nell'affrontare iterazioni successive, aggiungere agli aspetti del modello maggiori dettagli pertinenti all'iterazione in corso. Dal modello è possibile derivare test di verifica.
Per ulteriori informazioni, vedere Sviluppare requisiti e Sviluppo di test da un modello.
Creazione di requisiti del prodotto incrementali
I requisiti raccolti dai clienti non sono di per sé immediatamente appropriati ai fini della pianificazione di uno sviluppo incrementale. Per chiarire, ad esempio, la procedura in cui un utente acquista un articolo da un sito Web, potrebbe essere stata scritta una serie dettagliata di passaggi, quali: il cliente esplora il catalogo, aggiunge articoli al carrello, verifica il contenuto del carrello, fornisce l'indirizzo e paga, il magazzino pianifica il recapito e così via. Questi passaggi, o un diagramma attività equivalente, non rappresentano di per sé requisiti incrementali.
Al contrario, il primo incremento del sistema potrebbe offrire solo un articolo per la vendita, recapitare solo a un indirizzo ed eseguire solo una transazione di prova con il servizio di pagamento. Il secondo incremento potrebbe fornire un catalogo costituito da un elenco semplice. Gli incrementi successivi potrebbero aggiungere l'opzione di una confezione regalo per l'acquisto o la possibilità di richiedere cataloghi di fornitori diversi. Alcuni incrementi potrebbero riguardare la qualità del servizio, ad esempio la possibilità di gestire 1.000 clienti anziché uno solo.
In altri termini, gli incrementi iniziali devono includere i principali casi di utilizzo end-to-end e aggiungere gradualmente funzionalità a ogni passaggio.
Il principio è lo stesso se si utilizza un prodotto esistente, ma in questo caso sarà necessario iniziare dalla funzionalità esistente. Se non si ha familiarità con la progettazione interna del prodotto, i costi di aggiornamento possono risultare difficili da stimare. È consigliabile adottare stime piuttosto tolleranti per le modifiche iniziali.
Per ulteriori informazioni, vedere Sviluppare requisiti.
Immissione e modifica dei requisiti del prodotto
Registrare i requisiti del prodotto incrementali come elementi di lavoro requisito in Team Foundation e impostare il tipo di requisito su Funzionalità. È possibile creare un backlog dei requisiti utilizzando TWA o Team Explorer. Se sono presenti più elementi di lavoro che si desidera creare contemporaneamente, è possibile utilizzare Excel.
Stima dei requisiti del prodotto
Il team di sviluppo deve stimare il lavoro necessario per sviluppare ogni requisito del prodotto. La stima deve essere immessa in ore nel campo Stima originale dell'elemento di lavoro.
Nelle fasi iniziali del progetto è necessaria solo una stima approssimativa.
Suddividere grandi requisiti del prodotto in requisiti minori. Idealmente, ciascun requisito del prodotto richiede tempi di sviluppo di pochi giorni.
Assegnazione di requisiti del prodotto a iterazioni
I rappresentanti delle parti interessate all'interno dell'azienda e del team di sviluppo devono collaborare per assegnare requisiti del prodotto a iterazioni. A tale scopo, si partecipa in genere a una riunione in cui viene condivisa o proiettata la visualizzazione Office Excel della query Requisiti del prodotto.
L'assegnazione viene completata utilizzando le informazioni seguenti:
Priorità del requisito. Vedere le note nella sezione secondaria seguente.
Costo stimato. Considerando il numero di membri del team e la durata dell'iterazione, ogni iterazione prevede solo un numero fisso di ore disponibili per lo sviluppo. Un numero significativo di tali ore, inoltre, verrà utilizzato per la pianificazione dell'iterazione e per altre attività che non comportano direttamente lo sviluppo.
Dipendenze tra i requisiti del prodotto. In una serie incrementale di requisiti, i requisiti più semplici devono essere affrontati prima dei miglioramenti nella stessa area.
È possibile definire il requisito in un elemento di lavoro specificando un'ampia gamma di informazioni, come illustrato nelle figure seguenti:
.png "Requirement work item form")
Alcune linee guida sulla classificazione in ordine di priorità
Per la classificazione in ordine di priorità sono disponibili molto schemi dettagliati. Alcuni di questi schemi verranno esaminati durante la trattazione della pianificazione dell'iterazione. Per il momento, a livello di progetto, vengono fornite alcune linee guida utili per semplificare la gestione dei rischi e ottimizzare il valore aggiunto.
Classificare in ordine di priorità scenari end-to-end minimi.
Puntare a realizzare uno scenario end-to-end semplice il prima possibile nel progetto. In un secondo momento, aggiungere altre funzionalità alle diverse parti dello scenario. Questa prassi fa sì che le funzioni principali della piattaforma e le idee principali nei requisiti vengano provate nelle fasi iniziali.
Al contrario, non dividere la pianificazione in base all'architettura. Una pianificazione che completa il database, la logica di business e quindi l'interfaccia utente richiederà probabilmente un'elevata quantità di rielaborazione per integrare le parti alla fine. Analogamente, non è consigliabile una divisione orizzontale come {componente vendite; componente warehouse; componente pagamento}. Questa divisione produrrebbe probabilmente un sistema ottimale per la vendita sul Web ma il tempo scadrebbe prima che l'azienda riesca a ottenere il denaro dai clienti. È possibile pianificare componenti completi per iterazioni successive solo se si tratta effettivamente di componenti aggiuntivi facoltativi.
Classificare i rischi tecnici in ordine di priorità.
Se un scenario include un elemento tecnicamente rischioso, svilupparlo nelle fasi iniziali della pianificazione. Adottare un approccio ai rischi che preveda la gestione degli errori nelle fasi iniziali. Se un'attività non può essere portata a termine, è utile esserne a conoscenza all'inizio del progetto, in modo da poterla annullare o sostituire con un approccio alternativo. Per questo motivo, è consigliabile classificare in ordine di priorità i requisiti rischiosi nelle iterazioni iniziali.
Classificare in ordine di priorità la riduzione delle incertezze.
Le parti interessate all'interno dell'azienda nutriranno dubbi su alcuni requisiti. È difficile prevedere il comportamento più adatto del prodotto nel contesto aziendale. Classificare in ordine di priorità gli approcci più probabili per la riduzione delle incertezze. Questo obiettivo viene spesso realizzato sviluppando una versione semplice dello scenario, che gli utenti possono quindi provare. Rinviare lo scenario completo a un'iterazione successiva in cui sia possibile considerare i risultati di tali esperimenti.
Classificare in ordine di priorità i requisiti di valore elevato.
Se possibile, provare a stabilire una funzione relativa al costo opportunità del ritardo per ogni scenario. Utilizzare questi elementi per determinare i requisiti che possono attribuire maggiore valore ai clienti nelle fasi iniziali. Classificare in ordine di priorità questi requisiti nelle iterazioni iniziali. In questo modo, si potrebbe essere in grado di rilasciare presto un prodotto parziale.
Raggruppare gli scenari comuni a più utenti tipo.
In presenza di scenari utili per due o più utenti tipo, raggrupparli insieme. Classificarli in base al numero di utenti tipo che richiedono lo scenario. Classificare in ordine di priorità gli scenari che si applicano a un numero maggiore di utenti tipo nelle iterazioni iniziali.
Classificare gli utenti tipo.
Gli utenti tipo rappresentano segmenti di mercato o gruppi di utenti. I responsabili di marketing o i titolari di azienda devono essere in grado di determinare la priorità di tali segmenti o gruppi in base all'utilità da fornire o al valore del segmento. Se è possibile classificare in ordine di priorità segmenti o gruppi di utenti, rappresentare questo comportamento elencando gli utenti tipo per ciascun segmento in base alla classificazione. Identificare gli scenari per gli utenti tipo con valutazione più alta e classificarli in ordine di priorità nelle iterazioni iniziali all'interno della pianificazione.
In generale, è consigliabile classificare in ordine di priorità la riduzione dei rischi a causa della possibilità di errore. È opportuno classificare in ordine di priorità le funzionalità comuni in quanto associate a una probabilità elevata di essere richieste e a una probabilità ridotta di cambiare. È inoltre opportuno classificare in ordine di priorità i requisiti di valore maggiore. Infine, è utile consentire un rilascio tempestivo del prodotto a un subset di utenti tipo classificando in ordine di priorità tutti gli scenari necessari per soddisfare le esigenze di qualsiasi utente tipo.
Pianificazione dei test
Il lavoro stimato per ogni requisito deve includere l'impegno necessario per testare il requisito, manualmente o tramite la creazione di un test automatizzato.
Prima che sia considerato completato, ogni requisito del prodotto deve essere collegato a un set di elementi di lavoro test case che dimostrino insieme che il requisito sia stato soddisfatto. È inoltre necessario superare tutti i test.
Durante la creazione o la revisione dei requisiti del prodotto, è necessario aggiornare il piano di test corrispondente.
Revisione dei requisiti del prodotto
Rieseguire questa attività prima di ogni iterazione per valutare requisiti nuovi e rivisti, priorità riviste e stime riviste. Le prime iterazioni includeranno un numero maggiore di revisioni.
Dopo le prime iterazioni, i membri del team di sviluppo considereranno le stime più attendibili. I membri del team dovranno esaminare le stime per una o due iterazioni successive e rivedere i campi Stima originale dei requisiti assegnati a tali iterazioni.