¿Cómo haces para manejar las historias que tardan más de un mes en llegar al estado TERMINADO? Por supuesto, uno siempre podría dividirlos en varias de las llamadas "historias técnicas", pero son, con la excepción de los picos de refactorización, un gran no-no en Agile, ¿no es así?
Primero, haz cosas que tengan sentido. Si tiene sentido dividir la gran historia en algunas más pequeñas, incluso si no puede entregar esas partes a su cliente por separado, ¿por qué no debería hacerlo? No te pagan por adaptarte perfectamente a lo que dicen algunos líderes intelectuales.
En segundo lugar, si la situación es más bien una excepción, el trato es como tal. Si no desea dividir la historia en partes más pequeñas, puede empujar una historia entre un par de iteraciones y aceptar que esta vez se verá así.
Tercero, si la situación es bastante común , piense cómo puede ajustar el proceso que sigue de una manera que realmente permita tales historias . Una cosa que me viene a la mente es Kanban, donde renuncias por completo a las iteraciones y puedes lidiar con una historia XXL y al mismo tiempo construir muchas más pequeñas ya que no limitas el trabajo basándote en el tiempo, pero limitas un número. de tareas concurrentes. En este caso, una gran historia ocuparía solo un espacio, pero lo usaría durante más tiempo.
Cuatro, no seas ortodoxo en la entrega de valor a un cliente . Si quisiera, y necesitara, hacer algo de mantenimiento en la arquitectura que no le diera valor a sus clientes, pero lo ayudara a limitar los costos de mantenimiento, ¿rechazaría tal tarea? Probablemente no. Y, sin embargo, de alguna manera lo pondrías en tu cartera de pedidos.
Después de todo, ágil se trata de flexibilidad, de reaccionar a los cambios y no de mantener las reglas a toda costa, ¿verdad?
Aferrarse a las historias de los usuarios como la unidad de planificación más pequeña es uno de los errores abominables de los agilistas.
¿Cuál es la historia de usuario de un puente? ¿Dónde se tiene en cuenta la construcción de pilas, vanos, vigas, etc. que componen la subestructura? La construcción de la plataforma (carretera) es de tan poca importancia (relativamente hablando), en esta narración ni siquiera se detalla.
¿Cuántas historias de usuario para una casa involucran los cimientos y el techo? Sin embargo, son las partes más caras de un edificio.
Las historias de usuario son una herramienta fundamental para la definición del alcance y el establecimiento de objetivos para el proyecto, pero no son la única herramienta a utilizar. Ayudan a definir el propósito de un proyecto y cuándo está completo. No proporcionan el alcance completo del esfuerzo involucrado. Ayudan a comenzar el proceso de planificación. No son el plan final.
Si realmente no puede dividir la historia en partes valiosas, iría con el "componente comprobable más pequeño" para dividirla.
¿Puedes dar un ejemplo de una historia?
Gran respuesta de Pawel. Algunas otras cosas a considerar:
Hecho debe ser desde la perspectiva de a quién se le entrega la historia. Este no es siempre el usuario final.
Hay una diferencia entre envío potencial y envío. Intentamos que el trabajo que hacemos sea completo, aunque puede que no sea un conjunto completo de funciones.
Todas las historias se pueden dividir. Es difícil hacer esto teóricamente durante la planificación.
Trate de no dividir las historias en la dimensión del proceso. Por ejemplo, no construya en una iteración y pruebe en la siguiente. Esto tendrá un impacto en el rendimiento y puede conducir a una deuda técnica.
Ken tenía algunos buenos consejos. Hemos encontrado que las cosas más importantes a tener en cuenta son que...
De la misma manera que aborda cualquier épica: divídala en partes más pequeñas.
Hay muchas maneras diferentes de hacer esto. Por ejemplo, si su proyecto tiene muchos otros sistemas (heredados) con los que interactuar, intente encontrar una historia de usuario de nivel inferior que se ocupe de UN sistema heredado. Y vea cómo la implementación de eso impacta en la historia épica general.
Otro enfoque es abordar las cosas desde el punto de vista de las partes interesadas.
Echa un vistazo a esta publicación para ver otra forma de lidiar con eso .
Es bueno intentar dividirse en historias técnicas o funcionar como una mini cascada, siempre que tenga sentido para el equipo y las partes interesadas relevantes.
Matt W.