Metodologia ágil: rápida e suja ou planeje primeiro?

Pergunta ágil: o ágil acredita em fazer as coisas funcionarem da maneira mais rápida e suja - ou o ágil prefere construir solidamente desde o início? Ou isso não é uma questão de metodologia, e mais uma questão que você avalia caso a caso?

Tecnicamente, estou “refazendo” a base do sistema, depois que já construí grande parte da estrutura em si ... não é uma quantidade monumental de trabalho ... o Agile gostaria que eu especificasse primeiro todo o fluxo, analise-o, ajustá-lo e depois construir? Sinto que, de certa forma, é melhor assim ... depois de instalar um sistema bagunçado, vejo melhor como ele precisa ser feito ... por outro lado, não é tão organizado ... apenas curioso para saber o melhor desenvolvimento prática é nesse sentido.

Acredito que essa pergunta seja um pouco diferente de Agile e protipagem, pois não estou perguntando sobre prototipagem e código descartável; Estou interessado em agile para código de nível de produção.

A metodologia ágil é o primeiro plano. Simplesmente não é planejar tudo primeiro. Na verdade, você reúne requisitos, design, código, teste, implantação e presente. Você faz tudo isso em menos de uma quinzena (mais ou menos) no menor recurso que você pode implantar e obter feedback. Depois, faça tudo novamente adicionando outro recurso ou aprimorando um antigo.

A chave é escrever um código que aceite alterações, para que, quando você finalmente veja "como todo o fluxo deve ir", você possa alterar o código para fazer isso. Dessa forma, quando "o caminho que o fluxo deve seguir" (ou o que seja) muda mais uma vez, não é traumático.

Você não pode escrever rápido e sujo. Rápido e sujo fornece código ridgid. Seja rápido, trabalhando pequeno. Mantenha-se flexível, não espalhando conhecimento . Idealmente, qualquer alteração de recurso único deve impactar apenas um lugar no código.

Você não pode gastar muito tempo sem fazer nada além de planejar. Você pode planejar, mas precisa alterar o plano. Você precisa descobrir rapidamente os motivos para alterar o plano. Quando o planejamento está indo bem, sem surpresas para aprender, é quando o planejamento se prolonga por muito tempo. O planejamento e a codificação devem ocorrer próximos um do outro. Se você está aprendendo, quanto mais velho o plano, mais burro é.

A longo prazo, planeje ficar mais inteligente. Escreva um código flexível. Então, ficar mais inteligente não leva ao arrependimento.

Não gosto que para a maioria das pessoas seja "rápido e sujo" ou "grande design logo de cara". Eles nem sequer consideram que existem outras opções.

Agile é sobre a construção de um sistema, onde a mudança, mesmo no final do desenvolvimento, é trivial. Isso é feito construindo o software em pequenos pedaços incrementais e bloqueando o comportamento desses pedaços com testes automatizados robustos. E usando a implantação automatizada e frequente na produção para validar o valor dessas alterações.

Por ter testes automatizados robustos, torna-se trivial alterar até as partes mais difíceis da arquitetura, refatorando incrementalmente por períodos mais longos. Portanto, mesmo que você perceba que sua arquitetura poderia ser melhorada no meio do projeto, é realisticamente possível fazer a alteração relativamente rapidamente.

Algumas pessoas dizem que "alguns projetos logo de cara" são bons com o ágil. Mas se você pretende repetir esse design posteriormente, ainda precisará garantir que sua cultura de desenvolvimento produza um sistema fácil de mudar. Portanto, o "SDUF" não invalida a necessidade de testes robustos, refatoração agressiva e implantação contínua.

Ao criar "facilidade de mudança" no sistema, você não precisa pensar muito sobre o design inicial do seu projeto, pois isso pode ser alterado posteriormente. A abordagem "Rápida e suja", como muitas pessoas chamam de "pico", só é utilizável se você estabilizar os recursos que considera valiosos. Mas você não deve deixar pedaços de código hackeado em sua base de código por muito tempo, pois eles diminuem a velocidade.

Nem.

É "Comece simples e melhore enquanto você avança".

Rápido e sujo é quebradiço, mas rápido (se o projeto é suficientemente pequeno e tem vida curta).

O primeiro plano é rígido, mas estável (se o projeto for concluído antes de enfrentar restrições financeiras ou temporais).

O Agile é uma alternativa aos 2 acima. Ele se baseia em uma abordagem iterativa, na qual os recursos são concluídos um de cada vez, recurso por recurso, e o conhecimento adquirido ao concluir essas partes totalmente funcionais do programa é usado para detalhar e ajustar o plano à medida que o desenvolvimento avança. Para fazer isso, é necessário um planejamento antecipado - é necessário um planejamento pelo menos suficiente para estimar quanto trabalho os recursos individuais exigem - mas, como o Agile espera mudanças, um planejamento excessivo leva ao desperdício.

Uma das principais características do Agile é fazer iterações curtas e reavaliar. Você corre para explorar um novo território, aprende com ele e depois faz um plano. Dessa forma, seu plano será melhor. E se você falhar (a idéia de que o curso não funcione), você "falhou rapidamente", o que é bom.

Portanto, sua abordagem está correta. O perigo, porém, é dizer "Legal, funciona, já acabei. O que vem a seguir?". Você não terminou, existem muitos cantos cortados para endireitar e você deve ter tempo para fazê-lo corretamente, uma vez que esteja claro que sua abordagem gera um sistema funcional e viável. Isso pode ser escrever testes, documentar, StyleCop, otimizar, educar os colegas sobre o que você fez e como fez, revisar, etc.

Para adicionar às respostas acima, um princípio fundamental é o YAGNI . Se seu design e planejamento iniciais permitem a próxima etapa, tudo bem. Mas se isso permitir um passo hipotético futuro que você não pode provar que é necessário, assuma YAGNI.

Muito design, de cima para baixo e de baixo para cima, pressupõe que haverá uma reutilização significativa do código. A experiência diz que a reutilização de código simplesmente não é tão comum, porque você raramente resolve o mesmo problema. Se você precisar resolver uma variante desse problema no futuro, refate seu design no futuro para adicionar essa variante, mas não a considere agora.

Em outras palavras, planeje a tarefa imediata, mas não planeje nada mais adiante.