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!

Kaizen, questo sconosciuto

kaizenIl termine Kaizen è estremamente diffuso nella cultura giapponese e rappresenta una vera e propria filosofia di vita che si basa su piccoli e continui miglioramenti. Applicato ad un contesto lavorativo, il Kaizen implica un vero e proprio processo di miglioramento continuo, improntato su piccoli passi progressivi che coinvolgono tutti i membri dell’organizzazione, dal management agli addetti alla produzione.

Tale processo è sotteso da due funzioni principali: maintenance (manutenzione) ed improvement (miglioramento), con obiettivi all’apparenza in contrapposizione che, però, rappresentano due facce della stessa medaglia. Far proprio il Kaizen comporta un corretto bilanciamento di tali funzioni al fine di ottenere il “buon cambiamento”: l’obiettivo della maintenance è quello di mantenere gli standard attuali (tecnologici, gestionali e operativi), mentre l’obiettivo dell’improvement è quello di migliorarli.

Il Kaizen è diventato negli anni una filosofia operativa, sia del mondo Lean sia del mondo Agile, dove viene applicato al prodotto, per far si di avere una ottimale corrispondenza tra quanto realizzato e quanto atteso dal cliente, e al processo di sviluppo. Entrambe queste attività sono tipiche dell’Iteration review e delle retrospettive: immaginiamo che in una retrospettiva ci si accorge che, nonostante gli sforzi, le user story non sono effettivamente in un corretto done-state poiché richiedono continuamente di essere riviste. Si può quindi intervenire, ad esempio, migliorando le tecniche di unit testing. Nella figura seguente, possiamo riassumere gli step che consento di applicare metodicamente il Kaizen alle nostre attività:

continuous improv

Kaizen step-by-step

Per riuscire ad applicare con successo il Kaizen, è necessario svuotare la propria mente da preconcetti e dalla tendenza di essere conservativi:

  • · Superare le proprie convinzioni sul come “sia giusto” fare le cose;
  • · Focalizzarsi sui possibili miglioramenti ottenibili dal nuovo approccio, e non sui problemi che possono verificarsi;
  • · Negare lo status-quo con forza, senza la tentazione di tornare indietro;
  • · Non cadere nella tentazione di ricercare sin da subito la perfezione;
  • · Correggere gli errori e risolvere i problemi solo quando essi si presentano;
  • · Utilizzare la 5 whys analysis per ricercare la radice dei problemi;
  • · Coinvolgere tutti gli stakeholder: 10 idee sono meglio di una;
  • · Non porre limiti alle possibilità di miglioramento.

Alcune novita sul licensing di VS 2015

Se andate sulla pagina dove viene fatta la comparazione di tutte le versioni di VS 2015, potrete notare alcuni fatti interessanti. Ad esempio si può notare che il Power Point Storyboarding, la Code Review ed il Task Suspend/Resume sono stati resi disponibili non solamente per la professional, ma addirittura per la versione Community.

image

Code Lens, altra feature molto interessante, è stata resa disponibile anche per la professional. Vi invito a dare una scorsa alla pagina in questione, perchè passare a VS2015 non vi porterà solamente le nuove funzionalità di questa versione, ma potrebbe portare nella vostra edition, funzionalità prima presenti solamente nella premium o nell’ultimate.

Happy VS.

Lean Startup, Cohort Analysis

Riprendiamo il nostro cammino alla scoperta di Lean Startup, addentrandoci in quelli che sono gli aspetti più profondi e delicati per il nostro “esperimento” e la “ricerca” del nostro business.

Come visto, il cuore di Lean Startup è il ciclo build-measure-learn, ovvero la Strategia che consente di raggiungere il Goal primario di Validate Learning e definire le Tattiche relative all’Innovation Accounting. Per quanto possa sembrare semplice procedere ripetitivamente con n-cicli build-measure-learn, è bene approfondire le varie tematiche sottese, soprattutto relativamente al “measure” e al “learn”, considerando che la parte di “build” può contare su pratiche rodate derivanti dal mondo Agile.

In particolare “misurare” i miglioramenti e gli obiettivi raggiunti è tutt’altro che semplice: cosa vado a misurare nella realtà? Come misuro tutto ciò?

Uno dei metodi su cui Lean Startup fa particolarmente leva è la Cohort Analysis, ben definita da Wikipedia:

A cohort study or panel study is a form of longitudinal study used in medicine, social science and ecology. It is one type of study design and should be compared with a cross-sectional study.

A cohort is a group of people who share a common characteristic or experience within a defined period (e.g., are born, leave school, lose their job, are exposed to a drug or a vaccine, etc.). Thus a group of people who were born on a day or in a particular period, say 1948, form a birth cohort. The comparison group may be the general population from which the cohort is drawn, or it may be another cohort of persons thought to have had little or no exposure to the substance under investigation, but otherwise similar. Alternatively, subgroups within the cohort may be compared with each other.

In soldoni, si tratta di un approccio particolarmente utile per misurare (o meglio tracciare) il comportamento degli utenti e il loro attaccamento al servizio (fidelity) nel tempo.

Vediamo in concreto come poter utilizzare la Cohort Analysis rifacendoci ad un caso reale proposto da Robert J.Moore, che la applica in modo diretto ai nuovi utenti di Twitter. I dati si riferiscono al 2009, ma sono sufficienti per lo scopo di questo post, e sono raggruppati in tre diversi diagrammi.

Nel primo, viene illustrato il comportamento degli utenti nell’arco di un semestre in funzione al loro mese di iscrizione, rappresentato dai diversi colori. Sull’asse delle ordinate viene riportata la percentuale di utenti che hanno effettuato almeno 1 azione per ognuno dei mesi di riferimento:

cohort twitter 1

Comportamento utenti iscrizione/mesi

Da questa rappresentazione possiamo estrarre già una quantità notevole di informazioni strategiche:

  • Dopo l’iscrizione (che per definizione è il 100% delle attività), si nota che dopo il primo mese gli utenti hanno una calo di utilizzo che va dal 50% al 75%. Successivamente l’uso tende a stabilizzarsi, il che permette di fare previsioni abbastanza attendibili sul numero di utenti medi realmente attivi;
  • Gli utenti iscritti più di recente sono quelli che utilizzano maggiormente il sistema (gennaio e aprile 2009). Questo dato può essere dovuto a diversi elementi (che noi non conosciamo, ma che sicuramente Twitter conosce):
    • rilascio nuove features;
    • pubblicità;
    • effetto virale;
    • ecc…

Se spostiamo a livello settimanale l’analisi, ragionando su cohort presi su base settimanale a loro volta, otteniamo il risultato della figura seguente:

cohort twitter 2

Cohort Analysis Weekly

Anche in questo casosi evidenzia un drop-off simile a quello visto precedentemente, ma si chiarisce che esso avviene principalmente nella prima settimana di iscrizione. La cosa interessante è che gli utenti più “anziani” (azzurri e gialli) hanno degli andamenti altalenanti rispetto agli altri utenti. Questo, probabilmente, indica che il loro attaccamento al servizio è dovuto più a un motore di crescita “jump start”, ovvero qualche azione specifica di Twitter che li ha convinti a ritornare, che a nuove funzionalità, che di base contemplerebbero un andamento crescente quanto meno lineare.

Vediamo, infine, una terza indagine che prende in analisi la frequenza di utilizzo (numero di tweet, in pratica) nell’arco dei mesi, basandoci sulla stessa scala mensile/attività e sugli stessi cohort di rifermento al primo diagramma:

cohort twitter 3

Tweets numbers

A dispetto dell’alto tasso di abbandono dopo il primo mese (vista in precedenza), il tasso di attività in esso è superiore o pari al 100% per tutti gli utenti, indipendentemente se poi continueranno o meno ad utilizzare la piattaforma.

Di nuovo, come visto nel diagramma 36, gli utenti appartenenti al “cohort” giallo sono gli unici iscritti nel 2007 (rilevati a gennaio 2008) ad avere un tasso di attività superiore a quello degli iscritti dopo. Questo elemento è fondamentale perché indica che tali utenti, caratterizzare più in profondità da Twitter, sono un po’ gli adopter più fedeli su cui far leva e sono un indicatore concreto/storico del successo delle iniziative dell’approccio fail-fail-win.

Perché è importante tutto ciò? Se ci fossimo limitati a conteggiare, ad esempio, il numero totale di iscritti e la loro attività, avremmo avuto un’indicazione di massima del rapporto iscritti/tweet. Questo ci avrebbe fatto perdere l’indicazione relativa al “cohort giallo” che, a dispetto del dropdown, rappresenta una fetta di utenti particolarmente “attiva” e rilevante per l’impatto delle nuove modifiche introdotte. Al contrario, invece, il “cohort arancione” può essere più indicativo delle azioni una-tantum, perché la loro attività mediamente è stabile, con punti in cui cala in modo lineare per poi riprendersi e riportarsi vicino al punto medio.

Tutto ciò consente alla startup di:

  • prendere opportune iniziative, generali e mirate: Innovation Accounting;
  • dare informazioni di dettaglio ai possibili investitori per strappare nuovi round di finanziamento.

Card Styling nella Kanban Board

Con l’ultimo aggiornamento di VSO è stato introdotto il “Card Styling” per le card della Kanban Board. Di base è un semplice motore di regole per cui, in base a criteri espressi sui campi dei work item, abbiamo la possibilità di colorare lo sfondo delle card a nostro piacimento.

Il limite attuale è che l’unico stile possibile che può essere applicato è lo sfondo, ma non è improbabile che in futuro si possano avere altri stili possibili. Vediamo quindi un possibile uso di questa funzionalità.

Si supponga di suddividere le card per “grandezza” usando il classico T-Shirt sizing, ovvero ogni card può avere la grandezza S/M/L/XL. Sulla base della grandezza delle card introduciamo alcuni semplici regole del tipo:

1) Solamente una card XL può essere presente nella board ad eccezione naturalmente della colonna Done e del backlog
2) Solamente una card L può essere presente in una specifica colonna della board
3) Se in una colonna è presente una card XL, in quella stessa colonna non può essere presente più di una card M
4) Se in una colonna è presente una card L in quella stessa colonna non possono essere presenti piu di 2 card M

Questo è un possibile esempio di semplici regole che ci permettono di gestire la variabilità in grandezza delle varie card. A questo punto è necessario però avere un immediato impatto visuale sulla board relativamente alla grandezza delle card. Per questo possiamo usare la nuova funzionalità di Styling.

image

Questo nuovo menù aprirà una finestra in cui potete inserire una serie di regole per decidere il colore di sfondo delle card. Ecco ad esempio le regole per colorare di rosso le card XL, in giallo quelle L e in blu quelle S

image

  • Come potete vedere una regola ha un nome, il colore di sfondo da usare, ed un editor che vi permette di inserire condizioni sui vari campi dei Work Item. In questo esempio ho usato i TAG per categorizzare le card. Se una card soddisfa più regole, verrà applicata la prima soddisfatta. Dalla finestra di gestione regole potete infatti con il drag & drop effettuare un riordinamento.

image

In questo modo è possibile avere un immediato colpo d’occhio sulla grandezza delle card su cui il nostro team sta lavorando.

Gian Maria.

Visual Studio Online update del 7 luglio

Il nuovo update, di cui potete trovare descrizione nel blog ufficiale introduce due importanti novità. Il primo è la possibilità di specificare delle regole per la Kanban Board, che permettono di colorare lo sfondo delle card in base a particolari condizioni. Tornerò successivamente in un post dedicato su alcuni usi pratici di questa funzionalità.

Sul fronte security invece, è stato introdotto il concetto di Personal Access Token, ovvero la possibilità di generare un token di autenticazione, con una durata predefinita, che permette l’accesso ad alcune porzioni di VSO. In questo modo, le applicazioni che hanno quel token, potranno agire a nome dell’utente fino a che il token risulta valido.

Infine è possibile aggiungere work item direttamente nel backlog dello sprint, non richiedendo quindi di aggiungere I work item nel backlog principale e poi usare drag and drop o editing massivo per assegnarli ad una specifica sprint.

Happy VSO.

0  

Software Quality Attributes in Agile with Visual Studio Online, pt.2

Technical User Story: scenario complesso

Continuiamo il nostro viaggio nel mondo delle Technical User Story (TUS), ovvero la rappresentazione dei constraints non funzionali, fondamentali per la realizzazione di una soluzione di qualità in linea con le aspettative dell’utente.

Nel precedente post ci si è concentrati sullo “scenario semplice”, ovvero sul caso in cui la TUS sia strettamente legata ad una singola User Story, diventandone un’Acceptance Criteria che ne condiziona lo sviluppo e il passaggio in “Done State” in modo stringente. Più comunemente, però, i constraints non funzionali sono cross-User Story, rappresentando un aspetto trasversale del sistema e ponendo tutta una serie di problemi, sia nella loro gestione sia “nel quando” diventa possibile considerare una User Story in “Done State”

nfr cross us

Cross User Story constraints

Nello scenario cross-User Story è fondamentale individuare uno scope più ampio da considerare per lo sviluppo delle TUS, che, quasi sicuramente, non possono essere “contenute” in una singola iterazione. Per supportare in modo ottimale tale attività, è opportuno dividere il “generico” constraint introdotto precedentemente in due tipologie ben delineate:

  • Rule: è un constraint che limita la libertà nella scelta del come sviluppare la soluzione. Si tratta di un vincolo difficilmente percepibile da parte dell’utente finale.
    • Simplicity, Maintainability, Testability, Portability, Extensibility, ecc…
  • Restriction: più che porre limiti, contribuisce a definire i livelli di qualità annessi all’esecuzione della soluzione, inquadrabili come “vincoli” architetturali. È evidente che tale aspetto è percepito in modo diretto dall’utente.
    • Correctness, Performance, Reliability, Scalability, Security, Usability, ecc…

Per esplicitare meglio le differenze tra le due tipologie di constraint, si considerino i seguenti scenari-tipo annessi alla Simplicity e alle Performance:

 

Scenario, Simplicity::Coding Convention (Role constraint)
Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Dev deve modificare la soluzione dopo diversi mesi dal suo completamento
Stimoli Lettura e comprensione del codice senza documentazione esterna
Artefatti Codice Sorgente (aka: Intera Soluzione)
Ambiente Sviluppo
Risposta Definizione di una “Coding Convention”
Misura delle Risposta ???????????

Tab.1: Simplicity

Scenario, Performance::Login Response Time (Restriction constraint)
Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Utente esterno chiede di utilizzare il sistema
Stimoli Richiesta di accesso alle funzionalità del sistema
Artefatti Log-in Module
Ambiente Erogazione
Risposta Il sistema deve espletare la procedura di autenticazione in non più di 2 sec. Se il tempo di log-in supera i 10sec. per più di 10 utenti, la funzione va messa in Suspend e va inviato un alert al gruppo di supporto.
Misura delle Risposta Utenti loggati nel range di 2 secondi, utenti loggati oltre i limite dei 2 sec.

Tab.2: Performance

La differenza sostanziale tra le due tipologie di constraint è ben leggibile nello Scenario annesso alla Simplicity (tab.1). In esso si evidenzia come sia estremamente difficile, se non impossibile, definire in modo univoco la “Misura della Risposta” e i possibili test per la verifica della “Risposta” del sistema, essendo lo “Stimolo” non meccanizzabile. Ciò porta all’impossibilità di asserire in modo sistematico che la User Story è completata e far evolvere il suo stato in “Done State”. Tale condizione di incertezza non persiste, invece, per lo scenario Performance (tab.2) che esplicita elementi misurabili e direttamente testabili.

Nonostante queste profonde differenze, da un punto di vista schematico, i constraint cross-User Story possono essere visti esattamente come quelli single-User Story, ovvero come vincoli al Dominio di riferimento funzionale.

nfr rule

Rule & Restriction Constraints

Cosa diversa è, invece, la loro rappresentazione e gestione all’interno di strumenti di ALM, e in particolare di Visual Studio Online.
Nel caso delle Rule, esse sono assimilabili a dei Global Work Item a cui vanno collegate le varie Feature da realizzare: sarebbe inutile legare le Rule ai singoli PBI (singole User Story), perché impattano l’intero ciclo di sviluppo della soluzione e devono essere viste come uno stimolo al continuo refactoring durante le iterazioni, in funzione del raggiungimento dell’optimo relativo.  È del tutto evidente, quindi, che una Rule Feature ha un ciclo di sviluppo assimilabile a quello della soluzione (Release, Increment, ecc…).

In VSO, non essendo ancora contemplata la possibilità di modificare il Process Template e creare specifici Work Item type, possiamo utilizzare un item di tipo Feature per definire una Rule Feature, caratterizzata da una specifica naming convention del tipo: RULE::Name e con la Value Area settata ad Architecture.

nfr feature rule

RULE Feature

Successivamente si potrà procederà a “linkare” direttamente come “reference” la singola Feature alla Rule Feature:

nfr feature rule linking

RULE PBI Linking

Nel caso delle Restriction, i work item di riferimento sono le User Story che in VSO sono genericamente rappresentate sotto forma di PBI. Anche qui, per ora, è necessario adattare un PBI generico con una specifica naming convention: Restriction::Name, dando vita ad un Restriction PBI con la Value Area sempre settata ad Architecture.

nfr pbi restriction

Restriction PBI

A questo punto i PBI vanno linkati, come per le Feature, alla Restriction PBI che le vincola nel loro sviluppo, come accade per lo scenario semplice descritto per il post precedente. Se è vero, però, che il PBI va completato nella singola iterazione, lo stesso non vale per la Restriction PBI che resterà “In Progress” finché tutte le User Story/PBI annesse saranno completate. Da ciò risulta fondamentale la granularità della definizione degli Scenari di qualità al fine di non avere Restriction PBI che durino l’intero ciclo di sviluppo, difficilmente giustificabili e tollerabili, a differenza delle Role Feature.

Operando con una naming convention di riferimento è possibile, inoltre, costruire delle query ad-hoc che consentono di tenere sempre evidenza di quelle che sono le Rule e le Restriction attive nel sistema, andando anche eventualmente a “pinnare” il risultato sulla home.

nfr restriction query

Simple Restriction query

nfr restriction pin

Simple Restriction query “pin”

Va puntualizzato che nel caso di Team Foundation Server, essendo possibile modificare il Process Template, è opportuno creare appositi Work Item in grado di rispecchiare in modo specifico le caratteristiche delle Rule e delle Restriction.

 

Stay tuned!

DotNetPodcast n°48 – DB & Source Control

Ho avuto di recente la possibilità di passare una piacevolissima serata con gli organizzatori di DotNetPodcast, Roberto Albano e Antonio Giglio, e con un amico MVP Visual Studio ALM, Felice Pescatore

Grazie alla disponibilità di Roberto e Antonio, abbiamo fatto un “salotto informatico”, nel tentativo di rendere interessante ed, allo stesso tempo, divertente l’ora passata insieme. Il tutto è partito come “intervista” ma poi ci siamo coinvolgere dall’argomento, più attuale che mai.
Nel podcast si è cercato di fondere quelli che sono i concetti fondamentali dell’agile con le pratiche di gestione del source control (e non solo) su database.
Ovviamente, siccome Felice ed io “parliamo POCO”, sono stati anche accennati topic non necessariamente legati al controllo del codice sorgente, come la gestione del team, le metriche per la risoluzione dei problemi di allineamento dei membri del team, ecc.
Vi consiglio vivamente di ascoltare il podcast qui. Personalmente, mi sono divertito tanto durante la serata e credo proprio che il risultato sia buono.
Stay Tuned! 

Software Quality Attributes in Agile with Visual Studio Online

Lo sviluppo di una soluzione software è finalizzato alla creazione di Valore per il cliente, e, più in generale, per tutti gli stakeholders collegati. Proprio il Valore è l’elemento portante su cui si basa l’intera azione di deploy del prodotto, guidandone le varie fasi di realizzazione e di supporto.

Le varie metodologie Agili ci portano ad “osservare” la nostra soluzione dal punto di vista funzionale, andando a creare un Product Backlog (PB) contenente Epic o User Story che rispondono alla forma: “As a USER… I Want… So…”, mettendo al centro del discorso l’utente finale e, appunto, la sua visione funzionale del sistema.

Questo approccio è assolutamente valido per rappresentare il Valore della soluzione in funzione alle aspettative del cliente, ma trova dei profondi limiti quando si vuole andare a rappresentare i requisiti qualitativi/non-funzionali (NFR) del sistema.

In un post specifico (NFR: come definire correttamente uno scenario) si è già affrontato l’argomento che riguarda una possibile definizione formale degli NFR attraverso Scenari composti da 6 elementi lineari:

  • Stimolo (Stimuls), ovvero l’evento che sollecita il sistema;
  • Source of Stimuls (Sorgente dello Stimolo), la sorgente da cui proviene lo stimolo;
  • Artefatto (Artifact), la parte del sistema sottoposta allo stimolo. Chiaramente può essere l’intero sistema;
  • Environment (Contesto), il contesto in cui si verifica lo stimolo;
  • Response (Risposta), come il sistema risponde allo stimolo;
  • Response Misure (Misura della Risposta), permette di valutare se la risposta del sistema è soddisfacente.

specify nfr 

Figure 1 – Quality Scenario

Messo che gli scenari siano stati definiti, ragionando in chiave Agile evitando un Big Design Up Front (BDUF), come è possibile rappresentarli correttamente all’interno del processo Agile utilizzato, ad esempio Scrum? come è possibile sfruttare Visual Studio Online (o TFS) per tenerne traccia e farli convivere con le User Story?

Per trattare correttamente la tematica, la discussione verrà improntata su “scenari semplici”, in cui il requisito non funzionale è legato esclusivamente solo ad una sola User Story, e su “scenari complessi”, in cui l’NFR è cross-User Story.

 

Technical User Story: scenario semplice

Come detto, le User Story sono direttamente legate agli aspetti funzionali:

            “Essendo un Operatore di Sportello, voglio potermi loggare in modo da assistere il cliente

Esse coinvolgono, idealmente, diversi aspetti tecnici del sistema che ci si approccia a realizzare, poggiandosi sull’Intentional Architecture di riferimento.

In Agile si è abituati a lavorare in funzione del cliente, ma spesso ciò viene portato all’estremo e la presenza di riferimenti di tipo tecnico vengono banditi dal Product Backlog. Ma se si guarda alla definizione stessa di Product Backlog:

“The agile product backlog in Scrum is a prioritized features list, containing short descriptions of all functionality desired in the product.”

si nota che non viene fatto nessun riferimento esplicito a User Story o a requisiti funzionali, ma ad una lista generica di funzionalità che si desidera avere nel prodotto. Un PB può quindi avere:

  • Features;
  • Bugs;>
  • Technical work;
  • nowledge acquisition;
  • ecc…

in pratica, il PB contiene tutto quello che il Product Owner, coadiuvato dal team, ritiene utile inserire per raggiungere l’obiettivo in funzione del cliente. È bene, quindi, non confondere il Product Backlog con “il documento dei requisisti”… sono due cose completamente differenti!

Nessun problema, quindi, nell’avere delle Technical User Story (TUS) che rappresentino i requisiti non funzionali della soluzione in essere. Inoltre, non vi è alcun vincolo relativamente alla forma che essi debbano avere. In generale è più facile pensare alle TUS se si ha una visione complessiva della soluzione che si sta realizzando, discutendone durante un Story Brainstorming Workshop (rif. Mike Cohn) o un Release Planning, che consentono di andare al di là della singola iterazione di sviluppo.

Le TUS possono essere di vario tipo:

  • Quality Requirements: sono dedicate agli aspetti qualitativi/non funzionali della soluzione;
  • Product Infrastructure: di supporto allo sviluppo dei requisiti funzionali. Si pensi ad esempio all’individuazione di una libreria per la compressione dei dati, che va provata, testata ed integrata nella soluzione;
  • Team Infrastructure: si tratta di sperimentare strumenti che sono di supporto alle attività del team. Si pensi ad una nuova piattaforma ALM;
  • Refactoring: di supporto alle attività di refactoring. Da non intendersi solo relativamente al codice, ma anche all’Intentional Architecture, al Desing, ecc;
  • Bug Fixing: di supporto alla risoluzione di bug o di malfunzionamenti olistici;
  • Spikes: sono una particolare categoria che evidenzia la necessità di apprendere know-how relativamente a uno qualsiasi degli aspetti della soluzione, sperimentando le ipotesi sul campo.

Nel contesto specifico della discussione in essere, ci si concentrerà sui Quality Requirements.

Si ipotizzi che l’Intentional Architecture di riferimento preveda un NFR che declini la Security in funzione dell’accesso al sistema, rappresentato secondo il seguente Scenario:

Elemento Specifica (specifiche)
Sorgente dello Stimolo Un Utente esterno chiede di utilizzare il sistema
Stimoli Richiesta di accesso alle funzionalità del sistema
Artefatti Intera soluzione
Ambiente Erogazione
Risposta L’utente deve autenticarsi attraverso una 2-phase authentication
Misura delle Risposta Reazione in funzione di un numero massimo di tentativi errati

Lo Scenario, è, di conseguenza, un constraints di Dominio, secondo quanto rappresentato dalla figura seguente (fig. 2):

functional vs nonfunctional

Figure 2 – Scenario constraints

Partendo da questi elementi, come è possibile inserire tale requisito all’interno del Product Backlog? La cosa non è fonte di particolare problemi, potendolo esprimere in linguaggio naturale:

Un utente per poter accedere alle funzionalità del sistema deve autenticarsi con una procedura di tipo 2phase authentication: inserendo le credenziali statiche e poi il pin che viene inviato al proprio cellulare.

o anche nel formato che contraddistingue una tipica User Story:

Essendo un utente voglio potermi autenticare tramite una 2phase authentication con credenziali statiche e poi con pin inviato al mio cellulare, per poter accedere alle funzionalità del sistema.

È evidente che quest’ultima forma è una forzatura e sacrifica la chiarezza del linguaggio naturale in favore di una forma standard-de-facto. Se proprio si vuole utilizzarla, potrebbe essere opportuno non esprimerla in funzione dell’utente, ma di una fantomatica personas di sistema, ad esempio l’Amministratore:

Essendo l’Amministratore del sistema, voglio che gli utenti si autentichino tramite una 2phase authentication con credenziali statiche e poi con pin inviato al proprio cellulare, per poter accedere alle funzionalità del sistema.

In fondo, però, l’Agile non deve semplificare al massimo il processo e rendere chiaro cosa fare? Per questo la prima forma è fortemente consigliata. L’NFR riportato non è casuale, ma può essere considerato alla base della User Story di login presentata pocanzi (fig. 3):

login functional vs nonfunctional 

Figure 3 – Login constraint

In pratica, in questo caso, la TUS si configura come un nuovo Acceptance Criteria della User Story che ne vincola lo sviluppo a un requisito non funzionale definito tramite uno Scenario contemplato dall’Intentional Architecture. Tale definizione può avvenire sia ad inizio del percorso di sviluppo sia durante una delle sue revisioni periodiche.

Ma la TUS stessa ha un set di Acceptance Criteria che deve essere opportunamente definito e convalidato, prima di poterla considerare completa. Tornando all’esempio, una sua possibile definizione potrebbe essere la seguente:

  • Verificare che la fase di login avvenga in 15 secondi;
  • Verificare che dopo tre tentativi errati l’accesso per l’utente venga inibito;
  • Verificare che il messaggio di risposta arrivi nell’arco di 5 secondi;
  • ecc….

Bene, il requisito specifico di Sicurezza è ora espresso in modo diretto all’interno del PB, con tanto di criteri di accettazione, la possibilità di creare test automatici di validazione e tracciarne lo sviluppo. Si tratta di un risultato non di poco conto, che consente, inoltre, di parallelizzare le attività di sviluppo della User Story di login.

Resta un ultimo dubbio, però: quando si può considerare conclusa la User Story di login? Ebbene la User Story può ritenersi in “Done state” solo quando la stessa TUS è in “Done State”, essendo doveroso inserire nei relativi criteri di accettazione qualcosa tipo:

  • Tutti i constraints devono trovarsi in “Done” state.

Quanto detto può essere facilmente gestito in Visual Studio Online. Seguendo l’ordine di cui sopra, si crei la login User Story:

login user story 

Figure 4 – Login User Story

Notare che la Value Area è di tipo Business e che negli Acceptance Criteria si è specificato la necessità di superare i constraints. Si crei ora la login TUS di Security:

login tus 

Figure 5 – Login TUS

nessuna sorpresa che la Value Area sia di tipo Architectural.

L’ultimo passaggio è quello che lega la login User Story alla login TUS:

login us link 1

Figure 6 – Link login User Story to login TUS

da cui si ottiene il risultato seguente:

login us link 2

Figure 7 – login User Story linked to login TUS

Per avere anche una indicazione “visuale” della differenza tra i due PBI, è possibile creare una swimlane sulla Board di tipo “Constraints” che, una volta presi in carico sia la login User Story che la login TUS, le daranno un aspetto simile al seguente:

login us link 3

Figure 8 – Constraints swimlane

Si conclude qui la prima parte dell’approfondimento dedicato alle Quality Attributes in chiave Agile. Nel prossimo post verrà affrontato il caso in cui un NFR sia cross-User Story.