"El plan [de desarrollo de software] es una descripción razonablemente detallada de todas las actividades que necesita llevar a cabo".
Que, en general, no puede existir.
Si realmente tiene todos los requisitos totalmente comprendido, y tiene todas las cuestiones de tecnología totalmente comprendido, se podría escribir un documento de este tipo.
Si, sin embargo, está haciendo algo nuevo - algo que los usuarios aún no han instalado - o está utilizando cualquier tecnología nueva, no puede proporcionar ni siquiera una descripción "razonablemente" detallada de las actividades necesitas emprender.
Puede proporcionar una descripción general, que resumirá algo de lo que necesita hacer. Pero, a medida que explora los requisitos, los usuarios descubrirán cosas, aprenderán y cambiarán de opinión. Revisando el plan. A medida que explora la tecnología, los desarrolladores descubrirán cosas, aprenderán y revisarán el plan.
No puede ser tan difícil, la gente lo hace todo el tiempo.
El público del plan es la administración. Los gerentes quieren una descripción "razonablemente" detallada de todas las actividades. A medida que los usuarios y desarrolladores aprenden sobre los requisitos y la tecnología, los detalles cambian. Esto hace que la prueba "razonable" sea muy, muy difícil de satisfacer. Cuando los detalles cambian constantemente, ¿qué nivel de detalle es "razonable"?
Los cambios en el plan pueden llegar (y lo hacen) a diario. La mayoría de los gerentes no querrán realizar cambios diarios en el plan. Entonces, demasiados detalles se vuelven "irrazonables". Para crear un plan que no cambie muy a menudo, el plan debe ser un resumen de las actividades.La única versión viable de un "Plan de Desarrollo de Software" es una serie de objetivos definidos, no en términos de actividades, en términos de funcionalidad que se lanzará a los usuarios.
En resumen, la gente lo hace mal todo el tiempo. En más de 30 años de desarrollo de software (gran parte como subcontratista militar) existe una fantasía sobre la planificación que simplemente no surge de los hechos. Los proyectos se cancelan con planes "razonablemente detallados", planes demasiado detallados y ningún plan.
De hecho, un plan suele ser la principal causa de cancelación. ¿Por qué? Con una lista de actividades "razonablemente detallada", cualquier aprendizaje significa que el plan está equivocado. Como el plan difiere de la ejecución real, algo debe estar mal. Tirar una moneda. Si considera que la ejecución es incorrecta, cancele el proyecto por no seguir el plan. Si considera que el plan es incorrecto, arregle el plan para que coincida con el mundo real. Cuanto más detallado es el plan, más parece "correcto" y es más probable que la ejecución sea defectuosa.
Línea inferior.
Un plan de desarrollo de software puede ser un documento de fantasía escrito como parte de una metodología de desarrollo "cascada" en la que todo tipo de cosas están sobre especificadas por adelantado y se castigan los cambios (del aprendizaje a medida que avanza el equipo).
O
un plan de desarrollo de software es una Agile burndown chart que simplemente muestra las pruebas de velocidad para ser completado. El nivel de detalle "razonable" es bastante bajo, es solo un resumen. Y cambia durante cada retrospectiva de sprint.
Lectura recomendada: "Código completo". Al leerlo ahora mismo, esto te ayudará a comprender. – KdgDev