¿Qué tipo de plazos tienen generalmente los ingenieros de software? ¿Largo o corto?

Esto depende de muchos factores. Por ejemplo, las nuevas empresas suelen tener plazos (relativamente) cortos, mientras que las empresas que tienen un producto sólido y estable pueden tener plazos más largos. Otros factores podrían ser el alcance y los requisitos, el costo, etc. Si una empresa solo tiene un pequeño número de desarrolladores y es necesario construir muchas características, esto puede llevar a plazos cortos y ajustados. Pero si la compañía tiene muchos desarrolladores que practican TDD / BDD y un talentoso equipo de control de calidad, entonces los plazos pueden ser mucho más conservadores. Es realmente difícil decirlo sin todos los detalles.

He experimentado un par de variaciones de Agile y una variación de Waterfall y todas terminan con el ingeniero teniendo algo para mantenerlo ocupado con tareas específicas durante las próximas 2-4 semanas, y una vaga idea de lo que está por venir un mes o dos más adelante, y todo lo pasado que generalmente es mejor no pensar.

He oído que esto se llama “el cono de incertidumbre”.
Nunca hay un “hecho” y los plazos son líneas abstractas dibujadas en la arena (generalmente por alguien que no sea la persona que lo implementa) y luego los implementadores discuten sobre lo que pueden o no pueden hacer en ese período de tiempo.

Se elaboró ​​un nuevo plan que todos están de acuerdo en que posiblemente podría ajustarse a la fecha límite. Pero rara vez lo hacen.

En mi experiencia (1,5 años), constantemente me dan más tiempo del necesario para completar las tareas. Cuando me dan un plazo que no puedo cumplir, lo hago saber y me dan más tiempo. Tampoco me he quedado en el trabajo hasta tarde para cumplir un plazo, y nunca me sentí presionada para hacerlo.

Dicho esto, nunca he trabajado para una agencia o tienda de consultoría donde los clientes establecen los plazos. Solo he trabajado en lugares que venden su propio software.