MokaByte https://www.mokabyte.it/ Dal 1996, architetture, metodologie, sviluppo software Fri, 11 Nov 2022 18:16:25 +0000 it-IT hourly 1 https://wordpress.org/?v=6.1.1 https://www.mokabyte.it/wp-content/uploads/2022/07/cropped-Favicon-32x32.png MokaByte https://www.mokabyte.it/ 32 32 Bitcoin, blockchain e criptovaluta https://www.mokabyte.it/2022/11/11/bitcoinmm-1/ Fri, 11 Nov 2022 17:55:02 +0000 https://www.mokabyte.it/?p=9288 Questo tormentato 2020 sarà ricordato, ovviamente, soprattutto per altre cose. Ma, per la comunità di agilisti e il sempre più grande numero di persone che lavora adottando l’infrastruttura metodologica Scrum, il 2020 vede anche l’uscita di una nuova versione della Guida a Scrum. I giudizi sulle novità sono stati contrastanti: vediamo perché.

L'articolo Bitcoin, blockchain e criptovaluta proviene da MokaByte.

]]>
Introduzione

Negli articoli di questa serie parleremo di Bitcoin, passando in rassegna i diversi aspetti della tematica: la tecnologia blockchain, la criptovaluta bitcoin — scritta, per convenzione, con iniziale minuscola, mentre con l’iniziale maiuscola ci si riferisce alla blockchain di bitcoin o, più in generale, all’ecosistema nel suo complesso — e vari altri temi.

Tuttavia, per capire a un livello più profondo perché sia nato Bitcoin e quale sia il suo scopo, è necessario fare un passo indietro e capire cosa sia il denaro e come questo si sia evoluto nel corso della storia.

 

Che cosa è il denaro

I modi possibili per trasferire valore economico nello spazio e nel tempo sono due:

  • attraverso lo scambio diretto, ovvero attraverso il baratto;
  • attraverso lo scambio indiretto, ossia ricorrendo a dei beni intermedi che consentano di risolvere il problema della doppia coincidenza di bisogni o desideri: ciò che noi vogliamo acquistare è prodotto da chi non è interessato a ciò che noi vogliamo vendere.

La prima modalità, quella più rudimentale, è applicabile in mercati di piccole dimensioni, tribù o villaggi, dove sia presente una forte componente di fiducia tra le parti; l’altra modalità, quella più evoluta, diventa necessaria man mano che la dimensione del mercato cresce e la fiducia reciproca diminuisce.

I limiti del baratto

I principali motivi per cui non è possibile uno scambio diretto su un’economia di larga scala sono tre:

  • assenza della coincidenza di scala, perché si vorrebbero scambiare beni di valore assai differente fra loro;
  • assenza della coincidenza spaziale, perché si vorrebbero scambiare prodotti fra loro distanti nello spazio e/o difficilmente trasportabili;
  • assenza della coincidenza temporale, perché si offre un bene durevole in cambio di uno effimero.

È necessario quindi ricorrere a un mezzo intermedio, ossia un mezzo di scambio (prima proprietà intrinseca del denaro), per risolvere i suddetti problemi.

Le caratteristiche del denaro: scala, spazio, tempo

Nel corso della storia vari beni intermedi sono diventati denaro: persone diverse in luoghi ed ere diverse hanno privilegiato un bene anziché un altro come denaro, ma la scelta che hanno fatto ha determinato delle conseguenze ben precise. Analizzando il passato si può quindi capire meglio quali proprietà dovrebbe avere il mezzo di scambio eletto al rango di denaro affinché sia uno strumento eccellente.

Il denaro deve fondamentalmente possedere queste caratteristiche:

  • essere facilmente divisibile in unità piccole e allo stesso tempo raggruppabile così da cederlo nella quantità desiderata (scala);
  • essere facilmente trasportabile nello spazio, caratteristica che ha portato nel tempo a selezionare mezzi di scambio aventi un alto valore per unità di massa (spazio);
  • mantenere il proprio valore nel tempo (tempo).

Quest’ultima caratteristica è quella più cruciale per il denaro e ha un duplice significato molto sottile, che adesso esporremo. Il mezzo di scambio scelto deve essere durevole nel tempo, ossia non deve corrodersi, deperirsi o distruggersi, affinché le persone possano immagazzinare con il denaro i la propria ricchezza, deve cioè fungere da riserva di valore (seconda proprietà intrinseca del denaro). L’integrità fisica negli anni non è infatti sufficiente per la commerciabilità di un bene nel tempo, questo perché quel bene può perdere valore anche se si conserva perfettamente. Questa perdita di valore avviene se è possibile incrementarne notevolmente la quantità offerta con poco sforzo, perché chiunque avesse questo bene come riserva di valore se la vedrebbe “polverizzare” velocemente (easy money o denaro debole). Il denaro deve essere quindi rigido, o inelastico, ovvero deve essere il più difficile possibile aumentarne la quantità offerta (hard money o denaro forte).

Elasticità e accettabilità del denaro

Se analizziamo tutte le varie forme di denaro primitivo, come le pietre di Rai, le perline colorate dell’Africa, le conchiglie del Nord America o il bestiame e il sale, possiamo vedere che, sebbene non soddisfacessero a pieno la doppia coincidenza dei bisogni o desideri, fintantoché resse la loro commerciabilità nel tempo, grazie ad un elevato grado di inelasticità del mezzo, e si parla di svariati secoli, questi oggetti furono in grado di fungere da denaro e far nascere e sviluppare mercati sempre più strutturati ed efficienti rispetto alle primitive forme di baratto.

Ma non appena un fattore esterno, normalmente di natura umana e legato all’industrializzazione, veniva in contatto con queste civiltà e capiva l’importanza economica di quel mezzo in quel luogo, grazie alle sue capacità produttive riusciva sempre a inflazionare quel bene nel tempo. Questo ha sempre comportato il declino e la morte del mezzo di scambio utilizzato come denaro, unito ad un trasferimento di ricchezza da chi aveva accumulato i suoi risparmi nel tempo in questa forma “antica” a chi arrivava con le nuove tecnologie.

Oltre al grado di elasticità, un altro aspetto importante per la commerciabilità di un mezzo di scambio è il suo grado di accettabilità: più individui lo accettano, più esso risulta liquido e facile da scambiare. Quando diviene così diffuso da essere utilizzato per esprimere il valore di altri beni rispetto ad esso, ecco che si arriva alla terza proprietà intrinseca del denaro, cioè essere unità di conto.

Normalmente il bene intermedio che assolve più fedelmente a questi compiti (mezzo di scambio, riserva di valore e unità di conto) prende il nome di denaro. Lo scopo principale del denaro è quindi quello di trasferire valore economico attraverso lo spazio e il tempo.

 

L’evoluzione del denaro

A mano a mano che che l’umanità si è evoluta, le primordiali forme di denaro sono andate via via scomparendo grazie all’arrivo dei metalli, inizialmente apprezzati per le loro proprietà fisiche e poi per la loro semplicità di utilizzo come unità di conto. Infatti, la loro difficoltà produttiva, scarsità e indistruttibilità li rendevano commerciabili nel tempo, mentre la loro alta densità e l’elevato valore li rendevano commerciabili nello spazio.

Successivamente, grazie agli avanzamenti della metallurgia, questi beni divennero coniabili nelle forme e nelle misure desiderate, e la loro standardizzazione fu accompagnata da un’esplosione di utilizzo come mezzo di scambio, in quanto non era più richiesto di pesare il metallo nelle varie transazioni economiche. I metalli vincitori di questa gara furono quelli che risultarono più rari, scarsi e resistenti; in ordine d’importanza: oro, argento, rame – bronzo (i diversi valori economici li rendevano commerciabili in scala).

I limiti della moneta metallica

Tuttavia, la facile contraffattibilità delle monete (limatura dei bordi o nuclei di materiali non pregiati) e l’iniziale inflazionabilità dei giacimenti minerari di quel periodo (si stava esplorando il mondo anche per la loro ricerca), comportavano ancora un ostacolo alle piene possibilità di questa forma di denaro, perché minavano la fiducia del bene intermedio, facendogli perdere parte della sua commerciabilità.

Banconote e convertibilità in oro

Finalmente, nel XIX secolo nacquero le prime forme di banca, e con esse l’utilizzo di banconote o assegni difficilmente contraffattibili, i quali venivano emessi in cambio del deposito di metalli preziosi presso le tesorerie. Chiunque possedeva uno di questi “pezzi di carta”, poteva recarsi in una qualsiasi banca e riscattare il metallo prezioso associato a tale banconote/assegni. Ciò implicò la caduta del bronzo e dell’argento come mezzi monetari, dato che il problema di scala era stato risolto creando banconote o assegni di tagli diversi; fu adottato quindi l’oro perché aveva la rigidità monetaria più elevata di tutti i beni esistenti.

Nacque così l’era del Gold Standard, ossia la forma di denaro più sana e onesta che si sia vista dalla notte dei tempi, e non a caso durante il suo regno abbiamo osservato periodi di grande progresso economico: era la forma di denaro presente in periodi come la Repubblica Romana, la nascita di Costantinopoli, il Rinascimento e la Belle Époque.

Questo avanzamento così netto nella produzione di beni e servizi, sia in termini di qualità che di quantità, è stato la conseguenza delle basse preferenze temporali che questa forma di denaro ha comportato, ossia l’aumento della fiducia nel risparmio, che ha dato la possibilità di accumulare capitali e investire in ricerca e sviluppo, rispetto al consumo immediato, che consente solo la produzione di cose non destinate al valore durevole.

Saifedean Ammous nel 2019 ha detto: «Sano perché è un prodotto frutto delle scelte volontarie, e non di imposizione coercitiva, quindi un risultato spontaneo del libero mercato. Onesto perché la sua esistenza lega le mani a chi lo guadagna disonestamente sottraendo il valore altrui, vuoi attraverso inflazione monetaria, vuoi attraverso la mano violenta del fisco». [1]

 

Purtroppo, l’oro è riuscito ad affermarsi come standard monetario globale solo nel momento in cui è stato accentrato nelle mani di pochi, inizialmente le banche, facendogli perdere una delle sue migliori caratteristiche, ovvero garantire la sovranità individuale del denaro. Storicamente la Prima guerra mondiale ha posto fine all’era del sistema monetario governato dal libero mercato (potere dal basso, Gold Standard) e ha avviato l’epoca di quello controllato dai governi (potere dall’alto, Fiat Standard), che si è concretizzato definitivamente con l’abolizione della convertibilità dei dollari in oro, ad opera di Richard Nixon il 15 agosto 1971.

Durante tutto questo periodo, sono nate una serie di strutture paragovernative, come le banche centrali e il fondo monetario internazionale, che hanno dato ai governi pieno potere sul denaro portando a uno squilibrio sempre più evidente del sistema; si cerca di gestire, a torto o a ragione, in maniera centralizzata qualcosa che per sua natura è fortemente decentralizzato.

Le garanzie del denario fiat

Il denaro di Stato si chiama fiat, dal latino “sia fatto, creato, istituito”, a indicare in maniera precisa quale sia la sua natura. Esso può essere di due tipologie: garantito da un sottostante fisico (come l’oro) o non garantito.

Nel primo caso il denaro di Stato è equivalente all’oro, perché in ogni momento esso è convertibile nel sottostante utilizzato come riserva di valore; inoltre, è ammesso pagare i propri debiti sia con denaro fiat che con l’oro perché sono considerati equivalenti. L’impossibilità per un qualunque Stato di aumentare a proprio piacere le sue riserve auree, garantisce ai cittadini che quest’ultimo non possa manipolare la quantità emessa di banconote, e quindi di sprecare denaro e/o svilire la moneta, e con essa il potere d’acquisto.

Nell’altro caso, non essendoci un sottostante a garantire il denaro, lo Stato è libero di comportarsi come meglio preferisce; inoltre, in questa situazione generalmente viene imposto il denaro fiat a corso legale, così da promuoverlo sul territorio, facendo diventare tutte le altre forme di pagamento illegali e punibili.

L’affermazione del denaro senza sottostante fisico

Il passaggio da un sistema monetario statale con un sottostante a uno senza (non garantito), è avvenuto in maniera lenta e graduale, motivo per cui le persone si sono “abituate” a questa situazione e oggi rappresenta la normalità, anche se di fatto è un’eccezione nella storia.

Laddove la produzione di capi di bestiame, pietre, oro, etc. richiede comunque un lavoro, ossia uno sforzo fisico, economico e temporale, che di per sé è in grado di limitarne l’offerta, la produzione di valute fiat senza sottostante in qualunque quantità dipende semplicemente dalla volontà di chi governa.

Si capisce quindi, come sia facile ricorrere a questo metodo ogni qualvolta uno Stato si trovi ad affrontare una qualsiasi crisi. L’unico problema nel lungo periodo, è che così facendo viene creato denaro dal nulla (debito), che semplicemente andrà a diluire (inflazione) la ricchezza esistente di chi nel tempo ha risparmiato e investito. I governi hanno quindi la tendenza ad operare con alte preferenze temporali, anche a causa della natura dei loro mandati, condizione che porta nel tempo alla non sostenibilità del sistema e motivo per cui il denaro e lo Stato dovrebbero essere due sfere completamente disgiunte.

Friedrich Hayek nel 1984 diceva: «Non credo che avremo di nuovo un buon sistema monetario finché non ne toglieremo la gestione dalle mani dei governi. Tuttavia non potremo toglierglielo con la violenza, tutto ciò che possiamo fare è trovare una furba via alternativa che ci permetta di introdurre qualcosa che loro non possono fermare». [2]

 

Conclusioni

In questo primo articolo della serie Bitcoin abbiamo spiegato che cos’è il denaro e come questo si sia evoluto nel tempo. Nei prossimi articoli andremo ad analizzare il motivo per il quale è nato Bitcoin e successivamente come esso funziona.

 

Riferimenti

[1] Saifedean Ammous, The Bitcoin Standard. 2019

https://saifedean.com/thebitcoinstandard/.

 

[2] Friedrich Hayek, video intervista del 1984 all’Università di Friburgo

https://www.youtube.com/watch?v=BZ3JWGibgtw

 

 

L'articolo Bitcoin, blockchain e criptovaluta proviene da MokaByte.

]]>
Stili di leadership per l’agilità https://www.mokabyte.it/2022/11/11/leadershipxagilita/ Fri, 11 Nov 2022 17:37:40 +0000 https://www.mokabyte.it/?p=9283 In questo articolo affrontiamo il tema della leadership, con particolare riferimento alle qualità e alle caratteristiche necessarie per svolgere il ruolo di leader in un’organizzazione improntata ai valori, ai principi e alle pratiche agili.

L'articolo Stili di leadership per l’agilità proviene da MokaByte.

]]>
Stili di leadership in epoca moderna

Il tema del modello di leadership migliore per governare efficacemente un’organizzazione si è sviluppato con molta decisione negli ultimi quaranta anni. In realtà l’intero secolo passato ha visto un’evoluzione significativa del ruolo del leader e del suo modo di porsi nei confronti delle persone che a lui sono state affidate. In questo articolo cercheremo di dare una visione prospettica del tema, focalizzandoci in particolare sui modelli che meglio si adattano a realtà produttive che abbiano adottato principi e pratiche agili.

Thinker vs. doer

Allargando ancora di più lo sguardo possiamo dire che in epoca moderna abbiamo assistito e stiamo assistendo a tre fasi significative per quanto attiene i modelli di leadership.

La prima fase è quella che nasce molti secoli addietro e si conclude grosso modo nei primi anni del Novecento. Essa è caratterizzata dall’artigianato, in cui il lavoratore copre l’intero ciclo di produzione o buona parte di esso: l’artigiano pensa e fa.

La seconda fase copre l’intero Novecento e in qualche caso non si è ancora definitivamente conclusa. Questa fase è quella della produzione di beni di massa in grandi quantità e la singola persona coinvolta nella produzione tipicamente fa e non pensa o, perlomeno, non è tenuta a pensare a ciò che sta producendo. C’è infatti qualcun altro che ha pensato per lui alle azioni che devono essere compiute e al modo in cui devono essere eseguite. In questa fase esiste un gruppo ristretto di persone che pensa a come tutte le altre debbano operare: queste ultime si limitano a fare ciò che gli è stato detto, senza che a loro sia richiesto di attivarsi personalmente per cambiare o migliorare il flusso di produzione. L’operaio fa.

La terza fase ha cominciato a svilupparsi negli anni Settanta del secolo scorso e sta vivendo una fase di forte accelerazione proprio negli ultimi anni. Questa terza fase, vede una sorta di “riunificazione” delle attività del pensare e del fare nella singola persona.

Cerchiamo quindi di capire meglio come si connotano la seconda e la terza fase, comprendendo le ragioni che le hanno innescate.

 

Micromanagement e “manager eroe”

Negli anni Venti del secolo passato, a partire dagli Stati Uniti si afferma definitivamente la produzione di massa. Un caso emblematico è quello della Ford e in particolare della produzione del famoso Modello T [1] che fu realizzato in 15 milioni di esemplari, nell’arco di circa 19 anni.

L’organizzazione del lavoro vede l’applicazione delle teorie formulate da Taylor [2] che prendono il nome di “organizzazione scientifica del lavoro”. L’operaio deve svolgere i compiti a lui affidati nel modo più efficiente possibile. Il management decide e organizza tali compiti e l’operaio si limita ad eseguirli.

Un esempio del clima in cui si lavorava in Ford è ben rappresentato da questo esempio: venivano scelti alcuni operai e questi svolgevano una certa operazione sulla linea produttiva; un controllore rilevava i tempi di ciascuno; l’operaio che eseguiva il suo compito nel modo più rapido veniva preso come riferimento e gli altri dovevano fare obbligatoriamente come lui.

Il management dei “tempi moderni”

Charlie Chaplin in “Tempi moderni” ci ha regalato una rappresentazione macchiettistica di quel modo di operare, purtroppo non lontana dalla realtà.

In un tale contesto, il management è costituito da un gruppo relativamente ristretto di persone che decidono ogni cosa. I loro comandi discendono dall’alto verso il basso nella struttura aziendale: i livelli intermedi hanno il compito di attuarli, senza poter esercitare alcuna scelta autonoma; una serie di controllori verifica che tutto avvenga in ossequio alle scelte dei dirigenti.

Questo tipo di management prende il nome di micromanagement, proprio per l’esiguità numerica delle persone che prendono le decisioni.

Nasce in questo contesto la figura del “manager eroe”: colui che sa tutto, che conosce tutto ciò che avviene, che è competente su tutti gli aspetti produttivi ed è responsabile di tutte le scelte a qualsiasi livello e in qualsiasi ambito.

Micromanagement e manager eroe tratteggiano uno scenario che è ben sintetizzato dall’espressione “Command & Control”.

 

Da “complicato” a “complesso”

Il contesto in cui operava l’approccio industriale di Ford era molto particolare. Il suo prodotto aveva un potenziale di vendita molto elevato: gli americani necessitavano dell’auto e potevano permettersela, se il prezzo non era troppo elevato; inoltre non avevano una grande pretesa in termini di qualità e di variabilità, a causa della mancanza di elementi di comparazione; la concorrenza era relativamente ininfluente; le materie prime sostanzialmente illimitate e disponibili a basso prezzo; la manodopera era presente in gran numero e ad un costo bassissimo: si pensi a questo proposito alle decine di migliaia di italiani che in quegli anni attraversavano l’Atlantico alla ricerca di un futuro migliore; Ford sapeva quindi che poteva produrre in quantità il suo prodotto, perché comunque avrebbe venduto le auto senza problemi.

Le cose cambiano…

A proposito della variabilità, Ford era solito dire: “Scegliete il colore che volete, basta che sia nero!”. Ma il quadro generale in cui per decenni si era sviluppato questo modello di organizzazione era destinato a cambiare.

Con riferimento al modello Cynefin di D. Snowden [3], Ford si muoveva nel campo del “complicato”, cioè in un mondo deterministico, in cui capire a quale effetto portava una certa causa richiedeva certamente analisi… ma solo analisi!

A distanza di quasi un secolo il contesto è completamente diverso. Una qualsiasi iniziativa imprenditoriale si muove nel campo del “complesso”. Gli elementi di cui tenere conto sono più numerosi; l’evoluzione delle variabili in gioco è molto più imprevedibile; i rischi sono più elevati; i mutamenti di scenario sono più rapidi e profondi; le competenze delle persone coinvolte sono marcatamente più differenziate e più approfondite; i progetti sono necessariamente multidisciplinari.

 

Valore e persone

Possiamo evidenziare due concetti che segnano la profonda diversità della situazione attuale rispetto al passato: valore e persone.

Il concetto di valore

Il primo concetto da considerare è quello di “valore”. Affinché un’iniziativa imprenditoriale abbia successo, è necessario che apporti al cliente o al fruitore del servizio un valore distinguibile e certo. I valore da trasferire all’utente deve quindi essere identificato e capito. Quindi bisogna intraprendere le azioni utili a creare questo valore. Infine il valore deve raggiungere l’utente e deve essere sostenuto nel tempo. Tutte queste azioni richiedono la presenza di numerose e variegate competenze e conoscenze.

Il valore deve peraltro raggiungere rapidamente il fruitore con lo scopo di ottenere al più presto un feedback che aiuti a comprendere se stiamo operando nella giusta direzione: non si può più pensare di completare l’intero progetto per ottenere un riscontro, poiché le variabili in gioco sono così numerose e cambiano talmente rapidamente che attendere la conclusione del progetto potrebbe far cogliere troppo tardi questi cambiamenti, aumentando drasticamente le probabilità di insuccesso. Diventa dirimente per il successo dell’iniziativa veicolare il valore rapidamente verso il cliente identificando il flusso corretto e virtuoso.

Il sistema delle persone

Per fare ciò serve un “ecosistema” di persone capaci innanzitutto di cogliere i segnali del cambiamento e inoltre capaci di contribuire affinché l’organizzazione si adatti al cambiamento stesso. E questo è il secondo concetto: le “persone”.

È necessario circondarsi di persone pensanti, creando un ambiente aperto all’ascolto in cui i partecipanti possano sentirsi liberi di esprimere le proprie potenzialità, crescere professionalmente, sperimentare la validità delle proprie intuizioni e anche di sbagliare, perché sperimentare vuol dire mettere in conto il fallimento.

Superare i vecchi concetti di leadership

Individuazione e perseguimento del valore e valorizzazione delle professionalità delle persone sono due elementi che scardinano definitivamente i concetti di micromanagement e di manager eroe.

Il micromanagement è superato dalle equipe multidisciplinari in grado di prendere le migliori decisioni ai vari livelli di operatività.

Il manager eroe è superato dai leader in grado di creare le condizioni affinché i singoli collaboratori siano nelle condizioni di dare il massimo contributo.

 

Il leader

Con queste premesse, è lecito porsi alcune domande a riguardo della nuova concezione di leadership:

  • quali sono le caratteristiche peculiari del leader?
  • abbiamo dei modelli che ci guidano nel percorso di crescita del leader?

Rispondiamo a queste domande analizzando in modo sintetico quattro modelli di leadership che la letteratura ci propone. Prima però è necessario sottolineare che, in generale, non si tratta di piani di lavoro o di programmi di crescita, ma solo di riferimenti utili a confrontarsi con sé stessi e con gli altri, una guida che ci aiuta a impostare il nostro modo di proporci verso i collaboratori e ad avere maggiore consapevolezza del nostro ruolo e delle nostre azioni.

Ritorna l’atavica domanda: “Leader si nasce o si diventa?”. E forse la risposta ce la fornisce Manzoni in riferimento a don Abbondio: “Il coraggio, uno non se lo può dare” [4].

Un altro spunto di riflessione, particolarmente significativo in un contesto Agile, riguarda la diffusione della leadership: se definiamo leader chiunque condizioni il lavoro di altri… allora siamo tutti leader.

Ma passiamo ora in rassegna i quattro modelli di leadership a cui si faceva riferimento.

 

Servant Leadership (Robert Greenleaf, 1970)

Robert Greenleaf propone questo modello di leadership [9] unendo due termini opposti e creando una nuova e suggestiva espressione.

Afferma che “il leader è innanzitutto un servo”. Il termine servo è da intendere come l’atteggiamento di chi si mette a disposizione dei suoi collaboratori e delle persone a lui affidate, affinché questi possano dare il meglio di sé; è l’atteggiamento di chi ha compreso che in un contesto complesso il leader non può essere il centro di tutta l’organizzazione, per le ragioni che abbiamo espresso precedentemente.

Il leader è colui che guida altre persone, autonome e specializzate, verso l’obiettivo. Il suo apporto si “limita” quindi a favorire le condizioni affinché gli altri eroghino il massimo del valore.

Servant Leadership in un contesto Agile

In un contesto Agile questa immagine è stata per molto tempo associata allo Scrum Master che è proprio colui che esercitava la Servant Leadership a contatto con i team. Nella Guida Scrum 2020 tale definizione è stata abbandonata. Ma ciò non toglie che lo Scrum Master si adoperi per facilitare il processo Scrum, favorire l’autorganizzazione del team, insegnare le pratiche Agili, aiutare a rimuovere gli impedimenti fino a quando il team non diventa capace di farlo da solo.

In questo senso “si mette al servizio” dei collaboratori. L’atteggiamento del Servant Leader è orientato a incoraggiare la collaborazione, la fiducia, l’ascolto e implica l’uso etico del potere.

Il termine “Servant” ha costituito il successo e anche l’insuccesso di questo stile di leadership, poiché spesso esso viene equivocato e banalizzato.

 

Leadership situazionale (Ken Blanchard e Paul Hersey, 1984)

Blanchard propone uno stile di leadership [8] in cui l’atteggiamento del leader cambia in base alle circostanze, e per questo detto situazionale. Quattro sono gli atteggiamenti suggeriti: dirigere, addestrare, sostenere e delegare.

Il criterio di base utilizzato per stabilire l’atteggiamento da tenere è la maturità del team. Maturità intesa sia in senso strettamente lavorativo e professionale, che in senso psicologico. Nel primo caso si parla di maturità nella capacità tecnica, nella conoscenza e nell’esperienza. Nel secondo caso si parla di disponibilità, motivazione, fiducia in sé stessi e solidità. Il comportamento del leader invece si intende sia nei comportamenti di relazione che nei comportamenti direttivi.

I comportamenti di relazione si manifestano proprio nei rapporti con i membri del gruppo, nella creazione di canali di comunicazione, nell’offrire un sostegno emotivo, nel gratificare e nell’assumere atteggiamenti agevolanti.

I comportamenti direttivi si manifestano invece nell’organizzare i ruoli, nell’individuare le attività da svolgere, nel definire come, cosa, quando.

Il leader di fronte a un gruppo di persone giovani e con poca esperienza, ad esempio, assumerà un atteggiamento direttivo che può sforare anche in un rigido “command & control”.

Invece, all’estremo opposto, un leader che si trovi di fronte a un gruppo professionalmente navigato, capace di prendersi in carico una sfida e di raggiungere il successo, nonostante problemi tecnici e difficoltà di vario tipo, assumerà un atteggiamento di delega, consapevole della capacità dei suoi collaboratori.

L’attività di addestrare è esercitata quando il team è ancora poco maturo ma di fondo c’è la disponibilità ad assumersi una responsabilità. In questo caso il leader avverte l’esigenza di insegnare come muoversi, come organizzarsi, come prevenire e affrontare i problemi.

Sostenere è il tipico atteggiamento da utilizzare di fronte a un team tecnicamente maturo ma senza un’adeguata fiducia nelle proprie possibilità.

 

Host Leadership (Mark McKergow e Helen Bailey, 2013)

Questo stile di leadership [7] è basato sulla metafora del padrone di casa che organizza una cena oppure una festa. Prima dell’evento si impegnerà affinché tutto sia ben preparato e pronto, poi durante l’evento dovrà adoperarsi perché tutto funzioni al meglio.

Da padrone di casa si curerà che le persone si sentano accolte e che stiano bene, agevolerà la conoscenza tra i presenti e non sarà eccessivamente invadente, ma se l’atmosfera si smorza si spenderà in prima persona per rianimarla. Se durante la festa qualcuno esce dai limiti è suo dovere intervenire, impartendo regole e prescrizioni che guidino il comportamento degli invitati.

I sei “ruoli” della host leadership

Gli atteggiamenti o i ruoli che il padrone di casa assume sono sei:

  • iniziatore (initiator), cioè colui che innesca la scintilla ideando l’evento;
  • selezionatore degli invitati (inviter), perché si circonda delle persone adatte per quell’evento;
  • creatore dello spazio (space creator) fisico ed emotivo in cui si svolgerà l’evento;
  • protettore di questo spazio (gatekeeper) rispetto ai disturbi provenienti dall’esterno e dall’interno;
  • connettore (connector) tra gli invitati per agevolare la conoscenza reciproca;
  • e infine partecipante (co-participator), come tutti gli altri.

I quattro “luoghi” dell’azione

I luoghi in cui il padrone di casa assume questi atteggiamenti sono quattro:

  • al centro della scena (on the stage), quando si fa il brindisi oppure quando l’atmosfera deve essere rianimata;
  • tra gli ospiti (among the people);
  • sul terrazzo (on the balcony), dove osserva da lontano ciò che avviene;
  • in cucina (in the kitchen), per rimediare personalmente dietro le quinte a eventuali problemi.

Numerose possibilità

Uscendo dalla metafora, il leader applica i sei atteggiamenti nei quattro luoghi; si crea cioè una matrice di 24 possibilità in cui un certo atteggiamento assume un significato diverso a seconda del luogo in cui viene svolto.

Il leader con questo modello possiede uno strumento per accrescere la consapevolezza dei suoi comportamenti e dispone di un più ampio ventaglio di possibilità e sfumature dell’atteggiamento, che arricchisce il suo bagaglio.

 

Intelligenza emotiva (Daniel Goleman, 1995)

Secondo Goleman, quella emotiva [5] è la parte dell’intelligenza che permette a ciascuno di noi di conoscere prima e di controllare poi le nostre emozioni, di trovare in noi stessi la motivazione che guida il nostro agire, di riconoscere le altrui emozioni e infine di gestire in modo equilibrato le nostre relazioni.

Quello proposto da Goleman è un percorso affascinante e molto utile nel processo di maturazione personale e sociale. Da queste considerazioni nasce il lavoro successivo legato alla leadership [6].

Goleman ci propone sei stili di leadership e anche in questo caso si tratta di atteggiamenti che possono e devono essere applicati in modo diversificato in funzione del contesto contingente in cui ci si trova ad operare.

I sei stili di leadership secondo Goleman

Il primo stile di leader descritto da Goleman è il leader visionario — nel senso che ha una visione d’insieme e di prospettiva, non nel senso che ha le “allucinazioni” — che è in grado di intuire e vedere con più chiarezza l’obiettivo ed è capace di mostrarlo agli altri, guidandoli nella direzione giusta.

Il secondo è il leader affiliativo, che si interessa in senso globale alle persone che collaborano con lui tendendo a diventare loro amico. Questo lo espone con evidenza al rischio che poi alcune sue scelte siano condizionate da questo rapporto di confidenza e amicizia.

Segue quindi il leader democratico, che favorisce lo svilupparsi della partecipazione dell’intero gruppo, agevola la collaborazione e tiene conto di tutte le istanze che emergono dal gruppo. Non sempre questo stile è adatto: se il gruppo è bloccato, diviene necessario fare azioni più direttive per superare l’ostacolo.

Il quarto è il leader coach, che non è propriamente colui che indica una strada, ma che facilita l’emergere delle aspirazioni dei componenti del gruppo facendo domande e prospettando alternative, aiutando il singolo a trovare la propria motivazione e contribuendo a definire una sintesi complessiva, che poi il gruppo stesso implementerà concretamente.

Il quinto è il leader battistrada: nella metafora sportiva è colui che dà il ritmo a tutta la squadra. Secondo Goleman lo stile “battistrada” si applica quando il gruppo è bloccato e richiede più o meno esplicitamente una guida “forte”, capace di farlo uscire dal pantano. È uno stile che dovrebbe essere usato solo in circostanze specifiche e per brevi periodi di tempo.

Analogamente anche il leader autoritario dovrebbe palesarsi di rado, come il “manager eroe” che dall’alto comanda e controlla tutta l’organizzazione, impartendo ordini e attendendo risultati. Questo non è un atteggiamento sbagliato di per sé: in alcuni contesti semplici, in cui è chiaro il risultato da ottenere e il come ottenerlo, la presenza di un’autorità che coordina le attività è sicuramente efficace. Invece è scarsamente efficace in contesti complessi, come abbiamo già avuto modo di sottolineare.

Adattare lo stile al contesto

Tra i sei stili, Goleman identifica i primi quattro come positivi, perché capaci di instaurare un clima collaborativo ed empatico, mentre gli ultimi due, negativi e tendenzialmente da evitare, possono però essere utili in circostanze eccezionali.

 

Conclusioni

I contenuti rilevanti che ho voluto sottolineare in questo articolo sono la necessità di evidenziare il cambiamento in corso, di affrontare la complessità e di mostrare quanto la leadership sia coinvolta in entrambi.

Esistono poi degli strumenti identificabili con gli stili di leadership proposti: l’invito è quello di adottare quello ritenuto più adatto alla propria personalità e al proprio contesto. Bisogna essere consapevoli che, in quanto strumenti, vanno adoperati con attenzione, sostituendoli con altri se si rivelassero inefficaci.

 

Riferimenti

[1] Henry Ford e il Model T

http://www.history.com/topics/henry-ford

 

[2] Frederick W. Taylor, L’organizzazione scientifica del lavoro, ETAS, 1967 (ed. originale The principles of scientific management, 1911)

 

[3] David J. Snowden – Mary E. Boone, A Leader’s Framework for Decision Making,  “Harvard Business Review”, November 2007, pp. 69–76

 

[4] Alessandro Manzoni, I promessi sposi, capitolo XXV

 

[5] Daniel Goleman, Intelligenza emotiva, Rizzoli, 2011

 

[6] Daniel Goleman, Essere leader. Guidare gli altri grazie all’intelligenza emotiva, Rizzoli, 2004

 

[7] Host Leadership

http://hostleadership.com/

 

[8] Ken Blanchard – Paul Hersey, Leadership situazionale: come valutare e migliorare le capacità di gestione e degli uomini, Sperling & Kupfer, 1984

 

[9] Servant Leadership

https://www.greenleaf.org/what-is-servant-leadership/

 

 

 

L'articolo Stili di leadership per l’agilità proviene da MokaByte.

]]>
Effetto Forrester e dinamiche dei sistemi di produzione https://www.mokabyte.it/2022/11/11/effettoforresterspiegato/ Fri, 11 Nov 2022 17:01:36 +0000 https://www.mokabyte.it/?p=9277 C’è una storiella che aiuta a comprendere meglio di tanti studi come funzionano le dinamiche di produzione e vendita nei sistemi complessi. Attraverso la metafora della birra Lover’s, un prodotto di fantasia il cui percorso di produzione, distribuzione e vendita ci aiuterà a comprendere i flussi alla base della Lean Production.

L'articolo Effetto Forrester e dinamiche dei sistemi di produzione proviene da MokaByte.

]]>
Introduzione

In questo articolo ci dedicheremo all’analisi delle dinamiche dei sistemi di produzione complessi e vedremo quali sono gli effetti derivanti da una mancanza di sincronizzazione fra domanda e offerta all’interno de processo di produzione. Le oscillazioni che ne scaturiscono possono portare a una situazione di criticità del sistema, se non addirittura al suo collasso. Il fenomeno alla base di questo esempio è detto Effetto Forrester e ha a che fare, fra le altre cose, con i cosiddetti decisori a razionalità limitata.

Per presentare il problema, useremo una simulazione nata da un’idea formulata negli anni Sessanta del secolo scorso presso la Sloan School of Management del MIT; si tratta di un gioco di ruolo, il Lover’s beer game, in cui gli attori coinvolti devono agire rispettando alcune regole e muovendosi in un ambiente vincolato.

loversbeergame-1fig01
Figura 1 – Il Beer Game è stato giocato in molte sessioni di serious gaming come strumento per comprendere alcuni concetti basilari della produzione snella (lean).

Giocare per comprendere la realtà

Racconteremo qui quello che potrebbe essere il risultato di una tipica sessione di gioco; dalle innumerevoli “partite” giocate in tutti questi anni, nell’ambito dei vari corsi di management e lean manifacturing, è emersa una chiara tendenza: il più delle volte, il risultato finale è stato proprio quello che racconteremo nella storia.

Peter Senge, descrive dettagliatamente questo gioco nel libro La quinta disciplina  e, a tal proposito, ci conferma che il risultato finale non dipende dai singoli giocatori, ma dal modo in cui è configurato il sistema giocatori + ambiente + vincoli: “non sono le scelte delle singole persone o le cause esterne a condizionare il sistema, ma è il sistema stesso”.

Interessante notare che il gioco in realtà ha una corrispondenza forte con la realtà: nella storia recente ci sono stati infatti diversi casi in cui si è potuto assistere a comportamenti sistemici analoghi a quelli descritti in questo articolo.

Si può prendere per esempio il caso della crisi della produzione dei microchip verificatosi nel 1985, in un cui una serie di oscillazioni della domanda/offerta, impattarono sui prezzi e sulla disponibilità dei pezzi, nonché sui ricavi. Una situazione analoga si era verificata un decennio prima nel settore dei semiconduttori, in cui furono coinvolte aziende del calibro di Siemens e Honeywell. Un altro caso lampante fu quello che si ebbe verso la fine degli anni Ottanta nel settore dell’automobile, dove General Motors, Ford e Chrysler furono vittime di una situazione del tutto analoga a quella della Birra Lover’s. Rimandiamo al già citato libro di Senge per approfondimenti su questi specifici argomenti.

Per motivi di spazio, la versione del gioco riportata in questo articolo è necessariamente sintetica . Chi fosse interessato a maggiori dettagli, può senza dubbio far riferimento a La quinta disciplina, libro che è diventato una pietra miliare per la teoria del pensiero sistemico.

 

La birra Lover’s, i tre “attori” e il processo

Questa storia si basa su una fantomatica birra Lover’s, una marca di birra di fantasia, che nella nostra storia risulta piuttosto popolare fra i giovani di una ipotetica regione degli USA. Questa birra è economica e viene consumata con regolarità ma senza raggiungere volumi di vendita delle birre più diffuse. Un bel giorno, però, le vendite aumentano improvvisamente senza un evidente motivo; nel libro si spiega questa variazione come dovuta all’apparizione della birra nel video musicale di un gruppo piuttosto famoso fra i giovanissimi: per questo tutti i ragazzi in grado di comprare alcolici iniziano a comprarla con più frequenza.

Commerciante, grossista, produttore: tre punti di vista

Gli attori coinvolti in questa storia sono, oltre ai clienti finali, un commerciante al dettaglio che vende fra le altre cose la birra Lover’s, un grossista che rifornisce i negozi della zona di alcolici, fra cui anche la suddetta birra e, infine, la fabbrica produttrice della Lover’s.

Per spiegare cosa succede in questa simulazione verranno fornite tre versioni della stessa storia, dal punto di vista del commerciante al dettaglio, del grossista e del produttore. In questa simulazione si immagina che i tre attori non comunichino fra loro per telefono o di persona, ma si limitino a scambiarsi ordinativi e consegne tramite un sistema ormai rodato.

Un altro fattore da tenere presente è che, per motivi legati al processo di produzione e di distribuzione, ogni ordine verrà consegnato dopo 4 settimane: per come è regolato il sistema — un unico fabbricante, un rete di distribuzione limitata e un ampio numero di rivenditori finali — tale delta si propaga su tutti i nodi della rete.

 

Il punto di vista del commerciante

Il commerciante al dettaglio Tom vende nel suo negozio birre di vario tipo; ma in questo gioco concentriamo l’attenzione su un prodotto in particolare: la birra Lover’s, un prodotto non particolarmente conosciuto al grande pubblico, ma apprezzato dai più giovani, probabilmente anche in virtù del prezzo non elevato. Per questo motivo Tom sa che regolarmente, settimana dopo settimana, riesce a vendere 4 casse di questa birra.

Gli ordinativi sono effettuati a inizio settimana e, a causa della regolarità della vendita di questo prodotto, Tom richiede sempre lo stesso quantitativo al grossista inviando un ordine che ormai non ha bisogno di ulteriori spiegazioni.

Ordini e consegne

Per semplificare il ragionamento, immaginiamo che le consegne della merce e gli ordinativi per il futuro avvengano contestualente, nello stesso istante: per esempio, al lunedì, il camion del grossista consegna a Tom le 4 casse di birra, e il commerciante consegna all’autista un foglio su cui è scritto l’ordine successivo.

Tom non conosce quindi il grossista, né tantomeno conosce i dettagli di chi e come produca la birra, fattore che, come potremo vedere fra un po’, si rivelerà fondamentale… in negativo.

Egli sa che ogni ordine verrà effettivamente consegnato dopo 4 settimane, ma non se ne preoccupa, sia per la regolarità con cui riesce a vendere tale birra, sia perché tiene in magazzino una piccola scorta aggiuntiva, in modo che, ad ogni inizio settimana, abbia sempre 12 casse di questo prodotto. Quindi la scorta oscilla fra le 8 e le 12 casse, cosicché egli possa mantenere sempre un certo margine di sicurezza.

Questo accade regolarmente da molto tempo dando luogo a un andamento altalenante ma piuttosto ciclico e in media costante come quello riportato in figura 2.

loversbeergame-1fig02
Figura 2 – Il ciclo di vendita della birra Lover’s, misurato al punto vendita al dettaglio, segue un andamento molto regolare; il negoziante, ordinando sempre lo stesso quantitativo di birra, è in grado di asaudire le richieste di tutti i suoi clienti e al contempo di mantenere stabili le scorte di magazzino.

L’andamento delle vendite e dei rifornimenti, settimana dopo settimana

Prendendo in esame una settimana qualsiasi di questo periodo in cui il comportamento è stabile, la possiamo convenzionalmente chiamare settimana n. 1: tanto è il rifornimento quante sono le vendite.

Poi improvvisamente, le cose cambiano: senza un motivo apparente, al termine di una settimana, che chiameremo la settimana n. 2, le vendite aumentano raddoppiando da 4 casse a 8 casse. Il venditore non se ne preoccupa più di tanto, visto che la variazione, pur sostanziosa in percentuale, è comunque un evento isolato… o almeno così crede: forse è stato più caldo del solito oppure forse qualcuno ha dato una festa. Inoltre le scorte che Tom ha in magazzino (8 casse oltre alle 4 che oscillano in entrata e uscita) possono garantire di assorbire questo “sbalzo”.

Ciò nonostante, si prepara ad aumentare l’ordinativo il lunedì successivo — quello che dà inizio alla settimana n. 3 — in modo da pareggiare l’aumento delle vendite riportando il magazzino a 12 casse. Purtroppo all’inizio della settimana n. 3 il rifornimento che arriva è di sole 4 casse: non dimentichiamo infatti che ogni consegna si riferisce all’ordine fatto 4 settimane prima.

Pertanto, complessivamente, il magazzino è sceso da 12 a 8 casse. Se la variazione nelle vendite è frutto di un caso isolato — qualche festa in più, il caldo dell’estate o chissà cos’altro — Tom sa che nell’arco di 4 settimane il suo magazzino tornerà ad avere una scorta di 12 casse: in fondo, la scorta serviva proprio per assorbire eventuali oscillazioni. Per il momento Tom quindi non si preoccupa particolarmente e continua a comportarsi in maniera razionale sulla base della propria esperienza.

Cambiamenti decisivi

Durante la settimana n. 3, il commerciante comprende che quanto visto non era affatto un caso isolato, ma che anzi le vendite continuano su un ritmo di 8 casse a settimana. Essendoci in magazzino solamente 8 casse, al termine della terza settimana il negoziante si trova senza birra.

Alla consegna del lunedì della settimana n. 4, riceverà solamente 4 casse di birra: l’ordinativo maggiorato è stato fatto solamente alla settimana n. 3 per cui le 8 casse arriveranno alla settimana n.7. Ricordiamo infatti che ogni ordine viene evaso quattro settimane dopo essere stato consegnato.

Deve quindi risolvere rapidamente il problema e sa che probabilmente a metà settimana si troverà senza birra, andando quindi in debito di merce; per esempio potrebbe segnarsi il nome dei clienti e richiamare quando la merce sarà nuovamente disponibile.

Per questo, nemmeno le 8 casse ordinate la settimana precedente possono bastare: adesso non solo deve pareggiare lo svuotamento del magazzino ma anche fronteggiare il “debito” che si creerà fra pochi giorni. Per questo, decide di agire di anticipo e aumenta l’ordinativo a 12 casse.

Proseguendo questo trend, settimana dopo settimana Tom si trova ad aumentare sempre più il proprio ordinativo fino alla settimana 7: adesso il trend delle consegne dovrebbe invertirsi, dato che all’inizio di settimana n. 7 dovrebbe finalmente arrivare la prima consegna maggiorata (8 casse).

Scarsità di merce

In realtà, al lunedì di settimana n. 7, il grossista consegna solo 5 casse rispetto alle 8 ordinate. E nelle settimane successive le cose non cambiano; anzi addirittura peggiorano. Completamente in balia di fattori indipendenti dalla sua volontà, il negoziante non può far altro che arrendersi all’evidenza dei fatti.

Non riuscirà a soddisfare le richieste dei propri clienti, senza conoscere il motivo della crescita della domanda né il motivo della scarsità delle consegne. Il problema principale è che la mancanza di birra Lover’s ha rallentato la vendita di merce di contorno normalmente acquistata dai clienti che comprano la Lover’s: infatti chi andava nel negozio acquistava generi alimentari generici oltre alla birra.

loversbeergame-1fig03
Figura 3 – In questo grafico è riportato l’andamento delle vendite al negozio: l’alterazione nella domanda consuma in breve tempo le scorte del negozio e obbliga il negoziante a impegnarsi con i clienti più affenzionati a consegnare la birra non appena questa arriverà in negozio. Per questo il grafico scende sotto il livello dello zero.

 

Il punto di vista del grossista

Susan è la responsabile degli ordini e delle vendite di un grossista di zona: nel suo ruolo, Susan è testimone di un andamento analogo a quello che ha sperimentato il negoziante, anche se ovviamente con volumi certamente maggiori e su un altro tipo di scala: Susan è il riferimento per il rifornimento di molti negozi della sua zona, piccoli supermercati o genericamente intere zone molto ampie ma a bassa densità di popolazione.

Se un negoziante ragiona per le consegne in termini di casse di birra, l’unità di misura di Susan sono i bancali che sono movimentati tramite camion verso i vari negozianti della zona coperta dalla propria zona. Come il negoziante finale, anche Susan ha un tempo di attesa di 4 settimane per ricevere la birra che ordina alla fabbrica.

L’andamento delle vendite del grossista

Anche Susan quindi ha riscontrato un aumento delle vendite alla settimana n. 4. A dire il vero aveva avuto una piccola oscillazione alla settimana n. 3, ma anche nel suo caso aveva ipotizzato si trattasse di una variazione più o meno casuale.

Il grossista, per la sua posizione all’interno della rete di vendita, di fatto concentra e somma l’andamento delle vendite dei negozianti che dipendono da lui. Per questo l’oscillazione che Susan nota alla terza settimana è quasi impercettibile, mentre quella della quarta è sostanziale e maggiore di qualche ordine di grandezza.

Il grossista, non appena si rende conto che il nuovo trend non è una semplice oscillazione, interviene modificando gli ordini: anche in questo caso interviene prima con un semplice incremento poi con maggiorazioni più sostanziose.

Susan pensa che se la variazione delle vendite non sarà troppo repentina, le scorte di magazzino potrebbero essere sufficienti per assorbire l’aumento delle richieste in attesa che la fabbrica consegni gli ordinativi aumentati, vale a dire dopo dopo 4 settimane.

Scorte di magazzino insufficienti

Purtroppo per Susan, il nuovo picco di domanda da parte dei commercianti al dettaglio non si arresta, ma anzi aumenta man mano che passa il tempo. Se inizialmente la variazione poteva essere assorbita con le scorte di magazzino o comunque ridistribuendo le consegne ai vari negozianti, dopo qualche tempo arrivano alla dimensione di criticità massima.

Susan, con qualche settimana di ritardo rispetto al negoziante, sperimenta la sua criticità: non appena si rende conto che le nuove richieste stanno erodendo le scorte, reagisce prima razionalmente, aumentando quel tanto per colmare lo svuotamento del buffer ma, successivamente, trovandosi in difficoltà, prova forzare la mano con la fabbrica aumentando in maniera “forte” gli ordinativi alla fabbrica.

Anche il grossista quindi inizia ad assumere un atteggiamento emotivo, guidato dall’ansia di non riuscire a evadere tutti gli ordini: i commercianti continuano a chiedere sempre più birra e il grossista non ne ha. Come avremo modo di vedere, la fabbrica aumenterà la produzione fra qualche settimana e i risultati si vedranno solo fra qualche tempo. Nel frattempo che fare?

 

Arrivano i nostri…

Verso la settimana n. 16, la fabbrica, che aveva deciso di potenziare le proprie strutture e di produrre più birra, inizia a rispondere all’aumento degli ordinativi consegnando più merce di prima, riuscendo in questo modo a coprire quasi tutti gli ordini fatti dai grossisti 4 settimane prima.

Susan inizia a essere fiduciosa: la merce appena ricevuta non è ancora sufficiente a coprire il debito di consegne, ma è rassicurata dall’inversione di tendenza da parte della fabbrica e si attende quindi che le prossime consegne potranno colmare tale carenza. I suoi ordinativi infatti sono aumentati in maniera esponenziale.

Inversione di tendenza

Contemporaneamente, dal canale di vendita si nota una leggera flessione negli ordinativi. Susan non se ne cura, pensa che molto probabilmente i negozianti, che avevano più o meno seguito lo stesso trend negli ordinativi, e avevano ecceduto un po’ nella settimana precedente, adesso rallentano un po’.

In questa fase, con il produttore che inizia ad aumentare la produzione e il magazzino che finalmente inizia a riempirsi nuovamente, il rallentamento degli ordinativi da parte dei negozianti è visto come un fatto positivo. In fondo Susan ha ancora un debito considerevole con i negozianti.

Nelle settimane successive le consegne da parte della fabbrica iniziano ad essere regolari e rispettare quanto richiesto al momento dell’ordine quattro settimane prima, quando Susan aveva aumentato gli ordinativi del doppio o del triplo rispetto alla media storica.

Ora che le cose iniziano a mettersi al meglio, accade una cosa impensabile fino a poco prima: purtroppo, gli ordinativi da parte dei commercianti si bloccano del tutto. Nessun venditore finale sembra aver più bisogno di birra Lover’s!

Lo stato delle cose

La cosa drammatica è che, nelle settimane seguenti, le consegne da parte del produttore, sempre in accordo con quanto richiesto 4 settimane prima, aumentano esponenzialmente. Adesso stanno consegnando 10 se non 20 volte rispetto alla media storica. La merce si accumula nel magazzino mentre i negozianti continuano a non ordinare nulla.

Susan si rende conto che, con il trend attuale, se anche i negozianti dovessero riprendere a ordinare birra Lover’s, per poter smaltire tutta quella merce che si sta accumulando sui bancali in magazzino ci vorrà molto tempo. Probabilmente non ci riuscirà e probabilmente è a rischio la sopravvivenza della sua azienda.

Il tutto senza che il grossista abbia compreso il reale motivo di quanto accaduto. Ad oggi non ha ancora avuto modo di parlare né con qualcuno dei commercianti né con un rappresentante della fabbrica della Lover’s Beer; è stata sempre troppo occupata a gestire gli sbalzi nella lavorazione. La sola cosa che può fare per le prossime settimane è bloccare completamente ogni ordinativo per l’acquisto di altra birra.

 

Il punto di vista del produttore

Presso la fabbrica di produzione della birra Lover’s, l’andamento delle vendite segue un comportamento molto simile a quello che abbiamo visto presso il grossista e i singoli rivenditori finali, anche se ovviamente con volumi notevolmente maggiori.

Dopo una piccola variazione alle prime settimane, le vendite hanno registrato un sensibile aumento, con un trend quasi esponenziale che in poco tempo ha messo in difficoltà il reparto produttivo che non è riuscito a rimanere in pari con le sempre maggiori richieste. Analogamente, anche in questo caso, dopo questo picco di ordinativi, le richieste hanno subito un brusco rallentamento, per arrivare alla totale interruzione di ogni forma di ordinativo.

Le variazioni negli ordinativi

Il primo aumento negli ordinativi per i volumi della fabbrica non viene realmente percepito come variazione della domanda, ma come una perturbazione circoscritta. Anche in questo caso i responsabili alle vendite e alla produzione non hanno preso alcuna iniziativa, immaginando che l’alterazione potesse tranquillamente essere assorbita con le scorte di magazzino che sono sempre disponibili presso la fabbrica.

Quando successivamente si è visto che il trend degli ordinativi rimaneva in costante crescita, i responsabili delle vendite hanno compreso che non si trattava di una variazione isolata, ma di qualcosa di più strutturato.

In quell’istante si è provato a tamponare con un intervento sulle modalità di consegna, cercando di ottimizzare le poche scorte di merce disponibile, per esempio provando a soddisfare i distributori più importanti o mandando solo parte della merce ordinata. Contemporaneamente i responsabili della produzione si sono attivati per intervenire strutturalmente: prima assumendo nuovi dipendenti, poi provvedendo a potenziare i macchinari per realizzare volumi maggiori di birra.

Purtroppo, prima che le nuove attrezzatura potessero entrare in funzione e potessero consentire un sostanziale incremento della produzione, gli ordinativi si sono interrotti di colpo. Tutto a un tratto nessuno voleva più birra.

Cosa era successo? Oltre al rammarico di non essere riusciti a soddisfare una notevole quantità di richieste (mancati profitti) la fabbrica si ritrova adesso con dei costi strutturali notevolmente aumentati (nuovi assunti e attrezzature da pagare). Per la fabbrica, se gli ordinativi non fossero tornati ai volumi registrati prima dell’interruzione, tutto ciò avrebbe potuto significare un grosso problema.

 

Il punto di vista del responsabile del marketing e vendite della fabbrica

Nel libro di Senge, il racconto prosegue con l’aggiunta di una appendice in cui si narra del punto di vista di Marc, il responsabile del marketing e delle vendite della fabbrica. Marc è stato assunto di recente all’interno della azienda con lo scopo di far crescere le vendite e si ritrova a vivere in pieno tutta l’oscillazione: da un incremento incontrollato al successivo crollo.

Quando Marc vede che la birra inizia ad accumularsi nel magazzino, nel tentare di comprenderne le cause e trovare un rimedio, intraprende un viaggio — purtroppo ormai inutile — presso la rete di vendita andando a parlare con Susan, la responsabile di uno dei grossisti che distribuisce la birra Lover’s. La conversazione che si instaura mette in evidenza in modo piuttosto chiaro alcune possibile cause di quanto è successo.

Il confronto tra fabbrica e grossisti

Susan accoglie Marc, mostrando le scorte all’interno del proprio magazzino, scorte che si sono accumulate non appena dalla fabbrica hanno iniziato a consegnare gli ordinativi maggiorati. Marc frustrato e arrabbiato si interroga a voce alta su come tutto questo sia stato possibile…

Susan, cercando si immaginare quanto tempo ci vorrà per smaltire tutte quelle scorte, condivide la frustrazione e la rabbia di Marc. Entrambi sono frastornati e preoccupati della situazione.

Marc esordisce: “È una tragedia… ma come è potuto succedere?”.

Susan, dimostrando anche in questo caso una visione locale, perché non pensa di avere alcuna responsabilità, molto semplicemente ribatte: “Non è colpa nostra; sicuramente i commercianti al dettaglio non si sono saputi organizzare o forse non sanno gestire il mercato”.

Marc nella sua testa dà la colpa ai rivenditori, accomunando, in preda a un momento emozionale, commercianti al dettaglio e grossisti; certamente quanto accaduto è l’ennesima dimostrazione della variabilità del mercato e dell’incostanza dei consumatori. I due si congedano senza avere alcuna risposta per risolvere il problema, ma promettendo di risentirsi nei giorni successivi per provare a condividere qualche strategia.

Il confronto tra frabbrica e commercianti al dettaglio

Nel viaggio di rientro verso il suo ufficio, incidentalmente Marc si trova a passare davanti a un negozio che vende, fra le altre cose, la Birra Lover’s. Per la prima volta da quando lavora alla Lover’s, entra nel negozio di un commerciante al dettaglio per parlare con il titolare, Andrew.

Dopo le presentazioni di rito, Andrew porta Marc nel retro del proprio negozio per mostrare le giacenze di magazzino e anche in questo caso la scena, con le dovute proporzioni, è simile: il retro del negozio è pieno di casse di birra Lover’s. Con il trend di vendita attuale, per vendere tutte quelle casse di birra ci vorranno molte settimane. Marc rimane pietrificato: se tutti i negozianti della zona e delle aree vicine sono nella medesima situazione, la fabbrica corre grossi rischi per la propria sopravvivenza, perché non dovrà produrre più nulla per mesi.

Marc chiede i motivi di questo stallo improvviso; il commerciante serenamente risponde: “Non saprei, non è colpa nostra. Dopo che è uscito quel video musicale in cui appariva la Lover’s, abbiamo avuto un incremento nelle richieste dai nostri clienti; da 4 casse di media, siamo passati a 8 nel giro di una settimana…”

Marc interrompe: “Va bene. Prima le vendite sono esplose… Ma come mai poi sono crollate?”

Steven ribatte: “No, attenzione! Le vendite non sono né esplose né crollate; noi adesso continuiamo a vendere 8 casse di birra a settimana rispetto alle 4 iniziali. Ma il problema è che voi non ci stavate mandando la birra che ci serviva e stavamo accumulando ritardi e per mantenere i nostri clienti abbiamo dovuto aumentare gli ordinativi”.

Marc: “Ma noi abbiamo consegnato gli ordinativi non appena ci è stato possibile!”

Andrew: “Non so che dire… Forse il grossista ha fatto casino, tant’è che vorremmo cambiarlo. Di fatto abbiamo ricevuto la birra con ritardo, addirittura in un certo momento, nonostante noi aumentassimo le richieste, le consegne arrivavano incomplete, in misura molto minore rispetto all’ordine. Quando poi finalmente avete iniziato a consegnare la merce, ci avete mandato prima la giusta quantità, poi molto più del necessario. A quel punto abbiamo dovuto interrompere gli ordini”.

 

Alcune considerazioni

Anche se la storia nel libro di Senge prosegue ancora, noi ci interrompiamo in questo punto, dato che le cose viste mettono in evidenza già alcuni fattori molto interessanti. Questa storiella ha, ovviamente, tutti i limiti di una storia “didattica” e con scopi esemplificativi. Ma ha anche il merito di mettere in luce chiaramente un meccanismo che sembra semplice ma ha in sé numerosi aspetti di complessità.

Infatti, per quanto possa apparire difficile che la storia sia andata esattamente in questo modo, le numerose sessioni di gioco simulativo tenute nei corsi di management portano a esiti proprio molto simili a quelli appena visti nel racconto.

Dove sta il problema?

A una analisi distaccata della storia appare piuttosto chiaro dove sia il problema; ma perché è accaduto? Perché ogni attore della filiera ha commesso un errore così banale non tenendo in considerazione la tempistica di consegna e non ha saputo valutare gli aspetti logistici e le conseguenze delle proprie azioni?

Al fine di procedere ad una corretta analisi dello scenario appena visto è forse utile analizzare la storia sia da un punto di vista sistemico, come fa Senge nel suo libro, sia da un punto di vista organizzativo e di processo, ossia applicando le considerazioni fatte nelle precedenti puntate della serie, quando abbiamo parlato di Value Stream e di Cycle Time.

Vediamo queste riflessioni nei paragrafi seguenti.

 

Considerazioni sistemiche

Perter Senge fornisce tre massime che emergono dalla storia appena raccontata:

  • la struttura influenza il comportamento;
  • la struttura dei sistemi umani è “sottile”;
  • la soluzione può arrivare da nuovi modi di pensare.

La struttura influenza il comportamento

Studi e analisi in svariati settori hanno dimostrato che differenti persone hanno prodotto risultati simili se messe a lavorare nello stesso contesto o in contesti simili.

Quando ci sono cali di performance o problemi di una qualche natura, la prima tendenza è quella di cercare qualcuno o qualcosa su cui far ricadere la responsabilità. Ma, nella maggior parte dei casi, quando agiamo all’interno di un qualche sistema non ci rendiamo conto che le cause dei risultati che si ottengono sono da ricercarsi nel sistema stesso, non in fattori esterni o in errori dei singoli.

La struttura dei sistemi umani è “sottile”

Siamo portati a pensare al concetto di struttura come un insieme di vincoli che agiscono sugli individui. Ma la struttura nei sistemi complessi può essere definita sulla base delle sofisticate interrelazioni che si creano al suo interno e che ne regolano il comportamento finale.

In una azienda, come nell’esempio della Birra Lover’s, il risultato del sistema di vendita, dal consumatore al produttore, è dato dalla complessità risultante dalle azioni e decisioni dei vari attori che si muovono all’interno del sistema. Nessuno di questi può pilotare il sistema, ma eventualmente influenzarne il comportamento che sarà comunque il risultato dell’azione di tutti.

La soluzione può arrivare da nuovi modi di pensare

Quando ci troviamo ad agire per affrontare dei problemi all’interno di organizzazioni complesse, pur avendo le risorse e le capacità per risolvere determinare situazioni, non le esercitiamo perché troppo presi dal focalizzare la nostra attenzione sulle nostre decisioni, senza renderci conto che le nostre azioni interferiscono con quelle degli altri.

Nella storia della birra Lover’s, i singoli attori osservano e si concentrano solo sul proprio operato cercando una soluzione che riduca la variazione nel proprio ambito, senza invece considerare l’intero sistema in cui tutti agiscono e si influenzano.

Le valutazioni sistemiche proposte da Peter Senge sono fondamentali per provare a interpretare il comportamento degli attori nella simulazione della Lover’s Beer.

 

La storia fin qui

È arrivato il momento di provare a comprendere come sia possibile spiegare quanto successo nella storiella della Birra Lover’s grazie agli strumenti tipici dell’agilità, applicando concetti visti in precedenza: Lean Production, Cycle Time, Kanban, metriche e altro ancora.

Introduciamo a questo punto l’effetto Forrester (o “effetto frusta” o bullwhip effect)  causato fra le altre cose dai cosiddetti decisori a razionalità limitata e dalla mancanza di alcuni requisiti che sono ritenuti essenziali all’interno di un progetto agile.

Ma prima, ricapitoliamo brevemente la sequenza di eventi che si sono susseguiti:

Una piccola oscillazione nella domanda da parte dei consumatori finali viene prima sottovalutata dalla rete di vendita, poi presa in seria considerazione dal negoziante, che prima sopperisce con le scorte di magazzino, poi provvede ad aumentare gli ordinativi al grossista.

Le consegne avvengono con 4 settimane di “ritardo” dalla effettiva creazione dell’ordine: per 4 settimane quindi il negoziante non riceve alcun incremento della merce consegnata.

Il negoziante, prima gestisce la cosa in modo razionale, ma quando le scorte non bastano più, e non è in grado di soddisfare la sua clientela più affezionata, inizia a reagire in maniera impulsiva aumentando gli ordinativi in misura maggiore di quello realmente necessario: si confonde l’aumento della richiesta settimanale, con le richieste passate non soddisfatte, come se tutti i clienti che non hanno comprato nei giorni in cui la birra non era disponibile, si ripromettessero poi di comprare anche gli “arretrati.

Questo andamento si verifica con lo stesso andamento presso gli altri nodi della filiera (distribuzione e produzione), cosa che porta al blocco delle consegne: la fabbrica non era pronta all’aumento improvviso delle richieste.

Non essendo disponibile prodotto già presso la fabbrica, i venditori finali dopo le 4 settimane canoniche cominciano a ricevere addirittura meno scorte di quelle ordinate. A questo, reagiscono in modo ancora più irrazionale aumentando le richieste.

Finalmente il processo si sblocca, perché la fabbrica si attrezza per moltiplicare la sua capacità produttiva. Ma a questo punto, le richieste da parte di venditori finali e distribuzione si bloccheranno, perché entrambi si son visti recapitare un quantitativo di merce enormemente maggiore rispetto alle necessità.

Ancora una volta è necessario sottolineare che la variazione della domanda finale era minima e che nessun cliente probabilmente avrebbe comprato tutta la birra che non era stato in grado di acquistare nelle settimane precedenti.

Il processo quindi si traduce in una specie di onda fra domanda e offerta, che ha messo in difficoltà tutti i nodi della filiera: il negoziante prima non ha saputo soddisfare la richiesta dei clienti; poi si è ritrovato nel magazzino una eccedenza di birra che per essere smaltita avrebbe richiesto molte settimane; il distributore ha subito una sorte analoga e quindi, come il negoziante, ha interrotto gli ordinativi quando si è trovato nel magazzino bancali pieni di birra.

In fabbrica inizialmente non sono stati in grado di evadere l’incremento degli ordinativi ma non hanno subito alcun danno economico diretto, se non mancanza di un ricavo concreto; poi, quando hanno fatto gli investimenti necessari per incrementare la produzione, hanno subìto l’arresto della domanda, con conseguente impossibilità di ripagare gli investimenti fatti, oltre anche in questo caso ai magazzini pieni.

In questo articolo, vediamo di dare una spiegazione formale a quanto accaduto per comprendere le cause ed evitare che ciò accada anche, per esempio, all’interno di una piccola azienda che produce software.

 

Effetto Forrester

Da un punto di vista teorico, il comportamento del sistema preso in esame e le conseguenze delle azioni intraprese dai vari attori, sono spiegabili mediante il cosiddetto Effetto Forrester, detto anche effetto frusta o Bullwhip. Tale fenomeno si verifica, in determinate condizioni, in una catena di produzione, con una oscillazione della domanda e dell’offerta tramite la formazione di una specie di onda che, proprio come la corda di una frusta, si propaga amplificandosi man mano che ci si allontana dal mercato finale e si risale la catena di produzione. È tipicamente applicabile ai sistemi di supply/chain ma, come vedremo, lo possiamo vedere in azione anche all’interno di un sistema IT come quello della “fabbrica” del software.

 

Figura 1 – L’effetto Forrester o effetto “frusta”.
Figura 4 – L’effetto Forrester o effetto “frusta”.

 

Cause principali dell’effetto “frusta”

Molteplici sono le cause che danno luogo alla serie di fenomeni descritti nell’esempio della birra. Da un lato si può certamente indicare nella presenza di attori che prendono decisioni sulla base di informazioni circoscritte al loro ambito di intervento e che, per questo, vengono chiamati decisori a “razionalità limitata” di cui parleremo più avanti.

Non avendo informazioni dalla periferia rispetto al loro contesto d’azione, o comunque non avendo sotto controllo tutto il sistema nel suo complesso, maggiore è la lunghezza della catena di produzione, maggiore sarà l’inefficienza del sistema complessivo; più precisamente tanto più ci si allontana dal cliente finale — o più genericamente dal punto di chiusura del processo, ossia del controllo — maggiore è l’inesattezza delle informazioni e la grossolanità delle azioni intraprese. Per questo si parla di onda, oscillazione o genericamente di effetto frusta (figura 4).

Filiera lunga

In agilità, quando si deve sviluppare un prodotto software, o genericamente un prodotto IT, la lunghezza, o meglio la cortezza, della filiera di produzione è un aspetto preso in seria considerazione, visto che è noto a cosa possa portare una catena lunga.

In Scrum per esempio si cerca di ridurre il numero di intermediari organizzando team in cui tutti gli attori si parlano, collaborano e decidono. Per questo si cerca di eliminare prima di tutto gli intermediari, di mettere in comunicazione direttamente il team con il cliente/utente e il team con il management.

È per questo per esempio che un Product Owner che faccia da intermediario fra il cliente e il team di sviluppo è un cattivo PO, o almeno un PO che incorre nel rischio di allungare la catena. È per questo per esempio che in Kanban, dopo una prima fase di mapping del processo, si prova ad accorciare il processo, per esempio abilitando la cross-capacità delle persone, o facendo in modo che il gruppo si autoorganizzi per compiere quelle operazioni impegnative magari in gruppi senza chiedere il contributo di attori esterni.

Tempi di lavorazione

Altro fattore che impatta negativamente e che si somma alla lunghezza della catena è il tempo di lavorazione del prodotto: come abbiamo avuto modo di vedere in modo estremamente dettagliato nella serie di articoli precedenti di questa serie in cui abbiamo parlato di Kanban, il tempo di lavorazione, o Lead Time, impatta sulle prestazioni.

In questo caso, è causa — o effetto, dipende dai punti di vista — delle decisioni prese da un lato o dall’altro della catena: se il negoziante avesse potuto avere la sua birra in tempi più rapidi, avrebbe potuto prendere le proprie decisioni in maniera più coerente con la realtà delle cose. Analogamente, se la fabbrica avesse evaso gli ordini in tempi minori, avrebbe potuto recepire i segnali dal mercato in modo più realistico e magari prendere le adeguate contromisure per tempo.

Latenza

Lunghezza della catena ed elevato Lead Time sono due fattori ci portano a considerare i problemi visti con un altro aspetto, quello della latenza nella risposta del sistema alle sollecitazioni esterne.

Questo fenomeno si può spiegare con un paio di esempi piuttosto semplici: uno che probabilmente molti lettori possono aver sperimentato direttamente; l’altro solo se si è partecipato a un corso per imparare a pilotare un aereo.

Il primo è quello che si prova quando per esempio si prova a guidare una bicicletta o una motocicletta con il tubo canotto dello sterzo che non si muove con la dovuta libertà (serraggio troppo alto o qualche cuscinetto bloccato): in questo caso il manubrio risponde in maniera dura o addirittura a scatti. Per guidare una bici normalmente si apportano delle piccole e costanti correzioni alla traiettoria per rimanere in equilibrio. In questo caso la bici non sterza ed è necessario applicare una forza maggiore, che di fatto porta la bicicletta a sbilanciarsi nella direzione opposta, richiedendo una correzione maggiore e più repentina nell’altra direzione. In questo caso, spesso il ciclista inizia con delle piccole oscillazioni per finire con degli ondeggiamenti più ampi, che portano a volte a cadere.

Un effetto simile capita a chi pilota un aereo: per correggere l’assetto egli tira la cloche per alzare il muso. Ma l’effetto della azione non è immediato, per cui il pilota inesperto tira la cloche più del dovuto; dopo poco il muso dell’aereo si alza più di quanto necessario, e per questo il pilota da una correzioni vistosa verso il basso. Ma siccome anche in questo caso l’effetto non è immediato, il pilota alle prime armi comincia ad avere un po’ di ansia… e abbassa troppo. Quando il muso si abbassa, allora tira di nuovo la cloche… e la tira troppo.

Di fatto in quel caso il tipo di risposta del sistema non può essere modificata, per cui pare che nell’addestramento i piloti vengano addestrati ad evitare questo loop pernicioso, portando piccole modifiche e riportando sempre la cloche in assetto.

Il tema della latenza nella risposta è uno degli aspetti più importanti su cui si fonda buona parte della filosofia agile: seguire iterazioni brevi in Scrum, organizzare frequenti incontri con il cliente/utente per fare delle demo, raccogliere il maggior numero di feedback possibili sono tutte azioni che vanno nella direzione di aumentare la reattività del sistema, ossia intraprendere decisioni i cui effetti siano verificabili prima possibile.

 

Cause dirette secondarie dell’effetto “frusta”

Operare sui tre fattori appena visti (accorciare la filiera, ridurre il lead time, aumentare la reattività) è sicuramente un modo già molto efficace per migliorare il sistema e ridurre gli effetti negativi della frusta. Esistono poi anche alcuni altri fattori secondari che possono essere causa di effetto Forrester. Li vediamo di seguito, tenendo presente che in genere sono sintomi che esprimono un’elevata oscillazione della tendenza domanda/offerta.

Da notare che non è necessario che queste cause si manifestino tutte contemporaneamente per poter affermare che il sistema è sotto l’effetto Forrester.

Eccessivo livello di scorte

Un eccessivo livello di scorte, soprattutto a monte della catena per evitare rotture di stock, ossia premunirsi dal trovarsi senza scorte. In Agile vuol dire avere nel backlog abbastanza cose pronte da fare (raffinate nel senso di refinement), ma non troppe. In kanban, se ci sono troppe card nella colonna ToDo, il rischio per esempio potrebbe essere quello di non riuscire a evadere delle richieste di assistenza, se stiamo gestendo un help desk o ufficio operation, con la consegneza che gli utenti finali potrebbero nuovamente telefonare per effettuare nuovamente la segnalazione, creando un loop vizioso (ricordiamoci l’esempio del pilota inesperto…).

Inefficacia delle previsioni di vendita

L’inefficacia frequente o costante delle previsioni di vendita è un altro esempio. In agilità questo aspetto è stato abbondantemente affrontato: fare previsioni è molto difficile, se non impossibile, per cui si preferisce fare delle sperimentazioni in un ambito protetto e con un coefficiente di rischio ridotto al minimo.

Sbalzi della capacità produttiva

Sbalzi nella richiesta di capacità produttiva, che risulta a volte insufficiente e a volte eccessiva). Per questo motivo si cerca di tenere il più stabile possibile il contesto di lavoro: limitare il turn over, stabilizzare il processo di alimentazione del backlog, coinvolgere il più possibile e con la maggior frequenza possibile gli utilizzatori in modo da raccogliere feedback e nuove richieste di da implementare. Maggiore è la cadenza con cui raccogliere tali feedback (tante piccole gocce), minore saranno gli sbalzi (aggiunta o rimozione di grosse fette di backlog).

Cambiamenti ai piani di produzione

Frequenti cambiamenti ai piani di produzione non aiutano a prevenire l’effetto frusta. In un progetto software, il piano di produzione potrebbe essere qualcosa che ricade nel contesto Product Ownership o, più in alto, parte della vision. In agile il cambiamento è benvenuto e per questo le metodologie come Scrum o Kanban riescono a reagire prontamente a eventuali variazioni. È noto però che un cambiamento “forte” ha implicazioni non banali sul processo di produzione. Per esempio è probabile che la velocity cambi, o che il trend delle cose da fare, ossia il Burn Down di Scrum, subisca una radicale perturbazione.

 

Cause indirette

Oltre alle cause viste fino a questo punto, ci sono alcuni aspetti che forse è più corretto chiamare effetti ma che condizionano il sistema stesso dando luogo a un qualcosa che rientra nella teoria dei system dynamics, circuiti caratterizzati da ciclicità e feedback rientrante.

Comportamenti irrazionali

In determinati momenti, gli attori del sistema mettono in atto comportamenti irrazionali, frutto dell’emotività, o che possono apparirlo a posteri, come nel caso dei decisori con razionalità limitata.

Si opera in un contesto a razionalità limitata durante il processo decisionale quando la razionalità di un individuo è limitata dalle informazioni che possiede, dai limiti cognitivi della sua mente, e dall’ammontare finito di tempo che egli ha a disposizione per prendere una decisione.

Svariati modelli economici danno per scontato che le persone abbiano una razionalità media, e possano in quantità sufficientemente grandi essere approssimati come agenti in accordo alle loro preferenze. Il concetto di razionalità limitata rivede questo assunto per tenere conto del fatto che decisioni perfettamente razionali spesso non sono realizzabili nella pratica, proprio a causa della quantità finita di risorse computazionali disponibili per prenderle.

Mancanza di coordinamento

Spesso manca un coordinamento nelle decisioni dei singoli membri della catena di produzione. Anche in questo caso la mancanza di coordinamento è spesso legata ad una razionalità limitata dei decisori, i quali sono quindi portati ad assumere un comportamento localmente opportunistico: ogni decisore pensa prima di tutto a ottimizzare il proprio limitato ambito operativo. In questo caso, poiché i decisori mancano delle capacità e delle risorse per arrivare alla soluzione ottimale, essi applicano invece la loro razionalità solo dopo aver enormemente semplificato le scelte disponibili. In pratica, il decisore cerca una soluzione soddisfacente piuttosto che la migliore in assoluto.

 

Conclusione

L’effetto Forrester impatta sul processo di produzione e vendita di un bene, cosa che nel campo IT potrebbe essere la messa in produzione o il rilascio di un determinato componente o prodotto software.

La tipica conseguenza in una catena di produzione e vendita è che tutti gli attori nel mezzo della catena sono portati a un più o meno cosciente aumento delle scorte di sicurezza: si cerca di evitare la rottura di stock. La formica che accumula scorte per l’inverno, infatti, non ha problemi di obsolescenza del prodotto, cambio di requisiti (mangia sempre le stesse cose) o richieste particolari.

In un progetto software, il magazzino in genere è rappresentato da tutto il software che non è ancora stato rilasciato e che rimane in attesa di essere quindi verificato e provato sul campo. Per questo, in un progetto agile si cerca di minimizzare questa forma di magazzino, proprio per limitare l’accumulo di parti di prodotto non testate e non provate sul campo.

In un progetto software gli accumuli di magazzino non sono né un obiettivo rincorso, né una forma di protezione (irrazionale) ma casomai manifestazione di scarsa organizzazione o mancanza di strumenti: per esempio non si fa continuous integration.

Si è visto con l’esempio della produzione della birra che a un certo momento il sistema nel suo complesso ha iniziato a funzionare in modo non ottimale, cosa resa evidente da ritardo nelle consegne ad ogni livello della organizzazione. Questo effetto si può avere anche in una organizzazione che produce software. Si pensi per esempio a un sistema di gestione dei bug di produzione gestito tramite Kanban. In questo caso la variabilità può essere molto alta e, contrariamente a quanto possano dire gli analisti di mercato che si lanciano in rocambolesche previsioni, molto poco prevedibile.

Questo è un tipico caso in cui ciclo di lavorazione lungo, scarsa visione di insieme, ottimizzazioni localizzate, scarso coinvolgimento del cliente finale possono amplificare l’onda dell’effetto frusta, dando come risultato più evidente un ritardo nella lavorazione dei ticket.

 

L'articolo Effetto Forrester e dinamiche dei sistemi di produzione proviene da MokaByte.

]]>
Fare “il tagliando” a Scrum https://www.mokabyte.it/2022/11/11/tagliandoscrum22/ Fri, 11 Nov 2022 16:47:54 +0000 https://www.mokabyte.it/?p=9269 Questo tormentato 2020 sarà ricordato, ovviamente, soprattutto per altre cose. Ma, per la comunità di agilisti e il sempre più grande numero di persone che lavora adottando l’infrastruttura metodologica Scrum, il 2020 vede anche l’uscita di una nuova versione della Guida a Scrum. I giudizi sulle novità sono stati contrastanti: vediamo perché.

L'articolo Fare “il tagliando” a Scrum proviene da MokaByte.

]]>
Retrospettiva

Partiamo dalle parole dei principi sottostanti al Manifesto Agile [1]

A intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza.

Nell’ambito delle pratiche agili, questo principio è alla base della Sprint Retrospective come previsto dalle meccaniche Scrum e del concetto di retrospettiva agile in senso più ampio e generale.

Fedeli più allo spirito che alla lettera di quanto enunciato, abbiamo pensato che potesse essere il caso di “fare un tagliando” a Scrum, esattamente a due anni dalla pubblicazione dell’ultima versione della Guida Scrum [2], avvenuta proprio nel novembre del 2020.

Cambia tutto o non cambia niente?

Su queste pagine già era stata affrontata a suo tempo la questione [3] rilevando come in occasione dell’uscita della Guida Scrum versione 2020 ci fossero state reazioni contrastanti, che oscillavano tra chi affermava che nulla cambiasse, tranne qualche denominazione, e chi invece si era convinto che nelle poche pagine della Guida ci fossero invece stavolta dei cambiamenti anche sostanziali, seppur “mitigati” dalla stringatezza dello stile tipico della Guida.

A distanza di tempo, “facendo il tagliando” dopo due anni, credo si possano scrivere alcune considerazioni basate non solo sull’impressione del momento, ma anche su quanto è accaduto nella realtà della pratica di Scrum. Come detto nell’articolo citato [3], infatti: “Nella realtà aziendale, Scrum non è mai la pedissequa applicazione meccanica di quanto scritto nella Scrum Guide. La quale […]  non ‘esaurisce’ Scrum in tutte le sue sfaccettature. […] Chi ‘fa Scrum’ nella realtà aziendale sa bene che, pur senza tradire affatto lo spirito (e la lettera) della Scrum Guide, in quel documento poi non ci sono scritte le tante competenze, le tante pratiche e strumenti, le tante esperienze che sono tutte necessarie per ‘far funzionare’ Scrum sul campo”.

Pertanto, i cambiamenti da verificare non sono tanto quelli riportati nel testo, ma soprattutto nella effettiva applicazione delle “regole del gioco” sul campo.

Figura 1 – Il riassunto visuale dell’infrastruttura metodologica Scrum nell’interpretazione di Amazing Outcomes.
Figura 1 – Il riassunto visuale dell’infrastruttura metodologica Scrum nell’interpretazione di Amazing Outcomes.

 

I cambiamenti ufficiali

Facciamo un breve riassunto schematico di alcune delle modifiche più significative apparse nella Guida Scrum ultima versione.

Ampliamento degli orizzonti di applicazione

Che si intenda spingere Scrum verso un’adozione da parte di realtà produttive non strettamente software è indicato fin dalle prime pagine della guida dove viene data notevole importanza ai valori di Scrum, citando peraltro esplicitamente la teoria Lean.

Mai come prima, inoltre, vengono ricordati e “inquadrati” gli stakeholder a rendere ancora più esplicita la realtà produttiva ampia verso cui si orienta adesso Scrum. Sempre meno “meccanica di base”, sempre più infrastruttura adatta a un ampio spettro di produdizioni nell’ambito dell’economia della “conoscenza”. C’è un certo svincolamento dal solo sviluppo software, tendenza peraltro già in atto da anni.

Svincolamento dallo sviluppo software

Conseguentemente a quanto scritto sopra, laddove nelle precedenti versioni della Guida Scrum si parlava sostanzialmente di Scrum come di un’infrastruttura metodologica per sviluppare software, adesso si parla di lightweight framework capace di supportare nella generazione di valore attraverso soluzioni adattative per problemi complessi.

Chiaro che questo riguardi ogni tipo di produzione immateriale — e, perché no, anche materiale in certi casi — e non solo lo sviluppo del software. Identica impressione si ricava dal fatto che, a parte la parola “developers”, non c’è più una terminologia strettamente legata al mondo informatico.

Relazione stretta tra Artifacts e Goals

Altro cambiamento che in molti hanno notato, e che in diversi hanno però trascurato, è stata l’istituzione di una relazione “schematica” tra i diversi Artifacts e un corrispettivo obiettivo (goal). In tal senso

  • il Product Backlog prevede come impegno il Product Goal (concetto di nuova introduzione);
  • lo Sprint Backlog prevede come impegno lo Sprint Goal;
  • lo Increment prevede come impegno la Definition of Done.

Questo aspetto, che a molti è apparso esclusivamente teorico, ha in realtà avuto il merito di contribuire a definire meglio la stessa Definition of Done, specificandone l’ambito di applicazione precipuo, e di costruire una simmetria tra artifact e goal.

Ulteriori precisazioni sui “ruoli” dello Scrum Team

Una delle aree in cui le cose, almeno in teoria, sono cambiate più evidentemente è quella dello Scrum Team e dei “ruoli” che, tanto per cominciare, non si chiamano più così ma accountabilities cioè “responsabilità” il che non è solo un cambiamento di denominazione, ma un modo per specificare che chi svolge quel ruolo si assume anche le responsabilità ad esso connesso.

Viene poi specificato che l’intero Scrum Team è composto da 10 persone o meno.

In terzo luogo, dal momento che lo Scrum Team non prevede sottogruppi o “divisioni” o “compartimenti” — e questo è sempre stato specificato anche in passato — si sceglie, molto correttamente di ridefinire come Developers, cioè semplicemente “sviluppatori” quello che un tempo era il DevTeam. Non è nulla di più che una modifica “cosmetica” ma, d’altro canto, se non ci devono essere team secondari dentro il team principale non si capiva perché ci fosse un team di sviluppatori…

Quanto alle singole “responsabilità”, lo Scrum Master non viene più definito come servant leader, definizione che per molti anni ha rappresentato un po’ lo standard degli stili di leadership, nonostante altri approcci fossero possibili e ben documentati. Per il Product Owner viene enfatizzato il compito di rendere sempre ben presente il Product Goal a tutte le parti in gioco, senza ovviamente perdere di vista la cura del Product Backlog. Quanto ai Developers, oltre al già citato e corretto cambio di nome, si specifica che l’incremento completato a ogni Sprint deve essere di valore, utile e usabile: qualcosa di ovvio e già assodato per molte realtà, ma non ancora così esplicitamente enunciato.

Collaborazione e autogestione

Altro aspetto, forse più di facciata che non sostanziale, è quello rappresentato dal fatto che non si parla più di feedback — la parola è assente dal documento — mentre si insiste sul concetto di collaborazione.

Inoltre, al posto di parlare di un team autoorganizzato, si parla di uno Scrum Team self-managing cioè “autogestito”, vale a dire che chi fa cosa, quando e come viene deciso dai suoi componenti all’interno del gruppo.

Figura 2 – Il riassunto visuale dell’infrastruttura metodologica Scrum nell’interpretazione di The Liberators.
Figura 2 – Il riassunto visuale dell’infrastruttura metodologica Scrum nell’interpretazione di The Liberators.

 

Ciò che resta invariato

Ma, se in un contesto quacosa cambia, significa anche che qualcosa resta invariato. E forse su questo aspetto non ci si è concentrati abbastanza.

Da un lato ci sono degli aspetti che restano invariati anche ufficialmente, dall’altro ci sono degli elementi che non sono cambiati nella pratica, e il significato di questo secondo aspetto sarà specificato meglio più avanti. Guardiamo alcuni elementi invariati.

“Architettura”, regole e applicazioni di Scrum

È chiaro che certi concetti fondamentali non possono cambiare, altrimenti non saremmo più davanti a Scrum ma a qualcosa di diverso. Scrum resta un framework metodologico basato su un approccio iterativo e incrementale, declinato in maniera empirica, sulla base dei principi di ispezione, adattamento e trasparenza: e ci mancherebbe che questo cambiasse. Scrum, come descritto nella Scrum Guide, resta anche molto “scheletrico” nel senso che l’infrastruttura è decritta pienamente nei suoi elementi costituenti e nelle sue meccaniche di base, ma molti altri aspetti — ad esempio l’uso o meno di certi strumenti per la visualizzazione del processo, o le tecniche specifiche per condurre le retrospettive e così via — vengono lasciati alla libera iniziativa di chi adotta Scrum.

A fronte di questa “libertà”, resta tassativo l’invito a non adottare Scrum in maniera parziale prendendo solo qualche evento, magari modificandone la durata prescritta, o cambiando le attività delle diverse accountabilities oppure rinunciando a certi artifact. Nel caso lo si facesse, non si starebbero seguendo le “regole del gioco” e non si potrebbe dire di stare facendo effettivamente Scrum. Quindi, va bene un limitato livello di “personalizzazione”, laddove la Guida non specifichi l’argomento. Ma guai a “tradire” l’architettura ideale di Scrum o a eliminare elementi previsti, perché questo porterebbe a una metodologia che non è Scrum e che potenzialmente può rivelarsi inefficace.

Su questo aspetto — che forse è il più importante ed è quello su cui si può ragionare “a bocce ferme” due anni dopo l’uscita della Guida — torneremo nelle conclusioni.

Persone

Per quanto il framework Scrum sia importante, e sia adesso ancor meglio specificato, la sua applicazione vive e fiorisce nella concreta implementazione che ne faranno le persone. Se chi vuole applicare Scrum non sposa i valori e principi enunciati nella Guida, non ha una approfondita conoscenza delle meccaniche di base e non si assume le responsabilità insite nel suo ruolo… Scrum non funzionerà perché non si tratta di una formula magica o di un evento miracoloso.

Per quanto possa risultare scontato, questa è una verità invariata ormai da almeno un paio di decenni

Scrum Team e Accountabilities

Abbiamo già parlato delle novità e di come alcuni dettagli siano stati meglio speficicati, sia in termini formali che sostanziali. Tuttavia, alcuni dei cambiamenti sono stati fatti proprio per ribadire meglio, ad esempio, quel che si è sempre detto, ossia che nello Scrum Team non ci sono sottogruppi, non c’è una gerarchia, e che i suoi componenti hanno competenze cross-functional.

E non cambiano caratteristiche e compiti fondamentali del Product Owner, a partire dal fatto che resta una singola persona — non un comitato —  ed è responsabile della massimizzazione del valore del prodotto. Nonostante i cambiamenti alla tipologia di leadership in cui lo si inquadra, non cambia per lo Scrum Master la responsabilità di rimuovere gli impedimenti, tanto facile da enunciare, molto più complessa da mettere in pratica.

Eventi

Altro aspetto fondamentale di Scrum, che probabilmente non cambierà mai, è il fatto che gli eventi sono time-boxed, ossia limitati a una precisa durata temporale, e collocati in una ben definita scansione cronologica.

E non cambia il fatto che gli eventi contenuti nello Sprint (Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective) restano eventi collaborativi. Se così non fosse, non sarebbe Scrum.

Artifacts

Come visto sopra, si è ben specificata la corrispondenza tra artifact e rispettivo goal, ma questo non ha mutato certe caratteristiche dei singoli “manufatti”. Il Product Backlog resta — e resterà — la fonte delle attività che vengono intraprese nel corso dei vari Sprint. E ci fermiamo qui per non ripetere l’ovvio.

 

Conclusioni

Conclusioni non significa che l’articolo è finito. O meglio sì, ma non avrebbe senso non trarre delle conclusioni e sollevare anche degli interrogativi.

Passando dalla teoria alla pratica, quel che si è potuto notare è che in certi casi molte delle novità introdotte due anni fa sono passate abbastanza inosservate: si vede ancora, in certi casi, introdurre Scrum nei gruppi di lavoro con la terminologia e l’approccio precedenti al 2020, quando non succede ancora di peggio.

Da un lato questo è comprensibile: alla fine ciò che conta trasmettere sono certi meccanismi di base e se parliamo ancora di Dev Team invece che di Developers, poco cambia. Così come se si ricorre ancora alla metafora del servant leader per lo Scrum Master. E va anche detto che chi veramente applica Scrum in azienda, deve necessariamente andare oltre la Guida Scrum, apportare quelle “personalizzazioni” — non tagli o stravolgimenti — che proprio l’ufficialità delle “regole del gioco” consente e favorisce. Quindi è probabile che in pochi si limitino ad applicare Scrum solo come descritto nella Guida, dove ad esempio non si parla assolutamente di come fare uno Sprint Planning nel concreto, con le varie tecniche di stima per “pesare” le storie, né tantomeno si suggerisce l’adozione di una lavagna in stile Kanban per gestire il flusso di lavoro durante lo Sprint.

Ma da un altro lato, chi ha il compito di formare le organizzazioni e le persone al framework Scrum non dovrebbe mancare di cogliere, dopo due anni, il fatto che alcune sottili differenze introdotte dalla versione 2020 della Guida Scrum non sono solo dettagli “nominali”. Sono infatti, per ora, il punto di arrivo di un lungo processo cominciato embrionalmente circa trent’anni fa, e che va trovando la precisazione della sua definizione in modo empirico.

Scrum non ha più quell’alone di rivoluzionaria novità che poteva avere nelle sue implementazioni iniziali, quando era materia per pochi sviluppatori software particolarmente aperti alle novità “ideologiche” e alla ricerca di un modo più efficace per lavorare. Scrum è diventato “industria” nel senso che ormai viene adottato nei processi di produzione più disparati. E questi cambiamenti, compresa la necessità di precisare quanto poteva lasciare adito a interpretazioni fuorvianti, o di schematizzare — pure troppo — certi elementi in maniera che sia più facile la loro comprensione e la loro messa in pratica, fanno parte del processo.

Non sappiamo quando la nuova versione della Guida verrà pubblicata, né quali eventuali modifiche saranno apportate. Quel che ci auguriamo è che valori, principi, struttura e meccaniche di Scrum vengano aggiornate sempre partendo dall’esperienza di chi applica questo framework medologico nella realtà della produzione.

 

Riferimenti

[1] Manifesto per lo Sviluppo Agile di Software
https://agilemanifesto.org/iso/it/principles.html

 

[2] Scrum Guide

https://scrumguides.org/scrum-guide.html

 

[3] Francesco Saliola, La nuova Guida Scrum. Niente di nuovo o cambiamento sostanziale? MokaByte 267, dicembre 2020

https://www.mokabyte.it/2020/12/16/scrumguide2020/

 

 

L'articolo Fare “il tagliando” a Scrum proviene da MokaByte.

]]>
Veicoli elettrici ed esperienza utente https://www.mokabyte.it/2022/10/17/uxecar-2/ Mon, 17 Oct 2022 06:31:12 +0000 https://www.mokabyte.it/?p=9059 La mappa non è il territorio La volta scorsa ci eravamo lasciati iniziando a parlare di quanto siano importanti, nell’esperienza utente globale di chi usa un veicolo elettrico, i servizi di pianificazione itinerario e ricarica. Sono in genere disponibili come siti web e app mobili.   Questi servizi consentono in genere di progettare meticolosamente il… Continua a leggere Veicoli elettrici ed esperienza utente

L'articolo Veicoli elettrici ed esperienza utente proviene da MokaByte.

]]>
La mappa non è il territorio

La volta scorsa ci eravamo lasciati iniziando a parlare di quanto siano importanti, nell’esperienza utente globale di chi usa un veicolo elettrico, i servizi di pianificazione itinerario e ricarica. Sono in genere disponibili come siti web e app mobili.

Figura 1 – L’interfaccia di A Better RoutePlanner (ABRP) con la mappa e i criteri di pianificazione.
Figura 1 – L’interfaccia di A Better RoutePlanner (ABRP) con la mappa e i criteri di pianificazione.

 

Questi servizi consentono in genere di progettare meticolosamente il viaggio, ma non mancano malfunzionamenti e blocchi, e la UX è in molti casi decisamente migliorabile.

Normalmente un’autovettura — elettrica o tradizionale— fornisce al guidatore l’indicazione della quantità di energia rimanente (litri di benzina o livello della batteria) e del numero di km che si possono compiere con tale energia.

Se per le auto a benzina o Diesel questi numeri sono “abbastanza affidabili” — e comunque, nel caso, c’è sempre un distributore dietro l’angolo—, con un’elettrica le cose sono meno attendibili o prevedibili.

L’autonomia di percorrenza è calcolata sulla base del consumo istantaneo frutto di differenti fattori: velocità, pendenza del terreno, sistema di condizionamento aria dell’abitacolo e altro ancora. Questi fattori ci sono anche con un’auto tradizionale, ma son molto meno influenti sul computo complessivo.

Ho sperimentato quanto possa essere rischioso sottovalutare questo aspetto, specialmente con un’auto con un alto consumo kW/km.

L’episodio rivelatore

Il viaggio fatto per recarci nel luogo di vacanza era stato progettato con 2-3 tappe per ricaricare la batteria: in autostrada, nell’unica stazione che abbiamo incontrato nel tragitto, e subito fuori dal casello.

L’ultima tappa pianifica con ABRP [1] era quella che ci portava da Brescia a Livigno, percorso di circa 180 km con un dislivello medio positivo: una lunga salita con qualche tratto di discesa nel mezzo. Nella figura 2 è riportata l’altimetria del percorso.

Figura 2 – Altimetria del percorso.
Figura 2 – Altimetria del percorso.

 

Appena uscito dall’autostrada ho fatto l’ultima ricarica convinto di poter arrivare tranquillamente a destinazione: la batteria al 100 % garantiva circa 310 km nominali, autonomia nettamente superiore alla reale distanza. La pianificazione fatta con ABRP confermava i miei calcoli.

Peccato che quei 180 km siano in costante salita e che, specialmente nell’ultimo tratto, il consumo medio sia salito in modo considerevole, ben oltre la media dell’auto (pari a circa 26 kW / 100 km).

Che avrei avuto difficoltà ad arrivare a destinazione l’ho purtroppo realizzato quando oramai non avevo modo di ricaricare l’auto: se inizialmente il gap distanza-autonomia era di oltre 150 km, quando mancavano pochi km alla vetta, vicino alla dogana, il cruscotto mi segnalava 10 km di autonomia con soli 5 km prima dello scollinamento. Per fortuna sono riuscito a valicare il passo e nella discesa finale ho avuto modo di ricaricare l’auto, arrivando a Livigno con ben 60 km di autonomia. Primo momento di stress passato.

 

Il territorio non è la mappa

Dopo aver sudato freddo durante la salita finale, abbiamo depositato i bagagli in appartamento; a quel punto sono andato a rifornire di elettroni la mia auto. ABPR mi diceva che in paese erano presenti molte colonnine. Mi sono mosso fiducioso che ne avrei trovata almeno una.

Purtroppo quello che la app non mi aveva detto è che una buona parte delle colonnine erano localizzate in ZTL — quindi per i residenti elettrici? — oppure che si tratta di quelle private appartenenti ad alcuni alberghi, i quali pubblicano sulle mappe ABPR la presenza della colonnina e sistemi analoghi per attrarre clienti. Inoltre quelle raggiungibili (della rete Repower) in tutto il paese non stavano funzionando, non ho capito se per colpa della app di attivazione/pagamento o per disservizio sulla rete.

Se la prima crisi sulla montagna è stata superata allegramente — in auto ironizzavamo sull’impossibilità di rimanere completamente bloccati in mezzo al nulla — in questo caso ho iniziato a manifestare sintomi di un lieve attacco di panico, complice stanchezza per 7 ore di viaggio e la sveglia alle 4 per la tanto famosa partenza intelligente.

La vista appannata per la stanchezza creava visioni della mia auto bloccata sulla rotonda più trafficata di Livigno con orde di poliziotti intenti a sbeffeggiarmi per la mia insolente scelta di usare l’auto elettrica per le montagne della Valtellina. Già stava iniziando a mancarmi il ronzio della mia bellissima astronave elettronica: vi ho già detto che amo il suono delle Toyota elettriche?

Solo grazie alle indicazioni di un turista svizzero ho scoperto che poco fuori porta era disponibile una stazione fast recharge che ho poi utilizzato durante tutta la permanenza in paese: si è rivelata molto comoda perché posta di fronte a un ristorante e a un piccolo supermercato (vedi scenario 2 nel precedente articolo). In soli 40’ ho reimmesso abbastanza energia per muovermi almeno 3 giorni in paese. La colonna di ricarica è installata dentro una stazione di benzina, ed è stato quindi naturale fare amicizia col benzinaio e scambiare ogni volta quattro parole: devo dire che le sue reazioni quando ho raccontato come si vive con un’auto elettrica sono sempre state molto divertenti. La frase che ha vinto il primo premio è stata “Ma quindi dentro non c’è benzina?”. Penso volesse chiedermi se fosse un’auto ibrida, almeno ibrida.

 

I limiti delle app

In questo periodo di prova, ho trovato l’ecosistema digitale — le varie app e servizi web — scadente e non di livello per il tipo di prodotto e di servizio richiesto. Le app, quasi tutte, non hanno dati salvati in locale (p.e. mappa o elenco delle colonnine) per cui, ad ogni click, zoom, modifica, i dati devono essere ricaricati, con errori di buffer e ricarica. Spesso questo comporta tempi di attesa, blocchi (mappa vuota), dati non attendibili, impossibilità di pagare/attivare la colonnina.

Alcuni “bug” sono particolarmente scomodi: nel sottosuolo del parcheggio, la mancanza di segnale 4G manda in blocco app XWay con logout e perdita di dati. Con il tempo si imparano a gestire queste stranezze, ma è singolare che in un contesto con un così elevato livello di tecnologia, sia la componente digitale l’anello debole del sistema.

Sebbene verso la fine del mese le cose siano leggermente migliorate, considero comunque questo ambito totalmente insoddisfacente.

 

Quindi, in definitiva?

Al termine di questa lunga esperienza in cui ho vissuto la vita di tutti i giorni, e addirittura il viaggio delle vacanze, con un’auto elettrica, la domanda che mi sento fare più spesso è se io ne sia rimasto contento e se sia un’ esperienza da consigliare.

Rispondere a questa domanda non è semplice: spero che questo articolo possa aiutarvi in parte. Ma vediamo di fare ordine

Il prodotto auto elettrica

Mi ha conquistato totalmente. Ne sono affascinato e ho amato ogni aspetto della guida. Ho provato in questo mese anche una Tesla, che ovviamente, mi ha fatto innamorare ancor di più. Guidare un’auto elettrica è un’esperienza magnifica, facile, rilassante ed estremamente coinvolgente.

Numero e distribuzione delle colonnine

Al momento il numero è sufficiente per ricaricare senza troppi problemi, ma occorre pianificazione. Ad oggi del tutto insufficiente la copertura in autostrada, ma le cose pare stiano cambiando rapidamente [2]. Immagino però che anche un piccolo incremento delle auto vendute potrebbe mettere in crisi la rete attuale. Vedo che le cose si stanno muovendo in meglio; sono ottimista.

Tempo di ricarica

Legato al numero di colonnine c’è quello dei tempi di ricarica. Se la tecnologia delle auto dovesse evolversi rapidamente per raggiungere gli standard di Tesla, portando il tempo per una ricarica nell’ordine dei 5-10 minuti, allora anche il punto precedente potrebbe essere un non problema. Per quello che possiamo capire per come si sta muovendo il mercato, resta comunque il tema dei costi: più la ricarica è rapida, più costa.

Standard disponibili

Ad oggi esistono diversi standard di ricarica sia per quello che concerne la connessioni (tipo di spina) che di fornitura. Sul primo aspetto, non ho avuto alcun problema: ho usato il connettore CCS2 (fast) e il Type2 (quick charge). Il primo in genere consente ricariche fino a 100 kW mentre il secondo tipicamente viene “tagliato” intorno ai 10-20 kW. Ovviamente dipende poi dalla capacità dell’auto di assorbire tutta questa energia. Per esempio i 100 kW della CCS2 non sono digerebili da tutte: non ho dati attendibili ma ho notato che il mio ProAce accettava qualcosa meno. Nota di colore: spostare un pesantissimo cavo al cui interno scorrono 100 kW fa un certo effetto; mi perdoni il mio prof. dell’Università: sappiamo che i kW non scorrono come i combustibili tradizionali… ma l’iperbole rende l’idea.

Costi

Ho passato tutto il mese a fare conti e comparazioni. Ad oggi, se si ricarica velocemente, i costi sono di poco inferiori ai motori termici; da considerare però che un’auto elettrica costa molto di più e il mercato dei produttori non sembra al momento interessato a spingere su prodotti di fascia bassa; è un meccanismo piuttosto tipico ogni volta che c’è una nuova tecnologia.

Da quello che ho visto (prezzi agosto 2022 in piena crisi energetica) ricariche super-rapide stanno sui 0,6-0,7 € / kWh, costo non concorrenziale rispetto alla benzina. L’energia elettrica inizia ad essere interessante sotto gli 0,4 € / kWh. Ci sono abbonamenti “flat” molto vantaggiosi con cui si arriva agli 0,2 € al kiloWattora. Tipicamente il contratto casalingo si aggira sui 0,3 € / kWh che è comunque un buon prezzo. Se poi avete pannelli fotovoltaici installati sul tetto… la cosa diventa ancora più interessante.

Consumo dell’auto

La grandezza da tenere sotto controllo sono i kWh consumati per 100 km. Ho guardato e riguardato i numeri della mia esperienza estiva, per giungere alla stessa conclusione che gira in rete: per essere concorrenziale, un’auto elettrica deve stare sotto i 20 kWh / 100 km; per capirsi, Tesla sta fra i 16 e i 18.

Si deve guardare poi il valore medio e confrontarlo con il comportamento in situazioni reali: per esempio vedere cosa succede se si accende aria condizionata, si superano i 120 km/h o si viaggia in salita. Con l’auto a mia disposizione questi fattori ambientali hanno influito molto, come ricordato nell’episodio della salita verso Livigno raccontato poco sopra. Un viaggio in autostrada con un’auto elettrica tipicamente viene fatto a 110 km/h: per questo spesso vedrete delle Tesla in terza corsia a destra procedere “lentamente” anche se sono in grado di correre oltre i 200 km/h.

 

Conclusioni

Pur dicendo di essere convinti di voler passare all’elettrico, molti automobilisti vedono necessario ancora un periodo di 2-3 anni per avere un mercato maturo e stabile fatto non solo da veicoli ulteriormente migliorati, ma anche di tutti i necessari prodotti accessori, la rete di colonnine, i servizi digitali.

Personalmente, però, e con mia grossa sorpresa, in alcuni casi si può già vivere la mobilità elettrica con successo.

 

Riferimenti

[1] ABRP, A Better Route Planner

https://abetterrouteplanner.com/

 

[2] Robin Grant, Colonnine Free To X: come funziona la ricarica in autostrada. Quotidiano Motori, 23/07/2022

https://www.quotidianomotori.com/automobili/automobili-elettriche/colonnine-free-to-x

 

 

 

L'articolo Veicoli elettrici ed esperienza utente proviene da MokaByte.

]]>
OKR, cadenze in Kanban e Flight Levels https://www.mokabyte.it/2022/10/17/flightlevels/ Mon, 17 Oct 2022 05:59:41 +0000 https://www.mokabyte.it/?p=9056 I dati prodotti sul Web sono aumentati in maniera incredibile, specie negli ultimissimi anni. Spropositate quantità di dati rappresentano una potenziale fonte di informazioni utili per le aziende e per gli utenti. Ma come è possibile estrarre valore da questa massa caotica e informe? È in atto un cambiamento di paradigma da Big Data a Fast Data.

L'articolo OKR, cadenze in Kanban e Flight Levels proviene da MokaByte.

]]>
Superare l’ottimizzazione locale

Che si tratti di Scrum o Kanban, ci si rende rapidamente conto che lavorare a livello di un solo team è esempio di ottimizzazione locale: presto o tardi emergeranno innumerevoli frustrazioni legate a cosa succede “fuori dal team”.

Questo articolo non copre aspetti avanzati di Kanban e OKR, ma vuole illustrare un possibile approccio integrato di diverse pratiche, affrontando anche l’argomento “obiettivi”.

Di obiettivi se ne parla sempre poco, sia in Scrum che con Kanban, dove si tende a focalizzarsi troppo sull’output: velocity e numero di funzionalità prodotte da una parte, lead time e throughput dall’altra.

 

OKR: Tutti nel parlano, nessuno li sta davvero utilizzando

OKR significa “Objective and Key Results”: è un framework per creare allineamento sugli obiettivi e sui risultati attesi in ottica strategica, con una cadenze di breve-medio periodo.

È importante sottolineare che gli OKR non sono un sistema di performance management, motivo per cui è sconsigliabile calare gli OKR a livello individuale: fermiamoci a livello di obiettivi di team.

Figura 1 – Che cosa è esattamente un OKR?
Figura 1 – Che cosa è esattamente un OKR?

Parlo di “livelli” perché, gli OKR sono strutturati per facilitare la condivisione degli obiettivi: è quindi possibile spezzare un obiettivo strategico, a livello aziendale o di dipartimento, in un risultato tattico per una linea di business o di team.

Obiettivi e risultati chiave

Con queste premesse, possiamo dire che:

  • Objective: è un obiettivo espresso come una piccola “mission”, temporanea e qualitativa. Pensate all’obiettivo come all’effetto che le nostre attività avranno sul mercato, o al cambiamento nel comportamento dei nostri clienti.
  • Key Result: è un risultato chiave quantitativo che permette di raggiungere l’obiettivo. Deve essere numerico e quindi specificità e misurabilità del risultato sono d’obbligo.

Un esempio che spiega quanto detto potrebbe essere il seguente. L’obiettivo a livello strategico è rinforzare la presenza su un settore automobilistico debole; il risultato chiave sta nel fatto che il nostro veicolo vince premio come migliore della categoria.

Figura 2 – Obiettivo e risultato chiave.
Figura 2 – Obiettivo e risultato chiave.

A scopo esemplificativo, ho riportato solamente un risultato chiave associato all’obiettivo: è ovvio che al raggiungimento di un obiettivo, soprattutto di alto livello, concorreranno più risultati chiave. Restando nell’esempio che abbiamo fatto, altri risultati chiave potrebbero coinvolgere marketing e vendite, oltre alla produzione.

Calare il risultato chiave a un livello inferiore

Proviamo a calare il questo primo risultato chiave a un livello organizzativo inferiore, trasformandolo in un obiettivo per il team che coordina lo sviluppo del prodotto e quindi supervisiona il lavoro di più team, per esempio un team per gli interni, un team per il sistema di trasmissione, e così via. Quello che, al livello strategico, era stato il risultato chiave diventa qui invece l’obiettivo da raggiungere.

  • Obiettivo: il veicolo vince premio come migliore della categoria.
  • Risultato chiave: abitacolo silenzioso (rumorosità <70 dB).

È possibile che avremo più team che si prenderanno in carico i diversi aspetti del nostro prodotto: la logica è quella dei feature o component team.

Figura 3 – Passare al livello del coordinamento.
Figura 3 – Passare al livello del coordinamento.

Ulteriore approfondimento

Proviamo ora spingerci ad un livello organizzativo ancora inferiore in cui, nuovamente, il precedente risultato chiave viene trasformato in obiettivo, questa volta del team che si occupa dei sistema di trasmissione.

  • Obiettivo: abitacolo silenzioso (rumorosità <70 dB).
  • Risultato chiave: Integrare nuova tecnologia nel cambio.
Figura 4 – L’ulteriore livello è quello operativo.
Figura 4 – L’ulteriore livello è quello operativo.

Livello di aspettativa

Il terzo elemento fondamentale degli OKR è un livello di aspettativa, aggiornato settimanalmente, su quanto il team di sente sicuro del raggiungimento di uno specifico Key Result.

Questo intervallo di aspettativa può essere espresso su un intervallo tra 0 e 1 — quello originariamente usato in Google —, tra 1 e 5, tra 1 e 10, per quanto sia meglio utilizzare scale brevi.

L’obiettivo, per essere considerato sufficientemente ambizioso, dovrebbe contenere dei risultati chiave che inizialmente abbiano un livello di aspettativa non superiore al 50%: significa che il team si sta prendendo in carico un risultato che, al momento di iniziare il lavoro, ha un rapporto tra successo e insuccesso di 50 a 50.

Attenzione… è esattamente per questo motivo che gli OKR non devono essere usati, come dicevo poco prima, quale sistema di performance management. Il fallimento nel raggiungere un obiettivo di team ambizioso non deve in nessun modo influenzare la valutazione della prestazione del singolo. Se prendersi rischi è penalizzato, perché mai, allora, prendersi dei rischi? E, di conseguenza, perché innovare?

 

Non tutto quello che conta è misurabile

Per non cadere nella trappola della mera valutazione dell’output e quindi di seguire ciecamente solo i risultati chiave quantitativi, occorre predisporre un formato di aggiornamento che tenga conto del contesto. Questo formato può essere anche usato per un aggiornamento settimanale del team e per condividere la situazione al di fuori del team.

Figura 5 – La lavagna con le quattro aree per l’aggiornamento settimanale.
Figura 5 – La lavagna con le quattro aree per l’aggiornamento settimanale.

Questo semplice formato, ripetibile anche sotto forma di una board fisica o virtuale, è composto da quattro aree:

  • priorità della settimana;
  • preview delle prossime 4 settimane;
  • metriche di “salute”;
  • livelllo di aspettativa sui risultati chiave.

Ogni lunedì il team si incontra e condivide un aggiornamento su ciascuna di queste quattro aree.

I contenuti della board

Per priorità della settimana si intendono le attività più importanti o urgenti da svolgere nei successivi cinque giorni lavorativi.

La preview delle prossime 2-4 settimane serve per anticipare priorità future o possibili dipendenze o colli di bottiglia.

Le metriche di salute sono tutto ciò che non è incluso negli OKR, ma che deve restare entro una soglia accettabile. Le metriche di salute possono essere di natura tecnica (p.e.: uptime di un servizio), organizzativa (p.e.: dipendenze sotto controllo), economica (p.e.: P&L, Profit and Loss) o personale (p.e.: soddisfazione del team).

Il livello di aspettativa sui risultati chiave rappresenta un aggiornamento su quanto il team è fiducioso del raggiungimento degli specifici risultati chiave. Mentre le metriche di salute ragionano in termini di soglie minime/massime, i risultati chiave ragionano per target specifici.

Questa board può essere utilizzata solo all’inizio e alla fine della settimana. Al lunedì per fare un briefing di inizio settimana e al venerdì per chiudere con un aggiornamento su tutti i fronti, idealmente per celebrare il raggiungimento di qualche attività prioritaria o il miglioramento del livello di aspettativa su qualche risultato chiave.

Colmare il gap tra i vari livelli

Quante volte chi si occupa di strategia si lamenta del livello di dettaglio di chi si occupa di operatività? E quante volte chi si occupa di operatività si lamenta della vaghezza degli obiettivi strategici?

Tra gli effetti collaterali dell’utilizzo degli OKR c’è anche quello di innescare un meccanismo che incrementa fisiologicamente la qualità degli obiettivi e del come li descriviamo: il gap tra visione strategica e visione operativa può essere ridotto nel momento in cui dalla operatività ci arrivano i parametri concreti che possiamo utilizzare per valutare il raggiungimento degli obiettivi.

Per integrare le comunicazioni con il resto dell’azienda dobbiamo uscire dal singolo team e relazionarci all’esterno: per farlo possiamo appoggiarci sulla struttura, spesso sconosciuta, delle cadenze in Kanban.

 

Cadenze in Kanban: quando parliamo di cosa e perché

Anche qui, benché ci sia maggiore familiarità con gli eventi di Scrum, non significa che una cadenza regolare di incontri con uno scopo specifico non esista in Kanban. Esiste eccome ed è configurata in come rappresentato in figura 6.

Figura 6 – La “cadenza” in Kanban.
Figura 6 – La “cadenza” in Kanban.

La ragione per cui le cadenze non hanno preso piede potrebbe essere dovuta proprio a questa rappresentazione, forse eccessivamente complessa. Per cominciare, è importante premettere che:

  • queste non sono tutte riunioni obbligatorie;
  • è probabile che avvengano già in qualche forma nella vostra azienda;
  • vanno trattate come una linea guida per fare riunioni migliori;
  • è rilevante il fatto che siano correlate tra di loro a qualche livello.

Questi incontri hanno un ruolo importantissimo: garantiscono una permeabilità tra i diversi livelli aziendali che, altrimenti, rischierebbero di ricadere, nonostante Kanban, nella trappola del miglioramento locale, dell’isolamento dei silos, delle decisioni topdown e in una gestione di progetto praticamente waterfall

La nostra azienda potrebbe essere letteralmente tappezzata da lavagne Kanban, ma potremmo comunque non ricavarne alcun beneficio, in mancanza di una visione di insieme e di meccanismi di feedback integrati.

Considerazioni sulle cadenze

Fatta la dovuta premessa che Kanban prevede un livello di autodisciplina superiore rispetto a Scrum, vediamo di fare un paio di considerazioni valide per questi incontri, in modalità pull.

  • un determinato incontro potrebbe essere fatto solo quando serve e non necessariamente in date prestabilite;
  • nel vostro contesto, alcune di queste riunioni potrebbero non essere svolte affatto;

Vale il buon senso applicato: se vi rendete conto che i contenuti di queste cadenze Kanban vengono già affrontati in riunioni che tenete regolarmente, non c’è bisogno di aggiungere altre riunioni (nessuno ha bisogno di ulteriori riunioni…). Diversamente, può essere un’ottima occasione per sviluppare la buona abitudine di fare riunioni più efficaci, con agenda e tematiche prestabilite.

Queste cadenze possono servirci per allineare non solo le tradizionali metriche Kanban, legate all’efficienza del flusso di lavoro, ma anche gli OKR; si riesce pertanto a unire valutazioni di efficacia ed efficienza del lavoro a quelle di raggiungimento di obiettivi strategici.

Ma non finisce qui. C’è un ultimo strumento per evitare la troppo comune trappola per cui si finisce a produrre in maniera efficace ed efficiente… il prodotto o servizio sbagliato. Sono i Flight Levels.

 

Flight Levels: oltre la Kanban Board di team

Mentre la maggior parte dei framework di scaling agile si focalizzano principalmente su Scrum, si parla molto poco su come fare scaling di Kanban. Uno dei vari motivi di questa “reticenza” è probabilmente che lo scaling di Scrum può essere presentato in maniera “meccanicistica” — più team, più gerarchia, più meeting, più organizzazione matriciale, e cos’ via — mentre lo scaling di Kanban è necessariamente più organico e fluido.

Kanban ci mette alla prova sul come vediamo la nostra azienda, a livello sistemico, e sul come eroghiamo i nostri servizi e prodotti, sul cosa vogliamo ottimizzare globalmente, il che potrebbe essere completamente indipendente da un nuovo modello organizzativo o da dinamiche di scaling puramente meccaniche.

Non esiste, insomma, un “kit di scaling” per Kanban già pronto all’uso, da cui possiamo copia-e-incollare un approccio: l’approccio dobbiamo necessariamente costruirlo in base al contesto. Questo sarebbe comunque vero e corretto anche per Scrum, ma lo è sicuramente e obbligatoriamente per Kanban.

Figura 7 – Fligh Levels è un modello che descrive come Kanban potrebbe essere usato su più livelli di una organizzazione, in modo integrato.
Figura 7 – Fligh Levels è un modello che descrive come Kanban potrebbe essere usato su più livelli di una organizzazione, in modo integrato.

Flight Levels

Klaus Leopold, da qualche anno, ha reso popolare un modello che si chiama Flight Levels, per descrivere in che modo potrebbe essere usato Kanban, in maniera integrata, su più livelli di una organizzazione: la metafora è quella delle diverse altezze di volo degli aeromobili.

Da un satellite vediamo interi continenti, da un aereo vediamo una nazione, da una mongolfiera vediamo una città. Fanno tutti parte del “sistema mondo”, ma con un livello di dettaglio via via più raffinato.

Il modello che Leopold propone ha tre livelli:

  • livello strategico
  • livello di coordinamento
  • livello operativo

È un sistema Kanban completo, in cui l’output di un flusso diventa input dell’altro:

  • a livello strategico si decide cosa produrre e con che priorità;
  • a livello di coordinamento si stabilisce come produrre e a chi farlo produrre;
  • a livello operativo lo si produce

La granularità dei contenuti di questi livelli va ad aumentare progressivamente: da programma a progetto, da progetto a prodotto, da prodotto a funzionalità, da funzionalità a singola attività. In figura 7 ho sottolineato anche a quale livello potrebbero avere impatto le diverse cadenze Kanban, tenendo conto delle due considerazioni seguenti.

Anzitutto, questo è un suggerimento indicativo. Come dicevo sopra, valutate quali riunioni ricorrenti già avvengono nella vostra organizzazione, e decidete se alcuni di questi incontri avvengono già o magari sono da integrare.

In secondo luogo, l’indicazione su chi partecipa ai meeting segue questo principio: partendo dal livello strategico, alle varie cadenze sono invitati rappresentanti del livello sottostante ma nessuno del livello sovrastante. Quindi, ad esempio, a una Operation Review saranno coinvolti rappresentanti dei livello operativo e di coordinamento ma non quelli del livello strategico.

Visto così questo sistema a livelli rischia anch’esso di ricadere nella trappola di un meccanismo top-down, con una gestione delle attività di progetto in modalità waterfall: è per scongiurare questa situazione che ho pensato di illustrare come l’utilizzo integrato di OKR e cadenze ci aiuti a rinforzare i feedback loop, fondamentali per l’adozione di Kanban.

 

Integrare OKR, cadenze Kanban e Flight Levels

Giunti fino a qui abbiamo tre strumenti perfettamente integrabili:

  • gli OKR, che sono un framework per fissare e restare allineati su obiettivi e risultati attraverso un’intera organizzazione;
  • le cadenze in Kanban, che ci permettono di integrare i feedback da diverse parti dell’azienda;
  • i Flight Levels, che ci permettono di visualizzare il sistema Kanban completo, dall’idea al prodotto finito o al servizio erogato.
Figura 8 – Un’immagine che riassume l’integrazione degli elementi visti nell’articolo.
Figura 8 – Un’immagine che riassume l’integrazione degli elementi visti nell’articolo.

Riporto di seguito alcuni esempi di come alcune delle cadenze Kanban possono interagire nella pratica sia con i Flight Levels sia con OKR.

  • A livello strategico, la Strategic Review trimestrale può essere il momento in cui si valutano gli OKR trimestrali e si concordano quelli per il trimestre successivo. Questo avrà un ovvio impatto diretto sui successivi Replenishment Meeting, Operations Review e Service Delivery Meeting.
  • A livello di coordinamento, la Risk Review mensile può essere il momento in cui discutiamo gli elementi critici a livello di metriche di salute che non raggiungono la soglia minima che ci eravamo preposti. Come illustrato nello schema di figura 7, la Risk Review informa il Delivery Planning Meeting e cambia i contenuti di Operations Review e Service Delivery Meeting.
  • A livello operativo, il Replenishment Meeting settimanale può coincidere con l’aggiornamento di fine settimana della status board, in cui, in base all’andamento della settimana, decidiamo quanto e quale lavoro prendere in carico per la settimana successiva, influenzando direttamente il day-by-day del team.

Di nuovo, la parola chiave è permeabilità: per iniziare dobbiamo metterci nella condizione di creare il più piccolo sistema Kanban, magari di un solo progetto, end-to-end, visto da tre “altezze” diverse, che ci permetta di avere queste tre viste integrate non solo a livello di attività da svolgere, ma anche di obiettivi e risultati da raggiungere.

 

Comincia da quello che stai facendo adesso

Questo articolo non voleva essere una trattazione esaustiva di Kanban, OKR, Flight Levels e cadenze. Ovviamente ciascuno di questi temi racchiude complicazioni non banali nel passaggio dalla teoria alla pratica.

Quella che ho illustrato è una sorta di “starter kit” per poter uscire da un’ottica di miglioramento locale a livello di team, ed entrare nel reame di un miglioramento globale, o quantomeno esteso, introducendo elementi concreti di allineamento in termini di obiettivi e risultati.

C’è una certa eleganza empirica nel mettere assieme queste pratiche: il cambiamento organizzativo non è infatti un pre-requisito per iniziare da oggi ad applicare Flight Levels, OKR e cadenze. Il cambiamento organizzativo potrebbe essere solo una delle possibili conseguenze delle evidenze empiriche emerse utilizzando Kanban e OKR in maniera diagnostica.

Analisi della domanda

“Start with what you do now” è un principio cardine di Kanban e il primo passo che si può fare per iniziare a costruire la propria Kanban è quella che viene chiamata “analisi della domanda”, che si può iniziare a fare rispondendo a queste quattro domande:

  • Punti di partenza delle attività: ossia chi sono i committenti, le azioni o gli eventi che fanno iniziare le attività nel nostro team? Iniziamo a pensare al nostro team come a un team di servizio: chi stiamo servendo e per quale motivo?
  • Flussi delle attività: per ciascuno dei singoli punti di partenza, individuare quali sono tutti gli step necessari per portare a compimento l’attività. Cosa osserviamo? Ogni flusso ha fasi ben distinte, o ci sono fasi che si ripetono? Su quante di queste fasi il team è autonomo, su quante ha dipendenze esterne? Emergono colli di bottiglia?
  • Punti di arrivo delle attività: dove finiscono le nostre attività? Che cosa significa che una attività è “finita”? Il committente iniziale corrisponde con il cliente finale?
  • Aspettative del cliente: per ciascuno dei flussi di attività individuati, quali sono le cause di soddisfazione o insoddisfazione dei nostri clienti, siano essi finali, intermedi, interni o esterni?

Quest’ultimo punto inizia ad aprire la questione di come le attività del team soddisfino i clienti interni ed esterni e di come questa considerazione sul livello di soddisfazione apra poi discussioni sul raggiungimento degli obiettivi strategici, partendo dagli obiettivi di un singolo team: se lavoriamo in agilità, i nostri obiettivi non possono essere solo quelli di fare più story point o ridurre il lead time!

 

L'articolo OKR, cadenze in Kanban e Flight Levels proviene da MokaByte.

]]>
Continuous Delivery per il proprio team di sviluppo https://www.mokabyte.it/2022/10/17/rilasciocontinuo/ Mon, 17 Oct 2022 05:43:07 +0000 https://www.mokabyte.it/?p=9051 Non serve essere Netflix per adottare pratiche di Continuous Delivery: si tratta di principi applicabili a qualsiasi dimensione aziendale. In questo articolo ne vediamo un esempio concreto, ricavato dalle esperienze di un’azienda italiana.

L'articolo Continuous Delivery per il proprio team di sviluppo proviene da MokaByte.

]]>
D-Day: il giorno del rilascio

Ogni sviluppatore ha vissuto nella sua vita, almeno una volta, quella sensazione di palpabile tensione che si avverte nel Giorno del Rilascio. Tutti conosciamo le insidie dello sviluppo di un software e comprensibilmente temiamo il momento in cui questo comincerà a essere utilizzato, svelando i suoi difetti e, con essi, quelli del nostro lavoro.

Se siamo all’inizio della nostra carriera di sviluppatori, la paura del nostro primo rilascio potrebbe immobilizzarci, spingendoci a posporlo il più possibile. Se invece siamo sviluppatori esperti, sarà il fatalismo a farla da padrone: marceremo accigliati incontro al nostro destino e, se ci sarà da debuggare, si debuggerà!

In alcuni casi la preoccupazione per un rilascio è tale da toglierci il sonno la notte, o le notti, precedenti al fatidico Delivery Day. Siamo sicuri che debba essere veramente così?

Figura 1 – “If it hurts, do it often”: ripetere spesso un'azione ci aiuta a conoscerla e migliorarne l'esecuzione (immagine da Spotify AB).
Figura 1 – “If it hurts, do it often”: ripetere spesso un’azione ci aiuta a conoscerla e migliorarne l’esecuzione (immagine da Spotify AB).

 

La paura si vince con la conoscenza: si può forse dunque superare il timore del rilascio trasformando ogni giorno in un DDay, e rendendo le procedure di rilascio una routine prevedibile ed eseguibile su richiesta. È qui che ci viene in aiuto la pratica del Continuous Delivery.

 

Are you a release candidate?

Il termine Continuous Delivery (CD) [3] acquisisce notorietà nel 2010 con la pubblicazione dell’omonimo libro [2] scritto da Jez Humble e David Farley. Facendo evolvere i concetti di Continuous Integration (CI) figli del pensiero dell’eXtreme Programming di fine anni Novanta, il Continuous Delivery si propone di portare cambiamenti di qualunque tipo — incluse nuove features, cambi di configurazione, fix di bugs ed esperimenti — in ambiente di produzione e, quindi, nelle mani degli utilizzatori finali, in modo sicuro, veloce e sostenibile.

In un processo di tipo tradizionale, infatti, dopo lo sviluppo del prodotto seguono una serie di attività volte a far sì che il software sviluppato diventi rilasciabile. L’idea alla base del Continuous Delivery invece è che il software sviluppato debba essere sempre rilasciabile. Ma come arrivarci?

Figura 2 – Differenze tra diversi modelli di rilascio.
Figura 2 – Differenze tra diversi modelli di rilascio.

 

Il punto di partenza è quello, tipico della metodologia Agile, di suddividere il lavoro in singoli requisiti rilasciabili autonomamente. Lo step successivo, concettualmente fondamentale, è l’integrazione continua di ogni singolo sviluppo: anziché posporre questa fase a un momento successivo, essa viene automaticamente eseguita con il commit. Si crea così un sistema di feedback che rileva se un cambiamento rompe il sistema o non rispetta i requisiti nel momento stesso in cui viene introdotto.

Il Continuous Delivery aggiunge un passo in più: dopo le fasi di build e test il software è automaticamente rilasciato in un ambiente di staging, analogo a quello di produzione, con gli stessi processi e strumenti. Il software prodotto secondo questa prassi, se supera tutti i passaggi e arriva all’ambiente di staging, è quindi di fatto già in condizione di poter essere rilasciato. Ogni cambiamento introdotto nel sistema in questo modo diventa dunque un release candidate, rilasciabile in produzione tramite una nuova versione del software.

È possibile portare questo processo al suo estremo, automatizzando anche quest’ultimo passaggio, senza l’intervento di una persona per l’approvazione della messa in produzione: è la pratica cosiddetta di Continuous Deployment [4].

 

I principi del Continuous Delivery

Tenendo ben presente questa concezione di release candidate, si possono identificare sei principi essenziali per garantire un processo di rilascio efficace e continuo:

  • automatizzare quasi tutto;
  • mantenere tutto in controllo versione;
  • affrontare il “dolore” e costruire sulla qualità;
  • “finito” vuol dire “rilasciato”;
  • ognuno è responsabile;
  • miglioramento continuo.

Vediamoli in dettaglio.

Automatizzare quasi tutto

Molti team di sviluppo non automatizzano il processo di sviluppo perché pare rischioso, complesso e time-demanding. La verità è che quasi tutto — processo di build, test di accettazione, upgrade e downgrade di database, configurazione di network e firewall, e molto altro ancora — può, con il giusto lavoro, essere automatizzato. L’automazione è il prerequisito per una pipeline di deployment che sia affidabile, ripetibile e semplice come premere un bottone.

Mantenere tutto in controllo versione

Ogni piccolo commit di codice, tutto ciò che usiamo per lo sviluppo, il test, il rilascio dei nostri applicativi deve essere conservato con un sistema di versionamento (Git, Subversion, Mercurial o qualsiasi altro VCS). Ogni change set dev’essere referenziato con un numero di versione, e dev’essere sempre possibile identificare quale build dei vari applicativi è rilasciata in un dato momento in ogni singolo ambiente, e da quale versione proviene.

Affrontare il “dolore” e costruire sulla qualità

Integration, test, release possono essere momenti dolorosi in un progetto. Per questo non vanno rimandati alla fine, ma anticipati il prima possibile ed eseguiti il più spesso possibile. Questo principio consente non solo di migliorare le competenze del team ma soprattutto di individuare subito i difetti del software e di poter intervenire prontamente per correggerli. Scrivendo codice coperto da test, quindi, si è automaticamente vincolati a scrivere buon codice: è così possibile arrivare al “Build Quality In”.

“Finito” vuol dire “rilasciato”

Uno dei più classici problemi nella definizione di un requisito, solitamente espresso sotto forma di user story, è la nozione di “finito”, anche chiamata Definition of Done: la lista di attività che devono essere portate a termine affinché il requisito possa dirsi completato e che deve soddisfare i criteri di accettazione. A ben guardare, però, una feature raggiunge il suo scopo solo nel momento in cui viene utilizzata dai suoi utenti: è uno dei motivi alla base del Continuous Delivery. Per eliminare ogni equivoco, dunque, in un processo di CD si considera finito solo ciò che è già stato rilasciato.

Ognuno è responsabile

Il rilascio di un software richiede tipicamente la collaborazione di più persone (developer, tester, operations team, PO…). Poiché non genera valore per il cliente finché non è rilasciato, il successo di un progetto è sempre un successo di team, mai individuale. Rendere le persone corresponsabili e incoraggiare la loro collaborazione è uno step fondamentale per ottenere rilasci più rapidi e più affidabili.

Miglioramento continuo

Proprio come il rilascio di un’applicazione è solo la prima fase della sua vita, che continuerà a evolvere, così anche il processo di rilascio deve essere continuamente e incrementalmente migliorato.

 

Un processo anche per le piccole realtà

A quasi dieci anni dall’uscita del libro di Humble, il Continuous Delivery è celebre per essere utilizzato in molte grandi aziende del mondo digitale come ad esempio Google o Yahoo. Il deployment engine di Amazon gestisce oltre 50 milioni di rilasci l’anno, mentre Facebook rilascia dai 500 ai 1000 cambiamenti al giorno.

Il CD non è tuttavia una questione di scala: è basato su un insieme di principi che possono essere trasformati in pratica in modo diverso ma con uguale successo a seconda del contesto in cui opera ogni team di sviluppo, anche in aziende di piccole dimensioni.

La nostra esperienza con Mia-Platform

Quel che raccontiamo di seguito non ha la pretesa di essere esaustivo; è il frutto dello studio e dell’esperienza maturate nella nostra realtà, Mia-Platform [7] un’azienda informatica che conta circa 40 sviluppatori. Questo articolo, infatti, nasce dalle riflessioni sul lavoro fatto dai nostri colleghi Tommaso Ballardini e Riccardo Porrini che hanno razionalizzato la loro esperienza diretta nel talk “It Starts With a Goal” [1]

Mia-Platform fornisce il proprio software a molte aziende differenti, che lo utilizzano per lo sviluppo di applicazioni che servono complessivamente milioni di utenti. Si pone dunque la necessità di conciliare i rilasci del proprio prodotto con gli sviluppi, gli aggiornamenti e la manutenzione degli applicativi dei clienti, ciascuno dei quali ha i propri tempi e le proprie esigenze.

Gestire una tale complessità non è banale: il processo di delivery tradizionale, che prevedeva build e test manuali, ci ha creato negli anni più di un grattacapo. Non era infrequente la situazione in cui, a seguito di un rilascio a fine giornata, ci si trovasse poi a dover riparare il software a orari improbabili, perché l’integrazione del software e il suo funzionamento non erano stati prima debitamente testati e verificati; talvolta addirittura si poteva incorrere in problemi perché non sempre l’immagine che era testata era poi la stessa che veniva rilasciata.

 

Le pratiche di CD adottate dal team

Uno dei nostri team, al lavoro su un progetto specifico, ha deciso in accordo con gli altri di sperimentare e portare all’interno del proprio percorso di rilascio alcuni principi di Continuous Delivery, trasformandoli in pratiche concrete adoperabili nel proprio contesto. Di seguito le vediamo una per una.

Obiettivi pianificati

La pianificazione stabilisce gli obiettivi di rilascio per ogni ciclo di lavoro, che ha una periodicità definita, tipicamente settimanale. Ogni mattina, poi, il team si aggiorna e condivide ciò che verrà sviluppato e rilasciato quel giorno. La board del team, fisica o digitale che sia, consente di tenere gli obiettivi sott’occhio, mantiene il team allineato e aiuta ad attuare il principio dell’“Everyone is Responsible”.

Pipeline di deployment automatica

Il codice sviluppato e versionato attiva una pipeline automatica di build, unit test e test di accettazione. Il Product Owner, interno al team, verifica subito i requisiti di accettazione del cliente e abilita il rilascio automatico in ambiente di staging, dove il software è sottoposto a un’ulteriore validazione. In modo continuo, nel corso di ogni sprint, durante le finestre di rilascio prestabilite, le feature pronte passano dall’ambiente di staging a quello di produzione, tramite un deployment automatico che viene azionato manualmente.

Figura 3 – La pipeline del team che porta il codice dal checkout all'ambiente di staging (NB: per questo team, la linea rossa indica uno step attivato manualmente).
Figura 3 – La pipeline del team che porta il codice dal checkout all’ambiente di staging (NB: per questo team, la linea rossa indica uno step attivato manualmente).

Finestre di rilascio

Non sempre il business servito — il cliente — rende possibile rilasciare in produzione in ogni momento. Analizzando il traffico e l’utilizzo da parte degli utenti è possibile individuare i momenti migliori per i rilasci a seconda delle esigenze specifiche. Le finestre temporali sono generalmente dipendenti dalle applicazioni e dal dominio applicativo — per esempio, macchine non disponibili in determinate fasce orarie — e comprendono sempre anche il tempo per eventuali rollback, come il re-deployment della versione precedente.

Figura 4 – Il flusso di delivery del team è continuo. Il deployment in produzione invece è lanciato manualmente nelle finestre temporali previste.
Figura 4 – Il flusso di delivery del team è continuo. Il deployment in produzione invece è lanciato manualmente nelle finestre temporali previste.

Small batches

Il batch work (accorpare insieme feature differenti, bug fixes, etc.) è nemico dei developer perché aumenta la possibilità di far fallire il rilascio. La complessità di merge infatti non aumenta linearmente rispetto alla quantità di codice rilasciato. Un’eventuale roll-back, inoltre, invalida tutto il lavoro fatto, incoraggiando il team a scomporre il lavoro in singole feature e procedere per cicli di sviluppo incrementali.

Versionamento rigoroso

Poiché si rilascia molto spesso in tutti gli ambienti, è fondamentale sapere sempre che cosa è rilasciato in ogni ambiente. Per questo ogni applicazione e servizio espone un proprio numero di versione.

Figura 5 – In un processo di Continuous Delivery è normale rilasciare decine di volte al giorno. I cambiamenti che non funzionano vengono automaticamente bloccati prima di andare live e possono essere subito rilavorati.
Figura 5 – In un processo di Continuous Delivery è normale rilasciare decine di volte al giorno. I cambiamenti che non funzionano vengono automaticamente bloccati prima di andare live e possono essere subito rilavorati.

 

I risultati ottenuti sono stati estremamente positivi: dopo un primo periodo di assestamento e di messa a punto del processo, il team ha incrementato in modo esponenziale il numero dei propri rilasci, che oggi sono anche varie decine al giorno.

Allo stesso tempo, i rilasci che causano rotture critiche sono pressoché scomparsi, perché i cambiamenti che rompono il sistema vengono automaticamente bloccati prima di arrivare in produzione.

Molti degli insegnamenti appresi da questo team sono diventati patrimonio comune e pratica condivisa anche per tutti gli altri team di Mia-Platform. Ogni singolo progetto software ha il proprio contesto e le proprie esigenze specifiche, e dunque non sempre è possibile estendere a tappeto i processi in modo uniforme; ma i principi alla base rimangono comunque validi per tutti e sono oggi un riferimento imprescindibile nel percorso di sviluppo dell’intera azienda.

 

In conclusione

I principi di Continuous Delivery, applicati nella pratica secondo il contesto in cui opera ogni team di sviluppo, consentono di sconfiggere la paura del rilascio e far evolvere il software in modo più rapido, semplice e affidabile. Anche grazie a questi principi oggi riusciamo a gestire l’intricata trama dello sviluppo di molteplici prodotti e applicativi, e vivere i rilasci come una normale routine.

Un buon processo di delivery, nella nostra esperienza, è automatico, è uguale per tutti gli ambienti, comprende anche le infrastrutture, prevede due step separati per build e deploy, è attivabile da chiunque all’interno di un team, segue un versionamento rigoroso e consente in modo continuo il rollback del software.

Figura 6 – Il giorno del rilascio non diventa più un giorno del giudizio: i rilasci continui vengono vissuti come una normale routine.
Figura 6 – Il giorno del rilascio non diventa più un giorno del giudizio: i rilasci continui vengono vissuti come una normale routine.

 

I costi principali risiedono nella scrittura dei test e nell’automazione dei processi, nella suddivisione dei progetti in singole feature da sviluppare, e nel tempo necessario alle persone per adattarsi al nuovo processo di sviluppo. Nessuno di questi costi dovrebbe essere un freno tale da scoraggiare questa strada, dati i numerosi benefici che essa comporta tanto per l’azienda come per i suoi clienti.

 

L'articolo Continuous Delivery per il proprio team di sviluppo proviene da MokaByte.

]]>
Il contratto è agile! https://www.mokabyte.it/2022/10/17/contrattiagili/ Mon, 17 Oct 2022 04:56:00 +0000 https://www.mokabyte.it/?p=9043 Il presente articolo si propone di analizzare, attraverso alcune brevi considerazioni, la tematica sempre attualissima del rapporto tra metodologia Agile e contratti. A differenza di quanto viene spesso rappresentato, analogie tra i principi alla base dei due sistemi di norme (Manifesto Agile e codice civile) ci sono, e la loro presunta incompatibilità rappresenta un mito da sfatare.

L'articolo Il contratto è agile! proviene da MokaByte.

]]>
Introduzione

La questione relativa al rapporto tra contratti e metodologie Agile fa spesso discutere gli esperti del settore. Anche su queste pagine, in alcuni interessanti articoli, il tema è stato più volte affrontato. Il dibattito circa la compatibilità di determinate metodologie di sviluppo software — e dei principi alla loro base — con la normativa in vigore è però alimentato da alcune incomprensioni.

Senza pretese di completezza, in queste pagine si cercherà di sgombrare il campo da alcune errate “credenze” in materia contrattuale e di chiarire come questa sia totalmente compatibile con i principi espressi nel Manifesto Agile.

Non parleremo in dettaglio in questo articolo di tecniche di negoziazione e/o di mediazione per arrivare a un determinato accordo che poi può sfociare in un contratto, ma ci concentreremo specificamente sugli aspetti legali e normativi, visti però a un certo livello di astrazione.

 

Una contrapposizione apparente

Sfogliando un qualsiasi articolo che tratti la tematica del rapporto tra contratti e agilità, ricorre come un mantra la contrapposizione tra “contratto tradizionale” e “contratto agile”. Vediamo cosa c’è di vero, e di falso, in questa contrapposizione.

Il contratto “tradizionale”

Secondo quanto si crede generalmente, al contratto “tradizionale” sarebbe attribuita la specifica funzione di consentire a una delle parti — quella più scaltra o più forte contrattualmente — di perseguire il proprio interesse, anche a discapito di quello altrui.

Al contratto “tradizionale”, al contempo, si attribuirebbe l’ulteriore compito di sanzionare le inadempienze della controparte: la costante presenza di penali, in questo tipo di contratti, risponderebbe proprio a questa esigenza di tutela.

Il contratto “agile”

Il contratto “agile”, basato sui principi del noto Manifesto, all’opposto si fonderebbe sulla buona fede delle parti, garantendo trasparenza e collaborazione tra tutti gli attori coinvolti nel rapporto contrattuale: la sua funzione, in definitiva, sarebbe quella di creare valore diffuso, consentendo a tutti di perseguire i propri interessi.

Questo tipo di contratto, per via della sua peculiare struttura, sarebbe inoltre in grado di adattarsi a eventuali cambiamenti intervenuti durante la sua esecuzione, distinguendosi così dalla rigidità di quello “tradizionale”.

Non confondere i diversi piani

In quest’ottica, ed estremizzando i concetti al solo scopo esemplificativo, il contratto “tradizionale” risulterebbe quindi uno strumento per imporsi su altri soggetti: utilizzato dal più forte, economicamente o intellettualmente, verrebbe impiegato per ottenere in modo indebito condizioni contrattuali migliori, oppure per tenere sotto scacco, attraverso penali, la controparte. In realtà, a livello meramente legale, le differenze tra contratti “agili” e “tradizionali” sono apparenti e si basano su due incomprensioni di fondo.

Da un lato, chi scrive del rapporto tra metodologie Agile e contratti è in genere un tecnico con buona esperienza di business, ma tende a confondere piani molto diversi: occorre infatti ricordarsi che la fase delle trattative preludio alla formazione del contratto (la “negoziazione”) è cosa diversa dal suo contenuto e dalla sua esecuzione.

Dall’altro, vengono quasi sempre ignorati i fondamenti dell’ordinamento civile, attribuendo carattere di novità ad alcuni principi del Manifesto Agile che, in materia contrattuale, di innovativo hanno però ben poco, visto che certi principi esistono già e sono codificati nel codice civile, come vediamo di seguito.

 

Dai principi al contratto

Perché quindi non ha senso distinguere tra contratti “agili” e contratti “tradizionali”? Formulando diversamente la domanda, perché si ritiene che non esistano contratti “agili” basati sulla buona fede delle parti, sulla loro collaborazione e cooperazione, sulla trasparenza e sul perseguimento degli interessi di tutte i soggetti legati dal contratto?

Perché questi principi, anche se espressi nel Manifesto Agile, sono da sempre alla base dell’ordinamento civile e, in particolare, della disciplina contrattuale. E ciò è facilmente riscontrabile. La “buona fede”, che sembrerebbe del tutto estranea ai contratti “tradizionali”, è invece uno dei pilastri della normativa che regola i rapporti tra privati: attraverso una semplice ricerca nel testo del codice civile, si può rilevare come l’espressione “buona fede” vi compaia più di 60 volte. Non è un caso.

Il principio della buona fede

Il principio di “buona fede” permea profondamente la materia civilistica: abbiamo disposizioni specifiche, inderogabili, che obbligano le parti a comportarsi “secondo buona fede” nello svolgimento delle trattative e nella formazione del contratto, oltre che nella sua esecuzione e addirittura nella sua interpretazione.

È un principio talmente importante che la sua violazione può comportare, in determinati settori, anche sanzioni amministrative. Discorso analogo può essere svolto con riferimento ai concetti di “correttezza” e “collaborazione” già citati. Anche a essi il codice civile dedica varie disposizioni, imponendo alle parti del contratto, ad esempio, trasparenza informativa, lealtà reciproca e divieto di rottura ingiustificata delle trattative.

Nel rapporto contrattuale, inoltre, si richiede sempre che ciascuna delle parti compia quanto necessario per consentire alla controparte di adempiere alla propria obbligazione, ossia di “collaborare” alla realizzazione della prestazione pattuita.

Obblighi di protezione

Infine, occorre dedicare qualche parola in merito alla presunta vocazione “egoistica” attribuita al contratto “tradizionale”, che mirerebbe esclusivamente al perseguimento dell’interesse di una delle parti, quella che riesce a imporlo all’altra.

Nel nostro ordinamento la disciplina in materia di contratti si pone in maniera diametralmente opposta rispetto a quanto appena rappresentato: nei rapporti contrattuali, ma non solo, si è sempre in presenza di doveri di salvaguardia dell’interesse dell’altra parte. Vengono definiti “obblighi di protezione” e sussistono anche qualora non siano stati oggetto di specifica pattuizione, in quanto corollari del generale principio di buona fede.

Così, in presenza di un contratto di servizi, sussiste l’obbligo di evitare al proprio fornitore un costo maggiore per l’esecuzione della sua prestazione; ad esempio, non solo lo si deve informare di guasti o malfunzionamenti del servizio, ma ci si deve anche adoperare attivamente per la loro risoluzione.

Si può quindi affermare che, sul piano dei principi che regolano l’ordinamento civilistico, non esiste distinzione tra contratti “tradizionali” e contratti “agili”: il contratto è sempre “agile”, se con ciò si intende che, in tutte le fasi della sua “vita”, le parti debbano rispettare i principi di “buona fede”, “trasparenza”, “collaborazione” e che lo stesso debba essere funzionale al perseguimento dell’interesse di tutti i soggetti ivi coinvolti.

Una doverosa precisazione

Non si vuole ovviamente negare che il contratto, all’apparenza espressione della libertà e dell’autonomia di ciascun soggetto, possa essere nei fatti l’esito di un processo in cui le diseguaglianze tra le parti, di qualsiasi tipo, abbiano avuto un’influenza enorme: non è difficile rintracciare casi di questo tipo anche nell’ambito della propria esperienza diretta o indiretta.

Però questo è un problema reale che si trova comunque su di un piano totalmente differente dai principi dell’ordinamento. È un muoversi attraverso certi interstizi che nulla ha a che vedere con l’esistenza di determinati principi e con la necessità del loro rispetto nei rapporti contrattuali.

 

Quale ruolo per Agile in materia contrattuale?

Dovendo riassumere, diremmo che, nonostante sia anche possibile cercare di volgere a proprio esclusivo vantaggio i termini di un contratto, nell’ordinamento esistono già comunque alcuni principi, quali la buona fede, la collaborazione e la trasparenza, che in genere vengono messi in risalto nell’ambito delle metodologie agili. In tal senso, Agile nulla può aggiungere alle norme.

Quest’ultima considerazione, però, conduce a porci qualche ulteriore domanda: e allora quale ruolo possono giocare i principi e le pratiche Lean/Agile in materia contrattuale? Se non ha la capacità di individuare nuovi principi normativi su cui basare i nostri contratti, in che cosa ci può essere utile Agile? A questo proposito si possono provare a svolgere due tipi di considerazioni.

Scegliere con chi stipulare contratti

Mi sembra di poter dire, in primo luogo, che il Manifesto Agile abbia anche un valore “ideologico” — nel senso neutro del termine — e, come per un qualsiasi complesso o insieme di valori, può incidere sulle nostre scelte di business, analogamente a chi, per convinzione ideologica, sceglie ad esempio di consumare solo certi prodotti che ritiene consoni al suo sistema di valori e di principi.

Questo potrebbe, ad esempio, indurre una azienda che abbracci pienamente principi e pratiche Lean/Agile a rapportarsi solo o preferibilmente con partner commerciali che accettino espressamente, o si impegnino ad accettare, l’utilizzo di certe metodologie e certi approcci. È chiaro che magari questo sarà possibile al 100% solo in un mondo ideale, ma ciò non toglie che può essere un obiettivo da perseguire almeno in maniera parziale.

Aspetti tecnici nei contratti

In secondo luogo, si può pensare che precise modalità — di sviluppo tecnico o di natura organizzativa — previste dall’approccio Agile, siano integrate nel contratto. Non si sta parlando di principi generali, ma di specifici metodi di conduzione delle operazioni per lo sviluppo software o la creazione di altro prodotto. Oppure della definizione dei tempi e dei budget dei contratti che può essere stabilita nella maniera più consona (“a corpo”, “a consumo”, “a obiettivo” etc.) al tipo di intervento che viene condotto.

Si tratta di precisi elementi contrattuali che potranno integrare il contratto sotto il profilo delle modalità di esecuzione della prestazione, e che, data la loro complessità, saranno oggetto di una trattazione ad hoc in uno dei prossimi numeri. Ma, tanto per non rimanere troppo nel vago, nei contratti si possono indicare aspetti relativi a standard tecnici o a precisi requisiti o a tempistiche prestabilite, come si può invece anche optare per la loro deliberata assenza.

Chiaramente, tutti questi aspetti vanno valutati in una fase precente a quella in cui si arriva al contratto: l’inserimento di certi elementi ha, di fatto, un peso residuale e tecnico. E prevedere nei termini contrattuali l’inserimento, ad esempio, dell’adozione di una ben definita metodologia agile non trasforma automaticamente il nostro in un “buon” contratto, o in un contrato “agile”: nel contratto può comunque permanere un elevato squilibrio nella ripartizione delle responsabilità tra le parti o esso può essere imposto da condizioni di mercato sfavorevoli.

E, aspetto forse ancor più rilevante, tutto ciò non modifica l’atteggiamento della nostra controparte, che è forse l’elemento a cui occorre prestare più attenzione, se possibile, nei rapporti contrattuali.

 

Conclusioni

Da un punto di vista legale, i contratti “agili” non esistono: è importante prendere coscienza del fatto che la normativa attuale prevede già strumenti di tutela e principi in grado di consentire alle parti di realizzare pienamente i propri interessi commerciali ed economici ispirandosi a principi di buona fede, collaborazione, trasparenza.

Principi e pratiche Lean/Agile possono quindi svolgere un ruolo rilevante, ma non sotto questo profilo legale. Possono però orientare le scelte commerciali e di business delle aziende, e consentire di integrare il contratto sotto il profilo tecnico-metodologico, anche in maniere piuttosto innovative, ma che restano comunque nell’alveo degli esistenti principi dell’ordinamento.

 

L'articolo Il contratto è agile! proviene da MokaByte.

]]>
Veicoli elettrici ed esperienza utente https://www.mokabyte.it/2022/09/13/uxecar-1/ Tue, 13 Sep 2022 14:02:50 +0000 https://www.mokabyte.it/?p=8969 Introduzione Questa estate ho avuto la possibilità di provare per un periodo piuttosto lungo un’auto elettrica gentilmente fornitami da Toyota Motor Italia (TMI). Si tratta del classico long-range test drive — o, per dirla in italiano, una prova di guida per un periodo più lungo — che l’azienda offre a giornalisti specializzati, esperti del settore,… Continua a leggere Veicoli elettrici ed esperienza utente

L'articolo Veicoli elettrici ed esperienza utente proviene da MokaByte.

]]>
Introduzione

Questa estate ho avuto la possibilità di provare per un periodo piuttosto lungo un’auto elettrica gentilmente fornitami da Toyota Motor Italia (TMI). Si tratta del classico long-range test drive — o, per dirla in italiano, una prova di guida per un periodo più lungo — che l’azienda offre a giornalisti specializzati, esperti del settore, consulenti.

In realtà non credo di rientrare esattamente in nessuna di queste categorie, ma lavoro con TMI su tematiche di riorganizzazione e trasformazione Agile dei processi aziendali. Ad ogni modo, ho accettato volentieri l’offerta per l’estrema curiosità che nutro sull’oggetto “auto elettrica” e su quello che significa utilizzare questo tipo di mezzo di trasporto.

Durante questo periodo di prova ho accumulato una piccola esperienza che penso possa essere utile anche per altri.

Non parlerò qui di aspetti tecnici, di prestazioni delle differenti auto — ne ho usata solo una e non so quasi nulla di come sia fatta dentro — o di caratteristiche progettuali delle infrastrutture delle reti di distribuzione dell’energia: so ben poco di quello che c’è oltre il maniglione del cavo di ricarica.

Prospettiva UX

Partendo dal presupposto che un’auto elettrica non è semplicemente un mezzo di trasporto che usa una fonte di energia differente, ma richiede un approccio diverso e almeno per ora, un cambio nelle abitudini, parlerò della mia esperienza personale, relativa al mio caso d’uso, al tipo di auto che avevo, all’uso che ne ho fatto, cercando di concentrarmi su come è cambiata la (mia personale) esperienza utente in termini di mobilità. Da qui il titolo dell’articolo.

Se siete totalmente a digiuno di kW, kWh, tempi di ricarica, tipologia di connessioni e colonnine, vi consiglio di farvi un giro su uno dei molti blog che trovare in rete. Per andare sul sicuro, io sono partito dal blog [1] di Paolo Attivissimo, noto giornalista, blogger e debunker.

 

Il contesto

Il veicolo che ho avuto modo di provare è una Toyota ProAce Verso — un minivan 8 posti — con una batteria da 70 kWh,  autovettura molto simile a quella che guido ormai da anni e con la quale ho trasportato di tutto: quintali di olive al frantoio per la frangitura, quantità di miele al consorzio per il conferimento, le biciclette di vario tipo per andare agli allenamenti o alle gare, materiale edile vario, pali in legno e perfino il telaio di una Vespa PX 125; ricordo di averci dormito durante le trasferte alle manifestazioni sportive di ciclismo e di averci perfino girato un video con i colleghi durante un poolcar. Ah: ovviamente la mia auto “normale” è servita anche e soprattutto a trasportare persone…

Disporre di un’auto simile a quella che uso di solito mi ha permesso di fare confronti interessanti, sperimentando un modo totalmente nuovo di fare mobilità in contesti simili a quelli che vivo normalmente.

 

Come cambia l’esperienza di guida

Prima di tutto partiamo dall’esperienza di guida: difficile esprimere a parole cosa significhi guidare un’auto elettrica. Io l’ho trovata semplicemente magnifica: è estremamente rilassante, semplice, intuitiva, comoda. La guida in progressione continua — non c’è il cambio ma invece un variatore infinito — rende tutto semplice e intuitivo. Anche nei passaggi più difficili è tutto estremamente facile: che ci si trovi su una impervia strada di campagna con curve strette, pendenze estreme, strade sconnesse — tutte caratteristiche della mia strada di casa — o che si debba attraversare la città nell’ora di punta, la guida è sempre comoda e riposante.

Sebbene sia un motociclista appassionato, quindi legato a dover dosare gas, scalare, frenare all’ultimo momento per una staccata in curva, non ho sentito la mancanza del cambio e della frizione, anzi. Ho amato fin da subito questo modo di guidare.

Mediamente a fine viaggio sono sempre stato più riposato, anche perché, per esigenze di autonomia sono sempre stato “costretto” a viaggiare più piano… ma non è un male: alla fine non penso di aver allungato oltremisura i tempi di spostamento.

Quindi se mi chiedessero “Vorresti guidare sempre un’auto così?”, la risposta sarebbe “Certamente sì; mi ha letteralmente conquistato”.

Potrei terminare qui il discorso. Ma l’articolo affronta ulteriori aspetti, più tecnici in senso di progettazione della User eXperience, che può essere interessante considerare.

 

Come cambia la User eXperience globale con una eCar

Oltre alla differente esperienza di guida, un’auto elettrica richiede un notevole cambio di approccio nella gestione degli spostamenti. Se con un’auto a motore termico possiamo per così dire “improvvisare” — quando ci troviamo a secco, male che vada possiamo sempre fermarci al primo distributore di carburante disponibile —, un veicolo elettrico richiede un’attenta pianificazione, almeno all’inizio e almeno con la tecnologia attuale.

Figura 1 – Il veicolo Toyota collegato a una colonnina di ricarica. La diffusione di queste infrastrutture sta progressivamente aumentando e rappresenta un elemento fondamentale per l’esperienza utente con un’auto elettrica.
Figura 1 – Il veicolo Toyota collegato a una colonnina di ricarica. La diffusione di queste infrastrutture sta progressivamente aumentando e rappresenta un elemento fondamentale per l’esperienza utente con un’auto elettrica.

 

Per spiegare meglio questo passaggio vorrei considerare tre scenari d’uso:

  • Caso 1: Brevi spostamenti urbani (commissioni, spostamenti locali);
  • Caso 2: Mobilità periodica (p.e. due viaggi quotidiani casa – ufficio – casa);
  • Caso 3: Lunghe percorrenze (come, nel mio caso, per le vacanze estive).

In tutti questi casi, ricordo che non si tratta di un’analisi definitiva, ma di riflessioni preliminari partendo dalla mia esperienza fatta con un’auto che nasce per fare altro — è un van—, non è pensata per essere efficiente — è pesante e non è aerodinamica—, ma che di fatto si presenta come un “sosia elettrico” di qualcosa che siamo già abituati ad avere e che per questo ha un “metro di paragone”. È la lezione delle “stime agili” fatte proprio a partire da un’entita che ben conosciamo, piuttosto che per misure assolute.

Oltre a questo, aggiungo che durante l’estate 2022 ho fatto conoscenza con molti altri possessori di auto elettriche, tutti curiosi di scambiare informazioni durante i momenti di ricarica alle stazioni. Per questo, sebbene stia riportando informazioni relative al mio caso specifico, ho notato che non sono molto dissimili da quanto vissuto da altri, guidatori di Tesla a parte.

Caso 1: La User eXperience con una eCar nei brevi spostamenti

Partendo dal presupposto che si abbia la possibilità di ricaricare l’auto nella notte (p.e. colonnina vicino casa o wallbox in garage), questo scenario è quello più comodo: i seppur pochi km di autonomia delle auto elettriche attuali — i modelli Tesla fanno eccezione — permettono di vivere la giornata senza particolari accorgimenti. Possiamo partire da casa, recarci in ufficio, andare a fare la spesa, passare da amici  e tornare a casa rimettendo in carica la macchina alla fine del giro. Durante le soste di questo scenario, possiamo comunque sfruttare per ricaricare l’auto il tempo necessario per fare la spesa o per visita medica.

Dato che le pause saranno brevi, non è pratico affidarsi alle ricariche a bassa potenza che, sebbene più economiche, richiedono ore per riempire la batteria; se volete ricaricare l’auto rapidamente è sensato usare le colonnine più potenti. Per esempio una super charge di EnelX presente nel parcheggio di un supermercato vi permette di ricaricare 70 kWh (nel mio caso “il pieno”) in circa un’ora di tempo.

Si consideri che in questo caso, se si parte la mattina con la batteria completamente carica, l’autonomia media delle attuali auto elettriche (intorno ai 200-300 km) permettono di vivere la giornata senza particolari problemi. La ricarica durante le brevi pause non è quindi strettamente necessaria.

Caso 2: La User eXperience con una eCar sulla mobilità periodica

Questo è lo scenario che ho testato diverse volte nel mese di luglio prima delle ferie. E mi ha riservato interessanti sorprese.

Abitando fuori città (Firenze) spesso mi muovo abitualmente con la mia auto fino ai mezzi pubblici, tipicamente treno, e poi proseguo con i mezzi. A luglio sono dovuto andare da un cliente in pieno centro fiorentino: Zona a Traffico Limitato, ma con accesso consentito ai mezzi elettrici. La prima volta sono andato con la mia auto diesel, ho girato molto, senza successo, per trovare parcheggio: non vivendo in città e non andandoci tutti i giorni non sono aggiornato su dove si possa o non si possa entrare e su dove sia effettivamente possibile parcheggiare e a che prezzi.

La seconda volta, sono andato con l’auto elettrica: ho dovuto pianificare il viaggio per calcolare le distanze e localizzare le colonnine disponibili, e questo è qualcosa a cui sicuramente non siamo abituati. Ma ho potuto parcheggiare l’auto vicino a una  colonnina praticamente subito fuori ZTL, a 5 minuti a piedi dal cliente.

La colonnina era a media potenza — carica lenta, circa 4-6 ore per “il pieno” — per cui ho lasciato l’auto in carica per tutto il tempo in cui sono stato dal cliente. Ho pagato solo l’energia ricaricata ma non la sosta, che tipicamente è gratuita durante il periodo di ricarica più un’ora di parcheggio gratuito fornita per gestire lo spostamento.

Altro esempio di questo tipo di spostamenti è legato alla mia vita privata: mi capita spesso di andare a trovare i miei genitori che vivono in città. Il parcheggio nella loro zona è difficile da trovare: anche in questo caso con un minimo di pianificazione, ho trovato stazioni di ricarica di vario tipo/costo molto comode. Se la visita è breve, posso usare una fast charge se invece vado per una cena con serata annessa, la slow charge va benissimo e costa meno.

Gli esempi riportati mostrano come in realtà la vita che facciamo è già compatibile con la necessità di fare un rifornimento che ha tempistiche differenti dal riempire un serbatoio di benzina.

Certamente anche in questo caso poter ricaricare l’auto vicino a casa durante la notte semplifica la giornata, anche se poter ricaricare l’auto in ufficio è una cosa comunquemolto comoda.

Caso 3: La User eXperience nei lunghi viaggi

Questo scenario è quello che mette maggiormente in difficoltà un’auto elettrica. Specialmente se, come nel mio caso, l’auto ha un elevato consumo e/o scarsa autonomia.

Durante un lungo viaggio, in genere si vuole arrivare prima possibile a destinazione, minimizzando numero e durata delle soste: se con un’auto a benzina si può partire e fermarsi al distributore più comodo, con le auto elettriche si deve pensare il percorso minimizzando le soste e sempre in corrispondenza di punti di ricarica ad alta potenza (veloci) lungo il percorso.

Al momento, all’interno della rete autostradale, le stazioni fast charge sono scarse, anche se pare che le cose inizino a cambiare e, nell’arco di un paio di anni, potremo usufruire di punti di ricarica distribuiti come le stazioni di rifornimento di carburante.

Sulle strade non a pedaggio le cose sono forse ancora più complicate: pochi i punti fast charge che sono condivisi con chi magari sta “vivendo” uno degli scenari 1 e 2.  Che la “pompa” sia occupata accade anche per chi deve fare il pieno di benzina: ma le differenti tempistiche amplificano il problema dell’accesso concorrente alle poche colonnine.

Pianificare il viaggio significa decidere come dividere l’intero viaggio, quante volte e dove fermarsi, che tipo di ricarica fare e quanto ricaricare la batteria: per farlo si possono usare alcuni servizi pensati appositamente per questo scopo. Tesla ha un sistema tutto suo ma, per gli altri marchi, il più famoso al momento è A Better RoutePlanner (ABRP) [2], disponibile come sito web e app mobile, che permette di creare i percorsi di viaggio con suggerimenti su dove fermarsi e per quanto tempo: in base al tipo di veicolo (consumo e capienza batteria), destinazione, tipologia di colonnine che si vuole utilizzare, offre alcuni suggerimenti.

Figura 2 – L’interfaccia di A Better RoutePlanner con la mappa e i criteri di pianificazione. Sulle app e le loro caratteristiche torneremo più approfonditamente nel prossimo articolo.
Figura 2 – L’interfaccia di A Better RoutePlanner con la mappa e i criteri di pianificazione. Sulle app e le loro caratteristiche torneremo più approfonditamente nel prossimo articolo.

 

Breve anticipazione sui servizi di pianificazione

L’app non è solidissima e l’esperienza utente spesso lascia a desiderare. E queste considerazioni si possono estendere a tutte le app a tema veicoli elettrici che ho usato in questo periodo di prova.

Ma soprattutto ho potuto constatare anche in questa occasione che… la mappa non è il territorio.

Questi servizi consentono infatti di progettare meticolosamente il viaggio: purtroppo i malfunzionamenti, i blocchi, una UX decisamente migliorabile — problemi che peraltro affliggono gran parte delle app — rendono le cose meno semplici, e in certi casi anche difficilmente risolvibili.

 

Conclusioni

Per questo mese ci fermiamo qui. Abbiamo fornito solo una serie di considerazioni generali sul contesto e su possibili casi d’uso dei veicoli elettrici. Ma abbiamo introdotto il cruciale tema delle app di pianificazione dell’itinerario e delle ricariche che, insieme al veicolo, costituiscono un sistema in grado di garantire — o meno — una positiva esperienza utente.

Nel prossimo articolo approfondiremo il discorso sulle app di route planning e ricarica e sul loro ruolo fondamentale nella UX globale del mondo eCar.

 

Riferimenti

[1] Fuori Di Tesla: News. Un blog di Paolo Attivissimo dedicato alla mobilità elettrica

https://fuori-di-tesla.blogspot.com

 

[2] ABRP, A Better Route Planner

https://abetterrouteplanner.com/

 

 

L'articolo Veicoli elettrici ed esperienza utente proviene da MokaByte.

]]>
WebAssembly, uno standard web per il presente e per il futuro https://www.mokabyte.it/2022/09/13/webassembly-2/ Tue, 13 Sep 2022 13:44:20 +0000 https://www.mokabyte.it/?p=8962 Introduzione Sempre più spesso alcuni colleghi mi chiedono perché io insista molto sul fatto che WebAssembly potrebbe arrivare a sostituire Docker. Se proprio devo essere onesto, in realtà non so nemmeno io se questo succederà; sono però convinto che WebAssembly ci riservi numerose interessanti prospettive. Andiamo con ordine e vediamo insieme di cosa si tratta.… Continua a leggere WebAssembly, uno standard web per il presente e per il futuro

L'articolo WebAssembly, uno standard web per il presente e per il futuro proviene da MokaByte.

]]>
Introduzione

Sempre più spesso alcuni colleghi mi chiedono perché io insista molto sul fatto che WebAssembly potrebbe arrivare a sostituire Docker. Se proprio devo essere onesto, in realtà non so nemmeno io se questo succederà; sono però convinto che WebAssembly ci riservi numerose interessanti prospettive. Andiamo con ordine e vediamo insieme di cosa si tratta.

 

Perché Docker?

Nella distribuzione delle moderne applicazioni, abbiamo sempre bisogno di sicurezza. Dobbiamo essere certi che le applicazioni che consumiamo, e quelle che sviluppiamo, non possano in nessun modo intaccare il sistema che le ospita. In questo, non c’è ombra di dubbio, i container svolgono il loro lavoro egregiamente.

Molto più flessibili e veloci all’avvio rispetto alle Virtual Machine, ci garantiscono il necessario isolamento fra un processo e un altro e ci permettono di mantenere viva un’applicazione anche se un processo si blocca per qualsiasi motivo. Insomma, distribuire applicazioni a microservizi tramite container ha cambiato un po’ la vita di noi sviluppatori.

 

Però, come ogni nuova tecnologia, anche Docker ha sicuramente contribuito a risolvere alcuni problemi, ma ha portato con sé nuove sfide. Per essere onesti, se proprio volessimo una completa autonomia di ogni singolo processo, dovremmo pubblicare ogni singola funzione in un container separato;, ma, siamo sinceri, sarebbe un lavoro un po’ da pazzi, assolutamente possibile, ma poco pratico.

Attenzione, non sto parlando di qualche processo che si possa racchiudere in una lambda su AWS, o una function su Azure, ma di un’intera applicazione in cui ogni singola funzione sia un container. Nella realtà un container è più un’API, che poi, per chi applica Domain-Driven Design, è l’espressione di un Bounded Context, quindi, proprio micro non lo è.

Se poi vogliamo che veramente ogni singolo processo sia indipendente, allora bisogna anche che la comunicazione fra i container sia asincrona, e questo aggiunge complessità alla nostra infrastruttura. Per non parlare del fatto che il sogno di ogni sviluppatore è quello di scrivere un solo codice per tutte le piattaforme, e non è un segreto che i container non sono affatto agnostici alla piattaforma. Possiamo creare container per Windows o per Linux, ma non container “universali”.

Insomma, servirebbe una soluzione che ci possa garantire affidabilità e sicurezza, ma che sia un po’ più semplice da applicare, una via di mezzo fra isolamento ed efficienza.

 

I moduli WebAssembly

Sarebbe possibile avere una soluzione che ci possa garantire portabilità e aggiungere efficienza senza ricorrere a Virtual Machine e/o Container per avere garantito il giusto isolamento grazie alla sandbox che questi strumenti ci mettono a disposizione? In realtà lo è, e questa soluzione si chiama WebAssembly.

Abbiamo visto nel precedente articolo che il formato WebAssembly è un file binario che ha bisogno di un runtime per funzionare; ma attenzione, alcuni potrebbero pensare che anche i linguaggi del .NET framework, o i programmi scritti in Java, in fin dei conti, una volta compilati, sono dei file binari che girano sfruttando i rispettivi framework, quindi che vantaggi porta il formato WebAssembly?

Innanzitutto il formato WebAssembly è più simile a una virtual machine che non ad un binario in senso lato, così come siamo abituati a pensare per l’IL del .NET framework di Microsoft; è più una “stack based virtual machine”. La differenza? IL è un binario OOP, con tanto di interfacce, garbage collector, reflection, high level types, e tutto quello che serve per un’astrazione ad alto livello.

WebAssembly, da parte sua, è un binario molto più a basso livello, senza tutte le astrazioni presenti nel IL, senza tutti i pattern della OOP; è molto più simile all’Assembler, e questo binario è in grado di girare all’interno di tutti i browser moderni, senza ulteriori framework di mezzo. È agnostico alla piattaforma.

Certamente, qualcuno potrebbe obiettare che il binario WebAssembly giri all’interno di un browser. Ma anche questa affermazione è vera a metà. WebAssembly può girare anche all’esterno dei browser, e qui le cose si fanno interessanti. Per poter girare out-of-the-browser, WebAssembly ha bisogno di un host, che potrebbe anche essere un host custom scritto da chi distribuisce la soluzione.

Per nostra fortuna ne esistono di pronti all’uso, e li abbiamo già citati sempre nel precedente articolo: Wasmtime [1] e WAMR [2]. Grazie a questi host, possiamo compilare i nostri programmi direttamente in WebAssembly, e ormai la maggior parte dei linguaggi supporta questa soluzione, a partire da Rust, particolarmente indicato, sino ad arrivare a C#, Cobol, Java, Python e molti altri.

WASI

Quindi tramite questi host che ci permettono di far girare applicativi WebAssembly al di fuori dei browser, possiamo accedere alle risorse del sistema che ci ospita? Non esattamente; abbiamo detto che la forza di WebAssembly è proprio la presenza di una sandbox che ci garantisce tutto l’isolamento necessario. E allora?

Abbiamo bisogno di una API agnostica alla piattaforma che ci consenta di ottenere il tanto agognato obiettivo “Write Once, Run Everywhere”, e questa API esiste ed ha un nome: WASI (WebAssembly Sistem Interface). WASI [3] è il confine fra l’applicazione che gira nella sandbox e il sistema sottostante e fornisce tutta la protezione necessaria al server che ci ospita, praticamente molto simile a un container.

WAGI

È chiaro che il progetto WebAssembly, così come era stato pensato all’inizio, è andato ben oltre le aspettative, ed è quindi lecito chiedersi cosa possiamo ulteriormente fare. Ad esempio, perché non costruire un web server WebAssembly in grado di intercettare ogni richiesta e gestirla in un processo separato, una sandbox isolata?

Per questo abbiamo a disposizione WAGI (WebAssembly Gateway Interface) [4]. I dev un po’ più attempati forse avranno già notato una somiglianza con un amico de passato, ossia CGI (Common Gateway Interface). L’idea alla base è esattamente la stessa: il Web Server riceve la richiesta HTTP e avvia un processo per gestirla, in questo caso un processo isolato, con tutto ciò che ne consegue; un eventuale malfunzionamento non compromette la stabilità della soluzione.

Il valore aggiunto di WAGI è che è costruito su Wasmtime, e questo, oltre a garantirci una sandbox isolata, ci permette di non avere ulteriori framework di mezzo, rendendo il tutto estremamente snello ed efficace.

 

WebComponents

Se è vero che l’appetito vien mangiando, perché fermarsi proprio ora che ci stiamo divertendo ad avere WebAssembly ovunque? Perché non definire uno standard WASM-based per costruire componenti agnostici al linguaggio e isolati nella loro sandbox da poter riciclare?

Anche in questo caso ci sarà chi riconosce una soluzione simile del passato: COM, Component Object Model. Proprio come si faceva con COM, ossia costruire oggetti in C++ da utilizzare in VisualBasic, oppure condividere fogli Excel all’interno di Word, allo stesso modo l’idea è costruire componenti WebAssembly nel linguaggio preferito, e più indicato allo scopo, e consumarli ovunque.

Qui la strada è solo tracciata, nel senso che una soluzione definitiva è ancora in divenire. Al momento attuale abbiamo bisogno di un SDK per poter costruire componenti condivisibili. A tal proposito segnalo spin [5], un SDK di Fermyon, startup molto attiva nel mondo WebAssembly.

 

WebAssembly vs Docker

Giunti a questo punto è lecito chiedersi se WebAssembly sostituirà Docker in un futuro più o meno immediato. Ovviamente no, la sola ed unica risposta degna di un dev è: “Dipende!”

 

Qual’è la prima differenza rispetto a Docker? Un modulo WebAssembly non viene fornito con un filesystem preconfezionato (Linux o Windows), e nemmeno con altre primitive di basso livello. Variabili d’ambiente, file, directory, timer e altre risorse di sistema possono invece essere collegate direttamente al nostro modulo.

Più che a un container possiamo dire che un modulo WebAssembly è più simile ad un Pod di Kubernetes, nel senso che filesystem e variabili d’ambiente sono legati a un container nel momento in cui questo viene avviato. La differenza fondamentale sta nel fatto che questa è una caratteristica fondamentale di WASI (WebAssembly System Interface), uno degli standard di WebAssembly stesso. Fa parte di un runtime, non di un sistema di orchestrazione come nel caso di Kubernetes.

Possiamo concludere che, così come i container non hanno sostituito le Virtual Machine, Wasm non sostituirà i container. In ogni caso, ci sono caratteristiche di Wasm che lo rendono particolarmente appetibile negli ambienti serverless (cloud edge). Tra queste caratteristiche:

  • Wasm è simile a un Container, ma con un’astrazione a un livello più alto;
  • Wasm è agnostico alla piattaforma;
  • Wasm gira in una sandbox isolata;
  • sarà possibile costruire componenti Wasm-based

Quello che possiamo affermare è che WebAssembly ormai è uno strumento in più che abbiamo a disposizione, non si tratta di un qualcosa che sarà disponibile in futuro, e per questo non lo possiamo più ignorare. A dimostrazione di questo, molte novità sono attese in autunno anche da parte di Microsoft con il rilascio della versione 7 del .NET framework, in cui sarà possibile compilare applicazioni Blazor direttamente in WebAssembly e creare applicazioni WebAssembly out-of-browser grazie a .NET MAUI.

 

Cosa ne pensa Docker?

Sul sito di Docker è apparso recentemente un interessante articolo [6] proprio sul rapporto tra Docker e WebAssembly. Amici o nemici? Consiglio la lettura completa dell’articolo, ma già il titolo è in grado di dirci molto: Why Containers and WebAssembly Work Well Together.

 

Riferimenti

[1] Wasmtime. A fast and secure runtime for WebAssembly
https://wasmtime.dev/

 

[2] WebAssembly Micro Runtime (WAMR)
https://github.com/bytecodealliance/wasm-micro-runtime

 

[3] WASI. The WebAssembly System Interface
https://wasi.dev/

 

[4] WAGI. WebAssembly Gateway Interface
https://github.com/deislabs/wagi

 

[5] spin, SDK open source di Fermyon
https://github.com/fermyon/spin

 

[6] Tyler Charboneau, Why Containers and WebAssembly Work Well Together. 01/07/2022
https://t.ly/pRxF

 

L'articolo WebAssembly, uno standard web per il presente e per il futuro proviene da MokaByte.

]]>
Un sistema di monitoraggio del traffico veicolare “in tempo reale” https://www.mokabyte.it/2022/09/13/rttrafficmonitoring-7/ Tue, 13 Sep 2022 12:49:44 +0000 https://www.mokabyte.it/?p=8930 La dashboard di visualizzazione La dashboard di visualizzazione, basata su tecnologia WebSocket, viene implementata sotto forma di microservizio SpringBoot che espone un WebServer, il quale pubblica una pagina HTML di presentation e le classi di backend Java necessarie alla definizione del microservizio e di accesso ai dati di Cassandra. WebSocket è una specifica che permette… Continua a leggere Un sistema di monitoraggio del traffico veicolare “in tempo reale”

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
La dashboard di visualizzazione

La dashboard di visualizzazione, basata su tecnologia WebSocket, viene implementata sotto forma di microservizio SpringBoot che espone un WebServer, il quale pubblica una pagina HTML di presentation e le classi di backend Java necessarie alla definizione del microservizio e di accesso ai dati di Cassandra.

WebSocket è una specifica che permette la comunicazione bidirezionale sincrona tra un client e un server, nel nostro caso il browser web e il microservizio SpringBoot. WebSocket è un protocollo basato su una connessione HTTP attraverso cui possono essere scambiati frame a lunghezza variabile tra i due endpoint. Si tratta quindi di un protocollo generalmente utilizzato per la comunicazione sincrona tra il browser dell’utente e un’applicazione di backend esposta da un web server.

Figura 1 – WebSocket.
Figura 1 – WebSocket.

 

Un WebSocket è un canale di comunicazione che utilizza TCP come protocollo sottostante. Viene avviato dal client che invia una richiesta HTTP al server richiedendo un aggiornamento della connessione a WebSocket. Se il server supporta questo protocollo, la richiesta del client viene concessa e viene stabilita una connessione di questo tipo tra le due parti. Da questo momento tutte le comunicazioni avvengono tramite WebSocket e il protocollo HTTP non viene più utilizzato. WebSocket realizza un protocollo di comunicazione senza richiedere uno specifico formato di messaggistica. Spetta alle applicazioni concordare il formato dei messaggi scambiati. WebSocket API fa parte della specifica HTML5 ed è supportata dai più diffusi browser Internet.

Per la dashboard di visualizzazione la comunicazione WebSocket viene realizzata attraverso il framework Spring, utilizzando STOMP (Streaming Text Oriented Message Protocol) come protocollo di messaggistica. STOMP definisce un formato di comunicazione dove un client STOMP può comunicate con un message broker STOMP per realizzare un’interoperabilità di messaggistica di semplice implementazione piuttosto diffusa tra linguaggi di programmazione e piattaforme diverse.

L’implementazione della dashboard di visualizzazione viene completata dall’utilizzo delle librerie JavaScript JQuery e Chart. JQuery viene utilizzata nelle pagine per semplificare la selezione, la manipolazione, la gestione degli eventi e l’animazione di elementi (Document Object Model). JQuery semplifica anche l’uso di funzionalità AJAX, la gestione degli eventi e la manipolazione dei CSS. Attraverso la libreria Chart.js verranno creati gli elementi grafici in linguaggio JavaScript.

Backend

Descriviamo in questo paragrafo le classi che definiscono il layer applicativo di backend. Di seguito l’implementazione della classe di avvio Spring Boot dove si evince la direttiva che abilita lo scheduling che sarà impostato poi nella classe service.

Figura 2 – Classe di avvio SpringBoot.
Figura 2 – Classe di avvio SpringBoot.

 

La funzionalità WebSocket viene abilitata attraverso l’annotazione @EnableWebSocketMessageBroker. Viene quindi codificata la registrazione dell’endpoint STOMP alla URL scelta (/stomp) attraverso SockJS, abilitato un message broker e configurata la URL corrispondente (/topic). Di seguito il fragment di implementazione della classe di configurazione.

Figura 3 – Implementazione WebSocket e STOMP nel message broker.
Figura 3 – Implementazione WebSocket e STOMP nel message broker.

 

Di seguito la classe che serializza le informazioni che saranno ottenute da Cassandra attraverso la classe di tipo data service.

Figura 4 – Classe di serializzazione delle informazioni ricevute da Cassandra.
Figura 4 – Classe di serializzazione delle informazioni ricevute da Cassandra.

 

Di seguito la classe DataService con la codifica di accesso schedulato ai record di Cassandra e invio degli stessi sotto forma di messaggio (WebSocket/STOMP) alla dashboard di visualizzazione.

Figura 5 – Classe DataService con la codifica di accesso schedulato ai record di Cassandra.
Figura 5 – Classe DataService con la codifica di accesso schedulato ai record di Cassandra.

 

Di rilevo nella codifica viene segnalata la variabile responseMessage che rappresenta un’istanza di org.messaging.simp.SimpMessagingTemplate, implementazione dell’interfaccia SimpleMessageSendingOperations, classe che a sua volta specializza MessageSendingOperations. MessageSendingOperations implementa i metodi  necessari al supporto del framework di Spring per protocolli di Simple Messaging come STOMP. Il metodo convertAndSend invia il contenuto serializzato della classe httpDatiResponse alla URL di pubblicazione della dashboard.

Presentation

Viene riportata di seguito la codifica della pagina HTML/JavaScript che implementa le funzionalità di visualizzazione. Il primo fragment evidenzia l’importazione delle librerie client dei framework JavaScript utilizzati:

Figura 6 – Import Framework JavaScript.
Figura 6 – Import Framework JavaScript.

 

La codifica continua definendo le variabili di persistenza delle tabelle accedute attraverso JQuery e la creazione di una istanza SockJS e di un client STOMP.

Figura 7 – Variabili JQuery, istanza SockJs e client WebSocket.
Figura 7 – Variabili JQuery, istanza SockJs e client WebSocket.

 

Viene quindi codificato il client STOMP che sottoscrive il messaggio al path specificato. Nel body del messaggio saranno presenti i dati contenuti nelle tabelle Cassandra letti dal microservizio SpringBoot.

Figura 8 – Codifica e configurazione del client STOMP.
Figura 8 – Codifica e configurazione del client STOMP.

 

I dati di ciascuna tabella Cassandra (nell’esempio listaTrafficoTotale) vengono concatenati in una stringa con gli elementi HTML di visualizzazione.

Figura 9 – Creazione dei contenuti HLML di visualizzazione.
Figura 9 – Creazione dei contenuti HLML di visualizzazione.

 

La visualizzazione delle informazioni sui controlli Chart.js conclude l’implementazione della codifica JavaScript.

Figura 10 – Assegnazione dell’HTML costruito dai dati Cassandra ai controlli grafici.
Figura 10 – Assegnazione dell’HTML costruito dai dati Cassandra ai controlli grafici.

Grafici di monitoraggio

Di seguito i grafici di monitoraggio che rappresentano i veicoli al POI con il dettaglio della distanza, la distribuzione del traffico per tipo veicolo rilevata in nodo stradale specifico e il traffico totale per le direttrici stradali considerate.

Figura 11 – Veicoli al POI.
Figura 11 – Veicoli al POI.

 

Figura 12 – Dettaglio dei veicoli al Point of Interest.
Figura 12 – Dettaglio dei veicoli al Point of Interest.

 

Figura 13 – Distribuzione del traffico per tipo veicolo al nodo A24/A90.
Figura 13 – Distribuzione del traffico per tipo veicolo al nodo A24/A90.

 

Figura 14 – Dettaglio del traffico totale per tipo veicolo sulle direttrici considerate.
Figura 14 – Dettaglio del traffico totale per tipo veicolo sulle direttrici considerate.

 

Dashboard Spark

Spark pubblica alla URL: <nome_host>:4040/jobs la dashboard di controllo. La dashboard elenca i job completati e la loro corrispondenza sulla timeline di esecuzione. Nella figura 15 c’è il dettaglio di un job di esempio con i riferimenti alla corrispondente linea di codice Java, il timestamp del momento dell’invio, la durata, gli stage e il dettaglio dei task. Nella timeline, i job sono rappresentati con colori diversi per quelli in esecuzione, quelli eseguiti con successo e quelli falliti.

Figura 15 – Dashboard Spark: lista job completati.
Figura 15 – Dashboard Spark: lista job completati.

 

Figura 16 – Dashboard Spark: lista job completati e dettaglio sulla timeline.
Figura 16 – Dashboard Spark: lista job completati e dettaglio sulla timeline.

 

Figura 17 – Dashboard Spark: dettaglio del job sulla timeline.
Figura 17 – Dashboard Spark: dettaglio del job sulla timeline.

 

Di seguito la visualizzazione in formato DAG (Directed Acyclic Graph) di un job di esempio, con il dettaglio degli stage che esegue. Nella lista degli stage completati possiamo notare la corrispondenza di ciascuno alla linea di codice Java di implementazione. Anche in questo caso, la lista riporta le informazioni con il timestamp di invio, la durata, il numero di task terminati con successo, la quantità di dati di input e di output e il numero di letture/scritture.

Figura 18 – Dashboard Spark. Stage del job: visualizzazione DAG.
Figura 18 – Dashboard Spark. Stage del job: visualizzazione DAG.

 

Nelle figure di seguito, sono riportate la visualizzazione di dettaglio di ogni stage con le evidenze delle metriche di esecuzione.

Figura 19 – Dashboard Spark: dettaglio dello stage e metriche di esecuzione.
Figura 19 – Dashboard Spark: dettaglio dello stage e metriche di esecuzione.

 

Figura 20 – Dashboard Spark:  metriche aggregate e dettaglio del task.
Figura 20 – Dashboard Spark:  metriche aggregate e dettaglio del task.

 

Nel dettaglio di visualizzazione DAG di ciascuno stage vengono visualizzati i task che lo compongono: nel riquadro verde l’operazione eseguita da ciascun task (direct stream, map).

Nella parte evidenziata in rosso la corrispondenza al codice Java eseguito: nell’esempio, la creazione dello stream di lettura da Kafka utilizzando il runtime kafka 0.10 direct stream e le due operazioni di map che ottengono in sequenza i nuovi RDD richiesti dall’elaborazione.

Figura 21 – Dashboard Spark: dettaglio dello stage e corrispondenza di implementazione.
Figura 21 – Dashboard Spark: dettaglio dello stage e corrispondenza di implementazione.

 

Analogamente a quanto già descritto per lo stage precedente, con una serie di immagini, di seguito viene riportato il dettaglio del secondo stage, sempre riferito al job preso in esame.

Figura 22 – Dashboard Spark: dettaglio dello stage.
Figura 22 – Dashboard Spark: dettaglio dello stage.

 

Figura 23 – Dashboard Spark: dettaglio dello stage e metriche di esecuzione.
Figura 23 – Dashboard Spark: dettaglio dello stage e metriche di esecuzione.

 

Figura 24 – Dashboard Spark: dettaglio dello stage e corrispondenza di implementazione.
Figura 24 – Dashboard Spark: dettaglio dello stage e corrispondenza di implementazione.

 

Conclusioni

Questa serie di articoli descrive una possibile implementazione di una piattaforma digitale di monitoraggio in tempo reale di dati posizionali inviati dai veicoli in transito su alcune direttrici stradali. Sono stati presentati i moduli applicativi, i dettagli tecnologici di integrazione e le caratteristiche di funzionamento di Kafka, Spark e Cassandra.

L’esempio proposto è facilmente estendibile a molti altri casi d’uso. Per esempio, al monitoraggio delle informazioni che rilevano eventuali criticità sui dispositivi in dotazione dei veicoli che trasportano merci pericolose. La possibilità di attuare un monitoraggio in tempo reale di queste informazioni potrebbe attivare una più efficace gestione della sicurezza, anche con l’integrazione delle informazioni inviate dai dispositivi IOT installati su infrastrutture stradali critiche, anche utilizzabili per eseguire algoritmi di intelligenza artificiale orientati alla prevenzione degli incidenti e/o a rendere più efficiente la fluidità del traffico.

Tra le caratteristiche di Spark Streaming c’è la possibilità di integrare batch di dati storicizzati con dati live streaming. Questa caratteristica rappresenta un elemento significativo in tema di gestione e programmazione del fabbisogno e della domanda di nuovi servizi di mobilità e più in generale per l’attuazione dei modelli di smart city.

Anche in ambito industriale il monitoraggio dei dati provenienti dai dispositivi IOT installati sulle macchine può rappresentare uno strumento di analisi e miglioramento dei processi oltre che di valutazione degli impatti di una modifica dei processi stessi.

Più in generale è verosimile che le analisi basate sul monitoraggio in tempo reale dei dati provenienti dai dispositivi IOT integrati dai batch di dati storicizzati, e con l’applicazione su questi dati di algoritmi di intelligenza artificiale, rappresentano uno strumento efficace per analizzare e migliorare l’efficienza dei processi osservati.

 

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
Fare pair programming con l’intelligenza artificiale https://www.mokabyte.it/2022/09/13/aipairprogramming/ Tue, 13 Sep 2022 11:50:04 +0000 https://www.mokabyte.it/?p=8924 Il pair programming è, o dovrebbe essere, una pratica comune ed affermata nell’ambito della programmazione software. Ma è possibile ipotizzare l’assistenza dell’Intelligenza Artificiale in questo approccio allo sviluppo? In questo e in un successivo articolo, vediamo di approfondire il discorso.

L'articolo Fare pair programming con l’intelligenza artificiale proviene da MokaByte.

]]>
Pair programming + AI: un connubio possibile?

Possiamo immaginare di fare pair programming non con un’altra persona ma con l’intelligenza artificiale? Questa domanda, che può sembrare una provocazione, apre invece una serie di riflessioni molto interessanti e, forse, più attuali di quanto pensiamo. Prima di cominciare a vedere l’argomento in maniera più approfondita, però, è necessario un breve disclaimer:

  • nessuna intelligenza artificiale è stata maltrattata per scrivere questo articolo (qualche saltuario accidenti a parte);
  • non parleremo nel dettaglio di machine learning o AI, ma vogliamo approfondire l’idea che l’intelligenza artificiale, insieme all’apprendimento guidato o all’autoapprendimento, possa entrare nella vita degli sviluppatori e aiutarli a creare software migliore e di maggiore qualità.

Machine learning vs. Deep learning

È necessario, inoltre, fare una piccola parentesi per chiarire la differenza tra machine learning e deep learning: due termini che sentiamo usare spesso e che hanno alcune differenze sostanziali.

Immaginiamo di avere come input un cane e di dover classificare se è cane o non cane.

Con il machine learning, una persona deve estrarre le caratteristiche per capire se quell’immagine è considerabile un cane (coda, zampe, etc.) e una rete neurale viene addestrata per la sua classificazione. Una volta addestrata, la rete neurale è in grado di classificare in modo corretto se quello che “vede” è cane o non cane

Con il deep learning, l’apprendimento non è supervisionato da una persona: l’estrazione delle caratteristiche e la classificazione viene fatta direttamente dalla rete neurale.

Figura 1 – Machine Learning vs Deep Learning.
Figura 1 – Machine Learning vs Deep Learning.

 

Chiarito il significato di queste tecniche, vedremo in questo articolo come vengono sfruttate da strumenti, sia open source che a pagamento o in fase sperimentale, per aiutarci a scrivere codice migliore.

 

Che cosa è il pair programming

Il pairing è un aspetto molto importante nelle buone pratiche di Extreme Programming (XP): due persone lavorano a coppia sullo stesso codice, “aiutandosi” l’un l’altro con delle previse metodiche e dei ruoli che si alternano, in maniera tale da migliorare il processo di programmazione. Il pair programming, infatti:

  • aiuta a essere più attenti e produttivi quando si sviluppa codice;
  • permette di ridurre errori durante lo sviluppo del codice;
  • aiuta a condividere la conoscenza;
  • una volta che si fa anche a rotazione nel team, diventa uno strumento di team building.

Quando si lavora in team, non è facile scrivere codice in pair programming. Ciascuno, solitamente, scrive il proprio pezzo di codice sul proprio computer e sul proprio schermo. Creatività e design del codice rimangono nella mente delle persone e vengono tradotte in codice dal singolo sviluppatore, ognuno sul proprio schermo.

C’è poca collaborazione — che può essere sicuramente migliorata con Continuous Delivery e altre pratiche — e, in linea di massima, questo approccio rallenta, riduce e postpone i momenti di collaborazione.

Oltre la semplice scrittura di codice

Sappiamo però che realizzare software non è solo una questione tecnica ma è un momento di forte collaborazione tra le persone. È quindi importante trovare dei momenti per fare pairing.

Driver e navigator sono i ruoli tipici dell’attività di pair programming; lavorano con la stessa code base e nello stesso momento, e insieme programmano e soddisfano dei requisiti attraverso la scrittura di codice.

Il driver pensa in modo tattico a come incrementare una funzionalità ed esprime, ad esempio, l’intenzione “filtro lo stream per passarlo a C”.

Il navigator, invece, essendo mani alla tastiera, può avere la visione d’insieme sul perché si sta facendo una determinata azione e può dire: “Perchè non lo mandi a B invece che mandarlo a C?”.

Quella che abbiamo appena descritto è la dinamica tipica di quando si fa pair programming.

 

TDD (Test Driven Development)

Un altro aspetto importante da affiancare al pairing è il Test Driven Development (TDD). Scrivere un test, scrivere il codice per passare un test e fare refactoring fino a quando il codice è pulito in modo accettabile è fare TDD.

Questo ciclo rapido da fare ogni 10 minuti aiuta a scrivere codice più pulito e semplice perché fa solo quello che serve e niente di più: è testabile e con responsabilità chiare.

Figura 2 – Test Driven Development.
Figura 2 – Test Driven Development.

 

Un approccio TDD permette di scrivere codice documentato e manutenibile dalle persone nel tempo; non è quindi un aumento di costi ma anzi una riduzione sia di costi che di tempi di sviluppo perché si vanno a ridurre con certezza problemi che possono emergere successivamente in produzione, o a evitare complessità di codice che non verrà poi realmente utilizzato.

Quante volte ci capita di implementare un’intenzione che non serviva strettamente alla funzionalità che stavamo sviluppando?

 

Pairing e TDD

Da una parte il pairing, dall’altra il test. Ora proviamo a metterli insieme.

TDD lo facciamo da soli? Si può, però non è così divertente. La cosa migliore sarebbe farlo insieme: aiuta a condividere la conoscenza, a concentrarsi sull’obiettivo e a non disperderlo facendo over-engineering. Quante volte ci sarà capitato di scrivere un pezzo di codice e poi di decidere di aggiungere una parte che pensiamo ci servirà, credendo di avere una sfera di cristallo che ci permette di sapere oggi cosa ci servirà domani?

Tipicamente poi cambiano i requisiti e quella funzionalità si rivela inutile e rimane un pezzo di codice che non serve a nulla.

Facendo TDD insieme, se una delle persone inizia ad andare alla deriva verso la scrittura di qualcosa che esula dall’obiettivo, può essere fermato dal navigator che pone attenzione su quell’aspetto.

Figura 3 – TDD e Pair Programming.
Figura 3 – TDD e Pair Programming.

 

Il pair programming può essere efficace anche se iniziamo a farlo in una modalità a ping pong: scrivo un test e passo la palla all’altra persona che scrive codice per soddisfarlo, e poi l’altra persona scrive un test e io scrivo codice in grado di superarlo. In questo modo ci si alterna tra driver e navigator come vuole l’etichetta di un pair efficace e funzionante.

 

Pair e TDD non vengono fatti così spesso: perché?

Fondamentalmente perché è faticoso: stare con una persona tutto il tempo, essere disciplinati, non andare alla deriva con soluzioni che ci piacciono ma non servono, avere un forte affiatamento col compagno di lavoro, sono tutte cose che richiedono impegno, attenzione e disponibilità.

La voglia di isolamento spesso prende il sopravvento: a tutti piace mettere le cuffie e scrivere codice nel flow. Facendo così, si scrive codice che funziona ma magari non è testabile, manutenibile o pulito.

E l’intelligenza artificiale?

Queste difficoltà non ci fanno però abbandonare del tutto l’idea di fare pair programming e oggi vogliamo infatti provare a sperimentare come si possa farlo in compagnia dell’intelligenza artificiale e non con una persona reale.

Sappiamo però che un programma non può scrivere un programma, e quindi come può funzionare? Cominciamo co lo stabilire i ruoli: la persona è il navigator, colui che ha presente le intenzioni e la big picture, mentre il driver è impersonato dall’Intelligenza Artificiale.

La persona espone la sua intenzione: “Mi aspetto di passare a B i soli record che soddisfano la seguente condizione”. L’AI “sa” cosa vuol dire “passare” e “soddisfare la condizione” e quindi sa applicare probabilmente un filtro, lo implementa e chiede l’OK per proseguire.

Qualcosa di questo processo potrebbe essere considerato come un ciclo di apprendimento da parte dell’AI? Da un certo punto di vista il programmatore non va a descrivere come deve essere scritto il codice, ma solo quali risultati vuole ottenere da questo codice; l’AI, opportunamente addestrata, può fornire possibili implementazioni per una determinata intenzione. Più l’intenzione è scritta in modo formale, più è efficace, e a quel punto c’è l’OK di verifica in cui l’intelligenza artificiale chiede: “Funziona?”

 

Quindi? AITDD

Mettere insieme AI e TDD significa creare un processo iterativo in cui è fondamentale anche l’aspetto dell’apprendimento.

  1. Scrivo un test in modo formale.
  2. Chiedo alla mia AI di implementare qualcosa che soddisfi il test.
  3. Verifico che il codice implementato effettivamente soddisfi il test; se non lo soddisfa, implemento io come umano il pezzo di codice oppure lo correggo per dare un rafforzativo alla mia AI che impara così a classificare meglio.
  4. Insieme possiamo fare refactoring fino quando il codice è pulito.
Figura 4 – AITDD: Test Driven Development con Intelligenza Artificiale.
Figura 4 – AITDD: Test Driven Development con Intelligenza Artificiale.

 

Ora vi starete chiedendo se esista già qualcosa di simile. La risposta è: “non ancora”; ma sarebbe molto interessante perché ci farebbe fare il lavoro puro: quello di esprimere e definire l’intenzione dei componenti software e delegare la scrittura di pezzi di codice che a volte sono banali a un’intelligenza artificiale.

 

Conclusioni

Abbiamo visto in questo articolo un’ipotesi di lavoro in cui le pratiche del pair programming e del TDD vengono combinate con l’ausilio di una applicazione di intelligenza artificiale che assume il ruolo di driver nella coppia di programmatori. Se è vero che una tale soluzione al momento non è ancora implementata, nel prossimo articolo vedremo però qualcosa di più “concreto” che potrà risultare interessante per molti lettori.

 

 

L'articolo Fare pair programming con l’intelligenza artificiale proviene da MokaByte.

]]>
Un sistema di monitoraggio del traffico veicolare “in tempo reale” https://www.mokabyte.it/2022/07/11/rtrafficmonitoring-6/ Sun, 10 Jul 2022 22:06:15 +0000 https://www.mokabyte.it/?p=8892 Introduzione In questa sesta parte si conclude la descrizione dell’implementazione del modulo applicativo di Data Ingestion & Computing. Verranno presentati i dettagli di data processing Spark e di persistenza su Cassandra. Esecuzione delle attività di data processing e di persistenza su Cassandra Nella parte precedente sono stati descritti i passi che portano alla definizione del… Continua a leggere Un sistema di monitoraggio del traffico veicolare “in tempo reale”

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
Introduzione

In questa sesta parte si conclude la descrizione dell’implementazione del modulo applicativo di Data Ingestion & Computing. Verranno presentati i dettagli di data processing Spark e di persistenza su Cassandra.

Esecuzione delle attività di data processing e di persistenza su Cassandra

Nella parte precedente sono stati descritti i passi che portano alla definizione del JavaDStream da utilizzare per eseguire le attività di data processing. Su quest’ultimo, ogni iterazione del batch esegue i metodi statici della classe che implementa i calcoli di traffico totale, quelli basati sulla finestra temporale definita e quelli di monitoraggio di uno specifico POI (Point of Interest). Il batch si conclude con la persistenza di questi risultati su Cassandra.

La computazione di streaming viene avviata e interrotta utilizzando rispettivamente i metodi context.start() e context.stop(). Il metodo context.awaitTermination() permette al thread corrente di attendere il termine di un contesto di streaming, causato da un’istruzione context.stop() o da una eccezione. Di seguito le istruzioni Java utilizzate in questo caso.

Calcolo dei dati di traffico e persistenza su Cassandra

Questo metodo statico esegue le trasformazioni necessarie per ottenere un JavaDStream di tipo ChiaveAggregata, costituito dal numero di veicoli raggruppati per tipo e per direttrice stradale di rilevazione. Questo risultato si ottiene applicando in sequenza i metodi mapToPair e ReduceByKey al DStream precedentemente persistito in memoria. A ques’ultimo JavaDStream viene quindi applicato il metodo mapWithState che imposta un timeout di conservazione dello stato. L’ultima operazione consiste nella persistenza di quest’ultimo DStream su Cassandra.

 

Di seguito viene riportato il codice relativo alla chiave aggregata.

 

Ecco poi la codifica della funzioneDatiTrafficoTotale

 

E infine la codifica della funzioneCalcoloTotale

Computazioni su finestre temporali

Attraverso l’applicazione su un DStream del metodo reduceByKeyAndWindow, Spark Streaming supporta i calcoli sui dati acquisiti all’interno di finestre temporali, come illustrato dalla figura 1.

Figura 1 – Finestra temporale di dati.
Figura 1 – Finestra temporale di dati.

 

Questa funzione permette di unire gli RDD che rientrano nella finestra temporale che scorre su una sorgente DStream. Nell’esempio riportato in figura 1, lo slittamento temporale applicato su due unità temporali di dati (“RDD tempo 3” – “RDD tempo 5”) determina un’operazione di unione applicata alle ultime tre unità di tempo. Ne deriva che, per tutte le operazioni di questo tipo, è necessario specificare due parametri: l’ampiezza della finestra e l’intervallo di scorrimento. Questi parametri devono essere multipli dell’intervallo del batch di origine.

Di seguito il fragment di implementazione del metodo reduceByKeyAndWindow che permetterà di calcolare il numero di veicoli all’interno di finestre temporali con ampiezza e slittamento di trenta e dieci secondi rispettivamente. In altre parole sarà possibile visualizzare il traffico totale osservato nei trenta secondi precedenti a intervalli di dieci secondi.

 

Nel dettaglio sul JavaDStream in cache, di tipo IoTData, vengono applicati in sequenza i metodi mapToPair (necessario a filtrare per idStrada e tipoVeicolo) e reduceByKeyAndWindow ottenendo così un nuovo DStream con chiave di aggregazione idStrada e tipoVeicolo sulla finestra temporale corrente.

Per agevolare la lettura, non viene riportata la codifica di trasformazione in DStream di questo ultimo JavaPairDStream, implementazione necessaria alle operazioni di persistenza delle informazioni su Cassandra. Il lettore potrà fare riferimento a quanto riportato nel paragrafo precedente.

Rilevazione dei veicoli in prossimità di un Point of Interest

Di seguito la codifica della funzione che permette la rilevazione dei veicoli presenti nel raggio di un Point of Interest calcolandone anche la distanza da quest’ultimo.

 

Analogamente a quanto indicato nel paragrafo precedente, al fine di agevolare la lettura non viene riportata la codifica necessaria alle operazioni di persistenza su Cassandra, rimandando il lettore ai paragrafi precedenti.

Ed ecco infine il codice che implementa il calcolo della distanza dal POI di ciascun veicolo rilevato nel raggio stabilito.

 

Conclusioni

In questa sesta parte sono stati completati i dettagli di implementazione del componente applicativo di Data Ingestion & Computing, relativi all’applicazione delle funzioni di calcolo e persistenza su Cassandra, necessarie a soddisfare i requisiti di monitoraggio. Nella prossima parte verrà presentato l’ultimo componente applicativo, la dashboard di visualizzazione.

 

Riferimenti

Socks

socks-client

https://github.com/sockjs/sockjs-client

 

Kafka

https://kafka.apache.org/quickstart

https://www.slideshare.net/mumrah/kafka-talk-tri-hug?next_slideshow=1

https://www.youtube.com/watch?v=U4y2R3v9tlY

https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

 

Spark

https://spark.apache.org/docs/latest/index.html

https://data-flair.training/blogs/spark-rdd-tutorial/

https://data-flair.training/blogs/apache-spark-rdd-features/

 

Spark e Cassandra data connector

https://www.datastax.com/dev/blog/accessing-cassandra-from-spark-in-java

 

Zookeeper

https://www.youtube.com/watch?v=gifeThkqHjg

https://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper

 

Kafka e Zookeeper

https://www.youtube.com/watch?v=SxHsnNYxcww

 

Price Waterhouse and Cooper  “The Bright Future of Connected Carshttps://carrealtime.com/all/pwc-the-bright-future-of-connected-cars/

 

Hadoop

https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

 

Spark

https://www.infoq.com/articles/apache-spark-introduction/?utm_source=apachesparkseries&utm_medium=link&utm_campaign=internal

 

RDD

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf

 

WebSocket

http://jmesnil.net/stomp-websocket/doc/

 

Stomp

https://stomp-js.github.io/guide/stompjs/rx-stomp/ng2-stompjs/using-stomp-with-sockjs.html

 

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
WebAssembly, uno standard web per il presente e per il futuro https://www.mokabyte.it/2022/07/11/webassembly-1/ Sun, 10 Jul 2022 22:05:23 +0000 https://www.mokabyte.it/?p=8884 Introduzione WebAssembly, meglio conosciuto come Wasm, è certamente uno degli argomenti che ultimamante interessano maggiormente noi sviluppatori. Ma esattamente, di cosa si tratta? La prima definizione, e forse la più semplice, arriva direttamente dal consorzio W3C: The mission of the WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing… Continua a leggere WebAssembly, uno standard web per il presente e per il futuro

L'articolo WebAssembly, uno standard web per il presente e per il futuro proviene da MokaByte.

]]>
Introduzione

WebAssembly, meglio conosciuto come Wasm, è certamente uno degli argomenti che ultimamante interessano maggiormente noi sviluppatori. Ma esattamente, di cosa si tratta?

La prima definizione, e forse la più semplice, arriva direttamente dal consorzio W3C:

The mission of the WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.

Possiamo pertanto pensare a WebAssembly come a un formato bytecode standardizzato per l’esecuzione di programmi. Magari indaghiamo un pò più a fondo.

Tra linguaggi compilati, interpretati e bytecode

Ci sono programmi che vengono eseguiti soltanto con l’ausilio, o l’assistenza, di un Sistema Operativo. Possiamo citare C, C++, Go, Rust e altri che probabilmente nemmeno conosco; tutti questi linguaggi, una volta compilati, generano un file binario eseguibile direttamente sul Sistema Operativo che li ospita.

Esistono altri tipi di programmi, scritti con linguaggi di scripting, il cui codice viene letto, interpretato ed eseguito in successione. Tutti noi abbiamo scritto qualche riga in JavaScript, ma ci sono pure Python, PHP, Perl, Ruby e, anche in questo caso, altri che non conosco.

Infine, esistono programmi compilati in un formato intermedio, un bytecode, che per essere eseguiti richiedono la presenza di un strato speciale, un runtime, o una macchina virtuale. I più conosciuti, almeno per me, sono C#, che viene eseguito dal CRL (Common Language Runtime), così come tutti i linguaggi .NET, e linguaggio Java, che richiede la presenza della JVM (Java Virtual Machine).

Figura 1 – WebAssembly può rappresentare davvero la chiave per un web più veloce.
Figura 1 – WebAssembly può rappresentare davvero la chiave per un web più veloce.

 

E WebAssembly? A quale famiglia appartiene? WebAssembly è un formato bytecode, come C# e Java, ma che può essere eseguito da qualsiasi runtime compatibile con WebAssembly. Apparentemente, dunque, nulla di nuovo all’orizzonte, ma sono alcune particolari caratteristiche a renderlo interessante. Vediamo quali; ma soprattutto vediamo di capire come si è evoluta la storia di WebAssembly.

 

WebAssembly e i browser

Se è vero che WebAssembly è un formato bytecode che può essere eseguito da un qualsiasi runtime compatibile, allora bisogna capire dove risiedono questi runtime compatibili.

L’idea originale era proprio quella che tutti i principali browser web avessero questo runtime incorporato. Mentre scrivo questo, mi viene in mente un ricordo di molti anni fa alla Web Conference in Bicocca: un talk di Scott Hanselman, che diceva che il JavaScript era destinato a diventare l’Assembler del futuro. WebAssembly non è JavaScript, ma come al solito, Hanselman non è caduto lontano dall’albero. Ma perchè nei browser? Un post di Luke Wagner, creatore di WebAssembly, ci da una prima risposta:

WebAssembly defines a portable, size and load-time-efficient format and execution model specifically designed to serve as a compilation target for the web.

Partendo da questo assunto la speranza era che tutti i compilatori dei più diffusi linguaggi di programmazione — C, C++, Go, Ruby, Rust — avrebbero generato bytecode Wasm in grado di essere recuperato ed eseguito nel browser come un normale programma.

La prospettiva, se così la vogliamo chiamare, era che WebAssembly si sarebbe sbarazzato di JavaScript e si sarebbe proposto come il futuro dei già blasonati, e poi superati, applet Java, Flash, Silverlight, etc. Ma, inspiegabilmente, tutto questo non è successo, e col senno di poi, possiamo aggiungere, fortunatamente.

 

WebAssembly oltre i browser

Quella che poteva essere interpretata come una sconfitta, in realtà si è dimostrata la vera vittoria di WebAssembly. Possiamo trovare la ragione di tutto questo nelle caratteristiche di questo formato dettate proprio dall’ambiente dei browser. Vediamole di seguito.

Strong Security

La forte sicurezza è una caratteristica dettata proprio dall’ambiente a cui WebAssembly è destinato. Non possiamo fidarci di chiunque voglia far girare un applicativo all’interno del nostro browser.

Small binary sizes

Il terzo punto delle Fallacies of Distributed Computing ci ricorda proprio che la banda non è infinita, quindi bisogna limitare le dimensioni dei file.

Fast loading and running

Ormai lo sanno anche i muri che le applicazioni web devono essere veloci e reattive. Gli utenti si annoiano velocemente se i tempi di caricamento e funzionamento sono troppo lenti.

Support for many operating systems and architectures

Il tempo di Windows con processore Intel, o MacOS con M1 sono finiti. O meglio, ora gli utenti hanno a dispozione, oltre a questi, diversi altri tipi di dispositivi, ed è fondamentale che un applicativo sia in grado di girare su sistemi operativi differenziati e su architetture diversificate.

Interoperability with the browser

Da soli si perde! Va bene che il formato WebAssembly è in grado di girare nel browser, ma per essere appetibile deve essere in grado di interagire con l’HTML, il CSS e ovviamente, con JavaScript.

 

Queste caratteristiche, fortemente incentrate sulla connettività, hanno reso WebAssembly sicuramente interessante per il browser, ma non solo.

 

WebAssembly e il cloud

Molto tempo fa partecipai allo sviluppo del primo portale web per l’acquisto e la vendita di quote fondi in Italia per clienti istituzionali. In pratica un eCommerce per banche e istituti di gestione patrimoniale. Ricordo benissimo la sala server e il “misticismo” che girava attorno ad essa. Tutto, e ripeto tutto, era ridondato. Dai server alle linee telefoniche. Un tale investimento potevano permetterselo, appunto, banche o istituzioni simili. Poi, un bel giorno, Amazon ha deciso di recuperare un pò di perdite offrendo al mondo la potenza di calcolo dei propri datacenter. Il cloud, così come lo conosciamo, era nato!

Oggi i cloud provider sono diversi e non è più necessario avere una batteria di server nel sottoscala per distribuire applicazioni in rete: i costi sono accessibil più o meno a tutti, ma questo è discorso per un altro articolo. Però attenzione, i costi non sono spariti, e il guadagno dei grossi cloud provider sta proprio nel ridurre il più possibile i costi di gestione delle loro enormi infrastrutture.

Quando distribuiamo i nostri applicativi tramite Cloud ci aspettiamo principalmente sicurezza e costi ridotti. Il primo aspetto dipende in gran parte dal fornitore, e dalle scelte che noi andiamo a fare nel momento della configurazione del servizio, il secondo invece è un pò un mix di responsabilità, ma in ogni caso in gran parte riconducibili alla dimensioni dei file necessari al funzionamento del nostro applicativo.

Lo abbiamo ricordato prima, la banda non è infinita, e soprattutto non è gratuita. Lato fornitore poi ci possiamo aggiungere il fatto che non è cosa semplice dover supportare soluzioni scritte per diversi sistemi operativi e con tecnologie diverse: una certa uniformità non farebbe certo male. Insomma, ci sono diversi aspetti da considerare, alcuni già visti, altri nuovi, che potremmo riassumere in questo elenco

  • Strong Security
  • Small binary sizes
  • Fast loading and running
  • Support for many OSes and Architectures
  • Interoperability with Cloud Services

Ops… ma non le avevamo già viste poco sopra?

L’arrivo di Docker e Kubernetes

Certamente, quando Amazon ha messo a disposizione i suoi datacenter, tutte queste caratteristiche non erano rispettate; in fondo ciò che aveva fatto era stato condividere delle macchine virtuali con il mondo, e forzatamente, dimensioni e caratteristiche di queste ultime dovevano essere ridotte.

Docker ha cambiato completamente le regole del gioco: insieme a Kubernetes ha reso le nostre soluzioni scalabili e anche un pò più semplici da distribuire. Non parleremmo oggi di microservizi se non avessimo Docker a supportarci.

Pochi anni dopo Docker è apparso WebAssembly, forte delle caratteristiche viste sopra che, guarda caso, sono proprio quelle richieste dal cloud. WebAssembly sembra proprio perfetto per creare soluzioni leggere, facilmente distribuibili, sicure e interconnesse da distribuire nel cloud. Non sostituisce, almeno per ora, i container, così come i container non hanno sostituito le macchine virtuali; ma si presenta come soluzione alternativa e complementare.

 

WebAssembly e il resto dei linguaggi

Vediamo di entrare un pò nei dettagli tecnici di WebAssembly. Tanto per essere originali i primi linguaggi ad essere presi in considerazione e considerati “ideali per WebAssembly” sono stati “i soliti noti”, C e C++, che sono alla base di gran parte dell’informatica di oggi. Accanto a questi due candidati però si è fatto strada anche Rust, per lo più per il fatto che produce file eseguibili di ridotte dimensioni, veloci e ha una gestione sicura della memoria.

Bisogna ricordare che Mozilla, una delle grandi organizzazioni dietro al mondo WebAssembly, ha investito molto in Rust e l’unione dei due ecosistemi, Rust e WebAssembly, ne ha tratto giovamento. Ad oggi, Rust è probabilmente il miglior sistema host non browser per WebAssembly, e anche il miglior linguaggio di compilazione con notevoli strumenti per gli sviluppatori.

Figura 2 – WebAssembly è veloce, aperto, sicuro e in grado di dialogare con i più diffusi linguaggi.
Figura 2 – WebAssembly è veloce, aperto, sicuro e in grado di dialogare con i più diffusi linguaggi.

 

In tempi più vicini ai nostri sono apparsi sulla scena altri linguaggi, inspirati più o meno a quelli nati per il mondo web. AssemblyScript è inspirato proprio a TypeScript, ma progettato proprio per la compilazione in WebAssembly. Per chi come me è più vicino al mondo .NET, con la versione 7.0, in arrivo questo autunno, dovrebbe trovare novità sulla compilazione delle applicazioni Blazor Wasm direttamente in WebAssembly, saltando l’interpretazione del CLR, ma anche Go, Swift e altri si stanno accodando a questo trend. Kotlin sta lavorando a questo supporto, Python e Ruby si sono uniti recentemente, e via via altri linguaggi sino ad arrivare a COBOL! Insomma, WebAssembly sta veramente catturando l’attenzione di tutti.

Come nelle favole con il lieto fine, il linguaggio che forse meno ci si aspettava nell’ecosistema di WebAssembly si è dimostrato JavaScript. Proprio quello che, soprattutto all’inizio, in molti davano per quello che WebAssembly stesso avrebbe finito per sostituire. Il realtà al termine del 2021 il motore che alimenta Mozilla FireFox, JavaScript SpiderMonkey, ha rilasciato una versione con compilazione in WebAssembly, e improvvisamente il linguaggio che doveva essere soppiantato si è trovato ad essere parte dello stesso ecosistema.

Finita, per ora, la carrellata sui linguaggi che si stanno accodando a WebAssembly ci resta un’ultima nota prima di concludere. Vi starete chiedendo come sia possibile eseguire WebAssembly in così tanti dispositivi, Sistemi Operativi e ambienti diversi, cloud incluso. Tutti questi sistemi hanno bisogno di un sistema per esporre le caratteristiche dell’host al modulo WebAssembly, e per capire di cosa si tratta dobbiamo presentare WASI (WebAssembly System Interface).

 

WASI (WebAssembly System Interface)

Molti progetti sono nati con grandi ambizioni, e poi sono finiti nel nulla. WASI è nato come progetto ambizioso, ma poi … è andato ben oltre le più rosee aspettative.

Figura 3 – Il futuro di WebAssembly System Interface al momento appare ricco di sviluppi.
Figura 3 – Il futuro di WebAssembly System Interface al momento appare ricco di sviluppi.

 

L’idea iniziale era quella di creare uno strato fra il file binario WebAssembly ed il Sistema Operativo, un host tecnicamente parlando, in grado di fornire tutto il necessario al programma Wasm per funzionare. Il programma viene scritto normalmente, con tutte le sue funzionalità rispetto al file system, alle connessioni di rete e alla lettura delle variabili d’ambiente. Ma, anzichè dialogare direttamente con il Sistema Operativo, tutte le chiamate vengono passate all’host che fa da garante. Ogni connessione di rete potrebbe essere bloccata se ritenuta pericolosa, perchè l’host, nel progetto iniziale, era libero di aggiungere i livelli di sicurezza più severi.

Già detto così il progetto appare ambizioso, ma ad un certo punto il piano iniziale è cambiato. I progettisti di WASI hanno pensato che una libreria standard non era esattamente quello che volevano. Allora hanno optato per una soluzione in cui un modulo WebAssembly ospite potesse richiedere un filesystem, o un database, o ancora, una connessione di rete e l’ambiente host potesse soddisfare tutte queste richieste, rispettando le regole di affidabilità, sicurezza e prestazioni che si erano posti all’inizio.

Ad oggi WASI è ancora in evoluzione, ma già si possono vedere i risultati; stanno nascendo famiglie di prodotti che sfruttano appieno queste peculiarità: la versione Wasm di Blazor in .NET 7.0 sembra propio essere uno di questi prodotti. Non importa quanto tempo ci vorrà per completare il progetto, perchè quello che conta è che stà accadendo ora.

 

Conclusioni

Abbiamo passato in rassegna alcune delle tematiche principali che riguardano WebAssembly. Nel prossimo articolo approfondiremo il discorso relativo al rapporto tra Wasm e i container.

 

Riferimenti

Fallacies of distributed computing

https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing

 

L'articolo WebAssembly, uno standard web per il presente e per il futuro proviene da MokaByte.

]]>
Cos’è che fa di un DevOps un DevOps? https://www.mokabyte.it/2022/07/10/devopsok/ https://www.mokabyte.it/2022/07/10/devopsok/#respond Sun, 10 Jul 2022 21:37:14 +0000 https://www.mokabyte.it/?p=8880 Abbiamo letto ottimi articoli su quali debbano essere le caratteristiche e le competenze di uno sviluppatore, o di un architetto dei sistemi, o di un coach agile. Ma che cosa costituisce il nucleo essenziale delle competenze di un professionista che si occupi di DevOps?

L'articolo Cos’è che fa di un DevOps un DevOps? proviene da MokaByte.

]]>
DevOps: tentare una definizione

Negli ultimi anni le pratiche DevOps si sono diffuse causando una “rivoluzione gentile” nell’ambito dello sviluppo e della gestione del software. Le tecnologie, gli strumenti, le pratiche connesse all’area DevOps non sono più materia esoterica per pochi interessati, ma sono note, almeno a grandi linee, a coloro che devono occuparsi seriamente dell’IT nelle aziende.

I risultati e i miglioramenti tangibili apportati da tale approccio, che è anzitutto metodologico, prima ancora che tecnologico, sono stati sicuramente la ragione migliore per convincere certi scettici.

Parafrasando uno dei film culto degli anni Novanta (“Cos’è… cos’è; che fa di un uomo un uomo, signor Lebowski?”) vorrei parlare dei principi base per definire i caratteri distintivi dell’area DevOps, le caratteristiche e le competenze che deve possedere un professionista che operi in quest’area. In breve “Cos’è che fa di un DevOps un DevOps, signor Lebowski?”.

Cercherò di concentrarmi su alcuni dei principi che negli ultmi cinque anni ho potuto assimilare nell’ambito del mio cammino professionale e riassumerò una serie di riflessioni in alcuni paragrafi, senza pretesa di concludere con questo elenco la discussione, ma solo come stimolo per la riflessione e un miglioramento continuo. Quindi, quali sono le caratteristiche di un buon DevOps?

 

Essere una BaaS (Buzzword as a Service)

Diciamolo subito: gli ambiti innovativi forniscono tanti stereotipi ed esagerazioni quando ci si trovi a cavallo tra vera innovazione e buzzword sopravvalutata. All’inizio DevOps era sicuramente una buzzword, ma ora non lo è più. O meglio, può esserlo ancora per chi legge solo i blog o scorre distrattamente i tweet.

Ma non è una buzzword se si sono toccati con mano i benefici e i risultati di questo approccio. Nei contesti dove c’è stata una vera rivoluzione, la parola “DevOps” descrive perfettamente figure professionali che svolgono attività di collegamento tra i gruppi di sviluppo e le operation. Queste attività si individuano nella forma di integrazioni di sistemi, sviluppo di piccoli tool e… pubbliche relazioni perché spesso danno supporto agli altri.

I Devops seguono tutta la catena di montaggio partendo dal codice fino al delivery e monitoring delle applicazioni. Sono sistemisti che scrivono del buon codice, o programmatori che si muovono agili sulla shell. Giocano con molte tecnologie e spesso fanno “ricerca” nel senso che devono trovare la soluzione tecnica più giusta e adatta andandosela a cercare perché, non è già preconfezionata, scoprendo così quanto è in grado di risolvere la situazione.

 

Stare attenti a quando si dice “Alla vecchia maniera”

Nell’IT non è previsto l’utilizzo di espressioni quali “Ai miei tempi” o “Come si faceva un tempo”. Un paio di scarpe — o un altro prodotto artigianale — fatto alla vecchia maniera è resistente e di qualità, ma un sistema fatto così, pur essendo stabile, verrebbe inevitabilmente visto come “anziano”. Saggio, magari, in quanto anziano; ma con la barba bianca e lunga al posto dei baffetti hipster…

Anche qui occorre trovare un equilibrio tra innovazione per il solo gusto di “fare qualcosa di nuovo” e reale necessità di adottare nuove soluzioni. Di fatto, nel mondo IT, ogni anno assitiamo all’avvento di nuove tecnologie — software e hardware — e di nuove metodologie.

Figura 1 – Strumenti come Bash non perdono la loro validità e la loro potenza. Ma non possono essere la base per una struttura DevOps moderna e affidabile.
Figura 1 – Strumenti come Bash non perdono la loro validità e la loro potenza. Ma non possono essere la base per una struttura DevOps moderna e affidabile.

 

Molte delle cose fatte un tempo funzionano egregiamente anche oggi e comunque le usiamo volentieri: “Bash Rocks!”. Ma è innegabile che sistemi costruiti come quelli di dieci anni fa appaiono superati e soprattutto non invogliano l’organizzazione a perseguire una strada come quella di DevOps. Insomma, per molti il nuovo ha un valore, di per sé. Non entro nel merito della correttezza di tale giudizio, ma è innegabile che in molti contesti ciò accade.

E a volte il cambiamento è fortemente consigliato. Ad esempio, non è possibile sostituire un configuration management tool come Chef o Puppet con dello shell scripting. Concetti come idempotenza e auto-discovery richiedono comunque un effort nella loro realizzazione. È meglio quindi usare strumenti supportati da una community, piuttosto che scrivere componenti, per quanto validi, di cui poche persone mantengono la memoria storica.

 

Essere preparato su Git

Non può mancare una conoscenza approfondita di Git. Servirà quando uno sviluppatore ti chiederà aiuto o quando prenderai in giro il tuo amico perchè lavora dove ancora distribuiscono il codice e le nuove release su aeroplanini di carta: sull’ala destra c’è il messaggio di commit e su quella sinistra la versione; se l’aeroplanino ritorna indietro per via di forti correnti contrarie, hai fatto rollback…

Figura 2 – Git è uno strumento fondamentale nel panorama attuale dello sviluppo e quindi anche del DevOps. Fin troppo, a giudicare dall’immagine…
Figura 2 – Git è uno strumento fondamentale nel panorama attuale dello sviluppo e quindi anche del DevOps. Fin troppo, a giudicare dall’immagine…

 

Il pattern di “Infrastructure as Code” non può mancare, e quindi serve “versionare”. È importante sapere che lavoriamo in un ambiente deterministico e che possiamo pilotare piattaforme tramite codice.

Questo significa anche salutare la documentazione tradizionale: si legga il playbook di Ansible o il cookbook Chef per rendersene conto. Chiaramente, stiamo parlando di uno scenario perfetto… Il “documentone” verrà sempre chiesto; però devo anche dire che negli ultimi tempi sono riuscito più volte a tovare un dignitoso compromesso per cui anche un bel markdown fatto bene può bastare.

Ho imparato che tutto il lavoro svolto deve essere portabile. Un modulo Puppet o un cookbook Chef deve essere chiaro e leggibile. Sembra scontato ma non lo è. Spesso automatismi e meccanismi agili all’interno delle nostre infrastrutture risiedono solo nella nostra conoscenza: quelle infrastrutture le abbiamo sviluppate noi e ci risultanto pertanto familiari. Tutto ciò è poco DevOps, perchè diventa comunque un silos: un “agile silos” ma sempre un silos…

 

Scegliere i tool con senso critico

Il panorama dei tool DevOps è davvero ampio ed è costellato però anche di programmi che fanno la stessa cosa e che competono a suon di stellette su github e loghi accattivanti. Alcuni di essi sono veramente utili ed è gratificante contribuire alle community che li sostengono; altri vengono proposti in conversazioni di gruppo a tema “spariamo a nomi a caso” solo per fare la figura di quello che conosce tutte le novità. Ne nasce una sorta di cyber “flusso di coscienza” del tipo: “kubernetes! Prometheus! Openshift! Spark! Mesos! Puppy Linux!”…

Figura 3 – Il panorama dei tool per DevOps è andato ampliandosi in maniera significativa negli ultimi anni, tanto che c’è chi ha cercato di classificarli in maniera strutturata. Questo schema, messo a punto da XebiaLabs, imita la tavola periodica degli elementi chimici.
Figura 3 – Il panorama dei tool per DevOps è andato ampliandosi in maniera significativa negli ultimi anni, tanto che c’è chi ha cercato di classificarli in maniera strutturata. Questo schema, messo a punto da XebiaLabs, imita la tavola periodica degli elementi chimici.

 

Ma nel concreto, come fa un DevOps a scegliere i tool da usare, tra i molti prodotti open source presenti in questo panorama?

Occorre giudizio e misura, il che porta a evitare di giudicare solo in base alla popolarità. La popolarità ha sicuramente delle ragioni e una base, ma non deve essere l’unico criterio su cui basare l’adozione di un tool. Se tale software viene utilizzato estensivamente e, contemporaneamente, lo si reputa mediocre, si dovrebbe contribuire con ciò che pensiamo possa portare un miglioramento, nell’ottica del paradigma dell’open source.

L’open source del resto è un qualcosa di tutti e potrebbe in un futuro prossimo diventare un “bene comune”. Forse il paragone è esagerato, ma migliorare il software contruibuendo alla comunità che lo sviluppa e mantiene equivale a pulire una strada per il bene della comunità che la abita. Hai la necessità di percorrerla e devi impegnarti a renderla vivibile: se ti limiti a imprecare, non stai facendo nulla per migliorarla.

 

Condividere la conoscenza, abbattere i silos e fare team

Assolutamente sì. Sono punti fondamentali: senza questi tre elementi probabilmente il lavoro del DevOps sarebbe molto noioso.

La condivisione di conoscenza stimola la crescita di tutti coloro che partecipano al processo, facilita lo svolgimento delle operazioni, migliora la qualità delle soluzioni che si adottano. Detenere l’ownership di una procedura noiosa e complicata non è un gran valore, da custodire gelosamente… anzi, finisce per far perdere valore al tempo lavorativo che si impiega nel farla.

Intendo dire che, se ci è richiesto di intervenire solo perché noi e pochissimi altri “eletti” siamo in grado di eseguire una determinata procedura complicata, siamo distanti anni luce dalle metodologie DevOps. Non siamo noi i “proprietari” di quel tempo che impieghiamo a concludere il task perché qualcuno prima di noi ha deciso quanto sarebbe dovuto durare scrivendo passo passo un documento procedurale.

È compito di un Devops, a mio parere, arrivare al risultato scegliendo la soluzione più smart possibile. E in questo senso intendo che sia una soluzione efficace, efficiente, comprensibile, condivisa e facilmente modificabile/migliorabile. Per questo la condivisione della conoscenza nel team e l’abbattimento delle barriere fra dipartimenti sono valori importantissimi: non è questione di “siamo tutti più buoni”, ma è questione di “facciamo insieme le cose meglio, con soddisfazione da parte di tutti”.

Poi… che c’entra… al venerdì pomeriggio, ben venga pure il noioso, il ripetivo e il classicissimo “Se funziona non lo toccare!”. E, a questo punto, anche il “Eh vecchio mio, mi ricordo quando mettevamo il notepad in cluster…”. Ma sono eccezioni, perché DevOps è altro.

 

Conclusioni

L’abbiamo detto: non pretendiamo con queste brevi note di aver trattato esaustivamente il corpo delle competenze tecniche e attitudinali di un professionista che si muove nell’ambito DevOps. Ci piaceva però stimolare la riflessione e contribuire alla discussione con qualche considerazione maturata “nelle trincee”.

Le tecnologie e i tool si evolvono con una velocità notevole, a volte spiazzante. Ma l’approccio e la forma mentale di un DevOps sono elementi fondamentali e meno soggetti alla rapida obsolescenza di qualsiasi tecnologia.

 

L'articolo Cos’è che fa di un DevOps un DevOps? proviene da MokaByte.

]]>
https://www.mokabyte.it/2022/07/10/devopsok/feed/ 0
Quindici statistiche da conoscere per lavorare in UX design https://www.mokabyte.it/2022/07/10/uxstatistiche/ Sun, 10 Jul 2022 21:27:21 +0000 https://www.mokabyte.it/?p=8875 Nella moderna progettazione integrata di applicazioni e soluzioni digitali, il campo dell’UX design gioca un ruolo fondamentale in collaborazione con gli sviluppatori. Eppure spesso molti aspetti “pratici” di questo mestiere non sono così chiari.

L'articolo Quindici statistiche da conoscere per lavorare in UX design proviene da MokaByte.

]]>
L’articolo che qui leggete in traduzione è stato originariamente pubblicato su The CX Lead. un sito dedicato ai temi della Customer eXperience, che ci ha gentilmente concesso la ripubblicazione. Scopo di queste pagine è fornire una visione sul tema UX design da un punto di vista diverso dal nostro solito approccio. Emergono chiaramente alcune differenze tra il modo in cui le professioni legate allo UX design sono percepite da noi in Italia e nel mondo USA (anche se l’autore è britannico…). Già nel classico formato delle “enumerazioni”, tanto caro a blogger e giornalisti statunitensi, vi sono delle differenze, per non dire poi del modo in cui viene valutata la remunerazione o di quali siano le dimensioni delle aziende in cui si lavora. Tutti numeri su cui è possibile riflettere e fare le proprie considerazioni. Passiamo quindi a vedere queste quindici statistiche da tenere presenti se si vuol intraprendere una professione nell’ambito UX.

 

Quindici statistiche

Per chi stia prendendo in considerazione una carriera nelll’ambito dell’UX design, abbiamo raccolto 15 statistiche che forse vi interessa conoscere.

L’affermazione di Internet e dei social media ha spostato l’equilibrio di poteri prima quasi totalmente in mano ai produttori, facendolo pendere a favore dei consumatori. Le aziende rispondono a questo cambiamento creando esperienze positive in grado di soddisfare il cliente e farlo continuare ad acquistare.

Al centro degli sforzi per mantenere alta la soddisfazione del cliente sta la figura di chi progetta l’esperienza utente: lo UX designer. La Kent State University dell’Ohio ha affermato che “questo sarà il decennio della progettazione dell’esperienza utente” [2]. E va anche detto che, generalmente, la professione di progettista della User eXperience è ben remunerata.

Lo UX designer ha la responsabilità di accompagnare il comportamento dell’utente mentre questi interagisce con un prodotto o un servizio, e questo risultato viene raggiunto facendo sì che l’utente percepisca il prodotto come utile e facile da usare.

Per chi intenda intraprendere una carriera nell’ambito della progettazione dell’esperienza utente, vediamo una serie di statistiche per capire qualcosa di più sul ruolo e sulle prospettive lavorative per gli UX designer.

 

1. Cosa fanno gli UX designer nel loro tempo lavorativo?

Secondo un’indagine della Kent State University [2], il ruolo del progettista UX coinvolge tre aree chiave.

  • Scoperta, che consiste nell’identificazione dei pubblici a cui ci si rivolge, degli scenari utente e nell’analisi della concorrenza.
  • Ideazione, che riguarda il flusso del processo, le mappe dei siti, i wireframe e la progettazione vera e propria.
  • Prototipazione e test di usabilità, che include la prototipazione, ossia il rilascio di modelli testabili, i test di usabilità, e le revisioni del prodotto.

Facendo riferimento agli specifici progetti su cui si lavora, l’indagine mette in evidenza le quattro principali categorie su cui gli intervistati hanno dichiarato di aver lavorato nel corso della loro carriera:

  • Siti e applicazioni web: 94%
  • App mobile: 67%
  • Applicazioni enterprise: 60%
  • Applicazioni desktop: 54%

 

2. Esperienza media dello UX designer

Ogni anno, il sito UXtools.co, una risorsa gratuita per designer, aziende e studenti dell’ambito UX, effettua un’indagine sui tool per il design. Nel 2019 ha ricevuto 3149 risposte che hanno disegnato il seguente quadro sul panorama UX [3].

Secondo quanto emerso, la fetta più ampia dei professionisti UX aveva un’esperienza lavorativa di 3-5 anni (circa il 30%); il secondo gruppo più numeroso (circa il 25%) era rappresentato da chi aveva accumulato un’esperienza almeno decennale o ancor più estesa.

Tali numeri sembrano confermati da una ricerca del Nielsen Norman Group [4], poi, che aveva coinvolto 963 professionisti UX: da questa indagine emergeva che i professionisti UX con esperienza di 4-6 anni rappresentavano il gruppo più ampio (27%).

 

3. Le cinque competenze più richieste

La progettazione dell’esperienza utente UX si applica a quasi ogni settore industriale moderno. Pertanto, una volta che si sia in possesso delle fondamentali competenze richieste, non c’è limite alla crescita personale e professionale in questo campo.

Dando un sguardo al panorama per identificare le competenze necessarie per una buona riuscita nel campo dello UX design, abbiamo identificato quelle che seguono, come suggerito dall’azienda di software Adobe [5].

Sviluppo frontend

Sono pochi gli UX designer che sanno anche programmare, e quindi sono richiesti.

Progettazione di applicazioni vocali

L’ambito delle tecnologie basate sul riconoscimento della voce e del parlato è in grande espansione, e qui si aprono opportunità per quei progettisti UX in possesso di competenze utili alla progettazione di tale tipo di applicazioni.

Microcopywriting

Si tratta della scrittura dei brevissimi testi con i quali l’utente interagisce quando usa un prodotto. Non è una competenza molto diffusa tra gli UX designer.

Progettazione di interfacce utente (UI)

È necessaria una profonda comprensione del modo in cui gli utenti interagiranno con il design, il che implica andare oltre gli aspetti estetici per migliorare la funzionalità effettiva.

Comprensione dei dati

La capacità di leggere i dati risultanti aiuterà a determinare se il design che viene sviluppato soddisfa realmente le necessità dell’utente e, in caso negativo, permetterà di capire il modo in cui adottare un design migliore nelle successive iterazioni.

 

4. Stipendi medi dello UX designer

Tentare di definire lo “stipendio medio” di un designer UX è processo complicato, poiché le diverse fonti consultate utilizzano metodi diversi per cercare di arrivare a una risposta [6] [7]. Oltre a questo, il ruolo professionale di UX designer è relativamente nuovo, il che aggiunge ulteriore incertezza se si intende calcolare dei salari standard.

Ad ogni modo, a livello globale, il compenso medio annuale per un UX Designer risulta di circa 53000 dollari, con la Svizzera che paga circa 101000 $ e gil Stati Uniti che offrono una “paga base” annuale di circa 85000 $. (ndt: come confronto, il lettore italiano può guardare le cifre riportate nei riferimenti al [7] che sono significativamente più basse].

I dati di Glassdoor mostrano inoltre come ci sia discrepanza tra le diverse aziende, con alcune di queste che offrono stipendi sensibilmente più elevati: Apple, ad esempio, paga i suoi UX designer tra i 73000 e i 183000 dollari all’anno, Adobe sta nel range 66000-162000 $, mentre Google offre compensi annui tra i 77000 e i 173000 dollari.

Infine, il sito Skillcrush [8], il cui scopo è migliorare la qualità di vita dei propri studenti attraverso l’acquisizione di competenze digitali per poter affrontare carriere flessibili e ad elevato guadagno, colloca lo “stipendio medio” del progettista UX a circa 81000 $ all’anno, per neoassunti che abbiano fino a un anno di esperienza.

 

5. Compenso orario medio dello UX designer

Sempre più progetti vengono svolti da professionisti freelance e quindi anche vari UX designer potrebbero essere remunerati calcolando il numero di ore di impegno. Per il mercato statunitense, il sito di intermediazione domanda-offerta ZipRecruiter presenta il compenso orario medio per i 50 stati dell’Unione, con i valori più alti per lo stato di New York (ca. 52 $) e il più basso per il North Carolina (ca. 38 $).

 

6. Stipendio medio dello UX designer in base all’esperienza

Skillkrush [8] fornisce anche statistiche sullo stipendio annuale medio, basate sugli anni di esperienza.

  • Neoassunti: 75,000 –80,928 dollari (anni di esperienza: 0-1)
  • Livello intermedio: 90,000 –104,580 (anni di esperienza: 7-9)
  • Livello senior: 110,000 – 113, 368 (anni di esperienza > 15)

Con un’altra suddivisione, basata sul numero specifico di anni di esperienza [6] ecco una stima di quanto è possibile guadagnare negli Stati Uniti:

  • 0-3 anni: $ 76,996
  • 4-7 anni: $ 98,732
  • 8-12 anni: $ 112,203
  • 13+ anni: $ 123,447

Sempre nello stesso sito è possibile vedere le statistiche per le altre nazioni.

 

7. Le migliori cinque città USA in cui fare lo UX designer

JustInMind, un’azienda che produce tool multipiattaforma per il wireframing, ha stilato una classifica delle migliori città in cui svolgere la professione di UX / UI designer [9]. Non sorprende che l’area della Silicon Valley sia al primo posto con San Francisco.

  1. San Francisco, California
  2. Charlotte, North Carolina
  3. Austin, Texas
  4. New York
  5. Seattle, Washington

 

8. Dove si trova il maggior numero di UX designer nel mondo?

Non è impresa facile fonire delle cifre esatte relative alle aree con il maggior numero di UX designer nel mondo. Tuttavia, dall’indagine condotta nel 2019 [3], è possibile farsi un’idea. E le cinque nazioni con il maggior numero di UX designer che hanno risposto al sondaggio sono:

  1. Stati Uniti: 20.5%
  2. Canada: 4.22%
  3. Regno Unito: 4.22%
  4. Germania: 3.7%
  5. Francia: 2.5%

 

9. Richiesta attuale per UX designer

Per dare un’idea della richiesta di designer UX, il sito CareerFoundry [10] si è posta la domanda “Perché ci servono dei progettisti di UX?”, rispondendo che, a gennaio 2020, c’erano 1,74 miliardi di siti e più di 4 milioni di app mobili (contando iOS e Android). Potenzialmente, tutti questi siti e app necessitano delle competenze di un UX designer, in un modo o nell’altro.

Un altro articolo [11] mostra come ci sia una generale richiesta, a livello globale, di professionisti dell’UX.

 

10. Prospettive future sulle carriere nell’UX design

Prospettive di crescita del 3% annuale nelle richieste per industrial UX designer da qui fino al 2028 vengono stimate dallo US Bureau of Labor Statistics [12] mentre CNN Money prevedeva addirittura una crescita annuale del 18% nei dieci anni cominciati con il 2015 [13].

 

11. Dimensioni delle aziende che assumono UX designer

Per farsi un’idea sulle dimensioni delle aziende — in numero di impiegati — che cercano UX designer, abbiamo fatto ancora riferimento al portale Glassdoor [7]. Di seguito viene messa in relazione la categoria dimensionale delle aziende e la suddivisione percentuale delle richieste di ruoli UX (dati del 3 giugno 2020).

  • 0–50 addetti: 23%
  • 51 to 200 addetti: 4%
  • 201 to 500 addetti: 16%
  • 501 to 1000 addetti: 12%
  • 1001 to 5000 addetti: 10%
  • 5001 to 10000 addetti: 6%
  • > 10000 addetti: 26%

Per quanto i dati riportati qui sopra facciano riferimento a un periodo specifico, è interessante notare che le offerte di lavoro come UX designer si collocano principalmente nelle aziende più piccole e più grandi.

 

12. Numero medio di personale UX nelle aziende

Una ricerca [14] sul comparto dello UX design condotta nel 2019 da InVision — importante piattaforma di prototipazione, collaborazione e gestione del flusso di lavoro — ha concluso che il numero di designer nelle aziende è 27.

 

13. Livello di formazione richiesto agli UX designer

GetEducated che si occupa di formazione online, consiglia che, come livello minimo, allo UX designer servirà una qualifica biennale post-diploma, mentre alcuni di loro saranno in possesso di master o titoli ancor più elevati [15].

 

14. I cinque tool di progettazione più usati dagli UX designer

Ecco i tool più usati dagli UX designers, secondo quanto appreso dall’indagine del 2019 [3]:

  • Sketch: 23%
  • Figma: 19%
  • Abstract: 10%
  • Storybook: 5%
  • Craft: 4%
  • Altro: 39%

 

15. Ruoli manageriali ricoperti nelle aziende

Sempre l’indagine condotta da InVision [4] mostrava come alcuni designer UX rivestissero ruoli di management di alto livello. Quasi il 30% delle aziende intervistate aveva un UX designer in un ruolo di direttore, il 23% a un livello manageriale, mentre il 7% aveva un UX designer come vicepresidente.

 

Conclusioni

NdT: Le cifre che avete letto sono volutamente riferite principalmente al mondo statunitense, dove il ruolo di UX designer è meglio identificato, maggiormente riconosciuto e anche più lautamente remunerato. Ma ciò è stato fatto anzitutto nell’ottica di suscitare riflessioni sui punti di contatto e sulle discrepanze, guardando anche al panorama nazionale e, più ampiamente, europeo, in cui numerosi e capaci professionisti operano.

 

L'articolo Quindici statistiche da conoscere per lavorare in UX design proviene da MokaByte.

]]>
Un sistema di monitoraggio del traffico veicolare “in tempo reale” https://www.mokabyte.it/2022/06/06/rttrafficmonitoring-5/ Mon, 06 Jun 2022 20:50:09 +0000 https://test.mokabyte.it/?p=8808 Introduzione In questa quinta parte proseguiamo la descrizione della soluzione di monitoraggio real time presentando i dettagli di implementazione del secondo modulo applicativo, quello di Data Ingestion & Computing, realizzato da una libreria Java, eseguita da Spark ad ogni iterazione del batch.   Componente di Data Ingestion & Computing Questo componente applicativo implementa, per mezzo… Continua a leggere Un sistema di monitoraggio del traffico veicolare “in tempo reale”

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
Introduzione

In questa quinta parte proseguiamo la descrizione della soluzione di monitoraggio real time presentando i dettagli di implementazione del secondo modulo applicativo, quello di Data Ingestion & Computing, realizzato da una libreria Java, eseguita da Spark ad ogni iterazione del batch.

 

Componente di Data Ingestion & Computing

Questo componente applicativo implementa, per mezzo di Spark Streaming, la logica di ingestion dei dati pubblicati sul topic Kafka. Si tratta di una libreria Java distribuita nel runtime di Spark, che realizzerà la logica di Data ingestion & computing che soddisfa i requisiti di monitoraggio stabiliti.

Di seguito lo skeleton del progetto Eclipse.

Figura 1 – Progetto Eclipse di Data ingestion & computing.
Figura 1 – Progetto Eclipse di Data ingestion & computing.

 

Requisiti di monitoraggio

Il sistema di monitoraggio dovrà soddisfare i seguenti requisiti.

Anzitutto, la visualizzazione di dettaglio dei veicoli in prossimità delle coordinate di un Point of Interest stabilito, come da tabella riportata di seguito.

Figura 2 – Dettaglio dei veicoli in prossimità di un POI.
Figura 2 – Dettaglio dei veicoli in prossimità di un POI.

 

Oltre a questo, la visualizzazione della distribuzione del numero di veicoli raggruppati per tipo e per direttrice stradale di rilevazione, come da tabella riportata di seguito.

Figura 3 – Distribuzione dei veicoli per tipo e direttrice di rilevazione.
Figura 3 – Distribuzione dei veicoli per tipo e direttrice di rilevazione.

 

Sulla base di queste evidenze sarà codificata la libreria Java che, dopo aver impostato i parametri di esecuzione di Spark, applicherà ai messaggi di ogni batch di ingestion la sequenza di trasformazioni necessarie a ottenere il DStream finale. Su quest’ultimo verranno applicate le funzioni di calcolo necessarie a soddisfare i requisiti di monitoraggio richiesti. Nei paragrafi successivi verrà descritto il dettaglio di ciascuna delle trasformazioni eseguite da Spark.

 

Configurazione di runtime per Spark

Riportiamo di seguito i fragment salienti del codice della classe Java che realizza l’esecuzione e la gestione del processo di streaming di Spark. Nella prima parte di questa classe viene codificato quanto necessario alla configurazione di esecuzione di Spark e alla risoluzione dei servizi delle istanze di Kafka e Cassandra. La valorizzazione di questi parametri viene disaccoppiata dalla codifica Java attraverso un file di properties. Tra i parametri di esecuzione di Kafka, possiamo notare le classi che saranno utilizzate per serializzare e deserializzare i messaggi JSon pubblicati sul topic di Kafka.

Figura 4 – Configurazione di esecuzione di Spark.
Figura 4 – Configurazione di esecuzione di Spark.

 

Per attualizzare a run time quanto codificato, vengono riportate di seguito le coppie chiave-valore dei parametri di esecuzione di Spark definite nel file di properties:

Figura 5 – File di properties con i parametri di esecuzione di Spark.
Figura 5 – File di properties con i parametri di esecuzione di Spark.

 

Una volta che le configurazioni di Spark sono state dichiarate, viene creato uno streaming context dal topic di Kafka con batch eseguiti a intervalli di 5 secondi.

Figura 6 – Creazione e inizializzazione del contesto per l’istanza di Spark Streaming.
Figura 6 – Creazione e inizializzazione del contesto per l’istanza di Spark Streaming.

 

La classe org.apache.spark.streaming.api.java.JavaStreamingContext rappresenta l’entry point principale di tutte le operazioni di streaming di Spark.

Qualsiasi processo di Spark Streaming deve partire dalla creazione di una istanza dell’oggetto di StreamingContext. Sarà poi attraverso il metodo statico createDirectStream della classe KafkaUtils che verrà definito il contesto di streaming di dettaglio, in questo caso verso Kafka.

 

Ingestion di Spark dei messaggi Kafka

Ad ogni iterazione del batch, Spark esegue il trasferimento in una classe Java di tipo JavaInputDStream dei messaggi presenti nel topic di Kafka non ancora processati.

Figura 7 – Ingestion di Spark dei messaggi presenti nel topic Kafka.
Figura 7 – Ingestion di Spark dei messaggi presenti nel topic Kafka.

 

La variabile messagesTypeOfJAvaDStream è un JavaInputDstream di tipo ConsumerRecord<K,V>. ConsumerRecord<K,V>. Questo tipo rappresenta una collection di coppie chiave-valore ricevute dal topic di Kafka definito nel javaStreamSparkCntxt, il contesto Spark di streaming di tipo Java.

Nell’implementazione presentata la collection ConsumerRecord<K,V> viene attualizzata con tipi Stringa sia per la chiave che per il valore. Quest’ultimo conterrà il messaggio in formato JSON che verrà poi serializzato nella classe Java di tipo IOTData. La classe Java ConsumerRecord<String, String> contiene inoltre informazioni circa il nome del topic, il numero della partizione dalle quali il record viene ricevuto, un offset che punta al record nella partizione Kafka, e un timestamp come indicato dal corrispondente ProducerRecord.

JavaInputDStream è una interfaccia Java-frendly della classe InputDStream che a sua volta estende Dstream, il Discretized Stream che, come già descritto, rappresenta un’astrazione di base di Spark Streaming. Il Discretized Stream è costituito da una sequenza continua di Resilient Distributed Dataset (RDD) dello stesso tipo.

Nella firma del metodo statico createDirectStream troviamo i parametri LocationStrategies e ConsumerStrategies.

LocationStrategies

Le API consumer di Kafka attuano la bufferizzazione dei messaggi. Pertanto, per motivi prestazionali, è importante che l’integrazione con Spark sia tale che i client vengano mantenuti memorizzati nella cache degli esecutori, più che vengano ricreati ad ogni batch.

Nella maggior parte dei casi, la strategia PreferConsistent è quella più adeguata, in quanto distribuisce le partizioni in modo uniforme tra tutti gli esecutori disponibili.

Nel caso in cui gli esecutori si trovino sugli stessi host dei broker Kafka, la strategia PreferBrokers attuerà la pianificazione delle partizioni sul leader Kafka.

Infine, nel caso in cui sia significativo il disallineamento di carico tra le partizioni, la strategia PreferFixed consente di stabilire un mapping esplicito delle partizioni verso gli host.

 

ConsumerStrategies

La API per i consumer di Kafka può specificare i topic in diversi modi. ConsumerStrategies fornisce un’astrazione che consente a Spark di riottenere correttamente gli utenti configurati anche dopo il riavvio dal checkpoint.

ConsumerStrategies.Subscribe permette la sottoscrizione a una collezione definita di topic.

Attraverso il parametro SubscribePattern  è possibile utilizzare una regular expression per specificare i topic di interesse. Il parametro Assign consente di specificare una collezione fissa di partizioni.

Tutte le strategie di spongono di costruttori di overload che consentono di specificare l’offset iniziale di una specifica partizione.

Inoltre ConsumerStrategy è una classe pubblica che si può estendere implementando quanto necessario per esigenze specifiche di configurazione.

 

Serializzazione dei messaggi Kafka

I Discretized Stream possono essere creati sia da dati di live ingestion da un topic Kafka utilizzando uno streamingContext, sia da trasformazioni di Discretized Stream esistenti utilizzando le operazioni di:

  1. map;
  2. window;
  3. filter;
  4. reduceByKeyAndWindow

Come descritto al paragrafo precedente, ad ogni iterazione del batch Spark la variabile messagesTypeOfJAvaDStream, di tipo JavaInputDStream<ConsumerRecord<String, String>> contiene i messaggi trasferiti dal topic Kafka. L’operazione successiva del batch sarà quindi quella di applicare a quest’ultimo JavaInputDStream il metodo map per ottenere un nuovo JavaDStream di tipo IoTData, la classe che serializza in un oggetto Java ogni messaggio pubblicato su Kafka in formato JSon.

Di seguito la funzione che trasferisce la variabile di tipo  ConsumerRecord<String,String> restituita da Kafka in un JavaDStream di tipo IOTData, utilizzando per la trasformazione la classe GsonBuilder .

Figura 8  – Serializzazione dei messaggi Kafka.
Figura 8  – Serializzazione dei messaggi Kafka.

 

Internamente un DStream è caratterizzato da poche proprietà di base; una lista di altri DStream da cui dipende, l’intervallo di tempo nel quale il DStream genera un RDD, e una funzione che viene usate per generare un RDD ad ogni intervallo di tempo.

 

Individuazione dei veicoli distinti nei batch dei messaggi

La variabile nonFilteredIotDataStream di tipo JavaDStream, ottenuta al passo precedente, conterrà i tutti i messaggi dei veicoli circolanti sotto forma di classe di serializzazione di tipo IoTData.

Obiettivo di questo step è quello di ottenere, da questo Dstream, un DStream ridotto ai soli veicoli distinti per calcolarne l’effettiva numerosità sulle direttrici stradali. Sarà quindi applicando in sequenza i metodi .mapToPair e .reduceByKey alla varaibile nonFilteredIotDataStream che si otterrà un nuovo DStream di tipo JavaPairDStream.

Un JavaPairDStream  è un’interfaccia al DStream di tipo coppia di chiave e valore.

In questo caso il metodo mapToPair riduce il DStream riversato da Kafka nella operazione di Spark streaming ai soli veicoli distinti. La chiave consiste nell’identificativo univoco del veicolo e il valore la classe IOTDati che serializza il messaggio Kafka ricevuto.

Figura 9 – Individuazione dei veicoli distinti nei batch dei messaggi.
Figura 9 – Individuazione dei veicoli distinti nei batch dei messaggi.

 

Assegnazione del flag di permanenza su una direttrice

Per calcolare il numero dei veicoli che percorrono una determinata strada, è necessario verificare se i veicoli siano già stati processati in un batch antecedente. In questo step quindi il DStream ottenuto al passo precedente viene esteso in uno nuovo e arricchito da un flag di stato che marca, per un intervallo di tempo definito, la permanenza dei veicoli nella direttrice stradale di rilevazione.

Viene quindi creato un nuovo DStream di tipo JavaMapWithStateDStream a partire dal precedente applicando il metodo mapWithState, con una scadenza di questo stato impostata a 60 minuti. Di seguito il fragment di codice che implementa questa funzionalità.

Figura 10 – Assegnazione a ciascun veicolo del flag di permanenza su una direttrice.
Figura 10 – Assegnazione a ciascun veicolo del flag di permanenza su una direttrice.

 

Riduzione del DStream ai soli veicoli già processati

Una volta valorizzato il flag di permanenza su una direttrice ai veicoli considerati in tutti i batch, dal DStream del passo precedente viene creato un nuovo JavaDStream attraverso l’applicazione di un filtro che mantiene i soli veicoli processati. Questo si ottiene applicando in sequenza i metodi .map e .filter con regola Boolean.FALSE.

Di seguito il fragment di implementazione.

Figura 11 – DStream ridotto ai soli veicoli già processati.
Figura 11 – DStream ridotto ai soli veicoli già processati.

 

Definizione del DStream finale con i messaggi in formato IOTData

L’ultima operazione consiste nel trasformare il DStream del passo precedente in uno nuovo di tipo JavaDStream contenente i soli oggetti IOTData che serializzano i messaggi inviati a Kafka in formato JSon.

Figura 12 – DStream finale di tipo IOTData.
Figura 12 – DStream finale di tipo IOTData.

 

Questo DStream viene quindi persistito nella cache, e sarà utilizzato per le operazioni di calcolo del traffico totale della finestra temporale che verranno illustrate nella prossima parte.

Figura 13 – DStream definitivo persistito nella cache.
Figura 13 – DStream definitivo persistito nella cache.

 

Conclusioni

In questa quinta parte sono stati presentati i requisiti di monitoraggio e i dettagli di implementazione del componente applicativo di Data ingestion & computing, relativi all’avvio del batch di Spark Streaming e degli step di preparazione del DStream finale. Sarà su quest’ultimo che saranno applicate le funzioni di trasformazione e persistenza su Cassandra, che nella prossima parte completeranno la descrizione dei dettagli di implementazione di questo componente applicativo.

 

Riferimenti

[1] Socks

socks-client

https://github.com/sockjs/sockjs-client

 

[2] Kafka

https://kafka.apache.org/quickstart

https://www.slideshare.net/mumrah/kafka-talk-tri-hug?next_slideshow=1

https://www.youtube.com/watch?v=U4y2R3v9tlY

https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

 

[3] Spark

https://spark.apache.org/docs/latest/index.html

https://data-flair.training/blogs/spark-rdd-tutorial/

https://data-flair.training/blogs/apache-spark-rdd-features/

 

[4] Spark e Cassandra data connector

https://www.datastax.com/dev/blog/accessing-cassandra-from-spark-in-java

 

[5] Zookeeper

https://www.youtube.com/watch?v=gifeThkqHjg

https://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper

 

[6] Kafka e Zookeeper

https://www.youtube.com/watch?v=SxHsnNYxcww

 

[7] Price Waterhouse and Cooper, The Bright Future of Connected Cars
https://carrealtime.com/all/pwc-the-bright-future-of-connected-cars/

 

[8] Hadoop

https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

 

[9] Spark

https://www.infoq.com/articles/apache-spark-introduction/?utm_source=apachesparkseries&utm_medium=link&utm_campaign=internal

 

[10] RDD

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf

 

[11] WebSocket

http://jmesnil.net/stomp-websocket/doc/

 

[12] STOMP

https://stomp-js.github.io/guide/stompjs/rx-stomp/ng2-stompjs/using-stomp-with-sockjs.html

 

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
User Story Game https://www.mokabyte.it/2022/06/06/userstorygaming/ https://www.mokabyte.it/2022/06/06/userstorygaming/#respond Mon, 06 Jun 2022 20:09:46 +0000 https://test.mokabyte.it/?p=8805 Le User Stories sono uno strumento importante, spesso determinante nel successo di un progetto, come ogni Product Owner ben sa. In questo articolo, descriviamo un “gioco serio” che aiuta a comprenderne il valore, e proponiamo anche una modalità per svolgerlo da remoto, online.

L'articolo User Story Game proviene da MokaByte.

]]>
Un gioco che combina il disegno e il Taboo…

… per capire l’importanza delle User Story. Sostanzialmente, è questo ciò che vedremo in questo articolo. Vedremo infatti come è possibile usare attività “facili” — quali disegnare e giocare a Taboo [1] — per comunicare il valore cruciale delle User Story quando si deve passare dalle idee e dalle richieste di un cliente alla realizzazione di un Product Backlog “implementabile”. E su questo esempio di “serious gaming” faremo alcune riflessioni.

L’importanza della comunicazione

Durante il mio lavoro quotidiano di Product Owner, sempre più mi rendo conto di come il tema della comunicazione sia un elemento determinante per il successo o l’insuccesso di un progetto. Spesso tra il Product Owner e il team di sviluppo emergono diverse barriere comunicative che impediscono una condivisione efficace degli obiettivi e portano quindi a fraintendimenti. Questo si riflette in un risultato non sempre conforme alle aspettative del Product Owner e di conseguenza anche del cliente. In questo contesto, penso che una scrittura efficace delle user story possa essere un fattore determinante per il successo del progetto.

Obiettivo

Ho costruito questo workshop con l’obiettivo di simulare attraverso un gioco, e quindi con l’uso della metafora, una situazione di lavoro quotidiano per fare emergere quali sono le difficoltà che si incontrano; attraverso la discussione finale, poi, sarà possibile capire insieme a tutti i partecipanti come una scrittura corretta delle User Story può facilitare il raggiungimento degli obiettivi di progetto.

 

Descrizione del gioco

I partecipanti al workshop si dividono in team il cui obiettivo è quello di disegnare l’interno di una casa in modo da soddisfare le aspettative del cliente. Nel team c’è un Product Owner, incaricato di confrontarsi con il cliente e di tradurre le sue aspettative in user story, e c’è un team che realizzerà materialmente il disegno della casa, sulla base delle informazioni ricevute dal PO.

Il gioco è diviso in diverse fasi che corrispondono a diversi Sprint. Prima dell’inizio di ogni Sprint, i Product Owner si confrontano con il cliente che descrive le proprie aspettative. I Product Owner devono comunicare queste aspettative al team tramite le user story. Durante lo sprint il team realizza quanto descritto nella user story.

Alla fine degli sprint previsti, si confronta quanto è stato disegnato dai team con il risultato atteso. Vince il team che ha realizzato il progetto più vicino alle aspettative del cliente.

 

Regole

Ecco una sintesi delle regole del gioco

  • I partecipanti al workshop si dividono in team (da 2 a 4 persone): un membro del team ricopre il ruolo di Product Owner, gli altri interpretano il ruolo di developer.
  • Il cliente comunica solamente con i Product Owner.
  • I Product Owner non possono comunicare verbalmente con il team: l’obiettivo viene trasmesso solo tramite la storia utente.
  • Per scrivere la storia utente, i Product Owner non possono usare le parole tabù che verranno indicate e che esemplificano il concetto di complessità.
  • Il tempo di ogni sprint è limitato: 3-5 minuti.

 

Tempi di gioco

La durata totale del gioco può variare tra i 30 e i 60 minuti. Affinché il workshop non sfori il tempo dedicato devono essere rispettate queste tempistiche:

  • 5/10 minuti di introduzione al gioco;
  • 15/25 minuti di gioco;
  • 10/20 minuti di discussione finale.

Per ridurre la durata del workshop è possibile ridurre il numero di iterazioni nel gioco.

 

Fasi

Il gioco è diviso in diverse fasi che corrispondono agli Sprint di sviluppo. Ad ogni Sprint viene mostrata al Product Owner un’immagine che rappresenta l’aspettativa del cliente. Il Product Owner può avere un confronto verbale con il cliente e deve riuscire a trasmettere l’aspettativa al team senza utilizzare le parole tabù riportate.

Sprint 1

Obiettivo: il team deve disegnare la sezione trasversale del piano terra di una casa. Quella desiderata dal cliente è rappresentata in figura 1.

Parole Tabù:

  • camino
  • poltrona
  • finestra
Figura 1 – Sprint 1, Piano 0.
Figura 1 – Sprint 1, Piano 0.

Sprint 2

Obiettivo: il team deve disegnare la sezione trasversale del primo piano di una casa. Quella desiderata dal cliente è rappresentata in figura 2.

Parole Tabù:

  • TV / televisore
  • divano
  • orologio
Figura 2 – Sprint 2, Piano 1.
Figura 2 – Sprint 2, Piano 1.

Sprint 3

Obiettivo: il team deve disegnare la sezione trasversale dell’ultimo piano di una casa. Quella desiderata dal cliente è rappresentata in figura 3.

Parole Tabù:

  • comignolo
  • tetto
  • scrivania
Figura 3 – Sprint 3, Piano 2.

Sprint 4

Obiettivo: il team deve disegnare la sezione trasversale del piano sotterraneo di una casa. Quella desiderata dal cliente è rappresentata in figura 4.

Parole Tabù:

  • lavatrice
  • lampada
  • caldaia
Figura 4 – Sprint 4, Piano –1.
Figura 4 – Sprint 4, Piano –1.

 

Demo al cliente

Alla fine degli Sprint tutti i team mostrano al cliente quanto realizzato e lo comparano con le aspettative del cliente (figura 5).

Figura 5 – L’intero edificio, secondo le aspettative del cliente.
Figura 5 – L’intero edificio, secondo le aspettative del cliente.

 

Il team che è andato più vicino alle aspettative del cliente vince. Per valutare quale team si è avvicinato di più si può utilizzare la scala di valutazione riportata di seguito

Funzionalità

Ci sono questi oggetti al piano 0? (1 pt x oggetto)

  • camino
  • quadri
  • vaso

 

Ci sono questi oggetti al piano 1? (1 pt x oggetto)

  • orologio
  • tappeto
  • scale

 

Ci sono questi oggetti al piano 2? (1 pt x oggetto)

  • PC
  • comignolo
  • botola

 

Ci sono questi oggetti al piano –1? (1 pt x oggetto)

  • lavatrice
  • lampada soffitto
  • scaffale

 

La casa è colorata? (3 pt)

 

Discussione

Il fine di questo workshop è di intavolare una discussione e un confronto tra tutti i partecipanti sulle difficoltà emerse durante i diversi Sprint sulle conseguenze che genera la difficoltà di comunicazione e su come queste possono essere superate. Ecco alcuni spunti per instradare la discussione:

  • C’è differenza tra l’aspettativa del cliente e quanto è stato realizzato? Quali sono le differenze più evidenti?
  • Quali sono state le difficoltà più rilevanti che hai incontrato?
  • Cosa ti ha aiutato?
  • Cosa hai appreso nel corso degli Sprint?

 

Spiegazione del gioco

Nel gioco ho inserito diversi vincoli, per esempio il fatto che il Product Owner non possa comunicare direttamente con il team, ma debba usare solo le storie utente, o il fatto che alcune parole siano “tabù” e non possano quindi essere utilizzate per scrivere le storie. Di seguito spiego il perchè di questi vincoli:

Perchè il PO può comunicare con il team esclusivamente con le storie utente?

Spesso i momenti di confronto, soprattutto quando si lavora da remoto — come sta accadendo in questo periodo a una parte significativa di persone — sono limitati. Per questo la scrittura delle storie assume ancora più rilevanza e determina poi la corretta esecuzione del progetto.

Perchè ci sono parole tabù che il PO non può usare?

Spesso è difficile comunicare esattamente quello che si ha in mente: questo vincolo serve per simulare le barriere di comunicazione che inevitabilmente si affrontano nella quotidianità. Inoltre, molte volte è difficile uscire dagli stereotipi, per cui è necessario imparare a comunicare in maniera differente, articolando la propria visione senza essere bloccati sui concetti che usiamo sempre, quindi evitando gli stereotipi.

Perchè al PO viene mostrato un piano alla volta e non l’intera casa?

Spesso, durante il progetto, il cliente cambia idea e aggiunge nuove funzionalità a quelle previste inizialmente. È importante quindi puntare ad avere sempre una visione di insieme e riuscire a capire cosa il cliente vuole veramente ottenere dal progetto ossia il senso della richiesta complessiva che il cliente ci sta facendo. Questa visione di insieme non deve rimanere propria del Product Owner ma deve essere trasmessa al team.

Perchè a fine gioco solo alcune “funzionalità” danno un punteggio?

Il cliente a volte si focalizza su requisiti che per il team possono sembrare più superflui di altri — per esempio, il colore della casa— ma è importante, durante l’esecuzione del progetto, capire quali sono le priorità del cliente.

 

Come eseguire il workshop da remoto

Durante il periodo di “distanziamento fisico” che stiamo vivendo, sarà necessario evitare assembramenti e, ancora per diverso tempo, molte attività professionali o formative saranno svolte da remoto.

Ho pensato a questo workshop in modo che sia realizzabile anche da remoto. Ho individuato una soluzione che richiede l’utilizzo di un foglio di disegno condiviso e di un tool per creare room virtuali tra i partecipanti (Hangout, Zoom, Teams, etc.).

Per realizzare il workshop da remoto il consiglio è di utilizzare gli strumenti in questo modo:

  • Creare una virtual room sempre aperta con tutti i partecipanti che serve per scandire il tempo di fine sprint.
  • Creare una virtual room sempre aperta con tutti i PO che serve per comunicare loro le aspettative del cliente per lo sprint successivo.
  • Creare una virtual room del Dev Team (il PO non accede) di modo che il team si possa confrontare durante “lo sviluppo”.
  • Utilizzare un foglio da disegno grande, comune a tutti i team (ogni team ha la sua sezione), di modo che alla fine tutti abbiano la possibilità di vedere quanto realizzato dagli altri partecipanti.

Consiglio di preparare tutti i link prima dell’inizio del workshop e di assicurarsi che tutti i partecipanti abbiano dimestichezza con l’utilizzo del foglio di disegno e con le virtual room. 

 

Caso d’uso

Ho proposto questo workshop durante una unconference. Il tempo totale del workshop è stato di 30 minuti e hanno partecipato circa 15 persone.

Ho fatto in modo che chi, nella quotidianità, ricopre  il ruolo di Product Owner fosse assegnato il ruolo di developer e viceversa. Hanno partecipato al workshop anche persone con ruoli differenti all’interno dell’azienda ed è stato interessante vedere come ognuno di loro abbia approcciato il problema in maniera differente.

Stili di comunicazione

Durante gli sprint sono emersi stili di comunicazione totalmente diversi tra di loro: alcuni sono andati molto nel dettaglio descrivendo tutti gli oggetti del piano, altri invece hanno preferito riassumere in modo più sintetico ciò che il cliente chiedeva. Inoltre, avendo poco tempo a disposizione, ognuno si è focalizzato su dettagli diversi della stanza.

Vediamo di seguito due storie utente con stili completamente diversi.

User story team Verde

Storia Sprint 1

  • spazio ampio
  • focolare al centro dello spazio
  • scala sulla destra
  • punti luce sulla sinistra
  • (guardando davanti)

User Story Team Fucsia

Storia Sprint 2

Filippo si reca nella sua stanza preferita dove può guardare un sacco di film Netflix mentre si siede comodamente insieme ad amici (non dovete disegnare le persone, ma serve a farvi capire che è una seduta per più persone).

È presente anche in questa stanza una piacevole vista verso l’esterno vicino al dispositivo per trasmettere i programmi tipo quelli di Netflix. Fortunatamente Filippo non perderà mai la cognizione del tempo, grazie a un dispositivo a muro che ne tiene il conto. Anche in questa stanza è presente una scala.

Comunicazione e interpretazioni

La combinazione di diversi stili di comunicazione e di diversi focus sui dettagli hanno portato i team a interpretare in maniera totalmente differente l’obiettivo finale e quindi a realizzare output diversi tra di loro (figura 6).

Figura 6 – Il risultato dei diversi team nello Sprint 2.
Figura 6 – Il risultato dei diversi team nello Sprint 2.

Alcune considerazioni a partire dai risultati

Guardando il risultato complessivo realizzato dai team durante i diversi sprint (figura 7) è interessante vedere come molti di loro abbiano disegnato il tetto sotto il piano terra. Discutendo con i partecipanti, è emerso che una grande criticità durante il lavoro è stata la mancanza di una visione di insieme su quanto si stava realizzando: il team disegnava Sprint dopo Sprint quanto richiesto dal Product Owner senza rendersi conto dell’obiettivo finale da raggiungere.

Figura 7 – Il risultato dei diversi team alla fine del gioco.
Figura 7 – Il risultato dei diversi team alla fine del gioco.

 

Emerge quindi l’importanza per il Product Owner di capire l’obiettivo del cliente e di saperlo spiegare e condividere con il team di sviluppo di modo che tutti abbiano una visione globale di quanto si vuole realizzare. Ed è importante che tutti siano orientati al risultato finale più che allo svolgimento del singolo compito.

 

Conclusioni

Il gioco si dimostra quindi di valido aiuto nella comprensione del ruolo del Product Owner e in particolare dell’importanza di una competenza specifica, quella legata alla comunicazione funzionale, capace cioè di trasferire una visione d’insieme al team.

Inoltre, aiuta chi opera nei team a comprendere quali difficoltà si trova a gestire il Product Owner nel suo rapporto con il cliente. E rende immediatamente comprensibile quanto sia complesso mantenere le richieste del cliente, che spesso vengono presentate volta per volta, all’interno di una organica visione d’insieme.

 

 

L'articolo User Story Game proviene da MokaByte.

]]>
https://www.mokabyte.it/2022/06/06/userstorygaming/feed/ 0
Sbagliando si impara? https://www.mokabyte.it/2022/06/06/sbagliando-si-impara/ https://www.mokabyte.it/2022/06/06/sbagliando-si-impara/#respond Mon, 06 Jun 2022 19:56:29 +0000 https://test.mokabyte.it/?p=8801 Si dice che “chi ben comincia è già a metà dell’opera” ma anche che “sbagliando si impara”. Tra necessità di apprendere al meglio le pratiche agili fin da subito e gli inevitabili fallimenti connessi a qualsiasi attività umana, passiamo in rassegna una serie di errori tipici riscontrabili nella pratica di Scrum.

L'articolo Sbagliando si impara? proviene da MokaByte.

]]>
Introduzione

Anni fa — a dire il vero, parecchi anni fa — un collega di allora “confessò” ad alcuni di noi che stava seguendo un “corso” per smettere di fumare. Si trattava in realtà di una serie di incontri in cui figure professionali diverse, tra cui uno psicoterapeuta, aiutavano un piccolo gruppo di persone, seriamente intenzionate, a superare i momenti iniziali del distacco e a rafforzare la motivazione di chi aveva deciso di abbandonare la sigaretta.

Quando chiedemmo al nostro collega di che cosa si trattasse, ci colpì un aspetto della “pratica” che lui aveva colto e metteva in grande risalto: tutto aveva un’impronta “positiva”. Piuttosto che sugli ovvi e ben conosciuti danni derivanti dal fumo di sigaretta, coloro che stavano smettendo venivano fatti concentrare sui miglioramenti al benessere generale che sarebbero derivati dall’abbandono del fumo. Piuttosto che rafforzare la motivazione con frasi come “Non devo fumare perché mi fa male”, “Voglio smettere di fumare” e cose del genere, venivano proposti ai partecipanti dei “mantra” che suonavano più o meno così: “Il fumo è noioso”, “Fumare è un interesse secondario” e cose del genere, che al momento non ricordo perfettamente nelle parole esatte, ma il cui tono era proprio questo, di sufficienza e non di negazione.

“Concentrarsi sugli aspetti negativi, sugli errori commessi” — ci diceva il nostro collega — “finisce per rinforzare proprio quegli aspetti e non favorisce un miglioramento e una svolta nella propria condizione”. Questa era la motivazione che era stata data all’approccio “positivo” di tutto il percorso, o perlomeno questa era quella che il nostro collega aveva colto. Non ho alcuno strumento per ritenere se la cosa avesse un senso e una base scientifica ma, di fatto, il nostro collega — persona peraltro molto metodica e determinata sul lavoro — smise in effetti di fumare come si era prefisso e, almeno per gli anni prima che le nostre strade professionali si separassero, mai tornò a farlo.

Pattern e antipattern

Questo episodio avvenne nel periodo in cui nel mondo IT, in senso lato, ci si occupava primariamente di linguaggi e architetture di sistema. In quel panorama, era pratica consueta studiare i pattern architetturali — e se sfogliaste gli “arretrati” di MokaByte risalenti a una quindicina di anni fa trovereste decine di articoli che ne parlano — nonché i cosiddetti antipattern, ossia dei “modelli negativi”, tanto tipici quanto diffusi perché apparentemente risolutivi, che però andavano a rovinare tutte le migliori intenzioni nel realizzare sistemi che si accordassero ai canoni architetturali più sensati.

E questo episodio mi è tornato in mente proprio in questo periodo a proposito della pratica Scrum: meglio concentrarsi solo sul proporre e favorire modelli positivi, oppure ha senso anche individuare errori tipici che a più riprese e in gruppi diversi si riscontrano nell’adottare e mettere in pratica Scrum?

 

Indicazioni dalla Scrum Guide

Per molto tempo sono state le stesse vecchie versioni della Scrum Guide a definire questra infrastruttura metodologica come “semplice da comprendere, difficile da padroneggiare”. E proprio in queste brevissime affermazioni si potrebbero trovare le motivazioni per dire che ha senso anche mettere in luce errori tipici insiti nella messa in atto dei vari elementi di Scrum.

Come sanno tutti coloro che conoscono la “infrastruttura” di Scrum, in Scrum abbiamo una serie di elementi costitutivi. Oltre al non secondario elemento dei valori e della teoria di Scrum nella sua ultima edizione la guida [2] individua

  • il team Scrum: Product Owner, Scrum Master, Developers, ;
  • gli eventi Scrum: all’interno del contenitore Sprint ci sono Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective,
  • i “manufatti” Scrum: Product Backlog, Sprint Backlog e incremento, generalmente chiamati artefatti con un’errata traduzione dall’inglese artifacts.

In ognuna di queste tre aree potremmo sicuramente riscontrare degli errori tipici e ricorrenti, che una volta messi in evidenza possono portare a una rimozione delle “cattive pratiche” e a un miglioramento del processo.

In particolare, cercheremo di seguire i comportamenti delle persone che ricoprono i ruoli e individuandone gli errori nel corso delle varie “cerimonie” che essi conducono all’interno dell’infrastruttura metodologica.

Errori tipici e dove trovarli

Chiaramente si tratta di un tema trattato a più riprese e da più autori, specie nelle conferenze dedicate al mondo Agile, al punto che c’è chi si è spinto a parlare dei “sette peccati capitali” in Scrum [2] o chi ha realizzato delle carte degli antipattern in Agile [3] in cui vengono illustrate pratiche che, per quanto sembrino anche adeguate, in realtà rappresentano dei passi verso la disfunzione e la non riuscita.

Nella nostra breve trattazione, presenteremo alcune disfunzionalità effettivamente riscontrate e le commenteremo in maniera stringata. Crediamo infatti che già un elenco ragionato di tali errori ricorrenti possa aiutare a individuare quello o quelli in cui il nostro gruppo di lavoro ricade più frequentemente — non è detto che tutti siano protagonisti di tutti gli antipattern presentati — e, magari dopo attenta retrospettiva, a determinare le azioni da intraprendere per liberarsene e per continuare sulla strada del miglioramento continuo.

Ad ogni modo, non ci stancheremo mai di dire che, prima ancora che su pratiche, errori, antipattern e via dicendo, occorre concentrarsi sullo sviluppo di una mentalità improntata ai valori e ai principi dell’agilità.

E poi occorre ricordare che, per ovvie ragioni, spesso chi “interpreta” un determinato ruolo è portato a non vedere con chiarezza i comportamenti potenzialmente “distorti” che lo riguardano, ma è capace di osservare quelli che si evidenziano negli altri. Da questo sguardo incrociato — tradizionalmente destinato a sfociare in recriminazioni e accuse con il dito puntato — può invece nascere un franco ma costruttivo dialogo e una presa d’atto di certi comportamenti che portano a un loro miglioramento.

 

Errori tipici che riguardano il Product Owner

Il principale campo di azione di un PO è l’area del Product Backlog e del suo raffinamento, ma non significa che certi errori non vengano commessi anche in altri ambiti. Vediamoli di seguito

PO e Product Backlog

Un primo, significativo, errore ricorrente per il PO è quello di non essere davvero lui a stabilire le priorità, ma di fungere da “passacarte” nel senso che si limita a recepire e trasmettere le priorità stabilite dagli stakeholder. Succede a volte, e anche in maniera inconsapevole, ma deve essere chiaro che questo inficia tutto il lavoro: stabilire le priorità nel backlog spetta al PO e questo deve essere chiaro a tutti fin dal principio.

Un altro comportamento potenzialmente molto pericoloso è quello di non prendersi cura a sufficienza del Product Backlog. Il Product Backlog è un’entità “viva” e — passatemi il paragone — come con un animale domestico, non può essere abbandonato a sé stesso: ha bisogno di cure e attenzioni continue e quotidiane. Deve essere curato, riordinato, raffinato, controllato.

Qualche segnale di mancanza di cura del Product Backlog è però abbastanza facile da riscontrare e può consentire aggiustamenti. Ad esempio, se il Product Backlog è troppo grosso e contiene più elementi di quelli che il Dev Team potrà realizzare nell’ambito di alcuni sprint (tre, quattro, cinque?) vuol dire che è stato un po’ lasciato a sé stesso ed è diventato più un “ripostiglio” che non un vero e proprio backlog. Stesso dicasi se ci sono dentro elementi “invecchiati” che non vengono toccati da più di tre o quattro sprint o se ci sono elementi non bene definiti, che hanno solo il titolo e nient’altro.

Accanto a questi, c’è un altro potenziale comportamento “pericoloso”, quello del superPO che fa un po’ tutto lui… Da chi non crea le storie insieme al team di sviluppo in un processo collaborativo, a chi pur collaborando con il team, impone anche il modo in cui le storie debbano essere implementate, magari con precise indicazioni tecniche — è questo un compito del Dev Team, invece —, a chi, infine, pensa di essere onnisciente e non interroga gli stakeholder o degli specialisti tecnici per supportarlo nel processo di raffinamento.

PO e Sprint Planning

Anche nell’ambito della pianificazione dello sprint il PO può compiere errori tipici e ricorsivi.

Uno dei più comuni consiste nel non essere in grado di fornire un obiettivo chiaro, focalizzato e misurabile per lo sprint in questione: senza questo, il Dev Team avrà difficoltà a definire la sua parte di Sprint Planning.

Altro errore piuttosto comune da parte del PO consiste nel non valutare esattamente lo “stato di forma” del Dev Team e spingere affinché esso accetti in carico più lavoro di quanto realisticamente possa completare. Magari alcuni precedenti indicatori potrebbero far pensare che ce la faranno, ma non sarà così.

PO e Sprint

Il PO può compiere errori anche nel corso dello Sprint vero e proprio. Un tipico esempio è quello del PO assente: dopo aver svolto correttamente il suo lavoro nelle fasi di raffinamento del Product Backlog (che deve continuare) e di Sprint Planning, il Product Owner diventa assente, lasciando gli sviluppatori a “sbrigarsela da sé”.

A ben guardare è un po’ una sorta di riedizione del waterfall e, sebbene gli sviluppatori debbano effettivamente lavorare in autonomia, il PO deve essere sempre disponibile a rispondere a domande e interrogativi che possano sorgere.

Sempre nell’ambito di una sorta di micro-waterfall 2.0 ricade il caso in cui il PO divenga inflessibile nell’aggiustamento dei criteri di accettazione una volta che questi si dimostrino inadatti alla situazione nelle mani del team di sviluppo.

Si suole dire che, finché gli elementi da sviluppare stanno nel Product Backlog, essi sono di pertinenza del PO, ma una volta che entrano nello Sprint, sono i Developers a diventarne “padroni”. Esiste, ed è un problema a cui fare attenzione, la tendenza da parte del PO a continuare a considerare sua “proprietà” gli elementi che sono in sviluppo, con la conseguenza, ad esempio di allargare lo scope della storia una volta che essa già sia in lavorazione, altro tipico errore.

PO e Daily Scrum

Un evento in cui il PO può fare pochi danni, se è presente, è quello del Daily Scrum, fortunatamente. Qui il tipico antipattern è quello di trasformare la riunione stand-up del mattino in una sorta di estensione dello Sprint Planning in cui si discutono nuovi requisiti o si raffinano le storie utente.

PO e Sprint Review

Per concludere, un errore tipico del PO si manifesta in fase di Sprint Review, che non viene sfruttata al massimo come opportunità per migliorare la collaborazione tra PO, portatori di interesse e team Scrum.

Questo errore consiste nell’impiegare la Sprint Review per l’accettazione delle user stories implementate dal Dev Team; ma in realtà, tale accettazione andava fatta in concomitanza con la loro realizzazione e il soddisfacimento dei criteri di accettazione.

Come è possibile vedere da questa lista, il ruolo del Product Owner è giustamente considerato il più difficile nell’ambito della infrastruttura metodologica Scrum. Tante e tali sono le interazioni e la complessità che si genera a partire da esse, che è più facile che si evidenzino errori.

 

Errori tipici che riguardano lo Scrum Master

Probabilmente il ruolo dello Scrum Master è quello che può commettere errori per le più svariate ragioni: può accadere che ci siano Scrum Master molto bravi che però si trovano a interagire con un team disfunzionale o non all’altezza da un punto di vista tecnico, oppure, viceversa, che chi viene chiamato a ricoprire il ruolo non abbia le caratteristiche e/o la necessaria preparazione per svolgerlo al meglio.

Non è facile, infatti, mettere insieme quei tratti di pazienza, flessibilità, mancanza di dogmatismo, autorevolezza e al contempo capacità di comprendere la situazione nel suo complesso che sono necessari a un bravo Scrum Master.

Un errore che riguarda lo Scrum Master in senso generale è quello di intenderne la figura come quella di un manager in senso classico da organizzazione del lavoro taylorista: lo Scrum Master non è un “supervisore”, non è un “guardiano dei tempi e dei modi”, ma agisce con un approccio che deve favorire l’auto-organizzazione del team e far emergere le qualità, le capacità e l’assunzione consapevole di responsabilità da parte di tutti i componenti del Developers.

Chiaramente, non si deve cadere neanche nell’errore opposto, quello di diventare lo Scrum Master chioccia” o “mamma” che risolve in prima persona i problemi o che, per garantire l’importante aspetto dell’armonia della squadra, non mette in luce e non affronta eventuali problemi o conflitti che si manifestino, chiaramente sempre nell’ottica della risoluzione e non della recriminazione.

SM e Sprint Planning

L’errore più tipico dello Scrum Master in fase di Sprint Planning consiste nel non dimensionare adeguatamente lo Sprint Backlog.

Se regolarmente i Developers accettano dal PO troppi elementi, più di quanti siano in grado effettivamente di “digerire” durante lo Sprint; se buona parte (la metà?) degli elementi da implementare in uno Sprint finisce regolarmente per “avanzare” per lo Sprint successivo; se magari si riesce anche a completare il 100% delle storie, ma regolarmente non c’è mai tempo “libero” per colmare il debito tecnico che si accumula di Sprint in Sprint, significa che che lo Scrum Master non sta svolgendo bene il suo ruolo, che contempla anche il fatto di mettere un limite a quello che si può fare in uno Sprint. Ricordiamoci sempre che sono necessarie anche delle “casse di espansione” in cui far “tracimare” le “piene” che inevitabilmente il flusso degli eventi ci proporrà.

Altro errore tipico è quello di accettare storie non sufficientemente dettagliate: se il PO fornisce storie che non sono state raffinate a sufficienza, il problema è a monte e non è con l’accettazione passiva da parte del Dev Team, senza l’intervento dello Scrum Master, che questo problema sarà risolto.

SM e Sprint

Lo Sprint è la “fase di gioco” di Scrum in cui la presenza e l’azione dello Scrum Master emerge forse in maniera più evidente. In quanto tale, è anche una di quelle in cui si rischiano i più comuni errori ricorrenti. Una chiave per la riduzione di tali errori da parte dello Scrum Master può essere — rimanendo alla metafora sportiva — di ricordarsi sempre che Scrum è uno sport di squadra: mentre le conoscenze e le capacità individuali sono importanti ed è bene che emergano, gli atteggiamenti e i comportamenti da “primedonne” sono un sicuro indicatore di fallimento.

Di tutti gli errori che uno Scrum Master può commettere nell’ambito dello Sprint, forse il più comune e sfaccettato è quello di consentire l’interruzione del flusso di lavoro. Lo Scrum Master sa che, una volta che sia stato decretato l’avvio di uno Sprint, questo non deve essere disturbato o interrotto, se non per casi eccezionali. Sta quindi a lui “proteggere” — anche se il verbo non è proprio il migliore — l’integrità dello Sprint e la “tranquillità” dei Developers: gli stakeholder, inevitabilmente, porranno in atto comportamenti che rischiano di disturbare o interrompere il flusso di lavoro; e non lo fanno perché sono “cattivi”, ma semplicemente perché vedono le cose dalla loro prospettiva che non sempre è la stessa del Team Scrum.

Uno Scrum Master commetterà l’errore di consentire l’interruzione del flusso di lavoro se avrà un atteggiamento troppo arrendevole nei confronti del modo in cui “le alte sfere” possono disporre dei vari elementi dei Developers (spostandoli, convocandoli per interminabili riunioni, assegnando loro direttamente altri compiti, ingerendo nella composizione dello Sprint Backlog a Sprint iniziato, intervenendo al Daily Scrum e trasformandolo da stand-up meeting in qualche altro tipo di riunione). Ricordiamocelo sempre: gli sviluppatori si auto-organizzano, altrimenti non è Scrum.

Altro errore tipico dello Scrum Master è quello di non intervenire tempestivamente: se ci sono dei task che non avanzano di stato nel giro di due giorni, qualcosa non va. Magari chi se li è presi in carico ha delle difficoltà di qualsiasi tipo e non deve essere lasciato da solo: la ragione per cui si aggiungono i “pallini rossi” ai task che non avanzano non è legata a una colpevolizzazione di chi li sta facendo, ma all’esatto contrario, cioè al fatto che lì ci sono dei problemi che necessitano di sostegno.

Altro errore tipico è quello di non raccogliere dati utili per la retrospettiva. E con questa annotazione, che non necessita di spiegazioni, passiamo al paragrafo successivo.

SM e retrospettiva

Sul tema delle retrospettive al termine dello Sprint (e non solo quelle) rimandiamo sicuramente alla lettura della Parte V di Guida Galattica per Agilisti [4] dove sono trattate estensivamente le ragioni, le tipologie e le modalità per condurre una retrospettiva, e dove non mancano anche indicazioni sugli errori tipici che si possono commettere.

In questo paragrafo, vediamo quindi solo brevemente il tema degli errori nelle retrospettive di Sprint in relazione al ruolo dello Scrum Master.

Il primo e più evidente errore ricorrente è… non fare la retrospettiva. Magari lo Sprint è andato benissimo, magari non c’è tempo, magari si farà comunque al termine del prossimo Sprint. Se “inspect & adapt” è uno dei principi cardine di Scrum, è anche vero che Scrum è un sistema ordinato e con poche regole, chiare, che però vanno applicate. La retrospettiva è un momento fondamentale dell’infrastruttura metodologica Scrum, e va fatta.

Un secondo errore è fare retrospettive di bassa qualità: non cambiare mai formato, durata o luogo di svolgimento; non tenere una documentazione — per quanto stringata, anche solo con un po’ di testo scritto e qualche foto — che funga da memoria di quanto è stato fatto e deciso.

Ancora più in là ci si spinge con l’errore di fare retrospettive sbagliate, ossia retrospettive che, in fin dei conti non sono tali ma diventano qualcosa di diverso. È il caso della retrospettiva “processo” o “recriminatoria” in cui, invece di riflettere sui problemi evidenziati per adottare soluzioni in grado di garantire il miglioramento, si finisce per incolpare qualcuno delle eventuali criticità manifestatesi, oppure si degenera in una sterile sessione di recriminazioni e accuse incrociate.

Sappiamo che questi sono meccanismi assolutamente da disinnescare e il bravo Scrum Master deve avere nel suo repertorio tante possibilità per far sì che questo importante momento non diventi un potenziale “talk show televisivo” ma sia un punto fondamentale per garantire il miglioramento continuo, oltretutto scandendo il passaggio da uno Sprint concluso alla successiva pianificazione dello Sprint che seguirà.

La retrospettiva deve essere un momento in cui si avverte una sorta di “sicurezza psicologica”, in cui nessuno offende nessuno, né tantomeno è preponderante sull’intero gruppo. In tal senso, occorre ricordarsi che, a differenza di altre fasi in cui si favorisce il dialogo continuo con i portatori di interesse, quello della retrospettiva sullo Sprint è un momento in cui gli stakeholder non devono intervenire. Lo Scrum Master conosce questa regola e deve farla rispettare, indipendentemente dalla direzione da cui provenga la richiesta di partecipazione degli stakeholder: in qualche caso potrebbe addirittura essere il Team a chiederla, per “sviare” la necessità di un confronto interno e coinvolgere un elemento “esterno” verso cui riversare attenzione e responsabilità.

 

Errori tipici che riguardano i Developers

Anche il gruppo di sviluppatori può ricadere in tipici comportamenti disfunzionali. E va anche considerato che, a differenza che con il PO e lo SM, qui stiamo parlando di gruppo: la guida li chiama ora Developers ma stiamo parlando di un’entità di per sé complessa anche per il fatto di essere composta da un certo numero di persone, ognuna con le sue esigenze, la sua personalità e la sua propensione alla e capacità di comunicazione.

Se spetta allo Scrum Master lavorare per metterei Developers nelle condizioni migliori affinché comprendano sempre meglio Scrum, si autoorganizzino e si assumano le responsabilità che gli competono, solo i Developers possono nel concreto adottare i comportamenti individuali che, opportunamente armonizzati, ne fanno una vera e propria squadra con obiettivi comuni e buona comunicazione interna ed esterna.

Developers e Sprint Planning

Un primo, banale ma pericoloso errore ricorrente è quello dell’assenza dei componenti dei Developers in fase di Sprint Planning. Che si tratti di un solo assente o di più assenti, o addirittura di mancanza totale del team in questa fase (vedi sopra a “PO e Sprint Planning”), siamo nelle condizioni per cominciare uno Sprint nella maniera peggiore. I Developers sono parte integrante e fondamentale dello Sprint Planning.

Altro errore ricorrente è quello di dare per scontata la propria capacità di carico. Non è detto che, siccome si è fatto un determinato quantitativo di lavoro negli Sprint condotti fin qui si sarà in grado di fare lo stesso nel prossimo. Ci sono svariati elementi che possono entrare in campo e rallentare la velocità di sviluppo: l’ingresso di nuovi elementi nel team, l’assenza per malattia o per motivi più positivi di un elemento, l’abbandono di alcuni elementi che cambiano azienda o vita… I Developers devono essere consapevoli di tutto questo e sviluppare la capacità di autoorganizzarsi, rilevando la diminuzione temporanea della propria consueta capacità di carico e manifestandola chiaramente al PO in fase di pianificazione dello Sprint.

Anche per i Developers (vedi sopra “SM e Sprint Planning) c’è l’errore di contribuire a non dimensionare adeguatamente lo Sprint Backlog. Se si carica eccessivamente lo sprint con le feature da implementare, non resta tempo per colmare il sempre presente debito tecnico, per lavorare alla correzione dei bug, per condividere “scoperte” e apprendimenti, per supportarsi tra colleghi nelle urgenze o nei casi di difficoltà che possano emergere senza che fossero previsti.

Di questo deve essere consapevole da un lato il PO, ma dall’altro ci deve essere la “rivendicazione” continua da parte di SM e Developers: un Team Scrum regolarmente sovraccarico — lasciamo stare l’occasionale situazione che può verificarsi di tanto in tanto — finirà per ridurre qualità e quantità del valore che rilascia, e questo è un dato di fatto misurato in tante situazioni differenti.

Un errore non troppo diffuso, ma piuttosto pericoloso, è poi quello di lavorare su sprint di durata irregolare. Invece di stabilire una precisa cadenza per lo Sprint (due, tre o le canoniche e classiche quattro settimane), in fase di Sprint Planning si imposta una durata dello Sprint in base a “quello che c’è da fare”, ossia sono le storie scelte per lo Sprint che determinano la sua lunghezza. È l’esatto contrario di quello che Scrum propone con i suoi Sprint time-boxed, vale a dire che invece si devono scegliere le storie che è possibile implementare all’interno di un dato sprint di cadenza regolare e prestabilita.

Poi ci può anche essere la situazione in cui magari si decide di modificare, per quella sola occasione, la lunghezza standard dello Sprint, per ragioni contingenti. Ma la cadenza regolare degli Sprint e di tutte le attività ad essi connesse è una delle chiavi di volta dell’infrastruttura metodologica Scrum.

Developers e Sprint

Uno degli errori più comuni, più ricordati e comunque sempre commessi è quello di non tenere aggiornata la board. Se i ticket non vengono opportunamente mossi in maniera da riflettere lo stato corrente dello Sprint, se non si comunica chiaramente quello che si sta facendo, indicando le ragioni per cui si prende in carico un determinato task invece di un altro, il meccanismo dello Sprint si incepperà. Chiaramente è responsabilità anche dello SM che tutto questo venga facilitato e avvenga in maniera regolare, ma di fatto sono gli sviluppatori che si auto-organizzano e provvede a queste operazioni.

Altro errore tipico è quello di non porre un WIP limit sensato. Il Work In Progress deve avere un limite, secondo il principio dello “Stop starting, start finishing”, che sarà anche scontato, ma resta valido e importante. Lo Sprint deve rilasciare un incremento di prodotto potenzialmente consegnabile che fornisca valore agli stakeholder, e non risolversi nell’inizio di un numero indefinito di attività che non si sa se saranno concluse. C’è un numero massimo di task su cui il team può lavorare contemporaneamente in un certo momento, va compreso e va rispettato per migliorare il flusso ed evitare code. Creare code lunghe aumenta il periodo di tempo che intercorre tra la presa in carico di un task e il suo completamento.

Infine c’è un errore tipico che collochiamo qui e che potremmo chiamare fischi per fiaschi… Si tratta del caso, peraltro non raro, in cui lo Sprint procede bene, si lavora e si consegna qualcosa di funzionante… ma non era quello che il PO si aspettava e aveva richiesto. Qui il problema è principalmente di comunicazione e non dipende primariamente dai Developers.

Da un lato, i Developers devono chiedere lumi per ogni minimo dubbio al PO, e questo non sempre è facile quando i due ruoli si trovino lontani o il PO si assenti e così via. Dall’altro, probabilmente il PO ha raffinato la storia al punto tale che quando l’ha presentata ai Developers, questi non si sono resi conto di tutto quello che poteva esserci dietro. Quindi l’hanno implementata ma senza avere una visione di insieme che comunque è sempre necessaria. Le retrospettive servono a chiarire queste incomprensioni, nell’ottica di evitarle in futuro.

Developers e Sprint Review

Durante la Sprint Review ci sono dei comportamenti tipici che non fanno rendere al massimo questa attività. Un tipico errore è di trasformare la demo in una presentazione o in un report. Non si tratta infatti di “presentare” qualcosa, magari con PowerPoint, e nemmeno di spiegare per filo e per segno che cosa e come è stato fatto. Si tratta invece di mettere gli Stakeholder nelle condizioni di provare qualcosa di funzionante e di utilizzare questa occasione per dare e ricevere feedback.

Può essere fatto ricadere in quanto appena detto, oppure essere considerato a sé, anche il comportamento tipico dell’impiegare un portavoce. Non è un buon segno per i Developers se a partecipare alla Sprint Review sono sempre le solite due persone, e magari solo una di queste parla. Sebbene non sia necessario — ma neanche vietato — che tutti i Developers prendano parte alla Sprint Review, è importante che ci sia una rotazione dei compenenti che partecipano alla demo e ricevono feedback. Un segno di grande maturità dei Developers è quando questo non accade sulla base di “turni” decisi in maniera automatica e obbligatoria, ma si sviluppa da esigenze che di volta in volta cambiano e vengono discusse nel gruppo, nel vero spirito dell’autoorganizzazione.

Developers e retrospettiva

Vale in generale quanto detto sopra (vedi “SM e retrospettiva”) a proposito delle retrospettive di Sprint dal punto di vista dello Scrum Master (non fare la retrospettiva, fare retrospettive di bassa qualità, fare retrospettive sbagliate).

Ma se cambiamo prospettiva — perdonate il gioco di parole — e ci mettiamo nell’ottica dei Developers, emergono anche altre tipologie di errore.

Il primo è quello di considerare il tempo per la retrospettiva come un tempo supplementare per lo Sprint: in pratica, “Ci manca solo mezza giornata e poi avremmo finito le cose che dovevamo completare in questo Sprint! Quindi prendiamoci il tempo che era stato riservato alla retrospettiva per concludere il lavoro “serio” e… al diavolo la retrospettiva, tanto lo Sprint è stato concluso e pure bene. La faremo un’altra volta”. Non c’è molto da aggiungere: sembra una scelta sensata ma non lo è.

Il secondo è quello di trasformare la retrospettiva in una lamentazione collettiva: chiaramente la retrospettiva deve servire anche a tirar fuori ciò che non va, ma non deve diventare un rito collettivo di vittimismo, magari assecondato dallo Scrum Master. Alla fine della retrospettiva devono essere individuate collettivamente alcune azioni realisticamente realizzabili e che poi vanno messe in atto. Se c’è solo la fase dell’elencazione dei problemi, senza quella dell’individuazione del cammino per arrivare alle soluzioni, la retrospettiva serve a poco.

Per questo, in fase di retrospettiva, è anche buona cosa verificare cosa è stato fatto delle azioni da intraprendere che erano state individuate nella precedente retrospettiva: sono state implementate? Hanno dato qualche risultato? Le cose sono cambiate in meglio? Occorre rimanere sempre nel dominio del realistico: il cambiamento è possibile, ma è un processo lungo, che si fa passo dopo passo.

 

Conclusioni

Certamente qualche lettore avrà individuato qualche errore tipico che il suo gruppo di lavoro commette: penso — e mi auguro — che ne siano stati riscontrati ben pochi.

Ma l’elencazione, invero un po’ pedissequa, di certi comportamenti ha avuto lo scopo di stimolare e motivare a cambiamenti che sono possibili sulla strada del miglioramento continuo. Sbagliando si impara, ma continuando a sbagliare si sbaglia…

 

L'articolo Sbagliando si impara? proviene da MokaByte.

]]>
https://www.mokabyte.it/2022/06/06/sbagliando-si-impara/feed/ 0
Cybersecurity e cloud computing https://www.mokabyte.it/2022/06/06/vpncloud/ https://www.mokabyte.it/2022/06/06/vpncloud/#respond Mon, 06 Jun 2022 19:17:06 +0000 https://test.mokabyte.it/?p=8798 I servizi cloud rappresentano per le aziende un decisivo vantaggio in termini di costo, efficienza e scalabilità. Ma presentano, ovviamente, anche una serie di problemi di sicurezza che rischiano di esporre a situazioni potenzialmente pericolose. In questo articolo, originariamente scritto in inglese, ricapitoliamo alcune vulnerabilità e qualche buona pratica.

L'articolo Cybersecurity e cloud computing proviene da MokaByte.

]]>
L’ascesa del cloud computing

L’enorme crescita del cloud computing è stato uno dei fenomeni più impressionante negli ultimi cinque anni, anche se ciò probabilmente non è stato praticamente notato dalla maggior parte dei normali utenti web.

Dando uno sguardo al mercato globale del cloud computing osserviamo come si sia passati dalle cifre quasi trascurabili del 2015 ai 250 miliardi di dollari previsti per la fine del 2019, con una prospettiva di raggiungere i 620 miliardi di dollari per il 2023 [1].

Si stima che il 90% delle aziende [2] faccia affidamento sul cloud per quanto riguarda i loro servizi IT, finendo per allocare circa un terzo del budge per risorse basate sul cloud. Quando parliamo di servizi basati su cloud dobbiamo pensare a varie tipologie che spaziano dall’accesso ad applicazioni di terze parti via SaaS (Software as a Service) alle infrastrutture informatiche per intere aziende messe a disposizione come IaaS (Infrastructure as a Service). E non dimentichiamo che anche il data storage viene spesso garantito da servizi cloud, con Amazon a rivestire un ruolo di primo piano in quest’ambito.

Gli enormi vantaggi di queste tecnologie sono evidenti: si riducono le necessità di un’azienda nell’investire sull’infrastruttura “in casa” propria, lasciando il compito di soddisfare queste esigenze a specialisti cui viene demandata l’elaborazione dei dati; ciò consente oltretutto al business di mantenere maggiore flessibilità rispetto alle modalità di espansione.

La sicurezza, però

Ma in questo articolo non vogliamo parlare di questo aspetto positivo, quanto piuttosto concentrarci sul modo in cui tali benefici vengano conseguiti in tutta sicurezza.

La rapida ascesa del cloud computing ha attirato l’attenzione di “semplici” criminali, di agenzie statali di intelligence e anche di attività di spionaggio industriale; e va detto che non tutte le piattaforme cloud offrono una sicurezza ferrea. Pertanto, in queste righe, illustreremo alcune basi per l’utilizzo sicuro del cloud computing, spaziando da messa in funzione e gestione attente, fino all’uso di VPN (Virtual Private Networks, “reti virtuali private”) [3].

Ma, prima ancora di illustrare le soluzioni, vediamo di comprendere alcune delle principali minacce a cui sono sottoposte le nostre infrastrutture cloud.

 

Le principali minacce alla sicurezza del cloud

Ogni qualvolta una nuova tecnologia emerge catturando fette di mercato, la sua adozione si porta dietro dei problemi di sicurezza. È quello che è successo con il web o gli smartphone e che sta succedendo con la IoT (Internet of Things) e, certamente, con il cloud computing.

Dal punto di vista del cliente, il rischio maggiormente associato con i servizi cloud è quello della sicurezza dei dati, e a buona ragione, visto il gran numero di dati riservati che sono invece stati esposti da infrastrutture cloud.

Solo per citare un paio di esempi, nel 2017 i clienti della WWE, la più grande azienda americana che gestisce gli eventi sportivi e televisivi del wrestling professionistico, scoprirono che alcuni loro dati erano stati esposti [4] a causa di problemi di sicurezza dell’infrastruttura Amazon. E a inizi 2019 il servizio di data storage Elasticsearch ha annunciato di aver subito un attacco informatico e di aver perso dati relativi a circa 108 milioni di scommesse su vari siti di Casinò online [5].

I rischi: ragioni diversificate

Questo tipo di esposizione di dati può essere sicuramente causato da una cattiva gestione della sicurezza da parte dell’infrastruttura che immagazzina i dati, ma non sempre è così. Può infatti compromettere la sicurezza dei sistemi di immagazzinamento dati su cloud anche l’errore umano, “lato client”, attraverso pratiche quali un’inopportuna condivisione delle credenziali di accesso. Alcuni analisti, guardando in proiezione alla fine del 2020, credono addirittura che questo tipo di comportamenti sarà alla base del 95% dei “buchi” nella sicurezza dei dati [6], visto che i sistemi di sicurezza interni ai data storage vanno costantemente migliorando.

Ma che succede quando si abbassa la guardia sulla sicurezza informatica, indipendentemente dal fatto che ciò dipenda dal fornitore del servizio cloud o dall’utente finale? Le conseguenze sono molte e diversificate: dalla raccolta illegale di dati sensibili con tutti i possibili usi che se ne possono fare, agli attacchi DDoS (Distributed Denial of Service) per impedire l’uso di una risorsa di rete, dal furto di credenziali di accesso alla perdita completa di intere serie di dati. Vulnerabilità di sicurezza hardware tipo il Meltdown — in grado di colpire microprocessori Intel e ARM consentendo a programmi malevoli di accedere ad aree protette della memoria di un computer — possono avere effetti catastrofici, aprendo server virtuali ad attacchi esterni ransomware (con blocco del sistema e richiesta di riscatto) relativamente semplici.

E quindi, data la natura delle minacce insite nel cloud computing, quali azioni possiamo intraprendere?

 

Le basi per una solida sicurezza nel cloud

Di fatto, ci sono molti metodi per migliorare la sicurezza quando si tratta di cloud, e apprendere quelli fondamentali è assolutamente essenziale; e questo vale ai diversi livelli sia per gli stakeholder dell’infrastruttura informatica, sia per l’utente comune delle tecnologie cloud. Di seguito, vediamo quattro principi di buon senso e come sia possibile implementarli nel concreto.

1. (Far) rispettare protocolli rigorosi per la sicurezza delle password

Come detto sopra parlando delle minacce, gli errori umani giocano un ruolo importante nelle catastrofi che riguadano il cloud, come peraltro è vero in quasi tutte le aree della cybersecurity. Si tratta di un ambito in cui tutte le aziende possono compiere errori involontari, consentendo ai loro impiegati di mettere in atto pratiche pericolose in perfetta buona fede o, come potrebbe accadere in certi casi peggiori, addirittura di svolgere deliberatamente attacchi dall’interno.

Diventa vitale, pertanto, un addestramento regolare per quanto riguarda la sicurezza delle password. Per quanto possa sembrare banale, non ci stancheremo di ribadire l’importanza della scelta di password “robuste”, del loro periodico cambiamento e della necessità di mantenere riservate le credenziali di accesso. Se è necessario che le credenziali siano condivise, il gruppo di lavoro dovrebbe utilizzare strumenti dedicati per la gestione delle password — tipo LastPass — i quali utilizzano una cifratura per schermare i dati all’esterno.

Servono protocolli chiari che impongano l’adozione di comportamenti sicuri, fino al punto di ipotizzare anche qualche forma di “ammenda” per chi continui ad adottare una politica di password lassista. E questo deve riguadare tutti: dall’impiegato di base fino ai “piani alti” in cui si prendono le decisioni.

Non è un caso infatti che uno dei metodi più popolari per procurarsi in modo fraudolento credenziali di accesso [7] sia il whaling (“caccia alla balena”), ossia scegliere come bersaglio della frode informatica i dirigenti di alto livello, visto che sono proprio i C-level coloro che più probabilmente commetteranno errori per quanto riguarda la sicurezza delle password…

2. Adottare l’autenticazione a più fattori nelle impostazioni del cloud

Anche con le migliori intenzioni, l’errore umano comunque potrà verificarsi; e questa è la ragione per cui le aziende più diligenti adottano ulteriori forme di protezione, come politica di assicurazione. La regola generale è tanto semplice quanto evidente: fare di tutto per prevenire gli errori, ma tenere in considerazioni che essi prima o poi si verificheranno.

In tale contesto, entra in gioco l’autenticazione a più fattori (MFA, Multi-Factor Authentication). Come i lettori sapranno, nei sistemi MFA, chiunque desideri accedere a qualche risorsa cloud dovrà fornire almeno due successivi livelli di autenticazione: oltre alle “normali” credenziali di nome utente e password, potrebbero essere richiesti dati biometrici oppure ulteriori password o codici di autorizzazione generati da dispositivi hardware di autenticazione — le sempre meno diffuse “chiavette” — o inviati via SMS. Ma i sistemi sono anche altri.

I fornitori di servizi cloud a livello enterprise, come Cisco, OneDrive e Zendesk, mettono a disposizione la MFA con diverse modalità: per le aziende che usufruiscono di tali servizi, adottare l’autenticazione a più fattori è una mossa saggia per cominciare a ridurre le preoccupazioni per la sicurezza.

3. Usare le VPN per mettere in sicurezza reti e lavoratori in remoto

Le VPN (Virtual Private Networks, “reti virtuali private”) rappresentano il completamento ideale dell’autenticazione a più fattori. Pur sfruttando Internet per il loro traffico, le VPN promuovono la sicurezza dei dati scambiati attraverso vari accorgimenti. Detta molto in breve, una rete virtuale privata svolge le seguenti funzioni:

  • i dati che vengono spediti e ricevuti tra i vari utenti della VPN sono cifrati;
  • gli indirizzi IP di chi usa la VPN sono resi anonimi;
  • i dati vengono instradati su tunnel sicuri, tramite i server della VPN e successivamente trasferiti alla destinazione finale.

Le reti virtuali private possono essere usate [8] costantemente con i tool SaaS e IaaS always-on, il che rappresenta un enorme vantaggio per la maggior parte delle attività di business che fanno affidamento sui servizi cloud. Le VPN, poi, possono creare un ponte sicuro tra reti locali WLAN e piattaforme cloud distanti.

Tutto questo rende più sicure le reti aziendali e i dati che vengono inviati, limitando lo spazio utile agli attacchi informatici sulle loro connessioni cloud. Ma le reti virtuali private svolgono anche un altro ruolo nel rendere il cloud computing più sicuro: quando questi strumenti vengono installati sui computer usati da chi lavora in remoto, le VPN rendono tali dispositivi più difficili da attaccare, eliminando uno dei vettori per il furto di credenziali cloud più comunemente utilizzato dai malintenzionati.

Grandi produttori come Cisco forniscono dei prodotti VPN specificamente pensati per funzionare con le piattaforme cloud [9], mentre alcuni fornitori piuttosto conosciuti come NordVPN ed ExpressVPN possono essere utilizzati con successo per schermare le reti locali e i dispositivi in remoto.

4. Mantenere un “piano di sicurezza” attento ed adeguato

A volte certi attacchi al cloud sono causati dalla trascuratezza da parte delle aziende riguardo alle tendenze sul tema sicurezza. Qualunque sia l’applicazione usata localmente per connettersi con i servizi cloud, sarà necessario aggiornarla e applicare delle patch su base regolare, per garantire che tutte le vulnerabilità conosciute al momento vengano riparate. Un periodico e regolare controllo su tutte le applicazioni che interagiscono con la rete consente di intervenire su problemi specifici con soluzioni “locali”.

Un altro elemento che deve essere preso in considerazione è quello dei permessi. Come regola, le aziende dovrebbero limitare al minimo l’accesso ai loro servizi coud: se necessario, dovrebbe risultare facile accertarsi di quali siano i permessi disponibili a ogni utente della rete. In tal modo si limita lo spazio per attacchi da parte di interni e diventa più facile effettuare dei controlli di sicurezza nel caso sorga qualche problema.

 

Padroneggiare le basi aiuta la sicurezza del cloud

Il cloud computing non è destinato a una rapida scomparsa, anzi. L’outsourcing verso terze parti di applicazioni, database, elaborazione dati e così via è un aspetto essenziale nelle pratiche delle aziende moderne, e ha dei vantaggi in termini di efficienza, soddisfazione per il cliente e costi.

Tuttavia, come abbiamo visto, la sicurezza per il cloud è una preoccupazione reale. Seguendo le basilari indicazioni illustrate in questo articolo e valutando sensatamente le possibili “falle” nei propri sistemi, le aziende che intendono basarsi sul cloud potranno affidarsi con tranquillità a piattaforme di terze parti. In caso contrario, intrusioni e perdite di dati potranno diventare ricorrenti, con le serie conseguenze che tutti possiamo immaginare.

 

L'articolo Cybersecurity e cloud computing proviene da MokaByte.

]]>
https://www.mokabyte.it/2022/06/06/vpncloud/feed/ 0
Un sistema di monitoraggio del traffico veicolare “in tempo reale” https://www.mokabyte.it/2022/05/14/rttrafficmonitoring-4/ Sat, 14 May 2022 11:00:43 +0000 https://test.mokabyte.it/?p=8774 Introduzione Dopo aver completato la parte descrittiva dei framework, e presentata la big picture del sistema, da questa puntata vengono illustrate le integrazioni dei framework e le implementazioni di dettaglio dei moduli del sistema di monitoraggio real-time del traffico veicolare. Questa parte avrà come argomento il modulo software che simula l’invio dei dati dai veicoli… Continua a leggere Un sistema di monitoraggio del traffico veicolare “in tempo reale”

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
Introduzione

Dopo aver completato la parte descrittiva dei framework, e presentata la big picture del sistema, da questa puntata vengono illustrate le integrazioni dei framework e le implementazioni di dettaglio dei moduli del sistema di monitoraggio real-time del traffico veicolare. Questa parte avrà come argomento il modulo software che simula l’invio dei dati dai veicoli al topic di Kafka. Nella realtà ciascun veicolo sarà equipaggiato con i dispositivi e il software necessari a inviare al topic Kafka i dati oggetto di monitoraggio.

 

Componente IOT Data Producer

Di seguito viene riportato il dettaglio del progetto Java in Eclipse.

Figura 1 – Data Producer.
Figura 1 – Data Producer.

 

Inviare i dati oggetto del monitoraggio

I dati oggetto di monitoraggio come l’identificativo univoco del veicolo, il tipo di veicolo, la posizione, la velocità e il livello di carburante, nell’istante di rilevazione vengono inviati al topic di Kafka sotto forma di JSon per poi essere serializzati in una classe Java come rappresentato nel codice di figura 2.

Figura 2 – Il codice della classe di serializzazione dei dati inviati al topic di Kafka.
Figura 2 – Il codice della classe di serializzazione dei dati inviati al topic di Kafka.

 

Dichiarare i puntamenti e la lista di topic

Nello stesso progetto Eclipse viene quindi codificato un file di properties dove vengono dichiarati i puntamenti alle istanze Zookeeper e Kafka e la corrispondente lista dei topic di destinazione.

Figura 3 – Parametri di puntamento alle istanze Zookeeper e Kafka.
Figura 3 – Parametri di puntamento alle istanze Zookeeper e Kafka.

 

Una classe per inviare i messaggi

Allo stesso progetto appartiene la classe Java che implementa la generazione di messaggi e la pubblicazione di questi sul topic di Kafka (fig. 4).

Figura 4 – Classe che implementa la generazione e l’invio dei messaggi.
Figura 4 – Classe che implementa la generazione e l’invio dei messaggi.

 

Analizziamo il codice

Esaminando i commenti, possiamo facilmente individuare le linee di codice dove sono referenziati i parametri di risoluzione dell’istanza di Kafka e di quella di Zookeeper, la lista dei broker, la lista dei topic sottoscritti e, infine. la classe Java che verrà utilizzata per serializzare il messaggio pubblicato sul topic in formato JSon.

Nella stessa classe viene quindi codificata la generazione dei messaggi casuali e il loro invio al topic di Kafka. La classe kafka.javaapi.producer.Producer è una API Java di Kafka utilizzabile per creare un nuovo messaggio da inviare a uno specifico topic e, opzionalmente, a una specifica partition di Kafka.

La classe Producer è un Generic Java; pertanto sarà necessario specializzare il tipo dei due parametri. Il primo è la chiave di partizione, il secondo la classe Java di serializzazione del messaggio. In questa implementazione, essi sono rispettivamente un tipo String e la classe scelta di serializzazione del messaggio.

La classe Producer

Per l’istanza della classe Producer è necessario dichiarare le proprietà di runtime: il cluster di istanze Kafka, la classe che serializza i messaggi e l’eventuale routing verso una specifica partizione. Nel dettaglio:

  • broker.list definisce il puntamento della classe Producer verso uno o più broker per determinare il leader di ciascun topic;
  • class definisce quale classe di serializzazione da utilizzare in fase di preparazione del messaggio da inviare al broker;
  • i parametri serializer e value.serializer indicano come trasformare in byte la chiave e gli oggetti valore presenti nella classe ProducerRecord. È possibile utilizzare ByteArraySerializer o StringSerializer per tipi semplici stringa o byte.

Con il parametro partitioner.class è possibile definire la classe da usare per determinare a quale partizione del topic deve essere inviato il messaggio. Questo parametro non viene usato in questa implementazione.

L’ultima proprietà che viene presa in considerazione è request.required.acks. Questa informa Kafka che la classe Producer richiede dal Broker la conferma di ricezione del messaggio. Diversamente, si potrebbe implementare una politica fire and forget con migliori performance, ma a costo di possibili perdite di dati. Con questa configurazione viene eseguito il controllo di completezza delle richieste; il valore “all” determina il blocco fino alla full commit del record. Si tratta di una configurazione ovviamente più lenta ma più stabile. Se la richiesta fallisce il producer potrà automaticamente riprovare per un numero di tentativi definiti dal parametro retries.

Il Producer mantiene, per ciascuna partizione, un buffer con i record non inviati. Questo buffer è della grandezza specificata dalla configurazione del parametro buffer.size. Chiaramente, al crescere di questo valore si ottengono buffer di dimensioni maggiori che possono gestire batch più grandi, determinando una maggiore occupazione di memoria.

Il parametro buffer.memory controlla la quantità di memoria messa a disposizione al Producer per la bufferizzazione dei messaggi. Se i record sono inviati più velocemente di quanto possano essere accettati dal server, allora questa area di bufferizzazione verrà esaurita. Con la saturazione del buffer l’invio di chiamate aggiuntive verrà bloccato. La soglia di tempo di blocco è determinata dal parametro max.bloc.ms dopo la quale viene sollevata una eccezione di timeout (TimeoutException).

Inviare il messaggio

Di seguito la codifica Java che implementa l’invio del messaggio al topic di Kafka.

Figura 5 – Codice che implementa l’invio del messaggio  al topic di Kafka.
Figura 5 – Codice che implementa l’invio del messaggio  al topic di Kafka.

 

Dal codice Java possiamo facilmente individuare la classe che serializza le informazioni IOT e la variabile KeyedMessage necessaria al metodo send() della classe Producer. Quest’ultimo è un metodo asincrono che, quando invocato, aggiunge il record da inviare a un buffer contenente i record in sospeso, ne processa quindi l’invio concludendo così l’elaborazione. Questo permette alla classe Producer di poter raggruppare insieme singoli record per inviarli poi in modo più efficiente.

La classe Producer è di tipo Thread Safe: la condivisione di una singola istanza tra molti thread è più performante di un modello di sviluppo a istanze multiple. La classe Producer consiste in un pool di buffer di memoria dove vengono conservati i record non ancora inviati al server e di un thread in background. Quest’ultimo è responsabile di trasformare questi record in richieste e di trasmetterli al cluster di Kafka. Il mancato rilascio della variabile di istanza di questa classe determinerebbe dei memori leak di queste risorse.

Dalla versione 0.11 di Kafka la classe Producer fornisce due implementazioni aggiuntive: il Producer idempotente e quello transazionale. Il Producer idempotente rafforza la semantica di delivery da “almeno una” a “esattamente una” volta: gli eventuali tentativi aggiuntivi del Producer non introdurranno più duplicati. Il Producer transazionale permette a una applicazione di inviare messaggi a partizioni e topic multipli in modo atomico.

 

Conclusioni

In questa quarta parte è stata presentata l’implementazione del componente applicativo che simula l’invio dei dati oggetto di monitoraggio dai veicoli al topic di Kafka. Nella prossima puntata verrà descritto il secondo componente applicativo, quello che realizza la logica Spark di ingestion ed elaborazione dei dati presenti sul topic di Kafka.

 

Riferimenti

[1] Socks

socks-client

https://github.com/sockjs/sockjs-client

 

[2] Kafka

https://kafka.apache.org/quickstart

https://www.slideshare.net/mumrah/kafka-talk-tri-hug?next_slideshow=1

https://www.youtube.com/watch?v=U4y2R3v9tlY

https://kafka.apache.org/10/javadoc/org/apache/kafka/clients/producer/KafkaProducer.html

 

[3] Spark

https://spark.apache.org/docs/latest/index.html

https://data-flair.training/blogs/spark-rdd-tutorial/

https://data-flair.training/blogs/apache-spark-rdd-features/

 

[4] Spark e Cassandra data connector

https://www.datastax.com/dev/blog/accessing-cassandra-from-spark-in-java

 

[5] Zookeeper

https://www.youtube.com/watch?v=gifeThkqHjg

https://www.slideshare.net/sauravhaloi/introduction-to-apache-zookeeper

 

[6] Kafka e Zookeeper

https://www.youtube.com/watch?v=SxHsnNYxcww

 

[7] Price Waterhouse and Cooper,  The Bright Future of Connected Cars
https://carrealtime.com/all/pwc-the-bright-future-of-connected-cars/

 

[8] Hadoop

https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

 

[9] Srini Penchikala, Big Data Processing with Apache Spark – Part 1: Introduction. InfoQ, 30/01/2015

https://t.ly/FRcDu

 

[10] RDD

https://www.usenix.org/system/files/conference/nsdi12/nsdi12-final138.pdf

 

[11] WebSocket

http://jmesnil.net/stomp-websocket/doc/

 

[12] STOMP

https://stomp-js.github.io/guide/stompjs/rx-stomp/ng2-stompjs/using-stomp-with-sockjs.html

 

L'articolo Un sistema di monitoraggio del traffico veicolare “in tempo reale” proviene da MokaByte.

]]>
Verso #play14 Bologna 2022 https://www.mokabyte.it/2022/05/14/versoplay14_2022/ Sat, 14 May 2022 10:59:52 +0000 https://test.mokabyte.it/?p=8768 Ritorna la (non)conferenza sul serious gaming #play14 è una di quelle esperienze che, in questi due anni di necessarie restrizioni preventive, non è stato possibile reimmaginare e riproporre “da remoto”. Per alcune attività abbiamo imparato a cavarcela — a volta anche molto bene — con gli strumenti di connessione e lavoro collaborativo, che ci hanno… Continua a leggere Verso #play14 Bologna 2022

L'articolo Verso #play14 Bologna 2022 proviene da MokaByte.

]]>
Ritorna la (non)conferenza sul serious gaming

#play14 è una di quelle esperienze che, in questi due anni di necessarie restrizioni preventive, non è stato possibile reimmaginare e riproporre “da remoto”. Per alcune attività abbiamo imparato a cavarcela — a volta anche molto bene — con gli strumenti di connessione e lavoro collaborativo, che ci hanno consentito la prosecuzione di numerosi progetti.

Ma per un momento che è condivisione di esperienze, partecipazione anche fisica alle attività, comunicazione non verbale e divertimento, era necessario aspettare la possibilità di tornare in presenza, in sicurezza.  L’obiettivo della conferenza è stato, fin dalle prime edizioni a cui abbiamo partecipato all’estero, quello di portare la personale esperienza e le proprie conoscenze in merito all‘utilizzo di varie tecniche di  gioco tramite le quali apprendere alcuni dei concetti fondamentali dell‘Agile, del lavoro di gruppo, della collaborazione.

E così, dal 15 al 17 settembre 2022, sui colli bolognesi, torna #play14 giunto alla quinta edizione italiana. C’è grande entusiamo da parte degli aficionados ma anche molto interesse da parte di persone che hanno scoperto la unconference dedicata al serious gaming paradossalmente proprio in questi anni di sospensione.

Tutte le informazioni per partecipare alla quinta edizione italiana e acquistare i biglietti sono sul sito dedicato www.play14.it, ma in questa pagina vogliamo riportare il reportage che fu fatto nell’oramai “lontano” 2019, dopo quella che sarebbe stata, fino ad oggi, l’ultima edizione, e che fu davvero molto entusiasmante e coinvolgente.

 

——————————————————————————————

 

 

#Play14: la quarta edizione italiana

#Play14 è una “non conferenza” di due giorni dedicata al serious gaming in cui  si affronta il tema del gioco come strumento di team building, analisi retrospettiva, apprendimento, modellazione, problem solving e molto altro ancora [1].

Portata in Italia dal team di Agile Reloaded nel 2016, quest’anno la conferenza ha visto la sua quarta edizione italiana [2] dal 13 al 15 giugno, con svariate novità, a partire dalla location, che si è spostata presso il Future Lab [3], una bella struttura nei pressi di Bologna. L’alternanza tra ampi spazi all’aperto e all’interno della struttura — tra i quali una palestra autenticamente vintage — ha sicuramente contribuito alla riuscita dell’evento.

Figura 1 – La location ha offerto un’ottima alternanza tra spazi interni e all’aperto.
Figura 1 – La location ha offerto un’ottima alternanza tra spazi interni e all’aperto.

 

Durante i tre giorni, in un ambiente estremamente informale, divertente e stimolante, un centinaio di partecipanti ha potuto sperimentare  varie tematiche legate al management, al coaching, alla gestione dei gruppi di lavoro, all’analisi dei problemi e molto altro ancora. Tutto questo attraverso lo strumento del gioco serio.

Figura 2 – Il gioco è uno strumento dalle potenzialità straordinarie, applicabili nei più svariati contesti lavorativi e formativi.
Figura 2 – Il gioco è uno strumento dalle potenzialità straordinarie, applicabili nei più svariati contesti lavorativi e formativi.

 

Su queste pagine abbiamo dato conto delle precedenti edizioni — internazionali e italiane — di questa (non)conferenza atipica [4], [5], [6], [7], [8] e vogliamo raccontare qualcosa anche dell’edizione 2019, fermo restando che il racconto potrà restituire solo una visione molto parziale di tutto quel che è accaduto.

Un pubblico ampliato

Oltre alla novità della location, quest’anno abbiamo potuto riscontrare un certo rinnovamento nella composizione dei partecipanti: accanto a uno zoccolo duro di agilisti che hanno trovato nel serious gaming uno strumento per le loro attività di agile coaching, i presenti arrivavano da una più ampia “platea” professionale e di interessi. Era una tendenza già in atto dallo scorso anno, ma in questa edizione bolognese è stata confermata.

Un percorso di avvicinamento

Quest’anno [il 2019, n.d.r.], poi, al #Play14 “plenario” di giugno si era arrivati dopo un “tour” di #miniplay14 svoltosi nella prima parte del 2019. In pratica, si è trattato di una serie di eventi brevi, in genere in orario serale, a partecipazione gratuita, in svariate città d’Italia, in cui i partecipanti potevano sperimentare in piccolo i contenuti e le dinamiche di un #Play14: una sorta di assaggi, di “degustazione” che ha consentito a chi è intervenuto di farsi un’idea e magari di optare per la partecipazione alla (non)conferenza plenaria del 13-15 giugno.

 

Rompere il ghiaccio in una (non)conferenza

#Play14 si è svolto sulla consueta durata delle due giornate e mezzo, con il pomeriggio del giovedì dedicato a eventi “sociali” utili per conoscersi e rompere il ghiaccio in vista delle due giornate successivo. Queste attività icebreaker, per quanto spesso anche piuttosto semplici, risultano di fondamentale importanza al fine di creare fin da subito un clima rilassato, di condivisione, di collaborazione, senza certi freni comportamentali che sono normali invece nel consueto contesto di lavoro.

Quest’anno gli organizzatori avevano organizzato due sessioni di serious social game. Nella prima, denominata Human Bingo, i partecipanti, un po’ come nella tombola dovevano completare la propria tabella dove i numeri della tombola erano sostituiti da una “matrice di competenze”, come direbbero quelli bravi: dal saper suonare un kazoo all’aver cinque gatti a casa al coltivare insalata in terrazza.

Nel prosieguo della serata, i partecipanti hanno sperimentato metodi alternativi per lavorare insieme: conoscersi vuol dire anche guardare oltre le apparenze (si doveva realizzare un ritratto del proprio compagno di gioco disegnato su una busta di carta) e questo può essere fatto a un tavolo, su un prato o perché no, all’interno di una vecchia auto.

Figura 3 – (Non) scegliere la location è il modo migliore per accendere la fantasia, il pensiero laterale e dar vita a nuovi modi di pensare fuori dagli schemi.
Figura 3 – (Non) scegliere la location è il modo migliore per accendere la fantasia, il pensiero laterale e dar vita a nuovi modi di pensare fuori dagli schemi.

 

Pura energia

Altro gioco davvero semplice per scaricare lo stress e attivare la parte del nostro cervello più creativa e innovativa è la battaglia di palline, ossia liberare la propria energia e urlare con tutta la voce che abbiamo.

Figura 4 – La battaglia di palline è un altro modo semplice per rompere il ghiaccio e far entrare le persone in una condizione informale e collaborativa.
Figura 4 – La battaglia di palline è un altro modo semplice per rompere il ghiaccio e far entrare le persone in una condizione informale e collaborativa.

 

In genere, i giochi hanno bisogno di un bravo facilitatore che sappia guidare e regolare le dinamiche di gruppo, suggerire e stimolare i partecipanti.  Ma a #Play14 in molti casi il facilitatore non serve. I giocatori si inventano nuovi modi di intendere il gioco, nuove soluzioni compatibili con il regolamento ma totalmente innovative rispetto a quanto proposto.

In poche ore, tutto già acquista un’aura differente: con l’arrivo della sera, le persone sembrano  conoscersi da una vita, il clima è ormai quello del gruppo di amici. Si è già appreso qualcosa e si è pronti per i due giorni di (non)conferenza che seguiranno.

 

Marketplace e attività

Se il primo giorno serve per socializzare, conoscersi e rompere il ghiaccio, con il venerdì la conferenza entra nel vivo con il programma dei serious games.

Dato che si tratta di una unconference, il programma viene stabilito direttamente dai partecipanti secondo il classico meccanismo del marketplace: chi lo desidera può fare una  proposta che andrà a comporre il programma della giornata.

Figura 5 – Con il format del marketplace tipico della unconference, il programma della giornata si compone al mattino, grazie alle attività proposte dai singoli partecipanti, sulle quali poi si andranno a distribuire i partecipanti.
Figura 5 – Con il format del marketplace tipico della unconference, il programma della giornata si compone al mattino, grazie alle attività proposte dai singoli partecipanti, sulle quali poi si andranno a distribuire i partecipanti.

 

Ogni partecipante può proporre giochi dai temi e dalle dinamiche più disparate: dal team building, alla comunicazione, al pensiero laterale.

Molti modi per pensare

Quest’anno svariate attività si sono concentrate sul “pensiero”, sulle sue varianti, sulle sue dinamiche.

I giochi presentati da Alessandro Bogliolo sono molto interessanti per allenare il pensiero computazionale, capacità che mettiamo in atto ogni volta che dobbiamo, per esempio, svolgere un ordinamento o reperire un’informazione. Alessandro è professore ordinario di Sistemi per l’elaborazione dell’informazione all’Università di Urbino, dove conduce studi e ricerche nel campo delle tecnologie digitali applicate all’innovazione sociale.

Figura 6 – Alessandro Bogliolo coordina la creazione di un calcolatore umano: i partecipanti, organizzati secondo un reticolo che riproduce gli stati logici dei bit, simulano alcune semplici computazioni.
Figura 6 – Alessandro Bogliolo coordina la creazione di un calcolatore umano: i partecipanti, organizzati secondo un reticolo che riproduce gli stati logici dei bit, simulano alcune semplici computazioni.

 

Altro aspetto interessante relativo al “pensiero” in senso lato è quello messo in luce nel gioco Chaos Brain. C’è in molti la radicata la convinzione che il nostro cervello riesca a svolgere bene più processi nello stesso tempo. Questa idea si è concretizzata in pratiche lavorative volte ad aumentare la produttività e sopperire alle disfunzioni organizzative, i colli di bottiglia, le infinite attese. Ma come scoprirono gli inventori dell’approccio lean alla produzione, maggiore è il numero di cose  che facciamo in parallelo, minore sono le performance complessive. Chaos Brain è un divertente gioco che mostra come sia impossibile eseguire movimenti complessi, fare calcoli ed esercizi di logica allo stesso tempo. Il nostro cervello è sicuramente capace di fare molte cose in contemporanea, ma i risultati sono decisamente migliori se le facciamo una per volta.

Su un binario vicino al precedente, viaggia un particolare modo di giocare Happy Salmon: alcuni giochi funzionano meglio se ci mettiamo in una condizione di difficoltà. Alcuni partecipanti, allora, hanno provato a giocare ad Happy Salmon indossando delle bende sugli occhi. Un gioco svolto normalmente ad altissima energia e velocità mette in luce tutt’altre caratteristiche e richiede competenze differenti se si viene momentaneamente privati della vista.

Un po’ diversa, ma sempre legato ad aspetti del pensiero, è stata l’attività presentata da Pino Decandia: il gioco proposto affrontava il tema delle dinamiche decisionali, mettendo in luce le differenze che emergono quando ci troviamo all’interno oppure all’esterno della nostra area di comfort. La nostra vita ci vede in costante passaggio dalla zona di comfort a quella di influenza, dove le nostre azioni possono solo influenzare il comportamento degli altri e il contesto. Le azioni che compiamo appartengono all’area detta sfera di competenza.

Collaborazione e cooperazione

Molti giochi sono risultati interessanti perché sono riusciti a unire una componente di energia con la logica e alcuni principi di teoria dei processi.

Il gioco presentato da Piergiorgio Lovato divideva i partecipanti in squadre che dovevano “traghettare” i compagni su una improvvisata barella fatta di nastro adesivo. Lunghezza del nastro usato e numero di kg trasportati sono fattori che influiscono sulla performance della squadra e sul punteggio finale. Oltre alla capacità di collaborare in gruppo è necessario saper applicare pensiero laterale, strategie di problem solving, oltre che alcuni principi basilari della Lean Production.

Figura 7 – Il gioco prevedeva di trasportare dei compagni con una barella improvvisata fatta di nastro adesivo: servono capacità di collaborazione, soluzione dei problemi, pensiero laterale.
Figura 7 – Il gioco prevedeva di trasportare dei compagni con una barella improvvisata fatta di nastro adesivo: servono capacità di collaborazione, soluzione dei problemi, pensiero laterale.

 

Il gioco presentato al sabato da Luca Bergero fa uso di una serie di carte, che servono a stimolare un confronto sul modo in cui lavoriamo insieme verso uno stesso obiettivo e sul modo in cui comunichiamo. In questo caso, a emergere era il concetto di cooperazione: insieme tutti vinciamo o tutti perdiamo.

Kanban al ristorante

Qual è il modo migliore per imparare uno strumento di gestione del processo? Provarlo in pratica. E così al pomeriggio del secondo giorno, i partecipanti divisi in gruppi hanno sperimentato Kanban partecipando al gioco Kanban bruschetta, una implementazione realistica dei principi della produzione snella, dove si univa la teoria lean con la cucina.

Ogni squadra doveva implementare il processo di lavorazione secondo i classici principi lean: “stop starting, start finishing”, WIP limit, flow management. L’oggetto della lavorazione erano le bruschette… che poi avremmo mangiato a cena. La gara, svoltasi in iterazioni, prevedeva l’aggiunta a ogni passaggio di un dettaglio volto a condizionare — e migliorare — le prestazioni dei team: backlog ordinato, definizione del processo, limite ai compiti svolti in contemporanea, gestione del flusso.

 

Olympics Serious Games

Il terzo giorno, per una volta “contravvenendo” al classico schema del marketplace, gli organizzatori hanno proposto una competizione a squadre in cui sono stati effettuati svariati giochi in sequenza: lo zoom infinito, la collaborazione cieca, lo helium stick e il puzzle collaborativo.

 Figura 8 – Il terzo giorno è stato caratterizzato dalle “olimpiadi” del gioco serio: una serie di attività in sequenza, con una competizione a squadre.
Figura 8 – Il terzo giorno è stato caratterizzato dalle “olimpiadi” del gioco serio: una serie di attività in sequenza, con una competizione a squadre.

 

Tutti i giochi erano accomunati dal concetto di sfida, ma anche di collaborazione, fra squadre differenti, oltre ovviamente alla collaborazione all’interno di ogni team.

 

Conclusioni

Vedere seri professionisti, provenienti da ambiti lavorativi e aziendali diversi e a volte lontani tra di loro, che si trasformano per tre giorni in una giocosa folla di scalmanati può apparire a qualcuno discutibile, ad altri un’ottima cosa.

In realtà sono di grandissimo valore gli spunti, le riflessioni, gli apprendimenti, il confronto che solo un evento fuori dagli schemi come #Play14 è in grado di suscitare. Confidiamo in un’ulteriore edizione, in cui l’energia e la passione delle molte persone coinvolte possano ancora una volta concretizzarsi in attività formative e divertenti.

 

Riferimenti

[1] Il sito internazionale di #play14

https://play14.org/

 

[2] Il sito dell’edizione italiana di #play14

https://www.play14.it/

 

[3] FutureLab, la location dell’edizione 2019

http://www.futurelab.red/

 

[4] Giovanni Puliti, #Play14 Edizione 2014 – Reportage dalla unconference sul serious gaming. MokaByte 194, aprile 2014

https://www.mokabyte.it/2014/04/play14/

 

L'articolo Verso #play14 Bologna 2022 proviene da MokaByte.

]]>
Product Owner: chi è? https://www.mokabyte.it/2022/05/14/po_whois/ Sat, 14 May 2022 10:45:09 +0000 https://test.mokabyte.it/?p=8765 Le parole sono importanti! Tratto dal film Palombella rossa del 1989, divenne citazione frequente quella del dialogo tra il personaggio di Michele Apicella — alter ego di Nanni Moretti — e la giornalista che gli faceva rileggere l’intervista da lui rilasciata in precedenza. Il personaggio interpretato da Moretti criticava il linguaggio con cui era scritto… Continua a leggere Product Owner: chi è?

L'articolo Product Owner: chi è? proviene da MokaByte.

]]>
Le parole sono importanti!

Tratto dal film Palombella rossa del 1989, divenne citazione frequente quella del dialogo tra il personaggio di Michele Apicella — alter ego di Nanni Moretti — e la giornalista che gli faceva rileggere l’intervista da lui rilasciata in precedenza. Il personaggio interpretato da Moretti criticava il linguaggio con cui era scritto l’articolo, infarcito di anglicismi e luoghi comuni. “Le parole sono importanti. Chi parla male, pensa male e vive male. Bisogna trovare le parole giuste. Le parole sono importanti” affermava sconsolato un ossessivo Nanni Moretti.

Con tutta la simpatia — e la nostalgia — per quella stagione morettiana, non siamo così ossessionati e non vogliamo certo scrivere alcune note che si basino sostanzialmente solo sulla pedanteria linguistica. Però, una qualche precisazione su una tendenza a cui assistiamo in questi ultimissimi anni la vogliamo fare.

Ma in fondo… è project management, no?

A essere precisi, no. E in questo articolo cerchiamo di capire perché parlare del Product Owner come di un Project Manager agile è scorretto e fuorviante.

Potremmo tagliar corto dicendo semplicemente che:

  • in un caso (Product Owner, PO) parliamo di un responsabile di prodotto che deve massimizzare il valore del lavoro svolto da uno Scrum Team [2], nell’altro (Project Manager, PM) di un gestore di progetto che, giorno dopo giorno, gestisce il progetto per conto del Project Board entro specifici vincoli e con adeguate relazioni, lungo tutto il corso del progetto, con il Project Board e la Project Assurance [3];
  • Scrum è un’infrastruttura metodologica leggera pensata per aiutare persone, team e organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi; non va considerato come un metodo di Project Management: e infatti non prevede dei Project Manager, ma individua e definisce chiaramente altri ruoli, tra cui il Product Owner.
  • le parole sono importanti, come diceva Moretti, nel caso ce lo fossimo dimenticato J

Con questo, si potrebbe chiudere, ma sarebbe ingeneroso, oltre che banale. In realtà, proviamo a chiederci anzitutto perché in molti parlano di un Project Manager agile quando fanno riferimento al Product Owner (PO).

 

Le ragioni della confusione

Sono diverse le ragioni per cui tale fraintendimento si è diffuso, alcune abbastanza ingiustificate, altre con un’oggettiva base comprensibile, a voler essere onesti intellettualmente e non “fondamentalisti dell’agilità”.

“Pigrizia” nel cambiamento di mentalità

Tra le prime mettiamo sicuramente il fatto che in svariati contesti il passaggio ai principi e alle pratiche Agile è stato recepito più come una “riverniciatura” di certe strutture preesistenti, che come un vero e proprio cambiamento di mentalità e di comportamenti radicale, per quanto progressivo.

C’è quindi spesso la tendenza a voler semplicemente “rimarchiare” certe figure e certe attività, tradizionalmente presenti in azienda, con nomi nuovi e legati al mondo dell’agilità, ma senza che poi cambino le strutture profonde ad esse sosttostanti. Così un Product Owner può venire percepito come un Project Manager in versione agile.

Questo è anche normale, ed è uno scotto che occorre pagare con la diffusione sempre più ampia e pervasiva delle metodologie agili nelle grandi aziende e con l’adozione — o il tentativo di adozione — di una “mentalità” agile in un ambito organizzativo e produttivo spesso lontano da quelli di sviluppo del software nei quali infrastrutture metodologiche come Scrum sono nate e si sono evolute.

Ma anche se si capisce il meccanismo, discorso ben diverso è accettare questa visione.

Coincidenza di competenze

Ben più sensato è l’argomento per cui, prendendo in esame alcune competenze che sia il Product Owner che il Project Manager hanno in comune, e anche alcune attività simili che essi svolgono, si finisce per concludere che, con certe sovrapposizioni, anche le due figure possono essere “confuse”.

E allora, prima di vedere le nette e sicure differenze, vediamo proprio questo aspetto.

 

Competenze e caratteristiche comuni a PO e PM

Alcune caratteristiche, certe competenze, persino determinati tratti “caratteriali” sono comuni sia a un buon Product Owner che a un Project Manager. Basterebbe citare la capacità di organizzazione, la leadership, la comunicazione efficace.

Capacità di organizzazione

Sia un PO che un PM devono essere persone capaci di autorganizzarsi, sul lavoro e nella vita in generale, ma non tanto grazie a una disciplina “militare”, quanto piuttosto alla capacità di vedere il quadro generale della situazione e comprendere sempre a che punto ci si trova e quali sono le relazioni con gli altri attori dello stesso scenario.

Leadership

Si potrebbe aprire un capitolo infinito sugli stili di leadership [4], e di sicuro esiste qualche differenza sul modo di concepirla tra Project Management di stampo “tradizionale” e ruoli previsti nelle varie pratiche Agile. È indubbio però che la leadership — intesa come capacità di prendere decisioni, di essere di esempio, di aiutare le persone a trovare la loro via e a dare il meglio in quello che fanno, di far crescere la motivazione — debba essere competenza comune sia al PM che al PO. Magari ci saranno aspetti su cui insisterà maggiormente il PM e altri su cui si concentrerà di più il PO. Ma di certo, senza una sana capacità di leadership — che non è semplice “comando” — le due figure non potranno dirsi complete e in grado di svolgere le loro attività.

Comunicazione efficace

Visto che devono costantemente relazionarsi con i diversi attori coinvolti nel processo, sia il PO che il PM devono essere in grado di comunicare efficacemente con clienti, management, componenti dei team di sviluppo, utenti finali, fornitori e, in definitiva, con tutti coloro che possano ricadere nell’ampio “contenitore” degli stakeholders.

Solo similarità?

Se quanto detto sopra sicuramente favorisce la “confusione” di denominazioni di cui stiamo parlando in questo articolo, è anche vero che, in aggiunta alle competenze comuni, ci sono invece degli aspetti che caratterizzano maggiormente l’una o l’altra figura.

Solo per citarle in breve, a un bravo PO è richiesto ad esempio un approccio maggiormente imprenditoriale: non è semplicemente il direttore di un progetto organizzato in gran parte da altri per “costruire” un prodotto pensato da altri ancora, ma svolge un ruolo in cui il legame con il prodotto da realizzare è più stretto, partecipativo, e in cui le decisioni che deve prendere richiedono un’ampia visione sull’intero ciclo produttivo, dall’idea al prodotto finito

Di contro, a un bravo PM, sono richieste, ad esempio, grandi doti di negoziazione, e di gestione del tempo, che chiaramente anche un PO deve avere, ma che, in un processo Scrum sono spostate maggiormente su altri ruoli.

 

Differenze sostanziali

Al di là della parziale coincidenza di competenze, ci sono alcune nette differenze tra il Project Manager e il Product Owner. Prima di vedere la diversità nelle attività che svolgono, soffermiamoci brevemente su un concetto spesso ripetuto, ma tante volte lasciato un po’ in sospeso.

Le parole sono importanti, ancora: la “responsabilità”

Torniamo ancora sul “tormentone” di questo articolo, perché è proprio dalla comprensione della differenza tra due parole che possiamo capire una prima e significativa differenza tra PO e PM. Le parole che ci interessano sono inglesi e, in questo caso, è davvero difficile scegliere un corrispettivo italiano che renda esattamente il loro significato.

Se infatti guardiamo ciò che la bibliografia corrente dice a proposito delle figure di PM e di PO, scopriamo che entrambi sono ritenuti “responsabili” delle attività che svolgono. Il fatto, però, è che si tratta di una responsabilità indicata con due diversi termini inglesi: responsibility e accountability.

Responsibility vs accountability

Per farla breve: il Project Manager è ritenuto responsible di gestire alcune attività e svariate persone [3], mentre il Product Owner è accountable [5]. Per quanto entrambi i termini siano traducibili in italiano come “responsabile” — e di fatto “responsabile” è la parola usata anche nella traduzione italiana della Guida Scrum — c’è una differenza neanche troppo sottile.

In inglese, responsible indica chi si prende carico di una determinata attività, o chi o cosa ha un’influenza nel far accadere un evento, ma non indica un’implicito obbligo di rispondere delle conseguenze.

Se invece si è accountable, si presuppone che si sia responsabili nel senso di dover rispondere personalmente delle conseguenze delle proprie azioni e/o omissioni. Non è pedanteria linguistica: è una differenza semantica significativa. E vuol dire che il Product Owner è davvero più “imprenditore” rispetto al Project Manager a cui sono demandati compiti di gestione più “esecutivi” — sicuramente di alto livello e di cui è responsabile — ma con l’accountability che nel Project Management tradizionale viene invece imputata a chi lo incarica, perché il PM non è il “proprietario” del prodotto.

 

Le attività di un PO

Oltre a questa sostanziale differenza nella responsabilità, un altro modo, probabilmente ancora migliore, per stabilire chiaramente che un Product Owner non è un Project Manager agile è porre attenzione alle attività che un PO è chiamato a svolgere e che appariranno in gran parte diverse da quel che invece fa un Project Manager già a una lettura semplicemente non superficiale.

Alcune attività che sicuramente rientrano tra quelle che un PO è chiamato a svolgere sono le seguenti.

  • Essere “responsabile” del successo o del fallimento del prodotto che cura. E questo lo abbiamo spiegato diffusamente sopra.
  • Avere una visione che, tenendo in considerazione tutti gli stakeholder, tracci una direzione “unificata” per quello che il prodotto deve diventare.
  • Fornire le risorse necessarie allo sviluppo del prodotto, il che può significare essere in grado di autorizzare il necessario finanziamento.
  • Garantire un supporto continuo e facilmente individuabile per il prodotto.
  • Rendere massimo il valore del prodotto nei confronti di clienti, utenti e organizzazione che lo crea. L’abbiamo già detto: il PO è il “proprietario” del prodotto e diventa responsabile del fatto che questo prodotto crei quanto più valore possibile, in tutte le direzioni. Chiaramente, questo implica di doversi occupare del ROI (Return On Investment), del budget a disposizione, della cosidetta TCO (Total Cost of Ownership) e di altri aspetti che riguardano il ciclo di vita del prodotto.
  • Il PO, poi, deve occuparsi della tenuta del Product Backlog, che è in molti casi individuata come la sua attività “istituzionale” principale, ma che non è l’unica, per quanto richieda grande dedizione: definire chiaramente gli item del Product Backlog, ordinarli secondo priorità, raffinarli in modo da ottenere elementi di dimensione lavorabile, e rendere tutto questo facilmente visibile e comprensibile agli attori coinvolti nel processo, assicurandosi che lo Scrum Team abbia il materiale su cui poter lavorare negli sprint successivi.
  • Di non minore importanza è la tenuta dei rapporti con gli stakeholder, affinché tutti siano allineati alla visione del prodotto e agli obiettivi produttivi e di mercato. Significa, in pratica, invitare le persone giuste, nel senso di effettivamente interessate, alla Sprint Review, illustrare e discutere lo stato attuale del Product Backlog senza perdere di vista gli obiettivi, tener traccia del lavoro che ancora rimane da completare e, perché no, fare delle previsioni senza cadere nella trappola delle stime. Il tutto mantenendo il backlog sempre visibile a tutti gli stakeholder.

Quel che un PO non dovrebbe fare

Accanto ai suoi compiti, se elenchiamo brevemente quel che un Product Owner non deve fare, ci avviciniamo sempre più alla comprensione del perché il PO non è un PM “agile”.

Infatti il Product Owner non riceve gli input dai vari stakeholder per tramutarli in esecutività, ma piuttosto illustra la sua visione sul prodotto ai vari attori coinvolti e ne raccoglie il feedback: sembra una questione quasi sofistica, ma è invece un ribaltamento sostanziale rispetto a quello che dovrebbe fare un Project Manager.

E così, un PO non si occupa di creare e gestire una estesa documentazione di piani di progetto: non passa il suo tempo a scrivere documenti di avvio del progetto, piani predittivi a semestri o anni, diagrammi di Gantt o classica documentazione di questo tipo. E non si occupa neanche di controllare in maniera stretta i tempi e i progressi del team, magari allocando e riallocando continuamente “risorse umane” in un’ottica di ottimizzazione. L’abbiamo ripetuto allo sfinimento: il PO non è un PM dentro Scrum.

E infine, il PO non è un’“interfaccia” tra lo Scrum Team e il mondo esterno: per quanto a volte appaia svolgere questo compito, in realtà è l’intero Scrum Team che partecipa alle attività in cui sono coinvolti anche altri stakeholder, e il PO non svolge quindi alcun servizio di procura.

 

Conclusioni

Abbiamo visto un quadro — a onor del vero neanche esaustivo — sui motivi per cui un Product Owner non debba essere considerato un Project Manager agile. A di là di alcune competenze comuni tra i due ruoli e del fatto che alcune attività possano anche coincidere, le differenze sono sostanziali e tali da non consentire questa semplificazione: il PO è una figura non facile da svolgere al meglio ma che trova le sue caratteristiche principali nel suo tratto “imprenditoriale”, legato alla visione del prodotto e al suo ciclo produttivo, nella sua capacità di creare, ordinare e manutenere un Product Backlog — cioè un “manufatto” legato a un prodotto, più che un documento legato a un progetto — e, in ultima analisi, nel massimizzare il valore del prodotto per tutti gli attori coinvolti.

 

Riferimenti

[1] Ken Schwaber & Jeff Sutherland, The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game, november 2020
https://www.scrumguides.org/scrum-guide.html

 

[2] La traduzione in italiano della Guida Scrum, edizione 2020
https://www.scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Italian.pdf

 

[3] La voce “Project Manager” sul wiki Prince2®
https://prince2.wiki/roles/project-manager/

 

[4] Fabio Ghislandi, Accidenti! Non è command & control! Stili di leadership in un contesto agile. MokaByte 225, febbraio 2017
https://www.mokabyte.it/2017/02/stilileadershipagile/

 

[5] La figura del Product Owner come descritta nella guida in lingua inglese
https://scrumguides.org/scrum-guide.html#product-owner

 

L'articolo Product Owner: chi è? proviene da MokaByte.

]]>
Come monitorare l’avanzamento dei lavori in Agile https://www.mokabyte.it/2022/05/14/sal_agile/ https://www.mokabyte.it/2022/05/14/sal_agile/#respond Sat, 14 May 2022 10:25:22 +0000 https://test.mokabyte.it/?p=8760 Se in Agile parliamo di valore rilasciato e dell’importanza di creare un prodotto di soddisfazione per l’utente, perché ci ostiniamo a voler parlare di avanzamento di progetto? Ma poi interessa a l’utente a che punto siamo? O gli interessa quante cose utili abbiamo prodotto? E infine perché usiamo il tempo per misurare l’avanzamento? Forse serve qualcosa di differente.

L'articolo Come monitorare l’avanzamento dei lavori in Agile proviene da MokaByte.

]]>
SAL per ogni progetto

Siamo abituati a considerare lo Stato di Avanzamento di Progetto (SAL) come un progresso delle funzioni da implementare misurato su scala temporale. Nel Project Management tradizionale ci è stato insegnato a misurare questo SAL per mezzo di complicate tabelle, calendari, WBS, diagrammi Gantt e altre diavolerie del genere.

Questo approccio si basa su un assunto di fondo, peraltro antitetico a quello che abbiamo in Agile: quanto abbiamo fatto fino ad oggi, misurato su quanto avevamo in mente di fare in totale. Per questo si fa un piano upfront e poi, passo dopo passo, si cerca di capire a che punto siamo su quel piano. Quante funzionalità abbiamo implementato? Quante parti sono già finite? Come siamo messi coi tempi di consegna?

Ovviamente questo approccio si basa sul poter stimare “correttamente” il tempo per fare le cose e prevedere quanto ne manca al completamento di tutte le parti. Qualcuno si avventura  a misurare questo avanzamento in tempo puro (tempo trascorso / tempo totale preventivato) o risorse (soldi spesi ad oggi / budget complessivo).

Ci sono due aspetti di questa concezione che “stonano”  quando si guarda il progetto con un approccio Agile: il quando e il cosa. E prima di vederli nel dettaglio, occorre un’ultima premessa: non si fa agile, ma si è agili.

“Agile” è aggettivo con cui connotare un insieme di valori e principi a cui ispirarsi per mettere in campo pratiche: lo scopo è costruire prodotti che rilascino valore all’utente finale. Per questo pensiamo che non abbia troppo senso parlare di un “progetto agile”. E forse, anche “Agile Project Management” è una etichetta che ci piace poco: meglio parlare di prodotti e di valore.

Nonostante questo, per semplicità e chiarezza espositiva, chiameremo “progetto agile” un lavoro volto a produrre un prodotto o servizio di valore per l’utente e che si ispiri ai principi dell’agilità fra cui il miglioramento continuo del processo di lavorazione, la creazione di un prodotto in modalità  iterativa grazie ai feedback dal campo, la collaborazione fra business e dev, l’adattamento ai cambi di scenario.

 

Primo punto: il “quando” non è quello che ci serve

Misurare l’avanzamento di progetto su tempi determinati in fase di pianificazione ci porta di fronte a un problema evidente: i tempi ipotizzati saranno affetti da un errore molto ampio, per cui può essere poco utile costruire un piano di rilascio sulla base di una previsione che ha per definizione un livello di incertezza piuttosto alto.

Poi, non è detto che le funzionalità immaginate al giorno 0 siano esattamente quelle che realmente ci servono, o che ha senso fare: lo scopriremo meglio a mano a mano che procediamo.

Nella pratica infatti accade che, in gran parte dei progetti — quelli già “agili” per definizione ma anche in quelli “tradizionali” per forza di cose — le tempistiche sono costantemente riadattate e lo scope modificato.

Per questo in Agile ci diciamo spesso che il focus dovrebbero essere sul valore rilasciato e non tanto su tempi e costi: è il famoso “triangolo rovesciato”.

Figura 1 – L’approccio agile mantiene i classici vincoli del Project Management tradizionale, ma ne ribalta i rapporti di importanza.
Figura 1 – L’approccio agile mantiene i classici vincoli del Project Management tradizionale, ma ne ribalta i rapporti di importanza.

 

Per questo al Gantt e al calendario preferiamo un approccio empirico  e consuntivo; la rigida WBS diventa un dinamico Product Burn Down Chart che può, anzi deve, cambiare. Il SAL sul Gantt diventa un Burn Down Chart e il piano previsionale fatto a inizio progetto diventa un piano che si adatta di sprint in sprint sulla base delle reali potenzialità del gruppo di lavoro, e dell’ecosistema al contorno.

 

Secondo punto: neanche il cosa è quello che ci serve

La figura 1 mette in luce un aspetto fondamentale dell’approccio agile, ovvero che fissando tempi e costi, si può variare sullo scope, piuttosto che il contrario. Ma perché mai dovremmo non completare tutte le feature di sistema? Perché dovremmo fissare la data di scadenza e impegnarci per non  superarla? Non è forse una resa? “Tanto non ce la faremo a fare tutto, vediamo cosa riusciamo a fare per la data di scadenza, poi decidiamo”. In parte c’è del vero in questa presa di coscienza…

Ma c’è dell’altro. Partiamo dal backlog: sappiamo che contiene tutte le domande a cui dobbiamo rispondere per soddisfare i bisogni utente. Sappiamo che è ordinato per priorità, che in alto ci sono le cose di valore. Sappiamo che soddisfare anche una minima parte potrebbe comunque fornire una quota importante del valore complessivo.

Figura 2 – La classica schematizzazione del product backlog.
Figura 2 – La classica schematizzazione del product backlog.

 

Quindi, se da un punto di vista delle cose fatte possiamo fare una media aritmetica, parlando di valore rilasciato — ossia del senso di quello che stiamo facendo — occorre pesare il contributo di ogni elemento del backlog.

Vediamo di spiegare meglio con un esempio: immaginiamo di avere un backlog di 100 elementi e ipotizziamo che avendoli stimati tutti, tali items diano complessivamente 1000 punti effort. Come chi lavora in Scrum già sa, per punti effort si intendono proprio quelli che il team usa per stimare le user stories e con i quali poi si aggiorna a fine sprint la velocity e si compila il Burn Down Chart.

Figura 3 – Un normale Burn Down Chart in cui stimiamo la riduzione verso 0 dei “punti effort”.
Figura 3 – Un normale Burn Down Chart in cui stimiamo la riduzione verso 0 dei “punti effort”.

 

Il grafico di figura 3 ci dice quindi che, iterazione dopo iterazione, i punti effort rimanenti scendono per andare a zero. Se i punti erano inizialmente 1000, dopo averne realizzati 500 possiamo dire di essere più o meno a metà de lavoro? Dal punto di vista artimetico probabilmente si… ma forse serve altro.

 

Un nuovo approccio

Osservare solo il trend dei punti fatti — o di quelli che restano, come nel Burn Down Chart — non è altro che un modo differente per misurare la stessa cosa che si faceva nel Project Management tradizionale: contare quante cose abbiamo fatto e ipotizzare quante cose mancano.

Figura 4 – Rapporto tra punti del backlog e iterazioni effettuate.
Figura 4 – Rapporto tra punti del backlog e iterazioni effettuate.

 

Se vogliamo fare un reale cambio di passo, occorre mutare prospettiva e modificare radicalmente il significato di avanzamento di progetto.

In Agile è di primaria importanza focalizzare il lavoro sul rilascio di valore, sul massimizzare la soddisfazione utente e sul portargli un reale beneficio, o un nuovo, migliore, modo di fare le cose. In tal senso i punti effort non ci dicono molto: se abbiamo implementato 500 pt su 1000 pt sappiamo solo che abbiamo implementato 500 punti su un totale di 1000 ma non sappiamo nulla di quanto beneficio stiamo portando all’utente. Se per assurdo, il progetto non riuscisse a portare alcun beneficio reale anche dopo aver implementato il millesimo punto del backlog, potremmo dire di aver finito? Oppure dovremmo continuare?

E se, viceversa, dopo soli 100 punti il nostro utente fosse talmente contento di quello che ha da non volere più il resto? A che punto del progetto saremmo in quel caso? Dal punto di vista matematico al 10%, ma dal punto di vista del senso di quello che stiamo facendo, potremmo anche fermarci e dedicare le nostre energie a  un altro importante progetto.

Ma in Scrum abbiamo proprio che nel backlog, se ben organizzato, le cose in alto valgono di più, in termini di valore e di soddisfazione utente.

Figura 5 – Il backlog organizzato in chiave di punti valore. Il backlog è ordinato per valore: gli item in alto dovrebbero produrre più valore di quelli che man mano stanno sempre più in basso. Dopo aver implementato le storie in alto nel backlog, pochi punti effort dovrebbero produrre molto in termini di valore.
Figura 5 – Il backlog organizzato in chiave di punti valore. Il backlog è ordinato per valore: gli item in alto dovrebbero produrre più valore di quelli che man mano stanno sempre più in basso. Dopo aver implementato le storie in alto nel backlog, pochi punti effort dovrebbero produrre molto in termini di valore.

Punti valore

Se quindi introducessimo il concetto di “punti valore” accanto ai punti effort, potremmo dire che pochi punti effort, relativi alle storie in alto nel backlog, dovrebbero produrre tantissimi punti valore.

Se dicessimo che “La maggior parte degli effetti è dovuta a un numero ristretto di cause”, ci viene in mente nulla? Se vi dicessi Pareto?

Se prendessimo il trend dei punti effort rimanenti — come si fa con il Burn Down Chart — e lo comparassimo con il trend dei punti valore, otterremmo qualcosa di simile a quanto mostrato in figura 6: la curva del valore da erogare scende rapidamente all’inizio — si eroga molto valore e si risolvono i business needs più importanti nel progetto — per poi stabilizzarsi a tendere. Non è detto che vada a zero: vuol dire che potremmo decidere di lasciare qualcosa, tipo qualche bisogno di poco conto che potrebbe rimanere non soddisfatto.

Figura 6 – I punti effort e la velocity sono grandezze utili per il dev-team, il PO e tutti coloro che sono interessati a sapere a che punto è il progetto. Ma si dovrebbero introdurre anche altre grandezze, come per esempio i “punti valore”.
Figura 6 – I punti effort e la velocity sono grandezze utili per il dev-team, il PO e tutti coloro che sono interessati a sapere a che punto è il progetto. Ma si dovrebbero introdurre anche altre grandezze, come per esempio i “punti valore”.

 

Dal grafico si evince facilmente che, da un certo punto in poi, continuare a lavorare aggiunge poco valore o cambiamenti all’utente. Fermarsi allo sprint n o n+1 o n+m cambia poco.

Quindi lo stato avanzamento lavori assume una concezione completamente differente: invece di dire “Siamo giunti quasi a fine perché abbiamo completato tutte le funzionalità che ci eravamo proposti di fare”, possiamo dire “Siamo a un punto tale che potremmo anche fermarci, perché abbiamo già rilasciato gran parte del valore al cliente”.

Questa visione stravolge pesantemente la concezione di progetto tradizionale: “Dobbiamo fare tutto entro il”, o “Dobbiamo completare il progetto rimanendo nei costi” (scope, time, budget).

 

Cosa dobbiamo cambiare nell’operatività?

Se questo nuovo modo di considera il SAL ha un impatto molto importante dal punto di vista culturale, nella pratica della operatività quotidiana di team probabilmente le cose cambiano poco.

Un accorgimento che certamente dovremmo adottare è introdurre i punti valore su ogni item del backlog. Per esempio, si potrebbero modificare le card delle storie del backlog, introducendo uno spazio per misurare il valore in punti, analogamente a quanto facciamo con i punti effort.

Figura 7 – La scheda per la definizione delle storie riporta ora uno spazio anche per i punti valore.
Figura 7 – La scheda per la definizione delle storie riporta ora uno spazio anche per i punti valore.

 

Compito molto più difficile è invece capire come trovare le metriche per misurare il valore. Cominceremo a parlarne adesso per approfondire maggiormente nei prossimi articoli.

 

Ma come misurare il valore?

Abbiamo già trattato in passato le metriche con cui misurare il valore riportato [1]; all’epoca abbiamo parlato di misurazione della soddisfazione utente dopo che abbiamo rilasciato qualcosa; allora il tema era “Non è finito quando è finito, ma dobbiamo misurare se l’utente trova utile quello che gli abbiamo dato”.

Per quanto sia importante questo tipo di valutazione — misuriamo il beneficio del prodotto mentre l’utente lo usa — in ottica di Agile SAL è necessario valutare le cose che stiamo facendo in proiezione; in estrema sintesi il PO dovrebbe trovare il valore strategico di quello che è nel backlog.

L’argomento è molto ampio, lo affronteremo più approfonditamente nella prossima puntata, limitandoci a introdurre a livello macroscopico alcuni aspetti che potremmo prendere in considerazione per estrapolare queste metriche. Per esempio potremmo considerare:

  • Prospettiva sulla user journey: scomponendo l’intera Customer Journey in tanti passi, è probabile che ognuno di questi passi contenga al suo interno la risposta a determinate necessità. Non tutte dello stesso valore.
  • Prospettiva dei differenti stakeholders o utilizzatori: un esercizio utile è quello di introdurre differenti scale di misurazione del valore in funzione dell’utente a cui ci si rivolge. E si può fare una media, aritmetica o pesata.
  • Prospettiva su end-to-end: pensando alla Customer Journey in ottica end-to-end, non è detto che tutti i passi siano necessari o che sia necessario realizzarli con lo stesso livello di dettaglio. Suggerimento: si pensi al walking skeleton dello User Story Mapping.
  • Allineamento con la strategia dell’organizzazione e con la prioritizzazione delle iniziative: i razionali che possiamo usare per mettere in fila le iniziative di una organizzazione possono darci informazioni utili per misurare e classificare le storie di un backlog. Suggerimento: si veda Agile Portfolio Management.

 

“Prima” e “dopo” devono comunque cortocircuitarsi

Prima di lasciarsi e rimandare gli approfondimenti alla prossima puntata, è doveroso ricordare un punto fondamentale. Le metriche o i razionali che ci possono essere utili per misurare il valore rilasciato (punti valore delle storie) come presentati in questa puntata, sono di fatto valutazioni predittive: ci immaginiamo che quella particolare funzione sia più utile o di valore di quell’altra. Quando il PO mette in fila gli elementi del backlog è guidato da considerazioni di questo tipo.

Figura 8 – L’ultima slide della presentazione “Come misurare il valore di un prodotto”, tenuta allo scorso Agile Business Day 2019.
Figura 8 – L’ultima slide della presentazione “Come misurare il valore di un prodotto”, tenuta allo scorso Agile Business Day 2019.

 

Come visto in una precedente serie [1] queste considerazioni dovrebbero sempre essere confrontate con quanto poi realmente accade quando un utente usa il prodotto. Le metriche di misurazione del valore devono per forza di cose essere associate poi alla soddisfazione utente. Ricordo a tal proposito l’ultima slide della presentazione fatta insieme a Ilaria Mauric all’Agile Business Day [2].

 

Riferimenti

[1] Giovanni Puliti – Ilaria Mauric, Product Ownership e misurazione del valore di un prodotto –

I parte: Le misurazioni interne/indirette. MokaByte 247, febbraio 2019 (e articoli successivi della serie)

https://www.mokabyte.it/2019/02/productvalueownership-1/

[2] Agile Business Day

https://www.agilebusinessday.com/abd_2019-it/

 

L'articolo Come monitorare l’avanzamento dei lavori in Agile proviene da MokaByte.

]]>
https://www.mokabyte.it/2022/05/14/sal_agile/feed/ 0