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ó.
