Combinación correcta de planificación y programación en un nuevo proyecto

Estoy a punto de comenzar un nuevo proyecto (un juego, pero eso no es importante). La idea básica está en mi cabeza pero no todos los detalles.

No quiero comenzar a programar sin planificar, pero estoy luchando seriamente contra mi impulso de hacerlo. Quiero un poco de planificación antes para evitar la refactorización de toda la aplicación solo porque una nueva característica que se me ocurre lo requiere. Por otro lado, no quiero planificar varios meses (tiempo libre) y comenzarlo porque tengo miedo de perder mi motivación en este momento.

Lo que estoy buscando es una forma de combinar ambos sin que uno domine al otro. ¿Debo realizar el proyecto en forma de scrum? ¿Debo crear historias de usuario y luego darme cuenta? ¿Debo trabajar con funciones? (Tengo algo de experiencia en scrum y en la clásica forma de "especificación para codificar").

Actualización : ¿Qué tal comenzar con un "clic ficticio" e implementar la funcionalidad más tarde?

Estás en el camino correcto. No hay necesidad de pasar meses planeando, pero definitivamente debes tener algún tipo de plan.

La planificación lo ayudará a organizar sus pensamientos, identificar las tecnologías que pueda necesitar, aclarar los puntos problemáticos y darle una hoja de ruta para trabajar desde la que pueda dividir en objetivos mensurables.

Además, puede planificar unos pocos días solo para descubrir que esto es una pérdida de tiempo. Tal vez mientras planifica, se da cuenta de que está fuera de su alcance o que lo que está tratando de hacer no puede comercializarse. Es mejor descubrirlo ahora para que pueda reinvertir su tiempo en otras ideas que tenga, en lugar de ir por este camino solo para perderse en el bosque, rodeado de enredaderas de códigos fibrosos y rastros de lógica falible que tuercen su cerebro en nudos

Planifique el producto mínimo viable e impleméntelo. Luego escuche a sus usuarios y planifique la próxima mejora lógica e implemente eso. Repetir.

No importa cuánto tiempo dedique a planificar y diseñar su programa, siempre termina reescribiendo partes de él de todos modos. Es como la gravedad, no es inteligente negar su existencia.

Uno debe darse cuenta de que la refactorización es una parte normal del desarrollo y es solo una cuestión de decidir cuándo hacerlo. Espere mucho y terminará con grandes cantidades de espagueti, rogando por una reescritura completa. No es divertido.

Mi sugerencia es planificar un poco pero comenzar a codificar lo antes posible y refactorizar, refactorizar, refactorizar para mantener el código en forma. El principio DRY (no te repitas) es un gran indicador de eso.

Cuando estoy en esta posición, a veces uso TDD (desarrollo basado en pruebas) y comienzo a planificar algunas pruebas para la parte más compleja del sistema que estoy desarrollando. Alternativamente, puedo armar un pseudocódigo de alto nivel, nuevamente para las áreas más complejas. Creo que este proceso me da un plan de acción flexible y me ayuda a identificar qué áreas son las que más tiempo requieren.

Para mí, este enfoque funciona porque vive en algún lugar entre la codificación y la planificación. Una vez que tenga sus ideas de prueba y / o pseudocódigo, puede trabajar en cada sección lógica e implementar el código. A menudo abordo primero la parte más difícil de una solución propuesta, porque generalmente la parte más difícil es la característica principal de la aplicación y siempre puede retrasar cualquier campana y silbato.

Dado que comenta que la mayor parte del código está en su cabeza y que está listo para sumergirse y programar, usar este enfoque puede ayudarlo a concentrarse en cada sección sin que su sistema se enturbie por completo.

Para resumir de manera más sucinta, uno podría decir "aborde primero la parte más difícil, divida y conquiste, con pseudocódigo y / o planes TDD".

Solo intenta hacer que el código sea modular. Es probable que cualquier otra cosa que planee se descarte durante la próxima iteración.

Recomendaría escribir sus ideas por lo menos. Dependiendo del tamaño del proyecto, es posible que no se requiera mucha planificación formal. Sin embargo, si es muy grande, puede ahorrarse un dolor de cabeza y pasar un par de días haciendo una planificación más profunda.