Un approfondimento

In questo post andremo ad approfondire alcuni aspetti di collaborazione tra utenti, agenti di JIRA Service Desk e sviluppatori.

Un piccolo recap….

In precedenti post abbiamo visto come si è evoluto JIRA Service Desk, che adesso andiamo a riassumere:

• Agenti, che si occupano di gestire le richieste
• Utenti, che si occupano di creare le richieste
• Partecipant, ovvero un utente o un agente o un utente JIRA di altri progetti (lo sviluppatore o altro ruolo)

Questo ultimo è la nostra arma segreta, perchè ci permette di aggiungere persone alla segnalazione, in modo da consentirgli di poter leggere la segnalazione e di consentirgli di partecipare attivamente alla segnalazione.

Tenete sempre presente che tutti i prodotti della Atlassian si basano sempre sulla collaboration ed in questo articolo andremo a vedere come un Agente può richiedere l’aiuto di più soggetti per arrivare a risolvere la segnalazione dell’utente

Un caso di uso

Proseguiamo nella nostra esplorazione, analizzando e spiegando meglio questa situazione.

L’agente, quando riceve una segnalazione, può chiedere il supporto di uno sviluppatore o di un altro utente JIRA e una prima operazione che può eseguire è quella di inserire un nuovo partecipant, ovvero coinvolgere un utente nella risoluzione chiedendo delle informazioni particolari. Questo si può realizzare semplicemente con un click, direttamente dal task jira, quando si entra nel dettaglio della segnalazione.

Oppure possiamo anche inserire direttamente un commento interno, in cui andiamo a referenziare un utente, nel nostro caso potrebbe essere uno sviluppatore, cui chiediamo un supplemento di spiegazioni. le mentions ci aiutano tantissimo 😀

Un’altra possibilità è quella di aprire una segnalazione direttamente al progetto di manutenzione/sviluppo utilizzando l’apposita funzione, che permette di creare una issue collegata alla nostra di Service Desk..

In questo modo lo sviluppatore dispone già della segnalazione originaria, da cui ricava tutto ciò che gli serve, e può già lavorare alla risoluzione della stessa.

Conclusioni

Vediamo come nei prodotti Atlassian la collaborazione è sempre al centro di tutto. Non averemo mai persone sole contro gli utenti cattivi, ma delle squadre, dei team che si occupano di gestire le situazioni.

Reference

Maggiori informazioni sono presenti nel seguente articolo su JIRA Service Desk, da cui ho preso spunto per costruire questo articolo.

Analizziamo alcuni addon per Confluence

In questo post andiamo ad analizzare alcuni addon per Confluence che risultano interessanti. Cerchiamo di analizzarli e proviamo ad immaginarne un possibile utilizzo che ne possiamo fare 🙂

Vediamoli in dettaglio

Partiamo da Atlas CRM for Confluence, che permette di poter organizzare le informazioni dei clienti di una azienda attraverso le pagine di Confluence. Avevo già esaminato la possibilità di poter realizzare questa funzione, sfruttando le funzioni standard che Confluence mette a disposizione. In questo caso, l’addon permette di automaticcare e meglio organizzare tali informazioni. Lavorabndo a stretto contatto con JIRA, sfruttando le potenzialità di Confluence, abbiamo la possibilità di poter disporre delle informazioni in maniera più agevole, come mostrato in figura:

Usandolo con JIRA ci permette di poter gestire il nostro parco clienti, mettendo a disposizione una serie di interfaccie predisposte e ben congegnate :-). Non male 😀

Proseguiamo con Agile Retrospectives for Confluence, che permette di creare delle retrospettive su Confluence relativamente a Sprint concluse.

Addon utile nel caso di gruppi di lavoro particolarmente distribuiti nel mondo.

Continuiamo parlando di Refined Theme for Confluence Cloud, ovvero la possibilità di poter modificare lo stile e la grafica del nostro Confluence Cloud, in maniera semplice e veloce

consentendo di avere la possibilità di poter facilmente personalizzare il layout:

Abbiamo adesso la possibilità di poter personalizzare il nostro Confluence Cloud. Possiamo quindi arrivare a condividere delle sezioni della nostra documentazione fornendo una grafica differente :-).

Proseguiamo visionando Responsive Tabs, ovvero un addon che permette di poter inserire dei tab nelle nostre pagine confluence:

sfruttando delle macro molto semplici, come già abituati da Confluence.

Possiamo, con questo addon, arrivare a gestire delle sezioni dedicate ed organizzare meglio lo spazio della pagina. Non male come addon e ci possono essere tantissimi ambiti in cui possiamo applicare queste macro 😀

Terminiamo con Knowledge Pathways for Confluence. Si tratta di un addon creato per scopi didattici e che permette di creare un percorso che può essere utilizzato per descrivere una sequenza di passi, connessi a pagine confluence, ben precisa ed organica. Un esempio è sicuramente la fase di onboarding di un nuovo dipendente, in cui sono specificate quali informazioni deve conoscere, descrivere i ruoli aziendali, etc.

Conclusioni

Abbiamo visto una panoramica di alcuni addon per Confluence. Per alcuni di questi ho già in mente un utilizzo particolare, dove possiamo impostare delle pagine molto interessanti e utiuli per la vita di tutti i giorni. Nei prossimi post andremo ad esaminare come possiamo usare questi addon  e cercheremo di esaminarne di nuovi.

Citazioni

Lo spunto per scrivere questo post mi è stato fornito da questo articolo in inglese, scritto  molto bene, e che mi ha dato diverse idee.

Ultime novità

In questo post andremo ad esaminare le ultime novità che sono state rilasciate su Kanoah versione 3.3.0 e 3.3.1, il primo che viene eseguito dopo l’acquisizione da parte della Adaptavist. Da segnalate che sono stati ben ascoltati i feedback degli utenti.

Subito al dunque

Andiamo subito al sodo, andando ad esaminare le ultime news.

Re-design of Add Test Case to Test Run

Il layout è stato ridisegnato ascoltando tutti i feedback che sono stati forniti.

Extended REST API Support

Le API REST sono state estese con nuove funzioni, sempre ascoltando il feedback degli utenti. Un nuovo endpoint è disponibile per gestire test case/run custom fields, alla creazione e nei metothi di ricerca.

JQL Searching for adding JIRA issues to Test Coverage

Aggiunto il supporto per le ricerche JQL avanzate per l’aggiunta delle issue JIRA ai Test Coverage. Si posso usare sia filtri salvati che generare JQL custom

Export Test Cases to XLS

Possibile adesso eseguire lo scarico dei Test Case in formato XLS.

Add Test Coverage when editing Test Cases in bulk

Adesso è possibile eseguire l’editing dei Test Cases usando il bulk edit.

Conclusioni

Sempre sempre sempre ottime notizie dal fronte Kanoah. Rimaniamo in attesa delle ultime novità.

Test addon

In questo post completiamo quanto iniziato nel precedente post, andando a testare materialmente l’addon.

Dove eravamo rimasti?

Eravamo arrivati alla Dashboard che l’addon ci mette a disposizione. Da qui riprendiamo il nostro test, definendo i nostri primi obbiettivi :-D.

Eravamo rimasti alle definizioni, che a prima vista sembrano molto complicate, ma adesso andiamo a vedere come applicarli 🙂

Primo passo

Come primo passo andiamo a definire i nostri Objective. Andiamo prima a selezionarli dal menù a sinistra: 

Da qui possiamo selezionare le funzionalità, ma anche dalla dashboard:

dove abbiamo una apposita bottoniera da cui possiamo scegliere i nostri Objective. Quando andiamo a creare il nostro Objective, andiamo a specificare diversi parametri.

Nella precedente immagine abbiamo specificato alcuni parametri di test :-P. Il risultato della operazione è il seguente:

dove andiamo subito a gestire il nostro Objective. Il menù presente nella riga ci mette a disposizione le seguenti funzionalità:

Da qui possiamo subito aggiungere le metriche e possiamo subito inserire i risultati/avanzamenti attraverso il menù Punch In.  Da li impostiamo la percentuale di avanzamento.

In alternativa possiamo definire dei TASK JIRA o dei TO DO ed usarli per definire dei veri e propri task da assegnare alle persone per poi …. raggiungere i nostri obbiettivi 🙂

Ok. Semplice…. e poi??

Possiamo definire i vari obbiettivi su vari livelli:

• Aziendali
• Personali
• Gruppi di lavoro

e arrivare a perseguirli e per arrivare a raggiungerli. La Dashboard ci aiuta nel tenere sotto controllo il tutto

Conclusioni

Abbiamo la gestione dei nostri obbiettivi unita alla potenza di JIRA 😀 .  Questo addon permette di definire degli obbiettivi e, attraverso l’uso di JIRA, ci aiuta a tenerli sotto controllo ed a gestirli.

Test addon

In questo post andremo a completare quanto riportato nella parte di presentazione dell’addon, cercando come sempre di arrivare a identificare quali caratteristiche mette a disposizione e come ci può aiutare nel lavoro di tutti i giorni.

Installazione

Partiamo sempre dalla procedura di installazione, in cui indichiamo se sono presenti eventiali punti di attenzione da tenere sempre presenti. In questo caso andremo ad esaminare la installazione per JIRA Server, dato che l’addon è anche disponibile per Cloud. Come sempre andiamo a ricercare il nostro addon da installare nella relativa sezione, come mostrato nella figura:

Selezioniamo Free trial per iniziare la procedura cui siamo oramai abituati:

La procedura inizia con la fase di download ….

… quindi installa il tutto fino a completare l’operazione ….

… al termine, la procedura viene visualizzato un quadro riassuntivo delle caratteristicje dell’addon …

… e successivamente viene richiesto di connettersi ad internet per generare la chiave di licenza trial. Basta fornire l’account di cui si dispone …..

… per innescare il meccanismo di generazione chiave ….

… fino a rendere finalmente disponibile l’addon per i nostri obbiettivi :-).

Configurazione

Proseguiamo nella fase di configurazione dell’addon. In questo caso abbiamo una piacevole sorpresa. Al termine della fase di installazione, l’addon richiede un semplice e chiaro setup iniziale, in cui andare a impostare la configurazione. Per altri addon, solitamente, si doveva andare a gestire manualmente la configurazione posizionandosi nella sezione Addons e da li procedere ci conseguenza. Questo lo rende molto interessante. Vediamo di esaminare questa parte.

Siamo subito indirizzati alla pagina di welcome …

… dove ci viene richiesto di inserire il nome dell’azienda. Nel nostro caso sarà molto semplice :-). Il passo successivo, come indicato nella seguente immagine, abbiamo le caratteristiche che l’addon appena installato mette a disposizione.

Selezionand Next passiamo alla schermata successiva, dove andiamo a configurare il nostro addon, specificando l’amministratore ed i vari utenti.

Una volta eseguito ciò, abbiamo concluso questa fase di setup e siamo pronti per poter agire di conseguenza. La schermata finale che ci viene proposta, ci indica che cosa possiamo fare.

Nel nostro caso scgliamo di andare alla Dashboard, per poterla subito esaminare.

Questa ci mette a disposizione una serie di informazioni che andremo ad usare

Prima di iniziare il test ….

Una volta concluso il setup iniziale, possiamo procedere con l’utilizzo vero e proprio. Prima di iniziare partiamo da alcune definizioni, che ci serviranno per eseguire la nostra operazione. In questa parte andremo a definirli.

Objectives

Objectives (oppure anche Goals) definisce il risultato che si vuole raggiungere, a seguito di una serie di passi in un determinato periodo di tempo.

Key results (oppure anche sub-objectives) sono i risultati misurabili.

Punch è l’azione affinché objective produce progresso.

Alignment

Alignment deve essere visto come una gerarchizzazione, in ambito top-down o bottom-up, dei differenti Objectives, in modo da dargli una sorta di livello.

Weightage è un numero associato  a key result oppure alignment. Determina la grandezza dell’impatto che l’associazione sta per avere sullo stato di avanzamento di obiettivo che è al livello più alto.

Grading

Grading è la capacità di valutare gli sforzi e progressi su un determinato risultato objective/key result.

Labels

UpRaise permette di associare delle etichette (Labels) ad un objective. L’obbiettivo è di permettere di classificare i vari objectives in categorie.

Conclusioni

Concludiamo questo post con le definizioni e proseguiamo il test con il prossimo post :-).

Un pò di manualistica

In questo post andremo a vedere un pò di manualistica, che non fa mai male. In questo caso andiamo a spulciare nella manualista per capire come possiamo eseguire una BULK edit in JIRA 🙂

In cosa consiste

JIRA permette di eseguire una operazione di modifica/editazione multipla (Bulk edit appunto) delle issues. Questa operazione è sicuramente ottima quando si deve eseguire delle operazione che impatta più issue.  Se le dovessimo eseguire singolarmente…. aiuto

Ma prima di tutto

occorre sapere che questa opzione deve essere attivata. Andare quindi nelle permissions del progetto e … attivarle. L’attivazione è comandata dalle Global Permission (le trovate sotto le pagine di amministrazione, sezione System).  Da li andiamo a trovare la nostra bella opzione e…. forniamo le grant necessarie per poter avere  l’opzione disponibile.

Dalla figura vediamo come possiamo settare chi può usufruire della funzionalità.

Una volta configurata?

Possiamo fare tante bellissime cose 🙂

che adesso andiamo ad esaminare in dettaglio:

• Eseguire una transazione per un insieme di issues
• Cancellazione, modifica e spostamento di un insieme di issues
• Modificare il Watch di issues

Operazioni che, se eseguite una per volta, ci fanno invecchiare istantaneamente.

Come usiamo il tutto?

Bellissima domanda. Prima dobbiamo cercare il nostro insieme di issues da … trattare. Quindi andiamo ad applicare l’opzione che vogliamo :-), come mostrato nella seguente figura.

Una volta selezionata, passiamo al wizard che ci guiderà nella operazione che vogliamo fare. La prima operazione del wizard, come mostrato dalla seguente figura:

scegliamo quali issues andiamo a trattare. Il secondo passo è il seguente:

scegliamo l’operazione da eseguire. Supponendo di selezionare Edit Issues , viene proposta una nuova form che richiede quali modifiche operare :-), come mostrato della seguente figura.

Una volta inserite le informazioni necessarie, confermiamo e operiamo le modifiche.

Conclusioni

Abbiamo visto un esempio di come poterci semplificare la vita grazie alle funzionalità di JIRA. Continueremo sempre a pubblicare articoli didattici e di aiuto per gli utenti.

Reference

Per qualsiasi altre informazioni, in inglese, fate riferimento alla pagina del manuale.

Una breve divagazione

In questo post facciamo una breve divagazione sulle Agile Board. Cerchiamo di capire come possiamo sfruttare questo strumento  in vari ambiti e, sopratutto, vediamo come possiamo adattare alle nostre esigenze lo strumento.

Ringraziamenti

Un ringraziamento a Maria Luisa, per il lavoro che sta svolgendo con i prodotti Atlassian e che ha causato questa divagazione. 🙂

Vediamo come possiamo ….

… sfruttare la Agile Board a nostro uso e consumo. Infatti, si presta bene a diversi utilizzi, come ho già avuto modo di mostrare nel Workflow che ho già pubblicato qui nel marketplace della Atlassian, dove ho mostrato come poter utilizzare la Agile Board per tracciare il flusso delle fatture.

Un altro esempio lo trovate anche in questo post, che ho dedicato ad una ipotesi di realizzazione di Asset Management, dove anche li ho mostrato come la Agile Board trova un suo utilizzo molto naturale nel tracciare lo stato di ogni singolo asset.

Di conseguenza ….

… forti di queste esperienze, possiamo anche ipotizzare che ci siano anche altri possibili utilizzi delle board, anche non proprio relative alla metodologia Agile.

Stato di fatto – Fotografia – Snapshot

Un utilizzo che possiamo avere della Agile Board è quello di tracciare in generale lo stato di fatto. Allo stesso modo usato negli altri esempi. Un altro esempio riguarda il post che ho dedicato alla recensione dell’addon del Kanoah CRM, dove gli autori dell’addon hanno praticamente utilizzato una board per tracciare l’andamento degli affari.

Altri utilizzi?

Lasciamo che sia la nostra fantasia a trovare altri usi :-). Possiamo anche ipotizzare che sia gestita anche per gestire i percorsi di carriera del personale di una azienda. In questo caso, le issue sono utilzzate per rappresentare il dipendente, con tutte le sue informazioni, mentre gli stati del workflow sono i gradi di avanzamento di carriera/assegnazione incarichi e chi più ne ha ne metta, sfruttando anche la potenzialità di Confluence 🙂

Un altro esempio potrebbe essere la gestione di un parco macchine di una azienda. Le issue possono essere utilizzate per rappresentare le automobili, mentre gli utenti di JIRA sono il personale che ottiene in gestione l’auto…. ma questo è solo un possibile applicazione di un utilizzo un pò più generico: ovvero gestire la assegnazione di risorse e, utilizzando anche un altro addon che abbiamo censito, per rintracciarlo a livello geografico.

Ma la board è legata ad un solo progetto?

Fondamentalmente le Board sono legate ad un progetto, anche se possiamo sfruttarle per andare a leggere le informazioni anche da issue appartenenti a diversi progetti. Occorre però tenere presente alcune piccole accortezze per arrivare a gestirle al meglio.

1. Possiamo selezionare le issues che vogliamo, basta semplicemente impostare la JQL di cui si vuole
2. Occorre prestare attenzione: se il filtro JQL non presenta il campo project , allora la Board potrebbe non risultare associata al progetto o fruibile dalla Dashboard del progetto, come mostrato nella immagine successiva
3. Se vogliamo sfruttare le potenzialità della board di modificare lo stato delle issue, accertiamoci che le issue dei progetti selezionati presentino lo stesso workflow, che presentino gli stessi stati e che la Board sia configurata in maniera tale da telere conto degli stessi stati, ovvero quali stati e quale colonna etc. Se presentano WF differenti, potremmo non avere il comportamento che ci aspettiamo 🙂

Conclusioni

Abbiamo fatto una semplice digressione sull’argomento. Questo è sicuramente uno punto di partenza per altri ragionamenti che porterà sicuramente a conclusioni interessanti.

Nuova versione rilasciata

In questo post andremo a censire le ultime novità che sono state messe a disposizione degli utenti di Kanoah Tests.

Subito al dunque

Change history per i test run

Teniamo traccia di ogni cambiamento dei Test Run.

Campi personalizzati per i Test Run

Abbiamo adesso la possibilità di poter inserire dei campi personalizzati anche nei Test Run.

Migliorata la sincronizzazione tra Test Cases e Test Results

Migliorata la sincronizzazione tra i Test Case e i Test Results.

Creare Test Run direttamente dalla visualizzazione issue

Migliorata l’integrazione con JIRA: possiamo creare dei Test Run direttamente dalla issue vies standard 🙂

Drilldown issue information direttamente da Test Run

Non dobbiamo più navigare tra le varie schermate: adesso abbiamo a disposizione delle piccole ma valide facilitazioni per leggere le issue collegate ai Test Run.

Organizza i Test Run attraverso delle cartelle

Standardizzata l’organizzazione delle informazioni. Adesso possiamo organizzare i Test Run attraverso opportune cartelle.

Aggiornata la traduzione italiana

Segnalo anche questo punto, in cui sono coinvolto direttamente, dato che ho collaborato attivamente nella realizzazione della traduzione italiana, che spero sia un valido aiuto.

Conclusione

Kanoah si conferma sempre attenta alle esigenze dei propri clienti e mette sempre in campo innovazioni. Restiamo in attesa delle prossime sorprese :-).

Risorse per i prodotti Atlassian

In questo post andremo ad elencare alcune risorse disponibili per il mondo Atlassian, siano essi applicativi, documentazione, libri, ebook, etc.

Libro su Amministrazione di JIRA

Segnaliamo questo libro (in inglese) su JIRA. Si tratta di : JIRA Strategy Admin Workbook, di Rachel Wright.

Il libro contiene :

• 152 raccomandazioni per aiutare i JIRA Administrator a settare, mantenere pulito ed efficiente JIRA;
• 33 esempi reali di problemi da evitare,
• Best Practices, cose da fare e da non fare per ogni area di amministrazione
• Tanti e tanti altri esempi e consigli sulla amministrazione di JIRA.

Più che di documentazione, l’obbiettivo del libro è quello di essere un compendio di suggerimenti e consigli pratici che permettono ad ogni amministratore di arrivare a gestire al meglio JIRA :-), come indicato dalla stessa autrice :

The JIRA Strategy Admin Workbook will save you time, money and frustration.

This book is different – it’s not documentation.  It’s recommendations from years of cleaning up horrible JIRA configurations!  It’s about what you should do, what you shouldn’t do, and why.

Maggiori informazioni sono reperibili consultando il seguente link. Attendo commenti 🙂

eBook gratuito su XRay – Test su JIRA

Segnalo anche questo ebook sui test in JIRA, della Xpand IT, dedicato al mondo dei Test con JIRA. Abbiamo già ampiamente dedicato molti articoli del blog a tale argomento, presentando diversi  addon, quali Kanoah Tests e XRay, della stessa Xpand IT.

Adesso la XPand IT propone un ebook dedicato, riportando la loro esperienza in materia e cercando di metterla a disposizione degli utenti JIRA. Maggiori informazioni sono presenti in questo link.

Ultimo ma non ultimo

Segnaliamo anche una risorsa su di un argomento molto importante: DevOps. Si tratta di un libro sull’argomento, presente nel blog della Atlassian, in cui si evidenzia un caso di uso di DevOps e di come costruire un team di DevOps 🙂 e dove si viene anche rimandato ad un altro blog post, sempre della Atlassian, dove si spiega il perchè viene utilizzato DevOps.

L’ebook, in inglese, può essere scaricato al seguente indirizzo del blog della Atlassian.

Conclusioni

In questo post abbiamo fornito un ulteriore elenco di risorse a disposizione dei prodotti Atlassian e delle moetodologie che mette a disposizione. Seguiranno ulteriori post. 🙂

Kanban, Scrum, Scrumban, …

In questo post andremo a proseguire l’esplorazione sulla metodologia AGILE, concludendo l’introduzione di questo argomento.

Definizioni preliminari

Per alcune definizioni preliminari, vi rimando al seguente link del sito Agileway.it, dove ho trovato delle indicazioni molto ben fatte.

Kanban

Per spiegare in cosa consiste Kanban, sfruttiuamo A brief introduction to kanban, di Dan Radigan, 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ù semplice, ma anche il più chiaro possibile.

L’approccio Kanban bene si adatta a quelle situazioni in cui si hanno sempre delle attività continue da svolgere.

Il Product Owner scompone il lavoro in tanti piccoli task, più o meno complessi, modificando l’ordine degli stessi e inserendo in cima quelli con maggiore priorità. In questo modo è sempre possibile rischedulare il lavoro del team senza dover bloccare il lavoro del team.

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

Quando si ha a disposizione un insieme di task completati, si procede con un rilascio del nuovo software.

Questo approccio è molto più indicato nella manutenzione che nello sviluppo di nuove applicazioni.

Scrum

A differenza della precedente, la Scrum ben si adatta allo sviluppo di un nuovo progetto. Andiamo a capire meglio:

Scrum struttura il proprio sviluppo in cicli chiamati Sprint che durano da una a quattro settimane, al termine dei quali il team di sviluppo rilascia funzionalità immediatamente testabili.

In Scrum non abbiamo una figura di Project manager che coordina il team, ma possiamo dire che il team stesso è 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.

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.

Ogni giorno il team si confronta nello Stand-up Meeting, che deve durare non più di 15 minuti, dove deve emergere lo stato di avanzamento, problemi e criticità. Obbiettivo è di identificare subito ciò che può bloccare il lavoro del team e rimuoverlo in modo da consentire il normale svolgimento delle attività.

Al termine della sprint si rilascia ciò che è stato completato, mettendo a disposizione una funzionalità completa e testata, testabile a sua volta dal cliente.

Scrumban

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 per una bella immagine che descrive abbastanza bene visivamente che cosa è Scrumban, che mi sembra molto chiara e precisa. Maggiori dettagli li ho identificati qui (in inglese).

Scrumban mette insieme l’interazione continua di Kanban, aggiungendo una limitazione agli slot di task che devono essere eseguiti contemporaneamente.  In Scrumban, il gruppo di lavoro è organizzato in piccole interazioni e monitorato attraverso una board similare a Scrum e Kanban.

Si lavora solo su di un sottoinsieme di user story, che vengono scelte 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.

Kanban Vs Scrumban

La seguente immagine riassume le differenze tra Kanban e Scrumban.

Scrum Vs Scrumban

La seguente immagine riassume le differenze tra Scrum a Scrumban:

Conclusioni

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 di aver introdotto degli argomenti interessanti.

Nei prossimi post iniziamo a calare questi concetti su JIRA SOFTWARE, verificando che cosa sia possibile realizzare e come.

Ringraziamenti

Ringraziamenti per l’aiuto a Michael Forni, che è stato un valido supporto ed aiuto nella redazione di questi articoli. Di seguito i suoi contatti:

• Twitter: @MichaelForni
• Linkedin: www.linkedin.com/in/michaelforni
• Email: michaelforni@gmail.com

Citazione

Alcune immagini ed indicazioni sono prese dal sito AgileWay.it e da altre fonti (che cito di seguito), dove ho trovato indicazioni molto utili. Lo cito con piacere e ne suggerisco la lettura dei vari articoli: ritengo siano una fonte molto importante di informazioni in italiano. Altre immagini e riferimenti sono stati presi dai seguenti siti, quali:

• kanbantool.com – per l’immagine che mette a disposizione per descrivere Scrumban e per le immagini
• www.solutionsiq.com – per le immagini di confronto tra Kanban e Scrumban e tra Scrum a Scrumban.