Agile Life

luglio 2013 - Post

Architectural Styles and Patterns

La specifica di un Architettura Software passa attraverso l’analisi dei requisiti funzionali e non funzionali che il sistema dovrà soddisfare.

Una volta raggiunto una sufficiente analisi (in modo classico o sfruttando un approccio Agile come, ad esempio, DAD), è possibile definire l’(Intentional) Architecture che costituirà l’ossatura del software che andremo a realizzare.

In tale definizione, il sistema viene scomposto in elementi più semplici, a differente granularità, che permettono di catturare molti dei requisiti qualitativi e consentono di valutare più approfonditamente l’effort afferente. Tale attività viene effettuata dal Software Architect (nelle varie accezioni) che suddivide la descrizione in Viste e sfrutta gli Stili (Style) e i Pattern Architetturali per illustrare le proprie scelte.

Ecco, abbiamo incontrato due elementi che spesso creano confusione: che differenza c’è tra un Architectural Style ed un Architectural Pattern?

Diciamo subito che spesso entrambi vengono usati in modo intercambiabile, quasi come sinonimi, esattamente come accade spesso per Design ed Architettura di un sistema. In alcuni casi ci troviamo difronte anche ad una (in)volontaria omonima (Layer Pattern e Pattern Style).

Vediamo due delle definizioni tratte da Software Architecture: Foundations, Theory, and Practice:

An Architectural Pattern is a named collection of architectural design decisions that…

… are applicable to a recurring design problem parameterized to account for different software development contexts in which that problem appears.

An Architectural Style is a named collection of architectural design decisions that

… (1) are applicable in a given development context, (2) constrain architectural design decisions that are specific to a particular system within that context, and (3) elicit beneficial qualities in each resulting system.

Probabilmente dalla semplice lettura delle due definizioni non è così immediate estrarre le relative differenze. Ma se si analizza bene il testo si vede che il punto di partenza è differente: in pratica l’Architectural Pattern è pensato per risolvere un problema ben noto applicato allo specifico contesto, mentre l’Architectural Style è pensato per modellare il sistema al fine di raggiungere determinati elementi qualitativi.

Utilizzando una definizione pseudo-matematica, potremmo definirli come:

  • Architecture pattern: {problem, context} => architecture approach
  • Architecture style: architecture approach

Esiste inoltre una differenziazione nell’utilizzo dei Pattern e degli Stili all’interno delle Viste architetturali che chiarisce maggiormente le relative differente. All’interno delle Viste vengono utilizzati gli Stili che tipicamente afferiscono a tre categorie:

  1. Module styles
  2. Component-and-connector (C&C) styles
  3. Allocation styles

a ogni categoria appertengono una serie di stili, così come rappresentato nella figura seguente (tratta da Documenting Software Architectures, Views and Beyond)

architectural styles

Architectural Styles

Facciamo un esempio concreto.

Abbiamo il nostro sistema Vesuvius e vogliamo creare la Design View, in cui definiamo come il nostro sistema si scompone in moduli (per la differenza tra moduli e componenti rimando allo specifico post).

Immaginiamo di aver identificato alcuni moduli primari di Vesuvius, ma che, per ogni modulo, volgiamo descrivere la sua organizzazione interna, rappresentando i sotto-moduli che lo compongono e le relazioni tra essi.

In tal caso potremmo pensare di applicare il Decomposition Style che prevede la scomposizione in moduli secondo la regola dell’is-part-of:

decomposistion style

Decomposition Style

Ecco, in questo caso non abbiamo un Pattern che può assolvere al compito! Allo stesso modo nel Design che specializza l’Architettura, per la parte presentation potremmo optare per il Pattern MVC.

Volendo chiudere il discorso, possiamo affermare che:

  • Uno Stile Architetturale è utilizzato per descrivere l’organizzazione concettuale del sistema, evidenziato come esso sarà creato e come assolve alle specifiche funzioni;
  • Un Pattern Architetturale è, al contrario, è una soluzione completa per risolvere praticamente una specifica problematica afferente al sistema.

In tale ottica, come anche evidenziato dalla “formulazione matematica, un Pattern Architetturale è più legato allo specifico dominio e alla specifica tecnologia, mentre uno stile è più generico e facilmente utilizzabile in combinazione con altri stili.

Un ulteriore esempio: il pattern Broker specializza lo stile Publisher/Subscriber, ma lo stesso viene fatto dell’ESB.

Possiamo affermare che, tipicamente, usiamo gli stili e i pattern in combinazioni con due specifiche fasi di progettazione:

  • Definizione dell’Architettura -> Stili
  • Definizione del Design -> Pattern
DAD, il ruolo del Team Lead

teamleadTra i vari ruoli e le varie figure che ruotano intorno a DAD, e Agile in generale, quella del Team Lead (aka Scrum Master) è una delle figure centrali, che lega insieme capacità di gestione/interazione e competenze tecniche, quest'ultime, in generale, non strettamente richieste ma di forte aiuto a dare autorevolezza a chi si cimenta nel ruolo.

Un buon DAD Team Lead è una guida che innalza il livello del Team a quello che in un post precedente abbiamo definito High Performance Team. E' quindi un ruolo chiave che si comporta da Coach ma anche da riferimento tecnico e da abile bilanciatore delle necessità del Membri del Team, del Team, del Product Owner e dei vari Stakeholder. Il tutto posizionandosi anche border line, rispetto a ruoli e metodologie, laddove il Goal da raggiungere giustifichi l'azzardo.

Anche se ogni professionista ha un proprio modo di abbracciare la mission del Team Lead, che non è di controllo ma di coordinazione e di protezione del Team, è possibile identificare una serie di elementi che possono fare la differenza:

  • Essere disciplinato. Avere sempre ben chiaro i propri obiettivi ed i propri doveri, creando, ad esempio, una short list giornaliera e tenendo sempre sotto controllo le metriche afferenti al progetto come, ad esempio, il Burndown Chart;
  • Assumere decisioni che sono in linea con i valori ed i principi Agili, tenendo come riferimento i dettami legati al Valore ed al Rischio (Value and Risk Driver). Tutte le decisioni vanno prese coinvolgendo sempre il Team di Delivery nel suo complesso, cercando di rispondere adeguatamente agli stimoli di cambiamenti che interessano sia lo sviluppo, sia le varie fasi ALM;
  • Temporizzare correttamente i Daily Meeting. Il Meeting va opportunamente gestito, dedicando allo stesso non più di 15 minuti al giorno. Se un membro del Team, dopo aver esposto il lavoro fatto e le attività che andrà a fare, ha bisogno di approfondire qualche argomento, lo dovrà fare al termine del Meeting;
  • Veicolare al Team le esigenze del Management e le scadenze. Il Team Lead fa da "tampone" tra il Team di Dev e il Management, rappresentando in modo incrociato le esigenze di entrambi e trovando la quadratura del cerchio;
  • Avere sempre chiaro il flusso di lavoro da eseguire. E' fondamentale gestire sia l'ordinario che lo straordinario, ovvero le situazioni impreviste o un carico improvviso di attività. In questo i tool possono sicuramente aiutare, ma dietro bisogna avere una piena consapevolezza d'insieme;
  • Effettuare presto e spesso le demo. Nonostante il sistema sia "naturalmente" dimostrabile ad ogni iterazione, se ci sono dubbi o è necessario mostrare alcune funzionalità ai key stakeholder, il Team Lead deve spingere per effettuare la dimostrazione il prima possibile, anche durante lo svolgimento dell'iterazione;
  • Coach don't direct! Il Team Lead è un manager servente, ovvero al servizio del Team. Se ci si accorge di "dominare" la conversazione e che i membri del Team non si rivolgano al Team stesso ma a solo al Team Lead, allora bisogna cambiare qualcosa;
  • Essere un riferimento positivo. Uno dei principi portati di DAD è che il successo di un progetto è determinato primariamente dalle persone che vi lavorano. Per questo è fondamentale che il Team Lead dia il buon esempio, gestendo i momenti critici e pesando sempre le decisioni. Certo, alcune scelte potranno risultare sbagliate, ma se esse vengono fatte con il "consenso" del Team e analizzando il contesto con parsimonia, saranno da sprono a migliorare la capacità di analisi e la capacità decisionale non perdendo il rispetto del Team stesso;
  • Formare un Team Lead di riserva. Forse questo è uno dei compiti più strani: formare un proprio sostituto. Ma l'attività è assolutamente in linea con il ruolo di servente del Team, poiché da opportunità a uno dei membri del Team di abbracciare questo ruolo e garantisce al Team stesso che, in caso di assenza, ci sia qualcuno in grado di garantire il regolare svolgimento delle pratiche DAD/Agile/Lean;
  • Affinare i meccanismi di inserimento e rimozione dei work item dall'Iteration Backlog. Questo elemento abbraccia il 4 volare dell'Agile, ovvero la risposta al cambiamento. Il Team Lead deve essere in grado di rispondere adeguatamente alle richieste di cambiamento provenienti dal Product Owner, garantendone la fattibilità ed evitando di creare un overhead per il Team. Inoltre, nel caso in cui ci siano problemi durante le iterazioni, il Team Lead deve concordare con il Product Owner l'eventuale diminuzione del carico di attività da eseguire, il tutto in linea con il principio che un DAD Team si mette al lavoro solo sulle attività che reputa di poter terminare correttamente durante una iterazione.
  • Padroneggiare l'arte della scomposizione. Il Team Led deve essere estremamente abile nel guidare il Team nella definizione di User Story sufficientemente granulari da essere completate all'interno di una singola iterazione. Se la velocity permette di aggiungere nuovo lavoro ma le User Story rimaste hanno tutte story point maggiori, il Team Lead può guidare lo splitting della stessa o chiedere al Product Owner di rimuovere un'altra User Story (abbassandone la priorità) in modo da massimizzare le attività durante l'iterazione;
  • Promuovere una cultura in cui i successi e i fallimenti appartengono al Team. Il Team è tale se il successo appartiene a tutti e il fallimento è un elemento condiviso che serve per migliorarsi e non per accanirsi contro qualcuno. Il compito del Team Lead è quello di far maturare il Team, i cui membri, lo ricordiamo, in ambito DAD sono multidisciplinari e equamente responsabili.


[FELICEPESCATORE.IT]

Gamification e Agile, un connubio naturale

Dopo alcuni post sulla Gamification è giunto il momento di rispondere ad una ovvia domanda che per chi segue questo gruppo/blog, fortemente dedicato al mondo Agile, si sarà sicuramente posto: come si sposano i principi della Gamification con lo sviluppo Agile e l’Application Lifecycle Management in generale?

Ebbene, proviamo a rispondere alla domanda evidenziando come la declinazione più utile in questo ambito è rappresentata dai Serious Play, che, ricordiamo, sono i giochi utilizzati da due o più decision-maker che si confrontano per risolvere problemi reali e raggiungere obiettivi chiari e condivisi, tenendo opportunamente conto dei constraints.

In ambito Agile molti utilizzeranno il Planning Poker, che tramite delle carte permette di stimare la complessità di una User Story (What will be the cost of this feature?): ecco avete usato la Gamification. Un altro esempio molto utilizzato è Buy a feature che permette di stabilire quali feauture i clienti si aspettano di trovare nello specifico prodotto.

planning-poker-fullfan

Planning Poker

L’obiettivo di fondo è quello di coinvolgere tutti coloro che in qualche forma afferiscono al Team di Deployment, rendendo più forte la compressione dei problemi e del modello di business da perseguire, grazie ad un continuo miglioramento ed un commitment (impegno) preciso di ogni singolo membro.

La Gamification permette di utilizzare le dinamiche di un gioco per definire metriche che rispondano a domande come: “Stiamo migliorando la qualità del nostro lavoro?” o anche “Il prodotto che stiamo sviluppato risponde alle reali esigenze dell’utente finale? Tutto ciò viene realizzato in modo diametralmente opposto a quanto previsto dal project management classico, con una definizione up-front dei parametri di riferimento.

Cosa fondamentale è la possibilità di ripetere il gioco in modo da ottenere un “punteggio” da confrontare con quello precedente e avere un indice relativo di miglioramento del proprio processo di sviluppo.

Un esempio concreto? Microsoft Visual Studio Achievements è un plug-in per Visual Studio che, al raggiungimento di determinati obiettivi (linee di codice, bug risolti, ecc) consegna dei premi virtuali creando una classifica generale che l’azienda può utilizzare per premiare i Team (ricordate: in Agile quello che conta è il Team non il singolo sviluppatore) che hanno migliorato le proprie performance e ottenuto i risultati migliori.


[FELICEPESCATORE.IT]

DAD, una approccio pragmatico al raggiungimento degli obiettivi

Abbiamo avuto più volte modo di descrivere le motivazioni che possono portare un azienda che sviluppa software (o una sua unità funzionale) ad abbracciare Disciplined Agile Delivery come framework Agile di riferimento.
L'enfasi su un approccio pragmatico, che predilige, quindi, un utilizzo dei metodi Agili (Lean) all'interno di contesti aziendali anche complessi, consente di abbracciare l'intero ciclo di vita del software e non solo la fase di sviluppo. Tutto ciò ruota, come è ormai noto, attorno ai Goal, che si differenziano in base alla fase di riferimento e in base al contesto operativo. Ma come possiamo approcciare in modo strutturato alla specializzazione e alla definizione di un Goal specifico?
Come spesso accade, la rappresentazione grafica (Visual Language) è un ottimo modo per focalizzare i concetti e, nel caso specifico, avviene tramite quello che Ambler e Lines chiamano il Goal Diagram:

goal-notation-summary

Goal Diagram


Ogni Goal è caratterizzato da una o più Issue (tematiche, problemi) che possono essere risolte tramite una serie di opzioni da bilanciare opportunamente.
Nella figura precedente si nota che le varie opzioni sono priorizzate da una freccia che punta verso l'alto, indicando nella prima opzione la più desiderabile da un punto di vista Agile/Lean. Può anche verificarsi la situazione in cui una Issue non venga affronta o venga semplicemente ignorata: in tale caso l'opzione scelta sarà "None".
L'applicazione di questa selezione porta alla definizione di un vero e proprio Process Goal Diagram.
Prendiamo come riferimento uno dei Goal previsti dalla fase di Inception ovvero: Explore the Initial Scope (in realtà tale Goal nella versione attuale di DAD è confluito nel più ampio Identify initial technical strategy, initial requirements and release plan) che permette di focalizzare la Vision di progetto e ottenere l'assenso degli stakeholder. Un possibile Process Goal Diagram per esso è il seguente:

 

goal-inception-explore-initial-scope

Process Goal Diagram per l'Explore Intitial Scope

In pratica il Goal specifico si caratterizza attraverso 5 Issue:

  • Livello di dettaglio, ovvero quanto si intende approfondire il Goal nelle sue varie sfaccettature;
  • Tipo di Vista, come viene modellato il Goal;
  • Strategia di Modellazione, attraverso quali strumenti l'obiettivo viene modellato;
  • Strategia di Gestione dei Work Item, come vengono priorizzati ed organizzati i task;
  • Requisiti Non-Funzionali, come vengono definiti e gestiti i requisiti qualitativi annessi.

Come è facile intuire, ogni Goal ha delle specifiche Issue associate

goal-construction-address-changing-stakeholder-needs

Process Goal Diagram per Addressing changing stakeholder needs

L'utilizzo del Process Goal Diagram consente di evidenziare in modo diretto qual è l'approccio adottato per definire le caratteristiche di un Goal, richiamando rapidamente le scelte effettuate. Inoltre, per i nuovi DAD Team, è possibile pre-definire una serie di Process Goal Diagram in cui effettuare le scelte, aiutando la logia di apprendimento del framework.


[FELICEPESCATORE.IT]