Insieme abbiamo compreso cos'è e cosa non é Agile (per chi si fosse perso la puntata precedente può trovare tutto in questo post). Oggi facciamo un passo avanti e scopriamo i due famosi framework che nascono da Agile. Sì esatto, stiamo proprio parlando di Scrum e Kanban. Cosa sono? Come si utilizzano? Quale tra i due è il più giusto per te? Lo sappiamo: le cose da dire e da sapere su di loro sono tantissime ma prima di continuare facciamo un attimo un passo indietro.
AGILE vs METODO WATERFALL
Il gioco e le parole si stanno facendo troppo difficili? Non lasciarti spaventare dai nomi. Il Product Backlog è la lista di tutto ciò che si vorrebbe fare, in base alle priorità, all’interno del progetto. E ahimè mi dispiace dirlo ma non sempre volere è potere: non tutto ciò che viene inserito nella Product Backlog viene infatti sviluppato e rilasciato. Cosa non mancano mai in questa lista? L’ordine, le priorità, il valore che ogni item apporta con il suo sviluppo al cliente, la vivacità e la revisione costante del documento. Il Backlog è infatti un documento attivo, quotidianamente rivisto e modificato dal Product Owner.
SCRUM vs KANBAN
Ed eccoci arrivati al tema clou, ovvero a ciò che porta l’Agile Scrum a differenziarsi dal Kanban.
AGILE SCRUM: COS’É?
Trasparenza - il processo e i suoi sviluppi devono essere visibili e comprensibili ai responsabili del lavoro. La trasparenza richiede quindi un linguaggio comune e condiviso tra i partecipanti al progetto.
Ispezione - i prodotti e i progressi devono essere ispezionati frequentemente per individuare eventuali ostacoli per il raggiungimento degli obiettivi.
Adattamento - quando il prodotto è lontano dalla desiderata é necessario intervenire subito sul processo per limitare lo scarto rispetto agli obiettivi prestabiliti.
SCRUM: IL TEAM.
Quali sono le figure coinvolte nel processo Scrum? Da chi è composto il Team Scrum?
Product Owner - è il Responsabile del Prodotto, identifica gli item in relazione alla richiesta del cliente e li inserisce in base alle priorità nella Product Backlog.
Team di Sviluppo - è il team che svolge il lavoro effettivo, auto organizzandosi, sviluppando e consegnando il prodotto.
Scrum Master - è colui che facilita una corretta esecuzione del processo, rimuovere gli ostacoli che si incontrano nel percorso di sviluppo, tiene concentrato il Team di sviluppo sulle cose da fare, sfidandolo a migliorare. Nonostante il ruolo manageriale, rispetto al Project Manager non ha responsabilità nella gestione del personale.
SCRUM, IL PROCESSO.
Le fasi principali dello Scrum sono le seguenti:
Sprint Planning Meeting - il Product Owner, Scrum Master e il Team di prodotto selezionano dalla Product Backlog, in base alla priorità, gli item. Quest’ultimi vengono frammentati, semplificati e visti in termini di tempo di sviluppo necessario. Niente viene imposto dall’alto come nel tradizionale Metodo Waterfall, ma é lo stesso Team di prodotto che insieme al Product Owner si impegna responsabilmente a valutare quali item possono essere sviluppati e rilasciati nella Sprint. Per l’intera durata dello Sprint il team si focalizza solo sull’obiettivo da raggiungere e sugli item da rilasciare: la bravura del Product Owner e dello Scrum Master sta proprio nel lasciar lavorare il team su questo e arrivare al goal.
Daily Scrum - ogni giorno viene fatto un meeting dove lo Scrum Master e il Team di prodotto discutono, vengono spostati i task con l’obiettivo di muoversi verso il done (= fatto), identificando gli impedimenti che rallentano il lavoro. Ogni partecipante risponde a tre domande: Cosa ho fatto dall’ultima riunione? Cosa farò da adesso alla prossima riunione? Cosa ti impedisce di fare quello che hai pianificato? Grazie al Daily Scrum il Team ha una visione generale ma allo stesso tempo dettagliata del progetto e del suo andamento.
Sprint Review - questa fase non é altro che una dimostrazione delle funzionalità aggiunte dagli stakeholders. Un momento importante di condivisione e collaborazione intra Team: un modo per suscitare commenti e apportare miglioramenti.
Sprint Retrospective - il lavoro completato viene rilasciato mentre tutti gli item incompleti tornano al Product Backlog. In questa fase viene quindi fatta un’analisi di quello che é andato bene, di quello che é andato male, di ciò che può essere migliorabile nella Sprint successiva. Una valutazione che diviene punto di una nuova partenza.
AGILE KANBAN: COSA È?
Eccoci qua arrivati al secondo framework costruito sull’Agile, il Kanban. Ed eccoci qua ad individuare la principale differenza con lo Scrum.
Nel Kanban, a differenza dello Scrum, non si parla di Sprint ma di processo di sviluppo continuo. Esiste un limite massimo di item per ogni colonna di lavoro chiamato Work In Progress Limit: ciò permette di spostare le attività velocemente da una colonna all’altra, non fermando mai il flusso di lavoro e dando solo così la possibilità a nuovi item di essere inseriti. Il primo beneficio? Si riduce la sovrapproduzione, in quanto si produce solo su richiesta, nel momento e nella quantità richiesta.
Kanban aiuta a migliorare l’efficienza produttiva: questa parola giapponese, traducibile in italiano come “tabellone” e usato all’origine nella società Toyota, è oggi uno tra i sistemi di gestione del lavoro più utilizzati. Pianificando secondo le priorità le attività, attraverso Kanban, potrai avere una lettura immediata e trasparente del progetto e del suo andamento.
AGILE KANBAN, IL PROCESSO.
Possiamo iniziare a spiegare il processo su cui si basa Kanban partendo proprio dal suo nome. Kanban si sviluppa infatti su una Kanban Board, ovvero una lavagna in cui il flusso di lavoro segue un andamento da sinistra verso destra e dove le colonne indicano gli stati di avanzamento del progetto. All’interno della Kanban Board vengono create le carte Kanban, cioè le singole attività con tutti i relativi documenti e dettagli, eseguite in base a tempi di consegna e priorità. Quindi il primo passo è creare le task e assegnarle al più giusto membro del team; i partecipanti al team spostano poi le carte Kanban sulla Board a mano a mano che completano le loro attività. Questa organizzazione permette di visualizzare il flusso di lavoro di qualsiasi progetto, evitare la sovrapproduzione delle attività in corso e monitorare le attività in tempo reale migliorando quindi l’efficienza del team.
Ogni volta che uno spazio in una colonna viene liberata si può muovere un altro item nella colonna successiva. il Kanban è molto più flessibile dello Scrum: di fondo l’auto organizzazione è fondamentale in quanto non c’è uno Sprint planning come non vi sono date fisse in cui il team deve rilasciare. Rispetto al Tempo, prioritario nello Scrum, nel Kanban è lo scopo ad avere la meglio.
SCRUM O KANBAN?
Ci sono domande e domande. Questa è una di quelle difficili. Entrambi, sia Scrum che Kanban vanno bene. Entrambi sono la risposta giusta. Perché?
Perché quando si parla di Agile una delle cose più importanti che non devi assolutamente dimenticare è che non si sta parlando di una tecnica ma di una filosofia, di un approccio. Entrambe le metodologie, sia Scrum che Kanban, possono essere quindi da te provate, interpretate e migliorate a seconda delle tue esigenze. Inoltre si è diffuso da alcuni anni un ibrido, Scrumban, che unisce il meglio dei due framework. Scrumban si basa infatti sul metodo di lavoro Scrum, aggiungendo elementi mutuati da Kanban: uno strumento flessibile ma rigoroso.
Siamo arrivati alla fine di questo post ma resta sintonizzato: per te molte altre informazioni in arrivo!