Cliente con política UAT conservadora

Un cliente en particular tiene un enfoque muy tradicional y conservador para UAT e implementación. Cuando el equipo de desarrollo completa los elementos en el sprint, todo esto se empaqueta en un lanzamiento, que debe abrirse camino a través de un entorno UAT/Staging, donde se prueba completamente para la nueva funcionalidad, luego se prueba completamente la regresión y finalmente se implementa en Producción. . El motivo de este enfoque es que el entorno de Staging contiene una copia de los datos de producción, que es demasiado confidencial para los desarrolladores, y la empresa está acostumbrada a un enfoque de estilo cascada. Tenga en cuenta que esto no se puede cambiar, así que no sugiera algún tipo de revisión organizativa. Los evaluadores de UAT tampoco forman parte del equipo Scrum. Esto tampoco cambiará.

Aunque las pruebas unitarias, las pruebas de regresión y otras formas de prueba se incorporan al sprint, y el propietario del producto está muy involucrado, no hay forma de evitar este largo proceso UAT al final. Naturalmente, esto da como resultado muchas fallas informadas por UAT, y los elementos se rechazan y se envían nuevamente a desarrollo. El ciclo típico de UAT es de aproximadamente 1 semana.

Estoy buscando algunas buenas ideas sobre cómo estructurar los sprints de Scrum en ese tipo de clima/entorno. Nuevamente, no sugiera que la empresa cambie, porque eso está fuera del alcance de esta discusión. Esta es más una pregunta de "trabajo en el mundo real con clientes". Les encantan las prácticas ágiles, la gestión de la acumulación, el refinamiento, la planificación de sprints, la planificación de lanzamientos y todos los demás beneficios de Scrum. Solo necesitamos agregar esta 1 semana de UAT y rechazo al final, y estoy buscando formas de acomodar esto.

Cambiar a una metodología diferente también es una opción, si tiene algunas sugerencias.

No estoy seguro de qué es exactamente lo que estás tratando de mejorar aquí. ¿Interrupciones? ¿Cumplimiento de la Guía Scrum? Tampoco estoy seguro de cuáles son los motivos de las fallas que se informan después de UAT. ¿Están relacionados con la calidad del entorno escénico? Si compartes más detalles, actualizaré mi respuesta.
Gracias. El objetivo sería tener menos riesgo para la entrega. Entonces, idealmente, incorporaría el ciclo UAT en el sprint, pero encontraría cosas que los desarrolladores deberían hacer para evitar la holgura cuando el lanzamiento es una versión con pocos defectos. La razón por la que UAT es un desafío es porque el proyecto es una extensión de un sistema heredado que tiene muchas interdependencias. Luego se debe determinar si el problema era preexistente, causado por un nuevo código o causado en algún lugar posterior porque A invocó a B, luego A invocó a C, pero B directa o indirectamente alteró el estado de C, en menos de manera obvia
Scrum ofrece la mayor parte del ROI cuando no hay deuda técnica, como sistemas heredados impredecibles. En tales casos, si se cree que Scrum es el mejor enfoque, recomendaría hacerlo más confiable primero. Al mismo tiempo, escribió que Scrum no es una necesidad, por lo que mi respuesta fue más sobre resolver un problema, no resolver un problema dentro del marco de Scrum.

Respuestas (5)

TL;RD

No puedes pintarle los labios a un cerdo y esperar que sea la reina del baile. Cuando se enfrenta a un impedimento del proceso que no se puede cambiar, como el que está describiendo, debe hacer que los problemas del proceso sean un costo visible para el proyecto. Como casi no tiene control sobre el impedimento y puede hacer poco para controlarlo, su objetivo clave debe ser la transparencia .

Haga que su proceso sea visible y transparente para el equipo, las partes interesadas, la gerencia y el cliente. Entonces depende de ellos identificar el valor (o la falta del mismo) en los procesos externos. Su proceso interno identificará claramente el valor que está agregando el equipo, y el tiempo de entrega y los gastos generales del proceso agregados por cualquier externalidad.

Es trabajo de la alta gerencia controlar (o aceptar) las externalidades del proceso. Mientras todos tengan eso en cuenta, las cosas funcionarán mucho mejor.

Externalizar el circuito de retroalimentación UAT

Naturalmente, esto da como resultado muchas fallas informadas por UAT, y los elementos se rechazan y se envían nuevamente a desarrollo.

Esto es un problema, pero es una externalidad . Tiene un proceso externo que está agregando gastos generales del proceso (y, por lo tanto, costos) a su balance final. La forma correcta de manejar esto es hacer que esos costos sean visibles para las partes interesadas.

En su caso específico, eliminaría UAT de la Definición de Listo. El trabajo se completa para el Sprint cuando pasa las pruebas unitarias, la integración continua, la revisión por pares o cualquier otra cosa que esté en su Definición de Terminado. El trabajo realizado se presenta luego como un incremento completo al cliente al final del Sprint.

Luego, el cliente puede pasar su próximo Sprint realizando tanto o tan poco UAT como desee mientras usted trabaja en el siguiente incremento, y cualquier problema que pueda descubrir se ubica en el Product Backlog por el Product Owner como nuevo trabajo para un futuro Sprint. Este tiempo de espera adicional será un artefacto visible de su proceso elegido, y la visibilidad tiene un gran mérito. Esta es realmente la forma correcta de manejar esta situación y se ajusta a los principios centrales del modelo de desarrollo iterativo.

Ampliar Sprint para UAT con costos visibles

Como alternativa, puedes simplemente extender la duración de tu Sprint actual por dos o más semanas para acomodar su ciclo UAT. Parte de su definición de hecho será pasar el producto de mitad de sprint a UAT y luego esperar a que regresen los resultados.

El costo del tiempo inactivo del desarrollador lo impone el proceso externo. Su trabajo no es crear trabajo ocupado o perpetuar la "falacia de utilización del 100%". El equipo puede usar esa semana para actualizar el servidor de CI, aplicar parches a las estaciones de trabajo, realizar capacitación en el servicio o simplemente leer un buen libro. El punto es que este ciclo UAT tiene un costo de desarrollo (ya sea en trabajo no producto o en trabajo iterativo) que es parte del marco organizacional. Simplemente haga que ese costo sea completamente visible.

El principal riesgo de este enfoque es que cuando se completa la UAT, es posible que los cambios o trabajos nuevos no se hayan tenido en cuenta en las estimaciones del equipo. Como resultado, es posible que tenga o no tiempo suficiente para abordar los cambios o volver a trabajar dentro del Sprint. Como resultado, el costo visible para el proyecto será más Sprints fallidos (por ejemplo, Sprints que no cumplen con el Sprint Goal), trabajo incompleto que luego debe devolverse a Product Backlog o Terminación anticipada con un retorno a Sprint Planning.

Estos son resultados aceptables en el sentido de que aseguran que el proceso permanezca transparente y que el costo del proyecto para estos procesos sea visible para el equipo, las partes interesadas y el cliente. Solo recuerde que la transparencia es el objetivo principal y que nunca debe haber ningún trabajo invisible, nunca.

Me gusta el punto de hacer visibles los costos, esto es potencialmente lo más importante aquí.

Para que conste: cuando el Equipo de Desarrollo no puede entregar un incremento potencialmente liberable al final del Sprint, eso es una desviación grave de Scrum. Dejemos ese tema a un lado ahora.

Lo que podrías hacer:

  • involucrar a la mayor cantidad posible de usuarios finales en un Sprint . No te limites a la presencia física. Pensar fuera de la caja. Ejemplo: puede grabar videoclips que presenten nuevas funciones, compartirlos lo antes posible y preguntar a los usuarios si eso es lo que esperaban.

  • si UAT tarda 1 semana en completarse, piense en extender la duración de Sprint en 1 semana e incluirlos en Sprint. PERO no esperes con UAT hacer la última semana del sprint. No tome esto como una oportunidad para que el equipo de desarrollo haga aún más funciones nuevas, porque contraatacará con doble fuerza. ¿Ganancias? Menos trabajo en curso y cambio de tareas. (Supongo que actualmente Sprint a menudo se ve interrumpido por las solicitudes de esos usuarios finales)

  • Entrenar al Propietario del producto para que represente la opinión de los usuarios finales al nivel más alto posible.
Me gusta la extensión. Si tienes suerte y no te devuelven mucho, los debutantes tendrán algo de tiempo para limpiar la casa en preparación para la próxima iteración.
Esta fue mi primera inclinación. El siguiente problema sería cómo explicar la tercera semana a la gerencia. Querrían asegurarse de que esos desarrolladores se asignen principalmente al trabajo asignado. ¿Qué sugieres si la liberación está libre de defectos? ¿Picos en insectos? Las historias adicionales serían demasiado arriesgadas, porque probablemente necesitarían el ciclo UAT completo (la 3.ª semana de sprint), por lo que tendría que haber algún tipo de límite WIP en esa 3.ª semana, en términos de lo que podría emitir y obtener a través de UAT. .
@PittsburghDBA Me merezco una bofetada por lo que escribí, en realidad :) No fui lo suficientemente claro, así que déjame corregirme. Al incluir las pruebas UAT en Sprint, no pretendía hacerlas todas al final, en la última semana. Los usuarios finales (o quienes los realicen) deben ser incluidos lo antes posible en el proceso de cualquier manera posible.
@PittsburghDBA El tiempo de inactividad de sus desarrolladores podría dedicarse a mejorar su entorno de ensayo. ¿Tuvieron tiempo para profundizar en ese tema? Por lo que escribió, tengo la impresión de que las fallas reveladas durante la UAT son un síntoma del entorno de desarrollo, en lugar de malentendidos con respecto a los elementos de la acumulación de productos.

La realidad de su situación es bastante común y tiene cosas que hacer ahora y cosas para un futuro lejano.

Hagan ahora

Concéntrese en que la salida del equipo de desarrollo sea potencialmente entregable. Ese es el nuevo incremento de software que producen cada sprint se dirige a UAT y siempre debe pasar. (Si siempre pasa, la empresa verá menos valor en UAT).

1) Cree una Definición de Listo que represente el nivel de calidad que lo lleve a ser potencialmente liberable.

2) Permita que su equipo de desarrollo se niegue a aceptar elementos pendientes que no tengan los criterios de aceptación adecuados.

Esto lo acercará a los valores y principios de Scrum sin interferir con la organización en general.

el mediano plazo

Una vez que tenga calidad y consistencia, puede comenzar a enfocar el escenario UAT en más de una sesión de retroalimentación. Tal vez necesite pasar por alto el resto de la cadena y obtener usuarios reales en su revisión de sprint, pero ahí es donde comenzará a acelerar. Si no puede construir cosas en absoluto, eso está mal, y construya más de lo que los usuarios necesitan, generará más confianza.

3) Traiga a los usuarios finales y a las partes interesadas a su Sprint Review y adapte la acumulación en consecuencia.

4) Invita a UAT a tu revisión de sprint.

5) Inserte herramientas de recopilación de telemetría en su código, como Application Insights, para comprender realmente los comportamientos de sus usuarios.

El objetivo largo

A medida que demuestre su capacidad como equipo de desarrollo para entregar un software funcional que satisfaga las necesidades del negocio, los procesos UAT y de puesta en escena se verán cada vez más como un desperdicio. Lo harás. Tenga a sus Clientes/partes interesadas en su esquina luchando para dar a los Equipos de Desarrollo más control y responsabilidad.

Esto es perspicaz. No sé por qué, pero siempre me sorprende, al menos un poco, el ritmo del cambio organizacional.
La definición de hecho coincide con lo que iba a decir en una respuesta separada: si hay un impedimento esperado que estará presente en cada sprint, podría valer la pena adaptar su definición de hecho a esta realidad. ¡ Scrum no requiere que su incremento potencialmente entregable se envíe realmente! Su definición de hecho podría decir que debe desarrollarse, probarse y determinarse que esté listo para UAT y ahí podría ser donde se detiene su proceso. La retroalimentación de la UAT luego pasa a la acumulación para el próximo sprint y cuando un incremento pasa la UAT con éxito, se toma el tiempo para liberarlo.
"Definición de hecho" Probablemente no sea práctico aquí, las partes interesadas conservadoras no aceptarán ninguna definición de hecho. Vale la pena intentarlo, pero fallará cuando luego insistan en que algo no se hizo.

Esto es lo que yo sugeriría. Cuando se completa el ciclo UAT, el resultado del mismo se agrega al registro posterior del producto. Antes de la próxima sesión de planificación de primavera, el propietario del producto prepara y (re) prioriza el registro de tareas pendientes del producto. Durante la próxima sesión de planificación de primavera, el equipo de desarrollo junto con el propietario del producto seleccionan qué elementos de la cartera de productos se llevarán a la próxima primavera. Algunos problemas podrían ser críticos para que el PO los solucione, algunos podrían permanecer en la cartera de productos por más tiempo.

Esta sería la forma más natural de hacerlo, pero la mayoría de las veces, la política requiere una solución inmediata a la historia del candidato de lanzamiento, por lo que tenemos un desbordamiento en términos de planificación de sprint. El lanzamiento comenzaría tan pronto como sea posible, con nuevas correcciones, habiendo pasado UAT nuevamente. Interrumpe el patrón normal de scrum.
@PittsburghDBA, " la política requiere una solución inmediata a la historia del candidato de lanzamiento ", ¿qué pretende lograr tal política? Es decir, ¿cuál es la razón de eso? Claramente interrumpe su proceso/éxito, ¿entonces debe haber un lado positivo? Al igual que usted, vivo en el mundo real, con clientes reales y sus requisitos. Si bien la mayoría de las veces tenemos que aceptar lo que nos piden, no obstante debemos esforzarnos por explorar sus motivaciones y problemas con ellos tan a fondo como podamos, para que podamos sugerir una solución. Entonces, si no sabe por qué se aplica esta política, debe preguntar.

Si la productividad del equipo se ve gravemente obstaculizada por el trabajo que se rechaza una semana después debido a un UAT fallido, entonces puede ser útil tener esto en cuenta en la planificación de la historia. Trate de reestructurar sus historias para incluir este problema del mundo real, de modo que si falla UAT, todavía puede demostrar un progreso valioso para el cliente. Suponiendo que tenga éxito en la UAT de vez en cuando, ¿puede mostrarle a su cliente que el trabajo se está haciendo, solo puede haber un viaje de ida y vuelta adicional involucrado?

Si el cliente se ve afectado por estos retrasos, entonces debe abordar el problema de que su equipo no pudo fabricar un producto que satisfaga las necesidades del cliente. Mi siguiente paso sería tratar a los probadores de UAT como clientes. Dijiste que no son parte del equipo SCRUM, pero es posible que sean clientes. A ningún equipo de pruebas le gusta el software defectuoso, tal vez pueda trabajar con ellos para encontrar formas de recuperar las cosas que les importan antes en el proceso. Si son un cliente, involucrados en el proceso, pueden obtener ideas de esto. Es posible que digan "ya sabes, esa herramienta que usaste para asegurarte de que tu software funcionara antes de que lo probáramos... ¿crees que podríamos usar eso?" Entonces ha proporcionado un valor que nunca esperaron obtener.

Realmente todo depende de lo que el cliente realmente quiere. Quizás el problema se pueda manejar con el control de versiones. Tal vez tenga dos pistas, una pista que agrega nuevas funciones y la otra pista que garantiza que puede producir algo que pase UAT utilizando el conjunto anterior de funciones.

Gracias por esto. También estaba pensando en aumentar la frecuencia de lanzamiento, para que puedan realizar UAT en las historias completadas lo antes posible, y luego, hacia el final del sprint, el UAT se centraría más en las pruebas de integración y las pruebas del sistema.
Cliente con política UAT conservadora
RespuestasAquíPolítica de privacidad1y, 0v