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

Un elenco di controllo interattivo che consente di monitorare e monitorare l'avanzamento con queste best practice.

• Definisce gli input e i risultati finali in base a fase, milestone e persona.
• Fornisce panoramiche automatizzate (qualità, integrità e completezza) per indicare lo stato di avanzamento e l’integrità del progetto.

Documentazione basata sulla lista di controllo che descrive:

• Analisi Project Heartbeat.
• Panoramica di Stato per ruolo.
• Fasi e attività cardine.
• Persona chiave e il loro coinvolgimento in ogni fase (rilevante).
• Glossario dei Documenti e risultati finali richiesti.

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

Qualità fase

• Indica la qualità dei documenti e risultati finali 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 questo indica quanto è già stato completato per ogni fase del progetto.

Motivazione 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 e entro quale intervallo di tempo; 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 desideri ottenere/fornire?

• Chi ne trae vantaggio?

• Qual è l'ambito di applicazione?

  • Se aiuta a chiarire la situazione, puoi anche definire cosa si trova al di fuori dell’ambito.

• Come si definisce 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 vengono esaminati i progressi compiuti nel corso del progetto?

Budget

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

• Utilizzare le informazioni della fase cardine di convalida come base per le stime.
• Sii realistico nelle tue stime.
• Considera e rispetta tutte le linee guida, i processi o le restrizioni per il cliente a cui è soggetto.
• Prendere in considerazione i processi di contingenza e di revisione se successivamente è necessario rivedere o perfezionare il budget.
• 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 tabella di marcia, l'ambito di applicazione, gli obiettivi, i requisiti e i KPI.

Valutazione dei rischi

Per evitare spiacevoli sorprese, utilizzare 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 tracciamento 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 di inizio è usato per aumentare la consapevolezza che il progetto sta iniziando. Si tratta di una buona opportunità per:

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

• Presentare i fatti chiave del progetto.

• Rispondi alle domande.

• Assicurati che tutti abbiano la stessa knowledge base.

• Ottieni l'impegno di tutti coloro che saranno coinvolti - questo dovrà essere guadagnato.

  • Coinvolgendo i protagonisti (inclusi i potenziali autori) fin dall'inizio del progetto, aumentate le possibilità di ottenere il loro impegno 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 addestrati per l'attività in corso.

Architettura dei contenuti

L’architettura del contenuto 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; vedere 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

• Clustering Publish/Authorshare

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

Architettura applicazione

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

Si concentra su:

• Come 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 di sistema

L’integrazione del sistema 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 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 testing per il tuo progetto.

Ciò dovrebbe includere (tra l'altro):

• Dettagli di tutte le prove da eseguire
• Preparazione di qualsiasi contenuto necessario per tali prove
• Informazioni sugli strumenti di prova 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 modalità Selenium o AEM Developer

Progettazione esperienza

Experience Design (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 supporto

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

Consulta anche Adobe Support Portal.

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

• 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, vedere 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, vedere anche Monitoraggio e manutenzione.

Migrazione

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

Piano di ripristino

Assicurarsi di disporre di un piano di ripristino. In caso di emergenza, tali informazioni devono essere messe a disposizione per garantire l’uso dell’AEM in produzione. Questo dovrebbe riguardare situazioni come backup, ripristino, fallover 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 di distribuzione

Sistema di prova

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 di distribuzione
• Integrazione/dipendenze software di terze parti
• Impostazione della sicurezza
• Prestazioni della linea di base verificate eseguendo i test del giorno difficile nella configurazione di produzione
• Requisiti per i test delle prestazioni; consulta Best practice per il controllo 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 a test e sviluppo

Migrazione

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

• Architettura dei contenuti
• Strategia di migrazione

Comunicazione

Se necessario, assicurati che tutti i membri del team e la persona del progetto siano tenuti aggiornati.

Documentazione

Documentare 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 soddisfa le esigenze di utenti e clienti
• Il cliente/gli utenti accettano 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 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, vedere:

• Test delle prestazioni

• Pianificare ed eseguire i test

• Linee guida sulle prestazioni di base

Preparazione

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

Corso di formazione

Assicurare che tutto il personale coinvolto sia stato formato.

Vedi Adobe Experience Manager nel catalogo dei corsi.

Amministratori formati

Assicurati che gli amministratori della soluzione dispongano di:

• È stato addestrato
• Ha ricevuto il materiale di formazione appropriato
• Ricevuta la documentazione appropriata

Utenti formati

Assicurati che gli autori abbiano:

• È stato addestrato
• Ha ricevuto il materiale di formazione appropriato
• Ricevuta 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 debolezze di sicurezza.

Test di penetrazione/sicurezza

Per garantire la sicurezza della soluzione, eseguire test di penetrazione specifici e una gamma più ampia di test di sicurezza.

Per ulteriori dettagli, vedere l'elenco di controllo protezione.

Preparazione

La preparazione e la pianificazione contribuiranno a garantire un lancio senza intoppi.

Sicurezza

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

Fallback

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

Supporto

Assicurati che i servizi di supporto siano pronti e pronti.

Transizione

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

Rollout

Preparare ed eseguire le prove di fumo.

Responsabile della redazione/presentazione del business case del progetto.

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

• la definizione e i criteri di successo
• i KPI principali

Fornisci i milestone principali in base alla roadmap client.

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

• per il project manager da utilizzare durante la pianificazione dello sviluppo
• affinché il team di sviluppo possa lavorare da durante la progettazione e lo sviluppo.

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

• La definizione di successo.
• I criteri per il successo.
• KPI (sia aziendali che basati sulle prestazioni).

È responsabile dell'esecuzione tecnica del progetto.

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

Elabora la strategia di sviluppo:

• garanzia di allineamento con i KPI aziendali e prestazionali
• tenendo conto dei criteri di successo e della definizione

Lavora a stretto contatto con l'architetto (in particolare durante l'elaborazione della strategia di sviluppo per l'AEM) per definire aspetti quali la relazione tra modelli e componenti, la strategia di integrazione per applicazioni di terze parti e qualsiasi funzionalità specializzata.

È responsabile della supervisione dell’infrastruttura del progetto.

È responsabile di:

• la configurazione degli ambienti interni di sviluppo e test
• per l'abbinamento di tali sistemi ai sistemi client

Fornisce consigli sull'hardware, monitora le varie implementazioni e fornisce supporto operativo sia prima che dopo il lancio.

Parti interessate

• Persone (spesso provenienti dall’azienda) che hanno un interesse (partecipazione) al successo 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 per i gruppi pertinenti.

Scrittori tecnici

• A seconda delle dimensioni e della natura del progetto, gli autori tecnici specializzati possono essere utilizzati per scrivere 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.

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 il dimensionamento dell'hardware
• DevOps aziendale
• Best practice per la gestione di SEO e URL
• AEM e linee guida per l’accessibilità dei contenuti web
• Regolamento generale sulla protezione dei dati* Implementazione e manutenzione delle best practice

Amministrazione delle best practice

Sviluppo di best practice

Best practice di authoring

Documentazione AEM
Sono di particolare interesse (tuttavia l’elenco non è esaustivo) anche le seguenti sezioni della documentazione AEM:

• Sicurezza

• Distribuzioni consigliate

• DevOps aziendale

• Ridimensionamento hardware

• Concetti di AEM:

  • Sviluppo: nozioni di base
  • Concetti MSM
  • Linguaggio del modello HTML (HTL)

Documentazione correlata

• Adobe Experience Cloud - Pianificazione per Adobe Experience Cloud