2008-12-19 14 views

Respuesta

32

En primer lugar, debe distinguir entre plazos y estimaciones.

  • Las fechas límite provienen de fuentes externas, por ejemplo, "La característica X debe estar lista para la feria".
  • Las estimaciones provienen de fuentes internas, por ejemplo, "la característica X tardará N semanas en completarse".

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

Se producen problemas cuando no se pueden resolver los dos, si la fecha límite es menor que la estimación.

Consejos útiles para dev (derivaciones):

  • dejar que la persona que hace el trabajo de crear la estimación.
  • Asegúrese de que las estimaciones se basan en tareas pequeñas, cada una no más de un día o dos.
  • Utilice un ciclo de retroalimentación para que los desarrolladores mejoren sus habilidades de estimación.
  • Las habilidades de estimación precisas le permiten presionar más contra las demandas de plazos.

Consejos útiles para los vendedores/creadores de plazo:

  • no anulan una estimación con una fecha límite.
  • Si una fecha límite entra en conflicto con una estimación, las únicas opciones reales son (a) los desarrolladores trabajan horas extras, (b) los requisitos para la fecha límite se recortan, o (c) la fecha límite se pierde.
  • Explique por qué la fecha límite es importante y cuál es el objetivo de la función (el "cliente X firmará un contrato de seis cifras").
  • Comprenda que las personas que sienten que no pueden cumplir con los plazos agresivos no estarán motivadas.
1

Bien, estoy bastante contento con un plazo si 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 se entregarán en dicha el plazo está bien definido.

2

Creo que depende de cómo se crean los horarios. El desarrollador debe tener un papel importante en la elaboración del cronograma. De lo contrario, ¿cómo sabrá si es razonable o no?

Si alguien en la alta gerencia simplemente dicta que "Característica X debe hacerse por Y" sin tener una buena idea de cuánto tiempo realmente podría tomar (algunas cosas son mucho más complicadas de implementar de lo que parecen) entonces eso es una mala cosa Sin embargo, si trabajan con los desarrolladores para estimar la cantidad de esfuerzo realmente requerido y equilibrar eso con el resto de las necesidades de la compañía, entonces generalmente funciona bastante bien.

5

Tradicionalmente solo puede ajustar la calidad, las características o el tiempo, siendo la última la fecha límite. Calidad con la que realmente no quiere perder el tiempo. Entonces, mientras el proceso que está utilizando le permita calibrar las características para alcanzar los plazos, estoy bien.

1

Las revisiones periódicas son cruciales:

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

Debe tener fechas límite, pero igualmente th Estos plazos deben ser realistas y mensurables. Mover las especificaciones va a molestar al desarrollador, puede ser inevitable, pero no tenga miedo de mover cosas (después de las discusiones).

Las fechas límite y las estimaciones de trabajo nunca serán particularmente precisas, pero las técnicas básicas de Gestión de proyectos deberían significar que las personas son conscientes de que las han omitido y de por qué sucedieron.

9

Programadores ODECEMOS plazos por muy buenas razones!

Es casi imposible estimar con precisión cuánto tiempo tardará una pieza de código en diseñar, escribir y depurar hasta que lo haya hecho.

Desde mi experiencia personal, he pasado más de una semana obteniendo un script de shell "simple" para trabajar, que habría estimado en alrededor de una hora. Por otro lado, tomó aproximadamente una semana escribir un analizador sintáctico para las definiciones de datos COBOL (incluyendo todos los INCREÍBLES COMP COMP-3 OCCURS redefinen el SYNC y los bytes slack) que había estimado en aproximadamente dos meses.

El otro gran problema es que, frente a unos plazos ajustados, los programadores omiten las mejores prácticas y comienzan a piratear. De este modo, se ahorra aproximadamente el 50% del tiempo de codificación, pero se agrega un 300% al tiempo de prueba y depuración.

+1

-1 Es también depende de nosotros los desarrolladores para mejorar la forma en que hacemos estimaciones. No es "casi imposible", requiere práctica. Sería capaz de estimar alguna tarea casi exactamente porque sé exactamente lo que sucederá gracias a mi experiencia. No odio las fechas límites ya que me ayudan a enfocarme con un objetivo, odio las fechas límite irreales para mis publicistas :) – marcgg

+1

Novato o no, cuando busqué nuevas soluciones para errores desconocidos, mi jefe me sigue presionando para preguntar sobre los plazos. Si soy demasiado honesto, me costará trabajo. ¿Qué se puede esperar? Somos programadores y tienen un tiempo completamente desajustado por una cosa: pensamiento excesivo. –

+0

De acuerdo! Nunca puedes estimar una tarea que nunca has hecho antes. Es fácil estimar los sitios web de CRUD pero no se puede buscar información sobre la cual se debe investigar. Hasta que sepa cómo hacerlo, no puede dar una estimación adecuada. Lo mismo sucede cuando tengo prisa. Solo escribo código rápido sin siquiera pruebas básicas y luego refacciono el desastre por días \ –

5

Los desarrolladores deben participar en la creación de los plazos. Si son arbitrarios y se crean sin la participación de los desarrolladores, entonces tienen derecho a quejarse. Los proyectos legítimamente obtienen restricciones de tiempo de las empresas, pero los recursos y las características deben ajustarse para compensar. Esos ajustes no se pueden hacer sin la participación de los desarrolladores (sin mencionar BAs, QA y gente de operaciones).

3

La única ingenieros de software/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 el plazo , y entonces no me gustan porque cuando pierden la fecha límite los hace quedar mal.
  2. Ellos no tienen un problema con los plazos, como siempre y cuando alguien que entiende el trabajo que implica se establece la fecha límite . Los peores plazos son realizados por gerentes que intentan vender un proyecto y diciendo "3 semanas? No ¡problema!"Y luego decirle a su equipo desarrollo que tienen 3 semanas para producir una versión de trabajo de MS Office y recrear internet para niño pequeño del CEO.
Cuestiones relacionadas