quinta-feira, 23 de outubro de 2014

Qual é o problema com os "métodos ágeis"?



Muita gente lê as minhas opiniões “ácidas” sobre os, digamos, “métodos ágeis”, e fica com a impressão de que eu sou contra sua aplicação. Então, resolvi escrever um artigo simples, na qual eu pudesse expressar o que eu realmente penso sobre o assunto.



Qual é o problema com os "métodos ágeis"?


Para começar, vou responder à pergunta título desse artigo: “Qual é o problema com os 'métodos ágeis'?”
  • Nenhum. Na minha opinião, não existe problema algum com as práticas reunidas sob o nome genérico de “métodos ágeis”. Inclusive, eu uso e recomendo o uso de várias delas em muitos projetos.

Então, por que eu sou tão crítico em meus artigos? Por que eu vivo “atazanando” a vida dos “evangelistas ágeis”, dando munição para que a audiência “envenene” suas belas palestras sobre o assunto?

É isso que eu pretendo explicar.

O que são “métodos ágeis”?

Antes de mais nada, é preciso contextualizar essa discussão. O que são “métodos ágeis”?

Se você já leu alguma coisa sobre o assunto, deve ter dado “de cara” com o documento “Agile Manifesto”, criado por alguns luminares da Engenharia de Software, entre eles: Kent Beck, Martin Fowler e Robert C. Martin (“Uncle Bob”). Você pode acessar o “manifesto” em: http://agilemanifesto.org/

Manifesto for Agile Software Development


We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.


Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas


São ideias muito bonitas e válidas! E os Desenvolvedores e Engenheiros de Software logo passaram a defender o “movimento ágil”. Note que este movimento começou dentro da área de Engenharia de Software, ao contrário de outras tendências, como Gestão de Projetos, por exemplo.

Logo, um conjunto de práticas e métodos foram criados, para tornar o desenvolvimento de software mais ágil e com maior qualidade, focando mais em colaboração e sinergia. Uma das primeiras práticas dos “métodos ágeis” foi o eXtreme Programming, ou XP.

eXtreme programming (XP) é uma prática de desenvolvimento de software cujo objetivo é melhorar a qualidade do software e a capacidade de resposta da Equipe, face a frequente mudança de requisitos dos Clientes. Entre diversas práticas, o XP prega:
  • Releases constantes: “Iterate fast and release often”, com um curto ciclo de desenvolvimento e processo simplificado, sua tendência é realizar mais entregas, em menor intervalo de tempo;
  • Programação em pares: Com constante criação e revisão de código;
  • Ênfase em testes, tanto unitários como de integração.
Outra “prática ágil” que começou muito cedo foi o TDD – Test Driven Development, proposta por Kent Beck e outros autores.

O Test-driven development (TDD) é uma forma de desenvolver software, baseada na repetição de um ciclo bem definido de atividades:
  1. O Desenvolvedor escreve um caso de teste, que falhará, porém este caso define uma melhoria necessária em uma função do sistema;
  2. O Desenvolvedor escreve ou altera o código fonte para que este passe no teste. sem se preocupar muito com a forma ou arquitetura. A ideia é fazer o mínimo possível para que o código fonte passe no teste;
  3. Uma vez satisfeito com o código fonte, por ter passado no teste, o Desenvolvedor o refatora, para melhorar sua qualidade.

Esse método também é conhecido como “Test first” e é uma prática ágil associada deste o início ao XP.

Outras práticas mais exóticas

O XP e o TDD são práticas ágeis muito bem vindas e aplicáveis a qualquer tipo de projeto, gerenciado sob qualquer processo de desenvolvimento ou metodologia. Elas vieram de Engenheiros de Software DE VERDADE, e são baseadas em sólidos fundamentos técnicos.

Porém, outras práticas ágeis, menos técnicas e mais “exóticas”, começaram a surgir, e também foram classificadas como “métodos ágeis”. Entre elas:
  • Scrum: De acordo com a definição de http://www.scrum.org, “Scrum” é uma maneira de organizar equipes para trabalharem em conjunto no desenvolvimento de um produto. Este desenvolvimento, ocorrem em pequenas partes, com cada uma delas sendo construída sobre as outras, já criadas. Desta forma, se encoraja a criatividade e permite-se a rápida resposta aos feedbacks e às mudanças, de modo a produzir exatamente o que o Cliente deseja;
  • Planning Poker: É uma maneira de estimar o trabalho, evitando que “vieses” pessoais atrapalhem a estimativa. Os casos (histórias) individuais são apresentados para estimativas. Após uma breve discussão, cada participante escolhe uma carta que represente a sua própria estimativa, que pode ser de esforço ou dificuldade. Quando todos escolherem, as suas cartas são apresentadas de uma só vez. Se não houver consenso, uma nova rodada de discussões pode começar;
  • Kanban: É um método de gestão de trabalho, com ênfase em entrega “just-in-time”, sem sobrecarregar os trabalhadores da Equipe. Todo o fluxo de trabalho, desde a definição de uma tarefa até sua entrega ao Cliente, é exibida em um painel, e os membros da equipe podem “puxar” tarefas que estão na fila e colocá-las em andamento. Quando falamos em “kanban”, podemos nos referir ao sistema de controle de trabalho ou ao quadro representativo do trabalho;
  • Pomodoro: Esta técnica visa gerenciar o tempo de um trabalhador. A técnica utiliza um cronômetro para dividir o trabalho em períodos de 25 minutos chamados de 'pomodoros'. São somente cinco os passos básicos para implementar essa técnica:
    1. Escolher a tarefa a ser executada;
    2. Ajustar o pomodoro (alarme) para 25 minutos;
    3. Trabalhar na tarefa até que o alarme toque; registrar com um "x";
    4. Fazer uma pausa curta (3 a 5 minutos);
    5. A cada quatro "pomodoros" fazer uma pausa mais longa (15-30 minutos);
E por que eu considero essas práticas “exóticas”? Porque surgiram com base em empirismo, ou seja, através de experiências práticas, sem a devida fundamentação acadêmica ou técnica. Em outras palavras, não são práticas oriundas da Engenharia de Software, representada pelo SWEBOK (http://www.computer.org/portal/web/swebok), do qual sou defensor ferrenho.

Mas, o fato de eu considerá-las “exóticas”, não significa que sejam desprovidas de méritos. Na verdade, eu mesmo emprego e recomendo algumas dessas práticas.

Então, o que há de errado?

Bem, o que eu vejo de errado com essa “onda” de “métodos ágeis” é a sua exploração indiscriminada, com fins puramente comerciais. Criou-se uma “mítica” em torno dos, assim chamados, “métodos ágeis”, com os vendedores oferecendo soluções “mágicas”, para todos os problemas, associando-as aos “métodos ágeis”.

Vemos empresas que sempre defenderam outras práticas, como processos iterativos (RUP), se declararem como “ágeis desde criancinhas”. Vemos “evangelistas” darem palestras sobre “métodos ágeis”, com grande desenvoltura, com o único porém de JAMAIS TEREM DESENVOLVIDO UM SOFTWARE!

Na verdade, os vendedores demoraram muito tempo até adotarem os “métodos ágeis”. E sabe o por quê? Porque eles não conseguiam formar um “produto” vendável com esse conjunto de práticas. Além do fato de estarem muito alavancados (com alto investimento) em práticas que seriam consideradas opostas das “ágeis”.

E o conjunto dos vendedores, sejam eles internos ou externos à Empresa, passou a associar o termo “ágil” a “desenvolvimento rápido”, ajudando a conquistar o coração dos Clientes. Do lado dos Desenvolvedores, “ágil” passou a ser considerado “sem burocracia”, libertando-os de tarefas consideradas como “burocráticas”, por exemplo: elaborar um cronograma, ou criar um “documento de arquitetura”.

A união da “esperteza” dos Vendedores, com a “preguiça” dos Desenvolvedores, resultou nesse pacote “demoníaco” que hoje conhecemos como “métodos ágeis”.

Scrum + Kanban: Resolve todos os seus problemas

Os vendedores adoraram o “Scrum”. Por que? Porque é fácil de vender e não exige conhecimento técnico para sua divulgação. Qualquer idiota pode subir em um palco e falar “buzzwords” e frases de efeito sobre as maravilhas do “Scrum”. É só juntar com o Kanban, que você tem uma “metotologia ágil”, simples de implementar, fácil de vender e extremamente atrativa, tanto para os Clientes como para os Desenvolvedores.

E os Gerentes, que geralmente nada entendem de matemática, preferem os Kanbans com papeizinhos coloridos, do que uma planilha de cálculo de valor agregado! Ô diacho!

Junte-se a isso uma pitada de “Planning Poker” e você tem tudo o que precisa para desenvolver software, não?

Scrum não é metodologia de Gerenciamento de projeto, assim como o Kanban não substitui um Cronograma, com caminho crítico identificado, e, finalmente, o Planning Poker não substitui métodos consagrados de estimativas, como o Ponto de Função.

O que os Vendedores (sejam internos ou externos à Empresa) “esquecem” de dizer é que:
  • Scrum só funciona bem com equipes preparadas e coesas, com requisitos bem definidos e arquitetura previamente projetada;
  • Kanban funciona bem com tarefas de igual formato e tamanho, com WIP bem definido e respeitando o ritmo dos trabalhadores. Mesmo assim, não substitui a gestão de tempo de um projeto;
  • No Planning Poker, as estimativas devem ser baseadas no tipo de trabalho e no histórico da Equipe com o mesmo.

Se você não concorda comigo, então acesse: http://www.mindmeister.com/pt/75066778/critical-success-factors-scrum-and-lean-management e veja o “mapa mental” dos fatores críticos de sucesso do Agile + Scrum.

Se observarmos o tópico “Agile specification”, veremos vários itens na árvore:
  • Single Product Owner for Develoment Team;
  • Structure Complex Products by Themes;
  • Determine Business Value on Themes and Epics;
  • Prioritize Backlog;
  • Breakdown High Priority User Stories;
  • Estimate High Priority User Stories;
  • Specify Acceptance Criteria of User Stories if PO os not full time available;
  • Specify non Functional Requirements to minimize technical debt.

Então, se você já estudou a metodologia PMI, de Gestão de Projetos, ou as KPAs do CMMI, vai reconhecer vários fatores em comum, não? É claro! O fato do Vendedor dizer que você vai usar “métodos ágeis”, não lhe eximirá de fazer o que é certo, mesmo que seja chamado de outro nome.

Por exemplo, como você vai trabalhar a Arquitetura do Software? Dá para fazer isso com “história de usuário” e “sprint”? É claro que não!

Você pode chamar do nome que quiser, mas terá que fazer de qualquer jeito:
  • Planejamento (de tempo, de escopo, de recursos);
  • Gestão de Escopo;
  • Gestão de Tempo;
  • Gestão de Custos;
  • Gestão de Riscos;
  • Gestão de Qualidade.

A não ser que o seu cliente seja mais idiota do que você imagina, você terá que prestar contas pelos requisitos não funcionais do Software, e isso não se resolve “empilhando” resultados de “sprints” uns sobre os outros, com iterações de curto prazo.

É preciso pensar e gerenciar a arquitetura e o projeto do Software, de modo a aumentar a sua qualidade. Como fazer isso apenas com o Scrum?

Como você vai garantir a qualidade do software produzido com essa “trinca do capeta” (Scrum + Kanban + Planning Poker), por exemplo:
  • Arquitetura: Sem dependências cíclicas, respeitando a “Distância da Sequência principal”, que permite criar projetos com alta flexibilidade e manutenibilidade;
  • Projeto: Respeitar os princípios de SRP – Single Responsability Principle, DIP – Dependency Inversion Principle, com classes altamente coesas e de baixo acoplamento;
  • Implementação: Criar código que evite duplicidade, seja fácil de manter e que respeite as boas práticas de programação.

É claro que essas coisas não aparecerão nas suas “histórias de usuário”, e nem no seu belíssimo Kanban, certo? Também duvido que você faça “Planning Poker” para planejar a qualidade do software.


Uma pergunta: Dá para resolver problemas de arquitetura com “reuniões em pé”? (eu sei, essa foi pura maldade...)


Não adianta bandeja de ouro, se a janela continua quebrada

Eu sou um admirador da obra de Michael Levine: “Broken Windows, Broken Business: How the Smallest Remedies Reap the Biggest Rewards”.

Neste livro, ele fala que devemos cuidar das mazelas, mesmo pequenas, pois elas comprometem todo o conjunto da obra.

Por exemplo, vamos supor que você sempre passe por uma Empresa, quando vai da Casa para o seu Trabalho. Um dia, você nota que os vidros de uma janela, bem lá no alto, estão quebrados. Com o passar do tempo, você continua a notar que a janela continua quebrada. O que você vai pensar dessa Empresa? “Se ela não cuida de uma janela quebrada, o que dirá do produto que fabrica?”

Então, de que adianta “dourar a pílula”, dizendo que vai adotar “métodos ágeis”, se os problemas continuam visíveis? Eis alguns exemplos:
  • Falta de comunicação: Os membros da equipe desconhecem as coisas, ou não conseguem os recursos necessários para suas tarefas;
  • Falta de planejamento: Uma entrega atrasa porque um recurso necessário não foi disponibilizado a tempo;
  • Falta de coerência: Entregam um projeto para testes funcionais, sem apresentar um relatório de testes unitários (e sua devida cobertura).
Não adianta colocar um Kanban, se você tem que forçar os membros da Equipe a trabalharem depois do expediente, ou em fins de semana. Isso é resultado de mau planejamento e não existe motivo nem desculpa “ágil” que justifiquem essas atitudes.

O Cliente verá suas “janelas quebradas” e não será enganado pelos “métodos ágeis”!

Outro dia, eu soube de um caso no mínimo curioso. Certa equipe, resolveu adotar o “Planning Poker”, e fizeram uma sessão de estimativas. Até aí, tudo bem. Só que o Chefe funcional da Equipe participou do Planning Poker, e, como se fosse surpresa, a estimativa DELE foi a escolhida. O resultado? Corrida para entregar, horas extras e estresse generalizado.

Então eu lhe pergunto: Isso é “ágil” ou é a bagunça dos anos 70, antes do surgimento da Engenharia de Software?

Então, é isso que eu tenho a falar sobre o problema dos “métodos ágeis”. E dou um conselho: Se for para usar “métodos ágeis”, faça direito:
  • Capacite a equipe;
  • Crie e implemente um planejamento geral;
  • Crie cronogramas gerais e de disponibilidade de recursos;
  • Desenhe e projete a arquitetura;
  • Gerencie os riscos!