Estoy trabajando con TFS y establezco los puntos de la historia para todas las historias de usuario utilizando la serie de Fibonacci y establezco la velocidad del equipo. TFS tiene un campo llamado 'Trabajo restante' para la subtarea, es un valor en horas. ¿Se recomienda trabajar con este campo o cómo puedo usarlo porque la filosofía de Scrum es no trabajar con horas exactas, o me equivoco?
Algunos equipos, especialmente aquellos que son nuevos en Scrum, usan una combinación de puntos de historia y horas de tareas.
Los puntos de la historia establecen la capacidad del sprint, pero las horas de tareas permiten que el equipo haga varias cosas:
No todos los equipos encontrarán útiles las horas de tareas. Mucho depende de las circunstancias de su organización y de cuánta experiencia con Scrum tenga el equipo. Estimar tanto en puntos de la historia como en horas de tareas representa un desperdicio y la única razón por la que el equipo debería hacerlo es si obtiene algún valor obvio de este enfoque.
Usar el campo "trabajo restante" no es un problema, siempre y cuando no lo mezcle con puntos de la historia. En mi opinión, ambos no son compatibles entre sí. Sin embargo, aún existe la posibilidad de usar ambos al mismo tiempo para diferentes propósitos, por ejemplo, los puntos de la historia para la velocidad y el "trabajo restante" para los informes. Solo recuerde que puede estar agregando un poco de complejidad (y tal vez, confusión) al equipo cuando usa ambas medidas.
PD: Personalmente me ceñiré a los puntos de la historia cuando no se me requiera hacer un seguimiento del tiempo.
¿Es una buena práctica establecer el trabajo restante de una subtarea?
Una buena práctica es algo beneficioso para ti/tu equipo. La mayoría de las respuestas aquí se centrarán en experiencias personales en lugar de una respuesta canónica.
Dicho esto, es importante recordar uno de los Principios detrás del Manifiesto Ágil :
La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Por lo tanto, si su equipo necesita y se beneficiará del seguimiento de las horas y tiene remanentes a nivel de subtarea, entonces hágalo. Pero evita hacer cualquier cosa con tu equipo porque funciona para otro equipo .
A menudo es una buena idea usar horas en tareas para realizar un seguimiento del trabajo restante y trazarlo en un avance.
La Guía de Scrum solo requiere que un equipo tenga un plan para completar los elementos del backlog seleccionados y pueda comprender fácilmente el trabajo restante .
Horas en tareas : esta es la forma más común de calcular el trabajo restante. Es simple, rápido y tiene muy poco desperdicio. Simplemente actualizar el campo de la tarea en TFS es mínimo al final de cada sesión de trabajo. El beneficio que obtiene en TFS/VSTS es obtener un trabajo pendiente en el acceso web o en los servicios de informes.
Número de tareas : incluso más fácil, pero requiere más disciplina en el equipo para crear tareas discretas que tengan un tamaño más normalizado. En TFS/VSTS, no obtendrá un resumen para esto (a menos que tenga una regla para poner siempre un 1 en cada tarea). Puede obtener este informe en TFS con servicios de informes, pero no en VSTS sin código.
Pruebas de aceptación : puede ser muy efectivo monitorear el trabajo restante en la cantidad de pruebas de aceptación que aún no han pasado. Puede crear un resumen del tablero con una consulta sobre el plan anual para el Sprint y anclarlo a su página de inicio.
El campo Trabajo restante en TFS/VSTS no requiere horas, esa es simplemente la convención. Puede utilizar cualquier valor numérico que desee. Horas, días, unidades nebulosas, lo que sea... siempre que tenga un valor, obtienes las características.
Tengo algunos clientes que usan TFS que establecen un valor predeterminado en la plantilla de proceso para la definición del tipo de elemento de trabajo de la tarea que lo hace más fácil. Esto no está disponible actualmente en VSTS.
Tiago Cardoso