Como desarrollador de software, ¿le molesta cuando las personas le piden que realice cambios menores de inmediato en lugar de agregarlos a la acumulación?

Answer 1

Sí. Me molesta. Especialmente cuando estoy trabajando en algo más en ese punto. Siento que es realmente ineficiente cuando ocurre tal cambio de contexto.

Considera que estoy trabajando en una determinada tarea, y el control de calidad comienza a golpearme con errores que descubrió en mi última tarea. Desde su punto de vista, podría estar haciendo lo correcto porque hay una fecha límite en la que se debe enviar el código o simplemente es cómo funciona.

Cualquiera que sea la razón, es solo una forma ineficiente de hacer las cosas.

La mejor manera de lidiar con esto es comunicarse. Uno debe decirle a la persona de control de calidad que mantenga una lista de las cosas que están rotas y solo involucrarlo cuando se realiza una ronda de pruebas completas.

Si el problema es el proceso general, entonces es un problema mucho más profundo. Cualquier equipo de Ingeniería de Software debe tener procesos sólidos en su lugar. Trate de encontrar un proceso sólido que se pueda repetir durante todo el ciclo de desarrollo. ¡El proceso debe contener tareas específicas y detalladas que deben completarse antes de que se envíe el código!

Si nada funciona. Solo mantén tu propia lista. Y aborde los problemas en lotes cuando la lista de tareas pendientes alcanza un cierto umbral.

Espero que ayude.

Answer 2

No los dejes.

Si ha estado “tomándolo” por un tiempo, cambiar de posición sobre estas cosas será doloroso, pero DEBE hacerlo si desea un proceso de desarrollo de software exitoso.

CADA cambio debe pasar por el proceso de análisis, estimación y acumulación o, de lo contrario, sus estimaciones no tienen sentido. Cuando su jefe se acerca y le pide un presupuesto, dígale que no puede darle uno, porque no tiene idea de qué “pequeños cambios” se presentarán esta semana.

Oh … y no hay tal cosa como un “cambio menor”.

Answer 3

Yo era A2A, pero no soy un desarrollador de software.

Dicho esto, lo que se describe en la pregunta suena como un problema de gestión de proyectos. Si constantemente se le interrumpe cuando se le pide que aborde problemas menores de inmediato, no tiene un buen proceso implementado para los problemas de seguimiento (errores, en el lenguaje del software) y su resolución.

Answer 4

Ha pasado mucho tiempo desde que hice el desarrollo, pero he administrado desarrolladores, he sido PM, etc.

Esto debería ser una discusión con su supervisor. Realmente depende del alcance y la escala, si eres menos productivo en lo que tu PM quiere que hagas, entonces esto podría impactar el cronograma del proyecto y ser negativo en tu evaluación de desempeño.

Tampoco es una gran idea si hay más de un desarrollador en el proyecto para realizar cambios en el núcleo no documentados y no programados. Puede solucionar su problema pero crear uno más grande para otra persona.

Algunas buenas reglas que he aprendido en el camino: no trabajes más duro, trabajes más inteligentemente y, para preocuparte más rápido, debes trabajar lento.

Answer 5

Quiero decir, es natural que la gente quiera hacer sus arreglos rápidamente. No están familiarizados con el aspecto de la carga de trabajo, por lo que no tienen idea de lo que están pidiendo.

Si puedo agregar la solución rápidamente, lo haré. Si no, les haré saber el plazo en el que puedo devolverlo. El 96% de las veces, esto funciona. Si no es así, me comunico con su gerente o el PM para hablar sobre la solicitud. Si realmente es urgente, lo hago. Si no, se les dice que se enojen y ese es el final.

Nada por lo que enojarse.

Answer 6

En términos generales, sí. Esta es una de las razones por las que es tan difícil hacer estimaciones precisas. Los cambios menores no siempre son tan pequeños como esperamos.