project-management - microsoft - project management software open source
¿Qué es un buen plan de desarrollo de software? (5)
"El plan [de desarrollo de software] es una descripción razonablemente detallada de todas las actividades que debe llevar a cabo".
Que, en general, no puede existir.
Si en verdad tiene todos los requisitos completamente comprendidos y tiene todos los problemas tecnológicos completamente comprendidos, podría escribir un documento de este tipo.
Sin embargo, si está haciendo algo nuevo , algo que los usuarios aún no han instalado, o si está utilizando alguna tecnología nueva, no puede proporcionar ni siquiera una descripción "razonablemente" detallada de las actividades que necesita llevar a cabo.
Puede proporcionar una descripción general, que resumirá algunas de las cosas que debe 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 hace esto todo el tiempo.
La audiencia 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, las personas lo hacen 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 se especifican en exceso y los cambios (a partir del aprendizaje a medida que avanza el equipo) se castigan.
O
Un plan de desarrollo de software es un gráfico de desarrollo ágil que simplemente muestra los sprints que se completarán. El nivel de detalle "razonable" es bastante bajo, es solo un resumen. Y cambia durante cada retrospectiva de sprint.
Mientras navegaba por las respuestas en SO me encontré con algo que, en mi opinión, es uno de los conceptos erróneos de administración de desarrollo de software más frecuentes: "el plan [de desarrollo de software] es una descripción razonablemente detallada de todas las actividades que debe emprender".
De ahí la pregunta: ¿qué es un buen plan de desarrollo de software? ¿Se puede reducir a una estructura de desglose del trabajo? ¿Es la EDT lo más importante para un plan de desarrollo de software de todos modos?
Un Plan de desarrollo de software es un plan sobre cómo desarrollará el software que tiene la intención de desarrollar y entregar.
Aunque sé que ustedes, los jóvenes traficantes, todos piensan que el ejército es un montón de idiotas, de hecho tienen mucha experiencia en esta área y, a diferencia de muchas firmas comerciales, reflexionaron sobre lo que había que hacer. Eso incluyó un montón de lecciones muy dolorosas sobre cosas que deben tenerse en cuenta, cortesía de proyectos que fracasaron porque esas cosas NO fueron consideradas.
Estoy actualizando esto el 10 de abril de 2010. La fuente DOD-STD-2167A que mencioné anteriormente se ha apagado, por lo que tiene sentido apuntarlo a MIL-STD-498. Desafortunadamente, MIL-STD-498 se canceló en 1998, y el DoD ahora espera que los contratistas usen IEEE / EIA-12207 en su lugar. Los estándares IEEE, sin embargo, no son gratuitos como en la cerveza.
Ver DI-IPSC-81427A para un esquema del Plan de Desarrollo de Software.
Al leer la lista de cosas que se deben abordar, es posible que tenga la impresión de que algunos de esos párrafos, como las reglamentaciones de la Marina, están escritos en sangre. Hay una razón para esa impresión: lo son. Los proyectos fallaron porque no abordaron esas áreas a tiempo.
Consulte también http://sepo.spawar.navy.mil/SW_Standards.html : puede descargar un .zip con el estándar y todas las descripciones de los elementos de datos (especificaciones para los documentos individuales).
(Sí, soy consciente de que el DoD se ha alejado del DOD-STD-2167A, a favor de los estándares comerciales de IEEE. Sin embargo, IEEE cobra un derecho de brazo, pierna y trasplante en su riñón izquierdo según sus estándares. los estándares son gratuitos como en la cerveza).
Editar: primer enlace fijo
Un plan de desarrollo de software es un tipo específico de plan de proyecto. Si bien un WBS es importante, solo está rascando la superficie.
Un plan de proyecto integral debería tener:
- Plan de alcance (contiene el WBS)
- Horario
- Plan de costo
- Plan de Calidad
- Plan de personal
- Plan de comunicación
- Plan de riesgo
- Plan de adquisiciones.
Se puede encontrar más información sobre cada uno de estos planes en
El proyecto Management Body of Knowledge.
Para pautas más específicas, vea Code Complete 2 .
lo que siento que en el proyecto de desarrollo de software debe dividirse en dos partes
- Gestión de software
- Desarrollo de software
En la gestión de proyectos, se pueden cubrir todas las cosas adicionales posibles, como el objetivo de la empresa, la planificación del proyecto, el seguimiento del proyecto, la estimación, la reserva de la parte de horas, el seguimiento de defectos, etc.
En el desarrollo del proyecto, el ciclo de vida del proyecto se mantendrá como cascada completa
Artefacto: Plan de desarrollo de software
El Plan de Desarrollo de Software es un artefacto compuesto integral que reúne toda la información requerida para administrar el proyecto. Incluye una serie de artefactos desarrollados durante la fase de Inicio y se mantiene durante todo el proyecto.
El plan de desarrollo de software contiene