Uso uma metodologia ágil (SCRUM) há cerca de três anos e vejo algumas vantagens, especialmente no feedback de curto prazo em vários níveis (de clientes com acesso antecipado aos recursos implementados, de testadores que podem testar recursos como assim que são implementados, de outros desenvolvedores que podem fornecer feedback muito cedo sobre o novo código por meio de revisão etc.).
Por outro lado, tenho dois problemas em aberto, o primeiro dos quais tentarei explicar nesta questão.
Problema: dificuldade para obter um bom design
Tento fazer a refatoração assim que o código fica confuso, escrevo testes de unidade o máximo que posso (o que ajuda a evitar erros em geral e ao refatorar em particular). Por outro lado, desenvolver um recurso complexo em pequenos incrementos, com confirmações diárias e repensar continuamente o código quando ele é desestruturado, não está me permitindo produzir um design realmente bom.
O único módulo bem projetado que eu pude produzir recentemente obtive usando uma abordagem diferente: analisei o problema por alguns dias (na verdade, tive o problema em minha mente por alguns meses antes de começar a trabalhar seriamente. ), esboçou um design bastante detalhado de todas as classes envolvidas e seus relacionamentos por mais alguns dias e depois me trancou em meu escritório e anotou todo o código trabalhando sem interrupção por cerca de três semanas. O resultado foi a melhor coisa que produzi há algum tempo, com pouquíssimos bugs que eram fáceis de localizar e corrigir, e com um design muito claro, que não exigia nenhuma alteração relevante desde então.
Até agora, achei muito mais eficaz obter uma visão geral do que quero fazer antes do que começar a escrever código em pequenos incrementos, na esperança de que a grande figura surja magicamente no processo. Com o meu melhor esforço, a abordagem de desenvolvimento de pequeno incremento sempre me levou a um design pior.
Pergunta : Alguém já teve uma experiência semelhante? Estou aplicando o SCRUM da maneira errada ou no que devo prestar atenção se desejar desenvolver em pequenos incrementos e ainda assim acabar com um software bem projetado? Ou devo agendar uma história de usuário de design antes de iniciar a codificação real? Isso é considerado uma boa prática, pelo menos para recursos mais complexos que a média?
EDITAR NOTA
Estou ciente do fato de que um bom design não é algo absoluto e não tem valor por si só, mas depende do contexto, e que se deve buscar um design que seja bom o suficiente para o problema em questão.
Por exemplo, eu não me importo (muito) com o bom design se tiver que implementar um componente simples que (1) esteja pronto o mais rápido possível, (2) será usado apenas uma vez, (3) não usado por outras partes do sistema (YAGNI).
Eu me preocupo com o bom design quando um componente (1) será usado várias vezes e em várias versões diferentes de um produto, (2) precisa ser mantido e estendido ao longo do tempo, (3) possui muitos outros componentes, dependendo dele .
The only well-designed module I could produce recently I obtained by taking a different approach-- Você respondeu sua própria pergunta. Você ainda precisa de um design inicial; você não pode esperar que um bom design simplesmente cresça organicamente a partir da refatoração. Não é assim que funciona.