Risco e desperdício em projetos Agile

Quando você começa a “fazer Agile↳Agile11 conteúdosO antiágil: quais as práticas que te afastam do AgileGestão Dev & TI · ago 2020Adoção de metodologias ágeis em TI pode fazer a diferença em um mundo de rápidas mudançasGestão Dev & TI · mai 2023Webinar HostGator mostra como usar Metodologias Ágeis para tirar um projeto do papelGestão Dev & TI · mai 2019Ver tudo em Gestão Dev & TI →”, o foco está em obter a mecânica certa:

• mantenha seus updates curtos
• não sobrecarregue no design
• lembre-se de adicionar testes para tudo
• lembre-se de verificar o status da CI
• mostre apenas código de trabalho durante showcases
• …

Isso é perfeitamente natural já que os membros da equipe se esforçam para Competência. Infelizmente, também é natural a tendência de se envolver em táticas e esquecer-se de prestar atenção ao quadro maior.

Afinal, Agile é simplesmente uma maneira de gerenciar projetos de software. Assim como qualquer outra metodologia de gerenciamento de projetos, ele tenta garantir a entrega bem sucedida, lidando com as coisas que fazem com que projetos fracassem. Coisas como falta de coordenação, falta de compreensão, ineficiências etc. E, embora essas armadilhas possam derrubar qualquer equipe, parece que as novas equipes Agile são particularmente propensas a duas: risco e desperdício.

Risco

As equipes Agile muitas vezes acreditam (fortemente) em Emergent Design, enquanto omitem Design Big Up Front. Ou seja, querem deixar o design do sistema “aparecer” ao longo do tempo, em vez de planejarem tudo à frente do tempo *. A razão por trás disso é simples: BDUF te força a fazer escolhas de design com informações incompletas, o que leva a um trabalho desnecessário (“nós realmente precisamos de cinco camadas para carregar um conjunto de dados”) ou retrabalho (“eu realmente gostaria de saber que a biblioteca X não suporta recurso Y antes de usar em todo o lugar!”).

Há todo um conjunto de técnicas à nossa disposição para a prática de Emergent Design: atrasar decisões até o último momento em que for possível, tentar fazer a coisa mais simples primeiro, tentar evitar construir coisas a não ser que realmente precise delas etc. Tudo isso são técnicas ótimas e úteis que devem ser utilizadas sempre que possível. Exceto quando não é possível.

A coisa é que, na verdade, fazer Emergent Design (especialmente em grande escala) não é trivial. Cada sistema possui requisitos imprescindíveis no projeto que podem forçar a implementação a ocorrer de uma maneira ou de outra. Por exemplo, a necessidade de expor a funcionalidade de vários tipos diferentes de consumidores muitas vezes resulta em colocar a lógica de negócios por trás de uma camada de serviços. Se esses requisitos não estiverem lá, é desnecessária e provavelmente nociva uma camada de serviços (na medida em que complica as coisas e torna o sistema menos sustentável).

Quando se trata de requisitos imprescindíveis no projeto, a ignorância não é uma bênção. Surpresas que resultam da descoberta de requisitos imprescindíveis no projeto tarde demais raramente são agradáveis. Na melhor das hipóteses, você pode ter mais trabalho do que você planejava. No pior caso, pode ser necessário reescrever grandes partes do sistema que você já construiu.

Então, seguir os princípios de Emergent Design cegamente é arriscado, pois pode fazer com que as equipes Agile adiem a descoberta de requisitos do seu sistema de design. Em outras palavras, assim como fazer BDUF pode gerar desperdício, não fazer algum projeto Up Front (SDUF?) pode fazer a mesma coisa (Sim, pode ser um tipo diferente de desperdício, mas é não deixa de ser desperdício). O que me leva ao meu próximo ponto…

Desperdícios

Quase por definição, processos Agile assumem que haverá algum desperdício. Quero dizer, se você está construindo algo ao longo do tempo, aprendendo e mudando à medida que avança, você terá, muito provavelmente, que voltar atrás e mudar pelo menos algumas partes criadas anteriormente. O que torna os resíduos do Agile especialmente dispendiosos é o investimento em qualidade que as equipes Agile frequentemente fazem.

Muito frequentemente, as equipes Agile enfatizam fortemente a construção de software de qualidade (e, se não o fazem, deveriam). Mas a qualidade não é livre. Fazer TDD↳Testes automatizados4 conteúdosComo migrei meus testes automatizados de Java para Ruby… Será que fiz bem?Dev (Back & Front) · jun 2019TDD em Nodejs: conhecendo o JestDev (Back & Front) · mar 2019Arquitetura Hexagonal na prática com exemplos em PythonDev (Back & Front) · mai 2025Ver tudo em Dev (Back & Front) →, escrever testes automatizados, emparelhamento, e outras maneiras de garantir qualidade têm um custo associado a eles. Quanto mais testes você tiver dando suporte para o código que escreveu, mais testes você poderá ter que mudar se decidir refatorá-lo de forma significativa.

Um problema relacionado aparece quando o investimento em qualidade é feito às cegas. Se o código que você está testando realmente vai chegar à produção, então o investimento em qualidade é justificado. Por outro lado, se você faz TDD em uma solução que acaba sendo descartada ou escreve testes funcionais contra algo que irá mudar definitivamente (como uma interface de usuário em fluxo), aquele nível de investimento em qualidade não é, provavelmente, justificado. Poderá fazer mais sentido fazer um spike (ou talvez até um tracer bullet) primeiro para compreender melhor o que precisa ser feito.

Ok, vamos encerrar…

Assim, para resumir: descubra o risco antecipadamente para minimizar desperdícios. Fazer isso não o torna menos Ágil. É apenas bom gerenciamento de projetos.

* Em seu ótimo livro sobre os princípios Agile, Bob Martin dá um exemplo bastante ilustrativo de Emergent Design ao implementar um placar de jogo de boliche.

?

Texto original disponível em http://tatiyants.com/risk-and-waste-on-agile-projects/