Grazie per questo primo tutorial. Pensi sia utile questo framework anche per gestire progetti di digital marketing dove spesso l'esigenza del cliente è di, per esempio, acquisire più contatti in target ma come Agenzia ci troviamo a: eseguire delle analisi di mercato, costruire delle landing page, creare grafiche e video, strutturare copy, strutturare, lanciare e gestire campagne pubblicitarie, etc etc etc Grazie
Grazie Marco per questa versione pop dello scrum! Molte delle cose (concetti direbbero quelli bravi) che volavano in giro per la mia testa ora hanno trovato il loro "loculo" definitivo. Ho imparato a non confondere le pere con le mele e come lo scrum master sia un servant leader. Buon fine settimana e ai prossimi pop style video!
Spiegazione davvero esauriente e soprattutto priva di fronzoli ed interessante! A volte ci si trova catapultati in team che ti propongono uno stand-up quotidiano, una retrospettiva ogni due venerdì ed un "lean**qualcosa**" di tanto in tanto, e suddetti team non spiegano - vuoi per poco tempo, vuoi per negligenza - da dove derivi ciò e le motivazioni, adottando un modello di riferimento perché magari fa figo. Spesso si da per scontata la cosa, invece bisognerebbe approfondire le radici di tutto, proprio come proponi tu nei tuoi contenuti. Grazie 😃
ottimo video e chiarissima spiegazione, mi conferma che agile e' la nuova cagata di moda inapplicabile per definizione nella maggior parte delle aziende italiane
Non sarei così drastico rispetto alla definizione di "cagata", invece mi trovi più concorde sulla difficoltà di applicare davvero Scrum in molti dei nostri contesti. Il fatto è che un framework, una pratica o una metodologia non vanno applicati perché di moda o perché "lo usano tutti", ma perché hai valutato che nel tuo specifico contesto quella cosa ti sarà utile. Il contesto di business di molte aziende italiane spesso non è adatto e allora è come usare il martello per avvitare gli stop ad un muro. Peggio, si pensa di poter cambiare modo di lavorare della sera alla mattina, quando invece la trasformazione è lunga e complessa.
@@MarcoCaressa sono pienamente d'accordo con la tua risposta, in effetti avrei dovuto scrivere "...e' candidata di diventare la nuova moda... che poi viene tramutata in cagata", ma di fatto il risultato non cambia.
in questi giorni ho avuto modo di constatare come funziona la certificazione ufficiale, un questionario online con una quarantina di domande a risposta multipla, nessun controllo del candidato mentre tiene l'esame, nessuna verifica dell'identita', risposte giuste disponibili in un documento con tutte o quasi le domande possibili. Aggiungo quindi che oltre ad essere una moda è una farsa. Bah.. .anni e anni di ingegneria del software buona eclissati da una metodologia fumosa e farlocca col bollino finto.
Caro @marcocaressa, ho implementato Scrum da anni nella mia azienda, con ottimi risultati. Dopo anni ho deciso di rianalizzare da zero la situazione e mi sono imbattuto nel tuo video: semplice, autorevole, completo e simpatico! Un quesito a cui non trovo risposta esplicita da nessuna parte. Noi siamo una software house con un prodotto unico e migliaia di clienti. Le richieste di personalizzazioni, migliorie richieste dai clienti al nostro help desk e ai commerciali, le abbiamo sempre fatte scrivere direttamente dai nostri assistenti e commerciali direttamente nel back log. Il product owner le analizza e poi, in concerto con lo scrum manager, valuta il da farsi. Sono incerto se questo sia corretto. Le richieste dovrebbero forse essere scritte invece in un documento 'word' ', analizzate dal PO che quindi le ribaltera" nel back log? Mi esprimo meglio: nel back log possono scrivere tutti o deve senpre e solo scrivere il PO? Grazie
Il PO è il responsabile ultimo (accountable) del backlog e lo gestisce, ma non è l'unico che vi contribuisce. Dal punto di vista operativo, puoi organizzarti in modo che raccolga le richieste e poi le filtri inserendo nel backlog solo le user story ritenute valide (ma così potrebbe rischiare di diventare un collo di bottiglia). Oppure puoi, come state già facendo adesso, dar modo a più stakeholder di contribuire direttamente al backlog, lasciando al PO il compito di prioritizzare le user story e/o di eliminare eventualmente quelle non ritenute di valore e al Dev Team di stimarle (la stima è fondamentale, altrimenti non hai elementi per decidere quali story inserire nello sprint entrante). In ogni caso, direi che nello spirito di un progetto agile, il modo migliore è che chiunque abbia bisogno di aggiungere elementi al backlog possa collaborare e interloquire direttamente con il PO.
Complimenti per la chiarezza e la semplicità della spiegazione. Mi è parso di capire che tu hai sperimentato in concreto questa metodologia quindi avrei piacere ad avere qualche tuo feedback sulle difficoltà applicative, calandole in un contesto lavorativo italiano dove (fortunatamente) non è ancora possibile licenziare dalla sera alla mattina se qualcuno non è “agile” come vorremmo. Nello specifico, che succede se il livello motivazionale dei membri del team non è ugualmente alto? Se non ci sono obiettivi stimolanti ben definibili individuali e/o di gruppo? Se una persona del team viene elevata a capo gerarchico dei restanti membri? Possiamo ancora parlare di scrum team in questi casi?
Se una persona viene elevata a capo gerarchico del resto del team diventa difficile per non dire impossibile applicare Scrum. L'agilità è data in gran parte dal team competente e auto-organizzato. Quanto al tema della motivazione e agli obiettivi individuali e di gruppo, è compito dello Scrum Master, in teoria, come leader al servizio del team, creare le condizioni e il contesto affinché vi sia motivazione e sia sempre ben chiara e rafforzata la "vision" di progetto. Poi, chiaro, un conto è dirle le cose, altro è riuscire a matterle in pratica ;-)
Ciao Marco e grazie per questo prezioso tutorial, chiaro e comprensibile come sempre! Sto studiando il PM "classico" (ovvero quello che nello sviluppo software all'ITIS ci insegnavano come waterfall) e il corso ha anche un modulo Agile, usando SCRUM nello specifico. Non riesco però ad applicare nessuno dei due metodi nel mio team di lavoro in quanto, facendo embedded, da un lato siamo limitati alla rigidità e alle tempistiche dell'hardware (cicli di sviluppo più lunghi, costosi e con feedback lenti) e dall'altro avemmo bisogno di molta agilità lato software (CI/CD, release frequenti ecc). Inoltre la gestione del team SCRUM ha degli effetti collaterali positivi (coinvolgimento del team, comunicazione ecc) che mi piacerebbe applicare. Ho sentito, superficialmente, parlare di metodologie ibride che potrebbe proprio fare al caso mio (PM classico per pianificazione a lungo periodo, SCRUM per la gestione a breve periodo, ovvero nel range di 2-3 sprint di 3 settimane circa l'uno). Ho però paura che questo hybrid project management possa essere una qualche buzzword e che i ruoli tendano a diventare "confusi".. hai qualche riferimento da darmi in merito? o, ancora meglio, conti di parlarne in futuro? (anche se immagino possa essere un argomento un po' avanzato e quindi non molto "pop" ;-) )
Grazie Andrea. Bella e corposa domanda. Il concetto di "hybrid" si applica a scenari non così chiaramente orientati ad un approccio predittivo o adattivo. Paradossalmente, gli agilisti sono più "duri e puri", Scrum non prevede ufficialmente delle ibridazioni. I testi sacri ti direbbero che lo devi applicare senza snaturarlo. Per orientarti usa questo criterio: quanto stabili sono i requisiti di ciò che devi realizzare? Quanta incertezza hai sul perimetro di lavoro da affontare? Più lo scenario è stabile, più funziona l'approccio "tradizionale", più è mutevole e più è adatto Scrum o un altro ciclo agile. Potresti strutturare il progetto in fasi, per le quali vi sia un diverso grado di stabiità. In questo caso potresti adottare un approccio ibrido di tipo verticale sulle fasi. Immagina un progetto software dove gran parte delle incertezzze sono relative alla UX. Potresti strutturarlo con una fase di definizione/prototipazione della UX, da condurre in modo agile, con frequenti feedback, ingaggio continuo di cliente e stakeholder. Poi, una volta consolidata la UX con un prototipo, anche "throw away", potrebbe partire una fase di realizzazione (progettazione tecnica, sviluppo e test) più tradizionale. E' solo un esempio. Per poter applicare un approccio ibrido serve grande padronanza degli approcci di base, per capire come confezionarsi il vestito a misura del progetto che devi fare. Comunque hai ragione, non è un argomento molto...pop 😎
@@MarcoCaressa grazie della risposta. L'esempio calza molto bene ma contene solo uno degli aspetti di Scrum che mi ha colpito. L'altro (che ritengo fondamentale in un ambiente molto tecnologico e in costante evoluzione) è il coinvolgimento dell'intero team nella valutazione delle attività che si possono completare in un certo intervallo temporale (in questo caso sprint) e nel miglioramento/efficientamento continuo dei processi e delle iterazioni (la retrospective è una cosa che viene nominata solo come ultima fase nell'approccio predittivo). Grazie soprattutto per aver sottolineato che serve sicuramente un'ampia conoscenza di entrambi prima di poter trovare una eventuale propria soluzione di compromesso
Andrea, il coinvolgimento del team nella valutazione e nell'efficientamento delle attività non è solo una prerogativa di Scrum o dei metodi agili. Personalmente ho sempre cercato di coinvolgere al massimo i team che mi è capitato di gestire. Questo indipendentemente dall'approcccio metodologico adottato.
Ciao Marco.. ottimo video come sempre! Ti volevo chiedere se consigli qualche master in project management per poi entrare in questo mondo lavorativo.. grazie!
Ciao Andrea, mi permetto di segnalarti solo percorsi che conosco direttamente. Tra questi il corso di perfezionamento in "Data Driven Project Management", un percorso online organizzato dal Dipartimento di Ingegneria Civile ed Industriale dell’Università di Pisa insieme a "Beam me up", spin-off dell’Università di Pisa, e Mylia del Gruppo Adecco, mira a formare project manager che siano in grado di gestire la complessità, il rischio e l’incertezza che la digital transformation introduce nelle organizzazioni. Scadenza iscrizioni 22 dicembre. Inizio lezioni a gennaio 2022. Di seguito il link per avere informazioni: www.masterindustry40.it/corsi-brevi/ P.S. lo conosco perché sono tra i docenti 😎.
Ciao Marco, video interessante! secondo te, un certificato PMP, ha necessità di ottenere la certificazione SCRUM? perchè nel nuovo PMBOK7 si tratta molto l'Agile (non solo Scrum ovviamente).
Non parlerei di necessità, ma di voglia di arricchire il bagaglio. Oggi la certificazione PMP, come contenuti, abbraccia il mondo agile in modo deciso e ci si riferisce anche a Scrum, ma ovviamente una certificazione specifica in ambito ti consente di approfondire di più.
Ciao Marco! Grande tutorial come sempre! 😉 Il framework Scrum, come altri framework agili, se non erro non prevede esplicitamente l’impiego della figura del PM. Credo che uno dei motivi principali per cui erroneamente il ruolo del PM viene confuso con quello dello Scum Master sia anche dovuto alla difficoltà di collocare la figura del PM in un’organizzazione che adotta Scrum come metodo di gestione dei progetti software (quindi non solo per mancanza di conoscenza o di comprensione del framework). Pertanto mi domando: in un’azienda strutturata per operare in un contesto come quello che hai descritto, il PM che compiti rivestirebbe? Altra curiosità: secondo la tua esperienza, lo Scrum Master, per rivestire bene il suo ruolo, deve necessariamente essere stato uno sviluppatore? Grazie!
Scrum e in generale i framework/metodi agili non prevedono una figura di PM propriamente detta. XP (Extreme Programming) prevede qualcosa del genere, con un ruolo di Manager (che pianifica, traccia e monitora) distinto dal ruolo di (Agile) Coach, simile allo Scrum Master di Scrum. In un'azienda che opera con Scrum, molte delle responsabilità che di solito sono di un PM sono distribuite sul Team, quindi sull'insieme "Product Owner-Scrum Master-Developers). Ci sono figure manageriali ma non di PM in senso stretto. Possono essere account manager nei confronti di clienti o aree di mercato o resource manager/responsabili di unità di produzione o business unit. Secondo me essere stato sviluppatore aiuta molto ad essere Scrum Master, perché essere passato in un ruolo favorisce il supporto a quel ruolo, la comprensione di ciò che occorre. Per altro, secondo i sacri testi di Schwaber e Sutherland, anche lo Scrum Master all'occorrenza può contribuire alle attivitò di realizzazione assieme ai Developer. Ma qui ci sono scuole di pensiero più o meno integraliste che potrebbero non essere d'accordo 😁
Ciao sei stato molto gentile e chiaro, ho capito un pochino la ruota e i ruoli . Sto cercando di capire però nel pratico cosa fa ogni giorno lo scrum master. Questo ancora non mi è molto chiaro. Ok leadership e supporto. Ma qualche esempio? Una giornata tipo ? 😁 scusami di queste richieste.
Buongiorno Marco, sono un nuovo iscritto! Quali sono i software che possano aiutare alla gestione del progetto e del team? Magari anche con il monitoraggio dei costi e redditività. Grazie!
L'assegnazione issue-developer che la svilupperà, deve essere fatta dallo Scrum Master o ogni developer può scegliere in autonomia quali issue scegliere all'interno dello Sprint Backlog? Vado a dettagliare: Una volta definito lo sprint backlog, è lo scrum master (durante lo spint planning) ad abbinare le varie issue a ciascun developer, oppure ogni developer sceglie le issue di sua preferenza? Inoltre, l'assegnazione issue-developer vafatta durante lo sprint planning o dy by day durante il Daylu scrum? Grazie
salve, mi è capitato molto spesso che molti project manager volessero applicare per progetti WEB e e-commerce una metodologia AGILE SCRUM, ma chiedendo subito una data TASSATIVA di fine progetto... le due cose non COZZANO ???? cioè, l'avere una data finale di un progetto intero o di un programma non è prerogativa di una approccio waterfall dopo una lunga analisi basata su specifiche precise ? AGILE non lavora per sprint e si prende solo l'obbligo di chiudere lo sprint senza che è una parte del progetto e non il progetto intero ? grazie
Ciao Enrico, in realtà le due cose non cozzano. Ne parlo nel video su cosa signifca essere agili. In estrema sintesi, un progetto ha 3 vincoli fondamentali da rispettare. 1) Un perimetro di lavoro da eseguire (scope) sulla base di quello che devi realizzare e delle relative caratteristiche 2) Vincolo di durata (eventuali scadenze) 3) Vincolo di budget (eventuali tetti di spesa) Nell'approccio tradizionale, come dicevi anche tu, il perimetro di lavoro (lo scope) viene determinato inizialmente con un'attività di analisi piuttosto dettagliata. Una volta definito con precisione cosa dobbiamo realizzare e quanto lavoro richiede, passeremo a stimare tempi e costi. Quindi: scope fisso e tempi e costi variabili. Nell'approccio agile la prospettiva si ribalta. Lo scope non è fisso, perché non sei in grado di determinare all'inizio un perimetro di lavoro ben definito. Non vuol dire che non lo definisci per niente, ma che lo fai solo ad "alto livello". Magari in corso d'opera il perimetro di lavoro cambierà più e più volte in funzione delle esigenze che man mano si manifesteranno. Allora ti conviene ragionare a "tempi e costi fissi" e "scope variabile". Faccio l'esempio dell'e-commerce. Tu dici "ho 3 mesi di tempo e 100K di budget per realizzare il mio e-commerce". Il perimetro di lavoro è noto solo parzialmente. C'è un sottoinsieme di funzionalità irrinunciabili del tuo e-commerce che dovranno esserci per forza, ma tutte le altre le definirai in corso d'opera. Allora, man mano che lavori, ad ogni iterazione scegli quali funzionalità implementare, quelle che ti sembrano di maggior valore e utilità in quel momento e che magari non avevi considerato all'inizio ma che nel frattempo si sono aggiunte. Alla fine, dopo 3 mesi e dopo aver consumato il budget, ti ritroverai il tuo e-commerce con tutte le funzionalità che veramente ti servivano realizzate. Rimarranno fuori solo quelle che di volta sono state valutate sempre meno utili e prioritarie. In pratica, in un ciclo agile rilassi il vincolo di dover per forza realizzare qualcosa con tutte quelle caratteristiche. Fissi tempi e spesa e cerchi di realizzare l'insieme delle funzionalità di maggior valore possibile.
@@MarcoCaressa Grazie, diciamo però che per non far "COZZARE" tu utilizzi un ragionamento di una persona intelligente e con esperienza, il mio problema è differente. Cioè spesso oggi si vuole usare il metodo agile e promettere 10 cose con una data già fissa, si parte con poca analisi e quando ovviamente si capisce che si sta sforando, invece di limare e ridurre le richieste si fa pressione al team per chiudere in fretta con un sacco di straordinari e con pezze che creano solo "debito tecnico". Ti chiedo anche una ultima cosa, lo SRUM MASTER in ambienti software dovrebbe essere un EX programmatore o avere un buon bagaglio tecnico ? perchè nella realtà invece le aziende oggi prendono i PM, fanno fare a loro un corso di 2 weekend e diventano super SCRUM MASTER in 2 week.
L'help desk del nostro software riceve una richiesta di nuova implementazione da un cliente, come da 'manuale' segnala la cosa al PO che si occupa di analizzarla, metterla nel backlog etc. Il feedback di questa cosa al cliente (indicazione di quando gli faremo la modifica, eventuali costi etc.) deve essere dato dal PO o il PO lo dice all'help desk che lo riporta al cliente? O il PO lo dice al ProjectManager/Account manager?
Ciao Marco, come si inserisce la figura del Business Analyst IT in questo tipo di contesto. Leggendo in giro ho capito che è una persona che si occupa di tradurre il linguaggio dei programmatori in quello del cliente e viceversa, ma in tutti i framework non ne vedo la presenza e le mansioni
Il Business Analyst ha dei punti di contatto con il Product Owner Scrum, anche se non sono la stessa cosa. In ogni caso, il Product Owner è la "voce" del cliente, quello che deve individuare le feature di maggior valore per il cliente e definire le priorità di implementazione.
Ciao! Per un sistema Scrum, quale strumento consiglieresti ? Ne ho guardati alcuni, ma sembra che nessuno nasca specificatamente per Scrum, bisogna installare vari template o fare qualche adattamento, non mi hanno convinto molto. Hai qualche consiglio ? Ho provato anche clickup, ma oltre a richiedere, anche lui, l'aggiunta di uno o più template, mi è sembrato molto confusionario, tante funzioni (CRM ecc ecc) e nessuna perfettamente efficace. Meglio un tool che faccia solo 1 cosa e la faccia bene.
Mi sono trovato bene con Monday.com. Non nasce come tool per Scrum (in effetti non esiste un tool Scrum-based) ma consente di definire in modo semplice attraverso delle schede/template gli elementi di base che servono: il backlog, uno Scrum Board per l'avanzamento day-by-day dei task e la possibilità di avere dei Burn-Chart abbastanza facilmente.
@@MarcoCaressa grazie. prova a guardare Zoho Sprints che sembra nasca proprio per Scrum. l'ho usato qualche giorno in prova e tra i vari testati, mi è sembrato il più semplice da usare
Non direi i più difficili. Sono semplicemente due ruoli diversi, che richiedono capacità e competenze diverse. Nulla vieta però di poterli interpretare entrambi. L'importante è non pensare che l'uno possa fare automaticamente l'altro.
Ciao Marco, innanzitutto grazie per cercare di spiegare in termini concreti una cosa che spesso chi sviluppa "subisce" senza capire bene di che si tratti... ma non riesco ancora a capire, perdonami se è una domanda stupida. In un'ottica di consulenza (cioè, la maggior parte dei progetti in Italia) il cliente non sa molto degli aspetti tecnici e realizzativi di quello che desidera, e chiede alla tua azienda un prodotto (mettiamo, un'applicazione) con dei determinati requisiti, che poi vengono elencati in un documento di progetto. Alcuni sono requisiti "di base", altri funzionalità aggiuntive che, comunque, vuole che siano implementate nell'applicazione. In una logica Scrum, il MVP non può essere altro che, in qualche modo, il progetto stesso, con tutti i requisiti implementati. Magari puoi presentarti con una beta a cui manca un "raffinamento" in termini di debug e prestazioni, ma non credo sia fattibile presentarti con un prodotto con solo le caratteristiche "di base" (quindi con delle feature mancanti). Il cliente, nel caso migliore dirà "ah ok, ma non è quello che ho chiesto", nel caso peggiore avrà l'occasione di cambiare idea su scelte già fatte, ampliando e modificando lo scope del progetto. Mi sto perdendo qualcosa, oppure (come mi pare di capire) questo tipo di approccio può funzionare solo per prodotti realizzati "in-house", e non in una logica di consulenza? Grazie!
Ciao, in realtà il concetto di MVP, ma anche più in generale quello di "release" consiste nel rilasciare versioni con meno feature da arricchire poi in seguito. Il modello di delivery agile è incrementale ed è uno dei suoi vantaggi. Altrimenti il cliente vedrebbe il risultato, utilizzabile per lui, solo alla fine. Invece io rilascio una versione con un set base di funzionalità con cui comunque il cliente/committente può iniziare a fare business e a creare valore. Se il cliente si comporta come descrivi non è pronto per lavorare in un contesto agile (dove anche il committente deve essere ingaggiato attivamente e in modo continuo) e allora tanto vale inchiodarlo a delle specifiche funzionali firmate col sangue prima di procedere alla realizzazione :-)
@@MarcoCaressa grazie per la risposta, hai un po’ confermato quello che pensavo… è molto importante anche capire il cliente che si ha di fronte e capire se è adatto, altrimenti può essere un approccio “pericoloso”
In uno sprint di 2 settimane, noi dedichiamo solitamente gli ultimi 2 giorni per il test. I developer testano le issue sviluppati dai colleghi. il PO non fa un test vero e proprio , ma verifica a livello macro che tutte le issue rispettino l'obiettivo. Non ho trovato in giro indicazioni su quando devono essere fatti i test e quanto debbano durare. Sembra quasi che il test non sia contemplato, ma che ogni developer si autotesti in modo 'spinto' ogni qualvolta sviluppa una issue. Qual'è la tua indicazione sui test? Grazie
Ciao Marco, grazie per il tutorial molto utile...ma avrei una domanda da fare relativamente ai progetti SCRUM ovvero come ce li facciamo pagare dal cliente :)? un progetto per convinzione va prima stimato, fatto un preventivo e fatto accettare dal cliente! Nel caso di progetti scrum questa stima iniziale non può avvenire per la natura del framework. grazie in anticipo
Parlo di questo tema proprio nel mio ultimo video sulle stime. Molto brevemente, è opportuno cambiare forma contrattuale. Usi Scrum per sviluppare qualcosa che all'inizio non sei in grado definire completamente. Perciò non si può lavorare col classico schema dove definiamo prima i requisiti, in base a questi stimiamo la realizzazione e infine contrattualizziamo. Con Scrum l'ideale è lavorare a tempi e costi fissi e requisiti variabili. Es. 2 mesi, 50K euro di budget e con quella dotazione cerchiamo di realizzare il miglior prodotto con le funzionalità di maggior valore secondo esigenze che potrebbero emergere in corso d'opera.
@@MarcoCaressa l'ho appena finito di guardare :) è chiaro il discorso di tempi e costi fissi...in un progetto su cui sto lavorando ora abbiamo deciso di stabilire degli sprint settimanali, mammano si chiariscono le idee o il prodotto finale inizia a prendere forma e si capisce che servono ulteriori sviluppi aggiungiamo degli sprint che raggruppano le funzionalità mancanti ed eventuali emersi dallo sviluppo appena concluso. come sempre grazie :)
Ciao Marco bel video molto chiaro. Ho frequentato con successo il corso PM avanzato con ISI PM pre Covid 19 ma non mi sono certificata con Accredia. Vorrei frequentare un corso di lavoro agile (il metodo SCRUM è molto vicino al ns modo di approcciare i progetti e mi piacerebbe approfondire questa modalità). Area trasporti pubblici. Conosci un corso che può fare al mio caso? Come tutte le persone che lavorano non mi è possibile lasciare l'attività a lungo e dunque necessito o di corsi intensi ma di pochi giorni o con poco impegno settimanale ma su più settimane. Grazie mille
Ciao Claudia, per necessità di formazione e applicazione di pratiche di project management tradizionale e agile ti rimando ad una mia nuova iniziativa: Progettualitalia, una community digitale di Project Management che sarà operativa tra poche settimane. Ci saranno corsi e materiale anche su Scrum ;-)
Beh, sulla piattaforma potrai trovare tra poche settimane proposte di formazione per tutte le esigenze. Dal corso di Project Management base per chi si avvicina a corsi più strutturati per preparare specifiche certificazioni. Oppure, in alternativa, se non vuoi seguire un corso online, puoi consultare il blog, scaricarti materiale, documenti, template e altro ancora. Puoi sottoscrivere un abbonamento per il tempo che desideri e per la fascia di servizi che desideri. Insomma, puoi ritagliarti su misura l'abbonamento che serve a te. Se ti registri al link che ti ho dato avrai comunque diritto al 20% per i primi 6 mesi per qualsiasi abbonamento sottoscriverai.
Sono in parte d'accordo con te. Il problema è che un framework è, appunto, una "cornice" da interpretare e il modo con cui la si interpreta è fondamentale.
@@MarcoCaressa e' questo il problema se va interpretato non funzionerà a meno che non metti uno SM con il cronometro che chiude le riunioni sullo scadere. Tutte quelle fasi poi non aggiungono nulla al lavoro reale.
