Como obter um bom design ao usar métodos ágeis?

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 .

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.

Então não faça isso.

Nem tudo se encaixa na bela caixa ágil. Muitas vezes, um produto tem algumas coisas complexas que não podem ser criadas por indivíduos e não podem ser concluídas de maneira sadia dentro de um sprint. Forçá- los a entrar nessa caixa só causará problemas. Mas estes devem ser poucos e distantes entre si. Se você achar que muitos de seus componentes são assim, o proprietário do produto precisa trabalhar para melhorar as coisas (com sua equipe). Estou bem em fazer o que você fez: pegue a história, projete-a e depois martele-a o mais rápido possível, com a expectativa de que levará algumas semanas.

No caso mais geral, há três coisas que eu vi para obter um bom design no Agile:

• Na verdade, crie um design - muitos lugares que eu vi começar seu sprint e apenas começar a criar código de cowboy. Você terá um design ruim dessa maneira. O Agile não altera o processo de desenvolvimento do plano - código - teste - lançamento, apenas o reduz para partes mais granulares. No início do sprint, sente-se conforme necessário e crie a sua solução.

• Tenha um arquiteto / líder - assim que seu projeto for grande o suficiente, você terminará com várias equipes de scrum trabalhando em diferentes partes do aplicativo. É muito útil ter alguém (ou várias pessoas, dependendo do tamanho do aplicativo) cujo trabalho principal é saber o que todas as equipes estão fazendo do ponto de vista do design. Eles podem responder perguntas e orientar as equipes em direção a um design mais abrangente e abrangente. Cada equipe de scrum tem uma liderança que sabe a maior parte do que as outras equipes estão fazendo. Também vi e foi muito eficaz.

• Seja um pragmático - eu cobri este acima. Agile é uma ferramenta, e como qualquer ferramenta; não se aplica a todos os problemas. Se não faz sentido aplicar a algum componente, não o aplique lá. Seu objetivo é enviar um bom software; não esqueça isso.

É muito possível implementar em pequenos incrementos e acabar com um código de manutenção bem estruturado. Em teoria, é muito simples: se você garantir que o código esteja bem estruturado após cada alteração, ele sempre será bem estruturado. Seu código está se tornando mal estruturado porque você continua adicionando código quando deveria refatorar.

Não importa quanto tempo você gaste no design, eventualmente os requisitos serão alterados de maneira imprevista e você precisará escrever um código que não se encaixe no design original. Então você terá que fazer uma alteração incremental. Se você tiver um bom conjunto de testes de unidade e tiver habilidade em refatoração, poderá manter o código bem estruturado à medida que atender aos novos requisitos.

"Bem desenhado" é subjetivo

O que faz "bem desenhado" significa para você? para o proprietário do produto? Para o consumidor?

É "bem desenhado " um objetivo do proprietário do produto? um objetivo do cliente? ou apenas você?

O que você considera "não bem projetado" ainda atende às expectativas dos Proprietários do Produto e faz o cliente feliz? Então isso é muito "bem desenhado" .

Bom o suficiente e YAGNI

Nada na maioria das metodologias ágeis fala de "bem projetado", porque qualquer sistema que o Dono do produto aceita as histórias como completas e os clientes acreditam que atende a seus requisitos é "bem projetado" .

Espera- se que os desenvolvedores sejam profissionais e usem pragmaticamente as melhores práticas, designs e expressões apropriadas para implementar os recursos e as histórias.

Se você não considerar o momento de fazer as coisas corretamente, isso é um problema do desenvolvedor, se o Dono do produto exigir coisas em menos tempo que isso possa ser feito, é sua prerrogativa fazer isso e sua responsabilidade de educá-los sobre o problema. consequências na forma de dívida técnica histórias de .

SCRUM

_{A metodologia Agile que pode ser escrita, não é a metodologia Agile. "- Jarrod Roberson}

O SCRUM deveria ser uma estrutura de ferramentas para gerenciar o ciclo de vida total de um produto de software. Não é para ser um conjunto rígido de coisas, apenas um bom lugar para começar e, com sorte, melhorar.

A maioria das lojas em que trabalhei tem o que é chamado Sprint ZERO, Sprints para os membros seniores da equipe esboçarem uma arquitetura ou tema geral do produto.

Histórias maiores do que 20 dizem que geralmente são divididas até que sejam realmente algumas histórias de 3 a 5 pontos. Uma dessas histórias é: "Como equipe, precisamos nos reunir para discutir como vamos projetar esse recurso, para que tenhamos o mínimo de dívida técnica possível, considerando o tempo alocado".

Geralmente

Em geral, um sistema "bem projetado" é bom o suficiente e segue o YAGNI.

O Agile e o SCRUM, em particular como uma implementação do Agile, são mais sobre como produzir um produto da maneira mais transparente possível para o Dono / Patrocinador do produto.

Não se trata de nada de design técnico / arquitetura. É mais uma filosofia sobre como abordar a entrega de software que atenda às necessidades e expectativas dos clientes. Se não houver o que você chama de partes "bem projetadas" , isso não é uma falha per se, pois não é uma parte fundamental da filosofia.

Trabalhamos com o scrum há vários meses e quero compartilhar minha experiência com seu problema.

Alguns meses atrás, recebi um grande pedaço para implementar. Eu tinha todas as especificações prontas, então tive que implementar novos recursos de acordo. A tarefa era levar de 5 a 6 semanas (como eu calculei). Passei a primeira semana trabalhando apenas no design. A tarefa era um pouco complicada: havia um objeto principal que, como concluí da especificação, tinha 15 estados diferentes, e a interface do usuário deveria ter comportamentos diferentes para cada estado.

Projetei todo o fluxo de trabalho e a estrutura e as classes do banco de dados posteriormente.

Não vejo outra abordagem no meu caso. Se eu mergulhasse na codificação de uma só vez, teria uma grande confusão no final - quase impossível de manter e extremamente difícil de fazer outras alterações. Mas as mudanças ocorreram nas próximas duas semanas, então tive que refazer o código. Isso era fácil agora, com o design pensado inicial. Isso economizou nosso tempo, dinheiro e nervos.

Após essa experiência, tenho certeza absoluta de que vale a pena fazer um design aceitável no começo, do que esperar que, com algum milagre, você o consiga no final.

A visão traseira é 20-20. Se você tiver as informações à sua disposição no início do projeto para descobrir tudo e depois escrever o código em algumas semanas, sugiro que você faça isso.

Você não está dando crédito suficiente a todas as informações que obteve, as abordagens que foram tentadas e falharam / tiveram que ser alteradas e a capacidade aumentada do cliente / usuários de fornecer crédito suficiente aos requisitos.

Por que alguém com um histórico de projetos bem-sucedidos de queda de água mudaria para uma metodologia ágil?

Você sempre precisa de uma imagem maior de qual deve ser o objetivo final e quais recursos devem ser implementados e quando, antes de iniciar um projeto. Trabalhar em histórias como tarefas atômicas está causando problemas. Você precisa manter em mente os requisitos futuros o máximo possível.