Wondershare EdrawMind
Galleria mappe mentale Revisione agile di PMP
- 7
Revisione agile di PMP
Le conoscenze e i punti di prova relativi allo sviluppo agile vengono compilati prima dell'esame PMP. Il contenuto include la selezione del ciclo di vita del progetto, il Manifesto Agile, i Dodici Principi, il framework Scrum, altri concetti agili e l'analisi dell'agile in base alle 10 principali aree di conoscenza.
Modificato alle 2023-05-18 23:36:51
- Consigliato per te
- Profilo
Revisione agile del PMP
Opzioni del ciclo di vita del progetto
Predittivo
Progetti tradizionali, industrie mature: come l'edilizia, la produzione, l'industria IT
Agile
Iterare
Incremento
Ibrido
L’azienda passa da predittiva ad agile
Le previsioni per i progetti agili sono in parte previsioni e in parte agili
Predizione o agilità, utilizzando la risposta alla domanda come direzione della scelta
Utilizza le parole chiave come domande per distinguere tra agile e predittivo
Cambiamento organizzativo: da predittivo ad agile
Innanzitutto analizzare e valutare la cultura aziendale e l’impatto della trasformazione sull’azienda
Apportare cambiamenti dall’alto verso il basso, coinvolgendo le persone a tutti i livelli dell’azienda per comprendere i vantaggi e gli imperativi del cambiamento
Puoi scegliere un progetto meno complesso come pilota per ottenere un rapido successo e dare fiducia ad altri progetti.
Manifesto Agile
personale
Le interazioni individuali prevalgono sui processi e sugli strumenti
La collaborazione con il cliente prevale sulla negoziazione del contratto
consegna di valore
Il software utilizzabile supera gli archivi completi
Affrontare il cambiamento è meglio che seguire un piano
dodici principi
consegna di valore
Il nostro obiettivo più importante è soddisfare i nostri clienti attraverso la consegna tempestiva e coerente di software di valore
Preparati ad affrontare i cambiamenti nei requisiti, anche nelle fasi avanzate dello sviluppo. I processi agili controllano il cambiamento per il vantaggio competitivo dei clienti
Fornire software funzionante frequentemente, a distanza di poche settimane o un mese o due, favorendo cicli più brevi
Il software funzionante è la misura principale del progresso
personale
Uomini d'affari e sviluppatori devono collaborare tra loro, ogni giorno del progetto
Stimolare lo spirito combattivo degli individui e costruire progetti che abbiano loro al centro. Fornire l’ambiente e il supporto necessari, sostenuti dalla fiducia, per raggiungere gli obiettivi
Sia all’interno che all’esterno del team, il modo migliore e più efficiente per trasmettere informazioni è attraverso conversazioni faccia a faccia.
I processi agili promuovono lo sviluppo sostenibile. Proprietari, sviluppatori e utenti devono essere in grado di lavorare insieme per mantenere un ritmo costante e continuo
L'architettura, i requisiti e i progetti migliori provengono dal team organizzativo
Il team riflette regolarmente su come migliorare le prestazioni e adatta di conseguenza il proprio comportamento
processi
Le capacità agili sono migliorate da una ricerca incessante dell’eccellenza tecnica e del buon design
Debito tecnico e refactoring
Basato sulla semplicità, è l'arte di ridurre al minimo il carico di lavoro non necessario
Quadro di mischia
quadro generale
quadro generale
Visione del prodotto e roadmap del prodotto
Quante versioni sono necessarie per ottenere il prodotto finale?
piano di rilascio
1 versione determina il numero di iterazioni o sprint per un rilascio
pianificazione dello sprint
Punti principali
Carta del progetto Agile
Perché stiamo realizzando questo progetto?
Visione del progetto
chi ne trarrà beneficio
Ciò può far parte della visione del progetto e/o degli obiettivi del progetto
Per questo progetto, quali condizioni sono soddisfatte affinché il progetto sia completato?
Standard di rilascio del progetto
come coopereremo
Flusso di lavoro previsto
Statuto della squadra (Contratto sociale della squadra)
valori della squadra
Come la velocità dello sviluppo sostenibile e l’orario di lavoro principale
contratto di lavoro
Ad esempio, come viene definita la "prontezza", che è il prerequisito affinché il team accetti il lavoro;
Ad esempio, come definire "fatto" in modo che il team possa giudicare in modo coerente la completezza;
Considera il timeboxing
Utilizzare le restrizioni del processo di lavoro
regole di base
Ad esempio, le regole relative a una persona che parla a una riunione
norme di squadra
Ad esempio, il modo in cui i team trattano il tempo delle riunioni
3355
3 caratteri
proprietario del prodotto
team di sviluppo
Maestro di mischia
3 artefatti
Portafoglio prodotti
Arretrato di sprint
incremento del prodotto
5 eventi
Sprint
Riunione di pianificazione dello sprint
Riunione quotidiana in piedi
Riunione di revisione dello sprint
Incontro retrospettivo sullo sprint
5 valori
promettere
messa a fuoco
aprire
rispetto
coraggio
3 caratteri
Proprietario del prodottoPO (Rappresentante del cliente, esperto aziendale)
Mantenere e aggiornare il backlog del prodotto
Il Product Owner è l'unico responsabile della gestione del Product Backlog
Mantenere il backlog del prodotto e stabilire le priorità
Descritto ed espresso chiaramente in modo che il team possa comprendere appieno il Product Backlog
Determinare e approvare se l'incremento del prodotto è stato completato
Determinare se l'incremento del prodotto è completo e soddisfa la definizione di completamento DOD
Centri di test visitati frequentemente
Il PO deve essere a tempo pieno e indipendente e non può essere ricoperto contemporaneamente dal team di sviluppo o dal SM.
Cosa devo fare se i nuovi requisiti cambiano durante il conflitto?
In generale, i nuovi requisiti sono ora sul tavolo PB e hanno la priorità dal PO. Questo requisito di solito non viene soddisfatto in questo sprint.
La domanda enfatizza i requisiti legali e normativi e i requisiti con priorità estremamente elevata. Se non viene completata immediatamente, porterà al fallimento del progetto. In questo caso, l'OP deve generalmente comunicare con il team e riadattare gli obiettivi di questo sprint in modo che il completamento il più presto possibile è legato alla vita o alla morte della domanda del progetto
team di sviluppo
squadra auto-organizzata
Una specialità, molteplici abilità, un team interfunzionale
I membri del team di sviluppo non sono riconosciuti dai loro titoli, sono pur sempre sviluppatori, indipendentemente dal tipo di lavoro che svolgono
È meglio impegnarsi al 100%, formare un team a tempo pieno e superare i silos organizzativi
Segui il sole
Punti di prova comuni
Se ci sono requisiti, ordini o costrizione alla squadra a fare cose in questione, verranno eliminati direttamente.
Il team di sviluppo decide ed è responsabile della stima delle storie degli utenti, dell'assegnazione del lavoro, ecc.
Maestro di mischia Conosciuto anche come allenatore agile, facilitatore di squadra, Scrum Master, Project Manager
Garantire che l'intero team Agile e le parti interessate seguano le teorie, le pratiche e le regole di Scrum
Per PO
Assicurarsi che comprenda le responsabilità lavorative del PO, compreso come mantenere e aggiornare la tabella PB
Per il team di sviluppo
Garantire che possa seguire eventi agili quotidiani, come riunioni quotidiane in piedi, e utilizzare strumenti trasparenti, ecc.
Per l'esterno del progetto
Assicurati di comprendere le pratiche agili. Ad esempio, se hai bisogno di comprendere i progressi, puoi guardare la fonte di emissione delle informazioni. Se hai bisogno di comprendere la priorità delle storie degli utenti, puoi comunicare con l'OP, ecc.
Leadership al servizio, leadership al servizio, focalizzata sulla crescita del team e sull'aiutare il team a eliminare gli ostacoli
barriere interne
Quando il team di sviluppo incontra problemi tecnici, di processo o di altro tipo, aiuta a risolverli anziché risolverli da solo.
ostacoli esterni
SM negozia e comunica con parti esterne
Punti di prova comuni
In un ambiente agile, SM non è responsabile dell’assegnazione specifica del lavoro, delle modalità di lavoro, ecc.
Generalmente, l’SM è responsabile dell’eliminazione di alcuni fattori esterni e ostacoli che interferiscono con il team.
3 artefatti
Portafoglio prodotti. Portafoglio prodotti
storie degli utenti
concetto
Come <ruolo>, desidero la <funzionalità> in modo che il <valore> possa essere raggiunto
Principio di INVESTIMENTO
Indipendente
Negoziabile
Prezioso
Stimabile (valutabile)
Piccolo
Testabile
punto della storia
Come standard di riferimento interno, utilizzato all'interno del team. Confrontare il numero di story point tra diversi team non ha senso
Stimare i punti della storia dell'utente
Pianificazione del poker (Delphi a banda larga)
Vantaggi dell'utilizzo dell'Agile Estimation Poker
Promuovere la comunicazione tra i membri del team per condividere e apprendere maggiori informazioni
La discussione e la valutazione dei risultati della stima da parte del team renderanno i risultati della stima più reali e oggettivi ed eviteranno molte decisioni eccessivamente arbitrarie.
Si applica a una storia utente specifica o a tutte le storie utente utilizzate in un'iterazione
Stima dell'affinità
Si applica all'intera tabella PB, stima complessiva approssimativa
Contiene contenuto
Elenca tutte le caratteristiche, le funzioni, i requisiti, i miglioramenti e le correzioni che modificheranno il prodotto per le versioni future
Secondo una sequenza di priorità da alto a basso, alto valore e alto rischio > alto valore e basso rischio > basso valore e basso rischio
Gli elementi del Product Backlog di livello più alto sono più chiari, più specifici, conformi al DOR e richiedono uno sviluppo immediato
Aggiornamenti dinamici continui, dettagli progressivi
Il proprietario del prodotto è responsabile
Arretrato di sprint Arretrato di sprint
Spostare le storie degli utenti ad alta priorità dall'elenco PB allo Sprint Backlog In questo sprint, il team decide quante storie realizzare e perfeziona le storie degli utenti.
sondare/sondare
Principalmente per ottenere conoscenze di base per sapere se un determinato requisito è tecnicamente fattibile o meno. Questo metodo viene solitamente utilizzato quando le storie degli utenti non possono essere stimate in modo efficace.
Includere almeno un miglioramento del processo ad alta priorità identificato in una precedente riunione retrospettiva
Il team di sviluppo è responsabile e il PO risponderà alle domande.
Incremento prodotto Incremento prodotto
Colpire la definizione di DOD standard "fatto".
Il product Owner decide se viene completato o meno. Indipendentemente dal fatto che venga rilasciato o meno, l'incremento deve essere disponibile e continuamente integrato.
5 eventi
Sprint
Tradotto come "sprint" o "iterazione"
Durata 2-4 settimane (orario fisso), 5-9 persone
Precauzioni
Non è possibile apportare modifiche dannose per lo Sprint Goal
Obiettivi che non possono compromettere la qualità
Solo il Product Owner ha il potere di annullare gli Sprint Poiché gli Sprint sono molto brevi, l'annullamento ha poca importanza.
Riunione di pianificazione dello sprint
fare un piano
Cosa dovrebbe essere incluso nell’incremento fornito nel prossimo Sprint?
Come eseguire il lavoro richiesto per fornire l'incremento
Precauzioni
Spetta al team di sviluppo decidere quanti elementi del product backlog scegliere
Il Product Owner può aiutare a spiegare le storie degli utenti selezionati e a trovare dei compromessi
Partecipanti
In generale, il SM, il team di sviluppo e il PO partecipano congiuntamente e possono essere invitati a partecipare anche importanti stakeholder.
Riunione quotidiana in piedi
Contenuti della conferenza
Ieri
Cosa ho fatto per aiutare il Team di Sviluppo a raggiungere lo Sprint Goal
Oggi
Cosa farò per aiutare il team di sviluppo a raggiungere il proprio Sprint Goal?
Ci sono ostacoli che impediscono a me o al team di sviluppo di raggiungere lo Sprint Goal?
Dopo l'incontro, aggiornare le fonti di informazione sulle emissioni (schede, grafici dei burndown, tabelle dei gas, ecc.) e le schede dei problemi
Precauzioni
Registrare solo i problemi invece di discuterli. Dopo l'incontro, il personale specializzato può condurre un incontro per la risoluzione dei problemi.
Il SM deve essere tenuto nello stesso orario e nello stesso luogo. Generalmente si consiglia ai membri del team di ospitarlo. La durata è solitamente di 15 minuti.
Punti di prova comuni
Le riunioni quotidiane in piedi possono immediatamente seguire i progressi e apportare correzioni
Le riunioni quotidiane possono impedire che lo stesso lavoro venga ripetuto da membri diversi
Capacità di rilevare problemi e rischi in modo tempestivo e apportare miglioramenti tempestivi dopo la riunione per ridurre al minimo l'impatto dei rischi sul progetto
Partecipanti
Team di sviluppo (SM, PO, stakeholder importanti a seconda dei casi)
Riunione SOS (Scrum of Scrums)
Riunione di revisione dello sprint Riunione di revisione
Esamina gli incrementi del prodotto e ottieni feedback
Il team di sviluppo dimostra l'incremento del prodotto, l'OP invita le parti interessate a partecipare e l'OP determina se l'incremento del prodotto è stato completato.
Adeguare il backlog del prodotto
Articolare gli elementi del Product Backlog che probabilmente entreranno nel prossimo Sprint
Il risultato dello Sprint Review meeting è un Product Backlog rivisto
Partecipanti
cliente
partiti importanti
P.O
SM
team di sviluppo
Incontro retrospettivo sullo Sprint Incontro retrospettivo
Esaminare cosa è andato bene e cosa necessita di miglioramento, e inserire ciò che necessita di miglioramento nel prossimo Sprint per dare seguito (miglioramento continuo)
Partecipanti
SM
team di sviluppo
PO (soggetto a disponibilità)
5 valori
promettere
Disponibilità a impegnarsi per obiettivi
messa a fuoco
Metti la tua mente e le tue capacità nel lavoro che ti sei impegnato
aprire
Scrum rende tutto nel progetto accessibile a tutti
rispetto
Ognuno ha il suo background e la sua esperienza unici
coraggio
Abbi il coraggio di fare promesse, mantenerle e accettare il rispetto degli altri
Altri concetti agili
Gestione Kanban
Flusso di lavoro visivo
È possibile creare una lavagna e alcune carte
Eliminare i colli di bottiglia
Restrizioni WIP (Work In Progress) sui lavori in corso
Punti di prova comuni
La domanda menzionava che il flusso di lavoro del progetto è caotico, causando il blocco di alcuni processi. La gestione Kanban può risolvere efficacemente questo problema.
La domanda menziona che altri processi o procedure stanno procedendo senza intoppi, ma solo un processo incontra un collo di bottiglia, causando un ritardo nell'avanzamento dell'intero processo. Puoi prendere in considerazione l'assegnazione di membri del team interfunzionali da altri processi all'intero processo del collo di bottiglia.
MVP (prodotto minimo vitale)
Crea rapidamente un set minimo di funzionalità che soddisfino le funzionalità previste del prodotto, contengano funzionalità sufficienti per soddisfare i requisiti di distribuzione del prodotto e convalidare i presupposti chiave sull'interazione del cliente con il prodotto
Sperimenta con il minor numero di risorse e il minor tempo possibile per ottenere feedback dai primi utenti
Punti di prova comuni
Se i clienti non riescono a determinare chiaramente le proprie esigenze, possono costruire un prototipo preliminare del prodotto e, infine, soddisfare le esigenze dei clienti attraverso feedback e correzioni successivi.
Quando il mercato è incerto o i rischi sono elevati, utilizza gli esperimenti di progettazione MVP per verificare rapidamente se il tuo prodotto o la tua direzione sono fattibili.
Uno sguardo agile secondo le 10 principali aree di conoscenza
Integrare
Delegare al team il controllo della pianificazione e della consegna di prodotti specifici. I membri del team decidono come pianificare e integrare
L'obiettivo del project manager è creare un ambiente decisionale collaborativo e garantire la capacità del team di rispondere ai cambiamenti
Non esiste un processo di controllo del cambiamento in Agile.
scopo
I metodi agili creano e rivedono intenzionalmente prototipi e chiariscono i requisiti attraverso più versioni. In questo modo, l’ambito viene definito e ridefinito durante tutto il progetto
Definire l'ambito prima di ogni sprint
Riunione di Sprint Planning e Sprint Backlog
Conferma l'ambito prima della fine di ogni sprint
Riunione di revisione dello Sprint e approvazione dell'incremento del prodotto
programma
La relazione tra visione del prodotto, pianificazione del rilascio e pianificazione dell'iterazione
Programma iterativo con elementi non finiti
Si tratta di una pianificazione continua basata sul ciclo di vita adattivo. Questo approccio richiede che i requisiti siano documentati nelle storie degli utenti, quindi alle storie degli utenti viene assegnata la priorità e perfezionate prima di essere create e infine le funzionalità del prodotto vengono sviluppate entro un periodo di tempo definito. Questo approccio viene generalmente utilizzato per fornire valore incrementale alle interazioni con i clienti o per consentire a più team di sviluppare in parallelo un gran numero di funzionalità meno interconnesse.
programma su richiesta
Tipicamente utilizzato nei sistemi Kanban, basati sulla teoria dei vincoli e sul concetto di pianificazione pull della produzione snella, per limitare il lavoro svolto dal team in base alla sua capacità di consegnare. L'approccio di pianificazione su richiesta non si basa su pianificazioni specificate in precedenza per lo sviluppo del prodotto o gli incrementi del prodotto, ma attinge invece dagli elementi del backlog e dalle sequenze di lavoro non appena le risorse diventano disponibili.
Controllare gli strumenti di avanzamento
Sorgente di emissione di informazioni
bruciare il grafico
Grafico di accensione
costo
Utilizzare metodi di stima leggeri
Stime dettagliate sono adatte per la pianificazione a breve termine utilizzando il just-in-time
qualità
Pianificare la gestione della qualità
Definizione di DOD
Gestire e controllare la qualità
Revisione ciclica, controllo regolare dell'efficacia del processo di qualità, individuazione delle cause profonde dei problemi e implementazione di nuovi metodi di miglioramento della qualità
Concentrarsi su piccoli lotti e poter effettuare consegne frequenti
Sviluppo guidato dai test (TDD), integrazione continua
risorsa
Approfitta delle strutture dei team che massimizzano la concentrazione e la collaborazione, come i team auto-organizzati con generalisti
comunicare
Cerca di semplificare i canali attraverso i quali i membri del team possono ottenere informazioni, condurre frequenti controlli del team e consentire ai membri del team di lavorare insieme
Ufficio centralizzato
Lavoro quotidiano: riunione quotidiana in piedi
Gli artefatti del progetto devono essere pubblicati in modo trasparente e le parti interessate devono essere regolarmente invitate a rivedere gli artefatti del progetto
Lavoro quotidiano: fonti di emissioni di informazioni
Reporting e comunicazione: Sprint Review Meeting
squadra virtuale
finestra dell'acquario
Stabilire un collegamento per videoconferenza a lungo termine
accoppiamento remoto
Condividi il tuo schermo utilizzando strumenti per riunioni virtuali, inclusi collegamenti vocali e video
rischio
I rischi dovrebbero essere considerati quando si pianificano le iterazioni
I rischi dovrebbero essere identificati, analizzati e gestiti durante le iterazioni
I documenti sui requisiti dovrebbero essere aggiornati regolarmente sulla base di una maggiore comprensione delle attuali esposizioni al rischio e la ridefinizione delle priorità del lavoro man mano che il progetto avanza
acquistare
Potrebbe richiedere la collaborazione con venditori specifici per espandere il team. Questo rapporto di collaborazione crea un modello di approvvigionamento a rischio condiviso in cui acquirenti e venditori condividono i rischi e i benefici del progetto.
accordo flessibile
struttura multistrato
accordo quadro
Accordo supplementare
parti interessate
Promuovere un elevato grado di trasparenza
Ad esempio, invitando tutte le parti interessate a partecipare a riunioni e revisioni del progetto o pubblicando gli artefatti del progetto in uno spazio pubblico, con l'intento che incoerenze e dipendenze tra le parti o altre questioni relative a un progetto in continua evoluzione emergano il più rapidamente possibile .
I progetti altamente mutevoli richiedono un’interazione e una partecipazione efficaci da parte delle parti interessate del progetto. Per consentire discussioni e decisioni tempestive ed esilaranti, i team adattivi interagiscono direttamente con le parti interessate anziché passare attraverso livelli di gestione