Comúnmente veo historias que tienen desarrollo de back-end y front-end. Por ejemplo, considere un diálogo grande con algunas tablas y algunos controles dinámicos. Haremos varias historias (tal vez una para cada tabla y otra para el sistema de control dinámico).
El equipo de desarrollo se dividirá con una persona en el back-end y otra en el front-end. Esto hace que sea fácil para la persona de back-end preocuparse por la estructura de la capa SQL, mientras que la persona de front-end se centra en cosas como el diseño. Después de que se acuerde la interfaz inicial entre el back-end y el front-end, los dos desarrolladores pueden centrar su atención para terminar su parte al final del sprint.
Luego viene el caos. ¿Quién "posee" qué historia? ¿Qué significa "en progreso" o "hecho"? ¿Deberíamos hacer dos historias separadas para back-end y front-end? Si es así, ¿eso no rompe la idea de historias de usuarios basadas en la función? Nuestro sistema tiene una noción de "subtareas", lo que facilita algunos de estos problemas. Pero las subtareas agregan una complejidad adicional. ¿Hay una mejor manera? ¿Es esta una forma "mala" de usar Scrum?
He estado usando alguna forma de Agile en los últimos años en un par de lugares. Todavía no tengo entrenamiento oficial, así que perdone cualquier terminología o ideología incorrecta. Solo estoy tratando de aprender formas prácticas de mejorar nuestro proceso.
Respuestas:
Una "historia" se llama así porque representa una historia completa, bueno , desde la perspectiva del cliente. Sin el front-end o el back-end, no existe una ruta de caso de uso para que el cliente la ejecute.
En su caso, creo que tanto el front-end como el back-end deberían ser una sola historia. Dividirlo en tareas. Los desarrolladores poseen sus diferentes tareas. Estas tareas pueden rastrearse individualmente a través de sus fases: en curso, codificación realizada, prueba de módulo realizada, etc.
Asegúrese de incluir tareas asignadas de control de calidad en la misma historia; sin validación, una historia es inútil. El control de calidad probará la historia integrada de extremo a extremo que verá un cliente. Solo entonces se debe marcar la historia general como Hecho. En un entorno ágil ideal, un cliente real o un proxy del cliente también prueba la historia en una aplicación en ejecución y marca la historia Aceptada si cumple con los requisitos acordados.
Si desea bucles de retroalimentación más rápidos, intente dividir el caso de uso en características más pequeñas de extremo a extremo. Por ejemplo, en lugar de un caso de uso como "Un cliente puede comprar cosas usando un carrito de compras", divídalo en "Un cliente puede agregar un producto a un carrito de compras" y así sucesivamente ... Luego complete cada caso de uso más pequeño de principio a fin como se describe anteriormente.
EDITAR: quería respaldar los puntos anteriores con algunas fuentes. Las características de una buena historia de usuario se representan de manera concisa con un acrónimo llamado " INVEST ". Fue creado por Bill Wake y popularizado por el movimiento Scrum. Tenga en cuenta especialmente los artículos en historias que son independientes y verticales.
Un poco más de información aquí y aquí .
fuente
Quien agarra la historia. La clave desde el punto de vista organizacional es que una persona es responsable del trabajo. Una vez que tienes dos personas, es demasiado fácil pasar la pelota.
Depende. He visto trabajar en ambos sentidos. Si la historia es lo suficientemente grande como para que dos desarrolladores trabajen a tiempo completo, tal vez debería dividirse. Si los dos desarrolladores son parte de dos equipos diferentes, entonces tal vez debería dividirse. Si los dos desarrolladores trabajarán en él durante diferentes sprints, entonces tal vez debería dividirse.
La clave para recordar es que el proceso está ahí para servirle, no al revés. Las historias de usuarios son una forma para que la gente técnica y la no técnica faciliten la comunicación. Explican lo que les gustaría, todos negocian, y luego usted proporciona comentarios en la historia sobre su progreso.
Mientras el proceso funcione para usted, no puede ser tan malo.
fuente
Donde hemos implementado modelos Scrum, se espera perfectamente que múltiples desarrolladores puedan estar involucrados en una sola historia de usuario. Puede haber trabajo para la capa de datos, integración, CSS front-end, infraestructura, etc. El equipo puede unirse en las diversas subtareas para que una historia se haga realidad.
Dicho esto, una persona es propietaria de la historia y es responsable de actualizar el progreso de la misma y asegurarse de que todos hayan hecho su parte y que estén trabajando juntos. Esta es la persona para nosotros que informa que una historia está "hecha".
fuente
Como otros han sugerido, mi equipo también divide nuestras historias de usuarios en tareas. En general, esto es fácil de hacer si administra sus historias de usuario a través de software (como JIRA o Rally). Entonces es fácil decir qué partes de la historia avanzan.
Pero una alternativa para las tareas sería simplemente reasignar la propiedad a medida que cada persona termine su parte. Entonces, la historia se transmite: tal vez el desarrollador 1 comienza con el trabajo de back-end, luego pasa al desarrollador 2 para hacer la interfaz de usuario. Luego se pasa a su comprobador de control de calidad para su verificación. Este método debería funcionar bien en entornos donde está utilizando tarjetas reales en la pared o si su software no realiza un seguimiento de las tareas.
Pero en cualquier caso, recomiendo nunca llamar a una historia "terminada" hasta que el equipo acuerde que está hecha, incluidas las pruebas. De esa manera, todos tienen la oportunidad de dar su opinión. Y si combina esto con ideas sobre la propiedad del código colectivo y las revisiones de código, de todos modos cada historia es realmente "propiedad" del equipo. Puede ser "asignado" a diferentes personas a lo largo del camino, pero si alguien está fuera (enfermo / vacaciones / ¿demasiadas reuniones? / Otro) el trabajo aún puede hacerse.
Mi equipo a menudo acepta historias de usuarios como parte de nuestra reunión matutina de stand-up / SCRUM. De esa manera, todos pueden reconocer o disputar fácilmente si realmente está "hecho". Otras veces simplemente dejamos que nuestro ingeniero de control de calidad haga eso: si está satisfecha de que se haya probado y esté funcionando, y todas las tareas estén completas, entonces lo llamamos hecho.
fuente
Donde estoy hoy llamamos a este proyecto más grande "épico". Una epopeya se compone de múltiples historias y puede abarcar múltiples sprints / iteraciones. Una historia, para nosotros, siempre se da a un único desarrollador y debe caber dentro de un solo sprint. Una sola historia se subdivide en tareas. Cada una de las tareas son completadas por el mismo desarrollador en esa historia. Las tareas están destinadas a dar una idea del progreso de la historia durante el sprint / iteración. A medida que cada historia se completa, por cada desarrollador, la epopeya muestra el progreso.
El objetivo de la epopeya es tener un objetivo más grande que no necesariamente encaja en un solo sprint / iteración. Con el tiempo se completan todas las historias y se termina la epopeya. Las epopeyas se colocan en un lanzamiento.
Demostramos código cada dos semanas donde las historias para ese sprint / iteración deben mostrarse a los interesados y aprobarse. En este contexto, "hecho" para una historia significa que puedo mostrarte lo que hace. Un desarrollador posee su historia y es responsable de mostrarla (esta parte es una especie de simplificación excesiva, pero lo suficientemente buena para esta respuesta; coordinamos nuestras demostraciones a través de una sola persona). "Hecho" significa que se puede demostrar con éxito. "En progreso" significa que tengo tareas pendientes y la historia no está completa. Una epopeya se completa cuando todas las historias de esa epopeya se han demostrado con éxito.
Ahora esta es la progresión perfecta del caso. Tenemos historias y demostraciones que fallan, usuarios que quieren algo más, etc. Arriba está el objetivo y en su mayor parte funciona.
fuente