BDUF: A arte de fazer coisas que não deveriam ser feitas

BDUF é um acrônimo (Big Design Up Front) usado para indicar que todo o desenho da solução é feito antes da execução. Isso é algo bem típico no modelo tradicional de desenvolvimento de software, onde há explicitamente uma etapa de Análise que antecede a etapa de implementação. Assim, no final das contas, BDUF é arte das coisas que não deveriam ser feitas.

Nos anos 90, os sucessivos fracassos em projetos BDUF impulsionaram a criação de novos métodos de desenvolvimento, tal como o Scrum. Com o surgimento do Movimento Ágil em 2001, a crítica a essa grande antecipação do planejamento passou a ser mais contundente. O Chaos Report de 2002 foi acompanhado da constatação de que, mesmo em projetos considerados de sucesso (prazo e custos cumpridos de acordo com o planejado), o percentual de itens úteis era extremamente baixo.

Hoje em dia, com a expansão dos métodos ágeis, não há mais uma longa etapa de análise, porém, ainda vemos muitas atitudes BDUFeiras nas empresas.

Exemplos de BDUFagens:

Em desenvolvimento de produto:

  • Design Thinking de 6 meses.
  • User story mapping com dezenas de histórias.
  • Desenho de todas as telas do sistema para só então implementá-lo.

Em desenvolvimento de software:

  • Criação de toda uma API de serviços para depois pensar na aplicação.
  • Pensar na melhor arquitetura possível, às vezes chegando ao absurdo de nem olhar mais para o objetivo daquele produto.
  • Parametrização de todas as variáveis, antes mesmo de existir tal demanda.

 Em outras áreas:

  • Marketing BDUFeiro é aquele que faz grandes lançamentos de uma campanha em diversas mídias simultâneas, sem fazer nenhuma experimentação da aceitação do público. No marketing mais moderno, a propaganda está cada vez mais se direcionando para ser uma ação continuada com o uso de mídias digitais.
  • UX (User eXperience ou experiência do usuário) também é uma atividade que se não ficar atenta, pode facilmente BDUFar. Por exemplo, há empresas que passam meses traçando todos os perfis de usuário, considerando exceções e padrões que nem representam 1% do público de interesse ou do valor do produto. Hoje em dia, Design Thinking que dura 6 meses, ao final tem que começar tudo de novo, porque o mundo em volta já mudou. Nós acreditamos no Agile Design Thinking!

BDUF na vida: 

Às vezes vemos pessoas que planejam em excesso ou com muita antecedência na ilusão de que podem ter o controle sobre tudo o que irá acontecer. Por exemplo:

  • pessoas que planejam todos os detalhes de uma viagem a lazer, mas que se frustram com situações imprevisíveis;
  • pessoas que decidem que para encontrar um par amoroso precisam, no primeiro ano, entrar na academia, no ano seguinte aprender a dançar, para depois começar a frequentar boates.

Como deixar de ser BDUFeiro:

Antecipe resultados!

  • Evite o Jaque. É o famoso “já que”: já que estamos criando esse novo campo na tabela de dados, vamos aproveitar para colocar outros possíveis campos. Já que vamos mexer nesse código, vamos então fazer o refactoring completo. Toda vez que alguém invocar o “já que”, reflita se não é uma atitude BDUFeira.
  • Planejamento respeitando a analogia do horizonte.
  • Fatiar. Diante de um grande problema, ao invés de quebrar em pedaços técnicos, devemos fatiar. Ou seja, dividir algo a ser feito em pedaços menores que ainda agregam valor. Além de evitar o BDUF, há inúmeras vantagens em fatiar, por exemplo, o aumento do foco onde realmente está o valor.
  • Construa soluções incrementais e arquiteturas emergentes.

Experimente na prática!

  • A cultura da experimentação é uma das mudança mais impactantes quando as empresas passam a implementar Métodos Ágeis. Quando se entende que sempre estamos fazendo experimentos, há menos pressão para a solução perfeita no início de qualquer iniciativa.
  • “Não existe reuso sem uso”. Várias vezes as pessoas querem justificar o BDUF para evitar um futuro “retrabalho”. Porém, antecipam um trabalho antes mesmo que haja algum benefício daquilo que está sendo feito. Ter uma boa arquitetura é importante, mas ela deve ser enxuta, focada nas próximas entregas de valor, no que chamamos de arquitetura emergente. Recomendamos a prática de “refactoring” para aumentar o reuso de código, mas primeiro se deve focar no uso.
  • 1,2,N. O padrão 1,2,N se aplica para quando resolvemos o problema para uma situação, depois para uma segunda e então para N. Este assunto merece um post por si só.
Por |2018-09-16T18:33:01+00:0014 de junho, 2017|Desenvolvedor, eXtreme Programming, Scrum, Software Ágil, Técnico|

Sobre o Autor:

Rodrigo é instrutor internacional da Scrum Alliance (CST), Kanban Coaching Professional (KCP), instrutor internacional da Lean Kanban University e facilitador certificado de Management 3.0. Com doutorado na França, possui diversos artigos internacionais e lecionou por doze anos na PUC-Rio e na UFRJ.