Mitos ágeis - Revista Engenharia de Software Magazine 54

Já faz algum tempo que os métodos ágeis não são mais novidade nem vanguardistas. Cada vez mais e maiores empresas adotam processos e práticas reconhecidamente ágeis para o seu desenvolvimento de software. Ainda assim, da mesma forma que em ondas anteriores de inovações nos
processos de desenvolvimento, boa parte das implementações desses processos desvia do direcionamento original intencionado pelos seus criadores. Não é o caso de defender o purismo conceitual, mas algumas poucas concepções erradas podem atrapalhar a sinergia entre as práticas ágeis e fazer o processo conduzir a equipe a uma situação continuamente pior do que a inicial. Essa espiral descendente normalmente leva a dois caminhos: a desistência da adoção de práticas ágeis e o retorno ao desenvolvimento tradicional, ou a contínua adaptação dessas práticas, fazendo com que elas se tornem cada vez menos eficazes.

No contexto deste artigo serão abordados diversos métodos e processos que estão sob o guarda-chuva do Manifesto Ágil. Esses processos e métodos são formados por conjuntos de atividades, eventos, papéis e artefatos que procuram resolver um determinado problema num contexto específico. A essas soluções pontuais e específicas chamamos de ‘práticas’. No decorrer deste artigo o termo ‘práticas’ será usado para referenciar essas soluções que têm sua origem no Extreme Programming, Scrum, Kanban, TDD, Lean, dentre outros métodos, processos e abordagens.

Faremos uma exploração de alguns erros comuns encontrados em implantações de práticas ágeis. Esses erros foram observados em implantações de processos ágeis em diversos estágios, tanto iniciais quanto com mais de um ano. Nessa análise iremos entender o erro, explicar sua origem e contexto e discutir alternativas para resolvê-lo.

Com base nisso, serão discutidos mitos comuns no mercado e esclarecidos um punhado de princípios básicos que, se bem entendidos, aceleram qualquer projeto de transformação ágil. As situações onde são apontados mitos descritos neste artigo são comparadas a implantações corretas de práticas ágeis.

É importante esclarecer que o mito neste artigo são desvios em relação a modelos considerados corretos pela literatura vigente. Consideram-se implantações corretas aquelas que aderem a guias oficiais, como o Scrum Guide da Scrum.org e trabalhos seminais como o livro Kanban de David Anderson. Um exemplo pode deixar isso mais claro: se numa determinada empresa são feitas reuniões diárias (stand-ups) que levam mais de meia hora e a equipe começa a perceber que essa prática ágil não funciona, a conclusão está errada.
Reuniões diárias, segundo o Scrum Guide, não podem durar mais do que 15 minutos. Para poder avaliar sua eficácia a equipe precisa executar Scrum corretamente.

Mito 1: Ágil não documenta

Esse mito nasce quando alguém olha um quadro de Scrum ou Kanban e acha que não é possível documentar um projeto “sério” de desenvolvimento de software com aqueles papeizinhos. Quem olha um post-it com uma estória de usuário e acha que não é possível documentar naquilo tem, no mínimo, dois conceitos errados.

Em primeiro lugar, é um erro não diferenciar documentação de especificação. Nesse ponto cabe ressaltar que a diferenciação que será feita não é acadêmica, mas empírica e forjada no dia-a-dia dos projetos de melhoria de processo. Especificação é tudo aquilo que é necessário para que informação suficiente seja transmitida de um emissor (que precisa de um determinado software ou funcionalidade) a um receptor (que vai desenvolver o software ou funcionalidade). Para simplificar o contexto, digamos que um gestor de negócio precisa de uma nova funcionalidade no software usado pelo seu departamento, que realize uma série de cálculos financeiros. Existem diversas formas de transmitir essa necessidade do gestor para um programador com capacidade de implantá-la: