Quality assurance e metodi agili

Alessandro commenta in modo ineccepibile un post sul collocamento delle attivita di Quality Assurance (QA) nei metodi agili e mi sento solo di integrare con qualche considerazione di livello più basso, avendo lui già fatto gli opportuni riferimenti ai concetti di eccellenza nello sviluppo agile.

A mio avviso, l’autore del post commette la gravissima ingenuità di non tenere conto del concetto di project velocity o forse la concepisce – come spesso mi capita di ascoltare – solo in modo prospettivo:

Quanti punti facciamo la prossima settimana?

E basta.

In realtà almeno metà del senso della project velocity è retrospettivo:

Per garantire la qualità necessaria – test compresi, tutti: da unit test a test sugli utenti – la scorsa iterazione siamo stati capaci di “bruciare” 7 punti. Ne avevamo pianificati 18, ma evidentemente con tutti i test siamo riusciti a fare 7. Bene la prossima iterazione pianificheremo 7.

Ovviamente a prima vista questo significa rallentare. Perlomeno non meno che fare un’iterazione solo per fare test, come suggerisce l’autore. Tuttavia gli approcci sono ben lungi dall’essere equivalenti, perché in quello proposto nel post otteniamo feedback con minor frequenza, garantendoci solo una cosa: l’aumento delle chance di lavorare su un sistema che non rispecchia più la realtà dei fatti. Fatto che significa

  1. non risolvere i problemi realmente emersi, ma problemi già vecchi.
  2. spendere effort e quindi denaro su falsi problemi, pagando elevati costi opportunità.

Tutto sta nel tenere bassi i costi della contemporaneità, della coesistenza della fase di sviluppo e di test. Non per tutti i professionisti attorno allo sviluppo del software è, ad oggi, altrettanto facile. In ambiti come la progettazione UX per esempio i dibattiti sono ancora vivaci e dall’esito poco chiaro. Per gli sviluppatori però ormai ci sono tecniche e strumenti maturi. Basta solo la voglia.

January 04 2011 | Base | No Comments »

Stimare la project velocity alla prima iterazione – Prima parte

Circostanza frequente: team agile approntato, progetto intrapreso secondo la metodologia preferita (extreme programming o scrum o entrambe o…), hai terminato di stimare le user story, hai assegnato le dovute priorità insieme al resto del team e ora devi approntare un release plan che permetta di capire per quanto ne avrete. “Facile!” esclama il giovane agilista, “Basta prendere la somma degli story point e dividerla per la velocity del progetto!”. Senza dubbio corretto in linea di principio – e comunque non è mai così semplice nella pratica – ma soprattutto: alla prima iterazione che valore di velocity userai? Tu e il tuo team non avete mai lavorato su questo progetto, non hai dati retrospettivi su cui contare. E quindi? Affiderai tutto al caso?

Assolutamente no, ci sono delle tecniche per (aiutarci a) sciogliere questo nodo e voglio illustrartene qualcuna.

continue reading »

October 16 2008 | Esperti | No Comments »

Due giorni di sviluppo agile – Seconda parte

Proseguo il racconto che ho iniziato qui, dove avevamo visto l’avvio di un progetto di sviluppo adottando pratiche tipiche dell’extreme programming. Arrivati ad avere un backlog ben definito e distillato col forte contributo degli utenti esperti di dominio, vediamo ora la fase di release planning. continue reading »

July 21 2008 | Dalle trincee | 7 Comments »