{"id":651,"date":"2021-01-20T15:15:39","date_gmt":"2021-01-20T14:15:39","guid":{"rendered":"https:\/\/www.chiarini.it\/blog\/?p=651"},"modified":"2024-04-18T17:00:39","modified_gmt":"2024-04-18T15:00:39","slug":"pianificazione-agile-scrum-kanban-vs-waterfall","status":"publish","type":"post","link":"https:\/\/www.chiarini.it\/blog\/pianificazione-agile-scrum-kanban-vs-waterfall\/","title":{"rendered":"Pianificazione AGILE, SCRUM & Kanban Vs Waterfall"},"content":{"rendered":"\n
\"\"
Applicazioni di SCRUM e Kanban per cliente Chiarini & Associati<\/figcaption><\/figure><\/div>\n\n\n\n

Nel 2001 un gruppo di 17 sviluppatori di software scrisse il manifesto AGILE inconsapevoli di lanciare 12 principi che sarebbero stati poi seguiti in tutto il mondo, anche al di fuori del settore dell’information technology. Il manifesto ed i suoi principi \u00e8 consultabile nella sua forma originaria a questo indirizzo: https:\/\/www.agilealliance.org\/agile101\/12-principles-behind-the-agile-manifesto\/<\/a><\/p>\n\n\n\n

Fra i valori fondamentali di questo manifesto vogliamo concentrarci su tre in particolare che veramente hanno fatto la differenza: “Collaborazione con il cliente piuttosto che negoziazione contrattuale” ; “Individui ed interazioni pi\u00f9 importanti dei processi e strumenti” ; “rispondere al cambiamento piuttosto che seguire un piano<\/strong>“. Leggendo bene il manifesto AGILE \u00e8 chiaro che molta ispirazione proviene dai principi e strumenti Giapponesi del Toyota Production System. Ma vediamo il perch\u00e9 gli strumenti e principi AGILE sono diventati importanti anche in altri settori. <\/p>\n\n\n\n

Innanzitutto, partiamo con il notare che il Toyota Production System, Lean che sia, non \u00e8 mai stato forte nell’ambito Design Management. Gli strumenti del Design Management classici quali il QFD, il Design To Cost, il Design For Assembly and Manufacturing, la FMEA,<\/strong> etc. da decenni continuano ad esistere senza influenza alcuna da parte del mondo Lean. Date un occhio a questo nostro ulteriore articolo<\/a> per capirlo da soli. Secondo, gli uffici tecnici e l’R&D sono diventati sempre pi\u00f9 “turbolenti” riducendo drasticamente il Time-To-Market<\/strong>. Il mercato \u00e8 sempre pi\u00f9 agile e pretende risposte sempre pi\u00f9 veloci; la messa appunto dei vaccini Covid \u00e8 stata la dimostrazione per tutti. Dimentichiamoci, quindi, sempre di pi\u00f9, ambiti da societ\u00e0 di ingegneria vere e proprie, con progetti su pi\u00f9 anni, step ben precisi, requisiti negoziati con il ciente all’inizio e poi “scolpiti nella roccia”. <\/p>\n\n\n\n

Nel passato ci siamo abituati ai metodi cosiddetti di Waterfall<\/strong> o di Stage & Gate<\/strong> dove il progetto, dal punto di vista temporale, \u00e8 diviso in specifiche e distinte fasi (stage) separate fra di loro da un punto di decisione (una milestone<\/strong> o gate). Praticamente il punto di decisione \u00e8 in mano ad un project manager o ad un team di manager che decidono se andare avanti o meno con le altre fasi in base al raggiungimento di determinati obiettivi e risultati. Tipicamente questo approccio porta a lavorare “in serie” piuttosto che in parallelo a dispetto del cosiddetto concurrent engineering<\/strong> e della riduzione del Time-To-Market. <\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

La figura sopra mostra, schematicamente un waterfall classico del settore manifatturiero dove ogni macro fase in arancio \u00e8 divisa dalle restanti tramite una milestone in azzurro. Le fasi in questo classico approccio sono gestite con strumenti noti del Project Management<\/strong> quali il Gantt,<\/strong> il PERT<\/strong> ed il CPM<\/strong>. La figura sotto mostra una parte di un Gantt dove un’intera fase di analisi di fattibilit\u00e0 \u00e8 scomposta in varie attivit\u00e0 (Work Package<\/strong>) ed una milestone finale divide la fase dalla successiva in waterfall (progettazione e sviluppo prodotto).<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Al contrario, il movimento AGILE ha puntato su strumenti pi\u00f9 idonei al continuo e veloce cambiamento sia delle attivit\u00e0 sia dei tempi. Lo SCRUM<\/strong> \u00e8 stato il primo strumento adottato in ambito AGILE. Ideato negli anni ’90 da Jeff Sutherland e Ken Schwaber, deve il suo successo alle prime applicazioni in Yahoo e Google. Il nome SCRUM (mischia dal gioco del Rugby) in realt\u00e0 \u00e8 stato portato all’attenzione di tutti dal Giapponese Ikujiro Nonaka in un famoso articolo apparso su Harvard Business Review, anche se lo SCRUM di oggi \u00e8 particolarmente diverso come strumento applicativo.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

Lo strumento SCRUM si basa su:<\/p>\n\n\n\n