Combinação certa de planejamento e programação em um novo projeto

Estou prestes a iniciar um novo projeto (um jogo, mas isso não é importante). A ideia básica está na minha cabeça, mas nem todos os detalhes.

Não quero começar a programar sem planejar, mas estou lutando seriamente contra o desejo de fazê-lo. Quero um planejamento antes para evitar a refatoração de todo o aplicativo, apenas porque um novo recurso em que eu poderia pensar exige isso. Por outro lado, não quero planejar vários meses (tempo livre) e começar com isso porque tenho medo de perder minha motivação nesse período.

O que estou procurando é uma maneira de combinar os dois sem que um domine o outro. Devo realizar o projeto no caminho do scrum? Devo criar histórias de usuários e depois realizá-las? Devo trabalhar orientado a recursos? (Eu tenho alguma experiência em scrum e o modo clássico "especificação para codificar".)

Atualização : Que tal começar com um "clique fictício" e implementar a funcionalidade posteriormente?

Você está no caminho certo. Não há necessidade de passar meses planejando, mas você definitivamente deve ter algum tipo de plano.

O planejamento o ajudará a organizar seus pensamentos, identificar as tecnologias de que você precisa, esclarecer os pontos problemáticos e fornecer um roteiro para o trabalho a partir do qual você pode se dividir em objetivos mensuráveis.

Além disso, você pode planejar alguns dias apenas para descobrir que isso é uma perda de tempo. Talvez durante o planejamento, você perceba que está fora do seu alcance ou que o que está tentando fazer não pode ser comercializado. É melhor descobrir isso agora, para que você possa reinvestir seu tempo em outras idéias que possui, em vez de seguir esse caminho apenas para se perder na floresta, cercado por trepadeiras de código e trilhas de lógica falível que distorcem seu cérebro em nós.

Planeje o produto mínimo viável e implemente-o. Em seguida, ouça seus usuários e planeje o próximo aprimoramento lógico e implemente isso. Repetir.

Não importa quanto tempo gaste no planejamento e no design do seu programa, você sempre acaba reescrevendo partes dele de qualquer maneira. É como a gravidade, não é inteligente negar sua existência.

É preciso perceber que a refatoração é uma parte normal do desenvolvimento e é apenas uma questão de decidir quando você o faz. Espere muito tempo e você acabará com enormes quantidades de espaguete, implorando por uma reescrita completa. Não é engraçado.

Minha sugestão é planejar um pouco, mas comece a codificar o mais rápido possível e refatorar, refatorar, refatorar para manter o código em forma. O princípio DRY (não se repita) é um ótimo indicador para isso.

Quando estou nessa posição, às vezes faço uso do TDD (desenvolvimento orientado a testes) e começo a planejar alguns testes para a parte mais complexa do sistema que estou desenvolvendo. Como alternativa, posso reunir algum pseudo-código de alto nível, novamente para as áreas mais complexas. Acho que esse processo me fornece um plano de ação amplo e ajuda-me a identificar quais áreas provavelmente são as que consomem mais tempo.

Para mim, essa abordagem funciona porque vive em algum lugar entre codificação e planejamento. Depois de ter suas idéias de teste e / ou pseudo-código, você pode trabalhar em cada seção lógica e implementar o código. Costumo abordar primeiro a parte mais difícil de uma solução proposta, porque normalmente a parte mais difícil é o principal recurso do aplicativo e você sempre pode atrasar qualquer aviso.

Como você comenta que a maior parte do código está na sua cabeça e está pronto para mergulhar e programar, usar essa abordagem pode ajudá-lo a se concentrar em cada seção sem que sua mente fique obscurecida pelo sistema como um todo.

Para resumir de forma mais sucinta, pode-se dizer "enfrentar a parte mais difícil primeiro, dividir e conquistar, com pseudo-código e / ou planos de TDD"!

Apenas tente fazer o código modular. Qualquer outra coisa que você planejar provavelmente será descartada durante a próxima iteração.

Eu recomendaria escrever suas idéias, no mínimo. Dependendo do tamanho do projeto, muito planejamento formal pode não ser necessário. Se, no entanto, é muito grande, convém evitar uma dor de cabeça e passar alguns dias fazendo um planejamento mais aprofundado.