Pivotal Tracker "desaconseja encarecidamente" la estimación de puntos de velocidad para errores y tareas: debe cambiar una configuración y aceptar una advertencia para poder hacerlo.
Explican por qué aquí , pero simplemente no lo entiendo. Aquí hay un extracto:
Al medir la velocidad solo en términos de características, Tracker puede estimar cuánto trabajo real y valioso para el negocio se puede completar en una iteración futura, lo que le permite predecir cuándo se pueden lograr los hitos del proyecto.
Las tareas y los errores toman tiempo. ¿Cómo puede ignorar esto ayudarlo a predecir cuándo se alcanzará un hito?
Digamos que necesita completar tres funciones más para llegar al siguiente hito, y también necesita completar una tarea (porque una de las funciones no se puede iniciar hasta que se termine esa tarea)... ¿Cómo podría descontar el tiempo necesario para la tarea le ayuda a estimar cuándo se alcanzará el hito?
Sé que este hilo es un poco viejo ahora, pero como desarrollador de Pivotal, no estoy completamente de acuerdo con ninguna de las respuestas existentes.
La filosofía detrás de no estimar los errores no es que la reparación de errores no genere valor comercial, es que introducir un defecto en la aplicación y luego corregirlo no representa un impulso neto hacia adelante.
Por ejemplo, imaginemos que dos equipos están implementando el mismo conjunto de funciones en iOS y Android. El equipo de iOS tiene desactivada la estimación de errores/tareas, mientras que el equipo de Android la tiene activada.
Los equipos de iOS y Android estiman la misma historia en 2 puntos. Ambos terminan la historia en la misma cantidad de tiempo, pero en la siguiente iteración, resulta que los dos equipos introdujeron errores con su implementación.
El equipo de iOS solo ha introducido un error. Lo arreglan en una hora.
El equipo de Android ha introducido tres errores y les asigna un punto a cada uno. Tardan un día y medio en arreglarlos.
El equipo de iOS se está moviendo más rápido que el equipo de Android, pero la velocidad de Android ahora es mayor. Esto desbarata la planificación de iteraciones futuras, lo que hace que parezca que el equipo de Android se está moviendo más rápidamente hacia una versión viable, cuando en realidad pueden estar introduciendo errores en su implementación a un ritmo más rápido que el equipo de iOS y, por lo tanto, logrando su objetivo. metas más lentamente.
A veces, sin embargo, hay defectos que no fueron introducidos por su equipo. Tal vez sea una base de código heredada, y el defecto es tan antiguo como las colinas. En este caso, no tiene sentido que esta historia reduzca su velocidad, y probablemente debería registrarla en Tracker como una nueva característica, en lugar de un error.
Por supuesto, depende en última instancia de usted cómo quiere hacer la estimación de la historia. He trabajado con algunos equipos que tenían activada la estimación de errores/tareas, aunque personalmente prefiero tenerla desactivada. ¡El rastreador no te juzgará!
Pivotal Labs está tomando una decisión de marketing con esta elección de diseño. Al abordar el "valor de negocio" como la métrica clave, desestiman implícitamente la importancia del seguimiento de la capacidad del equipo o la programación del proyecto en un sentido más amplio.
Otra forma de ver esto es que están tratando de vender un tablero para los objetivos de gestión en lugar de la planificación de iteraciones. Las preguntas frecuentes de Pivotal Tracker dicen (énfasis mío):
Al medir la velocidad solo en términos de características, Tracker puede estimar cuánto trabajo real y valioso para el negocio se puede completar en una iteración futura, lo que le permite predecir cuándo se pueden lograr los hitos del proyecto [.]
Entonces, su idea es que los errores y las tareas no son trabajo "real" y no agregan valor. No estoy de acuerdo, pero ese es el punto que eligen hacer con su público objetivo. También parecen descartar la idea de que los errores y las tareas consumen la capacidad del equipo, y asumen que el costo de estas tareas no valiosas se puede amortizar con el tiempo, lo que deja a la gerencia libre para concentrarse en establecer objetivos para hitos.
También dicen:
A diferencia de las funciones, los errores y las tareas tienden a surgir con el tiempo y, si bien son una parte necesaria de su proyecto, se pueden considerar como un lastre constante para el resultado de valor comercial: un costo continuo de hacer negocios.
En otras palabras, en lugar de hacer que el costo de los errores y las tareas sean explícitamente visibles para el proyecto, los descuentan para proporcionar un panel de administración que se centre más en la entrega de funciones que en la programación basada en la capacidad. En mi opinión, esto impide el control adecuado del presupuesto del proyecto y las limitaciones de recursos del equipo, pero claramente hay personas que no están de acuerdo.
Para ser justos con Pivotal Labs, le permiten desactivar esta característica incorrecta. Puede asignar puntos a errores y tareas, con la advertencia (¿advertencia grave?) de que es una decisión irreversible para el proyecto.
Si bien no se recomienda, es posible habilitar la estimación de errores y tareas en la configuración del proyecto. Sin embargo, no es posible revertir esa configuración una vez que su proyecto tiene errores o tareas estimadas.
Personalmente, generalmente recomiendo que todas las tareas imputables al presupuesto de un proyecto o que consuman la capacidad del equipo sean muy visibles y debidamente contabilizadas. Con Pivotal Tracker, la elección es suya.
En lugar de invalidar las citas precisas y los enlaces anteriores (probablemente aún pueda encontrar el original en varios archivos de Internet), aquí están los enlaces actualizados de Pivotal Tracker que contienen más o menos los mismos conceptos pero con una redacción diferente e instrucciones actualizadas para cambiar cómo funciona el sistema. se comporta desde sus valores predeterminados.
No estoy familiarizado con Pivotal Tracker. Sin embargo, parece que tu pregunta es más general:
En mi opinión, deberías estimar estos. Pivotal Tracker parece estar considerando que solo las "características" brindan valor a los clientes. Yo diría que corregir errores en producción mejora la experiencia del usuario y ofrece valor. Ver aquí para más. La excepción a esto es que si se encuentran errores en las historias completadas en las pruebas funcionales/de regresión o incluso en las etapas posteriores al lanzamiento, los desarrolladores que los introdujeron deben corregirlos, sin obtener ningún punto de crédito por los mismos.
Del mismo modo, si mejora el rendimiento, la estabilidad o la seguridad, eso también mejora la experiencia del usuario y genera valor. Ver aquí para más.
Al no estimarlos, los barre debajo de la alfombra y corre el riesgo de acumular errores y deudas técnicas.
Otro punto interesante es que para estimar un error, debe comprender por qué no funciona, y eso suele ser lo más largo del trabajo.
Por lo tanto, puede tomar mucho tiempo y especulación para la estimación.
Lo que hacíamos sin Pivotal Tracker era calcular un "valor medio" (basado en el tiempo que tardaba en corregir el error, transformado en puntos), por lo que siempre le daríamos este valor a los errores (y a veces tiene grandes diferencias con la realidad, pero se compensan con el tiempo, ya que reajustamos el valor del error en cada sprint.
wrhall