Olá,

Concordo com o Tiago: velocidade mede capacidade de entrega. Corrigir defeitos afeta essa capacidade, então conta. Agora o grande segredo (que o Rafael parece estar no caminho certo de achar):

* Não use velocidade para medir valor. Sim, defeitos afetam o valor do software entregue, porém se ele foi considerado entregue na última iteração e, se o conceito de "entregue" está correto e inclui "código testado, integrado, com testes de aceitação definidos pelo cliente e os testes passaram", provavelmente o bug não será tão impactante assim.

Discuti sobre esse assunto com a Mary e o Tom durante o almoço e eis algumas das coisas importantes:

* O primeiro ponto é sobre a abordagem Lean: você deve fazer o máximo para garantir que seu código esteja livre de defeitos. Isso pode parecer idealista para nossa indústria, mas num ambiente de manufatura, isso é natural. Se você está numa linha de produção Lean que produz 100 tratores por dia, os 100 tratores, por definição, devem estar livre de defeitos. Se saiu um com defeito, você não vai aceitar:

(1) bem, agora eu só consigo produzir 99 tratores amanhã pois 1 sairá com defeito. Qual a causa raíz desse defeito? Como nos livrar desse defeito para sempre?

(2) bom, vamos começar a produzir 101 tratores por dia  e sobrecarregar nossas máquinas para garantir os 100 tratores bons por dia (já que 1 pode sair com defeito).

Apesar de não gostar de analogias, acredito que essa representa bem o cenário que estamos discutindo.

* O segundo ponto é sobre como medir valor? A Mary e o Tom propõe 3 medidas (e aqui já entramos no mérito das métricas que estou devendo outra thread) amplas que consideram a cadeia de valor inteira, do conceito ao dinheiro (concept to cash). Quanto mais medidas (e é natural querermos decompor as coisas), maior a chance de estarmos medindo a coisa errada. Quando temos 5 coisas de altíssima prioridade, na verdade não temos nenhuma. Enfim, as 3 medidas são:

(1) cycle time médio (quanto tempo demora para uma requisição do cliente ser atendida pelo seu processo?), e isso "reliably and repeatedly" (fiquei com preguiça de traduzir);

(2) retorno financeiro de alguma forma (ROI, NPV, ...), como garantir que nosso software está realmente trazendo valor? o que é valor no seu contexto?

(3) satisfação do cliente. Podemos produzir software com valor agora, mas isso é algo que conseguimos manter? por quanto tempo? Satisfazer as necessidades do cliente é algo que traz valor de verdade.

O ponto importante dessas medidas é que elas medem algo num nível tão amplo, que fogem do escopo da equipe e fazem com que as pessoas colaborem para atingir o objetivo comum. Velocidade é uma medida muito fácil de ser manipulada ("vamos dobrar o número de pontos que estimamos para cada história e nossa velocidade dobra!").

Espero ter esclarecido meu ponto. A discussão está boa...

Abs,
--
Danilo Sato
MSc. student in Computer Science - University of São Paulo - Brazil
www.dtsato.com