2014: ho chiuso un blog, ho aperto un blog.

Ho atteso fin troppo, era davvero arrivato il momento. Ho aperto il mio nuovo blog e non credo che scriverò ancora qui. Sì, forse in occasione di qualcosa di interessante per la comunità agile italiana, ma visti i ritmi con cui ormai ero arrivato a pubblicare mi sa che sarà davvero raro.

Perché ho aperto un nuovo blog? Per almeno due motivi:

  1. Non ha senso autovincolarsi al mercato italiano. Ammesso e non concesso che io abbia qualcosa di interessante da raccontare, perché raccontarlo solo agli italiani? Se ciò che racconto invece non fosse di molto interesse, tanto varrebbe allora massimizzare le chance di trovare qualche matto che mi dia retta, rendendomi comprensibile ad un pubblico più ampio. In ogni caso quindi, abbasso le barriere linguistiche!
  2. Da un po’ non mi occupo più esclusivamente di software e mal sopporto certi facili inquinamenti – mentre gradisco le contaminazioni, paradossi del linguaggio! Su questo blog si parlerebbe sempre meno di software e sempre più di modi di organizzare il lavoro, anche scrivendo software, ma non solo. Da qui la necessità di partire da capo.

Devo un sacco a questo blog e ancora di più a chi ne ha letto i deliri. Ringrazio me stesso per averlo pubblicato, i lettori per averlo commentato e ringrazio Internet per l’occasione che mi offre, ogni giorno, da una ventina d’anni di confrontarmi.

Ti becco di là?

January 06 2014 | Dalle trincee | 3 Comments »

Imparare ad imparare

Leggendo su indicazione del buon Stelio un articolo su Wikipedia relativo al metodo Montessori ho notato immediatamente, folgorato, un passaggio che riporto qui liberamente tradotto, riguardo gli elementi essenziali di un buon processo educativo:

  • Classi di età mista.
  • Attività a scelta dell’allievo all’interno di una ristretta gamma di opzioni.
  • Blocchi temporali di lavoro ininterrotto.
  • Un modello costruttivista o di scoperta, in cui gli allievi imparano i concetti lavorando materialmente in prima persona, piuttosto che per istruzione frontale.
  • Materiale didattico specializzato, sviluppato ad hoc.
  • Libertà di movimento nella classe
  • Un insegnante con padronanza del metodo

Beh, non posso fare a meno di notare come tutti questi punti possano essere tradotti, ricondotti, mappati con successo sulle metodologie agili e sui principi che ormai da 10 anni sostengo, pur con un approccio mutevole ed evolutivo, senza indulgere nella liturgia, nel cargo cult.

L’assunto fondamentale di questo mio articolo è semplice quanto basta per scriverlo in poche, pochissime parole: sviluppare un prodotto digitale è un processo di apprendimento.

Sulla base di questo assunto, rivediamo i punti esposti uno per uno:

  • La diversità come valore imprescindibile per la crescita – nel lungo termine – ed il successo dell’azione – nel breve. Raccogliere professionalità diverse in un team cross funzionale presenterà dei costi, certo, che saranno però ampiamente ripagati dalla robustezza dell’apprendimento del team stesso.
  • Ridurre il work in progress, focalizzare l’azione ma rinunciando a processi strettamente prescrittivi. Chiunque sappia cosa sia una kanban board – <rant>e vi assicuro che sono meno di quelli che ne parlano</rant> – sa che le caratteristiche fondamentali di questo strumento sono
    1. la limitazione della concorrenza
    2. la modalità di selezione autonoma del lavoro da svolgere sulla base di una coda di priorità e delle proprie competenze
  • Il timeboxing è un concetto antico, ausilio di qualsiasi processo cognitivo. Decenni e decenni prima che noti brand vegetali – ormai pericolosi anche da citare per motivi di copyright… – vedessero le prime luci, il metodo Montessori già affermava la necessità di non essere interrotti per intervalli protetti di tempo.
  • Il modello cognitivo di scoperta per eccellenza nella programmazione è il test driven development (TDD), vera e propria trasposizione del costruttivismo nel contesto virtuale del software. Procedere per tentativi incrementali di ipotesi, assemblaggio, validazione e pianificazione è infatti parte fondamentale della teoria costruttivista. Ma programmare è solo una parte dello sviluppare prodotti digitali! C’è anche l’interaction design e lo sviluppo del business model. E qui manteniamo un allineamento pazzesco con i principi costruttivisti se pensiamo alle tecniche tipiche del mondo UX (wireframe, prototipi…) e alla business model canvas utilizzata nel business model generation.
  • Continuous integration, user story, wireframe etc etc sono tutti artefatti creati appositamente per massimizzare il feedback cognitivo del team mentre questo impara sempre meglio cosa il mercato si attenda da lui.
  • Esaltazione della libertà di azione individuale, per massimizzare l’espressione del proprio valore, senza badare a sovrastrutture che non portano reale valore a nessuno degli stakeholder, purché sia chiaro a tutti cosa ci si attenda dai membri del team. Giacca e cravatta, sistemi operativi imposti, strumenti di sviluppo standardizzati, obbligo rigido di presenza in ufficio e altre inutili benché spesso scontate regolette sono solo una forma di spreco.
  • Un coach che sappia davvero cosa significhi sviluppo agile, agile UX, lean start-up senza diffondere versioni distorte delle metodologie che mettano a repentaglio la salute e la redditività del progetto. Per sgombrare il campo da sospetti di marchetta – lettore maliziosetto che non sei altro :-) – mi affretto ad aggiungere:
    1. A seconda del livello di maturità di un team il coaching potrà essere anche auto-condotto dal team, senza la presenza fisica (e pagata) di un coach
    2. Lungi da me qui fare un appello all’ortodossia! Le metodologie devono evolvere e deve regnare la serenità di poter sperimentare, ma solo dopo aver capito quale strada vecchia si sta lasciando per la nuova.

Concludo senza dimenticare di celebrare il volto che, senza che gli italiani si rendessero bene conto, finiva negli anni ‘90 sulla banconota delle mille lire e per ottimi motivi! Questa recente scoperta probabilmente mi porterà a capire meglio i dettagli del lavoro di Maria Montessori e magari a scoprirne di nuovi utili al mio lavoro.

Mi porterà ad imparare insomma. ;-)

July 19 2013 | Esperti and Uncategorized | 3 Comments »

Arrivederci Roma! (o come fare di un articolo una lean start-up)

OK, OK… sono qui che cerco uno spunto per iniziare questo post, ma mi vengono solo espressioni troppo di rito – se non addirittura retoriche – e proprio non saprei come… vabbè, nel solco tracciato dalle ultime tendenze startappare, proviamo a scrivere un MVB, un Minimum Viable Blogpost¹. :-)

A metà novembre inizierò a lavorare come coach per il team eBay Italia.

Bene. Il grosso è fatto. Abbiamo un messaggio chiaro, il nocciolo dell’articolo è risolto e se vuoi puoi abbandonare qui la lettura, altrimenti, per qualche considerazione in più, puoi proseguire.

A metà novembre inizierò a lavorare come coach per il team eBay Italia. Rimarrò nella compagine sociale di ideato nella veste di board advisor per le metodologie di lavoro, altrimenti detto amichetto.

Ecco, già questa release mi sembra più completa: offre il nocciolo della questione e spiega cosa resterà della mia (amatissima) attività precedente. Sì, perché verso ideato io ho un debito di gratitudine: solo con quelle persone ho potuto sviluppare la mia professionalità e al contempo rendere visibile il frutto del nostro lavoro insieme in una misura tale da garantirmi, ad oggi, le mie più grandi soddisfazioni.

Questo forse può essere un buon momento allora per introdurre le motivazioni che mi portano verso eBay ed il suo team. “Se ami così tanto ideato”, sento già inquisire, “perché non ci rimani?”. Va bene, ascoltiamo il mercato – questo articolo è pur sempre una lean start-up! – e cerchiamo di fornire le giuste feature:

A metà novembre inizierò a lavorare come coach per il team eBay Italia. Rimarrò nella compagine sociale di ideato nella veste di board advisor per le metodologie di lavoro, altrimenti detto amichetto.

Come naturale evoluzione della vita professionale, il passaggio a eBay mi attira per 5 motivi, qui sotto elencati in ordine sparso. Sono ipotesi, il mio intento è validarle.

  1. I dati. L’enorme quantità di dati a disposizione, sia sulla percezione del prodotto da parte dell’utenza, sia sul funzionamento del software scritto, e la sfida che quelli pongono nell’essere letti correttamente, sono da una parte una splendida occasione per migliorare me stesso in tecniche di analisi finora poco praticabili, dall’altra una splendida base per rimuovere il più possibile dalle conversazioni un atteggiamento speculativo, sostituendolo con del sano empirismo.
  2. Il team interno. Meno problemi di turn-over, di allocazione delle risorse, di attenuazione delle disfunzionalità sistemiche della consulenza, possibilità di pensare alle conseguenze a lungo termine delle scelte fatte oggi. Il coaching viene valorizzato dalla quotidianità, dalla continuità. Quella in cui approderò tra meno di un mese è un’azienda piccola nell’organico, in cui dopo pochi giorni si è già conosciuto tutti, senza le dispersioni del grande integratore.
  3. Il prodotto proprietario. Dopo anni di consulenza per lo sviluppo di prodotti di terzi – che mi ha portato anche a sperimentare con enorme gratificazione – tornare a contribuire allo sviluppo di un prodotto unico con una community di utenti enorme mi interessa, soprattutto su una scala mai affrontata prima.
  4. Product manager. La presenza di una persona che ha la responsabilità di capire e definire cosa vada fatto prima di stabilire come vada fatto. Un sogno. Questo è l’aspetto che credo mi formerà di più. La (mancata) product ownership del software è un problema gravissimo, talmente grave che credo sarà il nuovo tema topico nei prossimi mesi: qualsiasi metodo fallisce nel portare i suoi frutti se non sai cosa vuoi ottenere.
  5. Orientamento al ROI. I numeri attuali sono chiarissimi, comunicati al sottoscritto da subito, dalle prime ore. I numeri che si vogliono ottenere sono chiari. In mezzo ci sarà il nostro lavoro. No frills, ma sviluppo orientato alla generazione di ricavi. Non è sterile cinismo: dopo 13 anni di lavoro con i prodotti web, so quanto la serenità dei team passi per la concretezza dei requisiti. Nel mondo della consulenza con ideato pensiamo di aver detto la nostra negli ultimi anni, arrivando nel 2012 a proporre contratti innovativi. Ora per me è tempo di andare ad imparare che aria si respira quando il cliente non è più un alibi.

Beh, a rischio di essere stato un po’ prolisso, sicuramente ora le mie motivazioni sono chiare. Per ora il mio articolo può bastare. Aggiungiamo doverosi ringraziamenti!

[...]

Non mi rimane che ringraziare ideato, quindi, per tutto quello che sono potuto divenire con loro e grazie a loro negli ultimi 4-5 anni: Manuel, Antonio, Michele, Filippo, Paolo, Cirpo, Chiara, Andrea. Mille mila “grazie”!

C’è poi da rendere manifesto il debito di gratitudine verso le persone che, magari quando ideato ancora non esisteva, mi hanno letteralmente spinto fin qui:

  • Gabriele Lana, perché anche se è vero che probabilmente sarei arrivato alle metodologie agili per mille altre vie, la Storia è una sola e io, nella mia, devo ringraziare lui per avermi ispirato il fuoco per le metodologie agili (cit.) tanti anni fa. Una persona di generosità equiparabile solo alla sua competenza, dimostrata nei fatti anno dopo anno. Zero fumo, arrosto a pacchi, lui sì!
  • Francesco Ciccio Trucchia, concreto, concretissimo compagno d’avventure. Siamo citati insieme fin dai tempi del post di Gabriele. :-) I suoi consigli e la nostra complementarietà sono ancora oggi, dopo anni e anni, una fucina di valore tecnico ma soprattutto umano. Stima, stima, stima. Quando tu sarai davvero ricco, amico mio, io vorrò essere il tuo braccio destro!
  • Francesco Fullo Fullone, per avermi sempre messo in contatto con le persone giuste, per aver sempre, sempre, sempre impostato il suo lavoro verso lo sviluppo delle persone, per aver dimostrato e per dimostrare tutti i giorni all’Italia dell’informatica che le aziende sane esistono. E-si-sto-no.
  • Alberto Mucignat, perché lui non mi ascolta mai, ma io per fortuna lui lo ascolto sempre. Se un coach ha bisogno di un coach, il mio è Alberto. Parlo con lui e risolvo i miei stalli. Ti pare poco?
  • il team e-xtrategy, perché con loro ho imparato tutto quello che mille libri non potranno mai raccontarti. Una disposizione al cambiamento incredibile, una capacità pazzesca di darmi feedback sul mio stesso valore personale. Lorenzo, Mike, Miki, Marco, Adriano, Daniele, Alessandro, Giorgio, Ilaria, Silvia, Riccardo, Emanuele: grazie di cuore.
  • l’intera community italiana e internazionale con cui ho potuto interagire: GrUSP, PHP London, Extreme Programming Italia, PUG Roma, Better Software, Codemotion, XPUG Marche, WEBdeBS, ALE Network, Symfony, Indigeni Digitali, PUG Friuli. Siete stati tutti fonte, mezzo e vero obiettivo. L’ho detto per tutto il 2011 in giro per conferenze: nessun uomo, da solo, vale quello che può valere tra gli altri. Grazie!

Ora che ho fatto in tempo anche a commuovermi – uno scrive articoli e mette su un blog per motivi autoterapeutici, cosa credi? :-) – faccio appello all’Extreme Programming User Group e al PHP User Group di Milano per l’accoglienza nei prossimi mesi! eBay Italia, per chi non lo sapesse, è un’azienda meneghina, arrivederci Roma!

October 21 2012 | Dalle trincee | 14 Comments »

E due!

Dopo qualche anno dalla pubblicazione di Pro PHP Refactoring rieccomi sulla scena editoriale PHP con il vecchio amico Francesco Trucchia e, stavolta, in compagnia di tanti altri carissimi e stimati colleghi membri del GrUSP, il Gruppo Utenti e Sviluppatori PHP.

Sono molto felice di presentarti il nostro lavoro, dal titolo PHP Best Practices. Un libro molto tecnico, unico nel suo genere in lingua italiana e dedicato ai professionisti dell’ecosistema PHP. Il libro è di ampio respiro e si allarga su tante diverse tematiche.

Il mio titolo, neanche a dirlo, è quello dedicato al Test Driven Development. Ho cercato di dargli un taglio molto pratico, ispirato dal grande esempio di Kent Beck – autore pazzesco, ogni volta rileggerlo è una riscoperta. Nel capitolo ho cercato di rispondere alla “frequently asked” domanda: sì OK, bello tutto, ma poi dal vivo, nel mondo vero? La mia risposta migliore nel mio capitolo.

Ah dimenticavo: il mio sul TDD è l’unico capitolo scaricabile gratuitamente già da oggi, in attesa del lancio ufficiale del libro il prossimo 18 maggio al phpDay di Verona!

Buona lettura!

May 04 2012 | Eventi | No Comments »

Ho avvistato un contratto sano: esistono!

C’è voluto un intero anno di sperimentazione e raffinamento, per essere certi di non doverci smentire troppo facilmente, o che le correzioni apportate fossero più rilevanti dell’idea di partenza, ma oggi ho un racconto croccantissimo su un nuovo modello di pricing adottato da e-xtrategy, una internet company marchigiana per cui svolgo attività di coaching da qualche anno. Cercherò di essere breve per trasmetterti in poco tempo lo spirito di questo post.

Il problema da risolvere

I contratti che tipicamente regolano i rapporti nello sviluppo di software sono il vero dramma del nostro mercato. Ereditati da mercati con caratteristiche finanziarie, tecniche e sociali completamente diverse, i classici contratti a corpo ad oggi, secondo me, sono il principale motivo di fallimento dei progetti software. Senza dilungarmi troppo, mi basterà farti notare come

  1. mantengano il rischio completamente sbilanciato sul fornitore che, per definizione, non dovrebbe invece partecipare al rischio d’impresa neanche un po’
  2. richiedano di prendere le decisioni più cruciali – visto che si tratta di denaro – in modo definitivo nel momento di minima conoscenza riguardo al progetto stesso: l’inizio.

Purtroppo il contratto a corpo, sovrano indiscusso delle gare d’appalto, rimane lo standard di riferimento per i progetti software. Questo problema può essere mitigato dall’impiego di altre forme contrattuali tradizionali: il contratto tempo e materiali con tetto dei costi, per esempio, oggi è la vera spina dorsale di aziende come ideato, che si permettono di chiedere al cliente appena acquisito un briciolo di fiducia in più sulla base della grande fiducia accordata dai clienti già acquisiti.

Il problema dei contratti tempo e materiali è che scalano male. Cosa intendo?

Intendo dire che i contratti che definiscono un prezzo in modo accoppiato al tempo speso per fornire valore ad un cliente hanno alcuni grossi difetti:

  1. mantengono il rischio completamente sbilanciato a sfavore del cliente.
  2. non incentivano la creatività nel cercare soluzioni migliori di rilascio, fatturazione o pagamento, riducendo quindi il valore medio dell’offerta.
  3. non incentivano l’azienda fornitrice allo sviluppo tecnologico, anzi, disincentivando l’innovazione! Un’azienda che fattura il tempo speso a lavorare non ha molti incentivi finanziari a ridurre il tempo impiegato a risolvere un dato problema(*).

Questa insofferenza per i contratti tradizionali – perché di insofferenza nel mio caso si tratta – potrebbe sembrare un dettaglio, un vezzo pignolo da fanatico agilista, ma vorrei invece ti fosse chiaro come un contratto sbagliato possa distruggere ogni sforzo di adozione di un approccio iterativo e incrementale. Lo preciso perché fra questi approcci figura anche quello detto lean start-up – scrivo strizzando l’occhio ad un tema molto in voga in questi mesi.

Nel gennaio 2011, chiamati a sviluppare un’applicazione mobile per la domotica, i ragazzi di e-xtrategy hanno dovuto gestire da subito una grande incertezza: requisiti descritti poco e male, un cliente abituato alla programmazione di dispositivi automatici senza esperienza di design di interfacce utente e tecnologie relativamente nuove rispetto all’esperienza del team. Necessariamente si imponeva su entrambi i versanti cliente-fornitore una forma contrattuale più intelligente, che portasse l’esposizione al rischio di entrambe le parti a convergere.

La soluzione

Cosa abbiamo pensato con e-xtrategy un anno fa per contribuire alla sovversione di preconcetti causa di sprechi tipici? L’idea fondante il nuovo contratto è nota da sempre in altri mercati: soddisfatti o rimborsati. Vediamo un po’ di dettagli.

Il team vende il suo tempo a prescindere dalle specifiche di progetto come nel caso del contratto time & material, ma sulla base dell’intera iterazione, come una tariffa flat per intenderci. “Per un’iterazione di sviluppo del tuo team io ti pago tot” ed il team incassa la cifra pattuita per ogni iterazione lavorata alla consegna del deliverable più opportuno (tipicamente il codice, ma anche template grafici, wireframe, prototipi etc etc). Il fornitore può rifiutare arbitrariamente il prodotto dell’ultima iterazione, rinunciando ad ogni diritto su esso, senza pagare il conmpenso stabilito.

“Eh ma così rischio di lavorare gratis!” ti sento già argomentare. Vero, rischio di lavorare gratis per la durata di un’iterazione. Ma nel caso di team sufficientemente maturi un’iterazione dura 5 giorni, quindi il rischio con un contratto di questo tipo è di lavorare gratis 5 giorni. Davvero non conosci alcun team sopravvissuto a 5 giorni di lavoro oltre una deadline stabilita da un contratto a corpo classico? Permettimi di dubitarne.

Fissando iterazioni brevi con questo contratto il cliente gode

  1. del controllo del time to market, potendo rilasciare virtualmente ogni 5 giorni in produzione
  2. della possibilità di scaricare il team in ogni momento, impegando al massimo 5 giorni per scoprire l’inadeguatezza del team selezionato
  3. della possibilità di allocare budget gradualmente, posticipando gli investimenti il più possibile
  4. della possibilità di definire con la massima libertà i requisiti senza inutili rigidità upfront

Fissando iterazioni brevi con questo contratto il fornitore gode

  1. della sicurezza di lavorare senza garanzia al massimo 5 giornate, scenario preferibile a molti scenari effettivi e tipici dei contratti a corpo
  2. di flussi di cassa stabili e ben parcellizzati
  3. dell’incentivo interno a migliorare la rapidità di sviluppo senza andare a discapito della qualità: se impiego meno tempo a parità di funzionalità consegnata evidentemente avrò margini più ampi, ma se la qualità degrada il cliente finirà per non pagarmi l’iterazione.
  4. della possibilità di servire il miglior ritorno di investimento, recependo i requisiti all’ultimo momento utile e responsabile

La vera morale

Ovviamente questa è una forma contrattuale che si fonda sulla (quasi) certezza del fornitore di apportare fin dalla prima iterazione valore concreto e apprezzabile al business del cliente. Non è quindi un contratto adatto a tutti, bisogna saperlo sostenere fin dalle più remote retrovie, coinvolgendo management, commerciali, programmatori, designer, grafici. Ma e-xtrategy dopo un anno si ritrova con un cliente soddisfatto, iterazioni acquistate e pagate ben oltre l’accordo iniziale e un prodotto completo, di alta qualità e in grado di abilitare il cliente a recuperare l’investimento fin dalle prime battute.

Insomma il vero obiettivo del mio lavoro: sviluppo sostenibile di software. Eh… quante soddisfazioni! :-)

Soprattuto – sono serio – la chance per me di raccontarvi che un altro mercato dell’information technology è possibile e non in un fantomatico paese paradisiaco d’oltralpe. È possibile qui e ora e dipende da noi, tutti noi. Tu allora lo vuoi?

(*) ovviamente rimangono intatti gli incentivi strategici: impiegare poco tempo per servire un cliente mi permette di servirne di più, anche quando la somma delle ore spese – e il fatturato – non cambiano. Rimane quindi comunque valido il principio di un servizio tempestivo e più rapido possibile.

February 08 2012 | Dalle trincee | 18 Comments »

Noi siamo diversi

Dalla pagina del gruppo Facebook Engineering, quelli che fanno Facebook:

Il nostro ciclo di sviluppo è estremamente veloce e abbiamo costruito strumenti per mantenerlo così. E’ normale scrivere codice e averlo in produzione pochi giorni dopo. Questa è una piacevole sorpresa per gli ingegneri che hanno lavorato in altre aziende dove il codice ci mette mesi o anni a vedere la luce del giorno. Se lavori con noi, potrai avere un impatto immediato.(*)

Hai notato? “Pochi giorni dopo”, “piacevole sorpresa”, “impatto immediato“. Perché loro sì e tu no?

“Eh ma da noi è diverso!”.

Ne sono convinto: quella differenza la stai facendo anche tu.

January 25 2012 | Base | 4 Comments »

Many to many – No man is an island – Il video

Ciao! Buon anno, in primis!

Lo scorso ottobre sono stato invitato come speaker alla PHPNW 2011, dove ho tenuto il talk intitolato Many to many – No man is an island. Si parla di comunità, di nerd, di social skill e di incidenti aerei. La registrazione è buona; il talk spero.

Buona visione!

http://blip.tv/phpnw/phpnw11-jacopo-romei-many-to-many-no-man-is-an-island-5860230

January 03 2012 | Eventi | No Comments »

Siamo fatti così

Molto probabilmente ricorderai dai tempi della scuola il concetto di mitosi, quello per cui la cellula, raggiunto un certo stadio del suo ciclo di vita e un certo accrescimento, si divide in due cellule figlie duplicando perfettamente il proprio patrimonio genetico e assegnando ad entrambe grosso modo lo stesso numero di risorse.
Se non ricordi la lezione di scienze a scuola forse ricorderai il fatidico momento ricorrente nella serie animata Siamo fatti così in cui i globuli bianchi rispondevano ad un’infezione duplicando rapidamente l’organico di truppe disponibili. Nelle ultime retrospettive in ideato si è pensato di ricorrere allo stesso meccanismo per rispondere agli inconvenienti della crescita: comunicazione più complessa, gestione lenta della conoscenza e colli di bottiglia nel processo a monte del team di programmatori. E così ora ideato si ritrova con due team grandi la metà di quello originale. continue reading »

September 23 2011 | Dalle trincee | 8 Comments »

Capire davvero il lean thinking.

Il buon Gianandrea, attivo e paziente compare di riflessioni sui problemi dell’organizzazione del lavoro, sottopone alla mia attenzione questo articolo di Alessandro Cravera sul lean thinking. Un articolo rivelatorio delle distorsioni costantemente in agguato e in atto sempre più nel contesto manageriale che adotta metodologie agili per poi tradirne l’essenza. Lascia che ti spieghi come mai la pensi così.

Il pensiero di assunto da Cravera nella sua critica è quello di Womack per cui

Per usare le parole dello stesso Womack, il lean thinking è “un modo per fare sempre di più consumando sempre di meno”.

e da questa considerazione Cravera fa conseguire una riflessione sui rischi che il lean thinking comporta quando eventuali ridondanze vengono eliminate in nome della riduzione degli sprechi. Riflessione, questa, legittima perché effettivamente la riduzione tout court di ogni ridondanza è effettivamente a rischio di subottimizzazione, quella condizione in cui un ottimo locale può inficiare la prestazione globale di un sistema. Effettivamente lo scenario dello sviluppo di prodotti può fare tesoro di alcune ridondanze – basti pensare alla creazione di più ipotesi di interfaccia utente,  per fare un esempio banalissimo.  Quello che della riflessione non va, se vogliamo legarla ad una critica sana del lean, è l’assunto che il lean thinking sia devoto e prono alla subottimizzazione quando è assolutamente il contrario!

Nel Lean Primer di Craig Larman e Bas Vodde, la cui lettura consiglio a tutti gli interessati al pensiero lean, gli autori liquidano il punto di vista di Cravera già nella prima pagina (!) con questa considerazione che io riporto,  tradotta da me:

L’immagine e la metafora con cui vorremmo porre l’accento su un errore – ed un’opportunità – chiave è la staffetta.

Considera i podisti di una staffetta in attesa del testimone da parte dei loro compagni di squadra. L’account manager, inorridito da questo spreco da sottoimpiego indicato in qualche report, probabilmente definirebbe una nuova policy con l’obiettivo “dell’impiego al 95% delle risorse” per assicurare che tutti gli staffettisti abbiano da fare e siano produttivi. Forse – suggerirebbe – gli staffettisti potrebbero correre tre staffette contemporaneamente per incrementare l’occupazione delle risorse. [...]

Divertente… ma questo tipo di ragionamento è più tipico del management e dei processi tradizionali nello sviluppo e in altri domini. Invece, per contrasto, ecco l’idea alla base del lean thinking:

Tieni d’occhio il testimone, non gli staffettisti

Già traspare quindi il grave vizio di sostanza dell’ emerso – non capisco se solo per citazione o per effettivo sposalizio – nell’articolo di Cravera: guarda all’approccio lean attraverso le lenti dei processi classici e ne analizza l’eventuale risultato, ormai però distorto. Non mi dilungo oltre: se ti interessa il pensiero lean leggi l’articolo di Cravera con attenzione. Poi leggi quello di Larman e Vodde per capirlo davvero.

June 22 2011 | Base | 7 Comments »

Settimanella impegnata

Ciao!

  1. Domani sarò al jsDay dove potremo apprezzare lo stato dell’arte del know-how Javascript e delle tecnologie a contorno. Trovo sia un bell’evento, considerato che è il primo in Italia nel suo genere e con un’ottima line up fin da questa prima edizione.
  2. Da giovedì sarò al phpDay dove avrò l’onore ed il piacere di presentare il keynote venerdì, intitolato Many to many: no man is an island. Tratterò il tema particolarmente importante delle community e dello sviluppo della competenza.
  3. Oggi mi trovo a Madrid, dove stasera si terrà il primo ALE Gathering al termine della prima giornata di XP 2011. Si tratta di un neonato network europeo centrato sulla diffusione dei valori agili e lean nello sviluppo del software. L’obiettivo di stasera sarà quello di settare la vision del network. Sarà divertente perché, mentre la delegazione italiana sarà ben rappresentata, io mi sono offerto per rappresentare la comunità bulgara, impossibilitata ad inviare dei propri delegati. Se non è networking questo… ;-)

May 10 2011 | Uncategorized | 1 Comment »

Next »