Riepilogo meeting 3: “Risconto dell’analisi del dominio con validazioni di use cases e mockup”

Partecipanti

• PM
• Team di sviluppo
  • Tra cui un tecnografo
• Stakeholder
  • Rappresentati di RR
  • Rappresentante del reparto IT interno di RR
  • Focus group (2 operatori di RR, 2 studenti)

Nell’ultimo meeting sono presenti anche i membri dei focus group coinvolti nell'approvazione della sezione amministrativa della piattaforma e nell’approvazione della sezione dedicata agli ospiti.

Documenti prodotti

Argomenti discussi

Il tecnografo produce il seguente documento:

1. Descrizione dello stato finale da raggiungere: Sono stati mostrati gli use cases e i mockup ai focus group in modo tale da simulare un prototipo e ottenere un riscontro. Gli operatori hanno valutato positivamente l’attività di configurazione e visualizzazione dei consumi sia generali che per camera. Agli studenti è stata chiesto di dare un riscontro alla dashboard di monitoraggio dei propri consumi. Per facilitare l’interazione e la valutazione, è stata presentata anche la versione attuale di EcoDomus, consentendo un’interazione diretta con i grafici. I riscontri complessivi sono stati positivi.
2. Discussione dei requisiti: Sono stati ribaditi i requisiti, approfondendoli con i dettagli emersi durante la fase di analisi. Nel mentre è stata definita parzialmente la Requirements Breakdown Structure delineando i goal partendo dai requisiti di business.
3. Scelta dell’approccio per gestire il progetto (PMLC model) che meglio si adatta al "gap" individuato: Il PM comunica che il progetto sarà gestito in modo agile, adottando come PMLC un approccio iterativo. Si tratta di un progetto nuovo, con uno scope già definito ma una soluzione ancora da delineare, poiché parte del problema da affrontare (come le funzionalità di previsioni e editor di piantine) è nuovo per EC. Anche la reingegnerizzazione di EcoDomus rappresenta un’attività del tutto nuova per l’azienda. La fase di pianificazione verrà gestita in due modi:

• Ci sarà una fase di planning pensata allo sviluppo di microservizi considerando eventuali dipendenze tra i vari task e relative priorità. Le stime e la pianificazione verranno fatte considerando il caso migliore, ossia le risorse faranno i task più attinenti alle loro competenze, con le iterazioni che poi permetteranno di monitorare e correggere le stime.
• Nella fase di esecuzione si adotterà il metodo Kanban come modello da seguire per lo sviluppo del progetto, come suggerito dall'architetto che fungerà anche da consulente di tale metodologia. Durante questa fase gli sviluppatori si gestiscono in modo autonomo la selezione dei task, cercando di seguire quanto pianificato ma senza essere vincolati al piano. In questo modo possiamo avere una stima sufficentemente accurata, sia dei tempi che dei costi, durante la fase di stipulazione del contratto. Invece, durante il launching, viene lasciata maggiore libertà agli sviluppatori, sia nella gestione dei propri impegni con altri progetti, sia nella scelta dei task, dando la possibilità di scegliere task anche in ambiti meno familiari, per favorire la crescita delle competenze.

RBS

Terminato il meeting il PM finisce di definire RBS arricchendolo con le funzioni e le feature.

POS

Terminato il meeting il PM produce il POS 1.0v (uguale al POS 2.5v) che viene mandato al AD il quale lo approva.