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

10

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?

project-management agile

— WarrenFe
fuente

5

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

— jmort253
fuente

La plataforma de orientación es mi trabajo diario, por lo que conozco la mayoría de las tecnologías que quiero usar. Creo que usaré scrum simple y un plan básico. Entonces puedo comenzar con algunos retrasos y hacer el planeamiento en cada iteración.

— WarrenFaith

Sigues deletreando "planeando" mal. Solo pensé en señalarlo ya que no puedo editar tu comentario :) Pero sí, creo que scrum es un gran enfoque, mantiene la flexibilidad y te da la oportunidad de decidir si vale la pena el esfuerzo para continuar el proyecto.

— jmort253

Oo En alemán es al revés: planificación con una n y programación con dos m ...: D ¡Gracias!

— WarrenFaith

@WarrenFaith - ¡Lo siento! ¡Ese es mi etnocentrismo saliendo! Gracias por señalar mi error;)

— jmort253

11

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.

— Steven A. Lowe
fuente

3

.... y cada vez que tenga una idea de algo que cree que sería genial, simplemente escriba la idea en el registro de Scrum-backlog, pero no la implemente hasta que se haga el producto mínimo viable.

— k3b

la pregunta principal aún es qué tan profundo debería planearlo. Si pudieras darme ese consejo, también, recibirías la respuesta aceptada.

— WarrenFaith

1

@WarrenFaith: características - >> historias - >> casos de prueba.

— Steven A. Lowe

4

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.

— Martin Wickman
fuente

Gracias por su respuesta. Sé que la refactorización no es nada inusual, pero no quiero evitar la refactorización causada por la planificación fallida.

— WarrenFaith

@Warren: no planificar no evita la refactorización. Puede codificar la solución en la computadora o intentar codificarla en su cabeza o en papel. Creo que ambos son ineficaces. Comience a codificar, sabiendo que lo cambiará más tarde.

— Kevin Cline

@kevin cline: Ok, hagamos la diferencia entre refactorizar el código existente para una nueva característica o mejoras y reescribir casi toda la aplicación para una nueva característica. Puedo vivir con el primero, no realmente con el segundo ..

— WarrenFaith

@WarrenFaith: siempre y cuando el código esté ajustado y en forma, debería poder evitar reescrituras. El único momento en que he visto reescrituras es cuando el sistema se ha convertido en una gran bola de lodo (sin refactorización), o un cambio técnico fundamental (cambio de plataforma).

— Martin Wickman

3

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".

— BradB
fuente

No soy fanático de TDD pero gracias de todos modos!

— WarrenFaith

No estoy diciendo necesariamente que use TDD, mi punto es que es algo que uso como estructura para "planificar" mi código. De esa manera, no estoy saltando directamente a escribir mi código y no paso mucho tiempo escribiendo documentos masivos / planes de proyectos que están demasiado lejos de la codificación real. Se trata de encontrar el medio feliz. En principio, puede lograr lo mismo con un lápiz y papel. También debo señalar que no escribo una prueba para TODO, solo las áreas más complejas.

— BradB

3

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.

— davidk01
fuente

2

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.

— Kenneth
fuente