Estoy en un equipo ágil, con algunos desarrolladores, un diseñador y un tipo de ux. A veces, dividimos algunas historias de usuario en tareas cuando pensamos que son demasiado grandes.
Al hacer esto, siempre he leído que debemos dividir las historias de los usuarios en pequeñas funciones (para que podamos tener un producto potencialmente entregable después de cada tarea). Sin embargo, la mayoría de los miembros de mi equipo insisten en dividir las tareas en tipos de trabajo (por ejemplo, una tarea para los esquemas de esta historia de usuario, luego otra para el diseño y otra para la implementación). Entiendo que es una mala manera, ya que no estamos obteniendo productos potencialmente enviables, pero parece que no puedo dejarles claro que necesitamos cambiar esto. ¿Cómo podría hacer esto?
Ambos tienen razón. (O mal, dependiendo de la perspectiva).
Una posible pauta para definir las Historias es que deben ser "la menor cantidad posible de trabajo que, por sí mismo, proporcione valor comercial". Otro es el método INVEST . Tenga en cuenta el requisito 'Pequeño'.
Así que siéntete libre de dividir las Historias en Historias más pequeñas. Sin embargo...
Está perfectamente bien (y es común) que el equipo de desarrollo divida las historias en tareas por tipo de trabajo. Tenga en cuenta que el hecho de que se complete una tarea no significa que la historia esté lista. El trabajo de una Historia no debe incluirse en la rama principal del producto hasta que se completen todas sus Tareas. El hecho de que una historia esté a medio terminar no significa que su incremento no se pueda enviar, ¡simplemente no envíe esa historia!
Una historia de usuario debe implementarse dentro de un sprint (generalmente de 1 a 3 semanas). El spint en sí se puede organizar de cualquier manera, en realidad, el manifiesto ágil recomienda una estructura autoorganizada entre el equipo. Si este es el caso, tus compañeros de equipo están bien.
Si la historia de usuario es demasiado grande y no cabe dentro de un sprint, debe dividirse en historias más pequeñas que encajen. Si este es el caso, sus compañeros de equipo están equivocados. Y cualquier otra organización no estará dentro de la metodología ágil, y este debería ser su mayor argumento en contra de ellos.
Creo que @Sarov hizo algunos buenos puntos en su respuesta, y la parte más importante es la distinción entre historias y tareas .
La división de historias nunca debería ocurrir en función del nivel de la pila tecnológica con la que esté trabajando, a menos que pueda crear una función completa completamente en el front-end o back-end. El artículo aquí describe la técnica SPIDR de Mike Cohn para dividir historias de usuarios. Tenga en cuenta que ninguno de estos está dividido por "nivel de la pila de tecnología". La división de historias siempre debe ser vertical, no horizontal. Si tiene dificultades para convencer a su equipo de esto, una estrategia que he usado es recordarles a los desarrolladores que al dividirnos verticalmente siempre podemos mostrar valor comercial a las partes interesadas, ¡lo que generalmente los mantiene alejados del equipo de ingeniería!
La división de tareas puede ser horizontal, especialmente si la mayoría de sus ingenieros no son ingenieros full-stack. Si tiene equipos front-end y back-end dedicados, no hay problema con tener tareas para cada historia que involucren a diferentes miembros del equipo en diferentes partes de la pila. Solo recuerde que Scrum fomenta la funcionalidad cruzada, y los miembros del equipo siempre deben desear aprender más sobre las diferentes partes de la pila que usa. Cuanto más multifuncional sea su equipo, menos tendrá que preocuparse por un problema como este.
Daniel
Todd A. Jacobs