Associare il proprio Microsoft Account con l’account aziendale per condividere i benefici dell’abbonamento MSDN su Visual Studio Online

In un precedente post avevo parlato del funzionamento del piano Basic gratuito di Visual Studio Online e della possibilità di superare il numero di 5 utenti a patto che gli eccedenti siano in possesso di un abbonamento MSDN.

Con l’attuale possibilità di utilizzare Visual Studio Online sia con il proprio Microsoft Account che con l’account aziendale, per qualcuno si potrebbe porre il problema di riuscire a condividere i benefici dell’abbonamento su entrambi gli account, potendo quindi partecipare sia a progetti aziendali che extra-aziendali senza essere in entrambi i casi contati come utenti Basic.

Fortunatamente il problema è facilmente risolvibile associando i due account dalla propria sottoscrizione MSDN.

Apriamo quindi il nostro browser preferito e navighiamo su http://msdn.microsoft.com accedendo se necessario con il nostro Microsoft Account. Selezioniamo quindi in alto a destra il link Abbonamenti MSDN.

Nella sezione Visual Studio Online selezioniamo il link Collegamento all’account aziendale.

Nel dialog box Link to your Organizational Account impostiamo il nostro Account aziendale e clicchiamo sul pulsante Collega.

I due account risultano ora collegati (collegamento che è sempre possibile modificare o rimuovere utilizzando i link opportuni) ed è quindi possibile utilizzare i privilegi della propria sottoscrizione MSDN su entrambi.

Happy coding!

Scrum and TFS: cookbook

Nel corso di questi mesi abbiamo parlato dell’ALM in chiave Agile, evidenziando framework, approcci, best practice, strumenti e attività pratiche.

Inauguriamo, ora, una serie di post che hanno l’obiettivo di fornire una “soluzione tipo” per utilizzare Scrum e TFS (Team Foundation Server / Visual Studio Online) per la gestione di un progetto di media complessità. Prima di iniziare è, però, utile fare una precisazione: non si tratta di una soluzione “chiavi in mano” ma di un case-study che si può analizzare e che va adattato al proprio contesto. Inoltre la scelta di Scrum e TFS è dettata dalla volontà di abbracciare il framework Agile più diffuso e il miglior software di supporto all’ALM attualmente disponibile (fonte Gartner’s Magic Quadrant).

scrum tfs market adoptions 2013

Scrum e TFS, ALM leader

Inoltre, anche se potrebbe sembrare ripetitivo, accenneremo ai fondamenti di entrambi, evitando al lettore di “saltare” sul web per cercare informazioni base relative.

Allora… cominciamo!!

 

Pt.1, ALM: Scrum + TFS ed oltre

La complessità del software ha raggiunto nell’ultimo decennio un livello tale da considerare oggi la sua produzione una delle attività più onerose e difficili da realizzare.

Riferendosi al framework Cynefin [post relativo], un sistema è definito “complesso” quando non può essere modellato secondo un approccio lineare (matematicamente secondo equazioni lineari) perché il funzionamento olistico è più della somma del funzionamento delle singole parti, dipendendo anche dalla sua evoluzione/storia.

Questo ragionamento si applica all’intero ciclo di vita del prodotto, richiedendo la definizione di una strategia complessiva e di tattiche specifiche che si applicano alle varie fasi di gestione della vita di un software, dalla progettazione allo sviluppo, fino ad arrivare alla sua dismissione: Application Lifecycle Management, appunto.

Volendo riportare una buona definizione di cos’è l’ALM (ne esistono diverse, con focus differenziato sui vari aspetti), possiamo affidarci a Wikipedia:

“Application Lifecycle Management (ALM) is a continuous processof managing the life of an application through governance, development and maintenance. ALM is themarriage of business management to software engineering made possible by tools that facilitate andi ntegrate requirements management, architecture, coding, testing, tracking, and release management.”

Ma qual è il “core” dell’ALM? Soddisfare le esigenze del cliente (stakeholder), fornendo gli strumenti e le pratiche utili a catturare i feedback e a riorganizzare le attività in funzione della loro priorità. E qui il connubio con l’Agile è assolutamente evidente e “naturale”.

alm process

Application Lifecycle Management

In particolare, tra le diverse metodologie e i diversi framework Agile adottati, Scrum si è imposto nell’ultimo decennio come riferimento per un approccio moderno alla gestione dello sviluppo del software.

scrum process

Scrum Process

Il successo è dovuto ad un fattore principale: Scrum funziona ed è in grado di adattarsi a contesti fortemente eterogenei. Questo grazie al fatto che la metodologia creata da Ken Schwaber e Jeff Sutherland definisce una serie di ruoli, artefatti e momenti di riflessione/analisi, lasciando “libero” il Team di applicarli al proprio contesto. Attenzione: ciò non vuol dire che vige l’anarchia perché Scrum è difficile da implementare correttamente e va applicato nella sua interezza, altrimenti non si sta utilizzando Scrum! Quindi, niente “Scrum… but”! [si veda: Call it as you want, but don’t call it Scrum if it’s not!].
Possiamo descrivere, sinteticamente, l’applicazione dello Scrum process come segue:

Il {Product Owner (PO)}, dopo essersi confronta con gli stakeholder, definisce e priorizza le attività in quello che viene chiamato {Product Backlog}. A questo punto, lo {Scrum Master (SM)} riunisce il Team (compreso il PO) e, insieme ad esso, crea lo {Sprint Backlog} selezionando le attività da sviluppare nella successiva Iterazione {Sprint}. Prima di fare ciò, però, il Team ha definito il significato di “DONE”, ovvero quando una attività si può definire terminata (sviluppo, testing, documentazione, ecc..). Per ogni attività vengono definiti task unitari di lavoro, ne viene stimato il tempo di sviluppo in ore e, assolutamente fondamentale, i relativi criteri di accettazione.

Terminato lo {Sprint Planning}, lo Sprint (1sett. – 1mese) parte e i task individuati cominciano ad essere sviluppati. Giornalmente, prima di iniziare le attività, il Team tiene un meeting di 15minuti chiamato {Daily Scrum} in cui ci si confronta su cosa è stato fatto, cosa si farà nell’immediato e quali sono gli eventuali impedimenti.

Solo le attività che rispecchiano in pieno la definizione di “DONE” sono considerate terminate e, una volta raggiunta la fine dello Sprint, si procedete con uno {Sprint Review} in cui si mostra quanto realizzato al PO e agli stakeholder e uno {Sprint Retrospective} che consente al Team di analizzare la propria organizzazione al fine di migliorarla e migliorarsi.

La gestione di tutte le varie fasi può essere fatta senza l’ausilio di alcun supporto digitale, sfruttando, ad esempio, i classici post-it, ma ciò diventa poco pratico se si è in un contesto medio-grande con una struttura eventualmente delocalizzata in varie aree geografiche. Inoltre diventa difficile effettuare attività manuali di data-mining e associare le attività/task a quanto realmente sviluppato, per non parlare di tracciare agevolmente i feedback degli stakeholder e altre operazioni annesse.

Per questo, e non solo, uno strumento digitale di supporto all’ALM è sicuramente di estremo aiuto, soprattutto se flessibile ed integrato con le tecnologie di sviluppo stesse, esattamente come nel caso di TFS.

 

tfs-archi

Team Foundation Server ecosystems

Evitando di entrare negli aspetti di gestione del codice, della relativa integrazione con le piattaforme di sviluppo Microsoft (.Net in primis) e degli strumenti di Continuous Integration, due elementi rendono TFS particolarmente attraente e flessibile: l’indipendenza dalla metodologia di gestione adottata e la sua estendibilità. Il primo elemento si ottiene grazie ai Process Template, ovvero un “pacchetto” che definisce gli elementi caratterizzanti la metodologia scelta (es per Scrum: workitem, bug, impediment, ecc.) e le loro caratteristiche. E’ possibile definire un Process Template custom e continuare a utilizzare, in accordo con esso, tutti gli strumenti di TFS, senza dover modificare praticamente nulla nella piattaforma di supporto. L’altro punto di forza, come detto, è l’estendibilità, che consente di estendere TFS ed interrogarlo direttamente dai propri servizi/strumenti, sfruttando, ad esempio, le Team Foundation Server OData API.

Il nostro viaggio è solo all’inizio, nel prossimo post vedremo come creare un nuovo Scrum Project in TFS e gestire il Product Backlog, in accordo con l’esecuzione dello Sprint Planning.

Connettere il proprio account VSO al nuovo portale Azure

Il nuovo portale azure, http://portal.azure.com permette anche la gestione del proprio account di Visual Studio Online, ma fino al precedente deploy, era possibile gestire solamente i nuovi account creati dal nuovo portale. Da due aggiornamenti fa è invece possibile ora connettere i propri account esistenti, ma è necessario fare attenzione ad alcuni importanti fattori.

Connettere il proprio account è una operazione molto semplice.

Il primo passo è agganciare l’account VSO esistente al vostro account azure dal portale standard http://manage.windowsazure.com

image

Una volta connesso il proprio account VSO al proprio account di Azure, la situazione in cui vi trovate è probabilmente questa.

*) Il vostro account VSO non appare ancora nel nuovo portale Azure
*) Se accedete all’account VSO e navigate su un ulteriore account VSO creato in precedenza dal nuovo portale avrete un errore 401 di autenticazione e dovrete effettuare di nuovo un login (con stessa username e password).

Questo accade perché gli account utilizzati dal nuovo portale appartengono alla Directory di Azure, e quindi anche se il vostro account è lo stesso come nome utente e password in realtà sono viste da Azure come due identità differenti.

Prima di connettere l’account VSO al portale azure, VSO richiede un Live ID, una volta che il vostro account sarà connesso, VSO richiederà che l’account sia invece un account della directory di azure a cui si è connessi (Evidenziato dalla freccia nella figura precedente). Questo fa si che i due account, anche se con stesso nome utente e password siano distinti, ma usando purtroppo lo stesso cookie per visualstudio.com, vi causerà la necessità di fare logout e login se passate da un account connesso ad una directory (Directory account) ad uno non connesso che richiede LiveId.

Se osservate la figura precedente, la freccia indica appunto che l’account che sto collegando ad Azure verrà messo nella Default Directory. Per completare la connessione è necessario, sempre dal vecchio portaoe http://manage.windowsazure.com, aprire la sezione degli account di VSO, selezionare l’account collegato e nel tab di configurazione richiedere il collegamento Directory desiderata.

L’operazione non è infatti automatica, ma va richiesta in maniera esplicita e necessita di un certo quantitativo di tempo per essere effettuata (anche qualche ora). Una volta connesso il vostro account dovrebbe apparire come mostrato nella figura sotto.

image

A questo punto potete collegarvi al vostro account, e scoprirete che la vostra foto del profilo e le impostazioni sono cambiate, perché a tutti gli effetti ora state accedendo con l’account legato alla directory e non piu con il Live Id

Questa situazione è ora visibile dal nuovo update di agosto, entrando infatti nel mio account connesso con Azure mi trovo una welcome page in cui, oltre ad avere listati tutti gli account di cui sono proprietario e quelli a cui ho accesso, mi viene esplicitamente mostrata l’identità che è attualmente attiva.

image

Come potete vedere ora io sono connesso alla mia Default Directory, questo perché ho effettuato l’accesso al mio account VSO connesso ad Azure ed alla mia directory. Ora se tento di accedere ad un account VSO che non è connesso a nessuna directory avrò questo risultato.

image

Se leggete il messaggio mi viene detto che l’account Alkampfer@nablasoft.com associato alla Default Directory non è autorizzato ad accedere all’account. Questo perché l’account VSO a cui mi sto connettendo non è connesso a nessuna directory Azure, e quindi si attende un Live Id. A questo punto posso fare semplicemente Sign Out e connettermi con le stesse credenziali ed in questo caso la mia identità sarà quella del Live Id e potrò accedere all’account.

IMPORTANTE: Tutti i precedenti utenti che sono connessi con i propri Live Id ora non potranno più accedere al vostro account VSO fino a che non verranno aggiunti alla default Directory dell’account Azure a cui VSO è collegato.

L’operazione appena effettuata infatti è la base per poter gestire gli account di VSO al di fuori del Live Id. In questo modo si può sincronizzare la propria Active Directory aziendale con Azure, garantendo quindi la sincronia degli account e potendo finalmente gestire gli accessi a Visual Studio Online senza essere forzati ad utilizzare il Live Id.

Purtroppo l’uso degli stessi cookie tende a rendere il processo un pochino complesso, perchè chi come me accede ad account connessi e non connessi tende a dover fare spesso login e logout. Il consiglio migliore che posso dare è questo

1) Usare due browser, uno con cui si accedono agli account connessi ad Azure ed uno in cui si usano quelli non connessi

2) usare la navigazione in incognito per l’account che si usa di meno.

Per chi è interessato all’argomento VSO, continuate a seguire il nostro sito, perché li team di Get Latest Version sta pianificando una serie di articoli sull’argomento.

Gian Maria.

0  

Aggiornamento di VSO agosto 18

Non si fermano gli aggiornamenti di VSO, ed il 18 agosto abbiamo avuto un ulteriore aggiornamento. La funzionalità piu interessante è la possibilità di avere nella home page del progetto una “welcome page” che non è altro che il rendering del file Readme.Md presente nella radice del source control del progetto. Come sintassi è stata usata la GFM ovvero la sintassi Markdown con le aggiunte di GitHub, molto conosciuta nell’ambiente open source.

Nel test hub è stata introdotta la possibilità di effettuare il tagging dei test case, fino ad ora non permessa direttamente dal test hub.

Buon VSO.

Gian Maria.

0  

Welcome SAFe 3.0

Il 25 luglio scorso Dean Leffingwell ha ufficialmente annuncia il rilascio della versione 3.0 dello Scaled Agile Framework.

Le novità sono davvero tante e, praticamente, l’intera impostazione viene fortemente rivista, sia negli elementi che nell’infrastruttura stessa, il tutto in ottica di rendere disponibile alle organizzazioni uno strumento che consenta di focalizzarsi sul Value Delivery, migliorando il coordinamento delle attività annesse a Value Stream particolarmente ampi.

Da una veloce occhiata della Big Picture si nota propria la strutturale riorganizzazione della nuova versione rispetto alla precedente (2.5):

safe 3.0

SAFe 3.0

safe

SAFe 2.5

Si evidenzia subito come il Program Level ed il Team Level si stiano sempre più avvicinando, quasi a fondersi tra di loro, con l’esplicito obiettivo di disegnare un’organizzazione più orizzontale e più efficiente.

Dalla Big Picture 3.0 si nota, anche, un Portfolio Level molto più definito, che abbraccia una o più ART per le Epiche di Business e quelle Architetturali, e che evidenzia una maggiore attenzione a quegli aspetti decisionali strategici che influenzano in maniera diretta tutta l’attività di creazione dei Value Stream.

Volendo fare una panoramica delle innovazioni più rilevanti, troviamo inoltre:

  • Esplicito inserimento dell’approccio Kanban (Portfolio Kanban Systems) per la gestione degli elementi del Portfolio Backlog;
  • Un esplicito focus sulla figura del Lean Agile Leader, con evidenza delle criticità, delle responsabilità e delle competenze annesse;
  • Una diretta dipendenza tra le decisioni strategiche (portfolio Backlog e Value Stream) e il budget disponibile, che non si limita alla semplice contabilità ma viene esteso ad ogni aspetto, come, per esempio, l’innovazione. SAFe 3.0 definisce il Lean-Agile Budgeting come strumento annesso;
  • Enfasi sul ruolo di Coordinamento dei vari Agile Release Train avviati a livello Portfolio per il raggiungimento degli obiettivi di Valore programmati;
  • Particolare attenzione all’aspetto del Delivery (Program Level) con l’introduzione del Release Object e dell’approccio del Delivery on Demand;
  • Code Quality esteso esplicitamente alle pratiche più comuni: Test-First, Continuous Integration e, forse meno scontata, Agile Architetture.

Questo è solo un estratto di quanto presentato con il nuovo framework e di quanto vedremo in diversi post successivi.

Gestire le dipendenze funzionali

Ok, abbiamo deciso di utilizzare DAD, SAFe, Scrum o la metodologia/framework Agile che più ci ha convinto e abbiamo creato il Program Backlog grazie all’intenso lavoro del Product Owner in accordo con il Team.

A questo punto partiamo con la prima iterazione di sviluppo e dopo alcune ore di lavoro (e alcuni task completati) ci accorgiamo che per completare il task attuale abbiamo bisogno che il nostro collega completi il suo. In perfetta ottica di knowledge sharing, parliamo con lui e scopriamo che anche il suo task è bloccato, in attesa che un terzo completi un ulteriore task di base.

user stories dependency

User Story Dependency

Siamo in stallo e stiamo sprecando tempo!

La situazione descritta è sicuramente capitata a tutti, nessuno escluso, e le cause possono essere segmentate in tre gruppi principali:

  • End-User driven, la causa è da ricercarsi nelle Feature richieste dai key-stakeholder. Immaginiamo che il nostro cliente voglia un sistema di e-commerce: non posso completare la feature “carrello” finché non creo anche la UI che mi permette di visualizzare e selezionare i prodotti;
  • Requirements decomposition, in questo caso la dipendenza è iniettata dal modo in cui un requisito di alto livello è splittato in più requisiti più semplici (approccio Top-down);
  • Technology driven, questo ultimo gruppo raccoglie le dipendente di tipo tecnologico, ovvero dettato da vincoli Architetturali, di Piattaforma, di Integrazione, ecc.. Tornando all’esempio precedente: non posso testare la funzionalità di acquisto finché non completo il data layer.

Le situazioni a cui si può andare incontro, come si può ben intuire, sono molteplici e di complessità differente, e quindi è necessario, in base al contesto, avere un approccio strutturato che consenta di abbattere tali situazioni.

I principali attori a cui è affidato il governo di tali situazioni sono: il Product Owner e l’Architect Owner. Il primo ha il massimo peso nel caso di condizioni di stallo End-User driven, il secondo nel caso di situazioni Technology drive. Il caso intermedio (Requirements decomposition) vede entrambi protagonisti, teoricamente, alla pari.

Ma come è possibile risolvere le dipendenze ed evidenziarne l’esistenza? Ebbene, la letteratura consiglia alcune possibili strategie:

  • Ri-priorizzare uno o più Work Item: in questo caso il Product Owner può decidere di riorganizzare la priorità di uno o più Work Item in modo da abbattere il rischio di stallo, bilanciando l’approccio Value-Driven con quello Risk-Driven. Molto lavoro, in questo caso, deve essere fatto dal Product Owner nei riguardi dei key-stakeholder per spiegare l’eventuale ritardo di feature ritenute prioritarie, a favore di un’ottimizzazione del tempo e dei costi di progetto;
  • Utilizza Mock o Stub: questo approccio è quello, probabilmente, più tecnico. Infatti i vari moduli vengono isolati e per ogni dipendenza viene creato un Mock che ne simula il comportamento. Per lo scopo possono essere utilizzate apposite librerie come, ad esempio, Microsoft Fakes Framework. Lo svantaggio è che non è possibile rilasciare quanto sviluppato perché comunque incompleto e non funzionante nel complesso;
  • Rivedere i requisiti relativi: in tal caso si opta per una segmentazione dei requisiti di una feature. Se una feature non può essere completata in una sua parte per colpa delle dipendenze (ad esempio non posso completare l’acquisto on-line con carta di credito ma solo tramite paypal), si rimuove temporaneamente l’elemento bloccante. In tal modo è possibile completare correttamente l’iterazione, ottenendo un prodotto finito, ma con alcune funzionalità rimandate (è chiaramente da valutare il Cost of Delay).

Qualunque sia la strategia applicata, resta indispensabile evidenziare le dipendenze, sia per procedere correttamente nello sviluppo, sia per le future attività di manutenzione. Come sempre, l’ideale è quello di scegliere un approccio il più semplice possibile: se il Team lavora a stretto contatto e nello stesso open-space è possibile tranquillamente utilizzare apposite Board fisiche con una specifica organizzazione dei task (Physical dependency map). Se si applica una politica di gestione tramite uno strumento digitale ALM, come TFS, possiamo sfruttarne le specifiche funzionalità. Restando sullo strumento Microsoft, il modo più immediato è quello di utilizzare la funzionalità di “linking” sui vari Work Item.

workitems link vsonline

Linking TFS/VS Online

Prima di concludere è doveroso aprire una parentesi su un aspetto volutamente trascurato fin ora: quanto descritto vale per un Program Backlog associato ad un singolo Team (in pratica un Team Backlog) ma può essere opportunamente esteso al lavoro congiunto di più Team. In tal caso abbiamo un Product Owner per ogni Team (coordinato da un Chief Product Owner) e possiamo avere uno o più Architect Owner (anche qui coordinati da un Chief Product Owner), che creano una sorta di “Regia” per la gestione delle dipendenza. In tal caso, inoltre, gli strumenti digitali di gestione ALM diventano un MUST, essendo la fisicità un mero ricordo.

Nuovo Deploy per Visual Studio Online

Ieri è stato effettuato un nuovo deploy per Visual Studio Online. In questo deploy le modifiche maggiori sono fatte relativemente all gestione degli Organizational Account, ovvero potere usare i vostri account di Active Directory invece del LiveId per connettersi a VSO. In realtà questa funzionalità era già presente, ma disponibile solamente in fase di creazione di un nuovo account VSO, ora è invece possibile effettuare la richiesta ed agganciare un account VSO esistente ad un proprio Organizational Account.

Un’altra importante modifica è la possibilità di visualizzare i propri account VSO esistenti nel portale di Azure Preview (http://portal.azure.com). Fino ad ora infatti nella preview del portale era possibile solamente visualizzare i nuovi account creati dal nuovo portale, ora invece è possibile anche visualizzare i precedenti account VSO legati al proprio account.

Altre modifiche minori riguardano il licensing e specificatamente di includere tutta la parte di Test web-based per gli utenti con una Advanced License. E’ anche ora possibile cancellare il proprio account direttamente dall’interfaccia web, senza dover chiamare il support service.

Per quanto riguarda invece modifiche alle funzionalità disponibili nel sito, sono finalmente arrivati i grafici con trend, che permettono di avere una visualizzazione dell’andamento nel tempo di alcuni valori dei vostri work items.

Happy TFS.

Comments Off  

Back to Value, Agile Portfolio Management

Più volte abbiamo parlato del Portfolio (level), mostrando come gestire uno specifico Backlog con TFS2013 in modo da splittare le attività si più Team. Soffermiamoci ora sul Portfolio in se, rispondendo alla domanda “Come creo e gestisco efficacemente un Agile Portfolio?”.

Ebbene, la creazione e la gestione dell’Agile Portfolio per la produzione del software è un’attività complessa (cynefin – complex quadrand) quanto la creazione del software stesso. L’approccio Agile (e Lean) ha reso definitivamente chiaro che molta della complessità è legata alle interazioni che si creano tra le varie persone coinvolte nel processo di produzione, e ciò si riflette anche nella gestione del Portfolio di riferimento.

In generale, il punto di partenza per la definizione di un Agile Portfolio è la Vision strategica aziendale, che contempla fattori come: trend di mercato a medio e lungo termine, obsolescenza tecnologica, opportunità di business, morfologia del mercato, ecc…

Questi aspetti sono l’essenza di uno degli elementi portati dell’Agile Portfolio, il Portfolio Planning.

agile portfolio

La definizione del Portfolio Planning è la linfa costituente dei 4 pilastri (four pillar) dell’Agile Portfolio:

  • Value Management, definisce puntualmente cosa rappresenta il “Valore” nella Vision corrente, cosa che si concretizza nel Value Stream più volte richiamato in SAFe;
  • Work Management, sono le azioni di gestione messe in atto per portare a compimento le azioni di perseguimento del Value Stream, ad esempio l’Agile Release Train;
  • Capacity Management, condensa le azioni di gestione di tutto ciò che riguarda le risorse disponibili per il raggiungimento degli obiettivi, prima tra tutte le professionalità coinvolte, fondamentali negli ambiti di produzione complessi;
  • Financial Management, definisce gli espetti finanziari complessivi, legando le fasi al rispetto del budget e agli obiettivi di revenue che si vogliono perseguire.

Ognuno dei quattro pilastri ingloba, in misura differente e con approccio differente, le attività di Risk Management che, chiaramente, assumono un significato diverso in base al contesto di riferimento.

Infine, ma solo per descrizione non certo per importanza, troviamo il Portfolio Performance che trasforma la Vision in azioni concrete nell’ambito dello sviluppo e del posizionamento sul mercato. Un esempio: se la Vision è quella di “lanciare un treno” (ART launch) che abbatte costantemente il time-to-market, questo si traduce in una chiara impostazioni anche nelle attività di sviluppo che potrebbero, ad esempio, seguire una logica Lean.

E’ tutto? Assolutamente no! Abbiamo dimenticato uno degli aspetti più importanti e onnipresenti nel mondo Agile/Lean: il feedback che fluisce a tutti i livelli per riallineare costantemente il Portfolio con la situazione contingente o, dualmente, spingere affinché quest’ultima si avvicini maggiormente alla strategia inerente la Vision.

Be SAFe!

Come cambia il licensing di VSO / TFS

La notizia che Brian Harry ha dato sul suo blog è di quelle decisamente importanti. Sebbene le notizie sulle nuove funzionalità introdotte in TFS / VSO siano quelle più interessanti per i tecnici e per chi usa tutti i giorni gli strumenti, probabilmente le novità sul licensing sono quelle che in realtà impattano molto di più l’uso di un servizio.

Nel post sopra linkato si parla del livello di accesso per gli Stakeholder di VSO, ovvero tutte le persone che sono interessate al progetto che si sta realizzando. Questa richiesta è tipica di chiunque adotta TFS / VSO, di che tipo di licenza necessito per far si che i miei clienti e gli Stakeholder in generale siano in grado di accedere al mio TFS per segnalare bug / feedback / PBI etc?

Attualmente per TFS on-premise si ha la possibilità di usare un livello chiamato “limited” che permette ad un utente il solo diritto di inserire Work Item e visualizzare solamente quelli da lui inseriti. In VSO purtroppo questo livello, usato normalmente on-premise per permettere agli stakeholder di segnalare bug e richieste di modifiche, non era ancora presente. Questo fa si che per ogni persona che volete abilitare per visualizzare e gestire i Work Item dovete avere un utente di livello Basic, una spesa che chiaramente limita fortemente il numero di stakeholder coinvolti.

Oggi Brian Harry invece annuncia che sta per arrivare un cambiamento di licenza per VSO che permetterà agli stakeholder di accedere gratis a VSO con la possibilità di:

  • Full read/write/create on all work items
  • Create, run and save (to “My Queries”) work item queries
  • View project and team home pages
  • Access to the backlog, including add and update (but no ability to reprioritize the work)
  • Ability to receive work item alerts

Chiaramente questo livello di accesso non permetterà di gestire codice, build, test e tutte le attività che sono attinenti al team, per i quali valgono i costi attuali.

L’aspetto interessante, è che questo livello di cambiamento di licenza sarà poi esteso anche al TFS on-premises, rendendo l’offerta di TFS sempre più allettante.

Gian Maria.

Comments Off  

Back to Value, draw the canvas!

Dopo aver presentato il Product Canvas ed avere mostrato, brevemente, come integrarlo con gli strumenti comune in ambito ALM Microsoft, non ci resta che passare alla parte più interessante: dipingere la tela!

SampleProductCanvas

Un Product Canvas “popolato” (Roman Pichler)

Il product Canvas è pensato per essere “esplorato” e “popolato” da sinistra verso destra e, quindi, la prima area che va riempita è quella relativa al “Target Group”, utilizzando l’approccio personas-oriented.

ProductCanvasSteps

Se si riflette un attimo su questa priorità, ci si rende conto che è assolutamente ovvia ed in linea con un approccio Agile/Lean alla creazione di soluzioni IT.

Il secondo passo è quello di riempire la “Big Picture”, descrivendo le Features del prodotto attraverso tutti gli elementi che riteniamo idonei a rappresentarne la Vision. Ben vengano, quindi, user-story, StoryBoard, disegni della UI, ecc. Sono, invece, del tutto banditi elementi specifici dell’attività di implementazione: non troveremo mai: “creare le interfacce di accesso al db”.

Infine, il terzo step, è quello di decide quale feature verrà sviluppata nella prossima iterazione di sviluppo, elencando le relative user-story ed evidenziando eventuali attività atte a esplorare specifiche soluzioni o a ridurre il rischio.

Attenzione però a non interpretare questi step come sequenziali in senso stretto. Dopo la prima formalizzazione (sequenziale), l’intero Product Canvas va incontro a continue review e aggiornamenti, dovuti al know-how di dominio, continuamente aumentato man mano che si procede con il progetto.

Ecco il punto: il Product Canvas è uno strumento di apprendimento che posa la sua essenza sul tanto amato pattern inspect-and-adapt.

ProductCanvasAndLearning3

Product Canvas come strumento di apprendimento (Roman Pichler)