Innanzitutto complimenti per il contenuto e lo stile della presentazione. Non sono assolutamente un esperto di scrum e di metodi agili ma ho apprezzato molto il fatto che hai puntualizzato che un progetto agile comunque deve avere dei paletti (tempi e costi a scapito dello scope). La mia impressione di profano è che lo scrum vada molto bene per il product management ma necessita di qualche correttivo (o integrazione) per il project management. Secondo me se voglio usare lo scrum per un progetto devo fare qualcosa in più nell'ultimo sprint: -supporto per lo hand-over verso chi farà il product management e quindi verifica della documentazione costruita in modo incrementale nei vari sprint per assicurare completezza, correttezza e coerenza dei contenuti -una tosta campagna di regression test se negli sprint precedenti non ho potuto fare test completi in precedenza ma solo sull'incremento -una major sprint review perché non ci saranno ulteriori sprint: quello che c'è e quello che non c'è non ci sarà. Cosa ne pensi? Grazie
Ciao Gianfranco, hai messo parecchia carne al fuoco (o verdura, come preferisci). Tendenzialmente Scrum può coprire l'intero ciclo di prodotto, di cui quello di progetto è solo una parte. Ma può essere usato con profitto anche per progetti con hand-over. In questo caso, se il team di conduzione sarà diverso da quello di sviluppo (cosa che a prescindere da quello che ci piaccia, accade spesso per vincoli contrattuali) è sicuramente necessario un "Knowledge transfer" che potrebbe richiedere un supplemento di documentazione. Sul regression test non mi trovi d'accordo. Se parliamo di progetti software, mi preoccuperei parecchio se ogni sprint testasse solo l'incremento, per poi magari scoprire alla review che abbiamo smontato qualcosa che prima funzionava... Sul major sprint review non trovo sia necessario, non ho mai avuto l'esigenza di usarla. L'ultimo sprint coincide sempre con una release finale (almeno secondo il release planning concordato) e la review non è necessariamente diversa da qualsiasi altra.
No Francesco. MVP (Minimum Viable Product) è una versione preliminare di un prodotto da proporre a utenti/clienti target per testare delle caratteristiche che potrebbero far parte di una versione rilasciabile. Il termine "viable" va inteso come sinonimo di "fattibile". MMP (Minimum Marketable Product) invece è una versione di prodotto con il set minimo di caratteristiche/funzionalità che ne giustificano la commercializzazione. Normamente il MVP dopo un po' - se non viene abbandonato - evolve in un MMP.
Ma a parte i tecnicismi, a parte le definizioni agile=tempi costi fissi e scope variabile. Tu, Marco Caressa, hai mai dovuto gestire un progetto dove ti venivano anticipate le scadenze? Che contesto era? Cosa hai fatto concretamente? di sicuro non avrai snocciolato al tuo team una definizione "bla bla tempi costi fissi scope variabile..". Mi piace il tuo approccio pop, ma non ti sento ancora mettere parte di te in questi video, ma solo parte di quello che sai. Che forse, mia ignorabilissima opinione, fa la differenza fra i creatori di contenuti di successo e quelli che fanno qualche visita. Per mia esperienza, non sono le definizioni o l'applicazione rigorosa di regole o standard a fare la riuscita di un progetto: per quanto sia importante la teoria, è fondamentale la pratica, le esperienze. Avrai sbagliato anche tu? Raccontacelo. Come sempre, spero di darti un feedback costruttivo.
Fabio i tuoi commenti danno sempre spunti utili. Non si possono soddisfare tutti gli stakeholder, è inevitabile. Cerco sempre di fare esempi concreti. Stavolta quello della app. E scope variabile / tempi fissi non è teoria o tecnicismo ma pratica quotidiana. Qualche volta lo si deve ricordare (e l'ho ricordato in diversi casi) anche al team oltre che raccontarlo in un canale di divulgazione 😎
Innanzitutto complimenti per il contenuto e lo stile della presentazione.
Non sono assolutamente un esperto di scrum e di metodi agili ma ho apprezzato molto il fatto che hai puntualizzato che un progetto agile comunque deve avere dei paletti (tempi e costi a scapito dello scope). La mia impressione di profano è che lo scrum vada molto bene per il product management ma necessita di qualche correttivo (o integrazione) per il project management. Secondo me se voglio usare lo scrum per un progetto devo fare qualcosa in più nell'ultimo sprint:
-supporto per lo hand-over verso chi farà il product management e quindi verifica della documentazione costruita in modo incrementale nei vari sprint per assicurare completezza, correttezza e coerenza dei contenuti
-una tosta campagna di regression test se negli sprint precedenti non ho potuto fare test completi in precedenza ma solo sull'incremento
-una major sprint review perché non ci saranno ulteriori sprint: quello che c'è e quello che non c'è non ci sarà.
Cosa ne pensi?
Grazie
Ciao Gianfranco, hai messo parecchia carne al fuoco (o verdura, come preferisci). Tendenzialmente Scrum può coprire l'intero ciclo di prodotto, di cui quello di progetto è solo una parte. Ma può essere usato con profitto anche per progetti con hand-over. In questo caso, se il team di conduzione sarà diverso da quello di sviluppo (cosa che a prescindere da quello che ci piaccia, accade spesso per vincoli contrattuali) è sicuramente necessario un "Knowledge transfer" che potrebbe richiedere un supplemento di documentazione.
Sul regression test non mi trovi d'accordo. Se parliamo di progetti software, mi preoccuperei parecchio se ogni sprint testasse solo l'incremento, per poi magari scoprire alla review che abbiamo smontato qualcosa che prima funzionava...
Sul major sprint review non trovo sia necessario, non ho mai avuto l'esigenza di usarla. L'ultimo sprint coincide sempre con una release finale (almeno secondo il release planning concordato) e la review non è necessariamente diversa da qualsiasi altra.
Ho preso il libro di Gaito! A quando il tuo?
Progetto impegnativo...😎
@@MarcoCaressa ma tu ne hai di cose da dire...e non supercazzole mi sembra...
Ah ma non sono asteroidi quelli che dobbiamo gestire ogni giorno? 😅
Asteroidi e...ortaggi di vario tipo 😎
MMP = MVP giusto?
No Francesco. MVP (Minimum Viable Product) è una versione preliminare di un prodotto da proporre a utenti/clienti target per testare delle caratteristiche che potrebbero far parte di una versione rilasciabile. Il termine "viable" va inteso come sinonimo di "fattibile". MMP (Minimum Marketable Product) invece è una versione di prodotto con il set minimo di caratteristiche/funzionalità che ne giustificano la commercializzazione. Normamente il MVP dopo un po' - se non viene abbandonato - evolve in un MMP.
@@MarcoCaressa perfetto, grazie!
Ma a parte i tecnicismi, a parte le definizioni agile=tempi costi fissi e scope variabile. Tu, Marco Caressa, hai mai dovuto gestire un progetto dove ti venivano anticipate le scadenze? Che contesto era? Cosa hai fatto concretamente? di sicuro non avrai snocciolato al tuo team una definizione "bla bla tempi costi fissi scope variabile..". Mi piace il tuo approccio pop, ma non ti sento ancora mettere parte di te in questi video, ma solo parte di quello che sai. Che forse, mia ignorabilissima opinione, fa la differenza fra i creatori di contenuti di successo e quelli che fanno qualche visita. Per mia esperienza, non sono le definizioni o l'applicazione rigorosa di regole o standard a fare la riuscita di un progetto: per quanto sia importante la teoria, è fondamentale la pratica, le esperienze. Avrai sbagliato anche tu? Raccontacelo. Come sempre, spero di darti un feedback costruttivo.
Fabio i tuoi commenti danno sempre spunti utili. Non si possono soddisfare tutti gli stakeholder, è inevitabile. Cerco sempre di fare esempi concreti. Stavolta quello della app. E scope variabile / tempi fissi non è teoria o tecnicismo ma pratica quotidiana. Qualche volta lo si deve ricordare (e l'ho ricordato in diversi casi) anche al team oltre che raccontarlo in un canale di divulgazione 😎
Poffarre poffarrissimo, assolutamente trovare il tempo di guardare questo video
Secondo me l'hai già trovato 😎
@@MarcoCaressa l'arte di impiegare il tempo solo con i video veramente utili