¿Se pueden producir documentos de planificación de forma retroactiva para que se ajusten al producto que se ha construido?

Actualmente estoy implementando una aplicación de Android y tengo problemas para hacer mis diagramas de clase y secuencia, principalmente debido al hecho de que las especificaciones son demasiado abstractas y vagas. Estaba pensando en hacer la fase de implementación y luego aplicar ingeniería inversa a mi trabajo para producir los documentos de planificación.

Mi pregunta es, ¿está permitido y es recomendable?

¿Entiendo correctamente que está preguntando si está bien desarrollar documentación y código a medida que trabaja y lo comprende mejor en lugar de tratar de documentar todo por adelantado?
@MarvMills Para que conste, ¡esto es gestión de proyectos! Estoy atrasado en un proyecto y una forma potencial era implementar la aplicación primero y luego volver a la fase de diseño, pero está bien, sé lo que estoy haciendo. No sé por qué incluso publiqué aquí en primer lugar cuando voy a ser recibido de esta manera.
No lo tomes como algo personal, solo estoy exponiendo hechos. Si está trabajando en un proyecto, debe preguntarle a su Gerente de Proyecto, Internet no puede responder esto por usted, solo su Gerente de Proyecto puede hacerlo. Lo que también hace que la respuesta sea específica para su organización y situación exactas, por lo que la respuesta no será de utilidad para otros visitantes. Perdón,
¡Bienvenido a PMSE, Jorge! Creo que esta pregunta definitivamente se puede salvar con una edición juiciosa. El título trata sobre el desarrollo, pero hay una pregunta subyacente sobre las especificaciones emergentes que podrían tratarse aquí. Creo que hay una joya de pregunta aquí si se puede reescribir para que sea más sobre la planificación del proyecto o la secuencia de sus fases de diseño que sobre las prácticas de desarrollo.
Edité su pregunta en gran medida para que sea más una pregunta de metodología y gestión de proyectos. Siéntase libre de continuar editando si siente que he malinterpretado la esencia de lo que realmente está tratando de preguntar.

Respuestas (2)

Spikes y prototipos están bien; Retconning Project Plans no es

Estaba planeando pasar a la fase de implementación y luego aplicar ingeniería inversa a mi trabajo.

Desde el punto de vista de la gestión de proyectos, esto no está bien. La planificación es difícil, pero la falta de planificación crea una deuda técnica y problemas para el proyecto y la organización en el futuro.

Waterfall se trata de una planificación inicial. Agile se trata de la planificación justo a tiempo. Ninguna metodología permite la planificación "listo, dispara, apunta", que es lo que estás describiendo.

Desde el punto de vista de la ingeniería, sin duda es permisible hacer un pico de proyecto o crear un prototipo con una planificación mínima para validar una idea o crear lecciones aprendidas para crear una implementación más permanente. Sin embargo, lo que está describiendo aquí es más como reconfigurar sus documentos de planificación para que se ajusten a lo que termine, lo cual no es una buena práctica de ingeniería o gestión de proyectos.

Gracias por modificar la pregunta original y también responderla por mí. Es para un proyecto de fin de carrera y por eso soy el encargado del mismo. Lo estoy haciendo por mi cuenta y me recomendaron pasar a la fase de implementación lo más rápido posible. Las etapas de planificación me parecieron deprimentes y muy vagas. Simplemente sentí que era mucho más fácil modelar el diagrama de clase y el diagrama de secuencia después
+1 Como siempre, tienes facilidad con las palabras CG. "¡Listo, fuego, apunta!" se reutilizará aquí (¡no como una metodología, me apresuro a agregar!) :)

Otra buena analogía de tiro: disparar, mover el objetivo sobre el agujero de bala, ¡ojo de buey!

En el mundo real, cuando tiene un cliente al que le está vendiendo su producto, este enfoque indudablemente causará un montón de mayores gastos, tiempo y un mayor riesgo de insatisfacción del cliente. El problema es que muchos proyectos mal realizados en el espacio de TI se realizan de esta manera, lo que da como resultado un historial muy pobre de fallas de proyectos según lo informado por Gartner y muchas otras fuentes. Si ya está experimentando problemas de cronograma o costos, este enfoque exacerbará los problemas a pesar de que pueda contradecir su intuición.

Si las cosas son ambiguas, haz que se especifiquen. Dedique tiempo a profundizar y documentar antes de construir. Pagará dividendos al final.

¿Se pueden producir documentos de planificación de forma retroactiva para que se ajusten al producto que se ha construido?
RespuestasAquíPolítica de privacidad1y, 0v