¿Debería un desarrollador aceptar una estimación de la carga de trabajo realizada por una macro de Excel?

Depende de qué tan sensibles se vean al desarrollador, y en qué datos / lógica se basan. ( podrían basarse en datos estadísticos recopilados durante varios años sobre cuánto tiempo se requirió, por parte de este mismo desarrollador y / o por otros, para resolver tareas similares en el pasado ... o << em> podría basarse completamente en las suposiciones de su gerente, correctas o incorrectas.)

Idealmente, debería discutir con su gerente que no se puede esperar razonablemente que uno se comprometa y asuma la responsabilidad de una tarea estimada por otra persona.

El simple hecho de negarse a comprometerse con las estimaciones puede resultar en su rápido reemplazo, por lo que es mejor tener un enfoque más suave y evitar la confrontación directa si es posible.

Presumiblemente, la macro está operando en algún tipo de datos de entrada, ¿no es solo un generador de números aleatorios? Entonces, para responder a su pregunta, necesitamos saber qué son los datos de entrada y qué hace la macro. Sin esto, ninguna respuesta carece de significado.

O, ¿su pregunta es realmente acerca de aceptar estimaciones producidas por un gerente que carece de experiencia relevante? En este caso, la respuesta es no, usted (o su amigo) debe elaborar sus propias estimaciones y enviarlas al gerente. Si las 2 cifras no coinciden, deben trabajar juntas para encontrar la mejor manera de avanzar, tal vez acordar escribir menos pruebas o demorar más en escribirlas todas.

El rechazo en blanco no va a ayudar a nadie, y trabajar en una escala de tiempo que no puede cumplir tampoco es divertido, la solución está en adoptar un enfoque profesional y llegar a un compromiso que permita que el trabajo continúe.

Definitivamente NO.

Un programa pequeño, incluso un programa grande y complicado, no puede estimar cuánto tiempo tomará un trabajo de programación. Consulte Límites matemáticos a la estimación de software para conocer las razones. También está disponible un documento más extenso, revisado por pares, Límites grandes para la estimación de software .

También reconsideraría mi opinión del gerente en cuestión: ¿por qué cree que no se ha probado una macro de hoja de cálculo en el pasado, dado que se ha intentado todo lo demás para estimar la duración de las tareas de software en el pasado?

¡Ugh!

Este es un gigantesco "olor a trabajo". Eso es increíble microgestión.

Si no pueden confiar en que sus empleados proporcionen un presupuesto, ¿qué otra cosa no confían en usted?

Absolutamente NO.

Le prometo que el gerente no está tan ilusionado de pensar que su macro de Excel puede predecir con precisión las estimaciones. Ni siquiera estoy discutiendo lo que debería ser un hecho bien conocido de que hay demasiadas variables involucradas para predecir con precisión algo como esto en un algoritmo. Si inventó tal algoritmo, debería patentarlo y ganar millones en mi opinión.

Lo que realmente está sucediendo aquí es que el administrador está utilizando esta supuesta macro de Excel como un disfraz ligeramente oculto para ocultar el hecho de que está forzando expectativas poco realistas y una presión indebida sobre sus desarrolladores.

Él sabe que es BS y no le importa, es una excusa para sobrecargar recursos y tratar de hacer las cosas más rápido haciendo que todos sus desarrolladores "sin valor" perpetuamente "TARDE".

Este administrador suena como un imbécil explotador.

  

En un nuevo proyecto, un amigo tuvo que escribir pruebas en las que el tiempo requerido para escribirlas se calculó mediante una macro de Excel escrita por su administrador no desarrollador.

Hay modelos de estimación paramétricos para calcular el tiempo de finalización de los proyectos, incluidos los proyectos de software. Generalmente, la estimación es para el código de producción, pero no veo por qué no se puede extrapolar para estimar cuánto tiempo tomará escribir el código de prueba. Sin embargo, estas estimaciones son tan buenas como los datos que se introducen en ellas.

Suponiendo que el método utilizado es un modelo de estimación válido y que los datos son precisos y válidos, no hay razón para que una buena estimación no provenga de una macro de Excel escrita por un administrador que no sea desarrollador.

  

En tales circunstancias, ¿debería un desarrollador aceptar la responsabilidad de escribir y ejecutar las pruebas en el tiempo calculado?

Ninguna estimación debe ser aceptada a ciegas, bajo ninguna circunstancia. Ninguna estimación es perfecta, independientemente de cómo se genere. Depende del ingeniero revisar cualquier estimación, identificar posibles problemas, evaluar su impacto y discutir y refinar la estimación según sea necesario.

  

¿Son confiables los resultados de estas pruebas?

Las pruebas son tan buenas como el esfuerzo empleado en diseñarlas e implementarlas. Si un probador produce pruebas de baja calidad, los defectos se deslizarán a través de las pruebas y pasarán a una fase posterior del proyecto. Es lógico que la presión programada lleve a pruebas de baja calidad, por lo que si el tiempo no es suficiente para diseñar los casos de prueba apropiados y luego implementar esos casos, las pruebas no serían tan útiles.

Parece que estás haciendo dos preguntas diferentes:

  

¿Son confiables los resultados de estas pruebas?

Excel es una herramienta como cualquier otra con la que trabajamos y en la que se escribieron los cálculos no debería tener un impacto en los resultados del algoritmo en sí. El hecho de que la estimación provenga de una macro de Excel es irrelevante para determinar si los resultados del cálculo (es decir, la validez de la estimación) son o no válidos. Si tiene malas suposiciones en el modelo subyacente, no importa lo que use para hacer el cálculo, ya que las suposiciones subyacentes son incorrectas.

  

En tales circunstancias, si un desarrollador acepta la responsabilidad de   escribe y ejecuta las pruebas en el tiempo calculado?

Si el requisito de que el desarrollador realice el trabajo en el tiempo indicado está en su contacto, no hay mucho que puedan hacer para discutirlo siempre que las estimaciones sean razonables. Lo que nos lleva al siguiente punto: si los cálculos dan una cantidad de tiempo razonable y son similares a las estimaciones que se daría el desarrollador, entonces no hay razón para no objetar las líneas de tiempo indicadas. De hecho, podría ser ventajoso para los desarrolladores, ya que podrían influir en las suposiciones utilizadas en el módulo, a diferencia de si se les da una línea de tiempo arbitraria.

Si las líneas de tiempo parecen imposibles para la cantidad de trabajo requerido, obviamente deben plantear esta preocupación y tratar de trabajar con el gerente para obtener líneas de tiempo más realistas, pero si la línea de tiempo es factible, tendrán dificultades para objetar. a ellos.

En términos de gestión de proyectos y estimación de líneas de tiempo, sí, puede hacerse, pero depende en gran medida de la naturaleza del trabajo que se realice. Es probable que vea que se dan estimaciones más precisas para el tiempo requerido para escribir el código de prueba de unidad (suponiendo que el desarrollador entienda el marco y lo haya escrito antes) que cuando escriba el nuevo código en los casos de uso en que se escribe el código de prueba para.

No quiero minimizar las pruebas de escritura, pero es probable que el proyecto haya tenido varios desarrolladores que las hayan escrito antes. Si las estimaciones se basan en estos datos, pueden ser más precisas de lo que su amigo ha supuesto. Desde que su amigo abandonó el proyecto, no intentó crear estimaciones opuestas o ver si podrían completarse como se predijo, nunca lo sabremos.

Todo lo que tenía que hacer era completar una o dos pruebas para ver qué tan precisa era la estimación y regresar al gerente con un argumento legítimo. Puede haber otros miembros del equipo que podrían haber proporcionado comentarios sobre la confiabilidad de las estimaciones o las consecuencias de quedarse atrás. A veces, un gerente tiene que darle "algo" a su jefe para mantener a todos contentos. Los desarrolladores ven esto como una falsa sensación de seguridad. Tal vez si hubiera un movimiento para que los desarrolladores proporcionen estimaciones y muestren la voluntad de hacer las cosas, la administración puede desarrollar más confianza.

Lo que supongo es que, si pudiera completar las pruebas en menos tiempo, no diría nada al respecto. Por otra parte, excusarse de una práctica en la que no cree, puede indicar un alto nivel de integridad.

Respuesta fácil y breve:

No te importa de dónde viene la estimación.

Lo que realmente te importa es la estimación en sí misma. Acepte o no esté de acuerdo y explique por qué y cuánto usted estimaría. Eso es lo más importante.

En teoría, un desarrollador nunca debe aceptar una estimación realizada por otra persona, sin importar cómo se llegó a ella. Una razón es que dar una estimación más larga de lo que su gerente se siente cómodo expone de inmediato un posible problema de programación o tal vez un malentendido sobre el alcance del trabajo a realizar.

En general, las personas encuentran que la estimación del tiempo de programación es incluso más difícil que la programación en sí misma, por lo que si su administrador puede escribir una macro de Excel puede resolver el problema , es probable que pueda construir una macro para escribir el código (no es probable ).

Ahora, en práctica , si entiende que el trabajo y las estimaciones parecen razonables, tiene sentido simplemente expresar cierta preocupación acerca de la metodología, pero luego acepta provisionalmente ver si puede cumplirlas . Más adelante, si el trabajo le está demorando más que las estimaciones, debe informarle a sus gerentes lo antes posible. Prepárese para discutir las razones exactas en función de su experiencia de implementación real. Esperemos que en ese momento su gerente no sea irrazonable y continúe insistiendo en que trabaje para obtener estimaciones generadas mecánicamente.

Una de las metodologías de desarrollo de software más nuevas es agile , y uno de los marcos ágiles conocidos es scrum . Pero en esta metodología, los desarrolladores (equipo scrum) son responsables de calcular el tiempo requerido para realizar una tarea o implementar una historia de usuario.

Definitivamente digo NO . Porque:

1. Un administrador que no sea desarrollador no puede estimar el tiempo requerido para hacer un trabajo
2. La estimación del tiempo requerido para realizar cualquier trabajo requiere algo de inteligencia humana, que Excel no tiene
3. Al aceptar tales prácticas de trabajo, el administrador se acostumbra progresivamente a reemplazar a los desarrolladores en la estimación de los tiempos. Esto puede resultar en una catástrofe. Considere este escenario en el que su gerente dice:

  

Quiero comenzar un nuevo proyecto para vender bicicletas en línea y sé que a ti y a John les lleva 3 semanas lograrlo.