Estamos luchando por dividir los elementos de la cartera de productos (PBI)/las historias de usuario en fragmentos del tamaño de un sprint, ya que tenemos varios pasos que deben completarse de manera lineal.
Cada lanzamiento pasa por varios pasos:
Por lo general, podemos terminar el desarrollo y las pruebas en un Sprint y el UAT se completa en el siguiente Sprint. Tiene sentido tener las tareas de UAT bajo los mismos PBI que se usan para Desarrollo y Pruebas para evitar la duplicación de PBI/User Story. El problema es que tener los PBI siempre abiertos para más de un Sprint significa que nuestra acumulación de Sprint se vuelve demasiado grande, difícil de administrar y difícil de obtener métricas. También sienta un precedente en el que comenzamos a decir que las pruebas pueden estar en un Sprint diferente al desarrollo, etc.
Según tengo entendido tenemos las siguientes opciones:
Debido a otros procesos que no podemos cambiar, UAT no puede estar en el mismo Sprint que el desarrollo y las pruebas.
Actualmente usamos Visual Studio Team Services/Azure Dev Ops.
¿Sería la mejor práctica para esto?
¿Hay alguna otra opción que me haya perdido?
Su proceso UAT actualmente es externo a su equipo de desarrollo, y su entrega e implementación están estrechamente relacionadas. Sin cambiar su proceso subyacente o suposiciones comerciales, no hay forma de hacer que lo que está haciendo actualmente sea "ágil".
Sin embargo, puedes:
Si bien las diferentes respuestas pueden brindarle varias soluciones potenciales, generalmente se incluirán en uno de estos cuatro grupos. Cuál de las opciones disponibles que elija será en gran medida una decisión comercial o política , así que asegúrese de tenerlo en cuenta en su proceso de toma de decisiones.
Gracias, pero cuando avanzamos al entorno de prueba para UAT, debemos impulsar todo el lanzamiento de una sola vez. Esto nos permite tratarlo como un simulacro probando nuestro despliegue de producción. Esto significa que la UAT no puede ser el mismo sprint que el Desarrollo, no importa cuánto tiempo hagamos el sprint.
A pesar de la pregunta original, los problemas reales, como se describe en los comentarios , son:
UAT es un proceso externo.
El equipo y el proceso UAT no son internos al equipo de desarrollo y, por lo tanto, están fuera del alcance del control.
La entrega y la liberación de cada incremento están estrechamente acopladas.
Al equiparar la entrega con la liberación, especialmente con una dependencia externa, su proceso no puede cumplir con la Definición de Listo en una sola iteración.
Una vez que reconozca estos dos problemas de proceso incorporados, puede comenzar a evaluar soluciones.
Hay un gran grupo potencial de posibles soluciones a sus problemas. Cuáles son aceptables desde el punto de vista político y cuáles tienen sentido comercial para su organización variarán mucho de una empresa a otra.
Sin ningún orden en particular, algunas de sus opciones incluyen:
Haz Lean o Kanban, no Scrum.
Aunque la pregunta no estaba etiquetada como Scrum, la noción de "Sprints" generalmente es una señal de que un equipo está tratando de seguir Scrum. Sin embargo, si rutinariamente no puede alcanzar sus Sprint Goals en una sola iteración por razones institucionalizadas que no cambiarán, es posible que Scrum no sea el marco adecuado para usted.
Internalizar UAT.
Si UAT está fuera del equipo, es posible traerlo al equipo. Si eso es algo que su empresa quiere hacer o no, es un tema completamente diferente. Es posible, así que no descarte la noción simplemente porque no es la forma en que el proceso está configurado hoy.
Un Scrum Master o un entrenador ágil debe educar activamente a los líderes senior sobre problemas de procesos fundamentales como este. Permita que el equipo ejecutivo gane su cheque de pago resolviendo problemas de procesos organizacionales.
Desvincule la entrega de la implementación.
En un marco ágil, cada ciclo o iteración debe generar un incremento de trabajo potencialmente entregable. Sin embargo, en realidad no tiene que implementarlo solo porque se entregó.
Muchos equipos ágiles usan alternancia de funciones y otras prácticas de entrega continua para permitir que el equipo entregue funciones en los límites de Sprint (o incluso con más frecuencia), sin tener que implementar necesariamente esos cambios en entornos que no son de desarrollo. Al eliminar la implementación en su entorno UAT de su Definición de Listo y dejar que ellos habiliten los cambios de función cuando estén listos, crea la capacidad de desacoplar esos elementos de su proceso.
Por supuesto, esto significa que cualquier problema que se descubra en UAT deberá enviarse de vuelta al Product Backlog o a la cola de entrada como nuevo trabajo para ser estimado, priorizado y programado de acuerdo con su marco ágil. Tiene mucha flexibilidad en la forma de hacer esto, pero lo que no es negociable es que no puede tener un proceso externo que secuestre o pase por alto su proceso ágil interno.
Al elegir tener equipos separados o un proceso de prueba externo, la gerencia debe aceptar la compensación de que UAT y la implementación están fuera de banda, y que los procesos externos solo pueden crear nuevo trabajo para el equipo en los límites de iteración y a través del consumo. de los recursos del equipo que deben extraerse de otras actividades. De una forma u otra, esto es cierto independientemente del marco ágil (o incluso no ágil) que esté utilizando.
También hay otras soluciones posibles. Sin embargo, lo que todos tienen en común es que usted (el “usted” colectivo y organizacional) debe reevaluar sus suposiciones actuales y luego inspeccionar y adaptar hasta que haya logrado un proceso más eficiente. Tenga en cuenta que aceptar la carga sobre la productividad y los costos financieros de continuar haciendo negocios como lo hace hoy también es una decisión comercial legítima, pero que la gerencia no puede tener "negocios como siempre" y "mejora continua" al mismo tiempo. TAANSTAFL.
Gran pregunta. Parece que su cartera de pedidos tiene un cuello de botella en el estado de desarrollo de UAT. Scrum.org ha abordado el problema del cuello de botella al infundir prácticas de Kanban en Scrum para brindar hipertransparencia en escenarios como el que ha descrito.
Tener un Sprint Backlog en constante crecimiento es un artefacto de este tipo de cuello de botella, lo que resulta en un Sprint Backlog que es difícil de administrar porque la lista de elementos de trabajo continúa creciendo. Esto es abordado por la Ley de Little . En esencia, el resultado fundamental de la Ley de Little es que, para un proceso determinado, en general, cuantas más cosas se trabajen en un momento determinado (en promedio), más tiempo llevará terminar cada una de esas cosas (en promedio). promedio).
Limitar el trabajo en curso (WIP) y hacer que su equipo entienda su propia definición de flujo de trabajo puede descubrir las razones detrás de este cuello de botella sin la necesidad de duplicar esfuerzos de sprint a sprint. Suena extraño, pero ralentizar el flujo de trabajo limitando WIP es efectivo para comprender por qué los elementos se bloquean en ciertos estados (en su caso, UAT), lo que le brinda la oportunidad de abordar esos problemas y, al mismo tiempo, proporciona un mecanismo para completar el trabajo de manera eficiente. Los bloqueadores y las ineficiencias se vuelven calificables al usar estas técnicas, lo que las hace más fáciles de abordar.
Todo esto se puede encontrar en la Guía Kanban 2018 para equipos Scrum . ¡Espero que esto ayude!
Tiene uno (o ambos) de los siguientes dos problemas:
Personalmente, preferiría la primera solución. Pero, si ya dividió sus historias tanto como pudo, entonces sería preferible tener Sprints más largos que tener que cargar todo en dos Sprints.
cuando empujamos al entorno de prueba para UAT, necesitamos empujar todo el lanzamiento de una sola vez. [...] Esto significa que la UAT no puede ser el mismo sprint que el Desarrollo, no importa cuánto tiempo hagamos el sprint.
Un enfoque que leí recientemente fue tener dos Definiciones separadas de Listo (DoD). El primero (hasta UAT, pero sin incluirlo) haría que la historia se quemara, pero en el tablero de Sprint permanecería en una columna de "esperando UAT". El segundo DoD sería para cuando se implemente.
dom_michalec
Arrendajo