Project Management

Project Kickoff

Il kickoff di progetto è un meeting iniziale per l’avvio di un nuovo progetto. Viene convocato dal marketing / amministrazione nel momento di concretizzare una lead.

Partecipanti

• Marketing/Owner

• Possibili candidati per sviluppo

• Realizzazione (piattaforma)

• Sysadmin

Output

Nel kickoff vanno stabiliti:

• Tipologia progetto

  Se POC o prodotto completo. È importante stabilirlo perchè a seconda della tipologia cambiano le necessità per deploy, testing, ecc.

• Referente

  Il referente non è il project manager, ma piuttosto una persona di riferimento per il progetto: ovvero una persona che dovrà essere sempre informata sullo stato generale dello stesso. E’ compito sia del referente, sia del team di progetto, di tenersi vicendevolmente aggiornati sullo stato del progetto stesso, segnalando eventuali problemi, documentazione mancante, ambienti malfunzionanti e così via, nell’ottica di consegnare il lavoro nei tempi previsti: alzare la “bandierina” per segnalare un problema il prima possibile, e cioè appena ci si rende conto che il nostro margine di intervento sia nullo. Il referente può essere sia un membro del team che lavorerà sul progetto, sia un “esterno”. L’unico vincolo è che, nel caso sul progetto lavori un’unica persona, il referente sia qualcun altro; l’obiettivo che ci siano sempre almeno 2 persone a conoscenza di un progetto.

• Meeting

  Di seguito gli incontri necessari per gestire nel modo migliore l’andamento di un progetto:

  • Meeting di allineamento: 1 volta a settimana il referente si confronta con il marketing/product owner in un breve incontro di max 15 minuti, per sapere a che punto sia il progetto e per confrontarsi con i requisiti

  • Meeting con Pierpaolo/Luca: quando necessario (1 volta a settimana/2 settimane) il referente allinea Pierpaolo e Luca sulla situazione di progetto. E’ responsabilità del referente cercare di organizzare la riunione, con ogni mezzo

  • Meeting con i referenti di tutti i progetti: ogni 2 settimane Pierpaolo incontra tutti i referenti dei vari progetti per capire la disponibilità delle risorse e aggiornarsi sui progetti cross.

• Deadline consegna

  Importante anche perchè in base a questa si potranno fissare a ritroso date dei test e altri step propedeutici al rilascio.

  • Load test: da fare solo per i prodotti o per i software, pianificarli in modo che terminino almeno 2 giorni prima del rilascio. Utilizzare questo template per preparare la test list da dare al sysadmin.

  • Test end-to-end: pianificarli in modo che siano terminati almeno 3-4 giorni prima del rilascio, per avere la possibilità di fare aggiustamenti, modifiche, etc.

  • UATT (User Acceptance Tests): riguardanti solo la UI e la UX, fare in modo che non avvengano modifiche durante o dopo i test end-to-end! Quindi, da gestire a seconda del cliente. Se la UI/UX sono indipendenti dai test funzionali, possono andare anche in parallelo, utilizzando mock-up, etc.

• Ambiente

  Ambiente su cui dovrà essere deployato e girare il progetto. Generalmente svil e preprod per POC; svil, preprod e prod per prodotti “reali”

• Canale slack dedicato per coordinamento

• Progetto gitlab

  Se il progetto richiede codice, il repository sul nostro gitlab su cui andrà tracciato. Eventualmente anche più di uno per progetti che necessiteranno di più pezzi. Non necessarimente sul nostro gitlab, potrebbe essere anche GitHub o altri repositories per, ad esempio, codice pubblico

• Infrastruttura impattata

  A carico del sysadmin, serve per identificare quali componenti infrastrutturali, interne o esterne, saranno impattate dal flusso applicativo proposto nel progetto. In questo modo sarà possibile effettuare le richieste di consistenze, apertura firewall, preparazione database, etc. in tempo per gli sviluppi.

• Progetto su odoo

  Odoo sarà il punto di riferimento per il progetto, e dovrà quindi funzionare da hub centrale per il progetto, raccogliendo tutte le informazioni utili allo stesso. Bisognerà quindi creare il progetto su Odoo, scrivere e tenere aggionate tutte le informazioni:

  • Nome del progetto. Nel caso di progetti con vari sottoprogetti, come ad esempio Windtalk che si può suddividere in Windtalk Android e Windtalk iOS, creare più progetti seguendo la seguente convenzione per i nomi: <nome progetto> - <nome componente. Per esempio, Windtalk - Android o IPI - Odoo. In futuro implementeremo una funzionalità di “sottoprogetti” esplicita in Odoo.

  • I vari parametri di progetto emersi nel kickoff. Usare i campi appositi quando presenti, altrimenti annotare nella descrizione o come nota.

  • Documenti relativi al progetto (usare attachments odoo o mettere il link nella descrizione progetto o widget messaggi sotto al form)

  • Ore impiegate per lo sviluppo del progetto, utilizzando la funzione timesheet di Odoo. È importante segnare le ore effettivamente lavorate sul progetto corretto, così che l’amministrazione possa verificare tempi e costi spesi per lo sviluppo del progetto.

  • Board Tasks e avanzamento, alla Trello, usando il project management di Odoo. Per i progetti “con codice”, adottiamo una board standard, che per il momento deve essere ricreata “a mano”, ma in futuro sarà selezionabile come template o direttamente creata di default.

    La board standard prevede le colonne:

    • To Do

    • Doing

    • Test/QA

    • Done

    • Blocked

      Attività bloccate nell’attesa di altre attività o step propedeutici in carico ad altri membri del team, o del cliente, o di forze divine.

    • Continuative/Varie

      Sono attività trasversali che non si applicano al singolo task ma al progetto in generale. Per questa colonna andranno creati da subito anche dei task fissi: Riunioni/Calls, Documentazione, Analisi/Studio.