Revisitando o Agile

As metodologias de desenvolvimento ágeis são baseadas em conceitos simples: rapidez para modificar, entregas menores e contínuas, alinhamento constante com o usuário, etc. Muitos falam de seu uso e suas virtudes, mas nem sempre é muito bem explicada a filosofia de otimização de ROI (retorno de investimento) também existente nelas.

A melhor explicação que tive (e recomendo a leitura) veio do livro “agile management for software engineering applying the theory of constraints for business results”. Nele o autor nos relembra que a produção de software pode ser vista como um processo em etapas para a produção como, por exemplo, análise, desenvolvimento e teste. Cada etapa recebe insumos e produz seus produtos/artefatos: a análise recebe pedidos de features e entrega especificações para o desenvolvimento, este entrega código para o teste que, por fim, entrega softwares para a produção.

O que o autor nos chama a atenção é que esta esteira de processos retilínea não é realista. Cada processo tem suas perdas e estas perdas podem voltar para as pilhas dos processos anteriores de um modo que denominamos de realimentação negativa. O alarmante é que esta realimentação negativa pode causar, no limite, uma parada total da produção, já que podemos encher cada pilha de insumos com os retornos de falhas, consumindo toda a produção nestes acertos… sem mais produzir nada de novo. Já encontrei esta roda viva em projetos reais - não é agradável.

Um ponto interessante é que estes artefatos são feitos tanto de diagramas e documentos quanto de conceitos e, por isto, deterioram com o tempo. Por exemplo, o código errado, quando volta para o desenvolvedor, deve ser re-estudado. O tempo de re-estudo, por sua vez, é muito maior do que se ele tivesse sido revisto e acertado enquanto o desenvolvedor estava com todos seus conceitos frescos na sua mente. O mesmo acontece com o processo de design.

Uma última conclusão simples: um erro no design tem custo potencialmente maior do que um erro no desenvolvimento. O motivo é simples: ele gasta à toa as pilhas de desenvolvimento e teste com linhas de código e testes errados.

A teoria é boa, mas ela garante o bom resultado das metodologias ágeis? Parece que não.

Um pequeno artigo, que dá uma foto resumida do que temos agora, pode ser encontrado na revista IEEE Software que você pode encontrar em https://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0909/rW_SW_WhatDoWeKnow.pdf. Ele mostra que ainda temos muito a pesquisar e melhorar tanto neste tipo de processo quanto nos processos não ágeis. O artigo também nos dá em separado uma lista de estudos empíricos sobre o Desenvolvimento Ágil (veja em https://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0909/rW_SW_WhatDoWeKnow2.pdf ) .

Pode ser útil.

Abraços

Comments

• Anonymous
  October 01, 2009
  Não creio ser possível culpar metodologias (scrum, xp, etc) por erro de levantamento de informações. Um painel de tarefas não é um analista e nem um gerente de projeto. Ele está ali para prover a visão no tempo real das demandas de cada um do processo como um todo. Reuniões periódicas servem para reorganizar alguma coisa que pode estar desalinhada ou até melhor, que pode estar COMEÇANDO ainda a desalinhar. O responsavel (analista, fabrica de sw, qualidade) deve estar atento! A metologia não pensa, não sente e muito menos pressente um desvio do objetivo. Mais uma vez como ja defendi anteriormente aqui em seu blog, não da pra fazer as coisas sem recursos qualificados e principalmente  sem comprometimento humano.

• Anonymous
  October 01, 2009
  Muitas certezas, não é Nodari? Por isto a recomendação da leitura dos estudos neste posts. As pesquisas indicam que ainda não temos tantas condições de ter certezas. Abraços