EcoConn

Appearance

Schema dei meeting ​

Meeting 1: Discussione della proposta di progetto ​

Partecipanti: PM, team di sviluppo (tra cui tecnografo), stakeholder (due rappresentanti RR e rappresentante del reparto IT interno di RR). Input: La richiesta del cliente Output: Resoconto meeting, desideri del cliente sotto forma di must have, nice to have and out of scope, POS 0.1v Agenda:

  1. Introduzione: L’ente RR ci ha proposto un progetto di evoluzione di EcoDomus. Dobbiamo capire chi è RR, quali sono i suoi obiettivi e in che contesto deve operare l’evoluzione di EcoDomus.
  2. Scopo del Meeting: Capire le necessità di RR e i desideri sulla versione evoluta di EcoDomus
  3. Descrizione dello stato corrente: Dobbiamo esprimere al meglio il funzionamento di EcoDomus
  4. Descrizione del problema o della business opportunity: Quali funzionalità dobbiamo aggiungere a EcoDomus? Quali vantaggi possono portare a noi l’aggiunta di tali funzionalità? Dobbiamo capire se la soluzione verrà implementata in tutte le sedi di RR o solo quelle nuove e se possiamo mostrare la soluzione come show case per altri clienti.
  5. Descrizione dello stato finale da raggiungere: riepiloghiamo quali sono le mancanze di EcoDomus e come dovrebbe funzionare la sua evoluzione
  6. Bozza del POS: prima bozza del POS contenente la descrizione del problema

Meeting 1.5: Analisi del problema ​

Partecipanti: PM, Architetto Input: Resoconto meeting, desideri del cliente, POS 0.1v Output: Bozza business requirements, CoS e User Stories, POS 0.1.5v Agenda:

  1. Scopo del Meeting: Allineare l’architetto, formalizzare i business requirements e determinare le CoS e le user stories per analizzare il problema
  2. Discussione delle CoS e user stories
  3. Discussione del "gap" esistente tra lo stato corrente e quello che si vuole raggiungere al termine del progetto: condurre un’analisi as is e to be per analizzare il gap
  4. Bozza del POS: aggiornare il POS con l’analisi as is/to be

Meeting 2: Verifica dei desideri, CoS e User Stories ​

Partecipanti: PM, architetto, tecnografo, stakeholder (due rappresentanti RR e rappresentante del reparto IT interno di RR). Input: Bozza business requirements, CoS e user stories, POS 0.1.5v Output: Resoconto meeting, raffinamento business requirements, CoS e user stories, SMART analysis, POS 0.2v Agenda:

  1. Scopo del Meeting: Riscontro sull’analisi del problema e determinare i requisiti
  2. Discussione delle CoS e user stories: Ottenere un riscontro sulle Condition of Satisfaction e delle user stories
  3. Discussione dei requisiti: Ottenere un riscontro sui business requirements e determinare i requisiti rimanenti
  4. Bozza del POS: aggiornamento della situazione to be, definizione dei criteri di successo, definizione dei obiettivi con annessa descrizione dei rischi

Meeting 2.5.1: Raffinamento CoS e user stories ​

Partecipanti: PM, Architetto Input: Resoconto meeting 2, desideri del cliente, business requirements, CoS e user stories, POS 0.2v, SMART analysis Output: Raffinamento business requirements, CoS e user stories Agenda:

  1. Scopo del Meeting: Determinare le CoS e le user stories degli ultimi desideri del cliente
  2. Discussione delle CoS e user stories

Meeting 2.5.2: Analisi dei dominio ​

Partecipanti: PM, Architetto, team di sviluppo Input: Resoconto meeting 2, desideri del cliente, raffinamento business requirements, CoS e user stories Output: Event storming, context map, lista dei use cases da definire Agenda:

  1. Scopo del Meeting: Svolgere l’event storming per analizzare il dominio del problema
  2. Descrizione dello stato finale da raggiungere: Determinare da quali componenti sarà composta la piattaforma finale

Meeting 2.5.3: Analisi SWOT e prototipazione ​

Partecipanti: PM, Architetto, team di sviluppo Input: Resoconto meeting 2, desideri del cliente, raffinamento business requirements, CoS e user stories, event storming, context map, lista dei use cases da definire, SMART analysis Output: SWOT analysis, mockup, use case, SMART analysis, POS 0.2.5v Agenda:

  1. Scopo del Meeting: Riscontro sulla SWOT analysis e sui mockup
  2. Descrizione dello stato finale da raggiungere: Riscontro sui mockup creati.

Meeting 3: Risconto dell’analisi del dominio con validazioni di use cases e mockup ​

Partecipanti: PM, team di sviluppo, stakeholder (due rappresentanti RR e rappresentante del reparto IT interno di RR), focus group (2 operatori di RR, 2 studenti) Input: Raffinamento business requirements, mockup, use case, POS 0.2.5v Output: Resoconto meeting, POS 1v, RBS, PMLC Agenda:

  1. Descrizione dello stato finale da raggiungere: Ottenere un riscontro sullo stato finale da raggiungere tramite la validazione dei use cases e dei mockup da parte del focus group
  2. Discussione dei requisiti: definizione della RBS finale
  3. Scelta dell’approccio per gestire il progetto (PMLC model) che meglio si adatta al "gap" individuato
  4. Bozza del POS: allineare se necessario il POS e preparalo per l’approvazione