Tareas de desarrollo compartido para historias de usuarios ágiles

Mi equipo utilizará Visual Studio Team Services para un próximo proyecto. Las herramientas ágiles me permiten organizar las historias y tareas de los usuarios jerárquicamente de esta manera:

Epic> Feature> User Story> Task / Bug

Digamos que estoy diseñando un sistema de gestión de organización de estudiantes (club) para estudiantes de secundaria y asesores. Los estudiantes y asesores pueden unirse a clubes, ser oficiales, organizar eventos, enviar anuncios, etc.

Tomemos la función de Anuncios como ejemplo:

Historias del usuario:

• Como estudiante, quiero leer los anuncios de los clubes de los que formo parte para estar al tanto de los cambios de horario.
• Como asesor, quiero leer los anuncios de los clubes de los que formo parte para conocer los cambios de horario.
• Como asesor, quiero enviar anuncios de los clubes de los que formo parte para que mis alumnos estén al tanto de los cambios de horario.
• Como administrador, quiero enviar anuncios a TODOS los clubes escolares para que pueda estar al tanto de los conflictos de programación.
• etc.

Si asumimos que estas son Historias de usuarios bien escritas (que podrían no serlo), me confundo cuando mi equipo de desarrollo y yo nos sentamos para dividir estos elementos en Tareas de desarrollo. Podemos cubrir partes de varias historias de usuario con tareas de desarrollo únicas. Por ejemplo, tenemos una herramienta que genera acciones CRUD para todas las capas desde la interfaz de usuario hasta la base de datos simplemente definiendo las propiedades de un anuncio. Por lo tanto, las partes de varias historias de usuario "enviar" y "leer" se completan en un solo paso de desarrollo.

Por lo que he leído, cada historia de usuario debe ser independiente de las demás y eso tiene sentido. Pero cada una de nuestras historias de usuario comparte la tarea "Generar interfaz de usuario y base de datos" porque así es como creamos nuestra interfaz de usuario de nivel base (antes de personalizarla). No debería escribir una tarea "Generar UI y DB" para cada historia de usuario. Eso es demasiada redundancia. Pero no sé cómo escribir una tarea "Generar interfaz de usuario y base de datos" que debe completarse antes de que cualquiera de las Historias de usuario pueda iniciarse.

Tengo una confusión similar con nuestro sistema de permisos. Tenemos diferentes tipos de cuenta como Estudiante, Asesor y Administrador que tienen acceso a la página de Anuncios, pero tienen una funcionalidad diferente dentro de la página (capturé esta idea con las Historias de usuarios anteriores). Podemos escribir el sistema de permisos para que sea modular, de modo que pueda usarse para otras características, pero no sé dónde escribir la tarea para crear un "sistema de permisos modular".

Supongo que toda esta historia de usuario me ha confundido. Sí, es excelente para capturar la funcionalidad de un sistema, pero cuando se trata de pensar en las tareas de desarrollo, parece que no puedo entenderlo. Cualquier consejo sería genial.

TL; DR: Parte de la programación que hago para una historia de usuario se puede usar en otro lugar de nuestro proyecto para otras historias de usuario (sistema de permisos, etc.). ¿Cómo escribo / organizo Tareas para Historias de usuarios para ilustrar esta posibilidad?

No debería escribir una tarea "Generar UI y DB" para cada historia de usuario. Eso es demasiada redundancia. Pero no sé cómo escribir una tarea "Generar interfaz de usuario y base de datos" que debe completarse antes de que se puedan iniciar las Historias de usuarios.

No lo hace .

Escribes tus historias de usuario como necesidades de usuario de alto nivel: has llegado tan lejos.

Luego, eliges la historia de usuario (característica) que vas a abordar primero. En este punto, dado el estado actual del producto, usted decide la mejor manera de implementar esta función. Luego, realiza el trabajo técnico mínimo requerido para implementar la función. Luego pasas a la siguiente historia de usuario.

Esto podría funcionar de la siguiente manera:

• Nos sentamos para hacer la historia de usuario 1 e identificamos que requiere una base de datos. Entonces implementamos la base de datos y luego la función.
• Nos sentamos para hacer la historia de usuario 2 e identificamos que, hey, ya tenemos la base de datos, así que ahora solo tenemos que extender la interfaz de usuario.

O en su ejemplo, incluso podría funcionar de la siguiente manera:

• Nos sentamos para implementar el envío de un anuncio. Creamos una interfaz de usuario con un cuadro de texto y un botón de envío que hace que se publique un formulario. Back-end, no pasa nada. Frio. Historia de usuario completa.
• Ahora nos sentamos para implementar la recepción de anuncios ... supongo que es hora de comenzar a hacer algo con ellos cuando se envían.

El propósito de este proceso es evitar que intentes diseñar todo por adelantado y permitirte tomar decisiones informadas sobre cómo implementar lo siguiente dado el estado actual del software. Eso es directamente incompatible con tratar de dividir todas las historias en tareas técnicas antes de comenzar cualquiera de ellas.

Por lo tanto, solo diseña la solución una vez que retoma la historia y evoluciona su diseño, característica por característica. Depende de usted (e incluso si) documenta su diseño técnico una vez que comience a trabajar en una historia.

Si dos desarrolladores recogen dos historias al mismo tiempo y ambos comparten requisitos técnicos, eso le dice que no puede hacer esos trabajos en paralelo, así que elija uno y haga que el otro desarrollador haga otra cosa.

El propósito aquí es implementar soluciones simples y revisar su diseño a medida que surgen nuevos requisitos.

Y, lo más importante, recuerde: esto no es una ciencia .

Dado que está ingresando a cada sprint con una lista priorizada de historias, y cada historia se divide en tareas técnicas separadas, todos los desarrolladores deberían estar trabajando en tareas para la historia de mayor prioridad antes de comenzar a trabajar en la segunda historia de mayor prioridad. Debido a esto, cuando comience a trabajar en la segunda historia prioritaria, la tarea 'Generar UI y DB' ya debería haberse completado como parte de la primera historia. Por lo tanto, si durante la planificación del sprint encuentra que una tarea técnica se duplica en varias historias, atribuya esa tarea a la historia de mayor prioridad para que se complete primero.

Si su equipo tiene el hábito de reorganizar las prioridades de la historia una vez que el sprint ha comenzado, puede ver beneficios al incluir tareas técnicas duplicadas en cada historia y hacer una nota sobre la tarea de las otras historias que la usan.

Puede ayudar tener la mentalidad de trabajar desde una lista de tareas técnicas en lugar de una lista de historias.