Come rimuovere i TAG non più utilizzati su Visual Studio Online

Per tutti quelli che hanno avuto a che fare con i tag di Visual Studio Online in maniera corposa, saprete che creare un tag è semplicissimo. Basta scrivere la stringa nell’area relativa in un qualunque item:

Ogni tag aggiunto viene memorizzato sul team project ed è molto semplice andare a ripescarlo in un momento successivo, ad esempio, quando creiamo un altro item:
Fin qui tutto perfetto. Tuttavia, potrebbe succedere che alcuni tag non servano più nel tempo. In questo caso, eliminandoli da tutti gli elementi collegati, dovrebbero scomparire. Purtroppo questo non succede, almeno su Visual Studio Online, e, di certo non subito. Provando a controllare dopo una settimana, nulla è accaduto. Tutti i tag non usati esistono ancora. Non c’è niente di male a lasciarli, anzi, possono tornare utili, oppure, possono effettivamente essere tag nuovi ai quali ancora non è collegato nessun item. Ed ecco qui che viene comoda l’estensione che ho trovato sulla gallery, chiamata “Tag Admin For Visual Studio“, disponibile sia nella versione 2013 che 2015.
L’estensione, scaricabile direttamente dalla Visual Studio Gallery (anche tramite Visual Studio) ed è installabile in pochi click. Quello che troverete è un nuovo item di menu sul team explorer:
L’interfaccia è molto semplice, all’apertura vengono caricati tutti i tag immessi. Per ogni tag che andiamo a selezionare è possibile effettuare delle operazioni, quali:
  • Vedere gli tem collegati
  • Rinominare il tag (se non sono scelti più tag)
  • Cancellare i tag
  • Ed è proprio l’ultima opzione che consente di rimuovere definitivamente i tag che non ci servono più:
    Dopo un messaggio di conferma (da notare che nell’immagine si stanno eliminando tag legati ad altri item), i tag sono eliminati con successo:
    Dopo l’aggiornamento dell’eventuale pagina di backlog aperta, non ne troveremo più traccia sulla tendina di autocompletamento:
    Per scaricare le estensioni clickate sui seguenti link:
    Stay Tuned! 

    Thoughtland,la Terra del Pensiero

    idea mini Lean Startup presuppone che al neo imprenditore si sia “accesa la lampadina”, ovvero che abbia maturato un’idea che ritiene vincente e per la quale è disposto a mettersi in gioco.

    Ma come nasce un’idea e come si giunge alla conclusione che essa è perseguile?

    Prima di tutto bisogna ricordare che la grande maggioranza delle nuove startup fallisce, ovvero i nuovi prodotti/servizi realizzati sono un totale insuccesso. Questo fatto è stato riassunto in quella che Alberto Savoia ha definito la Legge dell’Insuccesso:

    “La maggior parte dei nuovi prodotti fallisce, anche se sono realizzati in modo impeccabile.”

    In quest’ottica, è bene rendersi conto che un buon modo per iniziare un “nuovo esperimento” con qualche chance di successo, è quello di partire da un’idea chiara, tenendo presente che qualsiasi idea è sempre sottoposta ad un periodo gestazione nella cosiddetta “Terra del Pensiero”:

    “La Terra del Pensiero è un posto immaginario abitato da due strane entità fluttuanti che interagiscono tra di loro: idee ed opinioni. Più precisamente: idee non realizzate ed opinioni riguardo quelle idee.” [Alberto Savoia]

    terra pensiero

    Si tratta di una interessante rappresentazione del processo di maturazione che ogni nuova idea attraversa prima di diventare la base del nostro nuovo “esperimento” di business. Finché le idee restano nella Terra del Pensiero, e quindi sono idee astratte, l’unica cosa che producono sono opinioni, che, però, possono essere estremamente pericoloso e portare a due conseguenze indesiderate:

    • Falsi negativi, generati da opinioni che ci possono spaventare e far abbandonare prematuramente la nostra idea;
    • Falsi positivi, generati da opinioni che ci possono rendere ciechi alla Legge dell’Insuccesso e farci imbarcare in iniziative troppo prematuramente.

    Nel primo caso la nostra idea è talmente tartassata da opinioni negative che la abbandoniamo a sé stessa, facendoci sopraffare dalla Legge dell’Insuccesso anche quando essa ha una possibilità su mille di essere quella giusta. Nel secondo caso, invece, ignoriamo completamente la fortissima probabilità di fallimento e ci buttiamo a capofitto nel nostro “esperimento”, anche se la nostra idea è destinata già in partenza al fallimento.

    In funzione delle opinioni, durante la gestazione nella Terra del Pensiero, le nostre idee possono subire sorti differenti, portandoci a:

    • non fare nulla: la nostra idea non lascia mai la Terra del Pensiero, siamo pigri e cauti ma tra le 1000 idee sbagliate potremmo buttare via anche quella buona;
    • avanti tutta!: lo sviluppo della nostra idea, surrogata dai falsi positivi, diventa la nostra ragion d’essere, ignorando quali sono le finalità della nostra startup. Cominciamo così a sviluppare un “prodottòtipo” senza curarci dei potenziali clienti e, se qualcosa non va, crediamo che sia colpa di come lo abbiamo realizzato ed investiamo nel suo miglioramento, senza renderci conto che nessuno ha bisogno di esso.

    Entrambe queste scelte sono estremamente pericolose e, nella stragrande maggioranza delle volte, portano alla morte, più o meno dolorosa, della nostra idea.

    Cosa possiamo fare allora? Beh, bisogna uscire quanto prima dalla Terra del Pensiero, dove tutte le idee nascono, ma dove si appesantiscono di falsi negativi, falsi positivi, paure e molta altra zavorra.

    make it happen featured

    Bisogna in sostanza “pretotipare” e avviare il “nostro esperimento”, velocizzando l’esperimento e imparando a conoscere il nostro business e i nostri clienti (Lean Startup docet): make it happen!

    Visual Studio Code

    Nei giorni scorsi si è svolta a San Francisco la più importante conferenza Microsoft dell’anno: //build/. Tante sono state le novità, tra cui un nuovo editor di sviluppo della famiglia di Visual Studio, il cui nome è Visual Studio Code. Questo editor, che è stato rilasciato attualmente in preview, consente la creazione di progetti orientati al cloud e al web ed è cross-platform: supporta infatti Windows, Linux e OSX. Il motivo principale che ha portato la nascita di questo IDE è stata la volontà di mettere a disposizione degli sviluppatori un ambiente leggero e di semplice utilizzo che aiuti a creare applicazioni che coinvolgono diverse tecnologie tra cui: ASP.NET, Node.js, HTML, CSS, LESS, SASS e JSON. E’ interessante sapere che questo IDE nasce come customizzazione di un editor già esistente chiamato Electron, che è stato utilizzato dietro le quinte anche da Visual Studio “Monaco” (il famoso editor online di Visual Studio). Inoltre, la presenza come il debugger, l’intellisense o l’integrazione con git, lo rendono un ambiente davvero attraente per il front-end developer. Il primo passo da fare per usare Visual Studio Code è quello di scaricare il pacchetto appropriato per il proprio sistema operativo da https://code.visualstudio.com/Download e installarlo sulla propria macchina (figura 1):

    Figura 1 – Le diverse piattaforme supportate da Visual Studio Code

    Inoltre, possiamo scegliere di installare oltre al pacchetto base, a seconda del nostro sistema operativo o di ciò che abbiamo già installato sullo stesso, una serie di tool aggiuntivi che ci aiuteranno nella realizzazione delle nostre applicazioni:

    • NET 5;
    • NodeJS (incudes NPM);
    • git: (command line tools);
    • Yeoman: un tool per fare lo scaffolding di applicazioni, ovvero genera per noi la struttura di un progetto;
    • generator-aspnet: generatore di yeoman per ASP.NET 5;
    • hottowel: un generatore di yeoman per applicazioni che usano AngularJS;
    • Express: un application framework per Node;
    • gulp: un task runner system;
    • mocha: un JavaScript test framework per Node;
    • bower: un client side package manager;
    • TypeScript: un framework tipizzato per estendere Javascript;
    • TypeScript definition manager: un repository di definition file da usare con Typescript.

    Al termine dell’installazione possiamo aprire l’editor per cominciare ad usarlo (figura 2):

    Figura 2 – Visual Studio Code

    L’IDE si presenta in questo modo: un menù principale (File, Edit…), un menù laterale con quattro pulsanti (Explore, Search, Git, Debug), al centro l’area di editing (in cui si possono affiancare fino a tre finestre) e in basso una barra di stato. Inoltre abbiamo una command palette che ci consente di eseguire comandi all’interno dell’ambiente in maniera rapida (figura 3).

    Figura 3 – La command palette

    Il primo aspetto interessante di Visual Studio Code riguarda il suo funzionamento: infatti si tratta di un editor file e folder based, che significa che basterà puntare ad una cartella o ad un file e non ad un file di progetto per iniziare a lavorare. Inoltre l’editor è in grado di riconoscere qualsiasi tecnologia supportata nel momento in cui viene aperta una cartella leggendo il suo contenuto. Per impostare invece una nuova cartella di lavoro, si può cliccare sul primo pulsante sul menù laterale (Explore), che apre una sezione che ci consente di visualizzare, aprire o aggiungere dei file presenti alla cartella selezionata (figura 4). In questa sezione, troviamo 2 sottosezioni, ovvero “Working Files”, dove troviamo i file aperti per la modifica, e “No Folder Loaded” (il cui nome cambierà a seconda della cartella in cui stiamo lavorando).

    Figura 4 – Scelta della cartella di lavoro

    Dopo aver cliccato su “Open folder”, siamo pronti per selezionare una cartella che rappresenterà il nostro workspace. Al suo interno possiamo aggiungere file usando i pulsanti accanto il nome della nostra cartella (figura 5):

    Figura 5 – I pulsanti di gestione dell’attuale workspace

    Supponendo di aver creato un file HTML, possiamo utilizzare il browser per visualizzarne il risultato (figura 6).

    Figura 6 – Un esempio di applicazione in Visual Studio Code

      Questa è per il momento solo una piccola introduzione su Visual Studio Code. Nei prossimi post entreremo in dettaglio sulle funzionalità di questo nuovo editor, come realizzazione di applicazioni ASP.NET e Node.js, supporto a Git, Debugging e configurazione.    

    Nuovo sprint in VSO

    Sono state messe online le modifiche del nuovo sprint per Visual Studio Online, e questa volta le novità sono veramente interessanti e tante.

    Per prima cosa è ora live la nuova infrastruttura di build, di cui avete avuto una preview con TFS 2015 RC. La build è stata completamente riscritta, e le novità sono veramente molte. Avevo già iniziato a parlare della nuova infrastruttura di build in un vecchio post, TFS2015 build vNext, ed ora che la preview è pubblica in VSO seguiranno altri post sull’argomento.

    Abbiamo inoltre una nuova funzionalità per fare opt-in nel Portfolio Management, è ora infatti possibile decidere se utilizzare o meno il livello Features, ed è stato anche aggiunto il livello Epics. Nei template sono stati aggiunti nuovi campi per un migliore supporto al metodo di sviluppo SAFe (Scaled Agile Framework).

    Choosing portfolio backlog levels

    Continuano infine le migliore alla Kanban Board. Con questo sprint potete editare in place, direttamente nella card, ogni campo che avete visualizzato; questo vi permette di gestire in maniera molto più veloce le varie card.

    Sono state aggiunte poi le Branch Policies su Git, ovvero la possibilità di assegnare una build alle pull requests. In questo modo ogni qualvolta viene fatta una pull request di una branch, viene verificata la build e se quest’ultima fallisce non viene data la possibilità di fare la merge dalla interfaccia utente. Inoltre è possibile specificare altre regole, come ad esempio un numero minimo di revisori minimo affinché la pull request possa essere accettata. Sempre sul fronte git è ora possibile accedere ai repository direttamente utilizzando oAuth.

    Gian Maria

    0  

    Lean Startup e Agile… attenzione a voler salvare capra e cavoli

    Come più volte ribadito, l’obiettivo di una Startup non è quello di sviluppare una soluzione funzionante (o almeno non è l’obiettivo primario su cui concentrare la propria attenzione e i propri sforzi), ma quello di capire se esistono clienti potenzialmente interessati alla nostra idea e se possiamo strutturare un business sostenibile intorno ad essa.

    Se consideriamo che il focus delle metodologie Agile è sullo “sviluppo di software funzionante”, così come direttamente richiamato sia nei Valori fondamentali: “Working software over comprehensive documentation” che nei Principi “Working software is the primary measure of progress”, dovremmo essere cauti nell’affermare che un approccio Agile è il modus operandi da adottare per la nostra Startup, che, lo ricordiamo, ha come indicatore primario del progresso la velocità di apprendimento e non la velocità di delivery della soluzione.

    Qualcuno però potrà obiettare: “va bene la learning velocity, ma se applico Scrum, ho dei riferimenti temporali time-boxed per verificare le mie assunzioni e, nel frattempo, mi ritrovo qualcosa di funzionante. In pratica salvo capra e cavoli!”. Ebbene, probabilmente la capra scapperà con i cavoli e voi vi ritroverete a cercare un altro lavoro ;-)

    capre e cavoli

    Per chiarire i differenti obiettivi dell’Agile e di un approccio scientifico alla creazione di una Startup, vediamo, in sintesi, un confronto diretto tra la metodologia Scrum e Lean Startup:

    Scrum Lean Startup
    • Il Product Owner crea e gestiste il Product Backlog con le feature e le user story relative al prodotto in funzione delle richieste del cliente;
    • Il Product Backlog viene priorizzato in funzione all’importanza della Storia dal punto di vista del cliente;
    • Viene creato lo Sprint Backlog dallo Scrum Team per l’iterazione seguente;
    • Ogni giorno viene aggiornato lo stato della nostra “Scrum Board”, vengono aggiornati gli strumenti di tracking (es: burndown) ed effettuato il Daily Meeting;
    • Durante lo sviluppo vengono utilizzate pratiche come test-driven development, automated acceptance test e continuous integration;
    • Allo scadere dello Sprint, quello che è fatto è fatto: nella Sprint Review viene mostrato al cliente quanto realizzato e vengono recepiti i feedback, mentre nella Sprint Retrospective, il Team ragiona su come lavora insieme e su come migliorarsi. Ricordiamo che “conoscere il processo” non è la stessa cosa di “implementarlo bene”.
    • Il tutto viene ripetuto in funzione dei tempi/costi di riferimento.
    • Identificare le ipotesi e le assunzioni alla base della nostra strategia;
    • Implementare il nostro Minimum Viable Product per testare la strategia scelta;
    • Sottoporre l’MVP ai nostri potenziali clienti/utenti e recepire quanti più feedback possibile;
    • Analizzare i risultati, riflettere su di essi e decidere se Perseverare o effettuare Pivot;
    • Fissare un nuovo obiettivo e ripetere il tutto.

    Come si vede, al di là alcune similitudini come quella di “velocizzare” il tutto quanto più possibile, gli obiettivi sono fortemente diversi: nel caso di Scrum, quindi, creo una soluzione/prodotto funzionante, avendo alle spalle un business definito e degli obiettivi di mercato consolidati. Nel caso della Startup, dopo aver chiarito la Vision, l’obiettivo valutare quanto prima la propria strategia, di business e di prodotto, e decidere cosa fare. Probabilmente ci affideremo più volte ad un pretotype prima di cominciare a realizzare un MVP.

    scrum process

    Agile Scrum process

    csm mm1 Lean Startup Poster

    Lean Startup build-measure-learn

    La fase costituente della Startup si pone, temporalmente, in una fase di pre-sviluppo, almeno quando ci si trova nella “Search phase” della Customer Development, in cui è fortemente sconsigliata l’adozione di una metodologia Agile che, paradossalmente, rallenterebbe il ciclo di apprendimento, legandolo ad un’iterazione time-boxed cadenzato. Certo, non tutte le metodologie Agili sono time-boxed, ma tutte sono iterative ed incrementali, cosa che stona con il concetto di pivot e con la possibilità di cambiare strategia quando necessario, ovvero “il prima possibile” se ci si accorge di essere sulla strada sbagliata.

    customer development pretotype agile

    Quando si passa, invece, dalla “Search Phase” alla “Execution Phase”, le metodologie Agili hanno una estrema rilevanza, poiché la Startup si appresta a consolidare il proprio business, trasformandosi in un’azienda e proponendo soluzioni/prodotti di qualità che assumono via via una centralità crescente, visto che il focus si sposta dalla learning velocity alla delivery velocity.

    Quello che è estremamente interessante è che applicando una diversa chiave di lettura al Manifesto Agile, è possibile vederlo alla base anche delle specifiche esigenze della “Search Phase”:

    • È fondamentale lavorare in sinergia in modo collaborativo ed efficace;
    • Dobbiamo essere capaci di sviluppare velocemente le nostre idee, indipendentemente dal fatto che siano declinate in un pretotype o in un prodotto, in modo da apprendere e verdicare la strategia;
    • L’apprendimento deve essere effettuato direttamente con i nostri potenziali clienti, con chi comprerà e utilizzerà il prodotto;
    • È necessario riflettere spesso su quanto appreso e rivedere la nostra idea e la nostra strategia, nonché il modo di lavorare, in funzione di ciò.

    Teniamo sempre presente che l’obiettivo finale è quello di fare business e qui la massima di David Hussman cade a pennello:

    “The difference between learning and failure is how much money you spend to do it.”

    Limitare la memoria massima di SQL Server in TFS

    ho già bloggato in passato sulla necessità di limitare il consumo di memoria di SQL Server nelle installazioni single server di TFS, al fine di evitare che SQL utilizzi tutta la RAM disponibile, rallentando fino talvolta a bloccare le altre parti di TFS (app tier). In questo modo il vostro sistema dovrebbe essere al sicuro da eventuali rallentamenti o blocchi dovuti all’eccessivo consumo di RAM di Sql Server.

    Se siete interessati a capire come ottenere il massimo dal vostro TFS, sicuramente questo post è quello che fa per voi.

    Vorrei però far notare che in generale, anche in installazioni dove SQL Server è su macchina dedicata, è sempre buona norma limitare il massimo uso di RAM di SQL Server, altrimenti si corre il rischio che SQL lasci senza risorse il sistema operativo ed anche altri servizi accessori.

    Se siete interessati all’argomento potete leggere il seguente articolo: How much memory does my Sql Server actually need. In generale, per quanto riguarda TFS, Grant Holliday ci da una formula empirica da utilizzare

    Riservare: 1 GB di RAM per il Sistema Operativo, 1 GB per ogni 4 GB di RAM installati nel range 4–16 GB, poi 1 GB per ogni 8 GB RAM installata sopra i 16 GB

    Questo significa che se il vostro SQL Server è installato in una macchina con 32 GB di RAM, si deve limitare la memoria usabile da Sql Server ad un valore di 25 GB.

    Il limitare la memoria diventa importante soprattutto durante gli aggiornamenti che richiedono cambiamenti di schema ragguardevoli, come ad esempio il passare dal 2013 al 2015.

    Ricordate pertanto di monitorare le performance del vostro Data Layer di TFS, in modo da massimizzare le performances ottenibili dal vostro hardware.

    Gian Maria.

    0  

    Integrazione tra PowerBI e VSO

    Durante Build 2015 sono state molte le novità che Microsoft ha annunciato relative alla famiglia di VSALM, prima tra tutte la disponibilità delle versioni RC di Visual Studio e Team Foundation Server.

    Tutte le novità verranno piano piano descritte in una serie di post e la prima di cui voglio parlare è l’integrazione tra VSO e Power BI, che andrà a coprire una delle aree scoperte di VSO rispetto ad un TFS On-Premises, la reportistica. Di base è ora possibile utilizzare Visual Studio Online come sorgente dati per Power BI

    image

    Una volta selezionato è sufficiente specificare il proprio account VSO, il Team Project che si vuole collegare (* per tutti i progetti), abilitare l’autenticazione oAuth2 e PowerBi è ora in grado di andare a “recuperare” i dati dal vostro account.

    Una volta che i dati sono stati importati è possibile iniziare a creare report utilizzando tutte le potenzialità offerte da PowerBI. Anche se non siete esperti di PowerBI, come me, di base l’integrazione fornisce già una dashboard con una serie di report pre-confezionati da consultare, che sono quindi disponibili senza dover effettuare nessun click o configurazione aggiuntiva.

    Appena i dati sono importati, la dashboard inizia a popolarsi con alcuni grafici base.

    image

    In questo caso potete vedere alcune metriche riguardanti il controllo di codice sorgente. Ogni grafico e tile può essere cliccata per entrare a visualizzare il dettaglio.

    image

    In questo caso ad esempio si può vedere il dettaglio relativo ai commit effettuati. Chiaramente è possibile creare qualsiasi tipologia di report si voglia, partendo dai dati importanti per creare il grafico desiderato.

    image

    In questa prima preview i dati sono presenti solamente per il codice ed in futuro verranno aggiunti grafici e metriche riguardanti tutte le altre aree di VSO.

    Gian Maria Ricci

    0  

    Lean Startup, Crossing the Charm

    Lean Startup ha un focus molto forte sulla Demand Creation, ovvero sulla necessità di attrarre un numero di clienti tale da garantire la sostenibilità al proprio business. Abbiamo parlando del Get, Keep and Grow funnel di Steve Blank, ma esiste un aspetto fondamentale che non abbiamo approfondito, ovvero la corretta segmentazione degli utenti, cosa che consente di fare una serie di previsioni sulle reazioni al nostro prodotto/servizio e scegliere la strategia di crescita.

    Come abbiamo spesso sottolineato nei vari post, esiste sempre una domanda fondamentale, all’apparenza banale, a cui rispondere e l’analisi del comportamento degli utenti non fa eccezione: “A chi si rivolge il nostro prodotto / servizio?”.

    La risposta più rapida che si può dare è “a tutti”, ma, come si può ben immaginare, è anche la più superficiale e sbagliata, tanto da portare al fallimento di brillanti idee perché si tenta di aggredire il mercato mainstream (quello di massa) esattamente come si fa con quello early stream, composto dagli early adopter e dagli innovatori.

    Occorre quindi avere una visione più profonda dei possibili utenti andando a sfruttare la segmentazione proposta in “Crossing the Chasm” da Geoffrey Moore, fondamentalmente schematizzata dalla figura seguente:

    charm

    Crossing the Chasm

    Come si vede dall’immagine, Moore identifica 5 gruppi di utenti:

    • Innovators (Technology enthusiasts), sono gli utenti che amano l’innovazione e che sono disposti a tutto pur di utilizzare una nuova tecnologia appena è disponibile, anche se ancora in fase di sviluppo. Si pensi ad esempio a quanti hanno scalpitato (e pagato) per provare i Google Glass in anteprima. Tipicamente essi rappresentano il 2,5% del mercato;
    • Early Adopters (Visionaries), sono coloro che vedono nella nuova tecnologia un’opportunità per ottenere un vantaggio competitivo, e sono disposti a collaborare e fornire feedback per renderla matura. Tipicamente rappresentano il 13,5% del mercato;
    • Early Majority (Pragmatist), si tratta di utenti pragmatici che decidono di utilizzare la nuova tecnologia laddove essa sia sufficientemente stabile e abbia il relativo supporto, sia del produttore che da parte del mercato stesso. Questi utenti cercano in tutti i modi di evitare i rischi e rappresentano un’importante fetta del mercato pari a circa il 34%;
    • Late Majority (Conservative), sono gli utenti che non amano cambiare le proprie abitudini e sono poco inclini alle nuove tecnologie, adottandole solo quando sono assimilabili ad una commodity. Rappresentano circa il 34% del mercato;
    • Laggards (Skeptics), sono gli utenti completamente avversi alle nuove tecnologie e che cercano, addirittura, di bloccarne la diffusione. La loro percentuale si attesta intono al 16%.

    Nonostante Moore utilizzi la distribuzione per rappresentare l’adozione di una nuova tecnologia sul mercato, è possibile astrarla al fine di rappresentare le tendenze di adozione di un nuovo prodotto o di una nuova soluzione innovativa:

    charm product

    Product/Solution Adoption

    In quest’ottica possiamo sovrapporre le due fasi del Customer Development di Blank con l’analisi di Moore:

    customer development chasm

    Customer Development & Chasm

    Esistono quindi due tipologie di mercato ben distinte attraverso cui il prodotto fluisce e con cui doversi confrontare: l’Early Market e il Mainstream Market, interessati da regole, strategie e piani estremamente differenti. Nel primo, gli utilizzatori vogliono “cose nuove” costi quel che costi, nel secondo vogliono prodotti e/o soluzioni complete e convenienti.

    Non è raro che una Startup “pretenda” di entrare nel mainstream market con le stesse regole del gioco dell’early market, finendo per “cadere nel dirupo” (fall in the chasm) e vanificando quanto di buono fatto in precedenza: si pensi, ad esempio, alla necessità di avere un supporto di primo livello nel mercato mainstream, cosa probabilmente poco utile e dispendiosa nell’early market.

    A questo punto il problema è come “saltare il dirupo” dotandosi degli strumenti giusti per superarlo. Chiaramente non esistono delle soluzioni assolute, ma è possibile affidarsi a delle best practice che ci consentono di affrontare al meglio la sfida:

    • Concentrarsi su una nicchia di mercato: meglio tentare di dominare una nicchia di mercato che tentare di conquistare tutti (almeno inizialmente), senza averne la forza e le capacità. Inoltre, se esistono competitor già affermati è probabile che non si è in grado di sfidarli, se non, appunto, proponendo una soluzione con caratteristiche specificamente pensate per un sottoinsieme degli utenti;
    • Chiarire quali sono i benefici della propria soluzione: è fondamentale che i clienti a cui miriamo comprendano il Valore della nostra soluzione e come essa possa aiutarli a migliorare le proprie attività. Inutile dilungarsi in un mero elenco di funzionalità, l’acronimo magico è UVP, Unique Value Proposition: Per [clienti] che [specificare il problema], il [nome soluzione/prodotto] offre la soluzione;
    • Sfruttare i casi di studio e i testimoni particolarmente influenti: grazie ai casi di studio è possibile dimostrare sul campo la validità della propria offerta. Inoltre, l’adozione del prodotto da parte di testimoni particolarmente influenti nel settore (es: Facebook per i social media), ne rafforza l’immagine, mostrando come essa abbia risolto i loro problemi e quanto i testimoni siano soddisfatti;
    • Permission Market: si tratta di instaurare un rapporto di fiducia con i propri clienti e, implicitamente o esplicitamente, ottenere l’autorizzazione a fornire informazioni e campagne di marketing inerenti il prodotto. Uno dei modi più efficaci di perseguire questo approccio è tramite l’Email Marketing, fornendo informazioni ai propri clienti tramite email solo dopo essere stati autorizzati a farlo;
    • Social Media: il contatto diretto con i propri clienti è fondamentale, facendoli sentire “coccolati” e raccogliendo feedback spontanei che sono di vitale importanza per il prosieguo del business.

    Come si può intuire si tratta di una serie di attività da calare nel contesto specifico ma che consentono di avere un “punto di appiglio” (point of attack ) nel mainstream market.

    Le novità di Build per VSALM

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

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

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

    Gian Maria.

    Agile Planning… and Pre-planning (grooming)

    Nel post precedente abbiamo inquadrato la tematica legata all’Agile Planning, descrivendo l’Agile Planning Onion e i vari momenti e livelli a cui le varie attività vengono svolte.

    Come visto, a livello di Product Planning vengono definite le funzionalità dello specifico prodotto, affidandone la governance ad un Product Owner (PO) e creando il ben noto Product Backlog.

    grooming

    Product Backlog

    Questo artefatto è sotto l’esplicita ed univoca governance del PO, ed è, come tutti gli artefatti Agili, soggetto a continui aggiustamenti ed allineamenti. Proprio in tale ottica, lo stesso co-autore di Scrum, Ken Schwaber, ha definito fondamentale l’attività di Grooming, nonostante essa non sia direttamente contemplata nella metodologia, suggerendo di dedicarvi non più del 5% del tempo di un’iterazione (4h per 2settimane) e assimilandola, nella forma e nei modi, al Daily Meeting.

    Il Grooming è un’attività di pre-planning in quanto consente di preparare al meglio il Product Backlog in vista dell’inizio del prossimo Sprint, basandosi su quanto emerso durante l’iterazione corrente.
    A questo punto una domanda dovrebbe sorgere spontanea: ma perché non unirlo allo Sprint Planning? La domanda è legittima, ma lo Sprint Planning ha una caratterizzazione molto forte che prevede l’individuazione degli obiettivi da raggiungere (Goal), la scelta di cosa realizzare e la definizione di massima di come realizzarlo. Quindi non vi è spazio per l’attività di Grooming che potrebbe essere anche di durata equivalente allo Sprint Planning stesso. In generale, lo Scrum Team si aspetta che, all’atto di avvio dello Sprint Planning si abbia:

    • Un Product Backlog priorizzato in funzione delle esigenze dettate dal Product Owner;
    • Una serie di User Story pronte ad essere inserite nel prossimo Sprint Backlog;
    • La definizione dei Criteri di Accettazione per le User Story stesse.

    E’ evidente, quindi, che bisogna trovare un momento diverso per effettuare il grooming (o pre-planning che si voglia). In base all’esperienza diretta, non si tratta di un solo momento ma è opportuno dividere il grooming in due sessioni pre e post Sprint Review, andando a focalizzare l’attività, separatamente, su due aspetti specifici:

    1. [Session 1] Rivedere il Product Backlog in funzione di quanto emerso durante lo Sprint;
    2. [Session 2] Rivedere il Product Backlog in funzione di quanto emerso durante la retrospettiva.

     

    grooming and review

    Grooming and Sprint Review

    Nella Session 1 (2h/2sett) è molto probabile che si parlerà prevalentemente dei problemi di natura tecnica annessi alle User Story sviluppate o a quelle non completate, andando così ad effettuare un audit del Product Backlog Risk related. Dualmente, nella Session 2 (2h/2sett) il focus sarà sulla review funzionale di quanto realizzato, basato essenzialmente sui feedback dei (key) stakeholders e quindi Feedback Related.

    Entrambe le sessioni sono appannaggio dello Scrum Team al completo (quindi: Product Owner, Scrum Master e Development Team) allo scopo di condividere il know-how relativo al prodotto, puntando ad ottenere una visione condivisa delle singole User Story, effettuando la stima del relativo effort, evidenziandone gli elementi critici e le possibili soluzioni agli impedimenti riscontrati. Non da ultimo, il grooming è il momento in cui condividere quelli che sono gli Acceptance Criteria e discutere del loro peso all’interno del processo di sviluppo, valutando quali sono strettamente necessari e quali possono essere eventualmente deferiti.