BDUF… Uma prática a se evitar?

Depois de um longo período de férias, estou de volta para falar de um assunto que ainda é bem recorrente quando a questão é sobre desenvolvimento e também design. Hoje vamos falar do famoso Big Design Up Front, popularmente conhecido como BDUF.

Mas, pra início de conversa, o que é isso? Bom, nada mais é do que você trabalhar em todos aspectos de design do seu sistema antes de começar a desenvolver algo. Ou seja, você levanta todos os requisitos com seu cliente e, baseado neles, começa a projetar o sistema de cabo a rabo. Em seguida, cria um documento gigantesco detalhando as características dos elementos e, finalmente, inicia a parte de desenvolvimento. Esse mindset é muito comum na grande mentira do waterfall.

Essa ideia surgiu devido engenharia civil. O processo de desenvolvimento de software era baseado no ramo da construção civil, ou seja, como construir uma casa sem ter o projeto dessa casa, certo? Com o passar o tempo, essa visão foi sendo alterada, dando origem a diversos métodos e frameworks.

Particularmente, eu não gosto dessa forma de trabalho e acredito que ela tem muitas chances para fracassar. Vou listar alguns motivos a seguir:

numero-1

Acreditar que nada vai mudar.

Ora, se você vai projetar todos os detalhes antes de começar a desenvolver, deve assumir que o escopo do projeto é imutável e, como todos nós sabemos, isso praticamente não existe. Quando você tenta levantar todos os requisitos com seu cliente logo no início do projeto, esteja preparado para encontrar muitas dúvidas e incertezas por parte dele e do seu time também.

numero-2

Muitas dúvidas durante o desenvolvimento.

Nessa etapa, geralmente, não são todos os integrantes que participam desse processo. Então aquela documentação marota que você criou para servir de manual para o seu time, é esquecida logo no primeiro dia. O ser humano é preguiçoso por natureza. Trabalho com projetos desde 2009 e, como já vi muito por aí, um time separado de design entrega umas telas “prontas” para um time separado de desenvolvimento e espera que as regras sejam seguidas. O resultado disso é: comportamento diferente do que foi projetado, bugs emergentes, passar a maior parte do tempo corrigindo bugs e cliente insatisfeito.

Documentação desatualizada.

A primeira mudança, depois de projetar tudo, é muito dolorosa. Você tem que atualizar seu documento de design e avisar para o restante sobre as mudanças. Nos primeiros dias isso pode não ser tão traumático, mas depois de uma ou duas semanas seu documento de design está desatualizado e ninguém vai querer ajeitar isso. Nem mesmo você, acredite.

numero-4

Desperdícios a vista.

Em projetos de software, as mudanças no backlog são comuns e o scrum se adapta com isso nas constantes inspeções durante as cerimônias. Ou seja, conforme o time entrega as partes do software para seu cliente, boa parte dos últimos itens do backlog são descartados. Isso acontece devido a mudança de prioridade, por parte do cliente, após a entrega. Para organizar isso, temos o trabalho de FDP (Fatiar, Descartar e Priorizar) do PO.

Agora imagine você, projetou e documentou todo o seu backlog e, no final, acabou que algumas funcionalidades foram completamente descartadas. O que fazer? Deitar no chão em posição fetal e chorar. Lembre-se sempre: tempo é dinheiro!

Porém, conversando com alguns amigos no canal #AgileUX sobre o tema, Sergio Giraldo falou sobre o lado bom em usar o BDUF. De acordo com ele:

Há cenários em que BDUF é válido, especialmente relacionado à arquitetura do sistema/software. Quando você estuda os riscos arquiteturais e nota que a indefinição é um blocker, vale fazer BDUF. Ou, em um conceito mais recente (~5 anos), Adaptable Design Up Front.

Ora, isso fez sentido para mim. Outro cenário em que precisei aplicar foi recentemente, inclusive. Trabalhei em um projeto onde o perfil do cliente era muito visual, sendo assim, ele queria ter uma ideia da tela antes de começar o desenvolvimento. Tivemos um início bem turbulento e, no meio do caminho, decidimos utilizar o BDUF. Apesar do atraso e prejuizo, aparentemente, o projeto fluiu melhor.

Esses foram alguns pontos que me vieram enquanto escrevia o post. Como falei no início do post, não sou muito a favor dessa prática. Prefiro trabalhar com o Design Emergente, ou seja, ir construindo pouco a pouco, junto com todos os stakeholders do projeto. Mas, deixo claro que não existe bala de prata. Não vou entrar no mérito de uma prática ser ou não melhor que a outra. Isso varia muito do contexto em que você se encontra. Esses pontos foram baseados na minha experiência.

Deixo claro também que esse conceito não é específico apenas do Design. Encontramos ele na área de desenvolvimento também.

E vocês? Quais foram as suas experiências o BDUF? Conta pra gente nos comentários!

Grande Abraço.

Mostrando 2 comentários
  • Responder

    Fala Diogo blz, muito bacana essa expressão nunca tinha ouvido falar de BDUF, posso ter escutado de outra forma, Termo de abertura de projeto? sei lá, são tantos os termos que ficamos até perdidos 🙂

    Realmente é muito difícil aplicar isso em um projeto caótico “Imprevisível” como o desenvolvimento, acredito que é mais aplicado em um ambiente previsível!

  • Bruno
    Responder

    Legal o post Diogo! Muitas vezes pessoas acabam aplicando o BDUF até mesmo em projetos pessoais e esse é um dos grandes motivos de falha desses projetos. Escrevi um post a respeito disso…

Deixe um Comentário

Comece a digitar e pressione Enter para pesquisar

lavar-roupa-suja