Cortes verticales con disciplinas divididas

Tenemos un equipo de DevOps que incluye un BA, desarrolladores de .NET y desarrolladores de SAP. Los desarrolladores de .NET y SAP pueden y solo trabajarán en su disciplina particular.

Algunas de nuestras historias involucran solo trabajo de .NET; Estos son fáciles de escribir. Lo mismo para las historias de SAP.

Algunos trabajos implican un esfuerzo que se extiende desde la interfaz de usuario (.NET) hasta el almacén de datos (SAP).

Cuando se encuentra una última historia, la mejor práctica es tener una historia con tareas específicas de la disciplina (sobre la base de que una historia debe ser un corte vertical completo) o dos historias separadas (sobre la base de que cada pieza se trabaja de forma independiente) ?

La complejidad aquí es que no podemos confiar en que uno de cada desarrollador esté disponible para trabajar en la historia al mismo tiempo; Dado que esas dos tareas deben realizarse como esfuerzos de trabajo separados (sin importar cuán interdependientes sean), parecería irrazonable/imprudente (en este caso) bloquear toda la historia debido a que una tarea no se pudo completar. (Podríamos esperar para siempre a que ambos desarrolladores estén disponibles. Es esta condición de carrera la que queremos evitar).

"Tenemos un equipo de DevOps que... no puede confiar en que uno de cada desarrollador esté disponible para trabajar en la historia[.]". Entonces, realmente no tienes un equipo; tiene un conjunto interdependiente de recursos matriciales. Esto suele ser un síntoma de una falla organizacional fundamental para adoptar la agilidad real. Eso es lo que hay que abordar.

Respuestas (1)

Tiene que ser una historia de usuario . Al usuario no le importan tus recursos. Una historia de usuario debe proporcionar valor y un backend por sí mismo o un frontend sin funcionalidad no es de utilidad para su usuario.

Obviamente son dos tareas. Y tu equipo debe comprometerse a hacerlo... o no hacerlo. No hay condición de carrera aquí. O los dos muchachos pueden hacerlo, o no pueden. Si está esperando que estén disponibles , le sugiero que verifique si realmente está haciendo Scrum . Porque eso solo puede suceder si hay alguien jugando con tus recursos mientras corren.