BDUF ou Big Design Up Front surgiu como uma prática para colocar ordem no caos. Olá, desenvolvimento ágil?
Os softwares que, eram desenvolvidos sem processo definido e com desorganização, causavam terríveis impactos em sistemas, como inúmeros bugs aparecendo.
As pessoas faziam incontáveis horas extras, com a pressão descendo a pirâmide da hierarquia da empresa e destruindo qualquer ponto de tranquilidade.
E claro, causando mais danos do que ajudando na entrega.
Para pôr ordem, com o tempo, foram definidos processos e assim, foram evoluindo de modo que outros processos emergiram formando modelos.
Um desses modelos é o cascata, muito famoso entre 1990 e 2000.
O objetivo deste artigo não é discutir sobre modelos de desenvolvimento.
Um problema desse modelo é o engessamento e falta de adaptabilidade das mudanças de requisitos do sistema e, consequentemente, a descoberta de negócio, onde muitos tipos de produtos eram impactados negativamente.
Desenvolvimento ágil
Então, em 2001 emergiu o modelo ágil com suas interações rápidas de pequenas entregas e constante contato entre cliente e equipe de desenvolvimento.
Mas o que diabos é o desenvolvimento ágil?
O desenvolvimento ágil é uma constatação percebida por desenvolvedores de software, de que, nem tudo relacionado à engenharia de software está nos livros tradicionais, principalmente quanto aos riscos envolvidos.
Estes profissionais, na maioria veteranos, no início de 2001 se reuniram durante um workshop em Utah, EUA e construiram as bases do Manifesto para o Desenvolvimento Ágil de Software, mais conhecido como Manifesto Ágil.
Basicamente, o desenvolvimento ágil é a filosofia que se utiliza dos princípios contidos neste manifesto.
Saiba mais sobre o Manifetso Ágil.
Hoje, ele é mainstream (posso chamá-lo de mainstream?) e o modelo cascata caiu em forte desuso e associado a BDUF.
O que significa BDUF na prática?
Posso resumir como o planejamento detalhado e minucioso, antes mesmo de conhecer os detalhes e incertezas que o projeto irá passar.
Por exemplo:
- Uma grande funcionalidade inteira projetada seu funcionamento antes de qualquer validação e processo de descoberta junto ao cliente;
- Detalhamento de planejamento de entregas muito longos;
- Decidir toda uma pilha de tecnologia no início do projeto. Sem ter a garantia que irá atender as necessidades, porque ela está na moda ou outro motivo;
- Documentar as funcionalidades antes mesmo de estar pronta.
Mesmo que muitos desenvolvem projetos com desenvolvimento ágil, ainda acabam em situações BDUF.
O que me faz pensar em alguns grandes problemas do BDUF:
- O timing de executar as tarefas.
Em algum momento será necessário decidir tecnologias, documentar funcionalidades.
É importante destacar que, mesmo em modelos ágeis, documentar pode ter um grau de importância, como discuti nesse post.
- Mapear comportamentos.
Mas, se essas etapas foram “adiantadas”, poder causar desperdício e queremos otimizar valor e o nosso sagrado tempo e claro, também ganhar velocidade de entrega.
Além de que acaba impactando em decisões de projetos baseado em incertezas, como escolher as tecnologias com baixo domínio ao invés de utilizar provas de conceitos para adquirir mais conhecimento.
Mas você deve estar pensando:
“Ahhh, mas precisamos já ter em mãos o que vamos desenvolver, porque queremos entregar logo”.
Não se preocupe! O projeto fica parado enquanto é adquirido conhecimento. 🙂
Caso tenha que começar a escrever essa parte do sistema, isole-a. Mocks de produção também podem ser utilizados para simular respostas da tecnologia.
Uncle Bob e outros parceiros, que escreveram o software Fitnesse, não sabiam qual tecnologia utilizar para persistência de dados.
Então, criaram mocks para o sistema ser funcional enquanto adquiriram conhecimento do problema que queriam resolver.
No fim, acabaram escolhendo criar persistência no sistema de arquivos do que utilizar a tecnologia inicial que tinham pensado.
Qual será o resultado se criar recursos que o cliente não irá utilizar? Ou que está distorcido que não atende a sua realidade?
A resposta para estas perguntas é: um monte de desperdício! Vai no caminho inverso do desenvolvimento de software Lean (que é assunto para outro artigo).
Identificando o que está fazendo o BDUF
Planejar artefatos de entrega baseado em dúvidas, como fazer POC pode resolver, quanto maior a quantidade de dúvidas mais complexo fica o planejamento.
O mais nebuloso é a solução, é como dirigir sem GPS por um local desconhecido, você poderá ir em lugares que não gostaria.
Na ânsia de ver software pronto ou paralelizar trabalho, podemos acabar criando um documento de como o software funcionará porém, requisitos mudam com a evolução.
Sejam influenciados pelo cliente final, profissionais de produto ou até desenvolvedores de software.
Já tive que descartar documentos de utilização de uma API Rest que ficou pronta antes do desenvolvimento pela quantidade de modificações que acabou sendo impactada no resultado final.
O BDUF seria uma prática ruim?
Algo que teria que ser descartado?
Existem locais que há valor na metodologia, arquitetar um novo projeto de software pode ganhar muito com BDUF, tomando cuidado com adoção de tecnologias, como já foi discutido acima.
Há pontos que é preciso visualizar e planejar algo além da primeira entrega de projeto que pode ser vital para evitar refatorações ou retrabalho.
Podendo entregar uma visão a longo prazo melhor que software orientado a processo ágil é muito mais focado em uma visão mais curta.
Projetos de escopo fechado que deverão seguir requisitos técnicos e protocolos homologados como software militares, no qual metodologias ágeis apenas atrasaria o desenvolvimento devido a várias cerimônias que possui.
“Big design up front is dumb, but doing no design up front is even dumber”.
– Dave Thomas
Como Dave Thomas nos diz, não ter nenhum planejamento é muito pior que BDUF rodando para resolver alguma tarefa.
Basear-se unicamente em feeling e experiência, sem lidar com inúmeras variáveis que rodeia o planejamento, é ter a receita do fracasso e isso pode ser suficiente para afundá-lo no mar do desperdício de tempo e dinheiro.
Ou seja, se tiver entre BDUF e NODUF (no design Up Front), vai de BDUF!
Devemos manter monitorando o nosso comportamento para evitar cair no emaranhado do BDUF.
Algumas vezes, só identificamos depois de horas de esforço gasto com etapas que poderiam ter sidos postergadas.
Então, trago alguns passos resumidos e que possam ajudar a evitá-lo:
- Documentar feature na última etapa do processo.
- Postergar decisões tecnologias o quanto puder.
Quanto mais conhecimento da jornada do produto, terá uma visão melhor sobre o todo. E ainda pode evitar de colocar microserviços e kafka em toda a oportunidade.
- Evite planejamento e replanejamento.
Como inúmeras reuniões, manter os stakeholders próximos com entregas frequentes para adquirir feedbacks o mais rápido possível e ainda, software alinhado com a expectativa.
Ficar longe de “BDUFagens” em cenários que necessita uma visão ágil é uma grande ideia pelo nível de esforço que é exigido.
E aí, bora evitar? 😉
Crie um perfil, conheça as oportunidades e receba propostas alinhadas ao seu perfil. São mais de 1000 vagas para desenvolvedores como você!
