Puntos de historia para tareas de corrección de errores: ¿Es adecuado para Scrum?

Me pregunto si deberíamos asignar puntos de historia a las tareas de corrección de errores o no. JIRA, nuestro software de seguimiento de problemas, no tiene un campo de puntos de historia para problemas de tipo Bug (es solo para Story sy Epic s).

¿Deberíamos agregar el tipo de problema de error a los tipos de problema aplicables del campo Puntos de historia ? ¿Cuáles son los pros y los contras? ¿Sería adecuado para Scrum?

Idealmente, su software debe estar libre de errores después de cada iteración, y la corrección de errores debe ser parte de cada sprint, por lo que el trabajo requerido para corregirlos debe considerarse al asignar puntos de historia (es decir, una tarea que es más probable que produzca errores) tener más puntos de historia asignados).

Sin embargo, en realidad, los errores aparecen todo el tiempo después del despliegue, sin importar cuán rígidas sean sus pruebas; cuando eso sucede, eliminar el error es solo otro cambio, una característica si lo desea. No hay una diferencia fundamental entre un informe de error y una solicitud de función en este contexto: en ambos casos, la aplicación muestra un cierto comportamiento, y el usuario (o alguna otra parte interesada) quisiera verlo cambiar.

Desde una perspectiva empresarial, las correcciones de errores y las características también son las mismas, realmente: o lo haces (escenario B) o no (escenario A); ambos escenarios tienen costos y beneficios asociados, y una persona de negocios decente los sopesará e irá con lo que les genere más ganancias (a largo o corto plazo, según la estrategia comercial).

Entonces sí, por supuesto, asigna puntos de historia a los errores. ¿De qué otra manera va a priorizar errores frente a características y errores contra errores? Necesita una medida de esfuerzo de desarrollo para ambos, y será mejor que sea comparable.

El mayor problema con esto es que las correcciones de errores son a menudo más difíciles de estimar: el 90% o más del esfuerzo real radica en encontrar la causa; Una vez que lo haya encontrado, puede llegar a una estimación precisa, pero es casi imposible juzgar cuánto tiempo llevará la búsqueda. Incluso he visto una buena cantidad de errores en los que pasé la mayor parte del tiempo intentando reproducir el error. Por otro lado, dependiendo de la naturaleza del error, a menudo es posible limitar la búsqueda con una investigación mínima antes de hacer una estimación.

La estimación de errores con puntos es intrínsecamente difícil, como ya se señaló en otras respuestas, y sí, la solución ideal es que los errores encontrados en una función DESPUÉS de que se haya aceptado el sprint se consideren nuevas funciones .

Sin embargo, esta dificultad en la estimación puntual de errores es una de las muchas razones por las que los paquetes de software Agile PM permiten que las tareas y los errores se estimen en horas, ya que se necesitan conocimientos y experiencia para ser expertos en la estimación puntual. Muchos proyectos se encuentran con problemas importantes para determinar la velocidad de manera adecuada, por lo que muchos proyectos ágiles usan puntos para determinar qué historias llegan al sprint, sin embargo, usan horas al calcular el gráfico de la carga .

Parece contrario a la intuición pero manejable siempre que la estimación de horas no se use como un factor para determinar el compromiso de sprint. El compromiso excesivo conducirá naturalmente a características perdidas o incompletas o tiempo extra, por lo que con el tiempo todos los involucrados se ven obligados a mejorar en la estimación puntual, momento en el que estimar las horas en tareas y errores se convierte lentamente en una métrica sin sentido.

No debe dar puntos a la resolución de errores. Considere el hecho de que el error surge de una historia en la que los desarrolladores ya ganaron puntos por completar la historia. No debería recibir puntos nuevamente donde en realidad no debería haber ganado los puntos para empezar.

La corrección de errores debería tener un efecto negativo en la velocidad. De lo contrario, la caída de calidad termina siendo recompensado con una velocidad no afectada o incluso mayor.

Quizás un enlace útil:

http://www.infoq.com/news/2011/01/story-points-to-bugs

Recomendaría tratar el error como una historia de usuario y asignarle varios puntos. No necesariamente lo escribiría en el formato de "Como una X, quiero Y para que Z" como es común con las historias de los usuarios; lo escribiría más como "Como una X, cuando IY, Z sucede, pero Z 'es el comportamiento esperado ".

La ventaja de esto es que le permite priorizar las correcciones de errores junto con las nuevas solicitudes de características. La verdad es que a veces, una nueva característica es más importante que corregir un error. Sin embargo, también le permite dimensionar adecuadamente el trabajo requerido, lo que le permite ajustarlo en un sprint cuando tenga la capacidad de hacerlo.

Una cosa a tener en cuenta es que puede ser difícil estimar el esfuerzo necesario para corregir un error. Podría involucrar múltiples componentes que interactúan entre sí, lo que requiere que alguien se familiarice con las interacciones de grandes partes del sistema o que varias personas trabajen en la solución.

La estimación de historias se basa en la noción de que, con el tiempo, un equipo gana experiencia para resolverlas. Con ella se mejora la precisión y se puede establecer la velocidad para medir la velocidad de un equipo. Una metodología perfecta para establecer pronósticos confiables para futuros sprints.

Los errores son una realidad para una empresa de desarrollo de software. Si bien estoy de acuerdo en que todos los errores deben detectarse durante el desarrollo de una historia, aceptar que esto no se puede lograr en todo momento, debe ser algo que todo equipo debe planificar. En lugar de pensar obstinadamente que el proceso debería gobernar al equipo, debería ser al revés.

Por supuesto, error o historia, desde el punto de vista comercial, no importa con qué esté tratando el equipo. Ambos pueden producir una cantidad igual de valor para el propietario del producto.

En nuestro equipo hemos experimentado algunas técnicas para estimar errores:

1. Estimando errores completamente desconocidos
2. Solo estimar errores que ya fueron analizados
3. Asignar tiempo para la corrección de errores y no estimar errores, sino clasificarlos únicamente en función del valor comercial

Con 1. hemos fallado miserablemente. Para la mayoría de los errores, hemos encontrado que el 90% del tiempo se dedica al análisis de errores. Después de eso, la corrección de errores se puede estimar de la misma manera que una historia. Al planear los errores en un sprint, cometimos el error de que el alcance desconocido impactó la resolución de la historia hasta el punto en que casi todos los sprints que hicimos de esta manera fallaron.

La opción 2 de la técnica de estimación de la relación 90/10 (análisis a corrección de errores) significaba que teníamos que planificar el análisis, que no era algo que estuviera cubierto para la planificación del sprint (habíamos aprendido de la opción 1, pero no teníamos una solución real cómo seguir con errores analizados). El resultado fue que el análisis de errores no se realizó ya que un sprint se centró en los elementos planificados. El equipo no tuvo tiempo para concentrarse en los errores del trabajo atrasado. Así que eventualmente tampoco se hicieron.

Al abrazar la incertidumbre, ahora nos hemos decidido por la opción 3. Hemos dividido el trabajo atrasado del producto en una parte normal de la historia / tarea que el equipo puede estimar utilizando puntos de historia y un trabajo atrasado de errores. En la acumulación de errores, el propietario del producto clasifica los errores en función del valor comercial y el juicio muy brusco del equipo. El equipo permite asignar una gran cantidad de tiempo durante un sprint que puede dedicar a enfocarse en los errores. El propietario del producto no conoce el resultado exacto, ya que no era posible planificar eso de todos modos antes. La proporción de la acumulación de errores con respecto a la acumulación normal se puede ajustar para cada sprint dependiendo del estado actual de cada acumulación y la importancia y el valor comercial del contenido.

Al eliminar la incertidumbre, liberó nuevamente al equipo. Los sprints no fueron comprometidos por errores desconocidos. Al separar los errores en una cartera diferente, aumentaron el enfoque de sprint regular del equipo y nos hicieron terminar los errores que también contenían un valor comercial significativo.

Por lo tanto, depende de si los puntos de la historia son adecuados para usted. Intentaría estimar los errores usando los puntos de la historia primero. Si eso falla, pruebe mi opción 3. Ha hecho que nuestro equipo (más de 30 sprint de edad) se enfoque nuevamente en errores más antiguos que contienen un gran valor comercial. También nos ha liberado de tratar de entregar algo que el equipo simplemente no puede estimar. Fue abrazar lo desconocido lo que nos acercó a la realidad y también hizo que nuestros sprints fueran exitosos nuevamente al tiempo que entregaba una gran parte (basada en la relación error / historia) del valor comercial a través de correcciones de errores. La proporción que usamos recientemente fue 50/50.

Tengo que estar en desacuerdo con la respuesta principal de asignar puntos de historia a errores. Los puntos de la historia deben ser por el nuevo valor entregado. Si va a asignar puntos al valor del producto y a los artículos sin valor, también podría estimar y realizar un seguimiento de las horas.

Los errores son la sobrecarga de lo que hiciste ayer y no son indicativos de la velocidad de finalización del producto, y tampoco crean ningún valor de producto nuevo (piénsalo). Los errores son como interrupciones y todos los demás pasteles de vaca con los que necesita lidiar semanalmente. La idea general de los puntos de la historia es que rastrea / estima cuándo entregaremos el producto (o conjunto de características). Los puntos de la historia son arbitrarios y así es como elimina toda la sobrecarga sin valor de la estimación. En general, el trabajo sin valor es constante semana a semana, por lo que está integrado en la velocidad del equipo. El equipo acelerará cuando eliminen o reduzcan este trabajo sin valor.

Dicho de otra manera, ¿por qué incluso rastrear puntos a errores? ¿Así que al final del día sabes cuánto "trabajo" hizo cada miembro? ¡Para! Mal gerente! :) Mide el equipo, no el jugador. Anime al equipo a controlarse si una persona no está tirando de su peso. Mucho más efectivo. Hacer los puntos de la historia no debería hacer que un individuo se sienta mejor, pero el equipo en su conjunto debería sentirse mejor cuando se comprometen al final del sprint. En el deporte, ¿el objetivo es bueno para el equipo o el individuo? Si el individuo juega para sí mismo, el equipo pierde a la larga.

Ya sabes, eventualmente no quieres usar puntos en absoluto. La estimación es tiempo quitado del trabajo real. Cuando un equipo alcanza el chi máximo , no usa puntos en absoluto, pero sabe exactamente cuántos elementos puede tirar en un sprint. Han dominado el arte de dividir unidades de trabajo que la estimación es desperdicio de proceso.

Algunas tareas son estimables, otras no. Para cosas que no se pueden estimar, use un presupuesto.

La reparación de un defecto no es una tarea fácilmente estimable porque tiene varios componentes desconocidos. ¿Qué está causando el defecto? Una vez que se comprende la causa, ¿cómo se puede solucionar? ¿Qué impacto tiene este cambio en el resto del sistema? ¿Cuántos defectos nuevos inyectó para arreglar este defecto?

Tenga en cuenta que la causa de un defecto puede provenir de cualquier punto del ciclo de vida del software: requisitos mal entendidos o mal comunicados, diseño deficiente o suposiciones incorrectas, codificación deficiente, pruebas incorrectas, nuevo conocimiento sobre el problema basado en la información obtenida de la versión actual ...

La creación de un presupuesto se puede hacer de dos maneras diferentes para las tareas de corrección de errores. Aquí hay algunas ideas que he usado con eficacia:

• Use datos históricos (digamos de una iteración anterior) para ayudarlo a comprender cuánto tiempo debe reservar para la corrección de errores.
• Ponga "bloques" de corrección de errores (digamos 5 puntos o 20 horas) en su cartera de pedidos y deje que el cliente elija esto en lugar de historias.
• Exija que cada miembro de su equipo dedique una cantidad de tiempo específica a cada iteración para corregir defectos.

Su objetivo es corregir tantos defectos como sea posible dentro del presupuesto asignado. Discuta con sus clientes estrategias para priorizar defectos reportados. Por ejemplo, ¿clasifica los defectos por criticidad y luego por prioridad? ¿Prioridad estricta? ¿Deberías atacar primero la "fruta baja"? ¿Errores de IU primero?

Además, corregir errores no gana valor. Los defectos de fijación son una forma de desperdicio. Ya ganó valor en la función, por lo que no debería obtener "puntos de bonificación" por corregir errores.

Tener un presupuesto ayuda con la planificación y aún le da una imagen precisa de Velocity. Presupuesta un número específico de puntos para la corrección de errores, dale al presupuesto una cantidad de tiempo aproximada basada en tus datos históricos, y luego elimina tantos errores como puedas en el tiempo presupuestado.

En lugar de centrarme en las historias, los errores y las tareas y los puntos que cada uno tiene, me parece mejor centrarme en ofrecer funciones para el cliente.

Los clientes esperan que el software funcione y solo den un valor real al desarrollo, las mejoras y las nuevas funciones, ya que impulsan el negocio hacia adelante.

Las correcciones de errores, por importantes que sean, no impulsan el negocio hacia nuevas áreas y nuevos clientes (tangencialmente y eventualmente sí, pero no de inmediato, que es lo que la gerencia está midiendo).

Entonces, los puntos se ven mejor desde el punto de vista más alto de la velocidad y cuántos puntos por semana se han hecho históricamente para historias con puntajes similares.

Esto puede conducir a una gestión por el historial de seguimiento en lugar de impulsar la necesidad urgente de que las historias de esta semana estén completas y con frecuencia descubran que no lo están. Sin embargo, la pérdida del control inicial y la mayor confianza que esto requiere harán que algunos gerentes corran hacia la puerta con horror.

Utilizo Pivotal Tracker (solo tengo JIRA, Trak, Trello y otros) y Pivotal Tracker tampoco hace puntos por tareas o errores. Se hace por las mismas buenas razones anteriores que también lo hacen cierto en JIRA como te estás viendo a ti mismo.