Lean Startup in a Nutshell, parte 2

Nel primo post della serie abbiamo fatto il punto su cosa sia Lean Startup e sul perché può essere utile conoscerlo ed adottarlo nell’ambito della creazione di una nuova startup.

Entriamo ora nel vivo dell’operatività della metodologia di Ries, andando ad occuparci del ciclo Build-Measure-Learn e dei tool annessi. Prima di continuare è opportuno ricordare che l’obiettivo di una startup è quello di accelerare tale loop in modo da ricevere velocemente i feedback dagli early adopters, i primi utilizzatori che condividono la Vision generale e che possono contribuire al suo raggiungimento. L’individuazione degli early adopters è fondamentale: tali utenti possono tranquillamente tollerare inefficienze e un prodotto parzialmente funzionante, perché sono “affamati” di novità e hanno “desiderio” di contribuire alla sua evoluzione.

In questo post vedremo, in particolare, come velocizzare la fase di Build, fase in cui l’idea viene codificata e presentata agli early adopters (e successivamente ai clienti) per i feedback.

build measure learn build

Build phase

Dal passaggio dell’idea alla codifica, il tool fondamentale è il Minimum Viable Product (MVP), sostanzialmente un prodotto/servizio che implementa il set minimo di funzionalità per la convalida della strategia. L’approccio di sviluppo, strutturato in termini di Validate Learning, si contrappone decisamente alla logica del “release maximum-feature”, in cui si cerca di rilasciare quante più features possibili, abbracciando la filosofia “release early, release often” che prevede di rilasciare velocemente e spesso nuove release della propria soluzione (Continuous Delivery). In tal modo si va ad abbattere quello che tipicamente viene indicato come l’8 MUDA, ovvero il sotto-utilizzo delle risorse umane, nello specifico gli early-adopters.

Ma cos’è concretamente un MVP? Possiamo immaginarlo come un qualsiasi artefatto che ci permette di verificare le nostre ipotesi e i nostri “atti-di-fede” (act of faith): dal prototipo, ad una semplice pagina web, fino anche ad un video in cui si descrive il prodotto/servizio.

Minimum Viable Product

The MVP

La fase di codifica vera e propria trova nelle metodologie Agile e Lean Software Development un ottimo strumento di riferimento, considerando anche l’estrema incertezza in cui si opera tipicamente una startup (ricordiamoci che sia il problema che la soluzione sono sconosciuti).

Attenzione, però! Il Program Backlog non va pensato in chiave standard, ovvero composto dalle Feature, bensì va popolato con le ipotesi da verificare ad ogni nuovo loop, mentre l’azione di sviluppo è gestibile attraverso un Iteration Backlog in chiave classica.

Una volta consegnato l’MVP, è possibile avere due scenari: se, quanto realizzato, non dovesse confermare le assunzioni (Innovation Accounting), è possibile ripartire dallo step precedente ed attuare le opportune azioni di PIVOT. Dualmente, se l’MVP le convalida, è possibile passare allo step successivo aggiungendo nuove funzionalità ad esso: si opera, sostanzialmente, in un’ottica di Continuous Integration, andando ad abbattere due dei MUDA di Lean: la Sovrapproduzione (over-production) e le Scorte (over-stocking). Ciò avviene concentrandosi solo su quello che è funzionale all’obiettivo imminente, integrandolo rapidamente nel nuovo MVP da consegnare agli early-adopters per le fasi successive.

Tornano alla Continuous Delivery è doveroso evidenziare che essa può diventare pericolosa nel momento in cui comincia ad essere necessario garantire una reliability di una certa robustezza, soprattutto quando si passa dagli early-adopters ai clienti di riferimento. Ad esempio: cosa accade se l’ultima modifica intacca il sistema di e-commerce? Chiaramente le revenue diminuiscono e la startup comincia a soffrire di liquidità.

Per tutelarsi da situazioni indesiderate, oltre agli strumenti di Quality Assurance tipici delle attività di sviluppo (si pensi, al TDD e al BDD, tanto per restare in chiave Agile), è possibile creare un Cluster Immune System, ovvero un sistema che monitora (Actionable Metrics) quanto accade nel sistema e ripristina la precedente situazione laddove l’ultimo deploy ha generato problemi evidenti. E’ possibile approcciare tale sistema sia in modo automatizzato che parzialmente-automatizzato, ma si tratta comunque di un percorso lungo e complesso, anche se inizia con semplici regole e best-practice. Al di là della scelta specifica, la cosa fondamentale è consentire al Team di lavorare con serenità, evitando che i fallimenti (che ricordiamo, ci saranno e devono esserci) si trasformino in qualcosa di diverso da strumento di apprendimento.

cust dev plus agile

Lean Startup & agile

Da un punto di vista tecnologico, due elementi sono particolarmente adatti alla fase di Build di Lean Startup: il primo è l’utilizzo di framework e middleware che dispongono di un’ampia community di supporto, consentendo così di velocizzarne l’apprendimento e la risoluzioni di eventuali problemi. Questo aspetto è sicuramente primario rispetto a quello tanto enfatizzato dell’open/closed source, poiché bisogna essere in grado di quantizzare il vantaggio nella sua interezza, ad esempio: se l’utilizzo di un framework open-source implica una curva di apprendimento molto ampia, ciò rallenterà l’esecuzione del loop build-measure-learn, in contrasto con l’obiettivo stesso di Lean Startup.

Il secondo elemento tecnologico è il Cloud (nelle sue varie forme IaaS, PaaS e SaaS), permettendo di non spendere praticamente nulla in infrastrutture tecnologiche grazie all’approccio pay-as-you-go. In tal modo è possibile realizzare la propria soluzione e farla testare agli early-adopters in modo estremamente conveniente, utilizzando solo le risorse effettivamente necessarie. Anche qui la scelta è eterogenea, passando per Microsoft Azure, Amazon EC2 fino ad arrivare a Heroku, tutte piattaforme con la loro specificità e adattabilità al contesto. A voler essere precisi, Lean Startup non parla in modo esplicito di Cloud, ma enfatizza il concetto di just-in-time scalability, ovvero la necessità di supportare il prodotto/soluzione con la necessaria infrastruttura, evitando di sottodimensionarla (MUDA:Attese) o sovradimensionarla (MUDA:Troppe Scorte). E’ possibile, comunque, considerare il Cloud come il naturale step evolutivo di quando previsto da Ries.

 

In conclusione, nella fase di Build, è fondamentale utilizzare strumenti snelli e dinamici che consentano di velocizzare il deploy (sicuro), abbattere i costi ed ottenere rapidamente i feedback dagli early-adopters.

Cloud Load Test con Visual Studio Online – parte 1: Web panel

Questo articolo è il primo di una serie di 3 in cui parlerò di Cloud Load Testing con Visual Studio Online.
In questa prima parte affronterò l’esecuzione di test di carico semplici su applicazioni web, utilizzando direttamente le funzionalità messe a disposizione dal portale di VSO.
Introduzione
Prima di iniziare a parlare nello specifico dell’esecuzione dei Cloud Load Test è importante soffermarsi su alcuni aspetti.
  • Per poter utilizzare la funzionalità di Cloud Load Test è necessario avere una sottoscrizione MSDN Ultimate
  • L’applicazione da testare deve essere esposta sul web (al tool va indicato l’url da testare)
  • Gratuitamente si possono utilizzare fino a 15.000 minuti al mese. Si tratta di “virtual user minutes”, quindi ad esempio eseguendo 1 test da 2 minuto con un carico costante di 200 virtual user si consumeranno 400 virtual user minutes.

Fatte queste precisazioni, vediamo come si possono eseguire i test di carico utilizzando l’iterfaccia presente sul portale di Visual Studio Online.
Iniziamo
Innanzitutto è necessario fare login al portale web di VSO e, dalla dashboard iniziale scegliere “Load test”.
Fatto questo viene proposta la finestra di impostazione delle variabili del test. Come vedete si tratta di un unica schermata, quindi  le impostazioni possibili sono abbastanza limitate, ma comunque sufficienti a fare un test di carico generico sulla nostra applicazione.
Come prima cosa viene chiesto l’url su cui eseguire il test di carico: si tratta di un solo url (quindi non è possibile eseguire da qui un test di carico a step consecutivi o a navigazione pseudo-reale) che può corrispondere all’home page del sito o, come nell’esempio, ad una qualsiasi pagina della web application. L’unico vincolo presente è che la pagina deve essere visibile pubblicamente senza necessità di inserire delle credenziali, visto che al momento non è possibile impostarle.
Il secondo parametro da inserire è il nome del test: si tratta di una stringa libera, che servirà a noi solo come reminder.
Sotto questi due parametri ce ne sono altri 4, indicati proprio come “Test settings”, che servono per poter meglio definire gli aspetti chiave del carico che si vuole applicare.
  • User Load: permette di definire il numero di utenti virtuali che contemporaneamente si collegheranno all’url fornito. I valori possibili sono 25, 50, 100 e 200
  • Run duration: è la durata complessiva del test. I valori selezionabili sono da 1 a 5 minuti
  • Think-time: si tratta del tempo di attesa tra una richiesta e l’altra. Serve per evitare che i sistemi di anti-hammering e anti DoS entrino in funzione. È possibile indicare tempi di attesa di 1 secondo (default) o 5 secondi
  • Browser distribution: questa impostazione indica la percentuale di utilizzo di browser che si vuole simulare. Scegliendo ad esempio “IE 80%, Chrome 20%” il test verrà eseguito con agenti useranno gli engine di Internet Explorer e di Chrome nelle percentuali selezionate

Settate queste impostazioni, cliccando sul bottone “Test now” si da inizio al test.
Esecuzione del Test
Ma cosa avviene, nel concreto quando si avvia il test?
Visual Studio Online crea per noi on demand un lab virtuale in un datacenter su Azure e configura gli agenti sulle vm con i parametri indicati:
Non appena il lab è pronto e configurato, inizia il vero e proprio test di carico. Gli agenti iniziano a generare traffico verso l’url indicato e i risultati sono inviati, quasi in real time, al nostro browser. In questo modo possiamo avere un’anteprima dell’esito del test.
In questa immagine vediamo, ad esempio, che intorno ai 50 secondi si è verificato “un buco” nelle richieste al secondo che il sito è risucito a gestire, testimoniato anche dal notevole incremento del tempo di risposta. Utilizzando questi dati potremmo avviare un’attività di analisi sulla nostra applicazione o sulla nostra infrastruttura per capire come mai si sia verificata un’anomalia del genere.
Risultati
Al completamento del test, ci vengono indicati gli esiti e le performance raggiunte.
Oltre al grafico che avevamo anche durante l’esecuzione ci vengono date altre informazioni.
Innanzitutto ci viene data l’indicazione tel tempo di risposta medio. Un tempo medio inferiore a 0,1 secondi è considerato buono. tra 1 secondo e 0,1 secondi è considerato “non molto buono”, sopra il secondo è considerato negativo.
Dopo il tempo di risposta, è indicato il numero di richieste che in totale sono state fatte alla web app.
Infine, c’è l’indicazione delle eventuali richieste che non sono andate a buon fine o che hanno generato un errore sull’applicazione.
Sotto questi valori viene indicato anche quali errori sono stati riscontrati.
In questo caso non ve ne sono, se si fossero verificati degli errori nella tabella troveremmo la causa generica dell’errore, il suo tipo specifico ed il messaggio di errore.
Conclusioni
Questo tipo di Load test non è sicuramente il più completo che si possa ottenere, ma va comunque bene se ci interessa avere delle indicazioni di massima sulle prestazioni e sul carico supportato dalla nostra applicazione.
Inoltre il setup di questi test è estremamente semplice e in pochissimi minuti si è in grado di avere un gran numero di informazioni utili.
Se quello di cui avete bisogno, invece, è un test approfondito, eseguibile simulando un flusso reale di navigazione… non perdetevi il mio prossimo articolo di questa serie.

Lean Startup in a Nutshell, parte 1

Con questo primo post, inauguriamo una serie di appuntamenti che vanno ad approfondire quanto introdotto in “Lean Startup, scientific innovation”.

Lean Startup propone un approccio lean-based alla creazione di un nuovo business e/o di una nuova startup, assimilando tale atto creativo ad un continuo esperimento. Così come suggerito da Eric Ries, in primis, ma anche da Steve Blank e altri pionieri di Lean Startup, una nuova startup non è un’azienda in miniatura e quindi la cosiddetta “dollhouse theory of startups” è assolutamente errata.

what is a startup transp

“A startup is a human institution designed to create something new

under conditions of extreme uncertainty”

L’obiettivo di una startup è, quindi, quello di trasformare la propria Vision in un business sostenibile, creando opportuni prodotti e servizi a supporto di esso. In linea generale, non si ha inizialmente bisogno di tutte le strutture tipiche di un’azienda rodata come, ad esempio, marketing o finance, bensì di una struttura snella con un mix di competenze in costante evoluzione.

Essendo la Vision l’unico punto fermo, il processo di realizzazione del prodotto (sevizio) annesso deve adattarsi a condizioni assolutamente incerte, in cui il problema è parzialmente noto (o addirittura in alcuni casi sconosciuto) e la soluzione è sconosciuta. In tale contesto, non è possibile ipotizzare l’utilizzo di approcci classici, ovvero:

  • Waterfall-like (known problem, known solution), richiede la conoscenza approfondita sia del problema e sia della soluzione che si vuole realizzare;
  • Agile (known problem, unknown solution), in cui il problema da risolvere è noto (in linea generale) ma non è ben chiaro quale soluzione realizzare per risolverlo ed il modo migliore per farlo.

Nel caso di una startup, siamo in una condizione di (partially) unknown problem – unknown solution, ovvero una combinazione delle condizioni precedenti in chiave peggiorativa. Lean Startup suggerisce di considerare lo sviluppo del business (e del prodotto/servizio) attraverso il ciclo build-measure-learn che va velocizzato il più possibile al fine di sfruttare al massimo in concetto di Validation Learning, ovvero validare scientificamente le proprie assunzioni (o come li definisce Ries, atti di fede – “Leap of Faith”).

buildmeasurelearn

Build-Measure-Learn

Ma l’apprendimento va associato a delle metriche affidabili e verificabili, altrimenti si tratta di supposizioni che non portano a vedere ciò che si vuole (Vanity Metrics) e a considerare livelli di crescita (grow) falsati da valori non connessi ai miglioramenti ottenuti nell’ultima esecuzione del loop Build-Measure-Learn.

Un esempio: se si utilizzano delle metriche generiche che consentono solo di vedere l’incremento dei download del prodotto, com’è possibile capire se essi sono dovuti alle nuove features introdotte o ad un aumento delle campagne di advertising?

Questi elementi sono ben esplicitati nella pratica definita Innovation Accounting, ovvero nella formulazione e nella verifica di una serie di metriche affidabili (Actionable Metrics) definite sulla base di alcune “semplici” domante:

  • Cosa vogliamo imparare nel prossimo loop?
  • Cosa è necessario misurare per fare ciò?
  • Cosa dobbiamo realizzare (es: MVP) per raggiungere il nostro obiettivo?

Tramite l’Innovation Accounting è possibile capire se si stanno facendo progressi o se la strategia adottata va modificata (PIVOT) perché non produce i risultati attesi. Da questo si capisce definitivamente quanto si importante accelerare il più possibile i loop build-measure-learn.

Chiudiamo questo primo appuntamento con l’enfasi sul “fallimento”: se la scelta strategia risulta errata, ovvero le assunzioni fatte non sono valide, ciò non vuol dire che è necessario arrendersi, bensì che bisogna adeguare le proprie scelte e le future azioni ai risultati ottenuti. Il pattern di riferimento non è quindi: win-or-fail ma fail-fail-win!

failure

win-or-fail vs fail-fail-win

I prezzi per le build e per I Load test in VSO sono usciti

Brian Harry aveva già annunciato alcune settimane fa una differenza al pricing per Build e Load Testing in VSO. Vi invito a leggere il suddetto post per i dettagli e ricordate che per ora le uniche modifiche che sono attive sono quelle che Brian ha annunciato oggi in questo post.

Con la modifica ora le build fatte direttamente in VSO (oltre ai primi 60 minuti al mese che sono gratis) costeranno 0.05$ al minuto per le prime 20 ore, e poi 0.01$ al minuti se eccedete le 20 ore. Questo piano rende vantaggioso usare le build per chi ha grandi progetti ed un grande numero di build.

Un’altra interessante modifica è che ora il limite delle licenze di VSO Professional che possono essere associate all’account è stato aumentato a 100 rispetto al precedente valore di 10.

Buon lavoro a tutti.

0  

Lean e Agile, similitudini e differenze

Inauguriamo questo nuovo anno con un post “chiarificatore”, utile per poter affrontare nei prossimi interventi i temi relativi al mondo Lean Startup e Lean Software Development.

what about leanQuando parliamo di Agile, spesso utilizziamo anche l’appellativo Lean come sinonimo di un approccio moderno alla gestione dei progetti e, in ambito @Scaling, alla gestione aziendale e alla gestione dei relativi processi. In effetti, nonostante Lean e Agile siano mondi distinti e ben strutturati che si intrecciano spesso perché entrambi prediligono la Customer Satisfaction e la massimizzazione del Valore, non è così immediato avere un’idea delle relative differenze e similitudini.

Lean ha origine nel Paese del Sol Levante presso la Toyota con il nome di Toyota Production System (TPS). Le sue basi vengono sviluppate da Taiichi Ohno e Shigeo Shingo durante gli anni ’50, ma solo negli anni ’90, grazie al libro “The Machine That Changes the World, Lean Thinking and Lean Solutions” di James Womack and Daniel Jones, esso viene concettualizzato nella sua accezione odierna sotto il nome di Lean, consentendo alle aziende di adottarlo in modo strutturale.
Agile è decisamente più giovane: la sua origine è databile agli inizi del 2001 (febbraio) quando un pool di esperti di sviluppo software danno vita al famoso Manifesto, che ne definisce i Valori ed i Principi portanti, pensato per un nuovo approccio in contrapposizione a quello che comunemente viene indicato come document-driven software development. Agile non definisce comunque una metodologia specifica, ma un set di elementi comuni che vanno a caratterizzare le sue diverse declinazioni come, ad esempio, Extreme Programming, Scrum, Adaptive software development, Feature driven development, ecc..

Già da queste poche righe emerge una differenza fondamentale: Lean nasce in ambito manifatturiero per poi proporsi come possibile soluzione per migliorare i processi aziendali. Agile nasce specificatamente per il mondo dello sviluppo software:

  Focus Settori Tool Kit
Lean Approccio olistico per rendere un’organizzazione o un processo più efficace ed efficiente. Lean è assimilabile a una filosofia operativa che abbraccia un forte cambio culturale supportato da una serie di tool di comprovata efficacia. Fortemente eterogenei tra di loro, prediligendo un contesto basato su processi stabili. Value Stream Mapping (VSM), Waste Analysis, Kanban, Heijunka, Jidoka, Multitasking, Supermarket, Visual Management, Empowerment, ecc.
Agile Basato su una serie di Valori e Principi che guidano la creazioni di soluzioni nell’ambito dello sviluppo software. Contesto con un alto tasso di incertezza e forte complessità. Specificamente pensato per aumentare la qualità e la velocità di consegna delle soluzioni software. Molti dei tool utilizzati in Agile sono diretta derivazione di Lean: Kanban, Empowerment, Visual Management, ecc.

E’ possibile quindi affermare che esistono diversi punti di similitudine, soprattutto se si abbraccia la specifica declinazione di Lean per il mondo software: Lean Software Development, proposta da Mary e Tom Poppendieck. Senza voler entrare (almeno in questo contesto) nello specifico, possiamo provare a mappare quello che è il tipico worklfow di esecuzione di un’iterazione Agile con le relative tecniche Lean:

agile workflow lean techinques

Agile Workflow & Lean Techinques

La prima fase è quella di Planning durante la quale il Team Agile è impegnato nella creazione/review del Product Backlog e dell’Iteration Backlog per l’iterazione in start. In tale fase troviamo le seguenti tecniche Lean:

  • Specify Value: identificare e capire cosa rappresenta un reale Valore per gli stakeholder, ovvero per i Clienti. In questa attività il lavoro principale è svolto dal Product Owner, mentre il Product Backlog rappresenta lo specchio delle necessità del cliente;
  • Quality at Source: ricercare la qualità in tutti i suoi aspetti al fine di creare prodotti/servizi privi di difetti. Un Team Agile seleziona per la prossima iterazione solo le feature di cui ha compreso i requisiti, rimandando ad ulteriori approfondimenti le altre. La selezione avviene, ovviamente, sotto la governance del Product Owner;
  • Implement Pull: la produzione è “tirata” dal cliente e non realizzata in funzioni a previsioni di mercato. Nell’Agile i Work Item sono espressione diretta delle esigenze del cliente, sempre sotto la responsabilità del Product Owner;
  • Empower the Team: il Team è autorizzato a prendere decisioni e ha responsabilità diretta di ciò che accade nello stream di produzione. Il Team Agile è autorizzato a selezionare i Work Item che ritiene di poter completare nella successiva iterazione ed è responsabilizzato nella risoluzione delle problematiche annesse al relativo sviluppo.

La fase di Execution è la fase core di sviluppo Agile. Qui troviamo applicate un insieme notevoli di tecniche prese “in prestito” da Lean:

  • Identify Waste: tutto ciò che non produce valore per il cliente è spreco, e come tale va rimosso. Agile abbraccia fortemente tale aspetto, fin dai suoi Valori fondamentali: solo ciò che è importante per il cliente va realizzato, il resto è inutile;
  • Do visual management: l’utilizzo di strumenti visuali è fortemente incoraggiato al fine di avere una visione rapida e sintetica dello stato corrente. Agile fa proprio tale aspetto, basti pensare alla onnipresente task board nelle varie forme;
  • Establish Kanban: Kanaban è il lean tool utilizzato per guidare la produzione in un’ottica pool, limitando il work-in-progress. In Agile non è raro trovare l’utilizzo di una Kanban Board per gestire le fasi di sviluppo/test/verifica;
  • Organize the Workplace: la corretta organizzazione degli ambienti di lavoro è un altro caposaldo de Lean, riassunto dalla tecnica “5S” e finalizzata a creare un workplace efficiente, efficace e stimolate. In questo caso Agile è meno prescrittivo, prediligendo un Team che lavori a stretto contatto, possibilmente in aree adiacenti, ma non indicando alcuna pratica specifica per la sua organizzazione.

La fase finale è quella di Delivery, in cui il prodotto viene consegnato al cliente:

  • Understanding value for customer: l’obiettivo finale di Lean è la Customer Satisfaction, sfruttando i feedback per guidare le modifiche al sistema produttivo e al prodotto stesso. In modo del tutto analogo, Agile coinvolge costantemente gli stakeholder durante tutta la fase di sviluppo del sistema, contemplando, inoltre, a fine iterazione, una specifica Iteration Review, in cui viene presentato al key stakeholder (cliente) l’ultimo incremento realizzato e vengono raccolti i feedback in modo da adattare di conseguenza il Product Backlog per le successive iterazioni;
  • Amplify Learning: una Lean Company è un’azienda che apprende continuamente e costantemente, evolvendosi in funzione delle reali necessità del cliente. Tale apprendimento avviene a tutti i livelli, singolarmente e nell’insieme delle funzioni. Allo stesso modo, Agile incentiva l’apprendimento costante tecnico/tecnologico/metodologico, prevedendo, inoltre, una cerimonia di fine iterazione denominata Iteration Retrospective focalizzata sulla crescita del Team.

Come si vede le similitudini sono tante e Agile sembra avere molto in comune con Lean, il che ci porta ad affermare che nel mondo dello sviluppo software:

è praticamente impossibile parlare di Agile e Lean in modo disgiunto, contemplando concetti e metodologie complementari con il comune obiettivo di incrementare il Valore e la Qualità della soluzione realizzata, abbattendone il tempo ed i costi di realizzazione.

lean vs agile

Lean and Agile, similitudini e differenze

Lean Startup, scientific innovation

Partiamo dal mito: le startup (o start-up) nascono perché un paio di geni lavorano nel loro garage ad una grande idea che cambierà il mondo, sfruttando il contesto particolarmente favorevole. Si tratta dello scenario comune che spesso si associa alle nuove aziende IT che conquistano la ribalta in modo più o meno dirompente, trasformando i propri fondatori in miliardari. Anche grandi colossi come HP ed Apple sono accomunati da questo mito, ma dietro c’è ben altro, tant’è che ben oltre il 90% delle startup fallisce a causa di due fattori fondamentali: nessuno è disposto a pagare per il prodotto/servizio che si è realizzato, non importa quanto esso sia tecnologico o perfetto, e la gestione aziendale è inefficace, perché spesso ritenuta inutile e noiosa.

La questione di fondo è che una startup, per quanto differente dalle aziende già presenti sul mercato, resta comunque un’azienda e necessita di uno specifico approccio di gestione che consenta di farla crescere e stabilizzare. Eric Ries, fautore dell’approccio Lean Startup, definisce in modo estremamente efficace una startup, ovvero:

“Un’istituzione pensata per creare un nuovo prodotto o un nuovo servizio in condizioni di estrema incertezza.”

e propone un approccio scientifico alla sua gestione:

“Ogni prodotto, ogni caratteristica, ogni campagna di marketing – tutto ciò che fa una startup- è inteso per essere un esperimento finalizzato al validate learning.”

Si tratta di affidarsi ad un ciclo operativo che consente di apprendere direttamente sul campo sia le esigenze del cliente (Valore) sia gli sprechi da eliminare (MUDA), migliorando l’efficienza nel creare una soluzione “voluta” dai potenziali clienti e l’efficacia manageriale.

Tale ciclo operativo va sotto il nome di BUILD-MEASURE-LEARN e il compito di ogni startup che voglia avere successo è quello di accelerane l’esecuzione: si comincia con l’identificare il problema che si vuole risolvere, si realizza il set minimale di funzionalità in grado di svolgere tale compito (Minimum Viable Product, MVP), lo si rende disponibile ai potenziali utilizzatori, se ne studia la reazione e si corregge la propria strategia in funzione di essa.

build measure learn

Il ciclo build-measure-learn sottende due aspetti fondamentali dell’approccio sintetizzato da Ries: Validated Learning ed Innovation Accounting.

Il Validated Learning caratterizza il compito primario di una startup: non si tratta solo di creare un prodotto ma piuttosto di capire quale prodotto, in linea con la propria Vision, può interessare i potenziali clienti. L’ “apprendimento convalidato” si basa su esperimenti frequenti che consentono agli imprenditori di verificare ogni elemento della loro Vision e rispondere a quelle domande che li tengono svegli la notte: Stiamo risolvendo un problema reale? E’ chiaro il nostro target di   riferimento? Il target di riferimento è disposto a pagare la nostra soluzione?

E proprio per rispondere in maniera scientifica a tali domande ci si serve dell’Innovation Accounting, ovvero della misura rigorosa del progresso ottenuto, cosa, in verità, estremamente difficile in un contesto di innovazione che si basa di per sé su un processo «semplicemente» troppo imprevedibile. In tale ambito, il progresso non può essere banalmente misurato come un aumento delle entrate o dell’attenzione da parte dei clienti: come si fa a sapere se esso è dovuto ai cambiamenti che sono stati fatti nelle nuove release del prodotto?

E’ necessario, piuttosto, basare le proprie decisioni su metriche che fotografino lo stato reale della startup (Actionable Metrics vs Vanity Metrics) e che risultino:

  • Impugnabili: chiara causa ed effetto;
  • Accessibili: facile da capire e maneggiare;
  • Controllabili: i dati devono essere attendibili.

In tal modo sarà possibile analizzare lo scostamento dalla baseline (situazione voluta) e decidere se continuare sulla strada intrapresa (Perseverate) o se è ora di cambiare strategia (Pivot).

Aggiornamento bug di sicurezza per bug in Git

Oggi è stato pubblicato da Brian Harry un post che parla di una vulnerabilità in Git che permette, nel peggiore dei casi, di eseguire codice sulla macchina di uno sviluppatore. Il post in questione è questo

Git vulnerability with .git\config

La vulnerabilità è stata corretta in tutte le versioni di TFS e di Visual Studio, per cui consiglio a chiunque lavori con git di applicare la corretta patch (I link sono nel post sopracitato ma per comodità li riporto qui).

TFS

  1. TFS 2013 RTM patch
  2. TFS 2013 Update 4 patch

Visual Studio

  1. VS 2013 RTM patch
  2. VS 2013 Update 4 patch
  3. VS 2012 VSIX update

Ricordate di prendere la versione corretta. Per VS2012 è un aggiornamento dei tool di git, mentre per VS2013 il supporto Git è nativo per cui dovete scaricare la corrispondente patch.

Purtroppo se avete un livello di update 1, 2 o 3 dovete prima installare l’update 4.

Buon lavoro.

Comments Off  

Edit dei file di codice sorgente da Web con Visual Studio Online

Brian Harry, sul suo blog, ha annunciato il nuovo rilascio di Visual Studio Online; rilascio che comprende anche l’attesa funzionalità di editing del codice direttamente dal portale web.
Vediamo come funziona.
 
 
Edit
Dopo essere entrati sulla Dashboard del Team Project che vogliamo gestire, andiamo sulla sezione “Code” e selezioniamo dal menù ad albero di sinistra uno dei file di codice sorgente.
 
Sulla destra si aprirà, come al solito, la schermata in sola lettura che contiene il codice. A differenza di quanto succedeva precedentemente, però, è disponibile un nuovo bottone “Edit“.
 
 
Cliccando sul bottone, succederanno tre cose:
  1. La toolbar cambierà visualizzazione
  2. Nel menu ad albero il file selezionato verrà “marcato” con un * ad indicare che è in modifica
  3. Nella schermata sarà possibile apportare modifiche al codice sorgente
 
 
Una volta completata la modifica, è possibile (consigliato, a dire il vero…) inserire un commento nella textbox che verrà associato al checkin e premere sul pulsante di salvataggio (comparso nella toolbar).
 
Cliccato su “Save“, la modifiche vengono salvate sul source control, viene creato un changeset e viene visualizzato un tooltip che ci informa dell’esito positivo dell’operazione, con un link alla visualizzazione del changeset stesso.
 
 
È anche possibile annullare le modifiche utilizzando il bottone “Discard“, sempre nella toolbar.
Infine, se prima di fare il checkin vogliamo verificare le modifiche apportate, è possibile fare una diff tra il file residente sul source control e la nostra versione, utilizzando il pulsante all’estrema destra della toolbar.
 
 
  
Upload, Create, Rename, Delete
Oltre a modificare direttamente i sorgenti, è possibile anche rinominare, cancellare e creare file e cartelle e fare l’upload di nuovi file.
 
 
Per creare un nuovo file o farne l’upload basta cliccare con il tasto destro su una cartella e scegliere “Add file(s)“.
Si aprirà un popup in cui si può scegliere se creare un file nuovo o se scegliere dei file già esistenti da caricare.
 
 
Viceversa, per cancellare un file cliccarci sopra con il tasto destro e scegliere “Delete” (viene chiesta conferma).
 
Per rinominarlo, infine, sempre dal menù contestuale che appare con il tasto destro scegliere “Rename“.
 
Tutte queste operazioni genereranno un changeset, quindi le modifiche saranno mappate e storicizzate sul source control.

Firefighter: Agile anti-pattern

firefighterGli sviluppatori amano sentirsi “importanti” e spesso si emozionano e si pavoneggiano quando sono insigniti del ruolo di firefighter, ovvero di pompieri chiamati a risolvere un’emergenza.

Ho letto, da più parti, che questa pratica è “supportata” da Scrum e dall’Agile in generale, a patto che sia attuata per un tempo limitato e che occupi solo una percentuale di tempo dell’iterazione.

Ebbene, tutto ciò è assolutamente falso! L’Agile non contempla minimamente la presenza di “firefighter” che, anzi, vanno in direzione opposta a quello che è il primo Valore dell’Agile Manifesto:

Gli individui e le interazioni più che i processi e gli strumenti

Tra l’altro, già il riferimento a tempistiche e percentuali, in modo così vincolante, dovrebbe far riflettere.

Un Team di Sviluppo (non solo Agile) è un’entità complessa, viva e con le proprie regole, su cui l’azienda ha investito ingenti risorse al fine di trasformarla in un ecosistema che produca Valore. Immaginare che qualcuno venga insignito del ruolo di “firefighter” mina il Team alle sue fondamenta, andando a creare membri di classe A e membri di classe B, creando fisiologiche frizioni interne e rendendo vano il lungo lavoro fatto per la sua costituzione e maturazione. A questo si aggiunge il fatto che tale approccio limita il know-how e la crescita ad un singolo componente del Team (o comunque ad un suo sottoinsieme), creando ulteriori disparità e demolendo l’idea stessa di Team cross-functional.

Inoltre, chi decide chi è un “firefighter”? Lo Scrum Master, il Team, il singolo Membro? Se il “firefighter” viene scelto, allora si passa ad un approccio command-and-control, all’antitesi dell’Agile, se invece viene (auto) nominato significa che il Team è ben lontano dal sentirsi tale.

Insomma, si evidenzia come questa pratica sia un vero e proprio Anti-Pattern che dà solo l’illusione di risolvere un problema nell’immediato, mentre crea grossi problemi in prospettiva, andando a degradare il Team e, di conseguenza, la sua capacità di creare Valore.

Update pre-natalizi

Potete leggere online le novità di Visual Studio Online relative all’update del 2 dicembre. Di tutte le novità, probabilmente la piu interessante è che, installando la versione del client di Release Manager Update 4, è ora possibile connettere Release Management al proprio account VSO per effettuare il deploy su azure.

Come sempre il deploy non è rilasciato per tutti gli utenti contemporaneamente, ma il rollout avverrà durante la settimana, per cui se non vedere le nuove funzionalità attive nel vostro account, è solamente questione di pazientare un poco.

Happy VSO.

Comments Off