{"id":89332,"date":"2017-01-30T15:14:42","date_gmt":"2017-01-30T14:14:42","guid":{"rendered":"http:\/\/artigianodelsoftware.it\/blog\/?p=89332"},"modified":"2017-01-30T15:14:42","modified_gmt":"2017-01-30T14:14:42","slug":"agile-in-jira-scrum-kanban-scrumban","status":"publish","type":"post","link":"https:\/\/artigianodelsoftware.it\/blog\/2017\/01\/30\/agile-in-jira-scrum-kanban-scrumban\/","title":{"rendered":"Agile in JIRA – Scrum, Kanban, Scrumban"},"content":{"rendered":"
\"image_pdf\"<\/a><\/a><\/div>
\n

Kanban, Scrum, Scrumban, …<\/h1>\n<\/blockquote>\n

In questo post andremo a proseguire l’esplorazione sulla metodologia\u00a0AGILE, concludendo l’introduzione di questo argomento.<\/p>\n

<\/a><\/p>\n

\n

Definizioni preliminari<\/h1>\n<\/blockquote>\n

Per alcune definizioni preliminari, vi rimando al seguente link del sito Agileway.it<\/a>, dove ho trovato delle indicazioni molto ben fatte.<\/p>\n

<\/a><\/p>\n

\n

Kanban<\/h1>\n<\/blockquote>\n

Per spiegare in cosa consiste\u00a0Kanban, sfruttiuamo\u00a0A brief introduction to kanban, di Dan Radigan<\/a>, dove il lettore viene indirizzato in un percorso abbastanza chiaro e semplice (Si tratta di un articolo in inglese, ma stiamo lavorando per rendere disponibile queste documentazioni in italiano). Cercheremo di dare una spiegazione il pi\u00f9 semplice,\u00a0ma anche il pi\u00f9 chiaro possibile.<\/p>\n

<\/a><\/p>\n

L’approccio Kanban<\/strong> <\/em>bene si adatta a quelle situazioni in cui si hanno sempre delle attivit\u00e0 continue da svolgere.<\/p>\n

Il Product Owner scompone il lavoro in tanti piccoli task, pi\u00f9 o meno complessi, modificando l’ordine degli stessi e inserendo in cima quelli con maggiore priorit\u00e0. In questo modo \u00e8 sempre possibile rischedulare il lavoro del team senza dover bloccare il lavoro del team.<\/p>\n

Il Team di sviluppo verifica i task da eseguire, seleziona quello in cima al backlog<\/strong> <\/em>e lo porta a compimento. Quando lo seleziona, lo sposta dalla colonna To Do<\/strong><\/em> alla colonna Doing<\/strong><\/em>. Quando lo completa, lo sposta nella colonna Done<\/strong><\/em>.<\/p>\n

Quando si ha a disposizione un insieme di task completati, si procede con un rilascio del nuovo software.<\/p>\n

Questo approccio \u00e8 molto pi\u00f9 indicato nella manutenzione che nello sviluppo di nuove applicazioni.<\/p>\n

\n

Scrum<\/h1>\n<\/blockquote>\n

<\/a><\/p>\n

A differenza della precedente, la Scrum<\/strong> <\/em>ben si adatta allo sviluppo di un nuovo progetto. Andiamo a capire meglio:<\/p>\n

Scrum<\/strong> <\/em>struttura il proprio\u00a0sviluppo in cicli chiamati Sprint<\/strong> <\/em>che durano da una a quattro settimane, al termine dei quali il team di sviluppo rilascia funzionalit\u00e0 immediatamente testabili.<\/p>\n

In Scrum<\/strong> <\/em>non abbiamo una figura di Project manager che coordina il team, ma possiamo dire che il team stesso \u00e8 in qualche modo auto-organizzato. Tutte le competenze per la realizzazione del progetto sono presenti in tutti i membri del team stesso. Con questo non voglio dire che il project manager non esiste in tali organizzazioni, fa solo qualcosa di differente.<\/p>\n

Prima di iniziare i lavori, il team si riunisce e definisce i task che saranno sviluppati definendo una Sprint. Nel definirli si impegna a completarli entro la fine della stessa. Una volta definiti, questi task sono inseriti nel backlog e si iniziano i lavori.<\/p>\n

Ogni giorno il team si confronta nello Stand-up Meeting, che deve durare non pi\u00f9 di 15 minuti, dove deve emergere lo stato di avanzamento, problemi e criticit\u00e0. Obbiettivo \u00e8 di identificare subito ci\u00f2 che pu\u00f2 bloccare il lavoro del team e rimuoverlo in modo da consentire il normale svolgimento delle attivit\u00e0.<\/p>\n

Al termine della sprint si rilascia ci\u00f2 che \u00e8 stato completato, mettendo a disposizione una funzionalit\u00e0 completa e testata, testabile a sua volta dal cliente.<\/p>\n

\n

Scrumban<\/h1>\n<\/blockquote>\n

Si tratta di una composizione delle due tecniche, un cui abbiamo l’unione di quanto di meglio abbiamo dai due approcci precedentemente indicati. Ho trovato, facendo delle ricerche, il seguente link<\/a> per una bella immagine che descrive abbastanza bene visivamente che cosa\u00a0\u00e8 Scrumban, che mi sembra molto chiara e precisa. Maggiori dettagli li ho identificati qui <\/a>(in inglese).<\/p>\n

<\/a><\/p>\n

Scrumban mette insieme l’interazione continua di Kanban, aggiungendo una limitazione agli slot di task che devono essere eseguiti contemporaneamente. \u00a0In Scrumban, il gruppo di lavoro \u00e8 organizzato in piccole interazioni e monitorato attraverso una board similare a Scrum e Kanban.<\/p>\n

Si lavora solo su di un sottoinsieme di user story, che vengono\u00a0scelte attraverso dei planning meeting, che hanno l’obbiettivo di predisporre delle vere e proprie Sprint. Per tenere le interazioni molto basse, Il WIP (Work in Progress) di ogni stato.<\/p>\n

 <\/p>\n

\n

Kanban Vs Scrumban<\/h1>\n<\/blockquote>\n

La seguente immagine riassume le differenze tra Kanban e Scrumban.<\/p>\n

<\/a><\/p>\n

 <\/p>\n

\n

Scrum Vs Scrumban<\/h1>\n<\/blockquote>\n

La seguente immagine riassume le differenze tra Scrum a Scrumban:<\/p>\n

<\/a><\/p>\n

 <\/p>\n

\n

Conclusioni<\/h1>\n<\/blockquote>\n

In questo post abbiamo concluso l’introduzione alla programmazione Agile. Spero di aver fornito le basi per poter iniziare ad approfondire questi nuovi argomenti o quanto meno\u00a0di aver introdotto degli argomenti interessanti.<\/p>\n

Nei prossimi post iniziamo a calare questi concetti su JIRA SOFTWARE<\/strong><\/em>, verificando che cosa sia possibile realizzare e come.<\/p>\n

\n

Ringraziamenti<\/h1>\n<\/blockquote>\n

Ringraziamenti per l’aiuto a Michael Forni, che \u00e8 stato un valido supporto ed aiuto nella redazione di questi articoli. Di seguito i suoi contatti:<\/p>\n