Uma cascata iterativa não é ágil

Nos últimos dois anos, notei uma tendência preocupante – em equipes de todas as partes do mundo.

É a tendência de criar um processo de cascata iterativo e chamá-lo de "ágil".

Uma cascata iterativa

Em um Sprint, alguém (talvez um Business Analyst junto com o [Product Owner](/pt/product-owner/ "Product Owner)), tenta descobrir o que deve ser desenvolvido.

Como se quer ser ágil, trabalha-se com User Stories. Mas em vez de tratar as User Stories como marcadores de posição para conversas futuras, cada User Story se torna um pequeno documento de especificação de três a cinco páginas de conteúdo – e eu certamente já vi documentos mais longos.

Essas mini-especificações/User Stories documentam quase tudo o que pode vir à mente sobre o assunto.

Como é necessário um Sprint inteiro para descobrir e documentar tudo isso, um segundo Sprint é dedicado ao design da interface de usuário da User Story. Às vezes, a equipe tenta ser um pouco mais ágil (pelo menos em pensamento) e começa o trabalho de design pouco antes da mini-especificação de uma User Story estar completamente escrita.

Muitos membros da equipe veem isso como perigoso, porque as especificações ainda não estão completamente capturadas. Mas e daí, é nesse ponto que a agilidade entra em jogo.

Os programadores então recebem dois documentos nas mãos. Um mostra claramente como a User Story deve ficar no final, e o outro fornece todos os detalhes relevantes sobre o comportamento da Story.

Só se pode começar a programar quando esses dois artefatos estiverem prontos. Em algumas empresas, são os próprios programadores que forçam essa forma de trabalho. Eles têm a atitude de desenvolver tudo o que se quer – mas é melhor dizer exatamente o que é necessário logo no início do Sprint.

Algumas organizações vão ainda um passo além e fazem os testadores trabalharem uma iteração atrás dos programadores. Isso aparentemente acontece porque as User Stories de uma equipe ficam maiores quando cada Story precisa ter uma mini-especificação e um design de UI completo antes que o código possa ser escrito.

Felizmente, a maioria das equipes entende que programadores e testadores precisam trabalhar juntos na mesma Iteração, porém não estendem essa teoria para uma equipe inteira colaborando.

Isso leva ao seguinte processo

Uma primeira iteração é dedicada à análise. Uma segunda iteração (que pode se sobrepor ligeiramente à primeira) é dedicada ao Design de Experiência do Usuário e a terceira iteração é destinada à codificação e aos testes. Isso não é ágil. Pode ser o primeiro passo de uma organização para se tornar ágil. Mas não é ágil.

É uma cascata iterativa.

No desenvolvimento tradicional em cascata, uma equipe realiza toda a análise do projeto inteiro logo no início. Depois, todo o design do projeto é elaborado. Em seguida, todo o código do projeto é escrito. Por fim, todos os testes do projeto são executados.

No processo cascata iterativo descrito acima, a equipe faz basicamente a mesma coisa, mas cada Story é tratada como um pequeno projeto independente. Primeiro, toda a análise da Story é concluída, depois o design dessa Story, em seguida todo o código é escrito e tudo é testado. Isso é um processo cascata iterativo, não um processo ágil.

Em um processo ágil, idealmente todos os trabalhos seriam concluídos exatamente ao mesmo tempo. A equipe terminaria simultaneamente a análise do problema, o design da solução, o código e os testes dessa solução. Todas as quatro disciplinas (e outras que não mencionei neste exemplo) seriam concluídas exatamente no mesmo momento.

É um pouco ingênuo acreditar que isso pode ser alcançado 100% das vezes. (Às vezes é possível.) No entanto, pode ser uma meta para a qual a equipe trabalha.

Uma equipe deve sempre tentar realizar o máximo de trabalho possível simultaneamente. Todas as reflexões feitas antecipadamente (análise, design etc.) devem ser feitas o mais tarde possível, não muito detalhadas, mas ao mesmo tempo permitindo que o trabalho seja concluído durante a iteração.

Se você trata suas User Stories como pequenos documentos de especificação, pare com isso. Em vez disso, comece a ver cada Story como um lembrete para uma conversa. Você pode adicionar algumas anotações às Stories sobre coisas que não quer esquecer na próxima reunião. Mas essas anotações devem ser opcionais e não um passo necessário em um processo sequencial. Isso mantém a agilidade e evita que o processo se torne uma cascata.

Este texto é do blog de Mike Cohn e foi traduzido por nós para o alemão.

Gestão de Stakeholders

=> Aprenda as dicas e truques mais importantes de Roman Pichler sobre Gestão de Stakeholders

Definition of Done: simples e ainda assim complexo

=> Descubra como a Definition of Done te ajuda no trabalho ágil.

Como funciona uma Sprint Review?

=> Aqui você encontra um exemplo de agenda para a Sprint Review