✊🏿 🔸 🧘🏻 Evaluación de tareas en puntos de historia 💛 👸🏼 ☦️

Casi todas las personas que se han encontrado con el desarrollo de software saben qué es la evaluación de tareas Story Points (SP), sin embargo, ocasionalmente les digo a colegas de otros departamentos o recién llegados al equipo que nunca se han encontrado con este enfoque, por qué usamos SP y por qué es conveniente para el equipo y efectivo para la empresa.

El propósito de este texto es describir qué es SP, cómo usarlos para evaluar problemas y por qué esta técnica se ha generalizado tanto.

Problema

Calcular el tiempo requerido para completar una tarea es una tarea muy simple y muy riesgosa que enfrentan los equipos de desarrollo.

Una evaluación incorrecta se convierte en una de las primeras razones para el desglose de los horarios o incluso el fracaso del proyecto.
El problema es que el negocio ve las valoraciones como pasivos. Los desarrolladores ven las calificaciones como supuestos.

Para ilustrar, citaré un ejemplo de un diálogo ficticio del libro de Robert Martin, The Ideal Programmer.

Mike (Gerente): ¿Cuál es la probabilidad de que pueda administrar en tres días?

Peter (Desarrollador): Puedo manejarlo.

Mike: ¿Puedes nombrar un número?

Peter: cincuenta o sesenta por ciento.

Mike: ¿Entonces hay una probabilidad bastante alta de que necesites cuatro días?

Peter: si. incluso cinco o seis pueden ser necesarios, aunque lo dudo.

Mike: ¿Hasta qué punto lo dudas?

Peter: Oh, no sé ... estoy noventa y cinco por ciento seguro de que el trabajo se realizará en menos de seis días.

Mike: ¿Entonces tal vez siete?

Peter:Bueno, si todo sale mal ... Maldición, si TODO sale mal, tal vez diez o incluso once días. Pero la probabilidad de tal coincidencia es muy pequeña, ¿verdad?

Creo que el diálogo anterior suena bastante familiar para cualquier desarrollador o gerente de proyecto.

Desafortunadamente, los problemas con las calificaciones no terminan ahí. También se deben considerar otras trampas:

Correlación de grado y grado

La calificación dada es válida solo si el autor de la calificación implementará la tarea. Después de todo, es obvio que el tiempo dedicado a la tarea por el desarrollador senior y el interno será diferente.

Una evaluación ideal en un mundo imperfecto.

Las reuniones urgentes, las cartas de trabajo, los mensajeros y un administrador de tareas caído complican aún más el ya complejo proceso de desarrollo, lo que hace que las horas ideales que imaginamos al evaluar sean poco útiles para un gerente de proyecto que intente armar un diagrama de Gantt que envejece rápidamente.

A continuación, consideraremos el enfoque para evaluar tareas en SP y cómo aborda todas las dificultades descritas anteriormente.

Soluciones alternativas

Naturalmente, el enfoque que usa SP no es el primer intento de resolver los problemas expresados, aunque probablemente sea el más popular.

En este bloque hablaré sobre otro programa que incluye un esquema de evaluación de tareas. El programa se llama PERT y no es necesario estar familiarizado con él para lograr el objetivo de los textos, por lo que puede pasar con seguridad al siguiente bloque.

Programa de Evaluación y Revisión Técnica

PERT Program Evaluation and Review Technique 50- XX .

:

O: . .

N: .

P: , , .

:

μ = \frac{O + 4 N + P}{6}

$\mu= \cfrac {O+4N+P} {6}$

, :

σ = \frac{P - O}{6}

$\sigma=\cfrac{P−O}{6}$

, :

\frac{1 + 12 + 12}{6} \pm \frac{12 - 1}{6}

$\cfrac{1+12+12}{6} ± \cfrac{12-1}{6}$

, . , , .

Puntos de la historia

¿Qué son los Story Points y cómo ayudan a evaluar las tareas? Mike Cohn, Agile Evangelist y CEO de Mountain Goat Software, habla sobre esta técnica de manera muy breve y clara.

¿Qué sucede si, en lugar de evaluar el tiempo que lleva completar una tarea, evaluaremos el esfuerzo requerido para resolver este problema? Para hacer esto, tomaremos la escala de calificación y le asignaremos tareas que requieren evaluación.

Al mismo tiempo, todos los factores que pueden afectarlo deben incluirse en la evaluación de los esfuerzos:

La cantidad de trabajo requerido;
La complejidad técnica de la tarea;
Posibles riesgos e incertidumbre en los requisitos;

No parece fácil, pero recordemos que no necesitamos darle una calificación clara a cada tarea, solo necesitamos encontrar su lugar en la escala de calificación entre otras tareas que se evaluarán.

Quiero enfatizar dos aspectos importantes del método Story Points que le permiten resolver los problemas que discutimos en la página anterior:

Evaluación relativa

Las tareas se evalúan entre sí, por lo que surge una escala de calificación universal que no depende de la experiencia del evaluador. Incluso si la tarea es reemplazada por la responsable, su evaluación permanecerá sin cambios, evalúe tareas bastante nuevas en relación con esta escala.

Sustitución de relojes con puntos abstractos

Así que eliminamos del evaluador la necesidad de evaluar la tarea en horas. En cambio, lo evalúa en puntos, por lo que eliminamos las contradicciones en la percepción de la evaluación por parte del desarrollador y el gerente. Además, ahora las distracciones y las circunstancias de fuerza mayor no afectarán la evaluación de ninguna manera, ¡porque no cambian los esfuerzos necesarios para resolver el problema!

Números de Fibonacci, camisetas y perros

Sí, sí camisetas y perros. Puede usar cualquier escala para evaluar tareas. Los más comunes son los números de Fibonacci, estos son valores numéricos claros y también con una buena ventaja: los elementos de esta secuencia reflejan bien el crecimiento de la incertidumbre que surge con la complejidad del problema estimado.

Sin embargo, algunos equipos usan una escala de calificación alternativa. Lo más común es una evaluación en camisetas y perros, cuando la complejidad de la tarea se indica en el tamaño de la camiseta (S, M, L, XL) o en la raza del perro (Chihuahua, Pug, Perro). Por lo tanto, los equipos están aún más abstraídos de la representación numérica de la evaluación, lo que en algunos casos incluso socava la transferencia a una evaluación temporal.

Puntuación del equipo

¿Cuál es la diferencia entre la evaluación del equipo y la evaluación individual?
¿Por qué es importante involucrar a todo el equipo en la calificación?

Uno de los mayores errores que se pueden cometer al evaluar las tareas es hacerlo usted mismo y no pedir las opiniones de los miembros del equipo. Tal vez tienen una opinión sobre esto? ¿Quieres agregar nuevo soporte de navegador? ¿Qué piensa QA sobre esto?

Las personas son el recurso de evaluación más importante. Pueden ver lo que tú no ves.

Pero, ¿cómo realizar una evaluación del equipo? Simplemente gritar calificaciones no es muy efectivo, además, después de haber escuchado su calificación, otro miembro del equipo puede cambiar de opinión y no expresará la suya.

Planificación de póquer

En 2002, James Granning describió un método que más tarde se hizo tan popular que ahora incluso puedes comprar barajas de cartas reales para la planificación del póker. O use uno de los servicios en línea para la sesión;

La esencia del método es la siguiente: todos los participantes del equipo reciben cartas con números de la escala de calificación. Luego se selecciona una tarea y se discuten sus requisitos. Después de la discusión, el moderador pide a todos los miembros del equipo que elijan una tarjeta y la pongan al revés. Luego, el moderador da una señal para mostrar las cartas.

Si las calificaciones de los participantes son consistentes, la calificación es fija, de lo contrario, las tarjetas se devuelven a la mano y los miembros del equipo continúan discutiendo el problema. Es una buena idea preguntar a quienes tienen calificaciones diferentes: "¿Qué dificultades ves en esta tarea?" o "¿Por qué crees que durante la implementación no habrá problemas?".

Vale la pena señalar que el consentimiento no debe ser absoluto. Puede aceptar que un conjunto de calificaciones vecinas también se considere un consentimiento.

Alternativas

Al igual que el método de evaluación en sí, la planificación del póker tiene alternativas. Hablaré brevemente sobre uno de ellos.

Puede omitir este bloque e ir directamente a la página siguiente.

Calificación afín

« . , . , . — . , , , .

, . , . .

, , .

, „“ .

Planificación de proyectos

¿Cuántas horas hay en Story Point'e y cómo construyo un diagrama de Gantt?

Por lo tanto, apreciamos nuestra acumulación de tareas, pero no puede crear un plan de proyecto en Story Point'ah. A menudo, el gerente del proyecto tiene una pregunta: "¿Cómo traducir SP en horas?"

La respuesta corta a esta pregunta es: "De ninguna manera".

Por supuesto, puede seguir a los desarrolladores con un cronómetro y registrar el tiempo que les tomó resolver el problema, y luego mostrar esta información en un gráfico. Luego obtienes la clásica "campana", como en el ejemplo en el bloque a continuación. Como vemos en la primera figura, algunas tareas toman un poco más de tiempo, otras un poco menos, pero en general, el valor total corresponderá a alguna distribución normal.

Lo mismo es cierto para las tareas en 2 SP y esto se muestra en la segunda figura. ¿Has notado que las “colas” de los gráficos se cruzan? Sí, algunas tareas clasificadas en 1 SP pueden requerir más esfuerzo que las tareas más simples clasificadas en 2 SP. Al final, ningún equipo ha aprendido a evaluar perfectamente. Además, traduciendo el SP a horas, volvemos al viejo rastrillo, cuánto tiempo necesitará el desarrollador para resolver un problema específico depende en gran medida del desarrollador.

Pero qué hacer, no podemos abandonar por completo la planificación. Afortunadamente, para esto no necesitamos traducir cada punto de historia en horas. Lo que realmente importa es cuánto SP puede "cerrar" el equipo de desarrollo para el sprint (iteración, lanzamiento).

Al recopilar datos sobre la velocidad del equipo, puede obtener datos suficientemente precisos para la planificación de proyectos a largo plazo. Además, no se olvide de la ley de los grandes números, los errores de estimación se compensan mutuamente, esto se aplica tanto a las tareas como a las iteraciones. Vale la pena señalar que esto es un poco optimista, porque Las inexactitudes generalmente se asocian con la subestimación en lugar de la revaluación. Pero nada es perfecto.

La velocidad (o velocidad) es una poderosa herramienta de planificación y la métrica principal del equipo de desarrollo. El equipo debe trabajar en la mejora continua para aumentar su velocidad. No olvide que la velocidad es un derivado de SP y, por lo tanto, también es relativa. No se pueden comparar dos equipos entre sí, el equipo compite consigo mismo.

imagen

Práctica

¿Qué matices necesitas saber?
¿Qué errores se pueden evitar?

En conclusión, quiero recopilar algunos consejos para aquellos que por primera vez decidieron probar las técnicas descritas en su trabajo.

Por dónde empezar

Esta es su primera planificación de póker y el equipo no entiende qué evaluar nuevas tareas. Reúna algunas tareas ya completadas, idealmente bien conocidas o típicas, y evalúe su complejidad entre sí. Use estas tareas para evaluar otras nuevas.

¿Tiene un nuevo proyecto y no ha completado tareas? Intente usar la calificación afina descrita anteriormente y asigne tareas a la escala de calificación.

No promediar calificaciones

A veces, cuando dos miembros del equipo han evaluado la tarea de manera diferente, es tentador asignar el puntaje promedio a la tarea y seguir adelante. No ceda ante esta tentación, la discusión es un elemento importante de evaluación, durante el cual el equipo puede revelar características previamente desconocidas en la implementación de la tarea.

Pero, como se mencionó anteriormente, siempre puede estar de acuerdo en que las estimaciones cercanas entre sí no serán motivo de mayor discusión.

No cambie las calificaciones,

incluso si durante la implementación se dio cuenta de que cometió un error durante la planificación, deje la calificación sin cambios. Te equivocarás en el futuro y en ambas direcciones. Deje que estos errores se compensen entre sí, no interfieran con el proceso.

Calificación de error

Encontré diferentes enfoques para evaluar errores. Algunos equipos evalúan todos los errores, excepto los que surgieron durante la implementación de nuevas tareas en iteración. Algunos no evalúan los errores, justificando esto por el hecho de que la velocidad del equipo debería mostrar un nuevo valor agregado al producto, y corregir los errores no debería afectar el crecimiento de este indicador.

Cualquiera sea el enfoque que elija, manténgase constante. La información sobre la velocidad histórica del equipo no debe verse afectada por el uso de diferentes enfoques para la evaluación.

Calificaciones cero

Otra pregunta que no tiene una respuesta clara. Alguien cree que no hay tareas que no requieran esfuerzo. Otros les responden que asignar puntos a tareas simples conduce a un aumento irrazonable en el gráfico de velocidad del equipo.

Puede ingresar un puntaje de 1/2 punto para tales tareas y monitorear retrospectivamente si la proporción de tales tareas excede los límites razonables. Pero el consejo principal es el mismo, mantente constante en tus decisiones.

Reevaluar tareas no finalizadas entre iteraciones

No siempre es posible completar una tarea en una iteración, incluso si se planeó originalmente. Sin embargo, no debe cambiar su evaluación al planificar la próxima iteración en función de la cantidad de trabajo restante. Tenga esto en cuenta cuando planifique, pero deje la estimación sin cambios para la historia.

Calificaciones retrospectivas

Si aún no está realizando retrospectivas, ¡es hora de comenzar! Esta es una gran herramienta de equipo para aumentar la velocidad y coherencia del equipo. Sin embargo, este es un tema aparte.

En el curso de sus retrospectivas, repase las estimaciones realizadas durante la planificación de la iteración y discuta si hubo grandes desviaciones entre las expectativas y la realidad.

También puede obtener varios problemas de la historia con las mismas calificaciones y discutir si todas estas historias realmente requieren la misma cantidad de esfuerzo.

Registre todo.

Si su sistema de gestión de tareas no admite clasificaciones y no calcula automáticamente la velocidad del equipo, deberá hacerlo manualmente. Como probablemente ya haya adivinado, los datos históricos son una herramienta importante para mejorar sus calificaciones.

Evaluación de tareas en puntos de historia