Dependencias entre equipos en una historia

Se puede hacer mucho usando simulacros y stubs.

Por ejemplo, el equipo podría determinar primero cómo se verá la API y luego crear rápidamente una API de código auxiliar que devuelva datos falsos.

Esto ayuda a separar las tareas de desarrollo frontend y back-end. Ahora los desarrolladores frontend trabajan usando el stub y los desarrolladores back-end trabajan para desarrollar la implementación de la API.

Puede ser que un stub sea insuficiente para manejar correctamente la interfaz y, en ese caso, es posible que desee crear una API simulada más sofisticada.

Este es solo un ejemplo de la mentalidad de tratar de reducir las dependencias para permitir que el equipo trabaje más en paralelo. Este es un enfoque que vale la pena, ya que es más fácil para el equipo concentrarse en completar una historia de usuario en lugar de tener muchas historias en progreso a la vez.

Para la estimación, desea estimar en el nivel de elementos de la cartera de productos. Si está utilizando historias de usuario, la historia de usuario suele ser el elemento de la cartera de productos. Y al estimar, desea tener en cuenta todo el trabajo necesario para que esté listo, según la Definición de Listo del equipo, cualquier criterio de aceptación en la Historia misma.

La mejor manera de manejar las dependencias es reducirlas o incluso eliminarlas. Esto lo ayudará a evitar (o al menos reducir) el desbordamiento, concentrarse en no estimar el trabajo de otras personas y tener estados claros de estar listo y terminado.

En tu caso particular, creo que puedes eliminar la dependencia de la tarea de diseño de UX/UI. Normalmente esperaría que este trabajo se hiciera como parte de la definición del trabajo. Esperaría que el diseño de la interfaz de usuario esté completo, al menos hasta un nivel de estructura alámbrica, antes de que el equipo refine el elemento de la cartera de productos. A menos que sepa cómo se supone que debe verse el formulario y cómo se comportarán los elementos de la interfaz de usuario (desde una perspectiva de UX), ¿cómo puede estimar y ordenar el trabajo?

Si mueve el diseño (del tipo UX) como un requisito previo para el refinamiento del trabajo del Equipo de Desarrollo, puede abrir diferentes posibilidades para administrar el trabajo de descubrimiento realizado por los gerentes de producto y los diseñadores de experiencia del usuario.

1. Al hacer una estimación, ¿debe estimarse cada parte por separado? ¿Cómo calcular la estimación "total"?

Todos los equipos participan en la misma Planificación de Sprint, discuten todos los aspectos de la Historia de Usuario y la estiman completamente.

¿Cómo?

Primero necesita una historia de usuario de referencia que tenga 1 punto de historia. Discute esta historia de usuario para que se entiendan todas las partes. Puede ser:

"Como usuario de la web, quiero restablecer mi contraseña, para poder seguir usando mi cuenta"

Tiene trabajo de diseño, frontend, backend.

Luego, le pide a los desarrolladores (diseño, frontend, backend) que den sus estimaciones sobre cuánto más compleja es su historia que la historia de referencia. Si es tan complejo como la historia de usuario de referencia, obtiene 1SP.

La estimación de la historia de usuario contiene todo el trabajo para "Terminar". Todo ello.

2.¿Cómo evitar el desbordamiento? Si la mayoría de las tareas se enredan así, es posible que pocas tareas se realicen, ya que el trabajo es en serie en lugar de paralelo.

Necesita practicar el desarrollo iterativo, sobre todo la inspección y la adaptación.

En tu caso:

Esta historia tiene tres partes:

1. Diseño de formulario de inicio de sesión

2. Implementación de la API de back-end

3.Implementación frontend (con estilos y conexión al backend)

Durante el refinamiento de la cartera de productos, crea algunos borradores iniciales para las tres partes y los agrega a la historia de usuario. Entonces tiene una historia de usuario imperfecta, pero aún así tiene todas las partes, por lo que todos los desarrolladores pueden comenzar a trabajar en ella. La historia de usuario se selecciona para un sprint y se analiza más durante la planificación del sprint. Se agregan más detalles.

Entonces empiezas a trabajar en ello.

No. de iteración 1:

Según los detalles de la historia de usuario, el frontend usa el diseño preliminar y espera algunos puntos finales del backend, se burla de ellos. Todo el trabajo está integrado en el entorno de desarrollo.

Uno o dos días después, los desarrolladores y el propietario del producto lo revisan (literalmente, en la interfaz de usuario). Esta es la inspección. Y decidir cómo modificarlo más. La adaptación viene después.

No. de iteración 2:

El diseño está actualizado. La interfaz lo actualiza. El backend entregó algunos puntos finales. La interfaz elimina algunos simulacros y utiliza puntos finales reales. Esto es adaptación.

Uno o dos días después, es tiempo de retroalimentación, otra vez. Alguien hace clic en el botón de inicio de sesión, no funciona. ¿Es culpa de frontend o de backend? Back-end. El diseño podría usar una fuente diferente. Esta es la inspección.

No. de iteración 3

El backend corrige y entrega todos los puntos finales. El diseño se actualiza con la nueva fuente. La interfaz lo pone todo junto.

Un día después, es tiempo de retroalimentación, otra vez. Ahora se ve bien y funciona como se esperaba. Esta es la inspección.

Ahora fusiona las cosas y las implementa en el entorno de ensayo. El propietario del producto ahora puede mostrárselo a las partes interesadas para obtener más comentarios.

Es posible que ocurran más iteraciones hasta que esté "Terminado".

No es ciencia exacta, es complejo, pero este es el flujo de trabajo y colaboración.

Debido a que una parte puede entregarse más lentamente que las demás, usted (el más rápido) puede cambiar para trabajar en otra cosa. Incluso puede solicitar comentarios sobre el trabajo parcial (diseño y frontend con backend completamente simulado).

Estas cosas se pueden suavizar en la Retrospectiva de Sprint. En un verdadero equipo multifuncional, el frontend puede hacer algo de diseño y el backend puede hacer algo de frontend (y/o viceversa) para que todos los desarrolladores entreguen al mismo tiempo y no tengan que esperar unos a otros. Todo es planificación, experiencia y capacidad.

Separar a las personas por experiencia no ayuda en absoluto, solo empeora las cosas. Hace que los bucles de retroalimentación sean más largos. Entonces, si bien puede pensar que la Historia de usuario está "Listo", en realidad no ha recibido (todavía) algunos comentarios que lo harán actualizarlo nuevamente, como un "error".

No hay despilfarro si lo espera. En realidad, debería querer esta retroalimentación lo antes posible para "Terminar" con ella. Obviamente, si cree que está "Terminado" y recibe comentarios inesperados, debe trabajar más y tener menos tiempo disponible para otras historias de usuarios o errores.

3.¿Cómo comprometerse en algo tan incierto (obra ajena)?

Junto con la inspección y la adaptación, la transparencia es el tercer Pilar de Scrum . Solo sea honesto y colabore para entregar la historia de usuario común, para lograr el objetivo de Sprint común. Esto es compromiso.

En Scrum, el compromiso se cambió por el pronóstico porque el primero tiene malas implicaciones en la calidad del trabajo.

Después de comprometerse a entregar una lista de Elementos de la Pila del Producto, el Equipo Scrum, principalmente el Dueño del Producto y especialmente las partes interesadas, pueden sentir que existe la obligación de entregarlos todos al final del Sprint.

Si lo entiendo correctamente, quería titular la pregunta con "Dependencias dentro del equipo": las dependencias ocurren dentro del equipo. Debe intentar establecer desarrolladores multifuncionales, no solo equipos multifuncionales.

Use el emparejamiento de desarrolladores de diferentes disciplinas (un desarrollador de backend con un frontend) o programación de mafia (todo el equipo se sienta alrededor de una computadora) para mejorar las habilidades faltantes de los miembros del equipo.

Idealmente, cada desarrollador del equipo puede realizar cualquier tarea en cualquier momento. En la práctica tendrás expertos para cada tema, y ​​el resto sabe más o menos qué y cómo desarrollar en ese tema. Los expertos son consultados durante el desarrollo o explican los detalles si las estimaciones muestran grandes diferencias entre los miembros del equipo.

Es posible que le interesen los resultados de búsqueda de "forma de peine de scrum" como https://www.linkedin.com/pulse/which-letter-shaped-employee-you-gaurav-sharma

Para las estimaciones, @alexandru-jieanu ya escribió una excelente explicación.