Welcome

This is the generic homepage (aka Aggregate Blog) for a Subtext community website. It aggregates posts from every blog installed in this server. To modify this page, edit the default.aspx page in your Subtext installation.

To learn more about the application, check out the Subtext Project Website.

Powered By:

Blog Stats

  • Blogs - 715
  • Posts - 31092
  • Articles - 310
  • Comments - 106992
  • Trackbacks - 591064

Bloggers (posts, last update)

Latest Posts

Le novità di Build per VSALM

Sicuramente non saranno completamente esaustive, ma nel blog di Brian Harry potete trovare una serie di link a tutte le novità riguardanti la famiglia VSALM che sono state annunciate a Build.

http://blogs.msdn.com/b/bharry/archive/2015/04/29/visual-studio-and-team-foundation-server-at-build-2015.aspx 

Chiaramente la novità piu succosa è la RC di TFS e VS 2015 Smile, buon download.

Gian Maria.

posted @ 30/04/2015 9.11 by Gian Maria Ricci

[js] LazyLoad

https://github.com/rgrove/lazyload

LazyLoad is a tiny (only 966 bytes minified and gzipped), dependency-free JavaScript utility that makes it super easy to load external JavaScript and CSS files on demand.

posted @ 29/04/2015 12.23 by Alessandro Gervasoni

Non si può non Gestire

Chi mi conosce sa che tra le mie passioni c’è quella del volo, cosa che mi ha portato a simulare parecchie ore di volo, in diverse condizioni e con diversi aeromobili.

Da qualche anno finalmente il mio lavoro non riguarda meramente lo scrivere codice o analizzare un nuovo software ma anche “tentare” di gestirne il flusso di sviluppo.

C’è stata una sera, mentre era all’aeroporto di Bresso durante una lezione di Pianificazione di Volo di un loro istruttore, che ho fuso i due mondi.

Ultimamente poi, per tutta una serie di motivi che non sto qui a spiegarvi, mi sto anche avvicinando al mondo della PNL, aggiungiamo quindi anche questo terzo pilone per tirare fuori dei ragionamenti sensati.

comunicazione_efficace

Non si può non gestire

Uno dei concetti chiave della PNL è che non si può non comunicare: quando si è posti in società anche se non diciamo nulla o non rispondiamo, stiamo comunque comunicando qualcosa a chi ci osserva (o chi ci sta parlando): probabilmente comunichiamo indifferenza, disinteresse, noia, odio. Di sicuro le altre persone si faranno un’idea di noi, ovvero avremo comunicato qualcosa.

Alla stessa maniera un progetto non si può non gestire, scegliere di non gestirlo è essa stessa una gestione.

20130816_voliprivati

Un aereo non si può fermare

Uno dei concetti chiave invece della Pianificazione di Volo (o meglio della sua conduzione) è che un aereo non si può fermare.

Questo significa semplicemente che in qualsiasi situazione ci troviamo durante il volo se noi possiamo “fermarci” a ragionare, l’aereo no, portandosi ad una situazione diversa da quella sulla quale stiamo ragionando, con l’inevitabile conseguenza che le nostre conclusioni possano essere potenzialmente errate.

L’esempio è presto fatto: se siamo in volo e improvvisamente non capiamo più dove siamo (pensiamo ad essere noi i piloti di un volo turistico), quanto tempo impieghiamo, o meglio, quali risorse consumiamo per ritrovarci e riprendere la conduzione controllata del volo?

Possiamo provare a guardarci attorno, cercare una strada, un fiume, un monte, una città e confrontare con le carte in nostro possesso, ma più tempo perdiamo più ci spostiamo da dove pensavamo di essere e più carburante consumiamo aumentando quindi l’area di indecisione sulla carta e consumando risorse (tempo e carburante).

A questo punto i casi sono due: se ci ritroviamo abbiamo comunque sballato completamente la nostra stima (ricordo che nel volo la stima è obbligatoria, il piano di volo è un documento richiesto per il volo, non è una cosa “che fa comodo”) e occorre rifare tutti i calcoli con le nuove quantità di risorse, tempo e carburante (quantomeno), e ovviamente farlo senza poter fermare l’aereo, quindi ancora una volta mentre le condizioni cambiano e ulteriori risorse si consumano.

Earhart-plane1

L’altro caso invece è quello di non ritrovarsi più, con fallimento del volo stesso per esaurimento di risorse (una su tutte: Amelia Earhart).

gestione-del-tempo

Non ho tempo di gestire

Va da sè quindi che non si può non gestire un volo, esattamente come non si può non gestire un progetto: dire che non si ha il tempo di gestirlo significa arrendersi agli eventi e lasciare che l’aereo si schianti, o che il progetto fallisca.

Non esiste possibilità di atterrare senza gestire il volo, non esiste possibilità di avere successo in un progetto (successo == arrivare alla deadline, o prima, con le risorse a nostra disposizione) senza gestirlo.

Ogni momento che passiamo NEL nostro progetto senza gestirlo è comunque un momento passato consumando risorse e che non ci sta portando nella direzione voluta corretta: in questo istante abbiamo ancora meno possibilità di farcela.

Adoro la simulazione

Quante fantastiche similitudini tra la pianificazione e la conduzione di un volo e una gestione di progetto.

A chi mi chiede spesso: “allora, fai ancora simulazione di volo?”, a volte rispondo “no, ora mi diverto con la gestione progetti”.

Pochi capivano che non scherzo: Pianificare E’ Simulare.

Oppure spesso alcuni mi “accusano” di non avere passione nel mio lavoro semplicemente perché non sono li a ballare nudo quando esce un nuovo Visual Studio o un nuovo framework o tecnologia, ma nessuno si ferma a pensare che anche per gestire un progetto si può avere passione.

Voi preferite un pilota che sa pianificare il suo volo o che si diverta di più a capire tutto quello che si può fare con la cloche (e che magari lo faccia durante il vostro volo)?

posted @ 25/04/2015 10.29 by Omar Damiani

Rinominare un Team Project in VSO

Una delle funzionalità più richieste è ora disponibile in Visual Studio Online, la possibilità di rinominare un Team Project, vediamo come.

Il primo passo è andare nell’area di amministrazione tramite il link diretto  https://nomedelvostroaccount.visualstudio.com/DefaultCollection/_admin oppure semplicemente premendo il simbolo dell’ingranaggio in alto a destra. a questo punto a lato del Team Project appare la freccia del menù contestuale, da cui potete scegliere il Rename.

image

Una volta scelto il rename basta semplicemente specificare il nuovo nome.

image

A questo punto è il caso di leggere attentamente il disclaimer, l’operazione di rename project è una operazoine che porta molti cambiamenti.

image

L’aspetto più noioso è che, se utilizzate i workspace locali con TFVC, se non avete Update5RC o VS 2015RC o superiori, siete costretti a ricreare il workspace. Questo significa che se avete modifiche pendenti, dovete fare shelve, cancellare il vecchio workspace, rifarlo e rifare unshelve. Se usate git è tutto molto più semplice, perché basta cambiare il remote ed il gioco è fatto. Se vi scordate comunque il messaggio di errore che ricevete è particolarmente chiaro

image

Trovate comunque nel link http://vsalmdocs.azurewebsites.net/Library/vs/alm/admin/project-rename tutte le informazioni necessarie per svolgere queste operazioni in dettaglio, per cui non è il caso di preoccuparsi troppo. Una volta premuto il bottone Rename Project, il sistema inizia le operazioni, al termine delle quali, il vostro progetto è rinominato.

Tra le cose interessanti vi è il redirect automatico, ovvero se qualche membro del team ha memorizzato qualche url come

https://gianmariaricci.visualstudio.com/DefaultCollection/Experiments/_versionControl#path=%24%2FExperiments%2Ftrunk%2FElasticsearch%2FMusicDb&_a=contents

Andandola a mettere nel vostro browser preferito potrete notare che è ancora valida, sebbene parte della url contenga il vecchio nome del Team Project. Chiaramente se andrete a creare un nuovo Team Project con il nome del vecchio, il redirect non funzionerà più, dato che in quel caso vi starete riferendo al nuovo Team Project.

Kudo al Team di VSO per avere finalmente soddisfatto una delle richieste più votate di tutti i tempi.

Gian Maria.

posted @ 24/04/2015 18.54 by Gian Maria Ricci

Team Project Rename in VSO

Con l’update di Aprile 24, in VSO è ora disponibile il Rename per il Team Project, potete leggere tutti i dettagli in questo post. Questa funzionalità è stata per lungo tempo la piu votata di User Voice, penso quindi che questo update faccia felici molte persone.

Gian Maria.

posted @ 24/04/2015 18.36 by Gian Maria Ricci

Jsonnet

Jsonnet is a domain specific configuration language that helps you define JSON data. Jsonnet lets you compute fragments of JSON within the structure, bringing the same benefit to structured data that templating languages bring to plain text. The example below illustrates a few features -- referring to another part of the structure, overriding object fields, and string operations.

http://google.github.io/jsonnet/doc

posted @ 22/04/2015 16.09 by Alessandro Gervasoni

Microservices Saturday 2015: un viaggio con NServiceBus

Vi ricordate quando da piccoli giocavate, e magari come me lo fate ancora :-), con il LEGO?

Nel 2009 dicevo, quotando me stesso:

Se modelliamo il nostro mondo in tanti piccoli, magari molto piccoli e molto tanti…, componenti che collaborano otteniamo un modello complesso, probabilmente molto complesso, ma facilmente testabile, manutenibile, evolvibile, etc…

Al tempo il concetto era molto più in linea con il single responsibility principle che con le architetture distribuite ma se oggi mettiamo insieme quel concetto con le potenzialità offerte da una metafora come il LEGO e troviamo qualcosa che faccia da collante, leggasi messaggio, allora ecco che in un’architettura distribuita il SRP si può applicare molto facilmente scivolando nel territorio di quelli che oggi vengono chiamati “microservices”.

La teoria è apparentemente molto semplice, e non solo apparentemente, ma i dettagli e le trappole lastricano ampiamente la strada verso un’architettura distribuita che sfrutti a pieno il concetto di “microservices”.

Se volete scoprire come Servizi CGN ha abbracciato un’architettura distribuita e stia giovando di tutto ciò non potete lasciarvi scappare certe occasioni.

Accorrete gente accorrete, i posti sono si tanti ma finiscono anche alla svelta :-)
https://www.eventbrite.it/e/biglietti-microservices-saturday-2015-un-viaggio-con-nservicebus-16391462305

.m

posted @ 22/04/2015 10.42 by Mauro Servienti

Ancora novità nella Kanban Board di VSO/TFS

Nei precedenti post abbiamo parlato delle novità che sono state introdotte nella Kanban Board di VSO:

Kanban Split Column

Novità di VSO Sprint 79

Definition of Done

Nell’ultimo deploy del 10 Aprile troviamo ancora ulteriori novità. In alto a Destra, potrete trovare un nuovo link, chiamato Settings, che vi permetterà di personalizzare le colonne (opzione già esistente) e le card (la nuova opzione introdotta con questo deploy).

image

La personalizzazione delle Cards permette di scegliere quali campi del Work Item saranno visibili nelle card della board. Ecco qui il pannello delle opzioni.

image

Come potete vedere, finalmente si ha la possibilità di mostrare l’ID del work item in alto a sinistra nella card. Si può poi scegliere se visualizzare avatar e FullName o solo l’avatar o solamente il nome per la persona a cui è assegnata la card. Infine si può scegliere se mostrare l’Effort e i Tag.

La possibilità di visualizzare i Tag è particolarmente importante, soprattutto in VSO, che ammanca ancora della funzionalità di personalizzazione dei Work Item. In Kanban infatti, non si tende a fare stime esatte dell’effort per ogni card, ma spesso basta il T-Shirt sizing: Small, Medium, Large, eXtra Large. Si può pertanto utilizzare i tag per categorizzare le proprie Card, ed avere una migliore visualizzazione:

image

In questo caso è immediatamente visibile la “dimensione” della card, in maniera molto chiara ed esplicita. Ricordo inoltre, che negli sprint precedenti è stata data la possibilità di fare editing in place del titolo della card, basta cliccare nella icona della matitina in alto a destra.

image

Sebbene questa serie di post sia focalizzata sulla Kanban Board, le personalizzazioni di cui vi ho parlato sono presenti anche per la TaskBoard. Ora anche per chi usa SCRUM e vuole scomporre lo Sprint Backlog in Task, è possibile decidere quali informazioni visualizzare nelle card.

image

In questo caso potete personalizzare l’aspetto dei Product Backlog Item e dei task separatamente. La possibilità di creare elementi direttamente nella board rende molto semplice e veloce creare la propria task board, partendo dai PBI dello sprint corrente.

image

Gian Maria.

posted @ 21/04/2015 19.54 by Gian Maria Ricci

[AngularJs] ng-repeat : $index

Nei template quando si utilizza l'attributo "ng-repeat" è possibile far riferimento all'indice del ciclo con la variabile
$index.

Esempio

<a ng-repeat="i in items">
                    <span class="name">{{$index}}. {{i.name}}</span>
</a>

posted @ 15/04/2015 15.58 by Alessandro Gervasoni

GoJS : Interactive Diagrams for the Web

http://gojs.net

posted @ 14/04/2015 19.41 by Alessandro Gervasoni

URI.js

http://medialize.github.io/URI.js

URI.js offers simple, yet powerful ways of working with query string, has a number of URI-normalization functions and converts relative/absolute paths.

posted @ 14/04/2015 8.59 by Alessandro Gervasoni

Definition of Done nella Kanban Board di VSO

Negli ultimi aggiornamenti di VSO abbiamo potuto notare alcune importanti migliorie nella Kanban Board, che onestamente era stata un po’ trascurata negli ultimi tempi.

Kanban Split Column

Novità di VSO Sprint 79

Nel secondo post avevo promesso di approfondire il concetto di Definition Of Done in Kanban, perché è di fondamentale importanza per gestire al meglio il processo. Per prima cosa, fin dagli albori del template SCRUM, in TFS/VSO si può trovare il campo Acceptance Criteria per i Product Backlog Item e le Feature.

image

Dal punto di vista prettamente agile, l’acceptance criteria rappresenta l’insieme dei criteri da soddisfare affinché la singola Card/PBI sia considerata completa a tutti gli effetti quindi, essa rappresenta la Definition of Done della singola card/PBI. Il problema è come declinare questa informazione dal punto di vista di una Kanban Board.

Sicuramente tutti i criteri che si trovano nella card/PBI debbono essere necessariamente soddisfatti prima che la card finisca nell’ultima colonna. Questa condizione è sicuramente intuitiva, ma visto che non vorremmo lasciare nulla al caso, possiamo utilizzare la nuova funzionalità di supporto alla Definition Of Done nella Kanban Board di VSO per rendere questa politica esplicita.

SNAGHTML12b0967

Come si può vedere, ogni colonna, tranne la prima e l’ultima, hanno la possibilità di editare la Definition Of Done. In realtà la posizione logica migliore per questa informazione sarebbe tra due colonne, in modo da rappresentare la barriera che determina le condizioni affinché una card possa essere mossa alla colonna successiva. In questo caso invece, essendo la DoD sulla singola colonna, essa rappresenta le condizioni da soddisfare affinché una card in quella colonna possa essere considerata come Done e quindi promuovibile alla colonna successiva.

Andando ad editare la Definition of Done della colonna Testing, possiamo esplicitare la condizione precedente, ovvero che per essere considerata DONE una card deve avere tutti gli Acceptance Criteria soddisfatti.

image

Ora sulla colonna si può una nuova icona con un piccolo punto esclamativo. Cliccandoci sopra si può vedere le DoD di quella specifica colonna.

image

Di base quindi l’acceptance criteria rappresenta la DoD della singola card, ma in Kanban esiste una DoD per ogni colonna, che vale comunque per tutte le card indipendentemente dalla acceptance criteria.

Questa funzionalità è molto utile per esplicitare in maniera chiara il livello di qualità che ci si attende prima di considerare completa una card. Nulla infatti rallenta il flusso come il dover riportare una card allo stato precedente perché si è dimenticati qualcosa. Un esempio tipico potrebbe essere quello di avere il codice pronto per andare in produzione, ma accorgerci che lo schema del nostro DB SQL è cambiato e gli sviluppatori hanno dimenticato di creare gli script di migrazione. In questo caso è evidente che è necessario aggiungere una condizione nella DoD della colonna Developing.

Per chi usa la Kanban Board su VSO, non dimenticate quindi di esplicitare tutte le condizioni di transizione, ricordate infatti che uno dei principi di Kanban è: Make Process Policies Explicit e la Definition Of Done è sicuramente una delle Policy più importanti dei processi agili.

Gian Maria.

posted @ 10/04/2015 19.49 by Gian Maria Ricci

Introduzione a Kanban su MVA ora online

Per chi fosse interessato è oggi online il corso su Microsoft Virtual Academy sul metodo Kanban, fatto da me dal caro amico Felice.

Trovate tutto qui.

http://www.microsoftvirtualacademy.com/training-courses/introduzione-a-kanban

Buona visione Smile.

posted @ 11/04/2015 11.05 by Gian Maria Ricci

Dove finisce la Kanban Board ed inizia il Feedback

Nel precedente post ho continuato la dissertazione sul massimizzare il flusso, ed ho spiegato come sia fondamentale estendere la Kanban Board a più stadi del processo possibili. Lo scopo finale è visualizzare tutti i passi che portano *dall’idea ai guadagno*. In un sistema software quindi dovremmo avere come ultima colonna un qualche cosa simile a: Usabile in produzione dal cliente finale. 

La domanda principale è: Usabile dal cliente finale significa guadagno?

In parole povere, il fatto che una determinata feature/card sia in produzione, è condizione spesso necessaria, ma non assolutamente sufficiente affinché inizi a generare guadagno. In questo caso quindi, anche se abbiamo massimizzato il flusso grazie alla nostra Kanban Board, non ci stiamo necessariamente avvicinando al Goal. Quello che viene spesso trascurato nell’implementazione del metodo Kanban è il considerare la metrica probabilmente più importante dei processi agili: IL FEEDBACK!!!!

L’aspetto interessante è che, si è tentato per anni di mutuare tecniche di progettazione da altre branche dell’ingegneria all’informatica (vedi il waterfall) ed il successivo fallimento di molti di questi tentativi ha generato un assioma di questo tipo:

Essendo il sistema waterfall mutuato da un altra branca dell’ingegneria, è possibile che mal si adatti all’informatica. Ergo è piuttosto inutile cercare di adattare metodologie di progetto da altre branche dell’ingegneria, perché l’informatica è troppo differente.

Questa affermazione è sempre vera? Venendo da studi di Elettronica, per me è naturale che un sistema di controllo per essere stabile debba necessariamente usare il principio del feedback.

Ora consideriamo che: il metodo Kanban è un sistema di controllo, il cui scopo è monitorare l’avanzamento dall’idea al prodotto finito grazie alla Board. A questo punto io sono fermamente convinto che:

Uno degli errori maggiori in Kanban applicato ad un progetto software è credere che il flusso finisca una volta raggiunta l’ultima colonna, ignorando per questo il feedback!!!!

Se grazie a Kanban abbiamo aumentato di molto il flusso di produzione (software o manifatturiero, …), ma nel contempo abbiamo una qualità scadente, siamo ben lontani dal Goal, a meno che il Goal non sia avere orde di clienti insoddisfatti (o di vendere contratti di assistenza).

In questo particolare caso l’ingegneria dei controlli e dell’automazione ci viene in aiuto, perché il modo migliore per capire se il prodotto del nostro processo è valido e di qualità, è acquisire FEEDBACK!.

Nei prossimi post vedremo quindi che tipologia di feedback utilizzare e come integrare questo processo in Kanban.

Gian Maria.

posted @ 10/04/2015 19.21 by Gian Maria Ricci

AngularJS Side Includes

With AngularJS, you can include HTML content, using the ng-include directive:

Example

<body>

<div class="container">
  <div ng-include="'myUsers_List.htm'"></div>
  <div ng-include="'myUsers_Form.htm'"></div>
</div>

</body>

posted @ 09/04/2015 16.38 by Alessandro Gervasoni

Baobab

Baobab is a JavaScript data tree supporting cursors and enabling developers to easily navigate and monitor nested data. https://github.com/Yomguithereal/baobab

posted @ 03/04/2015 9.29 by Alessandro Gervasoni

CQRS: “C” come “Conversation Id”

La serie di post su CQRS si arricchisce sempre più, ne mancano un paio per chiudere il cerchio e avere una overview abbastanza completa su “cosa”, “come” e “quando”.

 

image_2_thumb61

L’ultima volta che ne abbiamo parlato abbiamo introdotto il concetto di de-normalizzazione asincrona, elencando più o meno una lista di possibili passi simile a quella che segue:

  1. Invio del comando in POST;
  2. Ricezione del comando e dispatch dello stesso su una coda;
  3. Invio della risposta HTTP-202;
  4. Ricezione del comando e gestione dello stesso da parte del back-end;
  5. Broadcast dell’evento;
  6. De-normalizzazione;

Facciamo un passo indietro e semplifichiamo il processo riducendolo all’essenziale:

  1. Un processo (A) invia un messaggio ad un processo (B);
  2. Il processo (B) riceve la richiesta, fa quello che deve fare e pubblica un evento che notifica il suo nuovo stato;
  3. Il processo (A) deve reagire alla notifica/evento;

Ho volutamente utilizzato i termini processo e messaggio per sottolineare che la comunicazione è asincrona.

Ora, il processo (B) riceve svariate richieste e ovviamente pubblica svariate notifiche, eventi, (A) ha quindi bisogno di un modo per capire, tra tutti gli eventi che riceve, quali sono di suo interesse e quali no, quindi quali sono quelli relative a richieste che ha fatto lui e quali sono di altri.

Questo processo si chiama correlazione o gestione della conversazione, gli aspetti fondamentali sono:

  • colui che origina il primo messaggio deve avere la possibilità di generare un “Conversation ID” a suo piacimento, ovviamente responsabilità sua che sia unique oppure affidarsi a una parte dell’infrastruttura perché lo faccia per lui;
  • l’infrastruttura deve offrire un sistema per trasportare il “Conversation ID” da un endpoint all’altro;
  • l’infrastruttura deve garantire che il “Conversation ID” sia propagato a qualsiasi messaggio venga generato da un endpoint in maniera trasparente;

Date queste 3 semplici regole la complessità e/o ramificazione del processo diventa del tutto irrilevante.

Se volete approfondire questi temi venite a trovarci, ne discuteremo intensamente per una giornata intera, con tanto di esempi dal mondo reale.

.m

posted @ 02/04/2015 11.05 by Mauro Servienti

Solution Architect @ Particular Software

Sono felicissimo di annunciare che da oggi sono Solution Architect in Particular Software, un fantastico gruppo di persone notevoli. Come Solution Architect supporterò i clienti nel processo di adozione di NServiceBus e della Particular Platform.

Questo viaggio è cominciato 15 anni fa ed è decisamente lontano dalla fine, questa è una di quelle tappe che ti cambiano la vita, almeno la mia.

C’è una lunghissima lista di persone che devo ringraziare, senza le quali non sarei qui, troppo facile perdersi per strada qualcuno e fare un torto. Ci sono però 3 amici che sono stati fondamentali, quindi grazie Raffaele, Lorenzo e Andrea. (in ordine di apparizione).

posted @ 01/04/2015 10.30 by Mauro Servienti

mobileangularui.com

Build HTML5 Mobile Apps with Bootstrap and Angular JS
http://mobileangularui.com

posted @ 31/03/2015 17.14 by Alessandro Gervasoni

Kanban Board–Massimizzare il flusso

Come accennato nel post precedente sulle Split Columns della Kanban Board in VSO, Eliyahu Goldratt nel suo libro “The Goal” ci dice che uno degli scopi di una organizzazione è:

Maximize Throughput while Minimizing Inventory and Operating Expense.

In questo post vorrei fare una precisazione sul concetto di Flusso e Throughput, di centrale importanza per il metodo Kanban. Se avete letto The Goal sapete benissimo che uno degli scopi principali di una azienda è fare soldi, punto! Sembra cinico, ma senza un flusso di cassa costante, potete avere delle idee bellissime, essere innovativi, brillanti, ma sicuramente avrete difficoltà nel realizzare le vostre idee.

Nel software, quando andiamo a declinare il metodo Kanban, che ricordo essere nato in un contesto manifatturiero (Toyota), bisogna capire cosa intendiamo con il termine throughput. Facciamo però prima un semplice ragionamento in ambito manifatturiero, pensando ad una azienda che produce elettrodomestici. Supponiamo che la azienda usi Kanban, il flusso sia ottimale e le linee di produzione lavorino in maniera efficiente, i colli di bottiglia sono stati individuati, etc etc.

La domanda interessante che ci si deve porre è questa: se si vuole massimizzare il flusso dell’azienda, bisogna definire in maniera inequivocabile quale sia lo stato finale della nostra Kanban board, altrimenti rischiamo di non trovare colli di bottiglia. Facciamo un esempio in cui consideriamo come ultima colonna della Kanban lo stato “imballato”, che identifica quando il nostro elettrodomestico è stato imballato e pronto per la vendita.

Possiamo da subito capire che probabilmente questo non è corretto, se per qualche ragione il nostro magazzino non è efficiente, rischiamo di accumulare prodotti in magazzino senza essere in grado di farli pervenire ai distributori. In questo modo, se il magazzino è il collo di bottiglia, esso non verrà individuato, e ci accorgeremo dei problemi quando gli elettrodomestici “imballati” non hanno più posto dove essere stoccati.

Ok! Per risolvere consideriamo come ultima colonna Kanban una nuova colonna chiamata immagazzinamento, in questo modo se il magazzino diventa saturo, essendo Kanban un metodo pull, le linee di produzione dovranno fermarsi, dato che il magazzino non è più in grado di accettare pezzi. Anche in questo caso, se in alcuni periodi dell’anno quel tipo di elettrodomestici si vede di meno (frigoriferi in inverno), rischiamo di riempire il magazzino perché i grossisti non hanno bisogno di nuova merce.

Piano piano ci si rende conto che idealmente, l’ultima colonna Kanban per la nostra azienda fittizia, dovrebbe essere “venduto al cliente”. Ora è chiaro che ragionare in questi termini è decisamente difficile, ma se nel nostro monitoraggio del processo non consideriamo che il nostro elettrodomestico deve essere venduto ad un cliente finale, si rischia di non vendere, non fare soldi, e fallire.

Tornando quindi al concetto iniziale: Throughput!! Se seguiamo le indicazioni di Goldratt, dobbiamo accertarci che quando parliamo di flusso, stiamo includendo tutti gli stadi fino a quello che ci permette di fare soldi per far vivere l’azienda!

Cosa implica questo in Kanban applicato ai processi software? Che nella nostra Kanban Board, l’ultima colonna deve essere, per lo meno, Usabile in Produzione, ovvero il software deve essere rilasciato e disponibile al cliente finale. Se ci dimentichiamo di questo, rischiamo di accumulare una grande quantità di lavoro “finito” ma che non è usabile dal cliente/utente finale, e che quindi non può generare soldi.

Ricordate quindi che in Kanban la massimizzazione del flusso è fondamentale ed è altrettanto fondamentale che nel flusso si considerino tutti gli stadi, dall’idea alla produzione!

In realtà nemmeno questo alla fine è realmente sufficiente e capiremo perché nel prossimo post.

Gian Maria.

posted @ 21/03/2015 12.11 by Gian Maria Ricci

Latest Images

From miscellaneous
From miscellaneous
From miscellaneous
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini
From Immagini