¿Quién debe participar en la estimación del tiempo?

En un proyecto de TI:

1. ¿Quién debe participar en la estimación del tiempo? Desarrollador, líder de equipo, scrum master, etc.
2. ¿Cuál voto debe contarse más?

No se trata tanto de las personas involucradas como de las habilidades que deben estar presentes:

• Una buena comprensión del dominio del problema: esto es particularmente importante cuando los requisitos son ambiguos o de alto nivel. Como programador que nunca ha trabajado en viajes para estimar el trabajo relacionado con las clases de boletos en un avión y supondrá que hay 3 o 4 (economía, negocios, primero, etc.), pero si ha trabajado en viajes, sabrá que hay docenas Esto puede significar que un analista de negocios o un usuario experto está involucrado, aunque con el tiempo los propios desarrolladores desarrollarán este tipo de conocimiento.

• Una comprensión de la tecnología y el trabajo que implicará, generalmente un desarrollador, aunque un gerente con experiencia reciente que tiene la confianza del equipo, a menudo puede hacer el trabajo. Lo ideal es que consigas a la persona que realmente estará haciendo el trabajo de esa manera, ya que están comprados en la estimación.

• Una comprensión del proceso de estimación: esta es la clave. Debe haber una comprensión de cómo hacer una estimación decente, cómo garantizar que sea correcta, verificar los niveles apropiados de contingencia, verificar el doble recuento o demasiado relleno. Por lo general, un PM, un gerente de desarrollo o un desarrollador sénior traerá esto, aunque en algunos procesos una plantilla de estimación sólida puede proporcionar la orientación necesaria.

Esas habilidades pueden estar en una persona, aunque a veces necesitarán tres o más, pero la clave es asegurarse de que esas habilidades estén presentes, no que personas particulares estén presentes.

Dicho esto, en general, aunque buscaría a más de dos personas, ya que desea la seguridad adicional de que dos o más personas revisan el trabajo de los demás.

En términos de cuyo voto se cuenta más, no funciona así. Es una discusión y una negociación. Si un gerente piensa que la estimación de los desarrolladores es demasiado alta, necesita explicar por qué y desafiar (no presionar) al desarrollador para que lo justifique y deben llegar a un consenso. En caso de que no pueda llegar a ese acuerdo, diría dos cosas por experiencia:

(a) No vaya con el número que "quiere", solo está pidiendo problemas y lo que quiere no tiene un impacto material en la rapidez con que se puede hacer el trabajo.

(b) En casi todos los casos que he visto en los que se ha excedido a un desarrollador en una estimación, el número final se ha acercado más a lo que el desarrollador pensó que quienquiera que haya estado gobernándolos, en gran parte porque ignoraron el punto (a) encima.

(Dicho esto en ágil, creo, y ciertamente en XP, la regla es que los desarrolladores controlan las estimaciones y eso es definitivo. Si los usuarios quieren reducir las estimaciones, tienen que cambiar el requisito para algo más simple).

No sé si hay una respuesta única para esta pregunta. En el lugar donde trabajo, generalmente hay dos ingenieros del equipo que implementarán la función / corrección que proporciona una estimación. Por lo tanto, dos ingenieros proporcionan una estimación "mínima", "máxima" y "esperada". Por lo general, esperaríamos que ambas estimaciones sean razonablemente consistentes, por lo que si son muy diferentes, entonces se requerirá una discusión adicional (tal vez un ingeniero hizo suposiciones de que el otro no, etc.).

En nuestra situación, el "voto" de nadie se cuenta como tal. Por lo general, solo promediamos las dos estimaciones (recuerde, si aún no están en el mismo estadio, entonces rechazamos ambas y comenzamos con las discusiones nuevamente, por lo que tomar el promedio no es un gran salto). Las estimaciones son solo estimaciones, después de todo, por lo que no necesitan ser exactas .

En mi experiencia, las estimaciones tienden a ser realizadas por la persona que probablemente hará la tarea en sí. Los equipos SCRUM deben esforzarse por ser multifuncionales, pero después de un tiempo, ciertos tipos de tareas generalmente las realizan las mismas personas.

Es de vital importancia obtener una aceptación del equipo en todas las estimaciones. Si un desarrollador siente que posee una estimación, trabajará para cumplirla. Si a los desarrolladores se les entrega una estimación de que no lo hicieron ellos mismos y no tuvieron aportes o influencia sobre ellos, no sentirán el mismo nivel de responsabilidad y los sobregiros se explicarán con "Te dije que tomaría más tiempo".

Un proyecto tiene requisitos comerciales y plazos que vienen de arriba hacia abajo. Esas son "estimaciones dadas" para la primera iteración.

Estos requisitos deben dividirse en las tareas más grandes que tienen un costo 100% conocido (como "habilitar el registro" = 2 horas = "descargar log4j / SLF4J y conectar").

La estimación debe hacerse al nivel más alto posible que ya tenga suficiente experiencia técnica para hacerlo.

Las estimaciones corregidas deben volver a subir en la forma de "característica visible del negocio" = "esta cantidad de tiempo" hasta que lleguen al propietario del negocio en un nivel apropiado, capaces de eliminar / cambiar los requisitos o relajar los plazos. Luego vuelve a bajar. Hasta la convergencia final. En la práctica, las personas tienden a ignorar esta fase o simplificarla, lo que a su vez puede crear riesgos asociados con plazos y oportunidades perdidos.

¿Quién o quién debe participar en la estimación del tiempo? Desarrollador, líder de equipo, scrum master, etc.

Prefiero que todos estén allí en tiempo estimado y hacemos lo mismo aquí

¿Quién o cuyo voto debe contarse más?

Desarrollador pero aún se trata de trabajar en equipo nuevamente

¡LOS DESARROLLADORES CARGADOS DE IMPLEMENTAR EL PROYECTO! ¡NADIE MÁS!

Los desarrolladores que realizan el trabajo práctico real y los líderes del equipo de desarrollo son los únicos capaces de estimar adecuadamente cuánto tiempo llevará realmente. Solo los programadores familiarizados con el código base real pueden comprender las posibles dificultades y dificultades que pueden surgir en el curso del desarrollo. Todos los demás son un "espectador".

Además, la única forma en que se puede confiar en los desarrolladores para dar estimaciones precisas es cuando las personas de negocios confían en ellos y confían en su experiencia para que los desarrolladores sepan que no serán penalizados si su estimación no cumple con las expectativas de la empresa.

Regla general: tomará al menos 3 veces más tiempo que la estimación de cualquier gerente de proyecto o persona de negocios que no esté íntimamente familiarizado con los desafíos del desarrollo práctico y la base de código en cuestión.

Como alguien que ha trabajado como desarrollador práctico tanto en forma independiente como como empleado en grandes corporaciones durante casi 20 años, lo digo con la mayor certeza y el beneficio de una gran experiencia amarga.