Il progetto di gestione del progetto Parte 2: un confronto completo tra Waterfall, DAD, SAFe, LeSS e Scrum@Scale

Panoramica

Nella parte 1 del Project Management Blueprint abbiamo trattato le metodologie di sviluppo software Lean Software Development, Agile, Scrum e Kanban e come fanno risalire le loro radici alla Lean Manufacturing. Queste metodologie sono generalmente implementate a livello di singolo team. Tuttavia, la complessità aumenta man mano che i progetti e i team di progetto diventano più grandi e sono necessari nuovi approcci per essere agili su larga scala.

Nella parte 2, ci addentreremo innanzitutto nel modo in cui i project manager utilizzano la metodologia a cascata, che è il framework più comune per lo sviluppo di software nelle aziende tradizionali. Accanto a ciò, tratteremo i framework più popolari che cercano di incorporare principi agili su scala: Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) e Scrum@Scale.

Cascata

La metodologia a cascata (nota anche come modello del ciclo di vita dello sviluppo del software (SDLC)) è una metodologia più tradizionale in cui lo sviluppo del software passa da una fase all'altra come una cascata. Le fasi non si sovrappongono e hanno criteri di ingresso e uscita specifici per passare da una fase all'altra.

Le sei fasi del ciclo di vita del modello a cascata originale sono:

1. Requisiti: in questa fase, le aspettative e gli obiettivi del progetto vengono definiti e i requisiti vengono analizzati e documentati in modo approfondito, di solito da un analista aziendale. I requisiti vengono rivisti e approvati prima di uscire da questa fase.
2. Design: dopo che i requisiti sono stati approvati, iniziano i lavori per l'architettura e la progettazione del prodotto per soddisfare i requisiti approvati. L'architettura fisica, l'architettura dei componenti, la progettazione del database, i componenti dettagliati, la progettazione dei moduli e altri aspetti della progettazione sono documentati da un architetto o designer di software. Viene quindi riesaminato e approvato prima di iniziare l'attuazione.
3. Implementazione: dopo l'approvazione del progetto, l'implementazione o la codifica del software in base ai requisiti e alla progettazione viene eseguita dagli sviluppatori di software.
4. Verifica: al termine dell'implementazione, il software viene testato dal team di test o QA per garantire che i requisiti e la progettazione siano soddisfatti e che venga raggiunto il livello di qualità desiderato. I difetti vengono trovati, registrati, classificati e, in molti casi, risolti.
5. Rilascio e manutenzione: una volta completati i test e il debug, il prodotto viene rilasciato al client e installato. Spesso, si verifica un ciclo di test per garantire che l'installazione sia andata a buon fine. Dopo che il prodotto è stato consegnato, la manutenzione e il supporto continui hanno luogo per garantire che il prodotto continui a funzionare come previsto.

Vantaggi della cascata

Ci sono alcuni vantaggi a cascata ed è adatto a determinati tipi di progetti, ma ci sono anche alcuni seri svantaggi. Waterfall è più adatto a progetti più brevi in ​​cui i requisiti e la tecnologia sono ben compresi e non è probabile che cambino in modo significativo.

Se applicato al giusto tipo di progetto, alcuni dei vantaggi del modello a cascata:

• Semplicità: Waterfall è semplice da implementare grazie all'identificazione anticipata dell'ambito e alle fasi rigide e un chiaro passaggio da una fase all'altra.
• Visibilità: i progressi sono più facilmente misurabili e visti dalle parti interessate poiché l'intera portata del lavoro è nota in anticipo e poiché il progetto passa da una fase all'altra.
• Documentazione: l'ambito, i requisiti e i piani possono essere studiati a fondo e ben documentati, il che rende più facile per i team meno esperti lavorare al progetto.
• Lavoro a fasi: a causa dei ruoli rigidi e della transizione tra le fasi, è possibile che le risorse del progetto lavorino su altri progetti quando la loro fase primaria non è in corso.

Svantaggi della cascata

Waterfall non è adatto per progetti più lunghi in cui i requisiti non sono ben compresi e/o potrebbero cambiare e/o dove vi è un rischio tecnico significativo. Nell'era odierna in cui le condizioni di mercato sono in continua evoluzione e il time-to-market è fondamentale, questo vale per la maggior parte dei progetti software.

Gli svantaggi del modello a cascata, principalmente incentrati sulla sua incapacità di adattarsi al cambiamento, includono:

• Ambito monolitico: premia le parti interessate a pensare a TUTTO quando si definisce l'ambito del progetto, portando a un ambito monolitico.
• Feedback tardivo dei clienti: è difficile per le parti interessate e in particolare per i clienti immaginare l'ambito completo e dettagliato di un progetto. Poiché la cascata espone i clienti ai risultati del progetto principalmente nelle ultime fasi del progetto, diventa inevitabilmente difficile incorporare il feedback dei clienti nel progetto
• Cambiamento dei requisiti: nei progetti più lunghi le condizioni di mercato, e quindi gli obiettivi e i requisiti del progetto, sono a rischio molto elevato di cambiare durante il progetto.
• Valore creato alla fine: Waterfall richiede molto lavoro in anticipo, il che significa che il valore non viene prodotto fino alla fine del progetto.
• Interdipendenza di fase: l'incorporazione di modifiche spesso comporta requisiti e/o rielaborazioni progettuali che possono avere un impatto su altre aree del progetto. La dipendenza delle fasi successive da quelle precedenti può rendere i piccoli cambiamenti nel progetto sproporzionatamente impegnativi.

Consegna agile disciplinata (DAD)

Disciplined agile delivery (DAD) è stato formalizzato da Scott Ambler presso IBM e Mark Lines e amplia i framework agile e scrum, riconoscendo che le parti non agili di un'organizzazione sono solitamente coinvolte in una certa capacità nella fornitura di un progetto software. Questo framework include esplicitamente le attività delle operazioni IT, dell'architettura aziendale, della gestione del portafoglio, della finanza e dell'approvvigionamento nell'intero ciclo di vita della consegna. DAD mira ad aumentare l'agilità complessiva del business in modo pragmatico.

Principi e componenti principali

Ruoli

DAD ha molti più ruoli di Scrum ed è suddiviso in due categorie di ruoli di squadra. I ruoli primari sono ricoperti da persone che lavorano costantemente con il progetto. I ruoli secondari vengono in genere introdotti temporaneamente per aiutare il team con il ridimensionamento o altri problemi. DAD ha questi ruoli aggiuntivi perché affronta l'intero ciclo di vita della fornitura della soluzione e perché riconosce i vari tipi di ruoli temporanei e di supporto necessari che si trovano nel mondo reale

Ruoli primari:

1. Stakeholder: qualcuno che dipende dal tuo team che porta a termine il progetto: cliente, utente finale o collega interno.
2. Membro del team: le persone all'interno del team che svolgono effettivamente il lavoro pianificato: sviluppatori, designer, tester, ecc.
3. Team lead: analogamente allo Scrum Master, il team leader agisce come un servitore-leader per il team rimuovendo gli impedimenti, facilitando la coesione del team e diffondendo valori agili.
4. Proprietario del prodotto: a volte indicato come la "voce del cliente". Il Product Owner rappresenta le parti interessate e mantiene l'elenco prioritario del lavoro che deve essere svolto.
5. Proprietario dell'architettura: responsabile della mitigazione del rischio dell'architettura su larga scala. Questo ruolo è in genere ricoperto da uno sviluppatore senior all'interno del team poiché richiede un background tecnico profondo e una solida conoscenza del dominio aziendale.

Ruoli secondari:

1. Specialista: persone che si uniscono temporaneamente al team per dare una mano in un ruolo specializzato. Ad esempio, un analista di dati può unirsi per fornire capacità di ricerca nelle prime fasi di un progetto.
2. Esperto di dominio: consulenti fiscali, consulenti legali e altre persone che hanno esperienza nel settore e aiutano il team nelle sfide correlate.
3. Esperto tecnico: amministratore di database, esperto di sicurezza build master, ecc. Queste persone aiutano i membri del team più generalizzati nei punti chiave del ciclo di vita.
4. Tester indipendente: mentre i tester di solito fanno parte del team principale, in alcuni casi requisiti normativi o sistemi molto complessi, i tester indipendenti lavorano in parallelo per convalidare il lavoro svolto.
5. Integratore: su larga scala, diversi team stanno lavorando su diverse parti dell'intero sistema. Un integratore aiuta il team a integrare la propria parte con l'intero sistema e gestisce le dipendenze.

Supporto per il ciclo di vita

DAD promuove un ciclo di vita completo della consegna, non solo la parte di programmazione e rilascio coperta da agile/scrum, ma anche la fase iniziale in cui la visione del progetto è definita e approvata e le fasi di supporto e ritiro dopo il rilascio. Attualmente, DAD supporta 6 diversi cicli di vita:

• Il ciclo di vita agile: un ciclo di vita del progetto basato su Scrum
• Il ciclo di vita snello: un ciclo di vita del progetto basato su Kanban
• La consegna continua: ciclo di vita agile
• La consegna continua: ciclo di vita snello
• Il ciclo di vita esplorativo (Lean Startup).
• Il ciclo di vita del programma per un team di team

Questi cicli di vita tengono conto dei diversi stili di lavoro, livelli di agilità aziendale e altre situazioni in cui i team potrebbero trovarsi. Il punto principale è che questi cicli di vita fungono da suggerimenti. DAD promuove il pragmatismo rispetto al purismo poiché ogni situazione è unica e i professionisti agili disciplinati dovrebbero adottare il processo agile in base alle loro esigenze.

Obiettivi del processo

DAD utilizza un approccio basato sugli obiettivi per creare e adattare processi agili. Gli autori di questa metodologia delineano 21 processi più importanti e comuni che la maggior parte dei team dovrà affrontare durante i propri cicli di vita.

Tutti questi processi hanno punti decisionali documentati che richiederanno al team di decidere come strutturare quel processo. Ogni punto decisionale fornisce tecniche o pratiche suggerite che possono essere utilizzate per attuare la decisione. Puoi vedere un esempio di questo nell'immagine qui sotto. Un processo "Sviluppare una visione comune" ha 6 decisioni che dovrebbero essere prese. Ciascuna di queste decisioni ha da 2 a 5 pratiche suggerite. Le frecce indicano che gli autori DAD hanno ordinato l'elenco con l'elemento in alto come la migliore pratica e l'elemento in basso come la peggiore pratica in questo elenco. Il testo _ corsivo in grassetto_ indica buoni punti di partenza per le nuove squadre, che stanno appena iniziando con DAD.

Ridimensionamento di DAD

La consegna agile disciplinata si avvicina al ridimensionamento da due diverse angolazioni:

• Agilità tattica su vasta scala

• Agilità strategica su larga scala

L'agilità tattica cerca di affrontare i fattori di scalabilità del singolo team come le dimensioni, la distribuzione geografica, la complessità del progetto, ecc., attraverso l'applicazione situazionale degli obiettivi del processo e delle pratiche suggerite.

L'agilità strategica cerca di affrontare il ridimensionamento attraverso l'applicazione di strategie agili e snelle in modo ampio nell'intera organizzazione espandendo il framework per affrontare diverse aree dell'organizzazione:

• DevOps disciplinato: copre l'utilizzo di DevOps per fornire risultati più efficaci a un'organizzazione.

• Disciplined Agile IT (DAIT): spiega come applicare strategie agili e snelle a tutti gli aspetti dell'IT.

• Impresa Agile Disciplina:. descrive come applicare lean e agile in un'azienda.

Sicuro

Scaled Agile Framework (SAFe) è il framework Agile scalato più popolare, nonché il più complesso e completo in questo momento. Il 29% degli intervistati nel rapporto annuale sullo stato dell'agile afferma di utilizzare questo framework nelle proprie organizzazioni. A loro volta, ci sono molti project manager SAFe sul mercato.

L'inizio di SAFe è stato il libro di Dean Leffingwell "Scaling Software Agility: Best Practices for Large Enterprises", pubblicato nel 2007. Leffingwell è ora il capo metodologo di SAFe, ma anche molte altre persone contribuiscono a questo framework. Attualmente, nella versione 4.6, questo framework assomiglia a un prodotto software con controllo delle versioni, compatibilità con le versioni precedenti e vari componenti.

Principi e componenti principali

L'obiettivo principale di SAFe è facilitare la creazione e la crescita di un'impresa snella, poiché riconosce che molti diversi tipi di aziende sono, in parte, società di software che devono fornire continuamente valore nel più breve periodo di tempo sostenibile.

SAFe for Lean Enterprises cerca di creare un'impresa snella fornendo una base di conoscenze di comprovati principi, competenze e migliori pratiche.

SAFe 4.6 definisce le Cinque Competenze Core della Lean Enterprise. Ogni competenza è un insieme di conoscenze, abilità e comportamenti correlati, che insieme consentono alle organizzazioni di eccellere:

1. Leadership Lean-Agile : descrive come i leader guidano e sostengono il cambiamento organizzativo attraverso l'apprendimento, l'insegnamento e l'implementazione della mentalità Lean-Agile di SAFe.

2. Team e agilità tecnica : descrive le competenze, i principi e le pratiche necessarie per creare team Agile ad alte prestazioni.

3. DevOps e rilascio su richiesta : descrive come l'implementazione di DevOps e una pipeline di distribuzione continua offra alle organizzazioni la capacità di rilasciare incrementi di prodotto in qualsiasi momento necessario per soddisfare la domanda.

4. Soluzioni aziendali e ingegneria dei sistemi snella : descrive come applicare principi e pratiche agili snelli alla specifica, allo sviluppo, all'implementazione e all'evoluzione di applicazioni software complesse e di grandi dimensioni

5. Gestione snella del portafoglio : allinea la strategia e l'esecuzione applicando approcci snelli e di pensiero sistemico alla strategia e al finanziamento degli investimenti, alle operazioni agili del portafoglio e alla governance.

Ciascuna delle competenze chiave è mappata direttamente al rispettivo livello nel diagramma del processo SAFe, ad eccezione della Lean-Agile Leadership che comprende l'intero processo.

Competenza di leadership agile e snella

L'obiettivo principale della Competenza Leadership Lean-Agile è quello di aiutare a trasformare l'organizzazione in un'impresa agile. Questo viene fatto imparando, praticando e insegnando la mentalità, i valori, i principi e le pratiche Lean-Agile di SAFe.

I valori fondamentali di SAFe guidano la trasformazione verso l'impresa snella. In ogni occasione, il comportamento di un leader gioca un ruolo fondamentale nel promuoverli. I valori fondamentali sono:

1. Allineamento : comunicare la missione, la strategia del portafoglio e la visione della soluzione. Condurre briefing pertinenti e partecipare alla pianificazione dell'incremento del programma (PI) e alla manutenzione del backlog.

2. Trasparenza : Visualizza tutto il lavoro rilevante.

3. Qualità incorporata : impegnarsi in pratiche per fornire qualità durante tutto il ciclo di vita. Rifiuta di accettare lavori di bassa qualità. Sostenere gli investimenti in manutenzione e riduzione del debito tecnico.

4. Esecuzione del programma : Partecipa come imprenditori all'esecuzione di PI e stabilisci il valore aziendale. Assicurarsi che l'ambito sia allineato con la domanda e la capacità. Rimuovere in modo aggressivo impedimenti e demotivatori.

I valori fondamentali di SAFe sono supportati dall'adozione della mentalità Lean-Agile e dall'applicazione dei principi SAFe:

1. Prendi una visione economica

2. Applicare il pensiero sistemico

3. Assumere variabilità; preservare le opzioni

4. Costruisci in modo incrementale con cicli di apprendimento rapidi e integrati

5. Basare le pietre miliari su una valutazione oggettiva dei sistemi di lavoro

   

6. Visualizza e limita il WIP, riduci le dimensioni dei batch e gestisci le lunghezze delle code

7. Applica la cadenza, sincronizza con la pianificazione tra domini

8. Sblocca la motivazione intrinseca dei knowledge worker

9. Decentralizzare il processo decisionale

Questi principi sono simili ai principi Lean e Agile. Infine, la trasformazione dell'organizzazione avviene seguendo la Roadmap di implementazione di SAFe.

Competenza di squadra e agilità tecnica/Livello di squadra

La competenza Team and Technical Agility descrive le abilità, i principi e le pratiche necessarie per creare team agili ad alte prestazioni che creano soluzioni di alta qualità. Due caratteristiche chiave sono fondamentali:

• Agilità del team : i team adottano pratiche e principi Agile, che consentono loro di lavorare, imparare e adattarsi a una cadenza affidabile

• Agilità tecnica : i team applicano pratiche tecniche Agile che garantiscono la qualità del codice e dei componenti e la manutenibilità del codice che producono. Per raggiungere questo obiettivo, vengono applicate tecniche di ingegneria agili come lo sviluppo guidato dal comportamento (BDD) e lo sviluppo guidato dai test (TDD) per aumentare la qualità e il flusso. Il flusso veloce dipende dalla qualità dell'edificio in tutto il sistema poiché gli errori possono influire gravemente sul flusso e ritardare i rilasci.

Il livello di squadra del diagramma SAFe descrive come operano i singoli team Agile. Tutti i team fanno parte dell'Agile Release Train che lavora per fornire un incremento del prodotto. Si applica la maggior parte del flusso agile/scrum tradizionale, in cui i team lavorano in iterazioni per fornire sistemi funzionanti. I ruoli di Scrum Master, Product Owner e membro del team sono usati in SAFe così come la maggior parte delle attività e degli artefatti di Scrum. I team sono inoltre supportati da ruoli a livello di programma come Product Management, System Architect e altri servizi condivisi. Kanban viene utilizzato per visualizzare il flusso delle funzionalità attraverso il ciclo di vita della distribuzione e le interazioni e gli handoff tra i team.

Competenza DevOps e Release on Demand/Livello di programma

La competenza DevOps e Release on Demand descrive come "l'implementazione di DevOps e di una pipeline di fornitura continua offre all'azienda la capacità di rilasciare valore, in tutto o in parte, in qualsiasi momento necessario per soddisfare la domanda del mercato e dei clienti".

DevOps lavora per allineare lo sviluppo, le operazioni, il business e altre aree per lavorare insieme per fornire risultati di business. Sebbene non tutte le organizzazioni debbano rilasciare con la stessa frequenza di alcuni dei leader del settore del movimento DevOps (Amazon rilascia ogni pochi secondi), tutte le organizzazioni devono essere in grado di rilasciare su richiesta.

• DevOps fornisce l'approccio CALMR (cultura, automazione, flusso snello, misurazione e ripristino) che consente la distribuzione continua e il rilascio su richiesta

• Gli Agile Release Train (ART) sono team di team agili organizzati per fornire valore su richiesta tramite una pipeline di fornitura continua

Il livello di programma del diagramma descrive i ruoli e le attività necessarie per fornire continuamente tramite un Agile Release Train (ART) . Questo livello funziona in modo iterativo simile al livello del team, ma integra più team agili e include più cicli. L'ART è un team agile di team composto da 5 a 12 team (da 50 a 125 persone), inclusi i ruoli agili tradizionali e ruoli critici del programma come Release Train Engineer (RTE) e Product Management. L'ART fornisce in 8-12 settimane Program Increments (PI) pianificati tramite PI Planning e guidati da un Product Manager .

Il progresso delle funzionalità PI, epiche, ecc. viene tracciato e gestito tramite una scheda Kanban del programma. La RTE funge da Scrum Master sull'ART. Le riunioni giornaliere di sincronizzazione includono i team Daily Standups, Scrum-of-Scrums (RTE e Scrum Master), PO Sync (Gestione dei prodotti e proprietari di prodotti) e ART Sync (Scrum-of-Scrum e PO Sync insieme). Ogni PI ha una demo di sistema e una retrospettiva.

Competenza in soluzioni aziendali e ingegneria dei sistemi snelli/livello di soluzione elevato

La Business Solutions and Lean Systems Engineering Competency descrive "come applicare i principi e le pratiche Lean-Agile alla specifica, allo sviluppo, all'implementazione e all'evoluzione di applicazioni software grandi e complesse e sistemi cyber-fisici".

Oltre ai principi SAFe, l'applicazione dei seguenti 8 principi quando si lavora su soluzioni di grandi dimensioni è fondamentale per questa competenza:

Il livello di soluzione di grandi dimensioni contiene i ruoli, gli artefatti e i processi necessari per creare soluzioni complesse e di grandi dimensioni. Più ART stanno lavorando insieme su Solution Train per fornire soluzioni . Gli obiettivi primari sono:

• Gestire l'integrazione frequente

• Affronta continuamente i problemi di conformità

• Architetto per scalabilità, modularità, svincolabilità e facilità di manutenzione

La gestione della soluzione controlla il contenuto di una soluzione e il Solution Train Engineer (STE) guida il lavoro. Solution Architect è responsabile del mantenimento di una buona architettura per tutte le ART nella soluzione. Pre e Post PI Planning viene utilizzato per pianificare le soluzioni fornite tramite più incrementi del programma. Un arretrato di soluzioni contiene funzionalità e epici di soluzioni ed è tracciato tramite una scheda Kanban della soluzione

Competenza nella gestione del portafoglio snella/livello di portafoglio

La competenza di gestione del portafoglio snello "allinea la strategia e l'esecuzione applicando approcci snelli e di pensiero sistemico alla strategia e al finanziamento degli investimenti, alle operazioni di portafoglio agili e alla governance".

Il Lean Portfolio Management si concentra sulle seguenti aree:

1. Strategia e finanziamento degli investimenti: collega il portafoglio alla strategia aziendale, finanzia flussi di valore e stabilisce il flusso del portafoglio

2. Operazioni di portafoglio agili: coordina i flussi di valore, l'esecuzione del programma di supporto e l'eccellenza operativa

3. Governance snella: prevede budget, misura le prestazioni del portafoglio e impone la conformità

Il livello di portafoglio contiene i principi, le pratiche ei ruoli necessari per avviare e governare un insieme di flussi di valore di sviluppo. Un Portfolio Backlog contiene Business Epics e Enabler Epics ed è tracciato tramite una scheda Portfolio Kanban*. **Il Lean Portfolio Management (LPM) decide quali flussi di valore sono in un portafoglio e include i più alti responsabili delle decisioni in un'impresa. Un Enterprise Architect guida il lavoro e coordina i flussi di valore.

Meno

Il framework Scrum su larga scala (LeSS) è stato creato da Craig Larman e Bas Vodde, che lo hanno basato sulla loro esperienza nei settori finanziario e delle telecomunicazioni. Come suggerisce il nome, LeSS promuove il minor numero possibile di processi e procedure per far lavorare insieme molti Scrum team. Il ridimensionamento è difficile perché le persone lo rendono complesso, quindi l'obiettivo qui è renderlo il più semplice possibile.

Principi e componenti principali

“LeSS è Scrum, applicato a molti team, lavorando insieme, su un unico prodotto”. LeSS si basa su dieci principi che sembreranno familiari a chiunque abbia familiarità con i principi Lean-Agile:

1. Scrum su larga scala è Scrum

2. Controllo empirico del processo

3. Trasparenza

4. Più con meno

5. Focus sull'intero prodotto

6. Incentrato sul cliente

7. Miglioramento continuo verso la perfezione

8. Pensiero sistemico

9. Pensiero snello

10. Teoria delle code

LeSS ha solo due ruoli principali, entrambi presi in prestito da Scrum:

1. Proprietario del prodotto: lavora con 2-8 team.
2. Scrum master: Funziona con 1-3 team.

Tutti i team lavorano con lo stesso arretrato di prodotti in sprint di 1-4 settimane. Le squadre lavorano in parallelo, il che significa che iniziano e finiscono gli sprint contemporaneamente. Alla fine dello sprint, i team forniscono collettivamente un incremento di prodotto . Potrebbe sembrare quasi impossibile per un proprietario di prodotto lavorare con 8 team. LeSS promuove lo spostamento della responsabilità del chiarimento degli elementi del product backlog ai team. A loro volta, i team devono essere interfunzionali e contenere non solo competenze di codifica, progettazione e test, ma anche conoscenze del dominio aziendale. Ancora più importante, i team devono essere abilitati per poter raggiungere i clienti.

Pianificazione dello sprint

La pianificazione è divisa in due parti:

1. Pianificazione dello sprint 1: Quando i rappresentanti dei team si incontrano con il product owner e decidono quali elementi del backlog dovranno assumere e discutono di qualsiasi potenziale cooperazione che potrebbe essere necessaria tra i team durante lo sprint.
2. Sprint planning 2: come nella mischia tradizionale, ogni team si riunisce separatamente per creare un piano su come verranno realizzati gli elementi del backlog.

Affinamento del Product Backlog

Il perfezionamento del product backlog (PBR) viene eseguito durante lo sprint per preparare gli elementi del product backlog per la pianificazione dello sprint. LeSS non offre regole su come eseguire il PBR e lascia alle aziende il compito di capire da sole il processo più efficace. PBR prevede tre attività chiave:

1. Dividere oggetti grandi.
2. Dettagliare gli articoli fino a quando non saranno pronti.
3. Stima.

Fine dello Sprint

Alla fine di ogni sprint accadono tre cose:

1. Sprint Review: una demo Sprint condivisa, in cui team e clienti esplorano cosa è stato fatto durante lo Sprint e cosa dovrebbe essere fatto dopo.
2. Retrospettiva: ogni squadra tiene la propria retrospettiva per migliorare il proprio processo.
3. Retrospettiva generale: team, product owner e Scrum Master si riuniscono per ispezionare e adattare le pratiche organizzative per essere più efficaci.

Scrum@Scala

Scrum at Scale e Scrum@Scale sono usati in modo intercambiabile. Questa metodologia è stata introdotta da Jeff Sutherland nel 2014, che ha creato la metodologia Scrum ed è stato uno dei firmatari del Manifesto Agile.

Scrum@Scale prende Scrum come punto di partenza e offre un framework semplice e leggero per scalare Scrum con una "burocrazia minima praticabile". È meno prescrittivo rispetto alle altre metodologie agili scalate e può essere considerato come un meta-quadro. Evidenzia i problemi e le aree di ridimensionamento e offre un quadro mentale su come potrebbero essere affrontati.

Principi e componenti principali

Scrum@Scale è un framework che semplifica radicalmente il ridimensionamento utilizzando Scrum per ridimensionare Scrum. In Scrum, il “cosa” (product owner) è chiaramente separato dal “come” (Scrum Master). La stessa strategia viene utilizzata in Scrum@Scale in modo che la giurisdizione e la responsabilità siano ben comprese, eliminando sprechi e conflitti.

Scrum@Scale contiene due cicli per separare chiaramente le giurisdizioni: il ciclo Scrum Master e il ciclo Product Owner con due punti di contatto: Processo a livello di team e Feedback sul rilascio del prodotto.

Ciclo Scrum Master

Lo Scrum Master Cycle è responsabile di come verranno costruiti gli elementi identificati dal ciclo del Product Owner. In Scrum@Scale, i singoli Scrum Team hanno gli stessi ruoli, artefatti, attività e cerimonie degli Scrum tradizionali.

I team Scrum sono raggruppati in uno Scrum of Scrums (SoS) che è congiuntamente responsabile della produzione di un incremento congiunto del prodotto. Partecipano alla preparazione e alla definizione delle priorità congiunte degli arretrati, tengono retrospettive, mantengono gli arretrati di impedimenti e tengono uno Scaled Daily Scrum (SDS) (simile nel formato allo Scrum giornaliero) per coordinare i team e rimuovere i blocchi stradali. L'SDS è frequentato da almeno un rappresentante (di solito lo Scrum Master del team) di ciascuno dei team partecipanti ed è guidato dallo Scrum of Scrum master (SoSM) che è responsabile del coordinamento con gli Scrum Team e i Product Owner.

Se è necessario un ulteriore ridimensionamento, esiste uno Scrum of Scrum of Scrum (SoSoS) creato da più SoS che si riunirebbero anche quotidianamente, e così via. Il leader generale è l' Executive Action Team (EAT) che è responsabile della promozione dell'Agile nell'organizzazione, del coordinamento dei team Scrum secondo necessità e dell'ultima tappa per rimuovere gli impedimenti.

Ciclo del proprietario del prodotto

Il Product Owner Cycle è responsabile di quale prodotto o servizio verrà creato e di tutte le attività necessarie per supportarlo. I Product Owner sono assegnati ai team Scrum e svolgono tutte le attività del loro ruolo come definito in Scrum. I Product Owner sono raggruppati in Product Owner Teams che si associano ai team SoS. I Product Owner Teams si incontrano quotidianamente in un Meta Scrum per discutere una strategia di alto livello per i team e, se necessario, coordinarsi con il SoSM corrispondente e altri Product Owner e stakeholder. I Meta Scrum sono guidati da un Chief Product Owner (CPO) .

I Product Owner scalano in modo simile allo Scrum Master Cycle, a seconda delle dimensioni dell'organizzazione e culmina in un Executive Meta Scrum (EMT) , che è responsabile dell'impostazione delle priorità a livello aziendale.

Implementazione di Scrum@Scale

L'implementazione di Scrum@Scale inizia con la creazione di un modello di riferimento scalabile, ovvero un piccolo insieme di team che utilizzano Scrum su piccola scala. Questo viene fatto per risolvere eventuali politiche organizzative e pratiche di sviluppo che ostacolano l'agilità. Scrum@Scale suggerisce di risolverli in anticipo perché è probabile che tutti i team debbano affrontare questi problemi di vasta portata dell'organizzazione e le conseguenti frustrazioni potrebbero ostacolare l'adozione dell'agile. Il modello di riferimento viene quindi utilizzato come modello per il ridimensionamento di Scrum ad altri team e dipartimenti.

Inizialmente, per implementare il modello di riferimento, è necessario creare un team di azione esecutiva (EAT). EAT è composto da individui che hanno poteri politici e finanziari all'interno dell'organizzazione, poiché saranno in grado di attuare i cambiamenti delle politiche organizzative.

Conclusione

In questa seconda parte del progetto di gestione del progetto, abbiamo trattato alcuni dei framework più popolari utilizzati su progetti o programmi più grandi. Waterfall è ancora ampiamente utilizzato in molte organizzazioni e, sebbene presenti molti svantaggi a causa dei suoi processi rigidi, a volte ha senso utilizzare questo framework quando i progetti sono piccoli e l'ambito è ben definito ed è improbabile che cambi.

Quando le aziende incontrano progetti più grandi e complessi con requisiti o obiettivi in ​​continua evoluzione, cercano approcci più agili. Poiché Agile era originariamente pensato per piccoli team di 5-9 persone, vari professionisti Agile sono venuti con diversi modi per scalare Agile da singoli team, a più team, all'intera azienda. In questo articolo abbiamo trattato Disciplined Agile Delivery (DAD), Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) e Scrum@Scale.

Nella parte finale del progetto di gestione del progetto, tratteremo alcuni framework specifici di gestione del progetto come PMP (PMBOK) e PRINCE2. Esamineremo anche alcuni processi e framework di innovazione come "lavori da svolgere" (JTBD) e "design thinking".