menu

Será que o Agile virou um dogma?

Por

Memeplex Agile

memeplexUm termo interessante do qual tomei conhecimento através do livro “Management 3.0” do Jurgen Appelo foi Memeplex. Esse termo reflete um conjunto de conceitos que se juntam e se reinforçam mutuamente — o exemplo dado no livro era o do natal com renas, árvores de natal, papai noel, luzes natalinas, troca de presentes etc.

Aonde quero chegar com essa história de Memeplex?

O Agile surgiu como forte contraponto a um outro memeplex que era o da gestão tradicional (inclusive de projetos) com suas infinidades de práticas, técnicas e processos. Ou seja, conceitos inter-relacionados e interdependentes.

O Agile apareceu no cenário com “meros” quatro valores e doze princípios, ou seja, um memeplexzinho que nasceu para ser leve, ou “lighweight” se preferir; mas com o tempo foi “crescendo”. Novos termos e conceitos foram sendo agregados como se fizessem parte da natureza do Agile. Exemplos não faltam: Histórias de Usuário; TDD; Programação em pares; Integração Contínua; Entrega Contínua — quer que eu continue? Testes de Integração; Testes Funcionais; Retrospectivas; Plannings; Dailies, etc, etc.
Jurgen Appelo, no citado livro Management 3.0, falando sobre “rule-making” (normatizar):

O desenvolvimento ágil de software, para começar, não é fazer programação em pares, TDD, ou Histórias de usuário (…) Quanto mais se impõe regras rígidas, mais se restringe a capacidade natural dos integrantes da equipe para criar regras. Por fim, eles perdem a capacidade de serem realmente ágeis.

O problema não é — naturalmente — cada uma dessas práticas e/ou conceitos que foram se agregando ao Agile, mas a ferocidade com que se defende a adoção integral — não da mentalidade Agile — mas de todas essas práticas, frise-se, todas e muitas mais. Há empresas tidas como evangelistas do Agile que se enquadram perfeitamente na seara de não mais avaliar a utilidade e a conveniência de cada uma dessas práticas, algo, diga-se, nada Agile. Parece que desligamos o cérebro ao invés de explorá-lo com o máximo da força.

Contratos de usuário

historiaAs histórias de usuário, como diziam, deveriam ser “suficientemente incompletas”, justamente para gerar o diálogo entre os desenvolvedores e os clientes.

Tenho visto histórias de usuário que mais se parecem com mini contratos de escopo fechado, com critérios de aceite extensos e super detalhados. Tudo isso com o cliente participando do dia a dia da equipe.

Será que esquecemos que um dos valores do Agile é a Colaboração com o cliente acima da negociação de contratos?

Análise Marginal

Vou usar um exemplo do problema que temos trazido para nossos projetos. O problema da demasia nos testes de toda natureza. Isso mesmo, você leu certo, demasia em testes.

A gestão tradicional de projetos trazia o conceito de “Análise Marginal”, ou seja, encontrar o ponto em que o custo do esforço de qualidade igualaria o benefício obtido com a qualidade, em que a adição de mais esforço nesse sentido passaria a prejudicar o projeto em vez de beneficiá-lo.

Às vezes, um teste unitário basta, às vezes não, a ideia é que qualidade traz mais desempenho para equipe, com menos retrabalho, mais economia de custos, mais satisfação do cliente etc, mas acontece que o esforço de qualidade não é livre de custos e devemos avaliar o ponto ideal de pararmos.

Donald Reinertsen em seu livro “Principles of product development flow” corrobora esse ponto:

Vamos começar com um problema simples: Será que deveríamos lançar um produto diretamente do desenvolvimento para a fábrica antes de termos eliminado todos os defeitos? A maioria das empresas aborda essa questão como um debate filosófico em que um lado defende que o desenvolvimento deveria terminar seu trabalho antes de passar o produto para a fábrica e o outro lado argumenta que é uma bobagem esperar que o produto fique perfeito antes de entrar em produção. Quem estará correto?

Podemos descobrir quantificando o impacto econômico geral. (…) Qual a diferença no custo de se corrigir um defeito no chão da fábrica comparado ao de corrigí-lo no desenvolvimento? (…) Quanto retrabalho gera um típico produto imaturo no chão de fábrica? (…) Quanto tempo levaria para o desenvolvimento encontrar o mesmo número de defeitos que pode ser encontrado em uma semana no chão de fábrica?

Obviamente não é fácil fazer análises numéricas, como sugere esse autor, mas podemos pelo menos subjetivamente levar em conta alguns desses fatores para cada nova funcionalidade:

  • Avalie quanto outras funcionalidade dependem ou dependerão dessa;
  • Avalie qual seria o impacto na marca se houvesse um problema em produção, quantas pessoas seriam afetadas, qual o efeito de ocorrer uma falha;
  • Avalie quanto os usuários são sensíveis a falhas, mesmo que corrigidas rapidamente;
  • Avalie quanto sua marca seria afetada com a ocorrência de uma falha;
  • Avalie qual seria o custo de desenvolver e/ou executar os testes unitários, os de integração, os funcionais, os exploratórios etc

Essas variáveis servem como um norte do quanto investir para evitar um erro, podendo — às vezes — valer a pena apostar na resiliência e ser reativo no tratamento dos problemas. É claro que um teste unitário em geral é muito barato de se fazer, mas nem todos os outros são fáceis e baratos de fazer e/ou manter. Lembre-se disso na sua avaliação.

Vamos voltar a ser ágeis, largar os dogmas e voltar a pensar!

Segue um link para refletirmos:
http://manifestoagil.com.br/

About the author: Leonardo Campos

Leonardo Campos trabalha na área de TI desde 2000, atuou boa parte deste tempo como desenvolvedor Java, mas também desenvolveu profissionalmente com Ruby, .NET, VB, PHP e ASP. Desde do começo de 2009 vem atuando com Agile e hoje trabalha na ThoughtWorks Brasil. É estudioso de processos e entusiasta de Lean e Agile, sendo um dos organizadores do Lean Coffee São Paulo e editor da InfoQ. Leonardo é advogado por formação (Universidade Presbiteriana Mackenzie).
LinkedIn
@leonardocampos

7 comments

  1. Mauricio Bonetti

    Parabéns, Leonardo.

    Há quem diz que pensar de forma dogmática, independente do assunto, é o primeiro passo para o erro. Eu concordo com isso e em computação essa é a primeira vez que leio algo que trate a questão por esse viés. Para mim, o grande objetivo de qualquer metodologia ágil é proporcionar bem-estar para todos os envolvidos, ou seja, fazer melhor, satisfazer o cliente, satisfazer a equipe e faturar melhor.

    Posted on julho 23, 2013
    • Leonardo Campos

      Maurício, obrigado pelo comentário!

      Com o que você disse:
      “pensar de forma dogmática, independente do assunto, é o primeiro passo para o erro”, lembrei-me de um ponto interessante no framework Cynefin (http://blog.kudoos.com.br/gestao/teoria-da-complexidade-na-copa-de-2014/, http://www.infoq.com/br/news/2012/11/cynefin-gestao-de-mudancas)
      Nele existe a ideia que se pode cair para o quadrande caótico simplesmente deixando de raciocinar, fazendo sempre a mesma coisa só porque funcionou um dia.

      O que você acha?

      Posted on julho 23, 2013
      • Mauricio Bonetti

        Leonardo,

        Você trouxe informação nova. Categorizar o seu domínio joga luz para decidir quais práticas adotar. Não conhecia o framework, achei interessante também. Quando me referi ao dogmatismo o fiz simplesmente pensando em Sociologia. Não tenho experiência em conduzir equipes e, portanto, não sou um agente da mudança. Mas isso é uma ideia que sempre carrego comigo. Algo que deu certo em um contexto talvez não atenda a outro. Penso nisso quando escolho, por exemplo, uma linguagem de programação, ou um framework para resolver um problema. Não me importa se conheço ou não, o importante é ser o ideal para resolver o problema. Há quem desenvolva aplicação que não é distribuida usando EJB, enfim…

        Posted on julho 24, 2013
  2. Pingback: Tolerância Zero: Uma abordagem para a qualidade | Kudoos

  3. Pingback: 3 equívocos sobre Agile que ainda estão entre nós | Kudoos

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top