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

Un checklist interattiva che consente di monitorare e monitorare i progressi con queste best practice.

• Definisce gli input e i risultati finali in base a fase, cardine e tipo.
• Fornisce panorami automatizzati (qualità, integrità e completezza) per indicare il progresso e lo stato di salute del progetto.

Documentazione, basata direttamente sul elenco a discesa, che descrive in dettaglio:

• Heartbeat progetto analisi.
• Stato per ruolo panoramica.
• Fasi e tappe fondamentali.
• Persona chiave e il loro coinvolgimento in ogni fase (pertinente).
• A Glossario del Documenti richiesti e risultati finali.

Ulteriore riferimento materiale per fornire maggiori dettagli su aree specifiche.

Qualità fase

• Indica la qualità del Documenti richiesti e risultati finali in tutto il progetto.

Salute a fase

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

Completamento fase

• In qualsiasi momento del progetto, indica il livello di completamento per ogni fase del progetto.

Motivazione aziendale

• Le ragioni e le motivazioni fondamentali per l'esecuzione del progetto.

Ambito e programma

• È opportuno mettere a disposizione un ambito di applicazione di base e un calendario approssimativo per definire ciò che è necessario e entro quale arco di tempo; se aiuta a chiarire la situazione, puoi anche definire cosa si trova al di fuori dell’ambito.

Convalida

In questa fase è necessario convalidare e confermare gli obiettivi del progetto; ad esempio:

• Cosa desideri ottenere/fornire?

• Chi ne beneficerà?

• Qual è il campo di applicazione?

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

• Come definirai il successo?

• Come misurerai il successo?

  • Quali sono i requisiti, aziendali e tecnici?
  • Esistono sistemi legacy da sostituire e, in caso affermativo, esistono dati da migrare?
  • Chi sarà coinvolto?
  • Come misurerai il progresso?
  • Con quale frequenza esaminerai i progressi compiuti durante la durata del progetto?

Bilancio

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

• Utilizzare le informazioni del cardine di convalida come base per le stime.
• Siate realistici nelle vostre stime.
• Valuta e rispetta tutte le linee guida, i processi o le restrizioni dei clienti a cui il cliente può essere soggetto.
• Valutare i processi di contingenza e di revisione nel caso in cui sia necessaria una revisione o un perfezionamento del budget in una fase successiva.
• Ricordate che i costi si presentano in molte forme; acquisti, utilizzo di risorse e commissioni, tra l'altro.

Consegna

Un cambio di consegna sicuro assicura che l’utente/i gruppi appropriati siano consapevoli delle proprie responsabilità all’interno del progetto.

Devono essere forniti/generati dettagli completi per garantire una piena comprensione di tutti gli aspetti pertinenti, compresi la roadmap, l’ambito, gli obiettivi, i requisiti e i KPI.

Valutazione del rischio

Per evitare sorprese sgradevoli, utilizzare la valutazione del rischio per identificare e quantificare eventuali rischi potenziali insieme al loro impatto e alla loro probabilità.

Ciò dovrebbe essere fatto all'inizio del ciclo di vita del progetto per garantire che le eventuali variabilità siano individuate e valutate. Sulla base dei risultati puoi riferire alle parti interessate se è possibile implementare tutti i requisiti e, se necessario, se è possibile pianificare azioni appropriate da intraprendere e monitorate.

Comunicazione

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

• Lavorare verso gli stessi obiettivi fondamentali
• Dalla stessa base di informazioni
• Con gli stessi canali

Spegnimento

L'incontro Kick Off è usato per sensibilizzare l'opinione pubblica sull'inizio del progetto. Si tratta di una buona opportunità per:

• invitare tutte le parti interessate (o almeno i rappresentanti del gruppo).
• Presentare i fatti chiave sul progetto.
• Rispondi alle domande.
• Assicurati che tutti abbiano la stessa base di conoscenze.
• Ottenere l'impegno da tutti coloro che saranno coinvolti - questo dovrà essere guadagnato.
  • Coinvolgendo i primi giocatori (inclusi i potenziali autori) all'inizio del progetto, aumenta le possibilità di ottenere il loro impegno per il progetto.

Team di Sviluppo Personalizzato e Formato

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

Architettura dei contenuti

L'architettura dei contenuti definisce e descrive la futura architettura dei contenuti; compresi:

• Struttura del contenuto; incluse le risorse
• Strutture di base; incluse le campagne, ecc.
• Strutture multisito e multilingue (MSM, traduzione, ecc.)
• Contenuto supportato (compresi tag e concetti di assegnazione tag)
• Strategie di memorizzazione nella cache e di riutilizzo dei contenuti

Architettura del sistema

L'architettura del sistema definisce la vista concettuale del sistema; tra cui (tra l'altro):

• Struttura del sistema per tutti gli ambienti richiesti
• Sottosistemi
• Sistemi di terze parti
• Interfacce; hardware, software e interazione umana
• Server per ogni ambiente; vedi Requisiti tecnici e Linee guida per il dimensionamento dell'hardware
• Processi per ciascun ambiente; ad esempio, requisiti di distribuzione e manutenzione
• Attività di manutenzione (GC Datastore, ottimizzazione TarPM, ecc.)
• 🔗Memorizzazione in cache di Dispatcher
• Clustering Pubblica/Condividi autore
• Prestazioni lato client (minimizzazione JS, concat, sprites css, numero totale di richieste http e altre)

Architettura dell'applicazione

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

Si concentra su:

• Come interagiranno tra loro e con gli utenti.
• I dati da consumare e produrre dalle applicazioni, anziché la loro struttura interna.

Le definizioni dovrebbero riguardare:

• Struttura del codice di base per il progetto
• Artefatti di codice (bundle, pacchetti, ecc.)
• Suddivisioni dei modelli/componenti e delle loro relazioni
• Dettagli di alto livello sulle personalizzazioni richieste (in seguito verranno visualizzate sovrapposizioni specifiche)
• Progettazione di flussi di lavoro richiesti dalla soluzione (ad esempio, creazione di contenuti, approvazione, pubblicazione, trasformazioni, importazioni, esportazioni, ecc.)
• Considerazione speciale per tutti i moduli complessi, ad esempio MSM, Commerce, integrazione di terze parti

Integrazione di sistema

L’integrazione del sistema richiede la pianificazione (e quindi l’implementazione):

• Come tutti i sottosistemi e integrazioni di soluzioni sarà riunito per funzionare come un unico sistema coerente
• Come verranno integrati i sistemi di terze parti; insieme a qualsiasi considerazione particolare, ad esempio offline/online, lato client/lato browser o gestione del failover quando un sistema di terze parti è inattivo

Concetto di prova

Prima di iniziare lo sviluppo è necessario elaborare un concetto approfondito e completo di tutti test requisiti del progetto.

Ciò dovrebbe includere (tra l'altro):

• Dettagli di tutte le prove da eseguire
• Preparazione del contenuto necessario per tali test
• Informazioni su eventuali strumenti di prova da utilizzare
• indicazione ad alto livello di chi sarà coinvolto nelle prove; specialmente i gruppi esterni al team QA
• 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 soluzione.

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

Configurazione del supporto

Prima di sviluppare tutti i processi di supporto, necessari per distribuire, rilasciare, testare e segnalare i problemi, devono essere impostati.

Vedi anche Adobe Support Portal.

Autorizzazioni

Devi 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 read/ write definizioni di accesso per ogni
• Definizione dell'uso dei privilegi che interessano l'ambiente di pubblicazione; ad esempio, replicate
• Per gli utenti con privilegi minimi, è necessario definire i flussi di lavoro
• Utenti nel editor il gruppo non deve avere admin i diritti e non far parte del administrators gruppo

Per ulteriori informazioni, consulta Amministrazione degli utenti e sicurezza.

Monitoraggio e manutenzione

Il monitoraggio e la manutenzione sono aspetti fondamentali per garantire il funzionamento ottimale della soluzione una volta che questa è attiva. A questo scopo è necessario definire:

• Che cosa richiede il monitoraggio
• compiti di manutenzione; sia regolari che per casi speciali

Vedi anche Monitoraggio e manutenzione per ulteriori informazioni.

Migrazione

Eventuali contenuti del sistema legacy devono essere rivisti e convalidati per la migrazione.

Piano di ripristino

Assicurati di disporre di un piano di ripristino. In una situazione di emergenza ciò deve essere disponibile per garantire l'uso della produzione di AEM. Questo dovrebbe coprire situazioni quali 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; come Jira
    • un IDE; come Eclipse
    • uno strumento di gestione della costruzione; come Maven
    • uno strumento di integrazione continua; come Jenkins
    • uno strumento per il controllo della versione; come GIT/SVN
    • un gestore dell’archivio degli artefatti; come Archiva/Nexus

• Integrazione/dipendenze di software di terze parti

• Integrazione/dipendenze della soluzione

• Frequenza di distribuzione

Sistema di prova

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

• Architettura
• Dipendenze dalle costruzioni di sviluppo; incluse le build notturne
• Possibilità o limitazioni di test dell'integrazione/dipendenze di software di terze parti
• Strumenti di test
• Strategia di test automatizzata

Sistema di produzione

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

• Architettura
• Frequenza di distribuzione
• Integrazione/dipendenze di software di terze parti
• Configurazione della sicurezza
• Prestazioni della linea di base verificate mediante l’esecuzione di Test giornalieri difficili sulla configurazione di produzione
• Requisiti per le prove di prestazione; vedere Best practice per la garanzia della qualità

Integrazione

Pianificare, documentare e testare tutti gli aspetti del sistema e integrazione delle soluzioni, tra cui:

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

Migrazione

Pianificare, documentare e testare tutti gli aspetti della migrazione dei contenuti; compresi:

• Architettura dei contenuti
• Strategia di migrazione

Comunicazione

Assicurati che tutti i membri del team e l’utente tipo del progetto siano aggiornati in base alle esigenze.

Documentazione.

Documentare pienamente la soluzione; compresi:

• Manuale operativo
• Eventuali personalizzazioni che possono influenzare gli aggiornamenti
• Note sulla versione

Test di accettazione da parte dell'utente finale

Test di accettazione degli utenti (UAT) è fondamentale per garantire che:

• La soluzione soddisfa i requisiti utente/cliente
• I clienti/utenti accettano la soluzione (funzione, progettazione e prestazioni)

Dovrebbe essere prevista una lista di controllo ufficiale per la consegna del cliente; idealmente automatizzato ed eseguito su base notturna contro un'istantanea. I risultati devono essere inviati al project manager e al team di sviluppo

Test di prestazioni e di carico

I test di prestazione e carico sono utilizzati per garantire che la soluzione soddisfi i livelli di prestazioni richiesti, in media e nei carichi di picco.

Per ulteriori informazioni sui test delle prestazioni, vedi:

• Test delle prestazioni
• Come pianificare ed eseguire i test
• Linee guida sulle prestazioni di base

Preparazione

La preparazione e la pianificazione contribuiranno a garantire un rollout uniforme.

Formazione

Assicurare che tutto il personale coinvolto sia stato formato.

Vedi Adobe Experience Manager nel catalogo dei corsi.

Amministratori formati

Assicurati che gli amministratori delle soluzioni abbiano:

• Formati
• Ricevuto materiale di formazione adeguato
• Ricevuta la documentazione appropriata

Utenti formati

Assicurati che gli autori abbiano:

• Formati
• Ricevuto materiale di formazione adeguato
• ha ricevuto la documentazione appropriata; ad esempio, la Guida utente

Test di penetrazione

I test di penetrazione simulano un attacco su un sistema informatico per identificare potenziali carenze di sicurezza.

Test di penetrazione/sicurezza

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

Consulta la sezione Lista di controllo sicurezza per ulteriori dettagli.

Preparazione

La preparazione e la pianificazione contribuiranno a garantire un buon Go Live.

Sicurezza

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

Regresso

Assicurati che tutti i sistemi, le procedure e i meccanismi necessari per il fallback siano in atto prima di iniziare il ciclo di vita.

Assistenza

Assicurati che i servizi di supporto siano in-place e pronti.

Transizione

Pianifica ed esegui la transizione al tuo ambiente di produzione e agli utenti.

Uscita

Prepara ed esegui i test di fumo.

Responsabile della fornitura/presentazione del business case per il progetto.

La definizione e la definizione della portata del progetto; compresi:

• la definizione e i criteri del successo
• KPI principali

Fornisci le tappe principali in base alla roadmap del cliente.

È principalmente responsabile della raccolta e dell'analisi dei requisiti di alto livello, trasformandoli poi in specifiche:

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

Lavora a stretto contatto con il cliente per analizzare i requisiti. I loro punti di corrispondenza sono:

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

È responsabile della fornitura tecnica del progetto.

È responsabile della selezione di una metodologia di sviluppo conforme ai requisiti dei clienti.

Elaborare la strategia di sviluppo:

• garantire l’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 quando elabora la strategia di sviluppo per 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:

• configurazione di ambienti di sviluppo e test interni
• per la corrispondenza di tali sistemi ai sistemi client

Fornisce consigli hardware, controlla le varie implementazioni e fornisce supporto operativo sia prima che dopo.

Parti interessate

• Persone (spesso provenienti dal mondo degli affari) che hanno un interesse (partecipazione) nel successo del progetto. Spesso contribuiscono al bilancio.

Legale

• È necessaria una consulenza legale quando si negoziano i contratti.

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 interessati.

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

• Le persone che utilizzeranno 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 (Search Engine Optimization) e URL
• Linee guida sull’accessibilità dei AEM e dei contenuti web
• Regolamento generale sulla protezione dei dati

Best practice di distribuzione e manutenzione

Best practice di amministrazione

Best practice per lo sviluppo

Best practice di authoring

Documentazione AEM

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

• Sicurezza

• Implementazioni consigliate

• DevOps aziendale

• Ridimensionamento hardware

• Concetti di AEM:

  • Sviluppo - Nozioni di base
  • Concetti MSM
  • Linguaggio dei modelli di HTML (HTL)

Documentazione correlata

• Adobe Experience Cloud - Pianificazione per Adobe Experience Cloud