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

Este post não tem tags.

Compartilhe:

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.

Escute o artigo sobre BDUF. Dê o play!

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.

Entenda o BDFU

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

Sobre o autor(a)

Consultor, Trainer e Cofundador da K21

Rodrigo de Toledo é co-fundador da K21, Certified Scrum Trainer (CST) pela Scrum Alliance, Kanban Coaching Professional (KCP) e Accredited Kanban Trainer (AKT) pela Kanban University, além de Licensed Management 3.0 Facilitator. Com Ph.D na França, possui diversos artigos internacionais e lecionou por doze anos na PUC-Rio e na UFRJ, duas das principais universidades da América do Sul.

Artigos relacionados

Um pouco do que foi o evento Product to Rescue em 9 de Julho 2024   Foco no problema Manter o foco no problema pode ser Old School mas ainda está em alta. Ficamos muito presos em problemas inexistentes ou…

Após terminar de ler o livro Ruído de Daniel Kahneman, decidi reler alguns clássicos que não olhava há algum tempo. Dentre eles, Rápido e Devagar do mesmo autor e Pensando em Sistemas de Daniela Meadows. Não pude deixar de perceber…

O Guia do Scrum fala sobre o refinamento do Product Backlog: “O Product Backlog é refinado conforme necessário” (p. 9). Todavia ele não descreve exatamente o que é o refinamento. Uma reunião, uma atividade, um processo. Neste artigo vamos jogar…

Marcos Garrido, Sócio-fundador e Trainer na K21

Existem muitas formas de organizar as métricas de seu produto / empresa. Aqui neste blog já escrevemos sobre as Métricas do Pirata, Fit For Purpose (F4P) e Métricas nas Quatro Áreas de Domínio da Agilidade. Todavia, agora, queremos falar sobre…