Ancora una piccola precisazione sulle Automation

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.

Procediamo senza indugio

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. 😉

Un esempio ben dettagliato di questa gerarchia

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.

Un dettaglio della azione

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

Ragioniamo e verifichiamo

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:

Uno schema del JSON da usare

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.

Grazie.

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:

URCAAAAAA

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




Creiamo un link ad una pagina di Confluence su Jira

In questo post affrontiamo un argomento interessante, inerente le Regole di Automazione. Già recentemente abbiamo parlato, in questo post, di come la gestione dei limiti di queste regole cambiano dal prossimo primo novembre. Vediamo in questo caso come sopperire ad una necessità, ovvero come possiamo aggiungere un link ad una Pagina di Confluence ad una issue, direttamente da Regola di automazione.

Come moderni Bandeirantes, andiamo in esplorazione

Andiamo con ordine

Vogliamo associare ad una issue, quella che ha causato l’esecuzione della nostra regola, una pagina di Confluence ben precisa. Una cosa che notiamo subito è che non abbiamo a disposizione una azione specifica attraverso le Automazioni. DI conseguenza siamo leggermente frustrati. La domanda sorge spontanea. Come possiamo fare??

Stiamo calmi

Abbiamo una soluzione

Ebbene si. Possiamo sfruttare una delle azioni che meglio si adegua per poter agganciare una pagina ad una issue. In particolare possiamo sfruttare questa azione:

Send Web Request è quello che ci serve

Da questa azione possiamo fare ua cosa molto semplice: Chiamare una API di Atlassian e agganciare la pagina alla issue. ma vediamo quale è la API che andiamo a richiamare.

https://yourdomain.atlassian.net/rest/confluenceIssueLink/1/confluence?issueId={{issue.id}}&pageUrl={{createdPage.url}}

Questa è la chiamata alla API che ci interessa

Quello che occorre fare è impostare i parametri che ci servono e successivamente applicarli tramite la regola.

Il risultato è il seguente:

Un esempio che ho impostato su di un mio ambiente di prova

Conclusione

Questo è molto interessante. Possiamo agganciare una pagina Confluence alla nostre issue in maniera veramente semplice. Ci sono degli accorgimenti da tenere presente quando si utilizzano delle API, ma ne parleremo in maniera più approfondita in separata sede. Si tratta di una sorpresa. Rimaniamo in contatto.

Reference

Un ringraziamento a tutti i partecipanti a questa discussione della Atlassian Community, dove è stato chiarito questo punto e che ha permesso di poter scrivere questo articolo in Italica Lingua.




Sulla necessità di modificare massivamente i dati di un campo Jira Cloud

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.

Set explore mode = ON

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.

Questa immagine descrive la mia situazione. Nottate ad elucubrare per un risultato

…. 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.

La pagine dell’addon su Marketplace.

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

Fonte Marketplace Atlassian

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

Iniziamo a rilassarci e a pensare quante possibili applicazioni possiamo farne

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

Calma, non disperiamo. Abbiamo una piacevole novità

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.

Tratto da una operazione di Bulk Edit che hi eseguito.

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.




Team managed Vs Company Managed

Sono sempre stato leggerissimamente scettico dei progetti Team Managed. In questo articolo provo a spiegare come mai lo sono e perché, sempre secondo la mia modestissima personale opinione, è sempre preferibile creare dei progetti Company Managed. In qualsiasi caso

Esplorazione alchemica in corso

Le ragioni che porto sempre con me

La prima cosa che indico come difetto di tali progetti è il fatto di avere una configurazione molto molto (in alcuni casi uso anche il termine TERRIBILMENTE) limitata. Questo fa si che sia molto semplice configurare un progetto siffatto. Tuttavia non sempre questo può risultare una arma vincente. Infatti se mettimao a confronto le due possibili configurazioni che abbiamo

Il confronto che troviamo quando generiamo nuovi progetti

Team Managed configuration

Company Managed configuration

La prima cosa che notiamo è che le opzioni sono limitate per i Team Managed. I Company managed, per quanto più complicati, sono sempre più completi nella configurazione e nella gestione. Questo sicuramente ci aiuta (per citare un vecchio adagio che ho imparato nella meravigliosa città di Lucca: Nel più c’è il meno).

In aggiunta, nei Team managed ho notato una cosa molto grave (secondo sempre il mio modesto parere): Non possiamo usare le risorse condivise. In alcuni casi mi sono trovato costretto ad una trasformazione di un progetto da TEAM a COMPANY perché non c’era alcuna possibilità di poter espandere tali progetti e sopratutto gli utenti erano stati costretti a replicare all’infinito (copiando manualmente e non assegnando una configurazione preesistente).

In aggiunta, non sempre gli addon sono usabili anche su tali progetti. Ho rilevato che alcuni di essi non rispondono correttamente quando si prova ad applicarli.

Il mio dubbio è che questa tipologia di progetti, per quanto comodi, semplici e rapidi, non presentino delle strutture condivise e standard. Di conseguenza, occorre un qualcosa ad hoc per poter loro agganciare delle funzionalità standard.

Un progetto Company Managed, per quanto sia complicato, hai comunque il controllo completo della configurazione e riesci sempre a cadere in piedi. Mi permetto di condividere un meme che ho visto qualche tempo fà ed esprime esattamente dei concetti molto importanti:

Direi che l’immagine si commenta da sola

In questo caso è come disporre di un Linux e della sua splendida POTENZA.

Conclusioni

Quello che continuerò a suggerire, consigliare, fare presente e ribadire sotto tutti i punti di vista è che un progetto Team Managed va bene per fare cose molto semplici. Se si prevede nel futuro di fare qualcosa di più, partite subito con un progetto Company Managed.

A tale proposito, vi chiedo di visionare questo video di Monika Rani, che spiega in maniera molto chiara e semplice la differenza tra i due tipi di progetti:

e questo ottimo articolo, sempre scritto da Monika Rani, che spiega come migrare da Team a Company

https://monikarani.com/migrate-team-managed-projects-to-company-managed-projects-in-the-jira-cloud/



Un addon interessante per il Cloud

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

Altra esplorazione alchemica

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.

Fonte Marketplace

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.

Fonte Marketplace

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.

L’immagine serve per descrivere la soddisfazione del cliente

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

Il mio giudizio: POSITIVO

Reference

Maggiori informazioni sono reperibili alla pagina del Marketplace.




De Automation Rules Eloquentia

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.

Quello che viene mostrato dalla sezione degli Addons-Apps

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

Nuova funzionalità… ma…. 😮

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

Notiamo che il messaggio ci da la ferale notizia

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

INTERESSANTE

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.

Finalmente non avremo dei cicli IF THEN ELSE infinitiiiiiiii

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.




Jira Cloud e i database – Una ipotesi di lavoro interessante

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.

Modalità sperimentatore Alchimista in azione

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

La scena è presa dal celebre film THE MASK, ma descrive bene come ci riduciamo

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.

Ok. Adesso vediamo quali precauzioni possiamo prendere

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.

Come dice la stessa immagine, e allora?

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:

Scheda su Marketplace Atlassia dell’addon

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

La configurazione che l’addon mette a disposizione quando si collega a Jira Cloud Stesso.

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

Un esempio di progetto a mo di Database

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.




Appsvio – Primi test sul campo

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.

Modalità alchimista esploratore ON

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.

Un esempio tratto da un mio ambiente di prova

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

Un esempio: Sempre dal mio ambiente di prova, dove ho creato degli utenti di prova senza alcuna fatica
Come organizziamo le organizzazioni…. facilmente
L’opzione che. ho usato

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.

Lo studio continua



Risposte rapide: Utilizzo delle regole globali in Jira Cloud

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.

Questo è un esempio preso da uno dei vari cloud che gestisco

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…..

Come non ricordare Lou Ferrigno quando interpretava L’incredibile Hulk nella omonima serie televisiva…. (Ricordi di gioventù)

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:

Fonte: Il 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.

Rimaniamo vigili. Studiamo ed applichiamo tutti i giorni

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:

Non sono un grande fan di Clint Eastwook, ma in questo film esprime un concetto IMPORTANTE. Ricordiamolo sempre



Retrospettiva: Come la gestiamo al meglio

In questo post andremo ad esaminare 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.

In questo caso vediamo come poter gestire questa fase direttamente sotto Jira, senza dover saltare come dei canguri da Jira a Confluence e viceversa.

Infatti, se riusciamo a rimanere nella stessa pagina (o sempre nello stesso applicativo), siamo sicuramente favoriti e non perdiamo il filo del discorso. Entriamo in modalità esplorazione, come moderni Alchimisti.

Come moderni Alchimisti, esploriamo le funzionalità offerte da questo addon

Presentazioni doverose

Cerchiamo in questo paragrafo di introdurre il concetto di Retrospettiva: Prima di usare questo addon dobbiamo prima introdurre questo concetto per mostrarne poi il funzionamento. Andiamo quindi alla definizione.

In questo caso mi permetto di citare il seguente sito: Kambanize; e la seguente pagina, dove ho trovato una spiegazione semplice e chiara della definizione di Retrospettiva e di tutti i concetti ad esso collegati: I miei più sinceri complimenti per lo splendido lavoro fatto.

Complimenti vivissimi

Come funziona l’addon e che cosa offre agli utenti di Jira?

L’addon mette a disposizione una serie di strumenti, interni a Jira, per poter realizzare la Retrospettiva in maniera semplice. Ricordiamo, seguendo quello che vi ho consigliato di leggere, che la retrospettiva è un momento il Team si ferma e riflette sugli ultimi sviluppi eseguiti. Questa fase è importante perché serve pr riflettere su cosa è andato bene e cosa male; cosa migliorare e cosa mantenere e cosa non mantenere.

La modalità scelta dall’addon consiste nello spezzare la retrospettiva nelle seguenti fasi:

  1. Selezionare il Team che deve eseguire la selezione e il modello di retrospettiva che vogliamo operare. Per modello si intende la costruzione di una …. Kanban dove è possibile inserire delle colonne che rappresentano i vari punti (di forza, di debolezza, da chiarire, miglioramenti, etc);
  2. Una fase di Brainstorming, dove si vanno a riportare nelle varie sezioni, come se si trattasse di card di una kanban (siamo già abbastanza abituati a queste fasi grazie alla facilità di uso di Jira). In questa fase andiamo a costruire l’elenco dei punti da esaminare…. e li andiamo ad esternare tutti.
  3. Una fase di analisi e raggruppamento di queste card, in modo da catalogare questi punti da discutere con il Team. Diciamo che in queste prime fasi servono per preparare gli argomenti di discussione che devono essere derivati dalla esperienza diretta dello sviluppo…. ma non solo.
  4. Gli argomenti indicati nelle Card possono essere votati, in questa fase successiva, per poter essere selezionati e avere solo gli argomenti chiave, secondo quanto tutti i partecipanti alla retrospettiva pensano e ritengono opportuni.
  5. Ultima fase la discussione delle Card votate e, conseguenza, creazione delle azioni da intraprendere per poter migliorare ulteriormente i risultati.che possono sfociare in un insieme di issue Jira che possono essere assegnate alle persone del team affinché si occupino di implementare quelle azioni.
Siamo al lavoro per migliorare noi stessi

Alcune considerazioni

Nelle mie indicazioni ovvero quelle che ho indicato nella parte di introduttiva del post, ho scritto che la Retrospettiva può essere anche usata per capire se l’operazione che abbiamo eseguita (qualunque essa sia) deve essere rivista per migliorarla, mantenerla così, rimuoverla. Ovvero possiamo usare questo sistema anche per fare retrospettiva NON legate allo sviluppo software. Di conseguenza questo addon è usabile anche in altre situazioni. La faccenda si fa interessante.

Si….. molto interessatne

Una anteprima dell’addon

Come sempre andiamo a visionare in anteprima alcune funzionalità dell’addon mostrando degli screenshot che sono messi a disposizione dagli autori stessi dell’addon. La prima cosa che dobbiamo eseguire è attivare l’addon per il progetto. Infatti, come ben sappiamo, tutti gli utenti possono potenzialmente usare gli addon installati, ma non sempre questo è conveniente. Di conseguenza molti produttori inseriscono la possibilità di limitare l’utilizzo. Durante il test andremo a vedere come procedere.

La prima cosa che notiamo è che possiamo scegliere il nostro template su cui operare
Notiamo che possiamo creare il nostro Template

Possiamo scegliere il template di schema che possiamo usare per poter creare la Retrospettiva. Altro fatto importante è la possibilità di poter creare e gestirci il nostro proprio template. Questo lo teniamo d’acconto: La possibilità di poterci personalizzare il tutto, ci permette una discreta libertà, e questo lo voglio sfruttare a nostro vantaggio.

Selezionato il nostro template, Possiamo iniziare a creare le nostre retrospettive sfruttando lo schema che abbiamo.

Le fasi sono ben chiare

Tutte le fasi della Retrospettiva sono ben chiare e marcate. Di conseguenza anche chi le esegue per la prima volta non si confonde, ma anzi viene guidato.

Le azioni. daintraprendere diventano Issue di Jira …. subito

Con pochi click le azioni diventano issue di Jira. e subito le persone possono iniziare a lavorare a come migliorare il proprio lavoro. Il vantaggio è sotto gli occhi di tutti. Una persona che lavora nel migliorare il proprio lavoro lo fa con uno spirito migliore.

Conclusione e una ulteriore considerazione

Il giudizio iniziale che abbiamo sull’addon è sicuramente ottimo. Le funzioni Out-of-the-box ci mettono a disposizione solo una possibilità per eseguire una retrospettiva su Jira: Usare Confluence per generare delle pagine dedicate all’argomento, collegare tali pagine alle issue di Jira. In questo caso l’addon ci mette a disposizione una serie di funzionalità che ci aiutano a automatizzare delle procedure che ci portano ad eseguire la Retrospettiva in maniera molto più semplificata e sopratutto ….. strutturata.

Rianalizzando il tutto, forse questo addon potrebbe essere usato anche per altri scopi

Ma mi permetto una riflessione. Ad un primo esame queste funzioni potrebbero anche essere usate con un altro obiettivo. Mi spiego meglio. Sapete che non sempre uso ciò che Jira mette a disposizione con modalità standard. Cerco sempre di sfruttare ciò che viene messo a disposizione anche per fare altre operazioni e coprire altre necessità. Perché no? Le funzionalità non esistono solo per una possibilità, ma per tutte le possibilità che la nostra fantasia ci mette a disposizione. Per questa ragione voglio provare, durante la fase di test, a tentare anche un uso non proprio canonico dell’addon. Proviamo.

Reference

Maggiori informazioni sono disponibili alla pagina del Marketplace.