A los desarrolladores no les gusta estimar. ¿Qué puedo hacer para mejorar el proceso?

Algunas veces incluso hay berrinches al estimar o se toman licencias por enfermedad el día de planificación.

¿Estos son adultos de los que estamos hablando? Tal vez debería preguntarles directamente cuál es el problema con las estimaciones. Creo que tal vez no quieren rendir cuentas cuando no cumplen con las expectativas, ¿es esto cierto? La gente no puede trabajar más duro de lo que puede. Esta es también una buena razón para usar tamaños relativos.

Pregúntese por qué y cómo va a utilizar las estimaciones y comuníqueselo honestamente a los desarrolladores. Creo que el objetivo debería ser obtener un pronóstico, pero lo más importante es iniciar la discusión para hacer las tareas más pequeñas, más simples y crear un terreno común sobre en qué consisten las tareas.

Para facilitar las estimaciones, tal vez use una escala relativa fija con la que todos puedan relacionarse. Me encontré con "El peso abstracto de los casos de uso inteligente" tal como lo usa Smart (descrito en el libro This is Agile ) y se usa en esta presentación de diapositivas .

Peso abstracto de los casos de uso inteligente

1: Pedazo de pastel

2: moderado

3: Promedio

4: Difícil

5: Muy difícil

8: Extremo, pero conocido

10: Extremo y desconocido

Creo que las estimaciones en una escala como esta son más fáciles de comprender que los puntos relativos de la historia. Aún así, deje que todos voten a ciegas y déjelos aumentar la complejidad al mismo tiempo, esto para evitar que se influyan entre sí. Luego analice si las estimaciones no están muy juntas, de lo contrario, solo promedian.

Este problema no se limita solo a los desarrolladores o ágiles o incluso en la industria de TI. Esto atraviesa todas las industrias y todos los tipos de roles.

Proporcionar estimaciones se trata de tratar de predecir el futuro con la mayor precisión y precisión posible y la verdad incómoda es que no tenemos la capacidad de predecir el futuro con ningún grado real de exactitud o precisión.

La condición humana, sin embargo, espera un 100% de exactitud y precisión y cualquier cosa menos está rota e inutilizable. Esperamos resultados definitivos y creemos que realmente tenemos control sobre el futuro. De hecho, nuestro mundo es enormemente probabilístico, poco fiable, impredecible y muy aleatorio. Pero eso no vende, los clientes no compran eso, y cuando sacas las estadísticas, los ojos de todos se nublan.

El problema de obtener estimaciones es la cultura en la que se realizan esas estimaciones. Es la expectativa de un 100 % de exactitud y precisión y las graves consecuencias que tenemos cuando no lo logramos, asumiendo que el equipo falló versus solo un resultado aleatorio dentro de la distribución normal de posibles resultados. Colectivamente, hemos seleccionado con éxito el comportamiento de estimación de nuestro repertorio de comportamiento al recompensar las cosas incorrectas y castigar las cosas correctas.

Si desea cambiar este comportamiento, debe cambiar la dinámica cultural. Buena suerte con eso.

¿Ha intentado enseñarles cómo hacer estimaciones? No vi eso en su lista, y no todos "entienden" automáticamente cómo hacerlo.

Encontré dos razones principales por las que no estaba dispuesto a hacer estimaciones: una era la ansiedad por tener que cumplirlas, pero la otra era que nunca lo habían hecho antes, así que cuando les pregunté "¿cuánto tiempo creen que llevará eso?" ?" respondieron honestamente "No tengo idea". Cuando los presioné, dijeron "¡Bueno, solo estaría adivinando!" (Lo que podría traducirse, al planificar el póquer, en elegir una carta al azar).

Así que hablamos sobre cómo una estimación es una conjetura, pero es una conjetura educada, y todos lo entienden; y luego les mostré aproximadamente el proceso mental que uso para hacer estimaciones, y les dije que, por supuesto, no serían muy buenos al principio si nunca lo habían hecho antes, pero practicaríamos y mejorarían. eso. También contextualicé por qué las estimaciones eran importantes para nosotros como equipo (generar confianza en nosotros mismos y confiar en nuestros grupos de interés de que podremos hacer lo que decimos que podremos hacer), y señalé que aprender hacer estimaciones también es un buen movimiento de desarrollo profesional. (Si las personas que se resisten se inclinan por los "desarrolladores senior", este puede ser un buen argumento para ellos).

Creo que la forma más fácil para que la gente comience a hacer estimaciones es en términos de días ideales de trabajo, es decir, suponiendo que pudiera dedicar el 100% de mi tiempo a esta tarea sin interrupción, ¿cuánto tiempo me llevaría? Los puntos de la historia pueden ser demasiado abstractos para las personas que recién están aprendiendo esta habilidad.

Con respecto a su personal de control de calidad: también descubrí que las personas son reacias a participar en la estimación de tareas en las que no trabajarán directamente, por ejemplo, las personas que trabajan en un subsistema no quieren estimar el trabajo que está contenido completamente dentro de otro subsistema. Mi solución ha sido decir "bueno, has visto cuánto tiempo le toma a la gente del otro subsistema hacer tareas como esa, así que haz tu mejor estimación de esa manera". Todavía son reacios, pero al menos les he dado una rúbrica a seguir.

En este punto, no creo que te quede nada por hacer en el proceso del equipo. Probaría uno o más de los siguientes (sin ningún orden en particular):

• acérquese a cada desarrollador reacio individualmente en privado y pregunte desde una posición de curiosidad, ¿cuál es el problema que tienen para hacer estimaciones?

• acérquese a los gerentes de línea de los desarrolladores reacios (¿suponiendo que no sea usted?) y brinde comentarios que aparentemente necesitan capacitación sobre cómo hacer estimaciones. (Es decir, no entre en "no" y berrinches; concéntrese en "parece que no puede hacer esa tarea", por lo tanto, debe necesitar capacitación)

• acérquese a los gerentes de línea y asegúrese de que sus expectativas de responsabilidades de desarrollo sean consistentes con las de ellos, especialmente. alrededor de la estimación.

Descubrí que los desarrolladores están nerviosos acerca de proporcionar estimaciones (las hemos renombrado estimaciones aproximadas) porque temen que se les pedirá cuentas si subestiman o sobrestiman. Esto crea incertidumbre, miedo y aprensión.

Más recientemente, descubrí que planificar el póquer ayuda al equipo a decidir y obtuve buenas estimaciones de esto. ¿Has probado esto? https://www.mountaingoatsoftware.com/agile/planning-poker

Es como jugar un juego de cartas y puede ser divertido. También le expliqué al equipo por qué necesitamos estimaciones (y eso es todo lo que son: estimaciones) y por qué es mejor para ellos sobreestimar en lugar de subestimar. Necesitan poder dar una estimación con la que se sientan cómodos. Estoy de acuerdo con David Espina aquí. Haz que la estimación sea divertida. Cámbialo para mejor.

Es interesante que las respuestas se refieran a que el equipo no sigue el proceso o necesita capacitación. Hay un movimiento en Agile en torno a #noestimates, ya que existe la sensación de que incluso el uso de puntos de historia tiene sus raíces en la estimación de PM de la vieja escuela.

Si está utilizando INVEST en sus historias (Independiente, Negociable, Valioso, Estimable, Pequeño y Comprobable) piense en lo que pone en la historia, ahora la idea aquí es construir historias de un tamaño similar. Luego puede usar sus métricas para calcular el tiempo promedio para completar y usar eso en lugar de la velocidad (u horas de tareas) en la planificación.

Mira el trabajo que está haciendo Alan Holub. Al final del día, resulta tan preciso como intentar estimar, necesitamos y no necesitamos un compromiso del 10 % por parte del equipo.

Todo lo que ya está haciendo, que ha enumerado anteriormente, es excelente y, aunque hay algunas cosas más que puede hacer, no hay mucho antes de que lo tome en la cadena. Algo que vale la pena hacer:

1. Tener entrenamientos ágiles. Los estudios muestran que cuanto mejor sea un equipo versado en Agile, más lo aceptarán y se convertirán en un mejor equipo.

2. Asóciese con su desarrollador líder para resolver este problema. A veces, cuando parece que un maestro de scrum no puede comunicarse con el desarrollador junior, el desarrollador principal puede hacerlo. Trabajando con su desarrollador líder en el desarrollo de una cultura de equipo que esté abierta a la estimación.

Desafortunadamente, si ninguna de estas cosas funciona, es posible que deba abordar su comportamiento con sus gerentes o con Recursos Humanos. Personalmente, si tuviera un miembro del equipo que hizo una rabieta, no lo dejaría pasar. No solo es poco profesional, sino que da un mal ejemplo para el equipo y si lo dejas salirse con la suya, aprenderá que es una forma aceptable y efectiva de salirse de la estimación.

¡Sin embargo, ese es un último recurso!

Antes que nada; cuando el equipo alcanza los objetivos de negocio; no te preocupes por eso

PERO

Cuando leo los comentarios sobre trabajar durante años con la metodología Agile, sospecho que solo la está implementando parcialmente. Sin planificación de sprint, no está utilizando Agile.

Este sería un buen tema para abordar en las retrospectivas; ya que el proceso claramente se beneficiaría de ello. Cuando la planificación está continuamente en el lado bajo: eso también es algo que debe manejar en la retrospectiva.

Desde la perspectiva de un desarrollador, emitir una estimación invita a la siguiente distribución de probabilidad sobre los resultados:

• 50% de posibilidades de sobrepasar el límite, por lo que no solo tendrás que realizar más tareas, sino que también la gente te verá como un holgazán.
• 50% de posibilidades de fallar, por lo tanto, hacerlo tarde y ser gritado por el gerente
• 0% de probabilidad de haber estimado correctamente
• 100 % de posibilidades de dedicar tiempo a una tarea en la que el esfuerzo del desarrollador no recibe ayuda directa

Entonces, para abolir la codificación y proceder a la estimación, se necesita una zanahoria o un palo.

_{Hablado desde la perspectiva de 4 lugares de trabajo ágiles, en mi humilde opinión, ninguno de los cuales funcionó bien. Uno era un importante fabricante de automóviles alemán. Otra era una empresa de Silicon Valley...}