Gestione dei progetti - Elenco di controllo delle best practice managing-projects-best-practices-checklist

Un elenco di controllo interattivo che ti consente di tenere traccia e monitorare l’avanzamento con queste best practice.

• Definiscono gli input e i risultati in base a fase, milestone e utente tipo.
• Forniscono panoramiche automatizzate (qualità, integrità e completezza) per indicare lo stato di avanzamento e l’integrità del progetto.

Documentazione basata sull’elenco di controllo che descrive:

• Analisi Heartbeat del progetto.
• Panoramica dello Stato per ruolo.
• Fasi e milestone.
• Utente tipo chiave e il relativo coinvolgimento in ogni fase (rilevante).
• Un Glossario dei Documenti e risultati richiesti.

Ulteriore materiale di riferimento per fornire ulteriori dettagli su aree specifiche.

Qualità fase

• Indica la qualità dei documenti e risultati richiesti nel progetto.

Integrità fase

• Un indicatore di stato di alto livello per il progetto; utile per evidenziare le aree che potrebbero essere a rischio.

Completezza fase

• In qualsiasi momento durante il progetto, indica quanto è già stato completato per ogni fase del progetto.

Base logica aziendale

• Le ragioni fondamentali e la giustificazione per intraprendere il progetto.

Ambito e pianificazione

• Dovrebbe essere reso disponibile un ambito di base e una pianificazione approssimativa per definire ciò che è necessario ed entro quale arco temporale; se questo aiuta a chiarire la situazione, puoi anche definire cosa non rientra nell’ambito.

Convalida

In questa fase, devi convalidare e confermare gli obiettivi del progetto, ad esempio:

• Cosa intendi raggiungere/fornire?

• Chi ne beneficia?

• Qual è l’ambito?

  • Se aiuta a chiarire la situazione, puoi anche definire che cosa non rientra nell’ambito.

• Come definiresti il successo?

• Come si misura il successo?

• Quali sono i requisiti aziendali e tecnici?

• Esistono sistemi legacy da sostituire e, in caso affermativo, vi sono dati da migrare?

• Chi è coinvolto?

• Come si misura il progresso?

• Con quale frequenza esamini i progressi compiuti nel corso del progetto?

Budget

Prima di iniziare un progetto è necessario avere una stima affidabile e realistica dei costi di implementazione:

• Utilizza le informazioni della milestone di convalida come base per le stime.
• Esegui delle stime realistiche.
• Considera e rispetta linee guida, processi o restrizioni a cui il cliente è soggetto.
• Nel caso in cui in futuro fosse necessario rivedere o perfezionare il budget, prendi in considerazione processi di emergenza e revisione.
• Tieni presente che i costi possono presentarsi in molte forme, tra cui acquisti, utilizzo di risorse e tariffe.

Consegna

Un passaggio di consegne pulito assicura che la persona o i gruppi appropriati siano consapevoli delle loro responsabilità all’interno del progetto.

Dovrebbero essere forniti/generati dettagli completi per garantire che abbiano una piena comprensione di tutti gli aspetti pertinenti, tra cui la roadmap, l’ambito di applicazione, gli obiettivi, i requisiti e i KPI.

Valutazione dei rischi

Per evitare spiacevoli sorprese, utilizza la valutazione del rischio per identificare e quantificare i rischi potenziali, insieme al loro impatto e alla loro probabilità.

Ciò dovrebbe essere fatto nelle prime fasi del ciclo di vita del progetto per garantire che eventuali vulnerabilità siano identificate e valutate. In base ai risultati, puoi riferire alle parti interessate se è possibile implementare tutti i requisiti e, se necessario, pianificare l’adozione e il monitoraggio di azioni appropriate.

Comunicazione

La comunicazione è sempre fondamentale per il successo di qualsiasi progetto. Comunica in modo chiaro ed efficiente per garantire che tutti siano:

• Lavorare per raggiungere gli stessi obiettivi di base
• Dalla stessa base di informazioni
• Con gli stessi canali

Avvio

L’incontro iniziale è usato per aumentare la consapevolezza in merito all’inizio del progetto. Si tratta di una buona opportunità per:

• Invitare tutte le parti interessate (o almeno i rappresentanti dei gruppi).

• Presentare i fatti chiave del progetto.

• Rispondere alle domande.

• Assicurarsi che tutti abbiano la stessa knowledge base.

• Ottenere la conferma che tutti coloro che saranno coinvolti si impegneranno. Questo obiettivo dovrà essere guadagnato.

  • Coinvolgendo i protagonisti (inclusi i potenziali autori) fin dall’inizio del progetto, aumenti le possibilità che si impegnino per il progetto.

Team di sviluppo con personale e formazione

Prima di iniziare un progetto, è necessario assicurarsi che il team di sviluppo disponga di personale appropriato e che tutti i membri del team siano formati per l’attività in corso.

Architettura dei contenuti

L’architettura dei contenuti definisce e descrive l’architettura futura del contenuto, tra cui:

• Struttura contenuto, incluse le risorse
• Strutture di base, incluse le campagne e così via.
• Strutture multisito e multilingue (MSM, traduzione e così via)
• Contenuti di supporto (inclusi tag e concetti di tag)
• Strategie di caching e riutilizzo dei contenuti

Architettura di sistema

L’architettura del sistema definisce la visualizzazione concettuale del sistema, che include (tra le altre informazioni):

• Struttura di sistema per tutti gli ambienti richiesti

• Sottosistemi

• Sistemi di terze parti

• Interfacce; hardware, software e interazione umana

• Server per ogni ambiente; consulta le Specifiche tecniche e le Linee guida per il dimensionamento hardware

• Processi per ogni ambiente; ad esempio, requisiti di installazione e manutenzione

• Attività di manutenzione (Datastore GC, ottimizzazione TarPM e così via)

• Memorizzazione in cache di Dispatcher

• Cluster di Publish/Authorshare

• Prestazioni lato client (minimizzazione JS, concat, sprite css, numero totale di richieste http e non solo)

Architettura applicazione

L’architettura dell’applicazione definisce e descrive il comportamento delle applicazioni proposte.

È incentrata su:

• Le modalità in cui interagiscono tra loro e con gli utenti.
• I dati che devono essere utilizzati e prodotti dalle applicazioni, anziché la loro struttura interna.

Le definizioni dovrebbero comprendere:

• Struttura del codice di base per il progetto
• Artefatti di codice (bundle, pacchetti e così via)
• Raggruppamenti dei modelli/componenti e delle loro relazioni
• Dettagli di alto livello delle personalizzazioni richieste (le sovrapposizioni specifiche verranno riportate in seguito)
• Progettazione dei flussi di lavoro richiesti dalla soluzione (ad esempio creazione, approvazione, pubblicazione, trasformazioni, importazioni ed esportazioni di contenuti)
• Particolare attenzione per qualsiasi modulo complesso, come MSM, Commerce, integrazione di terze parti

Integrazione dei sistemi

L’integrazione dei sistemi richiede di pianificare (quindi implementare):

• Come tutti i sottosistemi e le integrazioni di soluzioni sono riuniti per funzionare come un unico sistema coerente
• Come vengono integrati i sistemi di terze parti, insieme a eventuali considerazioni speciali, come stato offline/online, lato client/lato browser o gestione del fallover quando un sistema di terze parti è inattivo

Concetto del test

Prima di iniziare lo sviluppo, devi elaborare un concetto approfondito e completo di tutti i requisiti di test per il tuo progetto.

Dovrebbe includere:

• Dettagli di tutti i test da eseguire
• Preparazione di qualsiasi contenuto necessario per tali test
• Informazioni sugli strumenti di test da utilizzare
• Indicazione di alto livello di chi sarà coinvolto nei test; in particolare gruppi al di fuori del team di controllo qualità
• Dettagli dell’automazione dei test; ad esempio, con la modalità Selenium o AEM Developer

Progettazione dell’esperienza

La progettazione dell’esperienza (XD) prevede la progettazione dell’esperienza utente per la tua soluzione.

L’esperienza utente deve essere analizzata e sviluppata sia per gli autori che per gli utenti finali del sito web.

Configurazione assistenza

Prima dello sviluppo, è necessario impostare tutti i processi di supporto necessari per distribuire, rilasciare, testare e segnalare i problemi.

Consulta anche il portale di supporto Adobe.

Autorizzazioni

È necessario pianificare e quindi implementare un concetto di ruoli e diritti per tutti gli utenti/gruppi che utilizzeranno la soluzione.

Ad esempio:

• Un elenco di ruoli (ovvero gruppi) con definizioni di accesso read/ write per ciascuno

• La definizione dell’utilizzo dei privilegi che influiscono sull’ambiente di pubblicazione; ad esempio, replicate

• Per gli utenti con privilegi minimi, i flussi di lavoro devono essere definiti

• Gli utenti del gruppo editor non devono avere diritti admin né far parte del gruppo administrators

Per ulteriori informazioni, consulta Amministrazione utenti e sicurezza.

Monitoraggio e manutenzione

Il monitoraggio e la manutenzione sono aspetti chiave per garantire il corretto funzionamento della soluzione una volta pubblicata. A questo scopo è necessario definire:

• Cosa deve essere monitorato
• Mansioni di manutenzione periodica e in casi speciali

Per ulteriori informazioni, consulta anche Monitoraggio e manutenzione.

Migrazione

Qualsiasi contenuto del sistema legacy deve essere rivisto e convalidato per la migrazione.

Piano di ripristino

Assicurati di disporre di un piano di ripristino. In situazioni di emergenza, questo deve essere disponibile per garantire l’utilizzo in produzione di AEM… Questo dovrebbe riguardare situazioni come backup, ripristino, blocco e altre.

Ambiente di sviluppo

Pianifica e documenta l’ambiente di sviluppo, tra cui:

• Architettura

• Strumenti di sviluppo

  • Un ambiente tipico è costituito da:

    • un sistema di tracciamento dei problemi, ad esempio Jira
    • un IDE, ad esempio Eclipse
    • uno strumento di gestione della build, ad esempio Maven
    • uno strumento per l’integrazione continua, ad esempio Jenkins
    • uno strumento per il controllo delle versioni, ad esempio GIT/SVN
    • un gestore dell’archivio di artefatti di build, ad esempio Archiva/Nexus

• Integrazione/dipendenze software di terze parti

• Integrazione/dipendenze della soluzione

• Cadenza dell’implementazione

Sistema di test

Pianifica e documenta l’ambiente di test, tra cui:

• Architettura
• Dipendenze dalle build di sviluppo; incluse le build notturne
• Possibilità o limitazioni di testare l’integrazione/le dipendenze del software di terze parti
• Strumenti di test
• Strategia di test automatizzati

Sistema di produzione

Pianifica e documenta l’ambiente di produzione, tra cui:

• Architettura
• Cadenza dell’implementazione
• Integrazione/dipendenze software di terze parti
• Configurazione di sicurezza
• Prestazioni della linea di base verificate eseguendo i test da carico estremo nella configurazione di produzione
• Requisiti per i test delle prestazioni; consulta Best practice per la garanzia di qualità

Integrazione

Pianifica, documenta e verifica tutti gli aspetti del sistema e dell’integrazione della soluzione, tra cui:

• Una strategia di test automatizzati
• Processi automatizzati per spostare le applicazioni dallo sviluppo al test, quindi alla produzione
• Processi automatizzati per spostare il contenuto dalla produzione al test e allo sviluppo

Migrazione

Pianifica, documenta e verifica tutti gli aspetti della migrazione dei contenuti, tra cui:

• Architettura dei contenuti
• Strategia di migrazione

Comunicazione

Assicurati che tutti i membri del gruppo e l’utente tipo del progetto siano tenuti aggiornati, se necessario.

Documentazione

Documenta completamente la soluzione, inclusi:

• Manuale operativo
• Eventuali personalizzazioni che possono influire sugli aggiornamenti
• Note sulla versione

Test di accettazione per l’utente finale

Il test di accettazione utente (UAT) è fondamentale per garantire che:

• La soluzione soddisfi le esigenze di utenti/clienti
• Il cliente/gli utenti accettino la soluzione (funzione, progettazione e prestazioni)

Dovrebbe essere presente una checklist formalizzata per il passaggio del cliente; idealmente automatizzata ed eseguita di notte su un’istantanea. I risultati devono essere inviati al project manager e al team di sviluppo

Test di prestazioni e di carico

I test di prestazioni e di carico vengono utilizzati per garantire che la soluzione soddisfi i livelli di prestazioni richiesti, a carichi medi e di picco.

Per ulteriori informazioni sui test delle prestazioni, consulta:

• Test delle prestazioni

• Pianificazione ed esecuzione dei test

• Linee guida sulle prestazioni di base

Preparazione

La preparazione e la pianificazione contribuiranno a garantire un rollout senza problemi.

Formazione

Assicurati che tutto il personale coinvolto abbia ricevuto una formazione adeguata.

Consulta Adobe Experience Manager nel catalogo dei corsi.

Amministratori con formazione

Assicurati che gli amministratori della soluzione abbiano:

• Ricevuto una formazione
• Ricevuto materiale di formazione adeguato
• Ricevuto la documentazione appropriata

Utenti con formazione

Assicurati che gli autori abbiano:

• Ricevuto una formazione
• Ricevuto materiale di formazione adeguato
• Ricevuto la documentazione appropriata, ad esempio la Guida utente

Test di penetrazione

I test di penetrazione simulano un attacco a un sistema informatico per identificare potenziali punti deboli nella sicurezza.

Test di penetrazione/sicurezza

Per garantire la sicurezza della soluzione, esegui test di penetrazione specifici oltre a una gamma più ampia di test sulla sicurezza.

Per ulteriori dettagli, consulta l’elenco di controllo della sicurezza.

Preparazione

La preparazione e la pianificazione contribuiranno a garantire una pubblicazione senza intoppi.

Sicurezza

Conferma la sicurezza della soluzione per gli utenti interni ed esterni e per i relativi contenuti.

Regresso

Assicurati che tutti i sistemi, le procedure e i meccanismi necessari per il regresso siano operativi prima della pubblicazione.

Supporto

Assicurati che i servizi di supporto siano pronti a intervenire.

Transizione

Pianifica ed esegui la transizione all’ambiente e agli utenti di produzione.

Rollout

Prepara ed esegui gli smoke test.

Responsabile della redazione/presentazione del caso di business del progetto.

Essenziale per plasmare e definire l’ambito del progetto, compresi:

• la definizione e i criteri della buona riuscita
• i KPI principali

Fornisci i milestone principali in base alla roadmap del client.

È principalmente responsabile della raccolta e dell’analisi dei requisiti di alto livello, per poi trasformarli in specifiche:

• per il project manager affinché li utilizzi durante la pianificazione dello sviluppo
• per il team di sviluppo affinché possa lavorarci durante la progettazione e lo sviluppo.

Collabora strettamente con il client per analizzare i requisiti. Questi requisiti vengono confrontati con:

• La definizione di buona riuscita.
• I criteri per la buona riuscita.
• KPI (sia aziendali sia basati sulle prestazioni).

È responsabile dell’esecuzione tecnica del progetto.

È responsabile della selezione di una metodologia di sviluppo conforme ai requisiti del client.

Delinea la strategia di sviluppo:

• garantendo l’allineamento con i KPI aziendali e basati sulle prestazioni
• tenendo conto dei criteri di buona riuscita e della definizione

Collabora strettamente con l’architetto (in particolare durante la definizione della strategia di sviluppo per AEM) per definire aspetti quali la relazione tra modelli e componenti, la strategia di integrazione per applicazioni di terze parti ed eventuali funzionalità specializzate.

È responsabile della supervisione dell’infrastruttura del progetto.

È responsabile di:

• configurare gli ambienti interni di sviluppo e di test
• abbinare tali sistemi ai sistemi del client

Fornisce consigli sull’hardware, monitora le varie implementazioni e offre supporto operativo sia prima che dopo la pubblicazione.

Stakeholder

• Persone (spesso dell’azienda) che hanno un interesse (partecipazione) alla buona riuscita del progetto. Spesso contribuiscono al bilancio.

Legale

• Durante la negoziazione dei contratti è richiesta una consulenza legale.

Formatori

• A seconda delle dimensioni e della natura del progetto, i formatori specializzati possono essere utilizzati per sviluppare e presentare sessioni di formazione ai gruppi pertinenti.

Autori di contenuti tecnici

• A seconda delle dimensioni e della natura del progetto, gli autori di contenuti tecnici specializzati possono essere utilizzati per redigere linee guida e manuali per gruppi specifici. Ad esempio, un manuale di manutenzione per gli amministratori di sistema o una guida utente per gli autori di contenuti.

Amministratori di sistema

• Responsabile del funzionamento continuo del sistema.

Autori e utenti finali

• Persone che utilizzano il sistema per creare e gestire il contenuto del sito web.

Altre best practice e linee guida relative alla gestione di un progetto AEM:

• Linee guida per le dimensioni dell’hardware
• DevOps aziendale
• Best practice per la gestione di SEO e URL
• AEM e le Linee guida di accessibilità dei contenuti web
• Regolamento generale sulla protezione dei dati* Implementazione e manutenzione delle best practice

Amministrazione delle best practice

Sviluppo delle best practice

Authoring delle best practice

Documentazione di AEM
Inoltre, le seguenti sezioni della documentazione di AEM sono di particolare interesse (tuttavia, questo elenco non è esaustivo):

• Protezione

• Distribuzioni consigliate

• DevOps aziendale

• Dimensionamento hardware

• Concetti di AEM:

  • Sviluppo: nozioni di base
  • Concetti MSM
  • HTML Template Language (HTL)

Documentazione correlata

• Adobe Experience Cloud: pianificazione per Adobe Experience Cloud