En un nuevo proyecto, un amigo tuvo que escribir pruebas donde el tiempo requerido para escribirlas fue calculado por una macro de Excel escrita por su gerente no desarrollador.
En tales circunstancias, ¿debería un desarrollador aceptar la responsabilidad de escribir y ejecutar las pruebas en el tiempo calculado? ¿Son confiables los resultados de estas pruebas?
Para obtener información, mi amigo se negó a ser responsable de las estimaciones que no hizo, pidió tener éxito para trabajar en otro proyecto y fue reemplazado por un sí-hombre sin experiencia fuera de la escuela.
project-management
productivity
testing
Nelstaar
fuente
fuente
Respuestas:
Depende de cuán sensibles sean para el desarrollador y de qué datos / lógica se basen. ( podrían basarse en datos estadísticos recopilados durante varios años sobre cuánto tiempo se requirió, por este mismo desarrollador y / o por otros, para resolver tareas similares en el pasado ... o podrían basarse enteramente en los de su gerente) correcto o incorrecto - supuestos)
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.
Rehusarse claramente a comprometerse con las estimaciones puede resultar en su reemplazo inmediato, por lo que es mejor tener un enfoque más suave y evitar la confrontación directa si es posible.
fuente
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 cuáles son los datos de entrada y qué hace la macro. Sin esto, cualquier respuesta no tiene sentido.
¿O es realmente su pregunta 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 producir sus propias estimaciones y presentarlas al gerente. Si las 2 figuras no coinciden, entonces deben trabajar juntas para encontrar la mejor manera de avanzar, tal vez aceptando escribir menos pruebas o quizás tomando más tiempo para escribirlas todas.
La negativa en blanco no va a ayudar a nadie, y trabajar en un plazo que no puede cumplir tampoco es divertido, la solución radica en adoptar un enfoque profesional y llegar a un compromiso que permita que el trabajo continúe.
fuente
Definitivamente NO.
Un programa pequeño, incluso un programa grande y complicado, no puede estimar cuánto tiempo llevará un trabajo de programación. Consulte Límites matemáticos para la estimación de software para conocer los motivos. También hay disponible un documento más largo, revisado por pares, Grandes límites para la estimación de software .
También reconsideraría mi opinión sobre el gerente en cuestión: ¿por qué él o ella cree que una macro de hoja de cálculo no se ha probado en el pasado, dado que todo lo demás se ha intentado para estimar la duración de la tarea de software en el pasado?
fuente
Ugh!
Este es un gigantesco "olor a trabajo". Esa es una microgestión increíble.
Si no pueden confiar en sus empleados para darles una estimación, ¿con qué más no confían en usted?
fuente
Absolutamente no.
Le prometo que el gerente no está tan engañado como para pensar que su macro 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 él inventó tal algoritmo, debería patentarlo y ganar millones en mi opinión.
Lo que realmente está sucediendo aquí es que el gerente está utilizando esta supuesta macro de Excel como un disfraz apenas 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 los recursos y tratar de hacer las cosas más rápido al hacer que todos sus desarrolladores "sin valor" permanentemente "TARDE".
Este gerente suena como un idiota explotador.
fuente
Existen modelos de estimación paramétrica para estimar el tiempo de finalización de los proyectos, incluidos los proyectos de software. Por lo general, 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 les envían.
Suponiendo que el método utilizado es un modelo de estimación válido y que los datos son exactos y válidos, no hay ninguna razón por la cual una buena estimación no pueda provenir de una macro de Excel escrita por un administrador que no sea desarrollador.
Ninguna estimación debe ser aceptada ciegamente, 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.
Las pruebas son tan buenas como el esfuerzo dedicado a diseñarlas e implementarlas. Si un probador produce pruebas de baja calidad, los defectos pasarán desapercibidos y pasarán a una fase posterior del proyecto. Es lógico que la presión programada conduzca a pruebas de baja calidad, por lo que si el tiempo es insuficiente para diseñar los casos de prueba apropiados y luego implementar esos casos, las pruebas no serían tan útiles.
fuente
Parece que estás haciendo dos preguntas diferentes:
Excel es una herramienta como cualquier otra con la que trabajamos y en lo que se escribieron los cálculos realmente 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 válidos o no. Si tiene supuestos erróneos en el modelo subyacente, no importa lo que use para hacer el cálculo, ya que los supuestos subyacentes son incorrectos.
Si el requisito de que el desarrollador haga el trabajo en el tiempo indicado está en su contacto, entonces no hay mucho que puedan hacer para discutirlo siempre que las estimaciones sean razonables. Lo que lleva al siguiente punto: si los cálculos están dando una cantidad de tiempo razonable y son similares a las estimaciones que el desarrollador se daría a sí mismo, entonces no hay razón para no objetar los plazos dados. De hecho, podría ser ventajoso para los desarrolladores, ya que podrían influir en los supuestos utilizados en el módulo en lugar de si se les da una línea de tiempo arbitraria.
Si las líneas de tiempo parecen inviables para la cantidad de trabajo requerida, entonces obviamente deberían plantear esta preocupación e intentar trabajar con el gerente para obtener líneas de tiempo más realistas, pero si la línea de tiempo es factible, entonces tendrán dificultades para objetarlas.
En términos de gestión de proyectos y plazos de estimación, sí, se puede hacer, pero depende en gran medida de la naturaleza del trabajo que se realiza. Es probable que vea estimaciones más precisas para el tiempo requerido para escribir el código de prueba de la unidad (suponiendo que el desarrollador comprenda el marco y lo haya escrito antes) de lo que lo hará para escribir un nuevo código contra los casos de uso en los que se está escribiendo el código de prueba para.
fuente
No quiero minimizar las pruebas de escritura, pero el proyecto probablemente ha tenido varios desarrolladores que las escribieron antes. Si las estimaciones se basan en estos datos, pueden ser más precisas de lo que su amigo ha asumido. Dado que su amigo dejó el proyecto, no hizo ningún intento de crear estimaciones opuestas o ver si podían completarse según lo previsto, 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 brindado 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 que todos estén contentos. Los desarrolladores ven esto como una falsa sensación de seguridad. Tal vez si hubo un movimiento para que los desarrolladores proporcionen estimaciones y muestren una disposición para hacer las cosas, la gerencia puede desarrollar más confianza.
Supongo 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.
fuente
Respuesta fácil y corta:
No te importa de dónde viene la estimación.
Lo que realmente te importa es la estimación misma. De acuerdo con ella o no de acuerdo y explicar por qué y cuánto se podría estimar. Eso es lo más importante.
fuente
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 inmediatamente un posible problema de programación o tal vez un malentendido sobre el alcance del trabajo a realizar.
Las personas generalmente encuentran que la estimación del tiempo de programación es aún más difícil que la programación misma, por lo que si su gerente puede escribir una macro de Excel puede resolver ese problema, probablemente pueda construir una macro para escribir el código (poco probable).
Ahora, en la práctica , si comprende el trabajo y las estimaciones parecen razonables, tiene sentido simplemente expresar cierta preocupación sobre la metodología aprobada, pero luego acepta provisionalmente ver si puede cumplirlas. Más tarde, si el trabajo te lleva más tiempo que las estimaciones, debes informarlo a tus gerentes lo antes posible. Esté preparado para discutir las razones exactas basadas en su experiencia de implementación real. Esperemos que en ese momento su gerente no sea irrazonable y continúe insistiendo en que trabaje con estimaciones generadas mecánicamente.
fuente
Una de las metodologías de desarrollo de software más nuevas es ágil , y uno de los marcos ágiles más 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:
fuente