¿Cómo se maneja Programación / plazos torno a los programadores? [cerrado]

Question

¿Los programadores como para crear los plazos? Soy un desarrollador web y horarios / fechas límite están por todo el lugar en mi campo. Pero he trabajado con algunos ingenieros de software / programadores que odian a los plazos, ¿hay una forma de evitar eso?

Answer 1

En primer lugar, es necesario distinguir entre los plazos y presupuestos.

• Los plazos vienen de fuentes externas, por ejemplo, "Función X tiene que estar preparado para la feria".
• Las estimaciones provienen de fuentes internas, por ejemplo, "Feature X tomará N semanas para completar".

En general, los programadores deben crear las estimaciones, y las ventas / comercialización crearán plazos.

Los problemas se producen cuando los dos no pueden ser resueltos - si el plazo está más cerca que la estimación

.

Consejos útiles para DEV (conductores):

• Deja que la persona que realiza el trabajo de crear la estimación.
• Asegúrese de que las estimaciones se basan en pequeñas tareas, cada una más de un día o dos no.
• Utilice un circuito de retroalimentación para permitir a los desarrolladores a mejorar sus habilidades de estimación.
• habilidades estimación precisa le permite empujar con más fuerza contra las demandas de plazo.

Consejos útiles para los vendedores / creadores de plazo:

• No anular una estimación con una fecha límite.
• Si un plazo entra en conflicto con una estimación, las únicas opciones reales son: (a) los desarrolladores a trabajar horas extras, (b) se recortan los requisitos para la fecha límite, o (c) la fecha límite es olvidada.
• explicar por qué el plazo es importante, y cuál es el propósito de la fecha límite es función ( "cliente X firmará un contrato de seis cifras").
• Comprender que las personas que sienten que no pueden cumplir con los plazos agresivos no serán motivados.

Answer 2

Los programadores ODIAN plazos por muy buenas razones!

Es casi imposible calcular con exactitud cuánto tiempo una pieza de código se necesita para diseñar, escribir y depurar hasta que haya hecho.

A partir de mi experiencia personal he pasado más de una semana conseguir un script de shell "simple" para trabajar, que yo hubiera estimado en alrededor de una hora. Por otra parte tomó alrededor de una semana para escribir un programa de análisis de las definiciones de datos COBOL (incluyendo todas las funciones COMP raro COMP-3 PRODUCE redefine SYNC y bytes de holgura cosas) que había estimado en unos dos meses.

El otro gran problema es que, frente a un plazos ajustados programadores saltar las mejores prácticas y empezar a cortar. De este modo el ahorro de aproximadamente el 50% del tiempo de codificación, pero la adición de un 300% a la hora de prueba y depuración.

Answer 3

Tradicionalmente sólo se puede ajustar la calidad, características o tiempo, siendo la última la fecha límite. Calidad en la que realmente no quiere perder el tiempo con. Así que, mientras el proceso está utilizando permite calibrar características para llegar a plazos, estoy bien.

Answer 4

Los desarrolladores tienen que participar en la creación de los plazos. Si son arbitrarias y creado sin la participación de los desarrolladores, entonces tienen derecho a quejarse. Proyectos legítimamente obtienen las limitaciones de tiempo de los negocios, pero los recursos y funciones deben ser ajustados para compensar. En dichas modificaciones no se pueden hacer sin la participación de los desarrolladores (por no hablar de BAS, control de calidad y operaciones gente).

Answer 5

El software sólo ingenieros / desarrolladores que he conocido que odian plazos sienten de esa manera por una de dos razones:

1. Son totalmente desorganizado, y saben que no van a cumplir con el plazo, por lo que no me gusta de ellos porque cuando se pasa la fecha límite que hace que se vean mal.
2. No lo hacen tener un problema con los plazos, como siempre y cuando alguien que entiende el trabajo en cuestión es el establecimiento de la fecha límite. Los peores son los plazos realizado por los gerentes tratan de vender una proyecto y diciendo "3 semanas? n problema!", y luego contar su equipo de desarrollo que tienen 3 semanas para producir una versión de trabajo de MS Office y volver a crear la Internet para niño pequeño del CEO.

Answer 6

Creo que depende de cómo se crean los horarios. El desarrollador tiene que tener un papel significativo en subir con el horario. De lo contrario, ¿cómo va a saber si es razonable o no?

Si alguien en la alta dirección, simplemente dicta que "Característica X necesita ser hecho por Y" sin tener ninguna buena visión en el tiempo que en realidad podría tener (algunas cosas son mucho más complicadas de implementar que suenan), entonces eso es una mala cosa. Sin embargo, si trabajan con los desarrolladores para estimar la cantidad de esfuerzo que realmente se requiere y el equilibrio que con el resto de las necesidades de la empresa, a continuación, por lo general funciona bastante bien.

Answer 7

Bien, estoy bastante contento con un plazo si de ese plazo ha sido determinado por el proceso de estimación bien pensado, con la participación de los directivos y los ingenieros y los requisitos para lo que se supone que debe ser entregado en dicho plazo están bien definidos.

Answer 8

Las revisiones periódicas son cruciales:

• una lista de los principales hitos y resultados
• dividirlo en trozos más pequeños
• Crear un conjunto de estimaciones más pequeños
• Haga los plazos razonables

Debe tener plazos, pero igualmente los plazos deben ser realistas y medibles. Mover la especificación alrededor va a molestar a los desarrolladores - que podría ser inevitable, pero no tenga miedo de mover las cosas (después de las discusiones).

Los plazos y estimaciones de trabajo nunca van a ser particularmente precisa, pero las técnicas básicas de modo de gestión de proyectos debe significar que las personas son conscientes de la falta de ellos - y por qué sucedió.