En nuestro equipo ágil, con frecuencia nos encontramos con el problema en el que Scrum Master señala que todas nuestras historias deben estar completamente asignadas y estimadas antes de una iteración y, una vez que se han agregado estas tareas, no se pueden agregar más tareas/historias durante la iteración. En mi opinión, esto es muy difícil de lograr a menos que se comprenda completamente el elemento de trabajo. En mi experiencia, tratar de completar una historia antes de trabajar en ella es difícil porque:
No sé qué implicarán realmente las tareas hasta que me familiarice con el código en esa área en particular.
Incluso cuando me familiarice, estaré constantemente leyendo documentos, etc. para mejorar mi comprensión y buscar eficiencia, por lo que posiblemente haga que mis tareas originales sean redundantes.
Quizás esto no sea muy ágil de mi parte, pero se siente como el mejor método para agregar valor al trabajo que se está realizando. ¿Estoy siendo demasiado rígido o hay un enfoque común para resolver este problema? ¿Este problema es común entre los usuarios de este sitio, ya que parece bastante común para los desarrolladores con los que he trabajado?
¿Cuándo agregar tareas a las historias y cómo estimar tareas?
Debe agregar tareas en el momento de la planificación de la iteración. El equipo de desarrollo debe tener un plan de juego sobre cómo lograr la historia. En mi experiencia, estimar las tareas en horas resulta útil. Sin embargo, debe entenderse claramente que las horas son solo para el propósito de la coordinación interna del equipo y no para que la gerencia las use como referencia para la medición del desempeño.
nuestro Scrum Master señala que todas nuestras historias deben estar completamente asignadas y estimadas antes de una iteración.
Estoy de acuerdo con su Scrum Master, esto debe hacerse antes del inicio de la iteración. Este es el objetivo principal de la reunión de planificación de iteraciones.
no se pueden agregar más historias durante la iteración.
Estoy de acuerdo con tu Scrum Master en esto. Esta es la premisa básica de Scrum.
no se pueden agregar más tareas durante la iteración.
No estoy de acuerdo con tu Scrum Master en la parte de no más tareas. Esta es la mentalidad de cascada (planificación predictiva). La premisa de Scrum (planificación adaptativa) es que el desarrollo de software es en parte un tipo de trabajo de I+D. Debe comenzar con un enfoque específico para hacer la historia según su mejor criterio. Sin embargo, si tiene problemas, una tarea puede demorar más de lo estimado originalmente. En algunos casos, su enfoque inicial puede no funcionar en absoluto y es posible que deba probar otro enfoque. En este punto, puede volver a estimar o rehacer las tareas.
Cuando hay un alto nivel de incertidumbre, les pido a mis equipos que realicen una historia de investigación con un límite de tiempo (pico) en la iteración anterior. Esto podría implicar hacer una prueba de concepto para validar un enfoque. Entonces el compromiso del equipo para lograr lo que se comprometió es mucho más firme.
Incluso cuando me familiarice, estaré constantemente leyendo documentos, etc. para mejorar mi comprensión y buscar eficiencia, por lo que posiblemente haga que mis tareas originales sean redundantes.
Esto suena demasiado tentativo. Debe comprender bien los requisitos y tener un enfoque planificado al momento de comprometerse con el equipo en la reunión de Planificación de la iteración.
Las razones más comunes por las que las personas luchan por estimar lo que he visto son:
Estás tratando de ser demasiado preciso.
Puede ser útil tener disponibles algunas historias que haya hecho anteriormente cuando las calcule para usarlas como puntos de referencia.
Si tiene un ejemplo de una historia de 2, 5, 8 y 13 puntos, tráigalos a su sesión de estimación. Con suerte, será más fácil estimar en la línea de "definitivamente es más grande que la historia de 2 puntos y más pequeña que la de 13 puntos". en cuyo caso es un 5 o un 8, elija lo que le parezca más cercano.
Recuerde, el propósito de la estimación no es la precisión. Serás demasiado grande a veces y demasiado pequeño en otras ocasiones, todo se equilibra con el tiempo.
Criterios de aceptación insuficientes
Si los criterios de aceptación no contienen información vital, la estimación es difícil. Las cosas a tener en cuenta son frases como "replicar el comportamiento actual". Si no sabe cuál es el comportamiento actual, será realmente complicado hacerse una idea del tamaño de la historia.
¡Haga que su propietario de producto/analista comercial aclare antes de aceptar la historia!
Tus historias son demasiado grandes.
Para usar el ejemplo que Daniel da en su respuesta:
Como usuario, quiero que mi factura final tenga en cuenta los descuentos disponibles para mí.
Trate de dividir la historia en partes más pequeñas. Tal vez:
Como suscriptor anticipado, quiero que mi factura final represente mi descuento por reserva anticipada.
Como usuario empleado, quiero que mi factura final tenga en cuenta mi descuento de personal.
Como titular de una tarjeta de fidelización, quiero que mi factura final tenga en cuenta el descuento de mi tarjeta de fidelización.
etc.....
Las historias más pequeñas son generalmente más fáciles de entender y es menos probable que involucren múltiples sistemas, etc.
Hay grandes incógnitas
Tal vez no haya trabajado en este código antes. Tal vez estés construyendo algo que es diferente a cualquier cosa en la que tengas experiencia. Podría ser que esté utilizando una nueva herramienta de terceros y no tenga idea de cómo funciona. Este tipo de cosas hace que la estimación sea prácticamente imposible ya que tienes muy poco en lo que basar un número.
En este escenario, es una buena idea hacer un pico para ayudarlo a comprender el problema en cuestión.
Siempre lo he tomado desde este punto de vista:
Si no puede elaborar la historia porque no sabe qué tareas deben realizarse, ¿cómo sabe qué tan grande es la historia para estimarla y cómo puede comprometerse a realizarla?
En estas situaciones (y son muy comunes) generalmente significa que una historia es demasiado amplia (no es que no sepas todos los pasos, son demasiados para enumerarlos en la práctica) o demasiado vaga.
Por ejemplo, digamos que tengo esta historia:
Como usuario, quiero que mi factura final tenga en cuenta los descuentos disponibles para mí.
Podría ser un solo campo o podría distribuirse en 10 sistemas diferentes, 2 de los cuales están en Excel. He tenido mucha fricción en este punto debido a las ideas de la gente sobre lo que es una historia entregable. Te diría que deberías tener una historia de investigación con un resultado concreto como:
Como ejecutivo de cuenta, me gustaría identificar todas las posibles fuentes de descuentos.
He tenido personas que se resisten a eso porque no es una entrega de funciones per se. Esas personas dirían que es trabajo de la empresa determinar y proporcionar, pero muchas veces estas terminan siendo preguntas muy técnicas porque el ejecutivo de cuenta puede verlo todo en uno o dos lugares, pero en realidad está en varias bases de datos. Personalmente, creo que vale la pena modificar un poco la agilidad para hacer bien el trabajo, pero tal vez otros puedan ofrecer una alternativa.
El otro gran problema con esto es que, si toma esa historia y completa el resto del esfuerzo disponible en el sprint con otras historias, la implementación del código basado en sus hallazgos tendrá que esperar hasta el próximo sprint. Hay una solución bastante simple para esto. Deja espacio en tu sprint para más historias. Si su velocidad es de 60 puntos, solo comprométase con 45. Eso puede darle el espacio para crear y generar más historias para implementar su solución. Nuevamente, estamos en el área gris de Agile aquí, pero creo que está haciendo el trabajo y manteniendo la intención detrás de esas reglas de Agile.
¡Espero que esto ayude!
ben
Daniel
ben