Agile Life

dicembre 2013 - Post

ALM, Agile Branch Strategy

Gestire la strategia di “branch” (e di conseguenza di “merge”) è sicuramente uno degli elementi più delicati nella gestione dello sviluppo di un software (Construction in DAD), la cui complessità aumenta in modo proporzionale alla dimensione del Team e, @Scale, al numero di Team coinvolti.

Tipicamente possiamo identificare tre tipologie primarie di branch:

  • Branch per Release, in cui il ramo principale (tipicamente “Main”) subisce un branch ad ogni nuova major release (1.0, 2.0, ecc). Ottenuta la build finale (ready-to-release), viene effettuato il merge con il ramo “Main” e il ramo specifico di release viene congelato ed utilizzato per le attività di fix del sistema in produzione (Transition in DAD).

Il lavoro sulla nuova release parte sempre dal ramo Main, costantemente aggiornato all’ultima versione rilasciata;

  • Code-Promotion Branching: in questo caso lo sviluppo avviene direttamente sul ramo “Main” e il codice (una volta superata la build e i relativi test di unità) viene “promosso” sul ramo di “Test”, per i test di integrazione ed accettazione, e sul ramo di “Prod” che identifica la soluzione in produzione. Chiaramente i fix effettuati sul ramo di “Test” sono sottoposti a merge con il ramo “Main”;
  • Feature Branching: in questo approccio il ramo “Main” viene splittato in funzione delle feature da sviluppare, consentendo di procedere parallelamente nello sviluppo della soluzione. Al termine dello sviluppo della feature, il codice viene unito a quello del ramo “Main”. Questa soluzione è molto utile quando il sistema è realizzato da più Team e quando si vuole parallelizzare al massimo le attività.

Ognuno degli approcci presentati ha, chiaramente, pro e contro, e si adatta meglio a diverse dimensioni del gruppo di lavoro annesso (1 o più Team) al progetto.

Nel caso specifico di un approccio Agile, è utile inserire una quarta tipologia, che definiremo: Iteration-based Branch. Si tratta, in pratica, di un mix tra le tre tipologie appena presentate, che associa il codice e le build all’evoluzione time boxed tipica di un approccio Scrum-like e che possiamo articolare come segue:

  • Si effettua il branch del ramo “Main” in concomitanza all’inizio delle attività sulla nuova release;
  • Si effettua il branch di Iterazione (Sprint)
  • Sul branch di iterazione si opera per feature (ricordiamo che le feature sono un insieme di User Story afferenti allo stesso ambito, anche assimilabili alle Epic). Quanto sviluppato va sempre validato con build e test automatizzati, in ottica di Continuous Integration;
  • Terminate le Iterazioni, si “promuove” il codice al branch di “Test” per effettuare i testi di Accettazione e quelli di Sistema. Il codice presente sul ramo di “Test”, eventualmente fixato, completa lo sviluppo della release e ne viene effettuato il merge sul ramo “Main”;
  • Completate le operazioni sul ramo di Test, il codice va in branch sul ramo di produzione, consentendo di gestire separatamente eventuali bug-fix annessi.

iteration-branch

Iteration-based Branch

Sebbene tale approccio possa sembrare complesso e, ad un primo sguardo, sembri produrre un numero elevato di branch (che comunque, utilizzando GIT, hanno un costo assolutamente trascurabile), la sua adozione permette di avere un totale controllo di quanto sviluppato e delle varie attività di Continuous Integration e Continuous Delivery.

Inoltre, più Team possono lavorare per feature, parallelizzando le attività e aumentando l’efficienza complessiva.

ALM, priorizzare le User Story per Valore… ma non solo

E' approccio comune, sia in Agile che Agile@Scale, priorizzare le User Story secondo quello che è il Valore associato, definito primariamente dal Product Owner con il Key-Stakeholder di riferimento.
Non sempre però questa scelta, in termini assoluti, è la più indicata, soprattutto se si considerano i seguenti fattori:

  • Gestione del Rischio, annessa a particolari feauture o parti del sistema: si pensi ad una funzionalità che interessa un domino poco noto o all'adozione di una tecnologia sconosciuta o poco matura;
  • Efficienza del Team, che può ridursi qualora le User Story a maggior priorità siano fortemente legate ad uno scope specifico (esempio, sviluppo della UI) e alcuni membri del Team non abbiano competenze sufficienti per dare un reale contributo.

Il primo fattore, in linea di massima, viene affrontato con degli Spike (funzionali o tecnologici) per confutare le proprie asserzioni. Nel caso dei framework @Scale (DAD e SAFe) si parla direttamente di approccio Risk-Driven, prevedendo di dare priorità allo sviluppo dei Work Item con alto rischio. Si consideri, ad esempio, una scelta architetturale che contempla la possibile adozione di un ESB, che, oltre ad essere esplicitata da Technical Story (livello Program se si adotta SAFe), può essere sottesa ad una User Story del tipo:

Essendo un Solution Architect voglio poter disporre degli strumenti per integrarmi con il resto della piattaforma con bassa dipendenza

Se tale User Story ha priorità bassa, potrei trovarmi nelle condizioni per cui una scelta architetturale fondamentale venga rinviata troppo nel tempo e le conseguenze, in caso di ipotesi errate e/o problemi relativi, crescano esponenzialmente. La soluzione è quella di "anticipare" tali User Story, affrontando subito problemi che altrimenti diventerebbero troppo costosi e creerebbero un debito tecnico molto alto. Utilizzando questo approccio, diamo allo Spike un "valore più nobile", sviluppando comunque un pezzo di sistema che poi sarà utile agli stakeholder perché realizzato confutando quanto ipotizzato o trovando la soluzione migliore.
Il secondo fattore è, invece, più ostico e meno contemplato nella letteratura Agile tipica. In teoria i membri del Team dovrebbero essere cross-functional e quindi poter operare indistintamente sulle varie parti del sistema che afferiscono alle User Story (tipicamente task). In pratica, una situazione di questo tipo è difficile da raggiungere e i membri del Team tendono a specializzarsi comunque rispetto ad un aspetto ben specifico. Bisogna allora evitare che nella scelta del Backlog di Iterazione le User Story afferiscano tutte alla stessa area, in modo da impiegare efficacemente il Team, cosa che rappresenta un Valore trasversale al progetto.
In pratica, possiamo definire un Iteration Value, composto da:

User Stories Value + Risk Value + Team Engagement

che, bilanciando equamente le tre componenti portanti, permette di:

  • ottenere un ampio Valore del delivery di iterazione;
  • abbattere velocemente il rischio di determinante scelte;
  • rendere il Team efficiente.

Per tener traccia di tale informazione è utile specificare esplicitamente la scelta di inserire nel Backlog di Iterazione una (o più) User Story con priorità inferiore, riportando una semplice descrizione preceduta dal "tipo di valore" che si massimizza.

iteration value

Iteration Value

[FELICEPESCATORE.IT]

ALM, un approccio pratico alla gestione del Debito Tecnico

Il problema del "Debito Tecnico" è spesso trascurato durante le normali fasi del ciclo di sviluppo, anche se (come abbiamo detto nel post specifico), nel medio periodo, porta ad una rincorsa continua della manutenzione correttiva a scapito di quella evolutiva.
Come possiamo approcciare praticamente il problema?
In un contesto Agile, il Technical Debt dovrebbe emerge ed essere affrontato in ogni Iteration Meeting, in modo da capire repentinamente quali azioni intraprendere. In alcuni casi estremi il momento adatto per discuterne potrebbe essere addirittura il Daily Meeting, anche se questo tende a destabilizzare le attività previste per la specifica iterazione e rischia di annullare il vantaggio di un approccio "time boxed", spostando il focus su un approccio Lean che, però, richiede una forte maturità del Team.
Restando, quindi, nella prima ipotesi, l'idea è quello di inserire, quando se ne ravvisa la necessità, una short-iteration qui ribattezzata: CTBi, ovvero Clean Technical Debt Iteration.
Questa iterazione breve (metà di quella standard adottata), consente di stabilizzare quando realizzato e far rientrare nel computo della Velocity, e dei relativi diagrammi di Backlog, anche le User Story che non si sono precedentemente riuscite a chiudere e che, quindi, hanno un peso 0 sulle stime.
Facciamo un esempio pratico: siamo nella situazione illustrata dalla figura seguente in cui l'Iterazione 2 è temporalmente conclusa (il framework Agile adottato è Disciplined Agile Delivery), ma la prima User Story non è completa!

cbt dashboard

User Story non completata

Attenzione: il Valore creato è 0, nonostante la User Story sia stata parzialmente completata. Questo perché la stima della Velocity (Story Point o Ideal Day, medio termine) è legata al Valore prodotto è non ai task (stima in ora, breve termine) realizzati.
Ma è corretto considerare completamente nullo il contributo della User Story? Probabilmente no, per questo possiamo, dopo una serie di iterazioni che presentano casi simili, creare una CTBi in cui spostare le User Story incomplete.
Questo approccio consente di evidenziare anche visivamente la presenza di un "ritardo" e di gestirlo con una modalità di recupero in modo da evitare la tentazione di ignorare la cosa: "ma tanto si tratta di poca roba".
Essendo la CTBi una short-iteration, la Velocity stimata avrà un peso più alto (rapporto Story Point/Time) rispetto a quella standard, permettendo di valorizzare quanto era stato già completato e di ottenere una media più realistica nell'istogramma che rappresenta la Velocity per iterazione.
Chiaramente si tratta di un approccio "una tantum" che non deve diventare sistematico. Se il Team non riesce mai a completare le User Story all'interno dell'iterazione, vuol dire che esiste un problema diverso da affrontare, ad esempio: incapacità di stimare correttamente la complessità relativa delle attività, sottodimensionamento, lacune tecnologiche, ecc.
Ma l'approccio CTBi enfatizza la trasparenza del Team, spingendolo a ragionare ancor di più sui problemi, e aiuta a diminuire l'ampiezza del Cono di Incertezza nelle stime di progetto.

 

[FELICEPESCATORE.IT]

Posted: 2 dic 2013 11:26 da felice.pescatore | con no comments
Inserito sotto: ,