¿Dónde está la línea divisoria entre la falta completa de planificación y la parálisis del análisis?

Question

En mi muy corto tiempo de trabajo en el campo de la programación, he visto dos extremos:

• Proyectos donde poco o nada de la planificación que se hizo y por lo tanto convertirse en pesadillas requieren muy poco mantenimiento.
• Proyectos que están perpetuamente en las etapas de planificación y no se mueven desde allí.

Parece que este último a menudo sucede como una reacción al anterior. ¿Dónde está el medio feliz? Y más importante aún, si un proyecto se está moviendo en una de estas direcciones, ¿cuál es la mejor manera de moverlo hacia dicho medio feliz?

Answer 1

En mi propia experiencia personal, He encontrado que las 'decisiones' son mi cuello de botella.

Si este es el caso, entonces:

1. Lista todas sus opciones de diseño
2. Escoja una opción (s) (recoger unos pocos, si usted no puede decidir sobre uno)
3. Lista del riesgos de la (s) mejor (s) opción (es)
4. Para cada riesgo, piense en una solución, luego diseñe una prueba concluyente de concepto y escríbala.
5. Si su prueba de conceptos demuestra que NO funcionará, arroje esa opción y elija otra.

Una 'Prueba de concepto' es una mínima aplicación para demostrar algo. (los míos suelen ser de 1 a 6 horas)

Si tiene una situación en la que 2 o más opciones son iguales, dése un límite de tiempo (como 5 minutos, no 2 meses) y tome una decisión ... cualquier decisión, y no mires atrás

Y confíe en que podrá hacer frente a los problemas que tenga y que no haya tenido en cuenta en el momento del diseño.

Answer 2

La planificación inicial debe ser aproximadamente O (log n) donde n se espera el tiempo de desarrollo total.

Si tiene que presionar en una semana, dibuje algo en una servilleta. Si tiene un mes, el primer día es para el diseño inicial. Si tienes un año, pasa una semana.

Esto asume que revisitas la planificación de forma iterativa, y no solo haces todo el estilo de comando en tu base de código, sin la supervisión de un adulto :-).

Answer 3

La parálisis del análisis puede tener muchos síntomas. Uno que he notado es que se hacen las mismas preguntas en cada reunión y no se llega a ninguna resolución. Si puede señalar esto a las personas que podrían ayudarlos a admitir que el proceso de planificación se está estancando.

Si puede, al inicio del proyecto, indicar que desea cubrir un cierto porcentaje de los requisitos en la etapa de planificación, digamos como 80-90%. De esta manera, hay un objetivo claro y no estás tratando de alcanzar la perfección. Puede volver a visitar la planificación y el análisis más adelante, simplemente no permita que se mantenga.

Answer 4

Creo que depende de 2 factores:

• La longitud del proyecto

  • ¿Es un proyecto 1 semana?
  • ¿Es un proyecto de 1 año?
  • ¿O en algún punto intermedio?

• El riesgo de los cambios que se introdujeron en el proyecto

  • Son arquitectónica en la naturaleza, que puedan afectar a una gran parte del código original?
  • ¿O simplemente está agregando una nueva característica?

Obviamente, es una combinación de los factores anteriores 2. Simplemente no tiene sentido pasar un mes diseñando una función que llevará 2 días implementarla y es de poco riesgo para la arquitectura. Me estoy imaginando una matriz aquí de tradeoffs de longitud/riesgo/tiempo de diseño.

Hubo algunos consejos interesantes en Code Complete 2, que actualmente estoy en el proceso de leer. No puedo recordar las palabras exactas, así que estoy parafraseando aquí, pero dicho algo a lo largo de las líneas de:

Los 2 errores más grandes que usted puede hacer en un diseño son:

1. Attemping to design EVERYTHING (you will fail) 
2. Designing NOTHING before implementation 

Encontrar el medio feliz entre estos 2 es la clave para un diseño y planificación exitosos.

Answer 5

Grandes preguntas, sin una respuesta absoluta, esto es lo que hace que la experiencia sea significativa. La experiencia incluye:

• cuánto detalle se puede realmente obtener de cualquier usuario/patrocinador y desde este grupo específico
• la cantidad de detalles hace su equipo necesidad actual (niveles de habilidades específicas técnicos/comerciales)
• grado de apertura son sus patrocinadores/usuarios para ayudar durante el desarrollo (la agilidad de un equipo tienes - ¿incluye el promotor/usuario?)
• lo bien que se está identificando brechas

un factor importante es el sistema que se está desarrollando: cuanto más crítica sea la "vida", más detalles necesitará (monitor cardiaco en comparación con una página web).

Cuanto más complejo, el costo/tiempo limitado, la vida-crítico más el trabajo frontal - los menos cuanto más se puede detallar mientras lo haces en el trabajo (prototipo a la producción)