Prima di iniziare …..

….. mi permetto di ringraziare nuovamente Atlassian per avermi accolto nella grande famiglia degli Atlassian Creators.

Sul processo di approvazione

Oggi affrontiamo un argomento molto interessante. Vogliamo analizzare che cosa abbiamo a disposizione per gestire tale meccanismo di approvazione. Quante volte ci siamo sentiti richiedere dai nostri superiori o dai manager di progetto la necessità di impostare tali meccanismi. In questo post mostreremo che cosa abbiamo a disposizione, partendo sempre dallo standard, ovvero dalle funzioni che la stessa Atlassian ci mette a disposizione. Successivamente andremo ad esplorare che cosa è possibile impostare con addons.

Cosa intendiamo per processo di Approvazione?

Per processo di approvazione intendiamo quella fase di un processo di lavorazione in cui, prima di poter procedere ad una fase successiva, occorre che questa sia approvata in maniera esplicita da un membro del gruppo di lavoro. Questa è una fase critica che deve essere gestita in maniera opportuna. Infatti necessitiamo di un sistema che ci permetta di tracciare:

• Quando arriviamo a questa fase
• Chi e quanti sono coinvolti nella fase di approvazione
• Che risultati deve produrre questa fase, sia per approvazione che per rigetto.

Per chi come me ha iniziato a lavorare su Jira dal 2009 (si, sono vecchio), questa fase era un vero tormento, perché l’unico sistema era quello di lavorare a livello di configurazione di Workflow per poter avere il risultato sperato, ma non sempre era gradito al cliente.

Ma per fortuna Atlassian non è rimasta a guardare e la funzione è stata poi aggiunta e resa disponibile a noi utenti. Andiamo ad esaminarla.

Cosa ci offre lo standard

E’ la nostra prima domanda. Andiamo ad esplorare questa funzione e analizziamola. La prima cosa che notiamo è che questa funzione è stata inserita solo su Jira Service Management: solo su tali categorie di progetti possiamo sfruttare questa funzione. Dalla seguente immagine vediamo dove è disponibile:

Questa funzione si attiva solo a livello di Workflow, dove è naturale che sia. IN questa funzione andiamo a selezionare diverse opzioni. In particolare abbiamo la possibilità di poter selezionare:

• il campo da dove scegliere gli Approvatori
• Il numero di approvatori richiesto (1, tutti, un determinato numero, etc)
• Se si approva, quale stato portare il ticket
• Se non si approva, quale stato portare il ticket

Le precedenti immagini descrivono che cosa gli utenti vendono quando, attivando la relativa opzione sugli stati del Workflow, configurano l’approvazione. Una cosa che andiamo a evidenziare è la presenza di due campi per gestire le approvazioni: Un campo utente singolo o insieme di utenti (NON GRUPPI) ed un campo per gruppo singolo o insieme di gruppi.

Interessante ma gli altri progetti di Jira?

Qui inizia la fase più interessante. Gli altri progetti NON hanno al momento alcuna funzionalità relativa alla approvazione. In questo caso abbiamo diverse possibilità:

Soluzione 1

Possiamo creare una issuetype dedicata ed un relativo Workflow per gestire questa situazione. In questo modo, isoliamo la fase in un punto ben preciso e la presenza del workflow opportunamente configurato, permette di poter gestire il tutto

Soluzione 2 – Addons

In questo caso mi sento di consigliare un addon molto interessante, ovvero Approval Path for Jira. Questo addon, cloud fortified, aggiunge la funzione direttamente a qualsiasi tipologia di progetto (quindi su tutto Jira), con delle UI molto interessanti:

La stessa configurazione del processo di approvazione risulta semplice

Super, ma che altre alternative abbiamo?

Lato Addon ho verificato l’esistenza di tante altre soluzioni che sono state implementate da altri produttori. Come sempre, sono e rimangono soluzioni valide e ottime. Dipende sempre dall’obiettivo che le aziende si prefiggono e come intendono realizzarlo: La possibilità che, come sempre ribadisco, di avere un numero di scelte maggiori, ci aiuta nello scegliere e nel decidere quale di queste è implementabile per NOI.

Ultimora

Ho il piacere di segnalare che questa funzionalità di gestione delle Approvazioni è stata resa disponibile anche per il profilo Cloud Premium, per Jira Work Management (prossimamente Jira), dove è possibile usare questa caratteristica.

Le seguenti immagini ci mostrano alcune possibilità che sono state offerte.

Dalla prima analisi che ho eseguito, risulta che siamo ancora all’inizio delle possibilità: Su Jira Service Management possiamo scegliere se lavorare con i Gruppi o con i Singoli utenti (con la possibilità di usare i campi ufficiali, ovvero Approvers o Approvers Group oppure altri campi custom). In questo caso siamo ancora limitati al singolo utente o alla lista di utenti. Questo è sicuramente un passo importante ma di sicuro ce ne saranno ulteriori.

Conclusione

Abbiamo visto una carrellata di possibilità che sono offerte lato Jira per arrivare a supportare le Approvazioni. Di conseguenza abbiamo un ventaglio di possibilità non indifferenti. Confido di aver fornito un ventaglio di scelte possibili tali per cui siate in grado di scegliere la soluzione che meglio si adegui al vostro interesse.

Reference

Riporto alcuni link di interesse citati in questo articolo:

• Documentazione ufficiale Atlassian
• Approval path for Jira
• Marketplace Atlassian

Dedico questo post a coloro che stanno iniziando ad usare Jira e che ancora fanno fatica a come ottenere dei risultati. Il mio obiettivo è quello di fornire un aiuto tale da portare a raggiungere un buon risultato.

Do per scontato un punto fondamentale: Si tratta chiaramente di un suggerimento volto ad aiutare o a fornire un punto di vista differente, senza avere la pretesa di essere un insegnamento miracoloso.

In questo caso voglio consigliare come poter inserire del testo, descrizioni, link e tutto ciò che riteniamo necessario…. il tutto usando un semplice ed interessante Addon:

Questo addon è interessante per vari motivi:

• E’ prodotto da Atlassian Labs (ed è anche GRATIS)
• E’ come avere un piccolo WORD all’interno di Jira
• Lo possiamo usare per qualsiasi occasione: Dalla legenda per le nostre Dashboard, alla spiegazioni dei nostri report, etc.

Secondo me, se lo usate, non ne potete fare a meno.

Buon divertimento.

Dedico questo post a coloro che stanno iniziando ad usare Jira e che ancora fanno fatica a come ottenere dei risultati. Il mio obiettivo è quello di fornire un aiuto tale da portare a raggiungere un buon risultato.

Do per scontato un punto fondamentale: Si tratta chiaramente di un suggerimento volto ad aiutare o a fornire un punto di vista differente, senza avere la pretesa di essere un insegnamento miracoloso.

Come classificare i nostri ticket su Board

Le Kanban Board sono utilissime in tantissimi contesti e molto spesso le usiamo anche per gestire situazioni che nulla hanno a che fare con lo sviluppo software. Infatti sono molto versatili e danno tantissimo valore aggiunto.

Tuttavia abbiamo un problema di visualizzazione quando il numero dei ticket aumenta. Come possiamo fare ad organizzare la Board?

Le Swimline ci forniscono un aiuto molto importante, perché ci permettono di avere un sistema semplice e di facile implementazione. Andiamo a curiosare meglio:

Se le analizziamo, quello che vediamo è la possibilità di poter gestire una classificazione automatica per:

• Assegnatario del ticket
• Epiche
• Story
• Progetti

che ci aiuta ad eseguire una classificazione veloce per i punti indicati. In particolare, se abbiamo la necessità di avere una board multiporgetto, la possibilità di raggruppare per più progetti ci permette di avere un quadro di insieme non indifferente.

L’ultimo punto, ovvero Queries, ci permette di poter gestire tutte le situazioni generiche che si possono presentare. Infatti possiamo specializzare le varie Swimline, usando il JQL (cosa che apprezzo tantissimo) e questo ci permette di poter classificare in maniera personalizzata la nostra Board. Vediamo come.

Quando creiamo la nostra swimline ci viene chiesto quale JQL andare ad impostare

Una volta creata la Swimline questo è il risultato:

Dedico questo post a coloro che stanno iniziando ad usare Jira e che ancora fanno fatica a come ottenere dei risultati. Il mio obiettivo è quello di fornire un aiuto tale da portare a raggiungere un buon risultato.

Do per scontato un punto fondamentale: Si tratta chiaramente di un suggerimento volto ad aiutare o a fornire un punto di vista differente, senza avere la pretesa di essere un insegnamento miracoloso.

Assegnazione automatica utente a ticket

Nei vari casi che ho trattato, ho notato che normalmente la gestione della assegnazione automatica di un ticket, secondo diversi casi e situazioni, viene facilmente risolta facendo uso delle automation rules. Queste infatti ci permettono di poter gestire un ventaglio di situazioni molto ampie.

Tuttavia devo fare un appunto a questo: In alcuni casi ho verificato che il neofita spesso compie un abuso di automazioni portando confusione. Infatti provo a descrivere questo suggerimento andando a descrivere una situazione che ho affrontato in vari casi.

Scenario

Il mio cliente aveva creato una automazione che, al cambio di stato, assegnava in automatico il ticket alla persona che aveva cambiato lo stato. Questa azione è sicuramente valida e va benissimo, se non fosse che mi aveva segnalato che non sempre funzionava. Mi aveva quindi contattato per risolvere la situazione.

Analizzando il tutto ho verificato che questa automazione veniva chiamata troppe volte e spesso esauriva il limite massimo di automazioni al mese. Il profilo cloud usato è Standard e dopo quanto riportato in questo mio post di qualche mese fà, i limiti sono cambiati.

In questo caso ho suggerito una soluzione molto semplice. Invece di far uso di una automation, semplciemente agire a livello di Workflow.

Infatti abbiamo la possibilità di sfruttare le postfunction standard e usare in particolare questa:

Se la sfruttiamo, quello che succede è che quando l’utente esegue la transazione, automaticamente gli assegna il Ticket. Come leggiamo dalla precedente immagine, occorre anche accertarsi che l’utente si possa assegnare il ticket e quindi il relativo permesso (sopra specificato) deve essere assegnato all’utente in questione.

Il vantaggio è quello risparmiare le automazioni sfruttando sempre e comunque azioni standard.

In questo post affrontiamo un argomento interessante, inerente le Regole di Automazione. Vogliamo creare una schedulazione pianificata tramite le regole di automation per creare una issue/task/compito in base a delle richieste particolari. Vediamo come fare.

Andiamo con ordine

Vogliamo creare in maniera automatica e schedulata una issue particolare ma quando andiamo a richiamare tutti i vari mattoncini lego delle nostre regole, abbiamo dei problemi e siamo in pieno disastro. Come possiamo fare?

Abbiamo una soluzione

Ebbene si: abbiamo una soluzione, ma andiamo sempre con ordine: un passo alla volta. Sappiamo che possiamo impostare un apposito trigger nelle nostre regole di automation, che ci permette di poter gestire le schedulazioni. In particolare (vedi immagini seguenti):

abbiamo quindi tutto, ma abbiamo anche un problema che non possiamo trascurare: Dobbiamo specificare un JQL per selezionare l’elenco delle issue da usare.

Possiamo non specificare il JQL, non sembra obbligatorio. Nel nostro caso di uso vogliamo creare una issue ad un orario ben definito, ma senza dover avere un insieme di issue da gestire. Come possiamo fare? Abbiamo la soluzione e si prega di inoltrare i ringraziamenti alle persone citata nell’articolo di Atlassian Community riportatoi di seguito.

Occorre impostare la seguente condizione

che ci permette di poter gestire questa situazione e ci permette di creare una nuova issue non appena scattato il trigger.

Vediamola in azione

Ho predisposto una regola di prova, per eseguire il test:

Una volta attivata abbiamo il seguente risultato:

e la issue risulta

Conclusione

Abbiamo scoperto un trucco molto importante perché ci permette di creare questa tipologia di schedulazione. questo ci permette di poter avere delle issue create a richiesta senza dover acquistare altri addon e sfruttando lo standard. Ovviamente si tratta di una soluzione che ci fa risparmiare, ma occorre sempre tenere conto di quanto ho già spiegato nel mio post che riguarda la nuova gestione dei limiti di esecuzione delle regole.

Reference

Ringraziamenti a tutti coloro che hanno partecipato alla discussione della Atlassian community e che hanno reso possibile la stesura di questo articolo in Italica lingua.

Credo che sia sempre ottimo precisare e dare ulteriori indicazioni sulle Automation, che sono un mondo molto vasto ed interessante. Cerchiamo di fare una piccola precisazione che sicuramente sarà molto utile.

Nel dettaglio

Quello che abbiamo a trattare riguarda il come generare un task affinché sia collegato ad una Epic. Come sappiamo la Epic è un caso eccezionale tra tutte le issue presenti su Jira. Si tratta dell’unica issue type che permette di poter avere delle Issue figlie. I motivi li abbiamo trattati in altri post precedenti ma credo che a breve li andremo a riprendere. 😉

Se vogliamo introdurre questa informazione quando usiamo le regole di automation ci accorgiamo di una cosa: Usando l’azione di Edit Issue, quando selezioniamo il campo Epic Link, non riusciamo a passare il valore. Qualcosa non funziona.

Il risultato non è quello sperato. Sembra quasi che l’azione non si esegua. Quindi?

Nozioni di Storia di Jira

Dobbiamo sapere (da storico dilettante non posso esimermi) che originariamente non esisteva la gestione Agile su Jira. E’ stata aggiunta da un addon (greenhopper) che ha introdotto questo aspetto. Atlassian si è buttata a pesce ed ha acquisito l’addon. Adesso sembra tutto integrato, ma….. in realtà credo ci sia una separazione ancora netta. Credo che sotto sotto sia rimasto un addon separato e di conseguenza anche il campo sia gestito in maniera separata.

Ho scartabellato e verificato ed il risultato è questo articolo del Community: Il campo va gestito esattamente come un qualsiasi campo custom. Passiamo al Json:

Se usiamo questa indicazione, riusciamo ad arrivare all’obiettivo.

Conclusione

Un ringraziamento a tutti coloro che hanno partecipato a questa discussione che ha permesso la redazione di questo articolo in Italica Lingua.

Un ultimo appunto:

Mentre componevo questo articolo, ho notato una cosa molto carina. Atlassian sta rivedendo l’interfaccia grafica della sezione delle regole di Automation. Infatti:

promette bene. Vedremo nei prossimi mesi che cosa succederà.

Prefazione

---

Iniziamo una serie di articoli il cui obbiettivo è di riassumere in un Case Study, l’esperienza raccolta nel risolvere un problema o nel coprire una necessità di un cliente.

In questo Case Study voglio raccontare come è stato possibile eseguire l’integrazione di due istanze Jira Cloud differenti, al fine di consentire il passaggio delle segnalazioni da una istanza all’altra. Questa comunicazione doveva sottostare ad un insieme di condizioni molto forti in quanto le due istanze erano usate da aziende differenti e di conseguenza nessuna delle aziende doveva essere in grado di poter visionare il contenuto dell’altra istanza Cloud.

Trattandosi di un argomento interessante cercheremo di svilupparlo facendo si che siano riportati tutti i ragionamenti che sono stati eseguiti per arrivare alla scelta definitiva ed alla risoluzione che ha fornito la soluzione, a giudizio di tutte le parti coinvolte, che meglio rispondeva alle esigenze.

Caro lettore, ti ringrazio fin da adesso per il tempo che dedicherai alla lettura e ogni tuo commento sarà il benvenuto.

Scenario

---

Partiamo subito descrivendo lo scenario che mi sono trovato davanti e quali condizioni dovevano essere rispettate per poter eseguire questa integrazione.

Il mio cliente aveva appaltato alcune parti del proprio Help desk a due fornitori. Questi avevano implementato tali funzionalità usando le proprie istanze Jira Cloud, che usavano anche per gestire altri Help Desk di altri loro clienti. E’ sorta la necessità di potere seguire uno scambio di segnalazioni in quanto poteva capitare che chi richiedeva l’intervento di un software/applicativo che è gestito dall’Help desk del secondo fornitore e viceversa.

Ogni fornitore recepiva le segnalazioni nei propri progetti di Service Management e li gestiva in maniera indipendente l’uno dall’altro. Non erano presenti punti di contatto. In aggiunta, le due istanze venivano usate anche per altri obbiettivi e di conseguenza era stato sollevato il problema di:

• sicurezza delle informazioni: ambo le parti chiedevano che fosse inoltrata solo la segnalazione in questione mentre tutte le altre informazioni rimanessero riservate.
• Istanze separate: Le istanze dovevano comunque continuare a lavorare come se nulla fosse. Le segnalazioni provenienti da altre fonti dovevano essere comunque indipendenti dalle segnalazioni di questa integrazione.
• Sincronizzazione: Le segnalazioni che sono oggetto della integrazione tra i due sistemi cloud, dovevano essere sincronizzate in modo da permettere ad ambo le parti di essere sempre aggiornati sulle modifiche.
• Semplicità: La configurazione non doveva risultate complicata o di difficile interpretazione.

Lo scenario si presentava abbastanza complicato e di non facile risoluzione, ma la sfida era molto interessante e non ci siamo arresi. Abbiamo iniziato con le analisi e ci siamo fin da subito impegnati nella risoluzione del problema.

Cosa avevamo a disposizione

---

Anche le due istanze non presentavano caratteristiche particolari:

• Non avevano Addon particolari installati, anzi in un caso era usata la versione cosiddetta out-of-the-box, ovvero la versione base di Jira.
• Disponevano di vari progetti che erano in capo ad altri clienti e solo uno. di essi doveva essere coinvolto nella sincronizzazione
• Disponevano di flussi di lavoro completamente differenti e che dovevano non essere toccati: la sincronizzazione si doveva innestare nei flussi esistenti.

Jira è un grande software ma le funzioni standard non permettono di mettere in comunicazione due istanze diverse. Di conseguenza dobbiamo rivolgerci al Marketplace per capire che cosa è stato sviluppato e messo a disposizione, un insieme di funzionalità che noi abbiamo a disposizione e che molte aziende non conoscono o non hanno. il tempo di conoscere.

Cosa offre il Marketplace

---

I produttori del marketplace hanno fatto un grande lavoro mettendo a disposizione un insieme di funzionalità che completano in maniera egregia Jira. La conoscenza che ho sviluppato in tutti questi anni di utilizzo, mi ha permesso di fare una rapida ricerca e cernita dei possibili addon da poter usare.

La prima scelta mi ha portato a selezionare 4 addon, da poter proporre alle parti, per arrivare ad offrire una soluzione accettabile. Dopo diverse riunioni, alcune molto combattive e non proprio semplici, la scelta è ricaduta su questo addon:

Posso assicurare che nelle varie riunioni si è molto discusso delle caratteristiche e delle funzionalità, ma alla fine, questo addon permette di poter realizzare esattamente quanto richiedevano cliente e fornitori, rispettando le richieste e le condizioni che avevano imposto e mantenendo anche la semplicità che era richiesta anche dagli stessi fornitori, nel gestire la sincronizzazione e nel mantenere la netta separazione delle informazioni. Capisco perfettamente il significato di questa richiesta e molto spesso la causa è da ricercare nel fatto che non tutti gli utenti che utilizzano questi prodotti sono esperti oppure usare questi prodotti non è il core business di queste aziende. Avere a disposizione la semplicità oltre che mantenere una generosa dose di praticità, permette di avere l’arma vincente per risolvere tutta una serie di situazioni.

Backbone Issue Sync for Jira permette di poter eseguire la sincronizzazione di issue tra progetti sia della stessa istanza, che di istanze differenti. In questo modo è possibile anche soddisfare altre possibili situazioni, in cui magari occorre mantenere sincronizzato un progetto COPIA che sia referenziato da altri utenti o che, con l’aiuto di altre funzionalità, di cui l marketplace è ricco.

La configurazione è molto completa ma, come si ribadisce facile da impostare. Come possiamo vedere dalla seguente immagine:

Possiamo gestire in maniera chirurgica cosa sincronizzare, sotto quali condizioni (e qui interviene il JQL di cui io sono un Fan sfegatato). Possiamo decidere campi sono soggetti alla sincronizzazione, compresi i campi custom che abbiamo definito nella sezione di amministrazione di Jira, oltre che decidere se impostare dei campi con valori di default.

Possiamo anche decidere la corrispondenza degli stati del Workflow: questo ci aiuta nell’impostare le corrispondenze ed innestare correttamente un flusso di lavoro in un altro.

Commenti ed allegati possono essere sincronizzati facilmente. Nel caso dei commenti possiamo anche decidere se, nella eventualità che usiamo progetti JSM, quali commenti vanno sincronizzati ed in che direzione.

Subito al dunque

---

Andiamo a vedere come questo addon permette di poter rispondere le esigenze espresse. In prima battuta abbiamo che la questione sicurezza è perfettamente garantita. in quanto tutte le operazioni di sincronizzazione sono eseguite in maniera trasparente e, sopratutto, l’addon garantisce un grado di separazione molto alto tra le due istanze: da una istanza non è possibile andare a leggere le informazioni dell’altra istanza e viceversa.

In aggiunta, la sincronizzazione non deve scattare sempre, ma solo quando è necessario ovvero quando effettivamente quando l’agente si accorge che la segnalazione è di competenza dell’altro Help desk, questo deve essere in grado di poter attivare la sincronizzazione.

Vediamo nel dettaglio la configurazione che è stata impostata al fine di gestire la sincronizzazione proteggiendo le informazioni.

La sincronizzazione scatta quando…

… si imposta un particolare valore in un campo. Si è scelto di usare il campo LABELS con opportuni valori. Questo ci permette di poter pilotare l’attivazione e la disattivazione della sincronizzazione

La issue che sincronizziamo …

… sono quelle dell’help desk che vengono convertite con una issue nella istanza destinazione e viceversa. In questo caso abbiamo una configurazione come mostrato dalla seguente immagine

In questo caso abbiamo una corrispondenza multipla, in modo da far corrispondere più issue dell’help Desk ad una soltanto.

I campi che sincronizziamo …

… sono pochi e comprendono anche i campi custom

Non abbiamo alcun campo inizializzato, ma se fosse necessario nel futuro, lo possiamo fare.

Gli stato del workflow che sincronizziamo …

… non abbiamo configurazioni particolari. In questo modo gli stati sono quelli che gli agenti dei vari Help Desk sono abituati a lavorare

I commenti che sincronizziamo …

… sono solo quelli che sono intercorsi tra agente e customer. I commenti interni non sono sincronizzati perché potrebbero contenere informazioni che sono personali dell’Help Desk sorgente e di conseguenza potrebbero contenere anche informazioni riservate. In questo modo non abbiamo problemi. 🙂

Gli allegati che sincronizziamo …

… sono tutti gli allegati che sono presenti nella issue. Questi sono importanti e devono essere riportati.

Conclusione

Questo addon ha brillantemente risolto la necessità che sia i due fornitori che del mio committente hanno espresso, e la procedura di sincronizzazione è attualmente in produzione. Per mia abitudine controllo i risultati del mio lavoro e tra non molto procederò ad una piccola intervista dove cercherò di identificare i vari feedback e di capire se occorre una ulteriore modifica, o se sono stati riscontrati dei problemi di qualche genere o natura.

Approfitto per ringraziare il lettore che con molta pazienza ha seguito quello che ho raccontato. Spero di aver fornito tanti spunti interessanti che possa anche fornire utilità. Spero che questo, sia l’inizio di tanti altri articoli che possa fornire conoscenza ed aiuto sull’argomento.

In questo post andremo a vedere come realizzare un mini ambiente di test su Jira, usando semplicemente la configurazione ed il supporto di un addon. Questo per tutti coloro che non vogliono appoggiarsi agli addon che sono dedicati al test e vogliono avere comunque un minimo di infrastruttura interna a Jira. In questo caso si tratta di una mia ipotesi. Spero possa risultare utile per tutti coloro che ne hanno bisogno. Ovviamente non è la soluzione principe, ma sicuramente può essere il principio di altre possibili soluzioni. Buona lettura.

Di cosa si tratta

In questo caso vogliamo tentare una missione impossibile. Cerchiamo di fornire un esempio di come possiamo gestire i test senza utilizzare gli addon di Jira che sono dedicati. Una premessa risulta necessaria, giusto per essere precisi.

Questo sistema è stato pensato per i piccoli team che, anche se possono usufruire della possibilità di poter usare addon free (perchè sono 10 utenti), ma non riescono a poterne usufruire o hanno bisogno di essere non strutturati oppure non si riconoscono e cercano delle soluzioni alternative. Lo sapete che in Italia siamo creativi e spesso cerchiamo la NOSTRA perfezione.

Come possiamo procedere

Lavorando con la configurazione, possiamo classificare i test sfruttando una o più issue type particolari. L’idea è infatti questa: possiamo definire dei nuovi issue type per classificare uno o più tipologie di test (a seconda dei nostri gusti o necessità).

Questa operazione viene eseguita anche da altri addon, che però ci mettono già a disposizione una situazione del genere. Non vi ricorda qualcosa questa schermata? 😀 XRay e RTM ci mettono a disposizione una situazione simile. In questo caso, sfruttamdo le potenzialità di Jira, creiamo noi gli issue type che ci servono. Una precisazione: Questa operazione deve essere eseguita da un Jira Administrator. Da tenere sempre presente.

Il secondo passo è quello di associare questi nuovi issue type direttamente al progetto. Questa operazione la andiamo ad eseguire direttamente dalla configurazione di progetto. Questa operazione può anche essere eseguita dal project administrator. Anche se il gruppo di lavoro è limitato non escludiamo che dei ruoli esistano.

A questo punto abbiamo la possibilità di poter generare tutte le tipologie di test che vogliamo: possiamo anche definire più tipologie di test o di oggetti di corredo ai test. La fantasia ci aiuta in questo caso.

Definiamo i passi dei test.

A questo punto, possiamo definire i passi che compongono i test e ci possiamo basare su di un addon (anche più di uno) che ci permette di definre delle Checklist. IN questo post ci concentreremo su questo addon.

Questo è uno di quelli disponibili, ma potete scegliere quello che volete. Non sono così integralista. Se vi trovate bene con un altro, usatelo senza alcun problema ;-D

Procediamo con la configurazione i queste checklist. L’obbiettivo è quello di definire la lista dei passi e per questo sfruttiamo le checklist. Questo addon free, come mostrato dalla immagine precedente (al momento in cui scrivo, l’addon è free).

L’addon permette di creare dei templatre di Checklist, che possiamo aggiungere, anche se abbiamo una limitazione di:

• 5 Template globali
• 5 Template di Progetto.

Come scrivevo, abbiamo un addon gratuito e di conseguenza non abbiamo tutte le funzioni, ma vediamo di sfruttarle in maniera adeguata 😀

A questo punto possiamo definire i nostri template direttamente dalla issue, come mostrato nella seguente immagine:

Possiamo crearci di volta in volta le opzioni di checklist che vogliamo e anche assegnare loro uno stato, e non solo. Se diamo una occhiata alla configurazione possiamo vedere diverse cose interessante:

Abbiamo diverse possibilità, tra le quali:

• Scegliere i progetti per cui abbiamo questa fuznionalità (abilitiamo solo i progetti che interessano).
• Quali stati associamo alle opzioni
• Quali permessi possiamo attivare sulle checklist
• Nelle global setting andiamo a decidere se possiamo inviare o meno agli utenti menzionati nelle checklist
• Il link per il supporto verso il produttore dell’addon

Il risultato finale

Dove ci ha portato questa configurazione? sicuramente adesso abbiamo la possibilità di classificare i test che sono stati eseguiti, definire quali azioni definiscono i vari test e quali risultati si sono ottenuti, rispetto a quelli desiderati.

• Se la nuova funzionalità rispetta i requisiti
• Quali azioni eseguire quando si esegue il test (e la checklist dotata di STATO ci permette di identificare facilmente se siamo andati bene o in errore
• Possiamo avere dei template (ovviamente siamo limitati dalla versione free, ma ci sono alternative che possiamo usare per specializzare ulteriormente
• In ultima analisi, abbiamo un qualcosa che si adatta alle nostre esigenze Gli addon preconfezionati hanno si esperienza, ma in alcuni casi possono non essere la soluzione migliore. Come sempre ribadisco, la bellezza del Marketplace è che possiamo avere più scelte

In questo post continuiamo la serie dei trucchi per poter risolvere delle situazioni di emergenza. In questo caso ci occupiamo di gestire una situazione che molto spesso viene chiesta dai miei clienti e che, grazie ad una intuizione, mi ha fatto scoprire una possibile soluzione che oggi condivido.

La necessità

Come posso inserire un link alla mia documentazione, sul PORTAL di Jira Service Management, in modo da poter far accedere il cliente direttamente alla documentazione?

Atavica domanda

La risposta ufficiale

Lato Service Desk (prima) e Service Management (adesso) lavora a stretto contatto con Confluence che grazie alla funzionalità di KB che viene messa a disposizione, possiamo condividere con i clienti tutti i documenti di cui abbiamo bisogno.

L’obbiezione

Alcuni clienti obbiettano che hanno scelto di non installare Confluence perché hanno già una solo soluzione in essere e che questa è più che sufficiente. Oppure dispongono di altra soluzione che non si può integrare direttamente con Jira ma che permette di avere. a disposizione un link diretto alla documentazione.

Il compromesso barbatrucco

Sfruttiamo una piccola caratteristica che presenta PORTAL. Come mostrato dalla seguente GIF:

In questo esempio mostriamo il dettaglio. Se aggiungiamo, nel sottotitolo del PORTAL del progetto, possiamo aggiungere dei link e, anche senza inserire codici particolari, sono immediatamente convertiti in link che ci reindirizzano sui siti indicati.

Conclusione

Si tratta di un compromesso, ovviamente, ma questo ci permette di poter inserire dei link quando non abbiamo a disposizione Confluence.

Annuntio Vobis Gaudium Magnum ……

Habemus Gruppo Atlassian Community espressamente dedicato a tutti coloro che parlano Italiano.

Possiamo finalmente chiarirci i nostri dubbi sui prodotti Atlassian usando la nostra meravigliosa Lingua. Possibile accedere a gruppo attraverso il seguente link.