Utili consigli per prepararsi alla certificazione Scrum Master PSM I™

Sei alla ricerca di utili consigli per prepararsi alla certificazione Scrum Master PSM I™?

L'Agile Mindset e il framework Scrum sono i protagonisti della trasformazione Agile. Lo Scrum Master è considerato tra i ruoli chiave di questa trasformazione che non è solo fare Agile ma soprattutto essere Agile.

Sono molti i professionisti che hanno iniziato a utilizzare il framework Scrum in azienda e tanti altri si stanno avvicinando. Tutti hanno in comune il desiderio di approfondire il suo funzionamento con casi pratici e ottenere un riconoscimento delle competenze acquisite.

Visto l'importante cambio di paradigma introdotto da Agile, il tempo da dedicare allo studio e il livello di difficoltà dell'esame, sono in molti a cercare suggerimenti e consigli per ottimizzare il tempo e aumentare le probabilità di superare dell'esame.

Così mi sono detto, perché non condividere gli utili consigli per prepararsi alla certificazione Scrum Master PSM I™ di chi ce l'ha fatta?
Questo articolo nasce con l'obiettivo di condividere le loro lesson learned, con lo scopo di aiutare chi sta preparando l'esame di certificazione a ottimizzare il proprio studio.

Di seguito sono riportate le recenti esperienze di chi ha da poco sostenuto e superato l'esame PSM I.  

Vuoi saperne di più? Iscriviti al webinar gratuito.

Utili consigli per prepararsi alla certificazione Scrum Master PSM I™.

Il mio viaggio verso la certificazione PSM I
Utilizzo metodologie Agile da diversi anni ma ritenevo importante partecipare ad un corso che mi desse la possibilità di estendere le mie conoscenze e capire come altri – sul campo - avessero gestito e superato alcune tematiche relative all’utilizzo del framework scrum.

Nel corso Professional Scrum Master ho trovato esattamente quello che stavo cercando. Sviluppo dei concetti teorici di base con ampio spazio ad esercitazioni in gruppo per “provare sul campo” i concetti toccati.

In particolare sono risultate molto utili le numerose esercitazioni pratiche in quanto hanno permesso di fissare i concetti principali ed allo stesso tempo di metterli in pratica.

Avendo come secondo obiettivo l’ottenimento della certificazione Scrum Master, ho poi proceduto ad integrare il corso con altri elementi che mi permettessero di approfondire a sufficienza il tema; quindi :

  • Studio della scrum guide
  • Studio del glossario
  • Open Assessment “Scrum Open” (dal sito ufficiale Scrum.org)

E con questo, alla prova di esame svolta con il docente l’ultimo giorno del corso sono arrivato a rispondere correttamente all’85% circa delle domande.

Nei giorni successivi ho rivisto gli argomenti su cui ero risultato particolarmente debole e mi sono nuovamente confrontato con:

  • Le domande fatte durante la sessione di simulazione di esame del corso (raggiungendo circa il 100% nei tempi massimi previsti)
  • Open Assessment “Scrum Open” (raggiungendo il 100% in modo costante)
  • Test gratuito online relativamente alla certificazione Scrum Master messo a disposizione da “Mikhail Lapshin” (raggiungendo il 100% nei tempi massimi previsti)
  • Question Bank di Sidharth Bathia

Importante sottolineare che tali test di esame NON sono dei dump dell’esame, pertanto hanno il solo scopo di far comprendere il livello a cui si è arrivati e fare emergere gli argomenti su cui è necessario fare approfondimenti.

L’esame richiede di rispondere a 80 domande in 60 minuti ed il minimo richiesto per passarlo è l’85% di risposte esatte. Dato il tempo molto limitato e la percentuale alta di risposte esatte da dare è importante rimanere concentranti e se per alcune domande non si è sicuri della risposta, rispondere con ciò che si pensa sia corretto e “markarle” in modo da rivederle con calma alla fine. Le domande sono un mix tra domande dirette in cui è necessario solo avere studiato (e qui è importante guadagnare tempo) e domande situazionali in cui è necessario avere compreso i concetti (in quanto viene chiesto di dare la/le risposte che riteniamo “più giuste”).

Next step verso la certificazione PSPO I
Dopo aver superato l’esame PSM I, ho seguito il consiglio del docente che durante il corso ci aveva accennato che la PSM I poteva fungere come base di conoscenza per poi affrontare la PSPO I.

Tale certificazione è certamente più complessa ed ampia della PSM I; mi sono quindi affidato ai consigli che venivano dati nei vari blog creandomi il mio percorso di studio; lo riepilogo :

  • Ripasso di tutto quando studiato per la PSM I
  • Studio aggiuntivo :
  • Prove di esame :
    • Tutti gli assessment svolti per la PSM I
    • Open Assessment “Product Owner Open” (raggiungendo il 100% in modo costante)
    • Open Assessment “Evidence Based Management Open” (raggiungendo il 100% in modo costante)
    • Test gratuito online relativamente alla certificazione PSPO I messo a disposizione da “Mikhail Lapshin” (raggiungendo il 100% nei tempi massimi previsti)

Anche in questo caso, è importante sottolineare che tali test di esame NON sono dei dump dell’esame, pertanto hanno il solo scopo di far comprendere il livello a cui si è arrivati e fare emergere gli argomenti su cui è necessario fare approfondimenti.

Come per la PSM I anche l’esame della PSPO I richiede di rispondere a 80 domande in 60 minuti ed il minimo richiesto per passarlo è l’85% di risposte esatte. Quindi i consigli dati per la PSM I rimangono validi. Aggiungo però che il livello di difficoltà è sicuramente superiore in quanto il numero di domande situazionali è molto più ampio, lo stesso vale per gli argomenti da conoscere. Per questo motivo, consiglio di sostenere l’esame solo quando si è certi di avere bene compreso tutti gli argomenti oggetto dell’esame.

Premessa: ho seguito alcuni corsi tenuti da Alessandro Ingrosso nell'ambito del framework Scrum pur non avendo all'inizio alcuna nozione in merito. Fin dai primi momenti mi sono sentito molto coinvolto sia per la modalità in cui Alessandro tiene i suoi corsi sia per le logiche Scrum che si vestivano molto bene con il mio modo di lavorare. Ho iniziato fin da subito ad applicare alcune nozioni apprese durante i corsi vedendo nell'immediato, seppur piccoli, dei risultati.

Certificazione: l'ultimo corso seguito era proprio mirato alla certificazione PSM I al quale ho partecipato con la convinzione che mai avrei comunque conseguito la certificazione stessa. I miei dubbi erano legati alla non perfetta conoscenza del framework ed al fatto (mia lacuna) che dovendo sostenere l'esame in inglese avrei avuto ulteriori difficoltà. Sia l'esame PSM I e PSPO I sono entrambi composti da 80 domande in inglese a cui rispondere in 60 minuti. Per superarli è necessario rispondere in modo corretto all'85% delle domande. Al termine del corso Alessandro è riuscito a trasmettermi la sicurezza necessaria per provare almeno a fare un tentativo. Questa sicurezza non era dovuta solo da un ottimo insegnamento/apprendimento tecnico delle regole Scrum, ma soprattutto dalla giusta comprensione delle logiche dietro al framework Scrum. Concludendo: non solo ho preso la PSM I ma anche la PSPO I.

Meriti: non posso che riconoscere che il merito di Alessandro nel conseguimento delle due certificazioni non sia legato solo alle sue competenze e conoscenza del framework Scrum,ma piuttosto alla sua capacità di trasmettere in modo chiaro e comprensibile le logiche dietro al framework stesso. Sono pienamente convinto che l'aver frequentato i suoi corsi e le successive certificazioni mi permetteranno di avere una visione totalmente differente della gestione dei progetti.

Grazie Alessandro.

Business Agility: cambiamento e competitività

“Business Agility: cambiamento e competitività” è il titolo del webinar tenutosi lo scorso 8 luglio 2020. Organizzato da Cornerstone International Group Italia, con Anna Di Girolamo abbiamo parlato di Agile Mindset, Business Agility, cambiamento e competitività.

L’improvviso mutamento dello scenario lavorativo, indotto dal lockdown, ha portato in auge l’applicazione delle metodologie Agile. Ma non tutte le organizzazioni sono consapevoli che non basta applicare una metodologia Agile per diventare Agile.

Per questo motivo l’obiettivo del webinar è stato quello di chiarire cosa è l’Agile Mindset e l’importanza del fare Agile ed essere Agile.

Vista l’attualità dell’argomento la partecipazione è stata molto alta, e ha coinvolto rappresentanti di medie e grandi aziende italiane.

Così abbiamo deciso di raccontare cosa è accaduto e sintetizzare alcuni degli argomenti trattati in un’intervista.

Potrebbe interessarti anche questo articolo: Cos’è Agile e perché sta diventando indispensabile portarlo in azienda.

Cos’è Agile e perché sta diventando indispensabile portarlo in azienda

Questo articolo è stato originariamente pubblicato sul sito Leadership & Management il 02 luglio del 2020. Riporto di seguito l’abstract, l’articolo completo è raggiungibile a questo link.

Il cambiamento è una costante. Aziende, organizzazioni e persone si affannano a “trattarlo” come fosse un’eccezione, si trovano spiazzate di fronte a ciò che muta e faticano moltissimo per adattarsi, ma il cambiamento è una costante: tutto cambia, più o meno lentamente, ma cambia.

La pandemia e il successivo lockdown sono stati un acceleratore di cambiamento di portata globale: eravamo impreparati, certo, e molte realtà imprenditoriali non ce l’hanno fatta, ma se da questa esperienza possiamo imparare qualcosa, allora diventa indispensabile fare una riflessione seria sul concetto di cambiamento.

Le aziende hanno bisogno di strutture snelle, poco (o nulla) gerarchiche, veloci, capaci di sfruttare al meglio la tecnologia, che hanno ristretto la burocrazia al minimo indispensabile e che siano in grado di sviluppare un approccio adattivo.

La domanda che tutte le aziende, oggi, dovrebbero porsi è: se il cambiamento è una costante, come posso organizzare la mia azienda in modo tale che non sia travolta dai continui cambiamenti ma che, anzi, sia in grado di evolvere continuamente per governarli? La risposta è Agile.

Panoramica certificazioni Agile

Una mappa mentale che rappresenta una panoramica non esaustiva delle certificazioni Agile.

Negli ultimi anni c'è stata una rapida  crescita nel numero di certificazioni Agile, Scrum e framework per far scalare Scrum nelle grandi organizzazioni. Sono sempre stato curioso di mappare lo stato attuale, identificando i principali enti di certificazione, i differenti percorsi, i livelli di certificazione, i requisiti di accesso, i costi, ecc.

Questo primo articolo (è mia intenzione pubblicare altri dettagli) ha come obiettivo quello di fornire una panoramica dell'offerta disponibile. L'articolo non entra nel merito qualitativo di ciascuna certificazione,  è solo un'istantanea dello stato attuale.

Nel rappresentare la panoramica delle certificazioni Agile e non solo ho utilizzato una mappa mentale navigabile. Ciascun nodo è anche un link che punta ai contenuti di approfondimento pubblicati nelle pagine dei siti ufficiali.

Gli enti e le certificazioni riportate potrebbero non essere tutte quelle esistenti. Inoltre rispetto alla data di pubblicazione dell'articolo potrebbero in futuro esserci ulteriori variazioni. Cercherò di mantenere più possibile aggiornata questa pagina, tuttavia se dovessi accorgerti dell'assenza di importanti enti o certificazioni, o riscontrassi errori puoi inviarmi una segnalazione e provvederò ad aggiornare rapidamente i contenuti.

La mappa mentale è navigabile, ed è possibile spostarsi al suo interno, ingrandirla o ridurla. Da questo link puoi scaricare la versione PDF della mappa mentale. Se hai trovato utile questo articolo puoi condividerlo sui tuoi canali social. In fondo alla pagina puoi lasciare i tuoi commenti.

Potrebbe anche interessarti questo articolo: Quale certificazione Agile scegliere?

I 4 valori del Manifesto Agile

I Valori del Manifesto Agile
I Valori del Manifesto Agile

Il Manifesto Agile si compone di quattro valori, ognuno dei quali rappresenta un bilanciamento tra due aspetti entrambi importanti. Non esiste un unico equilibrio tra le parti ma il contesto, gli obiettivi da raggiungere, la maturità organizzativa, la ricerca della creatività e dell’innovazione, generano differenti equilibri tra quanto è riportato a sinistra e a destra di ciascun valore.Non esiste una netta demarcazione tra giusto o sbagliato, ma il bilanciamento viene affinato rispetto al risultato ottenuto: ha funzionato o non ha funzionato.

Gli individui e le interazioni più che i processi e gli strumenti.

Oggi rispetto al passato ci troviamo spesso a lavorare su progetti che sono caratterizzati da un’elevata incertezza, e una forte spinta all’innovazione e alla creatività.
In contesti come questo cercare un processo predefinito e standardizzato per portare a termine un progetto non è mai la soluzione migliore. Siamo stati formati per cercare sempre l’unica soluzione ottima per raggiungere il risultato: analizzare, pianificare, eseguire, controllare e raggiungere l’obiettivo. 
Nella maggior parte dei casi si pretendono dei processi già pronti, preimpostati, ma di fronte all’incertezza e all’esplorazione di nuove soluzioni i team dovrebbero essere liberi di generare nuovi processi, di sperimentare ed essere aperti all’apprendimento.  

Piuttosto, i team dovrebbero creare i propri processi, trovando anche benefici da nuovi strumenti. Questo vuol dire che ogni singolo team può essere libero di utilizzare processi nuovi e personalizzarli in base alle proprie esigenze e obiettivi da perseguire. 

I membri di un team sono talmente abituati a ricevere processi e strumenti predefiniti da parte dell’azienda, che quando questo non accade, il lavoro rallenta o si blocca. 

La causa di tutto questo sono le abitudini e la cultura predittiva, che con il passare del tempo diventano sempre più stabili e ripetitive all’interno di un’organizzazione. Quando questo accade l’organizzazione non è più aperta all’innovazione, alla creatività e all’esplorazione.

Bisogna dunque bilanciare l’interazione tra individui e il rispetto dei processi mettendo al centro gli obiettivi del progetto.

Una domanda chiave può essere: quanto è importante avanzare nella scoperta di nuova conoscenza
Tanto più la nuova conoscenza genera valore e ci rende competitivi, tanto più dobbiamo liberare gli individui e rimuovere gli ostacoli che derivano da processi e strumenti predefiniti.

Il software funzionante più che la documentazione esaustiva.

Per software funzionante si intende un software completo, testato, integrato, che risponde ai requisiti di qualità che sono stati richiesti, e ultimo ma non meno importante, che generi valore per il cliente. 

Ma cosa significa nello specifico essere conforme agli standard di qualità? 

Va specificato innanzitutto che la qualità è soggettiva e può cambiare in base alle esigenze del momento. È necessario dunque specificare qual è il requisito qualitativo del prodotto che si richiede, ovvero la caratteristica principale su cui il progetto deve puntare. 

Ad esempio, non è sufficiente dire vorrei acquistare un abito di qualità

Cosa intendiamo di preciso per abito di qualità? Un abito di buona fattura, che vesta alla perfezione, o realizzato da uno stilista affermato?

Chi di noi acquisterebbe un abito di pessima qualità?

Occorre dunque specificare la qualità che si richiede in maniera chiara e misurabile. Nella sesta edizione del PMBOK la qualità è definita come “il grado a cui determinate caratteristiche sono conformi ai requisiti”. Il grado di qualità deve essere una metrica misurabile, o è DONE o è NOT DONE.

Per quanto riguarda la documentazione esaustiva invece, si intende tutto quel lavoro che non è consegnato al cliente perché privo di valore. L’investimento del cliente non deve essere sprecato per qualcosa che non gli verrà consegnato, perché questo non produce valore ai suoi occhi.

Questo approccio solleva un’altra domanda, come ci si assicura il trasferimento della conoscenza ad altri quando è necessario rendere efficienti i costi della documentazione?

Un documento cartaceo non sarà mai sufficiente a trasferire la nostra intera conoscenza a un’altra persona. Inoltre, va considerato che i singoli processi possono cambiare di volta in volta, perché è proprio la nostra conoscenza che ci fa cambiare comportamento, migliorare, ogni volta che ci troviamo in una situazione conosciuta. 

Questo perché la conoscenza acquisita porta sempre valore e ci permette di commettere meno errori e svolgere le attività in modo più efficiente. 

La soluzione ottimale è lavorare insieme in un team più possibile cross-funzionale.

Lavorare insieme condividendo gli stessi spazi fisici, è il modo migliore per condividere la conoscenza. Questo perché c’è meno necessità di documentare le attività, e perché il dialogo è il metodo meno costoso e più efficace per trasferire conoscenza.

Il limite importante è che la conoscenza non potrà mai essere trasferita facilmente in un altro gruppo, senza una forte interazione tra le parti.

Il lato positivo invece è che in questo modo si costruisce un team resiliente. Se sostituiamo un membro del team con un'altra persona, questa potrà integrarsi facilmente al gruppo, e acquisire conoscenza in tempi rapidi assorbendola dagli altri membri.

La collaborazione col cliente più che la negoziazione dei contratti.

Questo valore prevede la necessità di mantenere sempre una relazione collaborativa con i principali stakeholder del progetto, fortemente fondata sul concetto di trasparenza e fiducia.

La collaborazione è dunque un aspetto fondamentale, soprattutto di fronte alle numerose modifiche che ci saranno nel corso del progetto. È necessario dunque formulare dei contratti adeguati e non contratti ad ambito prefissato. I contratti a rimborso spese e i Time & Material sono quelli che si adattano meglio al Manifesto Agile. In questo mio precedente articolo puoi trovare un approfondimento specifico sui contratti Agili.

Rispondere al cambiamento più che seguire un piano.

In Agile non si utilizza il Gantt, ma questo non vuol dire che non si faccia alcuna pianificazione. Si procede piuttosto nell’esecuzione di una pianificazione di tipo adattativo, ovvero che accetta cambiamenti al progetto ed è flessibile. 

La pianificazione adattativa non prevede un percorso predefinito, perché ogni team deve trovare il proprio in base all’esperienza maturata e al contesto in cui si trova. Abbracciare il cambiamento è il modo migliore per far sì che tutto ciò avvenga.

Esistono contratti Agili? Quali sono i rischi?

Contratti Agili
Businessman pressing contract on a digital screen, concept about agreement in business

La situazione sui contratti Agili

Il Framework Scrum si sta rapidamente diffondendo nei reparti di sviluppo software delle aziende italiane. Spesso le aziende si rivolgono all'esterno per lo sviluppo del software, per questo motivo in aula mi viene posta sempre la stessa domanda: Esistono contratti Agili?

Ad oggi, in Italia, non sembrano esistere ancora dei modelli contrattuali Agili legalmente riconosciuti. È possibile fornire informazioni sui contratti Agili in generale, ma non supportati da un parere legale.

In Italia, al momento, possiamo  utilizzare tipologie contrattuali che possono essere adattate ad un contesto Agile.

L’assenza di modelli contrattuali Agili può essere un ostacolo è un problema che alcune aziende stanno affrontando in questo momento. Molte vorrebbero affidare esternamente lo sviluppo del software, potendo così beneficiare di processi Agili per la creazione rapida di valore.

Tipologie di contratti internazionali e soluzioni nazionali

All'estero sono già presenti forme contrattuali specifiche per progetti che adottano processi Agili.

Tra le prime organizzazione che hanno sviluppato modelli contrattuali agili è possibile trovare l'Agile Business Consortium. Questo il link per scaricare il modello: Agile Project Framework Contract Template. Ovviamente per utilizzarlo in Italia, oltre alla traduzione, è necessario un adattamento attraverso una consulenza legale.

Esistono anche altri modelli contrattuali di riferimento:

Per ora questi contratti possono essere utili come fonte di ispirazione per adattare contratti legalmente riconosciuti.

Nell'attuale contesto italiano i contratti che meglio possono adattarsi al framework Scrum, e in generale ad Agile, sono il Time & Material e il contratto a rimborso. Nei contratti può essere determinato un tetto massimo di costo, la durata del progetto e la durata di uno Sprint senza necessità di determinare nel dettaglio l’ambito del lavoro. Lo Sprint avrà così sempre lo stesso costo. Sarà necessario porre particolare attenzione al valore che si intende produrre in ogni Sprint, per evitare di spendere più del valore che si otterrà in cambio.

Cosa rende critico un contratto Agile?

L'aspetto considerato critico in un contratto Agile è la potenziale completa assenza di un ambito dettagliato. Oggi è frequente la possibilità che un progetto venga avviato a partire da un’idea e bisogno non ancora tradotti in requisiti tecnici e funzionali.

Una delle caratteristiche del progetto, infatti, potrebbe proprio essere quella di esplorare e apprendere qualcosa di nuovo. I processi e le pratiche Agili sono particolarmente efficaci in progetti complessi. Il modello Agile prevede che a fronte di un ambito poco o per nulla definito, si fissino due variabili : il tempo e il costo. Allo scadere del tempo e del budget, si restituisce ciò che è stato realizzato fino a quel determinato momento. Vi sembra folle? Non lo è, vediamo perché.

Alcune ricerche hanno messo in evidenza che il numero di funzionalità utilizzate da un utente in un prodotto è nettamente inferiore rispetto al loro numero totale. Semplificando potremmo dire che: il 20% delle funzionalità di un prodotto costituisce l'80% del suo valore.

Quindi possiamo affermare che: il costo di ciò che è stato prodotto, è sicuramente minore del valore creato in termini di business (profitti e/o riduzione dei costi).

Pertanto in un progetto non è necessario realizzare tutto, ma tutto ciò che ha valore.

Oggi è ancora particolarmente difficile trovare aziende disposte a fare un contratto su un ambito poco definito.

Ad esempio, cliente e fornitore si accordano per un valore economico e temporale fisso, a fronte di un ambito poco chiaro. In caso di contestazioni su cosa ci possiamo basare?

La trasparenza e la frequente comunicazione tra le parti diventano un elemento centrale per sviluppare fiducia nella collaborazione. Citando il terzo valore dell'Agile Manifesto: "La collaborazione col cliente più che la negoziazione dei contratti". Questo aspetto, a mio parere, non credo sia un elemento gradito ad un ufficio legale e non solo.

Vuoi saperne di più? Inviami le tue domande, ti risponderò nei prossimi articoli.

Cos’è il Framework Scrum? Come funziona?

Scrum
Scrum è un termine mutuato dal rugby.

Che cos'è Scrum e perché si chiama così?

Scrum è il più diffuso tra gli approcci Agili di Project Management, è un  Framework presentato per la prima volta nel 1995, che è stato creato per semplificare la gestione di progetti complessi ed innovativi. Scrum, parola inglese che letteralmente vuol dire “mischia”, è un termine mutuato dal rugby, sport dove tutti i giocatori formano un unico gruppo che spinge e fa forza per raggiungere un obiettivo comune.
Così come nel Rugby, l’obiettivo di Scrum è proprio quello di far convergere le forze di tutti i membri del team per “spingere” in un’unica direzione, affinché siano sempre coesi per raggiungere il risultato finale, produrre il massimo valore e ridurre al minimo i rischi e le perdite.

Questo vuol dire che i membri del Team lavorano per convergere su idee comuni ed essere sempre d'accordo sulle azioni da svolgere nel breve termine.
Il Framework Scrum crea le condizioni affinché le persone si sentano coinvolte nel progetto e lavorino in modo coeso durante tutte le fasi, comunicando tra loro e avendo sempre a mente l’obiettivo finale. La coesione e la comunicazione riducono al minimo l’inefficienza e le pratiche sbagliate.

Lavorare in un team spesso vuol dire far fronte quotidianamente a tante idee e tante proposte diverse, e quando si deve portare avanti un progetto ognuno ha il suo modo di vedere le cose. Gestire un progetto vuol dire raggiungere gli obiettivi attraverso uno o più risultati, e soddisfare le diverse aspettative degli stakeholder spesso non allineate fra loro. Questo, nel Project Management può portare all'insorgere di conflitti, ad un aumento dei costi, a ritardi nella consegna e a volte anche al fallimento del progetto stesso, perché ognuno segue una direzione diversa e alla fine ci si dimentica dell'obiettivo finale. Scrum aiuta a ridurre questi rischi.

Scrum non è una metodologia, è un framework

Scrum è un framework, non è una metodologia. Ma qual è la differenza tra Scrum è una metodologia classica?
Quando parliamo di metodologia ci riferiamo a un qualcosa di predefinito e strutturato, e soprattutto definitivo, che va seguito alla lettera e non prevede modifiche. Il framework è stato creato con l’idea di fornire un processo e dei ruoli ben definiti pur lasciando completa libertà alle persone di modificare gli strumenti in base all'obiettivo e alle tecniche che funzionano di più. Per questo motivo Scrum si può definire un framework aperto, senza strumenti o pratiche predefinite, a differenza delle metodologie tradizionali che sono pensate per progetti predittivi e sono ben definite e strutturate, ma soprattutto più rigide.

Vuoi saperne di più? Inviami le tue domande, ti risponderò nei prossimi articoli.