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 07:22 pm | Base

Trackback URI | Comments RSS

Leave a Reply