El propietario del producto desea realizar un seguimiento de cuántos puntos se gastan en errores durante un sprint. Esto puede generar algunos problemas, tales como:
Puntuación de una tarea que ya está hecha. Sorprendentemente, incluso una vez hecho, a veces hay discusiones y divergencias.
Puntuar muchas tareas pequeñas con 0 puntos que al final en realidad se resumen en algo significativo (un montón de soluciones rápidas).
Contar los puntos gastados en errores como puntos disponibles para nuevas funciones en el próximo sprint, junto con nuevos errores que eventualmente aparecerán.
Estoy de acuerdo con él en que es importante hacer un seguimiento del tiempo que se dedica a ello, pero los puntos no parecen funcionar muy bien en este caso. Entonces, ¿cuáles son los mejores enfoques y prácticas en este caso? ¿Cuenta las horas dedicadas a cada uno?
Lo primero que hay que recordar es que los puntos != tiempo ; Los puntos son una estimación relativa de la complejidad. Si bien podría tener una idea de las horas invertidas por punto utilizando la duración del sprint y la velocidad, ese no es el propósito.
La forma en que normalmente manejo la planificación de sprints para un entorno en el que los clientes inevitablemente informarán errores en el software en producción es asumir que se gastarán n puntos por sprint en errores. Esto va junto con el ejemplo de Mike Cohn en el que uno podría escribir una historia como "Como usuario, quiero que se corrijan al menos 15 errores".
La mejor situación es cuando el error informado no garantiza una solución inmediata y sus sprints son cortos, de modo que el "error" en realidad solo se puede contar como una historia para el próximo sprint. Pero "mejor" y "común" no son lo mismo...
Realmente trataría de llegar al corazón de lo que busca el propietario del producto: ¿es necesario ver que los errores se corrigen? ¿Necesita ver si se dedica más esfuerzo a los errores que a las características? - y planifique en consecuencia a partir de eso, en lugar de tratar de encontrar lo que podría ser una respuesta totalmente artificial a "cuántos puntos se gastan en errores".
La mayoría de los equipos no otorgan ningún punto por resolver la deuda técnica. La cuestión es que si agrega puntos para resolver errores en el código que ya se habían estimado con puntos de historia, está asignando puntos de historia para "hacer el trabajo" y no para "obtener resultados", lo que puede ser una diferencia sutil pero importante.
Los puntos Velocity y Story son una forma de medir qué tan rápido un equipo puede crear nuevas funciones de trabajo en incrementos de trabajo liberables.
En un proyecto, esto podría conducir a un equipo cuya velocidad disminuirá cada vez más con el tiempo, porque todo el tiempo se dedica a resolver la deuda técnica. Esto es bueno de alguna manera extraña, porque muestra que el código base actual no puede ofrecer un nuevo valor comercial en forma de nuevas funciones en el futuro cercano. Esto conducirá a una reescritura y las lecciones aprendidas conducirán a una arquitectura más escalable.
No todo tipo de dolor es malo.
Parece que tu equipo juega dos roles:
La técnica de estimación podría usarse para ambos, las estimaciones del equipo Scrum antes de la iteración, en apoyo, tiene una iteración de 1 día en lugar de 2 semanas.
Es difícil estimar las tareas de soporte en comparación con los EE. UU. habituales, son mucho más pequeñas. No compara EE. UU. con la tarea de soporte, entonces, ¿por qué está tratando de hacerlo en la dirección opuesta?
Trate de estimar las tareas de apoyo frente a las tareas de apoyo .
jcmeloni
eMgz