Scoping

In questa sezione, si descriverà il processo seguito per comprendere la situazione attuale del Committente e i suoi desideri, definendo gli obiettivi del progetto di conseguenza.

Contenuti

Scoping Meetings

In questa fase di Scoping, sono stati organizzati i seguenti meeting in giornate separate, distribuite nell’arco di due settimane.

Problem Definition Meeting

  • Partecipanti:
    • Claudio Rossi, in qualità di Committente;
    • Paola Celeste, in qualità di Project Manager lato cliente;
    • Pietro Magnolia, in qualità di Project Manager lato fornitore e di Facilitatore, ovvero mediatore della riunione;
    • Francesco Marroni, in qualità di Tecnografo, per la stesura del verbale.
  • Agenda:
    • Presentazione del Committente;
    • Presentazione tra il Project Manager lato cliente e il Project Manager lato fornitore;
    • Presentazione del business di GameCo;
    • Descrizione della situazione attuale di GameCo (ovvero dell’as is);
    • Descrizione del problema o dell’opportunità individuata da GameCo;
    • Descrizione della situazione desiderata da GameCo (ovvero del to be);
    • Definizione delle Conditions of Satisfaction a livello di progetto;
    • Organizzazione dei successivi Scoping Meetings.
  • Data: 09-01-2023
  • Durata: 4 ore
  • Verbale: link

Requirements Definition Meeting

  • Partecipanti:
    • Paola Celeste, in qualità di Project Manager lato cliente;
    • Pietro Magnolia, in qualità di Project Manager lato fornitore e di Facilitatore, ovvero mediatore della riunione;
    • Core Team lato cliente, come consulente per il Project Manager lato cliente:
      • Cristina Grigi;
      • Camilla Gialli;
      • Cesare Neri;
      • Carlo Verdi.
    • Core Team lato fornitore, come consulente per il Project Manager lato fornitore:
      • Francesco Marroni, in qualità di Tecnografo, per la stesura del verbale;
      • Filippo Ecru;
      • Federica Viola;
      • Franca Arancioni.
  • Agenda:
    • Presentazione dei Core Team di entrambe le parti;
    • Definizione delle User Stories, ovvero dei requisiti del progetto e delle Conditions of Satisfaction a livello di deliverable;
    • Presentazione e revisione della RBS;
    • Discussione del gap tra l’as is ed il to be.
  • Data: 11-01-2023, 16-01-2023
  • Durata: 8 ore, divise su due giornate
  • Verbale: link

POS Submission Meeting

  • Partecipanti:
    • Claudio Rossi, in qualità di Committente;
    • Paola Celeste, in qualità di Project Manager lato cliente;
    • Pietro Magnolia, in qualità di Project Manager lato fornitore e di Facilitatore, ovvero mediatore della riunione;
    • Core Team lato cliente, come consulente per il Project Manager lato cliente:
      • Cristina Grigi;
      • Camilla Gialli;
      • Cesare Neri;
      • Carlo Verdi.
    • Core Team lato fornitore, come consulente per il Project Manager lato fornitore:
      • Francesco Marroni, in qualità di Tecnografo, per la stesura del verbale;
      • Filippo Ecru;
      • Federica Viola;
      • Franca Arancioni.
  • Agenda:
    • Discussione del POS redatto dal Project Manager lato fornitore:
      • Discussione sul problema e sulle opportunità del progetto;
      • Discussione sugli obiettivi del progetto;
      • Discussione dei criteri di successo del progetto;
      • Discussione di assunzioni, rischi e ostacoli;
      • Discussione del PMLC Model.
    • Discussione sulla fattibilità di massima del progetto;
    • Approvazione o rifiuto del POS.
  • Data: 23-01-2023
  • Durata: 4 ore
  • Verbale: link

Conditions of Satisfaction

Durante il Problem Definition Meeting, sono state definite delle Conditions of Satisfaction a livello di progetto, disponibili al seguente link, allo scopo di formalizzare e dettagliare gli effettivi desideri del Committente.

Particolare importanza è stata data alla definizione di vincoli di tempi e budget più precisi, per comprendere meglio l’entità del progetto e successivamente facilitare la pianificazione e la gestione delle risorse.

Definizione dei requisiti

Di seguito, si riporta il processo di definizione dei requisiti del progetto, che è partito dall’identificazione delle necessità degli utenti finali del sistema e terminato con la definizione formale dei requisiti del progetto.

User Stories

Durante il Requirements Definition Meeting, sono stati definiti i requisiti di progetto in termini di User Stories, disponibili al seguente link. In questo modo, è stata condotta un’analisi sulle necessità degli utenti finali, ovvero dei giocatori dell’applicazione, quindi i requisiti del progetto saranno il più vicino possibile a loro.

Le User Stories dovranno essere utilizzate come riferimento per la verifica del sistema.

Requirement Breakdown Structure (RBS)

Tra le due giornate del meeting, allo scopo di facilitare la pianificazione nelle fasi successive del progetto, si è lavorato per trasformare le User Stories in una RBS, disponibile al seguente link. In particolare, sono state organizzate alcune Facilitated Group Session all’interno dell’azienda del fornitore, coinvolgendo gli esperti del dominio. Queste riunioni sono state condotte dal Project Manager, che ha assunto il ruolo di Facilitatore.

Siccome GameCo ha già realizzato un progetto relativo al gioco degli scacchi, sarà possibile riutilizzare alcuni dei requisiti di quel progetto, almeno per quanto riguarda la gestione delle regole di una partita di scacchi (1.a.d e 1.c).

Dopo aver presentato e discusso la RBS con il cliente, si è ottenuto un suo riscontro positivo, in seguito a cui è stata iniziata la stesura del POS.

SWOT Analysis

Come fase preliminare alla stesura del POS, è stata svolta la SWOT Analysis, disponibile al seguente link, per cui sono stati analizzati i punti di forza e le debolezze del progetto, da cui sono state derivate le possibili opportunità e minacce per il suo successo.

Project Management Lifecycle Model (PMLC) Model

In seguito all’analisi del progetto, si ha ragionato sull’approccio migliore per la sua gestione.

Per quanto riguarda la possibilità di adottare un approccio tradizionale, si è considerato che si potrebbe approfittare dell’esperienza di GameCO nello sviluppo di applicazioni di scacchi e dell’esperienza del fornitore nello sviluppo di applicazioni web per produrre un piano completo del progetto, senza che sia necessario introdurre i rischi della flessibilità dell’approccio agile (es.: posticipazione della pianificazione…).

Tuttavia, considerando anche i rischi legati alle aziende competitrici sul mercato, potrebbe essere necessario reagire tempestivamente a modifiche sui requisiti che potrebbero insorgere durante il monitoraggio di tali aziende.

Presi in considerazione i vantaggi e gli svantaggi dell’approccio tradizionale e di quello agile, alla fine si è deciso di adottare un PMLC Model di tipo incrementale.

Project Overview Statement (POS)

Dopo aver scelto il PMLC Model più adeguato, si è deciso di sintetizzare le informazioni raccolte nella fase di Scoping per presentarle al proprio senior management e successivamente al Committente, allo scopo di riceverne l’approvazione. Il risultato di tale sintesi, è racchiuso nel POS, disponibile al seguente link.

Infine, al termine del POS Submission Meeting, si è ottenuta l’approvazione del Committente. Quindi, si ha potuto procedere con la fase di Planning.

Back to Top | Previous Chapter | Next Chapter