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

12

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

77

¿Qué significa "aceptar" una "estimación"? Si estima que me llevará 30 días hacer algo, ¿qué sucede si lo "acepto"? ¿Qué me importa cuánto tiempo estima que me llevará hacer algo? Puedes estimar que lo haré en un minuto por todo lo que me importa, estarás equivocado, no yo.

— David Schwartz

2

@David Aceptar una estimación generalmente se refiere a revisar las estimaciones y garantizar el consenso. Por ejemplo, si se utiliza una herramienta de estimación paramétrica, hacer que los ingenieros del proyecto revisen esos datos para garantizar la coherencia, tal vez utilizando una segunda metodología como Wideband Delphi.

— Thomas Owens

12

Suena como algo que debería enviarse a Scott Adams para una caricatura de Dilbert.

— MetalMikester

1

Mientras haya una revisión. En este ejemplo particular no había ninguno.

— Nelstaar

55

Recuerde: una estimación, un compromiso, un objetivo y un plan para alcanzar un objetivo son cuatro cosas diferentes. Asegúrese de que todos tengan claro cuáles son esas cosas y cuál de esas cuatro cosas es la salida de Excel.

— nlawalker

14

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.

— Péter Török
fuente

7

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.

— Steve
fuente

Las pruebas se dividen en sub-sub-partes (casi atómicas) y se obtiene una pequeña estimación.

— Nelstaar

Creo que con este método, el probador final no ve / prueba el panorama general.

— Nelstaar

1

"Presumiblemente, la macro está operando en algún tipo de datos de entrada, no es solo un generador de números aleatorios" También podría ser aleatorio porque no es una forma de capturar CADA variable que haría que dicho algoritmo sea preciso.

— maple_shaft

1

@maple_shaft: Es por eso que lo llaman una estimación : no se espera (o no se debería) que sea precisa. Si estima usar algunos cálculos en Excel, o con lápiz y papel, no hace ninguna diferencia. Usar Excel para estimaciones tiene mucho más sentido que algunas otras 'técnicas' que he visto en uso ...

— Treb

Los estimados de @Treb deben ser tan precisos como lo permitan los datos proporcionados y el estado actual del proyecto, dado el Cono de incertidumbre.

— Thomas Owens

5

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?

— Bruce Ediger
fuente

1

No he leído esos documentos completos (todavía), pero los métodos paramétricos se han utilizado ampliamente para estimar proyectos de software dentro del 15% durante más de 20 años, suponiendo que los datos de entrada sean válidos. Además, los métodos de colaboración como Wideband Delphi pueden (y se han utilizado) para confirmar la precisión de los modelos paramétricos. Consulte Software Engineering Economics (Boehm) para obtener una discusión sobre los métodos paramétricos y la aplicación de Wideband Delphi en proyectos de software (con y sin modelos paremétricos también).

— Thomas Owens

Estoy de acuerdo con Thomas Si bien no puede predecir con precisión cada tarea para un proyecto completo, en el transcurso de un proyecto y utilizando datos históricos para una organización específica, puede ingresar al estadio. Algunas tareas tomarán más tiempo y otras más cortas, pero al final se promedian. Particularmente si el proyecto es similar a los ya realizados por la organización. Dicho esto, las estimaciones no pueden explicar cosas inesperadas realmente malas, como el hardware / software no funciona como se anuncia, las nuevas tecnologías son mucho más difíciles de lo previsto, la escasez de desarrolladores, el liderazgo y la gestión deficientes.

— Dunk

1

Ustedes necesitan leer y comprender el periódico. Una macro de hoja de cálculo simple no tiene la posibilidad de estimar correctamente. El software es matemático, y los sistemas matemáticos a veces están sujetos a un pequeño problema conocido como incompleto. Le garantizo que el gerente en cuestión se está engañando a sí mismo y que los resultados de la macro no se correlacionan con la realidad.

— Bruce Ediger

1

@Bruce: Habiendo utilizado la fórmula (incluidas las hojas de cálculo de Excel) para la estimación del proyecto con éxito, ciertamente puedo afirmar que ni Thomas, ni el Gerente ni yo mismo nos estamos engañando necesariamente. Como dije, cada tarea individual variará, pero en el transcurso de un proyecto tienden a equilibrarse. Descubrí que el uso de fórmulas (desarrolladas y modificadas con el tiempo) ha sido mucho más preciso que las estimaciones de desarrolladores individuales. En general, los desarrolladores son demasiado optimistas o demasiado pesimistas. Por supuesto, las fórmulas solo funcionan cuando se proporcionan datos razonables, la habilidad es ciertamente un factor.

— Dunk

Leí esos papeles anoche. Van en contra de más de 40 años de evidencia en gestión de proyectos y más de 30 años de evidencia en gestión de proyectos de software. Ver iiasa.ac.at/Admin/PUB/Documents/RM-75-071.pdf y sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

— Thomas Owens

4

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?

— ozz
fuente

1

El 99% de los desarrolladores ni siquiera pueden llegar a estimaciones erróneas basadas en algo objetivo y mucho menos estimaciones precisas. Así que no veo nada que indique "olor a trabajo" porque a alguien más se le ocurrió una estimación. Particularmente si usaron datos reales para justificar sus números. Si las personas son responsables de cumplir con la estimación de cada tarea, entonces es un problema de olor a trabajo. Sin embargo, si la herramienta subestimara enormemente todas las tareas, todos los desarrolladores se perderían las estimaciones. OTOH, si todos los demás parecen cumplir con la mayoría de las estimaciones y otro desarrollador nunca lo hace, entonces es un problema de olor del desarrollador.

— Dunk

@Dunk: mi punto es que la microgestión en este grado en el desarrollo de software es un "olor a trabajo" y no me gustaría trabajar allí.

— ozz

1

lo que llama microgestión es la única forma de hacer negocios en muchas industrias. Si no puede obtener estimaciones razonables de costos y cronogramas para grandes proyectos, entonces su empresa tendrá un trabajo muy difícil para obtener contratos. Contrariamente al ideal ágil, los clientes en muchas industrias no se comprometerán con contratos de decenas de millones de dólares si no saben lo que obtendrán al final. No estarían contentos con la idea de que su dinero se ha ido, tienen un producto que funciona, pero solo hace el 50% de lo que necesitan o desean.

— Dunk

@dunk: si está contento con que la gerencia produzca estimaciones para usted, continúe. Prefiero que el equipo de desarrollo produzca estimaciones. Las estimaciones de gestión ridículas (junto con los requisitos constantemente cambiantes, una discusión completamente diferente) son la razón por la cual muchos proyectos de software no se entregan a tiempo y dentro del presupuesto programado. Prefiero confiar en las personas que hacen el trabajo.

— ozz

No se trata de que la gerencia haga estimaciones o que las personas que realizan el trabajo elaboren las estimaciones. Se trata de sacar estimaciones de su trasero o intentar basar sus estimaciones en algunos datos objetivos. Según mi experiencia, al comparar las estimaciones de gestión con las estimaciones de los desarrolladores, descubrirá que las estimaciones de gestión tienden a generar tiempos más largos. Los desarrolladores tienden a ser optimistas .....

— Dunk

3

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.

— árbol de arce
fuente

1

Eh, solo porque el gerente esté generando estimaciones para los desarrolladores no significa que sean inexactos y realmente no podemos sacar esa conclusión sin más información. Si el gerente es competente, debería reconocer las cosas realistas versus las poco realistas y ajustar las cosas en consecuencia con bastante facilidad.

— rjzii

1

@Rob, está olvidando el punto clave que hizo el OP, que están sujetos a estas estimaciones (asumido estrictamente porque el desarrollador anterior en el equipo mencionó "no quería que se mantuvieran las estimaciones" y fue reasignado). No hay nada de malo en los modelos de estimación, pero deberían ser una guía aproximada y nada para "mantener a los desarrolladores", lo que desafortunadamente he visto que la gerencia le hace a MUCHAS personas.

— maple_shaft

2

Aquí el problema era que estas estimaciones se movían directamente en la factura del cliente. ¿Por qué algunos gerentes siguen llamándolo estimaciones?

— Nelstaar

@maple_shaft: sin saber cuáles son las estimaciones, es difícil decir si no fueron razonables y, por lo tanto, las objeciones a que se les mantuvieran eran válidas. Si se tratara de estimaciones justas (es decir, "Ocho horas para escribir Hello World"), entonces no hay problema en retenerlos más allá de la filosofía.

— rjzii

3

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.

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.

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 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.

¿Son confiables los resultados de estas pruebas?

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.

— Thomas Owens
fuente

3

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 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.

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

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.

— rjzii
fuente

Estoy de acuerdo en que este método puede / podría usarse siempre que haya un diálogo entre los actores del proyecto.

— Nelstaar

1

@Nelstaar: casi todo lo que he leído sobre gestión y estimación de proyectos implica un diálogo en ejecución y ajustes a medida que pasa el tiempo. Por lo general, las estimaciones más confiables tienen una probabilidad asociada con ellas con respecto a las probabilidades de alcanzar el objetivo indicado (es decir, 90% de probabilidad de que la tarea tome 8 horas).

— rjzii

2

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.

— JeffO
fuente

+1 por dar comentarios mientras se trabaja en las tareas en lo que respecta a las estimaciones.

— rjzii

1

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.

— Clemente Herreman
fuente

1

Debes preocuparte de dónde viene la estimación. Un modelo paramétrico con entradas válidas y razonables, un generador de números aleatorios, un estudiante de informática de primer año, un ingeniero de software con 5 años de experiencia con menos de 6 meses en el dominio y un ingeniero de software convertido en gerente de proyecto con 25 años de experiencia en el dominio todos tienen una capacidad diferente para producir una estimación efectiva. Esto también se remonta a un comentario que hice sobre una respuesta anterior sobre la responsabilidad ética / profesional de un ingeniero de software para representar, defender y cuestionar las estimaciones de manera adecuada.

— Thomas Owens

Exactamente: lo más importante es discutir la estimación. Con mucho gusto aprobaría el uso de macros de Excel si las estimaciones que hizo fueran más frecuentes que un ingeniero de 25 años de experiencia. Lo importante es la estimación, y la explicación que la conduce (carga de trabajo, recursos disponibles, dificultad), no por quién o qué se anunció.

— Clement Herreman

¿Estás de acuerdo conmigo diciendo que tu respuesta es incorrecta? Dadas las mismas entradas (como carga de trabajo, recursos, dificultad, etc.), quién es tan importante como qué y por qué. Todo se reduce a un factor de confianza. Confío en COCOMO (hecho y mantenido por algunas mentes líderes en la estimación de costos de software) más que en una macro de Excel (hecha por alguien con experiencia y conocimiento limitados en la estimación de costos, mucho menos en el dominio de la aplicación). Se trata del panorama general para establecer qué tan confiable es esta estimación.

— Thomas Owens

No no, supongo que no estoy lo suficientemente claro. Realmente no es importante quién hizo la estimación. Lo importante es la precisión de la estimación. Cada vez que obtengo una estimación, la comparo con lo que estimaría, luego la discuto con mi gerente de proyecto si estoy de acuerdo o no. Si su argumento es lo suficientemente bueno, entonces estoy de acuerdo con ellos y acepto la estimación. ¿Ver? Nunca he hablado ni pensado quién calculó.

— Clement Herreman

¿Cómo se determina la precisión si no sabe quién calculó y qué métodos utilizaron? Podría dar los mismos datos a dos personas: uno es un estudiante de ingeniería de software de primer año que está tomando su primer curso de informática y el otro es un ingeniero de software senior con 15 años de experiencia y 5 en el dominio. Ambos usan los mismos métodos de estimación (no lo olvides; a menudo, las entradas también son estimaciones). El estudiante puede decir que tomará 6 meses con un 95% de confianza. El ingeniero senior puede decir que llevará 15 meses con un 80% de confianza. Confiaría más en el ingeniero sénior.

— Thomas Owens

1

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.

— PeterAllenWebb
fuente

-1

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:

Un gerente que no sea desarrollador no puede estimar el tiempo requerido para hacer un trabajo
Estimar el tiempo requerido para hacer cualquier trabajo necesita algo de inteligencia humana, que Excel no tiene
Al aceptar tales prácticas de trabajo, el gerente se acostumbra progresivamente a reemplazar a los desarrolladores en los tiempos estimados. Esto puede provocar 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 usted y a John les lleva 3 semanas lograrlo.

— Saeed Neamati
fuente

55

El OP no menciona que el equipo de su amigo utilice métodos ágiles. No creo que las reglas ágiles tengan ninguna relevancia para los equipos que usan otros métodos (o ningún método). Sin embargo, el sentido común debería :-) Además, es obvio que no fue Excel el que decidió las estimaciones, solo ejecutó algunos cálculos basados en supuestos y datos (desconocidos para nosotros) (cada uno de los cuales puede ser correcto o incorrecto) . Si ingreso estimaciones para una tarea determinada por cada uno de los miembros de nuestro equipo, luego configuro Excel para calcular el promedio de estas, ¿Excel está haciendo la estimación?

— Péter Török

3

1 y 2 son evidentemente falsos. Los modelos de estimación paramétrica son ampliamente aceptados en la gestión de proyectos de software y lo han sido durante más de 20 años, y cualquier persona con capacitación en gestión de proyectos (ingeniero de software o no) puede recibir capacitación para usar estas herramientas, suponiendo que ellos (o, preferiblemente, los ingenieros de proyecto ) pueden proporcionar estimaciones precisas de las entradas.

— Thomas Owens

3

-1 - Esto no responde a la pregunta, tiene errores obvios ("... las nuevas metodologías de desarrollo de software son ágiles") y no parece agregar nada relevante. No estoy seguro de para qué fueron los votos a favor o la respuesta aceptada.

— Morgan Herlocker

1

ciertamente no sabemos de la pregunta si la estimación paramétrica es la norma en esta empresa y / o si se basa en una buena historia para su negocio; Si ese es el caso, por mucho que odie decirlo, la negativa a hacer el trabajo de acuerdo con los procedimientos operativos aceptados por la organización (sin seguir un camino razonable de cuestionamiento) es imprudente.

— StevenV

2

@Thomas Estoy de acuerdo, solo creo que hay mucho que no sabemos sobre la situación para responder categóricamente Sí o No. En cualquier caso, la negativa rotunda sin una buena discusión para asegurarse de que la situación y el razonamiento se entienden rara vez es un problema. Buen movimiento profesional.

— StevenV