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 punto de historia para los problemas de tipo Bug (es solo para Story s y Epic s).
¿Deberíamos agregar el tipo de problema Error a los tipos de problemas aplicables del campo Puntos de historia ? ¿Cuáles son los pros y los contras? ¿Sería adecuado para Scrum?
Idealmente, su software debería estar libre de errores después de cada iteración, y corregir errores debería ser parte de cada sprint, por lo que se debe considerar el trabajo requerido para corregir errores al asignar puntos de historia (es decir, una tarea que es más probable que producir errores debería tener más puntos de historia asignados a él).
Sin embargo, en realidad, los errores aparecen después del despliegue todo el tiempo, sin importar qué tan rígidas sean las pruebas; cuando eso sucede, eliminar el error es solo otro cambio, una característica, por así decirlo. 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 determinado comportamiento, y el usuario (o algún otro actor interesado) querría verlo cambiado.
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 adjuntos, y una persona de negocios decente solo los sopesará e irá con lo que les genere más ganancias (a largo o corto plazo, según la estrategia comercial).
Así que sí, por supuesto, asigna puntos de historia a los errores. ¿De qué otra forma vas a priorizar errores frente a características y errores contra errores? Necesita cierta medida del esfuerzo de desarrollo para ambos, y es mejor que sea comparable.
El mayor problema con esto es que las correcciones de errores suelen ser más difíciles de estimar: el 90% o más del esfuerzo real radica en encontrar la causa; Una vez que lo ha encontrado, puede llegar a una estimación precisa, pero es casi imposible juzgar cuánto tiempo tomará la búsqueda. Incluso he visto una gran cantidad de errores en los que pasamos 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 el sprint haya sido aceptado deben considerarse nuevas funciones .
Esta dificultad en la estimación de puntos para los errores, sin embargo, 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 necesita mucha experiencia y experiencia para ser experto en la estimación de puntos. Muchos proyectos se enfrentan a problemas importantes con una velocidad de determinación adecuada, por lo que muchos proyectos de Agile usan puntos para determinar qué historias entran en el sprint, sin embargo, usan horas para calcular el gráfico de reducción .
Parece contra intuitivo pero manejable, siempre y cuando la estimación de horas no se use como un factor para determinar el compromiso del sprint. El exceso de compromiso naturalmente conducirá a características perdidas o incompletas o horas extras, por lo que, con el tiempo, todos los involucrados se verán obligados a mejorar en la estimación puntual, momento en el que la estimación de horas en tareas y errores se convertirá lentamente en una métrica sin sentido.
Usted no debería 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 obtuvieron puntos por completar la historia. No debería recibir puntos de nuevo donde, en realidad, no debería haber ganado los puntos para empezar.
La corrección de errores debe tener un efecto negativo en la velocidad. De lo contrario, perder calidad termina siendo recompensado con una velocidad no afectada o incluso aumentada.
Quizás un enlace útil:
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 una Y para que Z", como es común en las historias de usuario, 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 solicitudes de nuevas 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 integrarlo en un sprint cuando tiene la capacidad de hacerlo.
Una cosa a tener en cuenta es que puede ser difícil estimar el esfuerzo que se requiere 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 varias personas para trabajar 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 ello 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 esprints.
Los errores son un hecho de la vida de 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, debería ser algo que todos los equipos deben planificar. En lugar de pensar obstinadamente que el proceso debe gobernar al equipo, debe 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 con algunas técnicas para estimar errores:
Con 1. hemos fallado de manera lamentable. Para la mayoría de los errores, hemos encontrado que el 90% del tiempo se invierte en el 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 afectó la resolución de la historia hasta el punto donde casi todos los sprint que hicimos de esta manera fallaron.
Según la opción 2 de la técnica de estimación de la relación 90/10 (corrección de corrección de errores), esto significaba que teníamos que planificar un análisis que no estaba cubierto por la planificación del sprint (habíamos aprendido de la opción 1, pero No hay una solución real de cómo seguir con los errores analizados). El resultado fue que el análisis de errores no se realizó porque un sprint se centró en los elementos planificados. El equipo no tuvo tiempo de centrarse en los errores de la cartera. Así que eventualmente tampoco se hicieron.
Al aceptar la incertidumbre, ahora nos hemos decidido por la opción 3. Hemos dividido la cartera de productos en una parte de la historia / tarea regular que el equipo puede estimar utilizando puntos de historia y una cartera de errores. En la acumulación de errores, el propietario del producto clasifica los errores según el valor comercial y el criterio del equipo muy aproximado. El equipo permite asignar una parte del tiempo durante un sprint que puede dedicar a centrarse en los errores. El propietario del producto no conoce el resultado exacto, ya que antes no era posible planearlo. La proporción de la acumulación de errores en comparación con la acumulación regular 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ó al equipo nuevamente. Sprints no fueron comprometidos por errores desconocidos. Al separar los errores en una acumulación diferente, tanto el enfoque del sprint habitual del equipo aumentó como los que nos permitieron terminar con los errores que también tenían un valor comercial significativo.
Depende de si los puntos de la historia son adecuados para ti. Intentaría estimar errores utilizando puntos de historia primero. Si eso no funciona, pruebe mi opción 3. Ha hecho que nuestro (más de 30 sprint de edad) se centre nuevamente en errores antiguos que contienen un gran valor comercial. También nos ha liberado de intentar entregar algo que el equipo simplemente no puede estimar. La aceptación de lo desconocido nos acercó más a la realidad y también hizo que nuestros sprints volvieran a ser exitosos mientras ofrecía una gran parte (basada en la relación error-historia) de valor comercial a través de la corrección de errores. La relación que usamos recientemente fue de 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 que se entrega. Si va a asignar puntos al valor del producto y a elementos sin valor, también puede estimar y hacer un seguimiento de las horas.
Los errores son la sobrecarga de lo que hiciste ayer y no es indicativo de la velocidad de finalización del producto, y tampoco crean ningún nuevo valor del producto (piénsalo). Los insectos son como interrupciones y todas las demás tartas de vaca con las que debes lidiar semanalmente. La idea general de los puntos de la historia es que realiza un seguimiento / 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 de una semana a otra, 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 los errores? ¿Para que al final del día sepa cuánto "trabajo" hizo cada miembro? ¡Para! Mal gestor :) Medir el equipo, no el jugador. Aliente al equipo a que se controle si una persona no está tirando de su peso. Mucho más efectivo. Hacer puntos de la historia no debe hacer que un individuo se sienta mejor, pero el equipo en general debe sentirse mejor cuando se compromete al final del sprint. En los deportes, ¿el objetivo es bueno para el equipo o el individuo? Si el individuo juega para sí mismo, el equipo pierde a largo plazo.
Sabes, eventualmente no quieres usar puntos en absoluto. La estimación es el tiempo quitado del trabajo real. Cuando un equipo llega a chi máximo , no usa puntos, pero sabe exactamente cuántos elementos pueden tirar en un sprint. Han dominado el arte de dividir las unidades de trabajo que la estimación es un 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ácil de estimar porque tiene varios componentes desconocidos. ¿Qué está causando el defecto? Una vez que se entiende la causa, ¿cómo se puede arreglar? ¿Qué impacto tiene este cambio en el resto del sistema? ¿Cuántos defectos nuevos inyectaste para corregir este defecto?
Tenga en cuenta que la causa de un defecto puede provenir de cualquier punto del ciclo de vida del software: requisitos incomprendidos 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 efectivamente:
Su objetivo es corregir tantos defectos como sea posible dentro del presupuesto asignado. Discuta con sus clientes las estrategias para priorizar los defectos reportados. Por ejemplo, ¿clasifica los defectos por criticidad y luego prioridad? ¿Prioridad estricta? ¿Deberías atacar primero a la "fruta baja"? ¿Errores de la interfaz de usuario primero?
Además, la solución de errores no gana valor. La reparación de defectos es una forma de desperdicio. Ya has ganado valor en la función, por lo que no debes obtener "puntos de bonificación" por corregir errores.
Tener un presupuesto ayuda con la planificación y aún le brinda una imagen precisa de Velocity. Presupueste una cantidad específica de puntos para la corrección de errores, asigne al presupuesto una cantidad de tiempo aproximada en función de sus datos históricos y luego elimine todos los errores que pueda en el tiempo presupuestado.
En lugar de centrarse en las historias, los errores, las tareas y los puntos que cada uno tiene, me parece mejor centrarse en ofrecer características para el cliente.
Los clientes esperan que el software funcione y solo le dan un valor real al desarrollo, las mejoras y las nuevas características a medida que estos impulsan el negocio.
Las correcciones de errores, por muy importantes que sean, no impulsan el negocio hacia nuevas áreas y nuevos clientes (tangencial y eventualmente quizás sí, pero no de inmediato, que es lo que la administración está midiendo).
Por lo tanto, los puntos se ven mejor desde el punto de vista superior de la velocidad y cuántos puntos por semana se han hecho históricamente para historias con puntuaciones similares.
Esto puede llevar a una gestión por historial de registro en lugar de empujar la necesidad urgente de que las historias de esta semana estén completas y frecuentemente descubran que no lo están. Sin embargo, la pérdida del control inicial y la mayor confianza que esto requiere requerirán que algunos gerentes corran hacia la puerta con horror.
Utilizo Pivotal Tracker (solo acabo de JIRA, Trak, Trello y otros) y Pivotal Tracker tampoco hace puntos por tareas o errores. Se hace por las mismas buenas razones anteriores que lo hacen también cierto en JIRA cuando te ves a ti mismo.
Lea otras preguntas en las etiquetas bug agile scrum user-story