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.

In questo post andremo ad esaminare un addon veramente interessante. Vi posso assicurare che ho avuto la possibilità di eseguire un collaudo molto accurato ed il risultato mi ha lasciato seriamente a bocca aperta dai grandi risultati ottenuti. Ma andiamo con ordine: Partiamo dall’inizio e spieghiamo il caso di uso cercando di mostrare come funziona questo addon.

Il caso di uso che mi si è presentato

In questa situazione, avevo la necessità di dover modificare massivamente il contenuto di un determinato campo, risultato della Migrazione da Server a Cloud per conto di un mio cliente. In questo caso, i campi migrati erano il risultato della migrazione del valore di Elements (ex nFeed). Il problema è che il valore dei campi risultava un qualcosa di questo genere, inaccettabile da proporre al cliente.

{“key:[“XXXXXXXX – Una descrizione del codice”]}

il risultato era un Json che non rispecchia proprio il valore desiderato dal cliente. Le funzionalità standard non permettono delle modifiche così approfondite. Si rendeva necessaria una operazione di ingegno. Iniziavo una analisi alchemica che mi aiutasse nella risoluzione del problema.

…. ma alla fine il risultato è giunto insperato

Una soluzione si è presentata quando oramai sembrava tutto perduto. Un addon mi salvava la vita e mi permetteva di poter correggere il valore e risolvere la questione. Si tratta di Advanced Bulk Edit for Jira, un addon della Codefortynine molto molto interessante.

Questo addon permette di poter eseguire delle operazioni sui campi permettendone la MODIFICA. Questa è una caratteristica molto molto interessante.

Dalla precedente immagine possiamo osservare che abbiamo diverse possibilità per modificare i campi. Possiamo aggiungere dei valori, eseguire delle operazioni di Sostituzione di testo con altro, etc. La faccenda diventa interessante

La mia esperienza lavorativa

Nell’utilizzo di questo addon ho notato una cosa molto molto interessante. Se andiamo ad eseguire una query JQL, quello che otteniamo è il seguente risultato (il particolare sul CLOUD): La query JQL non restituisce più di 1000 risultati, anche se le issue sono più di 1000. Questa è una limitazione che le API di Jira dispongono. DI conseguenza abbiamo sempre qualche problema

La seguente schermata è stata presa (opportunamente trattata per non mostrare dati riservati) al fine di riuscire a mostrare il risultato. Se ci fate caso il numero di issue selezionato è maggiore di 1000.

Quello che si nota è che il limite di 1000 issue è superato con questo addon. Non male, assolutamente non male.

Conclusione

Abbiamo un addon MOOOOOOOLTO MOOOOLTO interessante. Ho già identificato una serie di possibili utilizzi di questo addon in altri casi di uso. Verificherò e vi riporterò di seguito in altri post. Rimaniamo in contatto.

Reference

Maggiori informazioni sono disponibili presso la pagina del Marketplace.

In questo post andremo ad esaminare un addon che ci permette di poter estrarre i dati dal Cloud in modo da permetterci di poter eseguire delle interrogazioni mirate.

Una premessa importante

Chi lavora con il Cloud sa perfettamente che quando vogliamo eseguire delle interrogazioni sui dati, la risposta è sempre una. Il seguente memo ce lo spiega

Sul Cloud non abbiamo alcuna possibilità: Ci è precluso l’accesso al database interno. Di conseguenza non possiamo fare nulla per lanciare query… almeno fino ad ora.

Abbiamo una soluzione

Inventato da Bob Swift ma adesso sotto il controllo della Appfire, abbiamo un addon che ci aiuta in tal senso, fornendoci la possibilità di costruire un simil-database su cui poter eseguire le nostre interrogazioni.

Questo addon è nato con l’obiettivo di ricostruire un database simile, rispetto a quello che avevamo a disposizione con la versione onPremise, e permettere agli utenti cloud di riuscire a ricostruire delle query ed interrogazioni.

Come possiamo vedere dalla precedente immagine, riusciamo a ricostruire sia i dati della parte standard, compresi i campi custom. Dalla documentazione dell’addon abbiamo a disposizione anche uno schema dati che ci spiega come ricostruire le relazioni tra le varie tabelle:

Possiamo, attraverso questo addon, ricostruire un simil-database (non è proprio il database effettivo: Teniamolo sempre a mente).

L’addon al momento permette di poter estrarre i dati direttamente su di un database Postgresql. Questo ci limita un pò i movimenti, ma non più di tanto. Se in azienda abbiamo uno standard che ci impone l’utilizzo di altre tipologie di Database (ad esempio: In azienda si usano database MS SQL Server). Tuttavia, usando dei server Linux, il problema viene risolto.

Punti di attenzione

Dobbiamo però tenere sempre a mente alcuni punti di attenzione. Ricordiamoci sempre che il nostro Cloud Atlassian è prevalentemente una macchina virtuale localizzata su Internet e di conseguenza abbiamo:

• Il nostro cloud deve poter accedere al database e di conseguenza questo deve essere raggiungibile da internet
• Essendo raggiungibile da internet, occorre che questo database sia gestito in maniera opportuna.
• Non possiamo esporre direttamente i nostri database verso internet
• Il database da usare deve essere un database che viene immediatamente blindato o svuotato non appena viene compilato

Come si può vedere non si tratta di semplici raccomandazioni, ma di punti di attenzione molto importanti. Se non li rispettiamo abbiamo dei problemi abbastanza seri.

Di conseguenza abbiamo molto da considerare.

La mia esperienza

Ho avuto modo di collaudare questo addon direttamente presso un mio cliente e posso dire che l’addon lavora in maniera egregia. Nel senso che i dati estratti sono effettivamente il clone dei dati. Ma vorrei fare alcune ulteriori considerazioni.

Abbiamo principalmente i dati dello standard

Non ci facciamo illusioni. Non riusciamo a disporre di tutti i dati come nel caso delle nostre installazioni onPremise. Infatti quando possibile, si accedeva anche ai dati degli addon semplicemente andando a leggere le tabelle con prefisso AO%, come riportato in questa documentazione ufficiale Atlassian.

In questo caso l’addon ricostruisce, con buona approssimazione, le informazioni standard e attraverso opportune query, riusciamo a leggere le informazioni che ci servono.

Solo alcuni addon sono disponibili

L’addon riesce a leggere i dati di alcuni addon, come TEMPO TIMESHEET, ma una cosa che ho notato è che le informazioni che sono scaricate sono sotto forma di un JSON che deve essere ‘lavorate’ per poter estrarre i dati che servono.

Possibile eseguire backup totali ed incrementali

E’ possibile eseguire entrambe le modalità. Nel mio caso, potrebbe essere utile eseguire un primo backup generale e poi tutti i backup incrementali. Questo aiuterebbe notevolmente

Conclusioni

Abbiamo un addon interessante ma che deve essere usato con tutti i crismi del caso. Possiamo estrarre i dati che ci interessano e fare le statistiche personalizzate del caso, anche se in ultima istanza suggerisco di appoggiarsi ad appositi tools che permettono di poter portare le informazioni di Jira su PowerBI o QLIK e consentono di gestire le statistiche molto meglio che con un semplice database da rimettere in piedi.

Come sempre riporto le mie indicazioni perché, questo sicuramente lo avrete compreso leggendo i miei post, che è sempre meglio avere più possibilità che solo una possibilità. La libertà di scelta è una arma molto potente che intendo sempre sfruttare e mettere a disposizione, anche quando eseguo le mie consulenze.

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

La gestione degli utenti è molto importante per i Site Administrator dei prodotti Atlassian. Lo sappiamo bene noi che ci lavoriamo tutti i giorni e che ci scontriamo con le varie problematiche.

Tuttavia i produttori di Addon ci aiutano in questo arduo compito. Grazie a loro riusciamo a risolvere al meglio tutte le nostre problematiche, arrivando ad avere

Cosa ci permette di fare?

Questo addon ci aiuta nella gestione utenti semplificata, permettendo anche di poter gestire alcune funzioni interessanti. Andiamo subito a curiosare sulle possibilità offerte.

Possiamo avere una gestione semplificata degli utenti attraverso una funzione di importazione degli stessi e permetterci di semplificarci la vita. Infatti, non tutte le organizzazioni si possono permettere di acquistare Access e l’utilizzo di Addon che dispongono di questa funzione, ci permette di poter avere delle funzioni non indifferenti

IN aggiunta abbiamo la possibilità di poter inserire, sempre in maniera semplice, i nostri customer interni in maniera semplice e veloce, sfruttando le funzionalità che sono presenti a sistema.

La mia esperienza lavorativa

Posso dire che questo addon, in un particolare caso, ci ha permesso di poter gestire al meglio i customer interni di una azienda, permettendoci di poterli creare e configurare in pochissimo tempo (neanche 1 ora).

Abbiamo usato con successo la funzione che ci permette di poter attivare tali customer velocemente ed il cliente è rimasto piacevolmente soddisfatto del risultato. Lui stesso lo utilizza per poter attivare i nuovi customer.

Questa immagine non può che esprimere al meglio quanto penso dell’addon

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.

Scrivo questo articolo quasi di getto e per rispondere alle ultime novità sul mondo delle Automazioni. Principalmente sulla parte Cloud di Jira. L’obiettivo è di fornire un quadro situazione per mostrare il funzionamento delle ultime novità e per indicare anche come poterle gestire correttamente. A tale proposito ho predisposto una regola di tipo didattico per descrivere meglio il funzionamento, ma andiamo con ordine.

Marzo 2023

Verso la fine del mese di marzo 2023 succedeva una cosa leggermente strana. Mi segnalavano che nelle istanze Cloud l’addon delle Automation risultava in TRIAL e sopratutto era ben staccato. Di conseguenza molti miei clienti si sono preoccupati (ma non solo loro).

Da un rapido controllo era emerso che Atlassian stava semplicemente integrando l’addon trasformandolo da addon esterno a addon di Sistema.

Infatti se andate a controllare, oggi lo troviamo come addon di sistema.

Fino a questo non ci sarebbe molto altro da dire… tuttavia abbiamo anche delle altre sorprese. L’integrazione si è portata dietro anche delle novità. Vediamole nel dettaglio:

Automation manuali

Una delle novità riguarda l’introduzione delle Automation manuali, ovvero richiamabili su richiesta dall’utente

Notiamo tuttavia una cosa molto molto … preoccupante. La combo che permette di richiamare questa nuova funzione è vicinissima alla combo del passaggio di stato. Molti mi hanno fatto notare (e sono perfettamente d’accordo) che la probabilità di selezionare la combo sbagliata è altissima. Devo riconoscere che la Atlassian ha introdotto una funzione importante, ma tempo che nella foga del momento non abbia ben calcolato dove inserire tale funzione, scegliendo una posizione infelice. Il mio suggerimento è di trattarla come le funzioni degli addon. Esiste la sezione dedicata alle Automation. Credo che sia meglio inserirla li

Non sono d’accordo con il messaggio. A mio giudizio questa sezione è quella ideale per gestire tale funzionalità.

Che altro?

Ci sono anche delle altre novità. Abbiamo a disposizione, sempre lato Automazioni, delle nuove funzionalità interne che ci permettono di poter gestire meglio delle …….. TABELLE DI LOOKUP

Vedo che ho catturato la vostra attenzione. Andiamo subito al sodo. Se infatti ricerchiamo tra le possibili azioni, abbiamo la possibilità di poter creare questa tabella:

Siamo ancora alle prime armi, ma possiamo subito vedere che il potenziale ci sta tutto. Anche se limitato a 20 entry massimo, possiamo impostare una serie di corrispondenze che possiamo sfruttare a nostro vantaggio.

Per richiamare le corrispondenze abbiamo a disposizione un semplice metodo. Infatti questa tabella si definisce come uno Smart Value. Basta semplicemente usare:

{{Esempio.get(issue.summary)}}

per richiamare la corrispondenza. In questo esempio abbiamo la possibilità di poter sfruttare anche degli altri Smart Value. Cosa molto importante.

Risultato, Conclusioni?

Semplice: Abbiamo la possibilità di poter gestire queste regole in maniera molto più semplice, ci liberiamo dalla schiavitù di blocchi IF-THEN-ELSE potenzialmente infiniti e abbastanza difficili da gestire. Ci permette di dare un ordine non indifferente e, come vediamo, anche di gestire al meglio queste situazioni. Ripeto. Siamo alle prime armi. Le novità non sono sempre cattive, ma hanno sempre del potenziale. Dobbiamo sempre vedere il potenziale, senza mai perdere di vista i punti di attenzione.

Un annoso problema che ci assilla è causato dal fatto che non sempre possiamo collegare Jira Cloud con i Database….. fino ad ora. Qualche mese fa stavo eseguendo delle sperimentazioni che mi hanno portato a scoprire un addon molto interessante. Adesso, dopo la sperimentazione posso descrivere i primi risultati.

Descriviamo lo scenario

Questa situazione la conosciamo bene. Quando i clienti ci chiamando perché vogliono leggere le informaizoni dai loro database locali e le vogliono rendere reperibili anche su Jira Clòoud. Questa di solito è la nostra faccia

Proviamo a chiarire. Sappiamo beniussimo che il nostro Cloud è una macchina remota AWS localizzata, nel nostro caso, a Dublino o Francoforte (quindi GDPR RISPETTATA. CHIARO??). Concetto da tenere sempre presente è che Jira Cloud è su Internet e di conseguenza per poter accedere ad un database, questa macchina su internet deve essere (UDITE UDITE) autorizzata.

Ora, se andiamo in una azienda qualsiasi, i responsabili della sicurezza avrebbero qualcosa da dire. Se apriamo una porta del genere, occorre ben presidiarla oppure si rischia di fare dei danni. Ricordiamoci sempre che quando si apre una porta su internet, prima o poi si rischia che qualcuno di non desiderato entri dentro senza il nostro permesso. Fa parte dei rischi.

Quali precauzioni?

Possiamo prendere diverse precauzioni per far si che chiunque tenti di entrare non possa andare oltre un certo limite e, se anche dovesse arrivare, li si fermi. Parafrasando il celebre film “Il Codice da Vinci”, mi permetto di citare un verso della Bibbia: (Giobbe 38-11). e dissi: `Fin qui tu giungerai, e non oltre; qui si fermerà l’orgoglio de’ tuoi flutti?’

Possiamo fare in modo che il database che colleghiamo a Jira Cloud sia una copia con pochi dati. In questo modo, anche se qualcuno dovesse arrivare a leggerli, le informazioni siano parziali e non servibili allo scopo. Questo però implica che:

• i dati devono essere aggiornati a cadenze regolari
• In alcuni istanti i dati non saranno perfettamente disponibili (intendo gli ultimi)
• In ogni caso se qualcuno arriva li, legge dei dati e potrebbe comunque tentare delle operazioni di ricostruzioni.

Sicuramente questo è un sistema per limitare il danno, ma non eliminiamo completamente la possibilità di eliminare il danno.

La vera precauzione consiste nell’inserire il database direttamente su Jira, o sulla macchina remota. Solo così avremmo a disposizione la possibilità di poter gestire una sicurezza molto alta. Se il database è già interno a Jira, allora abbiamo la sicurezza di Atlassian che ci protegge. Tuttavia la macchina remota NON è usabile da parte nostra e non credo che Atlassian ci permetta di poter mettere mano a tali macchine dall’oggi al domani. Di conseguenza le possibilità sono molto ridotte….. oppure no?

Non disperiamo. Abbiamo una soluzione

Ebbene si. Abbiamo una soluzione. Possiamo portare i dati direttamente su Jira e usarli come un database e per questo obiettivo un potente addon ci permette di poter gestire questa situazione. ma come?

Semplice. Possiamo memorizzare i dati all’interno di un progetto di comodo, dove i record sono presenti nelle issue. Come ben sapete, le issue possono diventare qualsiasi cosa noi vogliamo. Questa è una delle grandi possibilità che Jira mette a disposizione di noi utenti.

Benissimo. Se mappiamo i record usando le issue type seguendo questa logica: è un tipo di record. Nell’issue type andiamo a memorizzare i dati che ci servono, utilizzando i campi custom per memorizzare anche altre informazioni del nostro record. Risultato? abbiamo il nostro database locale.

A questo punto passiamo alla seconda domanda. Come lo usiamo?

Anche qui ci viene incontro uno splendido addon che ci aiuta a rispondere a questa seconda domanda. Si tratta di:

Questo addon permette di poter eseguire delle interrogazioni direttamente su Jira come se fosse un database. In questo caso abbiamo a disposizione la nostra arma segreta: il JQL; che ci aiuta nell’interrogare i dati senza grandi problemi. Lo stesso lo possiamo fare con questo addon che ci permette di poter gestire il risultato finale.

L’addon permette di poter creare una connessione a Jira Cloud stesso . Questo consente di gestire Jira Cloud come un database e, come sempre sostengo da immemore tempo, il JQL ci aiuta a creare la query di selezione dei dati

Moooolto interessante e quale è il risultato?

Il risultato finale è che abbiamo a disposizione la possibilità di definire dei campi ‘database’, se mi si può concedere la libertà di scrivere così, dove i valori visualizzati sono prelevati dal progetto che abbiamo definito su Jira

Sfruttando l’addon possiamo ottenere questo risultato:

Come possiamo vedere, l’addon ci permette di poter sfruttare le issue di un progetto come se si trattasse dei record del nostro simil-quasi-database (concedetemi questo termine), ma l’utente finale non vede questa cosa: per lui è una lista. L’addon permette anche di poter aggiornare il campo a cadsenze regolari. Ciò che si deve fare e aggiornare l’elenco delle issue del progetto che abbiamo battezzato. L’addon può essere programmato per far si che l’elenco sia aggiornato a cadenza regolare.

Ovviamente consiglio di trovare un compromesso al tempo di aggiornamento che vogliamo: Questo per evitare comunque di sovraccaricare la nostra istanza di Jira Cloud.

Risultato?

Abbiamo una nuova arma in più per definire un database all’interno di Jira e sopratutto abbiamo la possibilità di poter mantenere una discreta sicurezza senza aprire quella della nostra sicurezza. In aggiunta, questo sistema può essere usato anche per:

• definire assets aziendali senza avere insight
• definire delle tabelle di un database interno a Jira
• definire delle semplici liste valori aggiornabili facilmente
• definire quello che vogliamo all’interno di Jira.

L’unico limite è la nostra fantasia.

Un mio appunto personale

Il 29 Giugno ho avuto il piacere di presentare questa soluzione al Meetup Madrid/Buenos Aires. Mi permetto di condividere il Video del mio intervento, disponibile su Linkedin

Reference

Maggiori informazioni sull’addon sono disponibili nella pagina del marketplace.

In questo post andremo a descrivere i nostri test sulle App che Appsvio ci mette a disposizione. Li ho visti in azione e ho partecipato all’ACE di Boston, dove ho avuto il piacere di fare uno Speech. Li ho testati sul campo su situazioni reali e cercherò, in questa sede, di descrivere gli scenari che ho affrontato.

Customer and Organization Management for JSM

E’ il primo addon che ho avuto modo di vedere in azione e le mie impressioni sono più che positive. Lo scenario che ho visto riguarda la gestione degli utenti esterni di un Service desk. Il mio obiettivo era quello di creare rapidamente e, sopratutto, in maniera molto semplice, un insieme cospicuo di customer. ribadisco. ESTERNI.

Se il cliente deve gestire tale situazione, usando la gestione standard, dette out-of-the-box, abbiamo una sola alternativa: FARLO A MANO.

L’addon ci permette di poter gestire questa operazione in modo più agevole. Una interfaccia non indifferente ci aiuta ad eseguire questa operazione

L’ultima immagine svela come ho fatto. Questo addon mette a disposizione una funzione per poter importare, usando un semplice CSV file, gli utenti che ci servono. Usando questo barbatrucco, possiamo creare tutti i customer esterni che ci servono.

Non ho mica finito

Il test continua nel prossimo post e vedremo che cosa ci permette di fare il prossimo addon Appsvio. Stay Tuned.

In questo post andremo ad testare un addon molto interessante, in cui vediamo come gestire al meglio le Retrospettive dei nostri sviluppi, o anche delle sole operazioni. Se vi ricordate, ne avevo parlato anche in altri miei post in passato, dove indicavo come questa caratteristica come una operazione fondamentale da usare anche per analizzare i problemi e impostare delle risoluzioni.

Ho indicato nel mio precedente post di presentazione, che questo addon ben si presta anche ad altri utilizzi. In questo articolo andremo a valutare anche queste possibilità. Proviamo a sperimentare.

Installazione

Come sempre partiamo dalla installazione dell’addon, verificando i vari passi. A tale scopo, usiamo una delle tante istanze id test che ho a disposizione.

Configurazione Generale

Procediamo con la configurazione generale. La prima operazione che dobbiamo fare è quella di attivare il progetto affinché possa utilizzare le nuove funzioni: L’addon mette a disposizione una interfaccia generale da cui accedere alle funzionalità offerte. Dal menù Apps abbiamo a disposizione una apposita voce di menù:

La seguente GIF ci mostra cosa viene mostrato alla selezione della voce di menù Apps:

In un mio ambiente di test ho predisposto un progetto di sviluppo software per poter eseguire il test, come potete vedere dalla seguente immagine.

Cosi come abbiamo abilitato il progetto usando le interfacce dedicate dell’addon, abbiamo la stessa possiblità anche nelle configurazioni del progetto.

Procediamo con la configurazione da adottare sul singolo progetto. In questo caso impostiamo la prima configurazione usando quanto l’addon stesso mette a disposizione. In particolare selezioniamo Setup Retrospective e….

A questo punto selezioniamo Join Retrospective e procediamo con il test.

Test addon

Procediamo con il test canonico. In questo caso abbiamo usato il template standard e abbiamo iniziato a lavorare gestendo una retrospettiva. Nella prima fase andiamo a censire tutte le indicazioni di:

• cosa è andato bene
• cosa non è andato bene
• cosa è piaciuto
• cosa non è proprio piacuto

Un timer ci ricorda che la fase deve durare il giusto tempo, senza che le persone del gruppo di lavoro siano impegnate troppo tempo. Possiamo comunque interrompere questo timer in qualsiasi momento. Una volta identificati tutti i punti, si procede con la fase successiva:

Possiamo in questo punto sempre andare a modificare ed integrare i vari punti che sono stati espressi dal gruppo di lavoro.

A questo punto Possiamo eseguire delle ulteriori operazioni

A questo punto possiamo votare i punti rimanenti per poterli poi discutere

A questo punto procediamo con i punti votati per arrivare a definire quali punti devono essere affrontati per migliorare la produttività del gruppo di lavoro

Iniziamo a impostare le azioni da intraprendere

A questo punto possiamo concludere la retrospettiva e questo è il risultato:

A questo punto, da questo report abbiamo la possibilità di poter generare dei task che possono essere assegnati e lavorati per poter chiudere la retrospettiva e giungere al miglioramento.

Un uso alternativo dell’addon

Vediamo in questo capitolo come possiamo fare un uso alternativo dell’addon.

Ho esaminato il funzionamento e mi viene una strana idea. Se utilizziamo questo addon per arrivare a definire un … Requisito Funzionale? Potrebbe essere una idea delle tante che mi sono balzate in testa.

A questo scopo andiamo a definire un nuovo template

Creiamo quindi il nostro nuovo modello

A questo punto ripetiamo le operazioni che abbiamo visto in precedenza

Quindi? il risultato che abbiamo a cosa ci porta?

Semplice: Possiamo adeguare questo addon per definire un percorso che ci aiuta nel ragionamento e nel determinare il risultato che vogliamo ottenere. Le colonne che possiamo definire, ci aiutano a determinare un workflow molto semplice, che ci permette di guidarci. In aggiunta ci permette di poter standardizzare il modo con cui ragionare in ambito aziendale e questo è molto importante se vogliamo che un domani, quando altre persone vogliono lavorare nella redazione di un nuovo requisito, il workflow sia il medesimo.

In questo caso specifico che ho riportato, risulta quindi possibile inserire tutti i punti che ci aiutano nella definizione di un requisito funzionale e che ci permettono di poter schematizzare questa analisi, che ci porta a definire il requisito. Ovviamente ho inserito un esempio.

Possiamo a questi punto fare una considerazione. Abbiamo la possibilità di poterci definire tutto quello che vogliamo. Possiamo usare questo addon per definirci qualsiasi lavorazione di cui abbiamo bisogno qualsiasi workflow che ci aiuti nel raggiungere un determinato obiettivo. L’unica limitazione è la fantasia.

Domanda:

Sappiamo che nel profilo Standard, l’utilizzo delle regole globali è limitato. Come possiamo tenere sotto controllo il numero di esecuzioni?

Risposta

Possiamo sempre controllare il numero di esecuzioni. Gli utenti Jira Administrator possono accedere alla relativa sezione che gestisce le regole di Automation. Li troviamo una sezione che ci dice quanto è il consumo.

Adesso è bene chiarire un punto importante

Questo post mi serve anche per dare un chiarimento molto importante. Si tratta di una cosa che mi ha lasciato abbastanza basito e credo che sia bene chiarire, altrimenti mi trasformo nell’Incredibile Hulk…..

Sulle regole di automazione, si sta diffondendo una convinzione che non ha proprio ragione di esistere. Alcune aziende mi hanno segnalato che per poter sfruttare al massimo le regole di automazione, occorre disporre di un profilo Cloud PREMIUM, mentre con un profilo free o standard non si ottiene nulla a causa delle eccessive limitazioni sulla esecuzione delle regole stesse. Scusate ma proprio non comprendo proprio questa frase perché, cosi come viene impostata, non ci dice nulla, anzi. genera molta più confusione di quanto si possa immaginare. Proviamo a chiarire meglio.

Mi permetto di citare il link di documentazione ufficiale dove si spiegano diverse cose e invito una attenta lettura dello stesso in modo da chiarirsi le idee.

La limitazione riguarda l’esecuzione delle regole che sono applicate a:

• più progetti o multiprogetto
• globali

In particolare ripongo l’attenzione su questa frase:

All multi-project and global rule executions will count toward your usage. Single-project rule executions do not count toward your usage.

Fonte : Il documento sopra citato

In particolare mi permetto di riportare la seguente immagine, tratta dallo stesso documento sopra citato:

Quindi mi sembra di capire che le limitazioni sono attive, nei profili standard e free, solo quando la regola non è più applicata ad un singolo progetto. Se la regola è monoprogetto, non abbiamo alcuna limitazione.

Quindi l’informazione corretta è: Se si usano le regole su singolo progetto, non dobbiamo preoccuparci per il limite. Altrimenti, si.

Vero, ma avere una regola globale la gestiamo meglio ….

Verissimo, ma proviamo a ragionare alla Italiana (anzi: alla Siciliana). Lo so, mi piace vincere facile 🙂 . E’ vero che usando una regola per singolo progetto ci limitiamo e abbiamo il problema che se la dobbiamo applicare su più progetti = gestire più regole e modificare più regole. Concettualmente è sbagliato. Se il numero di regole è inferiore a 10, allora possiamo anche rischiare. Se superiamo questo limite, allora possiamo anche valutare il numero di esecuzioni e verificare se abbiamo la necessità di andare su profilo PREMIUM. Andare alla cieca equivale impegnare un budget in maniera errata. Vi lascio immaginare le conseguenze.

Come sempre dico: VALUTARE BENE e poi decidere, ma ancora meglio se abbiamo a disposizione tutte le informazioni. In caso contrario quello che potrebbe succedere è che decidiamo in maniera errata senza avere la soluzione che ci serve.

Conclusione

Invito a tutti i lettori ad una ovvietà: ragionate sempre con la vostra testa. Se vi dicono che le cose funzionano in un certo modo, FATE UN CONTROLLO, come sempre faccio io. Tutto quello che scrivo è frutto della mia esperienza e di conseguenza di quello che ho visto all’opera. Vi lascio con una fonte di ispirazione:

Esaminiamo oggi una soluzione molto interessante, presentata da MrAddon by Tecnofor, per gestire la Matrice di Priorità. Prima di presentare l’addon, credo che sia doveroso prima iniziare a descrivere i concetti che stanno alla base. Entriamo in modalità esplorazione.

Cosa è la matrice di priorità?

Prima di parlare dell’addon, occorre definire che cosa è una Matrice di priorità e spiegare come si usa. Non pretendiamo di fare una trattazione …. pesante. Per questo vi rimando ai siti che danno una spiegazione più che esauriente. A ciascuno il suo mestiere.

Questo concetto ci riporta ad una questione che molti di noi conosciamo. Quando un nostro customer ci apre una segnalazione, abbiamo sempre un problema perché chi lo apre da una priorità, mentre chi lo deve risolvere ha una sua priorità. Questo è un dato di fatto. Di conseguenza occorre stabilire un principio che aiuti chi deve risolvere, cosa è effettivamente urgente, grave o problematico. La Matrice di Priorità di aiuta a gestire questa situazione.

MrAddon by Tecnofor interviene in questo punto con la sua soluzione che permette di fornire una chiave di lettura e di aiuto per gli Agenti.

Questa soluzione prevede L’introduzione di due nuovi campi, sui quali andiamo a definire la matrice che ci aiuterà nel definire che cosa è realmente urgente e grave da quello che non lo è. Il Customer viene invitato a impostare due campi che indiano le seguenti informazioni:

• Impatto
• Urgenza

IL primo inteso come Impatto del probelma segnalato mentre il secondo riguarda l’urgenza della segnalazione che viene proposta. Il customer è obbligato a tale scelta.

Cosa vede l’agente?

L’agente vede i due campi compilati, ma grazie alla matrice riesce a determinare la vera urgenza e ad agire tempestivamente per quello che serve.

Infatti, grazie ai valori indicati, quello che possiamo fare grazie alla Matrice delle Priorità, abbiamo l’assegnazione della reale priorità, in base a ciò che serve realmente

Usando questo sistema, possiamo definire facilmente la reale priorità da assegnare alla segnalazione e procedere di comseguenza.

Conclusione

Abbiamo dato una prima occhiata ad un sistema per definire come possiamo dare una reale priorità alle segnalazioni che ci arrivano dai nostri utenti, senza diventare matti e senza dover eseguire un triage che ci permetta di avere un risultato pronto per avere una reazione in base a ciò che effettivamente in base alla reale esigenza. Da provare 🙂