Il tempo nell’approccio lean allo stream di creazione del valore

icon timeChe lo si evidenzi in modo più o meno esplicito è solo un dettaglio, il tempo è un fattore determinate di tutte le attività umane ed è quello predominante anche nell’ambito dello sviluppo di soluzioni software, soprattutto quelle legate a stringenti dinamiche di mercato.

Sappiamo bene che negli approcci “classici” come il waterfall la presunzione è quella di poter determinare in anticipo la durata delle varie fasi del processo di deployment, illudendosi che un Big Design Up Front (BDUF) estremamente dettagliato possa portare ad una stima accurata. Ricordiamolo: la stima deve essere attendibile, ma è impossibile che sia accurata, altrimenti si rischia di avere deadline estremamente discutibili.

In ambito Agile, il tempo è spesso suddiviso in intervalli limitati (time-boxed): decido di suddividere la mia attività di sviluppo in un numero stimato di iterazioni e, ad ognuna di esse, assegno una finestra temporale ben definita (tipo 2 settimane) all’interno della quale mi impegno a terminare gli elementi che compongono l’Iteration Backlog.

Questo approccio è largamente diffuso ed utilizzato e porta indubbi vantaggi, ma anche una situazione di “freeze” che durante l’iterazione non consente di rispondere sempre adeguatamente alle richieste di modifica del cliente, ragionando comunque a breve termine in funzione dell’Iteration Goal.

Nel mondo Lean (Kanban) il focus si sposta sul concetto di Value Stream, ossia un flusso costante e limitato di lavoro finalizzato a massimizzare il valore per il cliente. Non si parla di delivery o deployment dopo xGG o xSettimane, bensì lo si effettua nel momento in cui quello realizzato ha raggiunto uno o più goal concordati con il cliente o con gli stakeholder in generale.

Ma come facciamo in questo caso ad avere un’idea dell’efficienza del team e ad effettuare delle stime accurate in relazione a nuovi progetti richieste? Ebbene, come in Agile esiste la Velocity che è in grado di dirci quante User Story riusciamo a completare in una iterazione, tipicamente in Lean si ricorre ad una serie di “misure temporali”: Lead Time e Cycle Time in primis.

Il Lead Time è fondamentale soprattutto in ottica di management in quanto misura il tempo impiegato dalla richiesta del cliente alla sua evasione. Si immagini che venga richiesta l’aggiunta di una nuova pagina web alla nostra applicazione: ebbene il contatore del Lead Time scatta al momento della richiesta e si conclude quando il cliente può effettivamente utilizzarla, ovvero quando ne viene fatto il deployment.

time teadtime

Lead Time

Bisogna evidenziare un elemento di discussione: un po’ come avviene per la questione “Done-Done” vs “Done-Done-Done” in Agile, non tutti concordano che il Lead Time termini con il Deployment, affermando che invece termina con il Delivery, ovvero quando ciò che è stato realizzato è pronto per la fase di QA e Test di Accettazione. Da un punto di vista della Product Board, però, il Delivery è solo una fase di passaggio, mentre quello che conta realmente è il Time-to-Market, che rientra nella nostra ipotesi primaria.

La seconda misura temporale che abbiamo citato è il Cycle Time, che, invece, è il tempo che il development team impiega per realizzare la funzionalità specifica: il cronometro scatta quindi quando il task viene posto “In progress” e termina quando viene posto in “Done”.

time cycletime

Cycle Time

Possiamo leggere queste due misure da una prospettiva estremamente chiara e significativa:

  • Il Lead Time medio è il tempo medio che il deployment team impiega per mettere in esercizio una funzionalità. Letta in modo diverso, è il tempo del Time-to-Market;
  • Il Cycle Time medio è il tempo medio che il development team impiega per sviluppare una funzionalità.

In questo modo è possibile avere un quadro di quella che è la capacità del team di progetto e del team di sviluppo di rispondere alle esigenze dei clienti.

Esiste anche una terza misura, particolarmente interessante, che calcola il tempo di “reazione”, ovvero il tempo medio di permanenza nel Product Backlog di una richiesta prima di essere schedulata per la lavorazione. Tale tempo è il Reaction Time.

time reactiontime

Reaction Time

Se ragioniamo in termini di DevOps (più Ops), il Lead Time è anche chiamato Resolution Time e insieme al Reaction Time sono due SLA che misurano la risposta in ambito maintance. E’ facilmente intuibile che lo scopo è sempre quello di ridurre quanto più possibile il valore che tali metriche assumono durante le attività di sviluppo, in modo da minimizzare l’effort generale e migliorare il Time-to-Market.

In VSO/TFS non esiste la misura diretta del Lead Time e del Cycle Time, ma è possibile utilizzare il Cumulative Flow Diagram per avere un’idea dell’andamento medio di essi e capire se il team è in fase di miglioramento o viceversa. In esso il Lead Time però fa riferimento al Delivery e non al Deployment della soluzione.

ALM KB CumulativeFlow

Cumulative Flow Diagram

Loggare in più file con Powershell

In questo articolo vedremo come loggare l’output di uno script Powershell all’interno di più file. Per raggiungere questo scopo faremo uso dei diversi message stream che abbiamo già visto nel precedente articolo: do no use write-host cmdlet.

La presenza degli stream in un linguaggio che supporta il piping come Powershell è di rilevante importanza soprattutto per evitare che l’esecuzione dei comandi ricevano messaggi al posto dell’informazione reale che si aspettano. Se volete approfondire l’argomento vi consiglio il seguente articolo: http://blogs.technet.com/b/heyscriptingguy/archive/2014/03/30/understanding-streams-redirection-and-write-host-in-powershell.aspx

Nell’esempio che segue scriviamo in diversi file in base agli output che ci interessano:

  1. Log.txt per Write-Host e lo stream di Output (Write-Output);
  2. Warning.txt per lo stream di Warning (Write-Warning);
  3. Error.txt per lo stream di Error (Write-Error).

In particolare alla riga 16 e 18 inviamo l’output di Write-Warning e Write-Error verso lo stream Output. Tutti gli stream e le informazioni scritte in console tramite Write-Host, vengono scritte nel file Log.txt usando l’operatore “*>” quando richiamiamo lo script (riga 24).

La magia per scrivere negli altri file invece viene fatta usando il Tee-Object, che si memorizza i risultati delle righe 16 e 18 e li scrive nei relativi file.

 

Maggiori info sulla redirezione: https://technet.microsoft.com/it-it/library/Hh847746.aspx

Maggiori info su Tee-Object: https://technet.microsoft.com/en-us/library/hh849937.aspx

do not use write-host cmdlet

Se non fosse ancora chiaro: non usate la cmdlet write-host! Non pensiate che sia la solita affermazione avventata, bensì, il motivo di questa affermazione ha radici profonde. Innanzitutto, chi usa Powershell, deve imprimere nella sua mente un concetto fondamentale:

Powershell is about automation

Questo significa che gli script Powershell che scriviamo devono essere sempre pensati con l’obiettivo di automatizzarli. Ed in questo contesto, la cmdlet Write-Host non ha nulla in comune con l’automatizzazione. Per capire le ragioni di questa affermazione occorre indagare sul funzionamento di Write-Host. Per cominciare, in Powershell esistono differenti message stream:

  1. Output/Success
  2. Error
  3. Warning
  4. Verbose
  5. Debug

Per scrivere all’interno di questi stream si possono invece usare le seguenti cmdlet (numerate in base all’ordine precedente):

  1. Write-Output
  2. Write-Error
  3. Write-Warning
  4. Write-Verbose
  5. Write-Debug

Da qui si evince che Write-Host non è associato a nessuno di questi stream! Questo significa che Write-Host non passa all’interno di nessun message stream, ma le informazioni che gli vengono date saranno sparate direttamente nella console. Quindi questo è l’unico contesto in cui è consigliabile usarla. Ovvero, se abbiamo necessità di creare uno script che non sia automatizzato ma interattivo, in cui l’utente deve interagire, allora Write-Host va bene. Jeffrey Snover, il padre di Powershell, nell’articolo che trovate a fine articolo, consiglia di usarlo per i soli script che saranno poi gettati. In tutti gli altri casi, è consigliabile l’uso di Write-Output. Se vogliamo invece dare la possibilità all’utente di scegliere la quantità di informazioni da mostrare a video o nei file di log, usiamo Write-Verbose.

Per avere un riscontro reale del funzionamento di Write-Host, possiamo usare la seguente cmdlet all’interno di una console:

All’interno del file log.txt troviamo solo l’output di Write-Output ma non di Write-Host. Naturalmente possiamo barare ed eseguire il comando con Write-Messages *> C:Templog.txt.  In questo modo forziamo la scrittura di Write-Host all’interno del file tramite gli operatori di redirezione (ndr: ho notato questo comportamento solo in PS 5). Ma se volete un consiglio spensierato: non fatelo!

Notate che anche la cmdlet Write-Output può scrivere all’interno della console! L’unica differenza è che le informazioni passeranno all’interno dello stream di Output (in formato object) e possono essere riutilizzate per altro (attraverso il piping). Nel caso in cui Write-Output non è seguita da altro, saranno allora visualizzate nella console grazie ad Out-Default. Di sicuro l’unica caratteristica che perdiamo con Write-Output è la possibilità di formattare (o meglio colorare) il testo di output per la console. Però con un po’ di fantasia, possiamo crearci una cmdlet che consenta la colorazione dell’output nella console (ho preso spunto da questo post su Stack-Overflow: http://stackoverflow.com/questions/4647756/is-there-a-way-to-specify-a-font-color-when-using-write-output):

Approfondimenti

Write-Host considered harmful: http://www.jsnover.com/blog/2013/12/07/write-host-considered-harmful/

VSO e deploy di Agosto

Questa volta l’annuncio è sicuramente tardivo, perchè il deploy di VSO è del 7 Agosto, ma volevo comunque, sebbene in ritardo, annunciare una ulteriore funzionalità migliorata della Kanban Board in VSO.

Nei precedenti deploy era stata introdotta la possibilità di cambiare lo sfondo delle card in base a regole sui Work Item, ed avevo mostrato come questa funzionalità può essere utilizzata per marcare visivamente il T-Shirt sizing. In questo ultimo deploy la possibilità di cambiare l’aspetto delle card in base a regole sui work item è stato ulteriormente espanso, permettendo interessanti combinazioni.

Se premete il bottone dei settaggi nella Kanban Board, la prima cosa interessante è che viene aperta una visualizzazione in cui potete configurare molte opzioni del vostro account che riguardano la visualizzazione agile.

 

image

Se aggiungiamo una regola, possiamo verificare che ora è possibile anche personalizzare il titolo, ad esempio si può creare una regola per cui se la card ha una priorità uguale a 4 (massima) il titolo verrà mostrato in rosso ed in grassetto.

image

In alto a destra potete vedere una preview, di come verrà visualizzato il titolo, e nella vostra board ora si può visualizzare immediatamente le card per cui la priorità è massima.

image

Oltre a questo, un’altra interessante novità riguarda le librerie client per sviluppare con TFS. Nella versione VSO/2015 le nuove REST API costituiscono probabilmente una delle migliori opzioni, dato che non richiedono nessuna libreria, ma se avete codice che utilizza il Client Model di TFS, la conversione non è indolore. Finalmente il Client Object Model di TFS è disponibile come libreria Nuget, come potete leggere qui. Questo significa anche che potete redistribuire tutte le dll, invece di richiedere l’installazione del Team Explorer / Visual Studio.

Happy VSO.

Gian Maria.

Benvenuto BugGuardian

Qualcuno avrà probabilmente notato che negli ultimi mesi ho scritto solo qualche post qui sul blog. Questo per due motivi principali

Il primo è che, come alcuni già sanno, qualche mese fa mi sono trasferito in un altro paese, piuttosto lontano, con una cultura ed una lingua piuttosto differenti, dove ho iniziato una nuova avventura. Questo ha inevitabilmente preso molto del mio già risicato tempo libero.
Il secondo motivo per cui non sono stato molto attivo qui, che è anche la ragione di questo post, è che ho lavorato ad un nuovo progetto che ho rilasciato oggi: BugGuardian.
Cos’è BugGuardian
BugGuardian è una libreria Open Source, scritta in C# Shared Project, che permette di creare in modo molto semplice dei work item di tipo Bug su un account Visual Studio Online o su un Team Foundation Server 2015 on-premises nel caso in cui l’applicazione sollevi un’eccezione non gestita (Unhandled Exception).
Può essere ovviamente usata anche con delle invocazioni manuali nei blocchi di try/catch per tenere traccia delle eccezioni gestite.

Questa libreria supporta applicazioni scritte con il .Net Framework v4.0 e superiori e può essere usata in moltissimi tipi di progetto, tra cui:
  • Asp.net
  • Asp.net MVC
  • WPF
  • Windows 8 / 8.1 Apps
  • Windows Phone 8 / 8.1 Apps
  • Universal App
  • Universal Windows Platform Apps (Windows 10)
  • ecc
Come ho detto, si tratta di un OSS quindi potete trovare tutti i sorgenti pubblicati su GitHub.
Per poterla installare ed usare senza necessariamente doverla compilare manualmente, ho pubblicato il pacchetto su NuGet. È sufficiente cercare BugGuardian nella Package Manager GUI o eseguire il seguente comando Package Manager Console:
Install-Package DBTek.BugGuardian
Utilizzo, supporto e Feedback
Per trovare linee guida ed esempi sull’utilizzo della libreria consultate la documentazione del progetto. Inoltre nella cartella TestApps dei sorgenti ci sono alcuni esempi di utilizzo con i tipi di applicazione più comuni.

Ad ogni modo, solo per fare un esempio di quanto sia semplice utilizzarla, questo è il codice di cui avrete bisogno per gestire un’eccezione e creare il relativo Bug su VSO / TFS:

using (var creator = new DBTek.BugGuardian.Creator())
{
creator.AddBug(myException);
}

Se avete dei dubbi o dei problemi durante l’utilizzo di questa libreria, fatemelo sapere attraverso la  Issues page di GitHub e cerrchero di fixare il problema prima possibile!
Attendo i vostri feedback :)

Voglio ringraziare il mio amico e “collega” Marco Minerva (@marcominerva) per il supporto, la pazienza e la Code Review.

Come gestire la security con SQL Source Control

Una delle problematiche più comuni che si hanno gestendo il database sotto source control è quello derivante dalla security. 

Nel caso in cui si seguano pratiche in cui è l’utente il detentore delle autorizzazioni, non risulta per nulla semplice applicare soluzioni “portabili”. Il problema sta soprattutto in fase di deploy o di “get” delle versioni sulle macchine degli sviluppatori. Proviamo a pensare ai due casi:
Primo caso – sviluppo
Immaginiamo di avere due differenti workstation guidate dallo stesso repository remoto di controllo del codice sorgente (SC), una delle quali ha un’istanza SQL Server ai quali database si accede con sql authentication ed una in cui, per accedere ai database, si usa la sicurezza integrata di windows. Gli sviluppatori continuano a modificare il database e, spesso, incorrono nella necessità di dare le dovute permission ai propri utenti (uno windows ed uno sql creato ad hoc tramite login). 
In questo scenario proposto, nessuno dei due utenti è sysadmin, altrimenti le permission sarebbero superflue. Supponendo di avere una tabella HumanResources.Employees, ogni dev, per attribuire i permessi di INSERT/UPDATE SELECT, dovrebbe scrivere il seguente listato:
GRANT INSERT, UPDATE, SELECT ON HumanResources.Employees TO ‘AALPI-NBreporter’; — Windows
GRANT INSERT, UPDATE, SELECT ON HumanResources.Employees TO myDatabaseUser; — SQL

In generale, già dall’aggiunta dell’utente, i dati verranno messi sotto source control, se non diversamente specificato:

Entrambi, dopo le modifiche, proseguiranno con il “check in”, o meglio, con l’operazione di invio dei cambiamenti al repository remoto.
Ma ora, ogni qual volta gli sviluppatori proveranno a percepire le nuove modifiche, che succede?

Presto detto, ognuno dovrà “sorbirsi” l’utente e la login dell’altro (e non è detto che esista sull’istanza). Ecco come verrà proposta la modifica sulla prima istanza:

Questo significa che lo sviluppatore che sta utilizzando la sicurezza integrata sarà costretto, al fine di proseguire con l’operazione di get, a creare una login identica a quella inviata dall’altro collaboratore. Allo stesso modo accade il viceversa, solo che, mentre nel primo caso è possibile creare la login, se l’utente windows proposto non esiste già, risulta un tantino invasivo allineare la propria macchina per ricevere la modifica. 
Da notare inoltre che, quando vengono incluse informazioni sensibili (nell’esempio la password della login proposta) esse vengono completamente mascherate e stravolte. Cosa che porta ulteriori problemi; si pensi ad esempio ad un’applicazione in sviluppo che utilizza l’utente per connettersi. Il config è sul repository centrale salvato con una password e quindi risulta molto scomodo dover cambiare ogni volta l’informazione di autenticazione.

Provando ad accettare le modifiche così come sono, otterremo i seguenti feedback. Prima di tutto un warning per le informazioni sensibili:


ed, in secondo luogo, una nuova login/utente che non avevamo prima:
Nel caso del passaggio di una credenziale windows, avremmo addirittura ricevuto un errore bloccante. Non è detto che l’utente windows sia presente sulla macchina di sviluppo di un nostro collaboratore.

Secondo caso – deploy in ambienti di staging/test/produzione
Il primo caso, seppure scomodo, è comunque da considerarsi non troppo pericoloso. Purtroppo non è possibile dirlo per i deploy negli ambienti successivi allo sviluppo. Un deploy di questo tipo può portare dei disastri sulla sicurezza dell’ambiente verso il quale andiamo a pubblicare le nostre applicazioni/database. Dopo aver accettato in sviluppo le modifiche di cui al punto precedente, immaginiamo ora di fare deploy con un prodotto di diff, per generare gli script da applicare. 
Risulta facile capire che, esattamente per come accade durante le operazioni di get, gli algoritmi di diff andranno a proporci le nuove utenze create in sviluppo per applicarle sugli ambienti successivi allo sviluppo. 
Soluzioni possibili
I suddetti problemi, molto simili, provocano non pochi problemi, addirittura possono danneggiare i nostri ambienti di deploy. Per fortuna abbiamo qualche possibilità, fornita da SQL Source Control.
Primo step – da utente a ruoli
Sicuramente, il modo migliore per non essere contagiati da questo problema è utilizzare i ruoli a database. Un ruolo è un punto sul quale andare ad attribuire permessi senza “scomodare” utenze, ma soltanto facendo in modo che queste ultime ne facciano parte, esattamente come per un gruppo su domain controller. Supponendo di avere un ruolo ApplicationAccessRole, le operazioni di cui al primo punto, diventano:
GRANT INSERT, UPDATE, SELECT ON HumanResources.Employees TO ApplicationAccessRole;
Proviamo quindi a creare un ruolo, con l’istruzione CREATE ROLE ApplicationAccessRole; e, successivamente, eseguire il comando di GRANT appena descritto. Una volta eseguio, associamo al ruolo l’utente che stiamo utilizzando (negli esempi di sviluppo sopra,myDatabaseUser) con la sp_addrolemember o con la nuova sintassi di ALTER ROLE.

EXEC sys.sp_addrolemember @rolename = ‘ApplicationAccessRole’, @membername = ‘myDatabaseUser’;
oppure
ALTER ROLE ApplicationAccessRole ADD MEMBER myDatabaseUser; –<– from SQL Server 2012

Questa operazione porterà il SQL Source Control a proporci quanto segue:

ci siamo quasi, anche se l’utente appare ancora. Passiamo allo step successivo.

Secondo step – Ignorare gli utenti
Nel tab di setup del database sotto source control è possibile aggiungere la spunta su “Ignore users and role membership”:

Una volta aggiunta, il SQL Source Control ci proporrà di fare salvataggio dei cambiamenti di un particolare oggetto, chiamato Database Comparison Options. Facciamo checkin solamente di quel file e aggiorniamo l’anteprima del cambiamento che stiamo per committare. Otterremo finalmente quanto desiderato:
La membership dell’utente non è più proposta, quindi non siamo legati ad esso. Siamo veramente molto vicini alla conclusione, tuttavia, è ancora possibile aggiungere utenti manualmente al nostro database (e quindi anche al source control).

Terzo step – filtrare gli utenti
Il SQL Source Control ci consente l’utilizzo di filtri molto comodi per decidere cosa e come pulire i nostri changeset. Per definirli, è sufficiente premere il tasto destro sul database e selezionare in “Other SQL Source Control tasks” la voce “Edit filter rules..”:
La schermata che apparirà consente sia di filtrare intere classi di oggetto, sia di personalizzare il filtro con pattern di stringhe, sia sullo schema sia sul nome dell’oggetto:
Una volta salvato, oltre ai cambiamenti generati dagli script precedenti, troveremo anche il filtro nell’anteprima dei changeset. Come suggerisce il tool, è necessario fare checkin prima del filtro stesso, per avere i filtri applicati sugli oggetti che sono in modifica. Quando il filtro raggiunge il source control, anche un nuovo utente creato manualmente da SQL Server Management Studio non sarà più visibile.

Stay Tuned! 

Criteri di Accettazione e Definition of Done… una questione di “3 Amigos”

Durante le varie attività di coaching, spesso mi sento chiedere: “chi deve scrivere i Criteri di Accettazione?” oppure: “a Chi spetta il compito di specificare la Definition of Done?”.

Ebbene, la mia riposta è più o meno sempre la stessa: “non si tratta di identificare Chi, ma di Condividere al meglio una responsabilità”.

Soprattutto, bisogna sempre ricordare che i Criteri di Accettazione sono elementi “vivi” che maturano durante la vita del progetto e sono direttamente legati all’evoluzione stessa e alla comprensione della specifica Feature/User Story; il tutto sotto il cappello della Definition of Done.

In quest’ottica, la definizione dei Criteri di Accettazione aiuta a capire più in dettaglio i boundary relativi alla specifica User Story e pone le basi per la realizzazione dei Test di Accettazione. Una loro prima stesura può essere effettuata parallelamente alla scrittura stessa delle User Story o in uno specifico meeting dedicato (es: Story-writing workshop, backlog grooming, ecc).

Fondamentale è che il team collabori alla definizione e al riferimento di tali criteri e, possibilmente, alla definizione dei relativi test. Nella pratica, però, può capitare che il team sia impossibilitato, ad esempio, a rivedere una Feature presente del Product Backlog in modo rapido, soprattutto se è nel mezzo dell’iterazione e la sua attenzione è quindi sull’Iteration Backlog.

Come fare, allora, a supportare il PO nella sua interazione con il cliente? Ebbene, può essere utile sfruttare una tecnica nota come “3 Amigos”, formalizzata probabilmente per la prima volta da George Dinwiddie e molto simile a quanto proposto da Janet Gregory e Lisa Crispin, nel libro Agile Testing, con il nome di “The Power of Three”.

L’idea è quella di organizzare un meeting snello e veloce, nel momento in cui serve, a cui partecipa un temporary team per discutere puntualmente e in modo conciso su uno specifico argomento, in stile Kaizen Blitz. Il temporary team è composto da tre figure, i “tre Amigos” appunto: Product Owner, Developer e QA Tester.

3amigos

3 Amigos

Si pensi alla differenza con il classico planning meeting o al grooming che, tipicamente, avvengono ad inizio e fine iterazione: che succede se l’iterazione è di 3 settimane ed è appena partita? Sicuramente non possiamo aspettare che termini, ma non è neanche opportuno distogliere tutto il team dalle proprie attività, soprattutto se quanto richiesto dal nostro cliente non viene prima calato nel contesto specifico.

Grazie alle diverse competenze dei 3 Amigos, la specifica richiesta del cliente viene discussa da più punti di vista, andando a realizzare una prima formalizzazione delle Feauture relative che cercano di coniugare al meglio le esigenze del cliente con quelle delle attività in corso. Il tutto avviene in chiave Given-When-Then, template tipico dei Criteri di Accettazione:

  • (Given) some context
  • (When) some action is carried out
  • (Then) a particular set of observable consequences should obtain

ottenendo una serie di asserzioni simili alle seguenti:

  • (Dato) il mio conto bancario online e accertato di avere un saldo sufficiente
  • (Quando) provo ad effettuare un bonifico che rientra nelle mie possibilità
  • (Allora) il sistema deve completare l’operazione senza errori

Chiariti i dubbi primari lato business (si spera ;-)), è responsabilità del Team rifinire la User Story e gli stessi Criteri di Accettazione: take it to the team!

La cosa su cui bisogna fare molta attenzione nell’utilizzo di questa pratica è la capacità del Developer e del QA Tester di discutere in funzione del Dominio e del Contesto specifico, al fine di evitare che il meeting si trasformi in un workshop per spiegare tali elementi, vanificandone sostanzialmente lo scopo.

The One Metric That Matters

Nel precedente post dedicato alle Actionable Metrics abbiamo parlato della Cohort Analysis e di come la suddivisione di utenti in gruppi omogenei sia estremamente utile ai fini di una deep analysis.

Ma una startup si trova oggettivamente a confrontarsi con decine, se non centinaia, di dati diversi, spesso difficilmente aggregabili tra loro e che si prestano a un numero altrettanto elevato di metriche. Come riusciamo a districarci tra tali metriche, andando, soprattutto, ad identificare quelle realmente significative per monitorare la nostra crescita e per validare il risultato delle innovazioni introdotte nel nostro MVP?

geek poke roi

 a lot of metrics

Scontato dire che “dipende”: dipende dal business, dipende dal prodotto, dipende dai clienti…. Detto questo, esistono comunque alcuni elementi che ci consentono di ragionare in modo più oggettivo, unitamente ad una serie di strumenti pratici per aiutarci a ridurre il range d’azione. Partiamo subito con il dire che una metrica è oggettivamente “meritevole” se è un indicatore di

dove siamo ora rispetto al nostro passato, dove stiamo andando, se continuiamo sulla strada intrapresa (presereve), e dove vogliamo andare

In generale, gli esperti concordano nel considerare una metrica come una “buona metrica” quando essa contempla tutte le seguenti caratteristiche:

  • Esprime un tasso o un rapporto , piuttosto che un valore assoluto o cumulativo. Ad esempio: il tasso di crescita degli utenti nel corso del tempo è un valore assolutamente più significativo rispetto al loro numero totale;
  • Comparativa , permettendo di confrontare direttamente i risultati precedenti nei diversi intervalli temporanei. Ad esempio: il tasso di crescita degli utenti è aumentato del 2% rispetto alla settimana precedente;
  • Non complicata , relativamente facile da capire;
  • Facilita e migliora l’accuratezza delle previsioni;
  • Coerente e regolare (giornaliera, settimanale, mensile, trimestrale);
  • Condiziona il nostro comportamento .

Detto questo, gli elementi del nostro “dipende periodico” sono quelli che condizionano la scelta tra le “buone metriche” che comunque possono essere di numero considerevole. Dobbiamo quindi valutare i seguenti fattori:

  • Il business di riferimento . Va di per sé che se il nostro business è on-line sicuramente avremo delle metriche diverse da chi si occupa della vendita diretta: si pensi ad esempio alla misura che rileva quanto i nostri utenti sono “collaborativi”, scrivendo recensioni o votando le risposte di altri clienti. Per questo fattore, comunque, esistono anche una serie di parametri indipendenti, come ad esempio il “coefficiente virale” o, se preferite, “il passa parola”;
  • La fase di attuazione del nostro esperimento (stage). E’ fondamentale individuare bene in quale fase del processo di crescita della nostra startup ci troviamo, poiché ognuna di esse deve avvalersi di metriche specifiche, potenzialmente inutili nelle altre. Con riferimento alla Customer Development di Blank, possiamo trovarci in quattro fasi:
    • Customer Discovery , in cui stiamo scoprendo i nostri utenti e i nostri clienti, ovvero coloro per sono disposti a pagare perché vedono nella nostra idea una soluzione ad un loro problema reale. Spesso si utilizzano questionari o interviste, fatte su una popolazione organizzata in funzione del nostro presunto posizionamento di mercato, andando a valutare quantitativamente i dati ottenuti. Un approccio più pragmatico è quello di utilizzare un pretotype per la verifica sul campo della nostra idea;
    • Customer Validation , in cui andiamo a convalidare il nostro bacino di utenti. In tale fase è fondamentale lavorare velocemente e qualitativamente sul nostro MVP in modo da poter chiedere ai nostri potenziali clienti: “come ti sentiresti se non potessi più usare la nostra soluzione?” andando a raccogliere quantitativamente la risposta e qualitativamente il grado di soddisfazione che ne emerge;
    • Customer Creation, in cui il focus è sulla creazione di un modello di business in grado di scalare, basato su una soluzione di qualità con le feature desiderate dai clienti di riferimento. In questa fase è fondamentale avere delle metriche che consentano di priorizzare e validare le features stesse e le attività in essere;
    • Company Building, in cui smettiamo di essere una startup e diventiamo un’azienda sul mercato con l’obiettivo di essere profittevole, andando a rendere efficienti i processi interni e spingendo sulla crescita economica/finanziaria.

search execute extended

  • I nostri utenti, o meglio i nostri stakeholder, che per una startup significa:
    • Founders: metriche che consentano di validare il modello di business;
    • Developers : metriche per fissare le priorità e l’ottimizzazione delle feature;
    • Marketing : metriche che misurano il tasso di crescita in relazione agli utenti;
    • Investitori : metriche legate alla crescita attuale e a quella potenziale. Si pensi a metriche quali: growth rate, customer lifetime value, customer acquisition cost, ecc..

Come si intuisce, la definizione, validazione e valutazione delle metriche è un’attività “costosa” che impegna costantemente la startup a tutti i livelli, senza eccezioni.

theoneSpesso le startup ricorrono ad una rappresentazione grafica dei risultati tramite una serie di dashboard, andando nel tempo a limitarne il numero in funzione di quelle che riscontrano essere più significative. L’obiettivo da ricercare è quello della “The One Metric That Matters” (OMTM), ovvero scoprire e focalizzarsi su quella che è la metrica più rilevante per il proprio “esperimento”, andando a tracciare una riga nella sabbia che definisce, su base settimanale/mensile/quadrimestrale/annuale e in modo chiaro, quando le nostre azioni hanno prodotto un significativo passo in avanti del nostro “esperimento”.

line in the sand

The One Metric That Matters, a line in the sand

E’ abbastanza evidente che l’OMTM può essere sicuramente univoco nei primi mesi di vita di una startup, ma quando la stessa inizia a cresce e strutturarsi, diventa più probabile avere diversi OMTM in funzione dei vari team, e successivamente dei vari reparti, su cui si poggia la nostra azienda in espansione.

Kaikaku: Kaizen Blitz

Nell’appuntamento precedente abbiamo descritto la filosofia Kaizen, intesa come un processo di miglioramento continuo a piccoli passi.

Esiste però un’eccezione, dovuta a situazioni di emergenza in cui è necessario ottenere rapidamente un breaking point, ovvero una soluzione di rottura che consenta di riallinearsi ai risultati attesi, andando ad eliminare rapidamente gli sprechi (MUDA) grazie ad una rapida innovazione di processo, tecnologica o anche una loro combinazione.

Anche per raggiungere questo obiettivo esiste un termine ben preciso: Kaikaku, letteralmente “cambio radiale” duale al Kaizen che predilige, come visto, l’approccio opposto.

Il Kaikaku è anche conosciuto come Kaizen Blitz, Kaizen Events, Breakthrough Kaizen, System Kaizen e Flow Kaizen, con quest’ultima declinazione che ben si presta ad evidenziare come, nell’applicazione pratica, il Kaikaku sia la combinazione di diversi Tool Lean con il ciclo di Deming, così come rappresentato nella figura seguente:

kaikaku

Kaikaku in Action

Le fasi che contraddistinguono il Kaikaku sono, quindi, otto, direttamente correlate al Plan-Do-Check-Act:

  • Plan
    • Select the Theme: viene isolato e scelto l’elemento su cui attuare la trasformazione;
    • Plan the Schedule: viene specificato l’intervallo temporale di osservazione;
    • Grasp the Present Situation: viene formalizzata la situazione presente;
    • Estabilish the Target: viene definito l’obiettivo a cui tendere.
    • Analyze the Cause & Identify Corrective Action: vengono analizzate le cause dello scostamento dell’obiettivo desiderato ed identificate le azioni correttive da intraprendere;
  • Do
    • Implement Corrective Action: vengono messe in atto le azioni correttive selezionate.
  • Check
    • Evaluate the Result: vengono valutati i miglioramenti (o i peggioramenti) derivati dalle azioni correttive applicate.
  • Act
    • Standardize & Follow-up: se effettivamente sono stati riscontrati dei miglioramenti, quanto attuato viene reso parte del processo. Se quanto ottenuto consente di raggiungere gli obiettivi del Kaikaku, il tutto termina, altrimenti si può pensare di ripetere più volte il ciclo.

E’ fondamentale sottolineare che il “blitz”, per essere tale, deve:

  • avere una durata di 3 – 5 giorni;
  • definire un obiettivo e uno scopo chiaro;
  • produrre piccoli cambiamenti immediatamente assimilati;
  • coinvolgere chiunque si pensi possa essere utile o chiunque voglia dare il proprio contributo.

Tipicamente, il Kaikaku ed il Kaizen sono entrambi presenti nel processo di trasformazione di un’azienda, creando una stretta sinergia basata su cambiamenti repentini seguiti dal loro perfezionamento e dalla loro stabilizzazione successiva.

full innovation stack

Full Innovation Stack

Deployare una Web App su Azure con la nuova Build di Visual Studio Online

In questo post vedremo come fare, iniziando da 0, a deployare una nostra soluzione su una Web App di Azure utilizzando la nuova Build di Visual Studio Online.
Per farlo, useremo esclusivamente il portale web di VSO.
Collegare Azure a VSO
Innanzitutto bisogna “far sapere” a Visual Studio Online che abbiamo un account Azure che vogliamo utilizzare come endpoint di deploy per la nostra soluzione.
Per farlo, dobbiamo andare nella parte dei setting del progetto (cliccando sull’apposito bottone  presente in alto a destra, dopo essere entrati nella pagina del progetto), cliccare sulla tab “Services“, poi su “Add new Service Connection” ed infine su “Azure“.
A questo punto si aprirà un popup dove dovremo inserire l’ID della sottoscrizione Azure che contiene o conterrà la web app da pubblicare, un nome (anche se il campo si chiama “Subscription Name“, non è necessario usare il nome della sottoscrizione, si tratta di un campo di testo libero che ci servirà per identificare la sottoscrizione nel caso ne collegassimo più di una a VSO) e le modalità di autenticazione.
È possibile utilizzare sia un certificato (reperibile tramite il portale di Azure) sia direttamente le credenziali.
Fatto questo, la nostra subscription di Azure e il nostro account Visual Studio Online saranno collegati (almeno su questo team project).
Creare la build definition
Ora che abbiamo impostato la connessione tra VSO ed Azure, spostiamoci nella sezione Build del progetto e creiamo una nuova build definition di tipo deployment.
Siccome vogliamo deployare su Azure, nella sezione “Deployment” scegliere “Azure Website” come indicato nell’immagine.
Verrà create una nuova build definition con alcuni step da configurare.
Vediamo passo passo come procedere.
Il primo step rappresenta il vero e proprio processo di Build. È completamente configurabile, ma la cosa più importante è quella di definire il file di soluzione che dovrà essere utilizzato come source della build. Va selezionato nella casella indicata dalla freccia rossa.
Nel secondo step vanno inseriti i criteri di esecuzione post-build degli Unit Test. Se non abbiamo degli unit test (male…) oppure non vogliamo eseguirli (male anche questo :) ) possiamo eliminare questo step cliccando sulla “X” che compare spostanto il mouse su questo step.
Il terzo step è quello che ci interessa di più in quanto è quello che si occupa di fare il deploy del risultato della Build verso la nostra web app su Azure.
Qui troviamo un menu a discesa in cui, se l’associazione della sottoscrizione Azure è andata a buon fine, troviamo le nostre sottoscrizioni collegate a VSO e possiamo scegliere quella che faà da target per il deploy.
Nella casella successiva, denominata “Web App Name” dobbiamo inserire manualmente il nome della Web App di destinazione. Come vedete in realtà si tratta anche in questo caso di una Combo Box, ma al momento attuale le Web App già esistenti non vengono caricate automaticamente (non dimentichiamo che questa nuova build è ancora in preview).
Ecco quindi alcuni consigli e note:
  • Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione e che non esiste nella region selezioanta, verrà creata su Azure nella region selezionata
  • Se inseriamo un nome di una web app che non esiste nella nostra sottoscrizione ma che esiste già in quella region, verrà restituito un errore in fase di deploy
  • Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione ma che è in una region diversa, verrà restituito un errore in fase di deploy
  • Se inseriamo un nome di una web app che esiste già nella nostra sottoscrizione e che si trova nella region selezionata, il deploy utilizzerà quella web app e la aggiornerà

Quindi attenzione a quello che scriviamo :)
I due step rimanenti danno la possibilità di indicizzare e pubblicare i simboli della nostra applicazione (consigliato per poter avere informazioni aggiuntive in caso di eccezioni non gestite) e di pubblicare gli artifact risultati dalla build.
Quando abbiamo impostato tutti i parametri, possiamo salvare la nostra build definition assegnandole un nome.
Possiamo anche modificare i vari parametri di default navigando nelle varie tab per personalizzare la build secondo le nostre esigenze.
Deployamo!
Una volta completate le personalizzazioni, è il momento di lanciare la compilazione e di verificare che il processo di deploy vada a buon fine.
Per lanciare la build, utilizziamo il bottone “Queue build” presente nella toolbar della build definition oppure nel menu contestuale della build stessa.
Quando clicchiamo su quel bottone, il sistema accoderà una build su un agente di compilazione presente sui nostri server oppure in un datacente Microsoft (nel caso in cui abbiamo scelgto di utilizzare la build “hosted”)
In ogni caso il progesso sarà visibile nella console real time presente sul web.
Prima verranno eseguiti i task di build e di test:
Poi, al successo di entrambi, il deploy verso azure:
Quando tutto sarà finito, avremo la nostra applicazione funzionante e deployata su Azure. Facile!