Tenemos un Product Owner (PO) que comienza a probar mientras un elemento está en revisión de código y brinda comentarios a los desarrolladores. Veo, desde el punto de vista del PO, que esto permite una retroalimentación más rápida. Sin embargo, no creo que deba comenzar a probar mientras el código aún está en la etapa de revisión, sino esperar hasta que el elemento esté listo para la prueba porque tenemos probadores.
Recibí comentarios del equipo de que "el tiempo de respuesta de las tareas es más lento (las pruebas parecen ser lentas a veces)"
¿Alguna idea sobre este tema?
Mi idea/solución es:
Sé que esta es una pregunta obvia, pero me gustaría saber si alguien ha encontrado algo similar y qué hizo para solucionarlo.
La respuesta depende de si esto ralentiza o acelera el proceso.
¿Cuántos de los errores que encontró se descubrieron durante la fase de revisión del código?
Si todos fueron descubiertos durante la revisión del código, entonces tal vez ella esté perdiendo el tiempo (y el de todos). Aunque todavía podemos preguntar:
¿Cuántos de los errores que encontró se corrigieron antes de la etapa de revisión de código?
Si todos lo fueran, entonces ella le está ahorrando tiempo al hacer que revise el código corregido con menos errores.
Y luego está el tipo de errores que encuentra que marca la diferencia.
Un Propietario de producto normalmente revisaría el producto en busca de problemas de interfaz de usuario, redacción, errores tipográficos y estética.
Estos "errores" no serán detectados por Code Reviews o el departamento de control de calidad, ya que son principalmente subjetivos. (Con la excepción de los errores tipográficos). Entonces, cuanto antes solucione estos problemas, menos trabajo (de volver a probar) para todos los involucrados.
Si, por otro lado, solo encuentra errores difíciles de encontrar que una buena revisión de código habría detectado en mucho menos tiempo, entonces tal vez valga la pena señalarle que está perdiendo el tiempo.
Un último pensamiento: si ella simplemente está tomando el producto para una prueba de manejo rápida y (ya que los encontró) informando todos los problemas que encuentra, entonces tal vez sus programadores necesiten una mejor ética de trabajo; si lo probaran durante un minuto antes de lanzarlo, también encontrarían y corregirían estos errores obvios.
Como regla general, diría que cuanto antes el Product Owner comience a probar, mejor .
La razón de esto es que muchos errores ocurren como resultado de una mala comprensión de los requisitos. El propietario del producto está en una posición privilegiada para revisar y dar retroalimentación a un equipo.
Pídale a PO que espere hasta que el elemento esté en la fase de prueba y mantenga el tiempo de sprint y no se convierta en un cuello de botella.
Si el propietario del producto descubre un problema en la fase de prueba, es posible que sea necesario volver a trabajar y repetir la revisión del código. Esto podría considerarse un desperdicio si el Product Owner pudiera descubrir el problema antes en el ciclo de desarrollo.
Algunos equipos de Scrum con los que he trabajado llegaron al punto de demostrar características al Product Owner durante el desarrollo , y mucho menos esperar a que comenzara el ciclo de prueba.
Si actualmente al equipo le resulta perjudicial recibir comentarios tempranos del propietario del producto, sugeriría buscar formas de mejorar el proceso de desarrollo para que esto sea un problema menor.
Mi recomendación sería construir su proceso de desarrollo en torno a un ciclo de retroalimentación temprano y flexible. Un enfoque que he visto adoptado es tener un entorno específico para el propietario del producto. Cuando el equipo de desarrollo siente que tiene una compilación estable, la lanza al entorno del propietario del producto y le informa que hay nuevas funciones para revisar. Si hay problemas conocidos, deben comunicarse claramente y es responsabilidad del propietario del producto no informar duplicados.
La comunicación y el trabajo en equipo son fundamentales para que esto funcione.
A favor de eliminar el desperdicio, también sugeriría esperar.
Suponiendo que el tiempo de un PO es más caro/valioso que el de un probador o desarrollador, simplemente debido a la oferta y la demanda, ya que solo hay un PO, pero varios desarrolladores/probadores, lo siguiente sería una pérdida de tiempo de PO:
Además, los desarrolladores pueden sentirse un poco molestos si se critica su trabajo antes de que lo declaren "terminado". No le dices a un cocinero que su plato no está sabroso arrastrándolo fuera del horno cuando el cocinero insiste en que solo está medio cocido y necesita otros 20 minutos. No le dices a la gente que estacionan como idiotas cuando todavía están en la calle moviéndose. En otras palabras, no le digas a las personas que cometieron errores cuando aún no han terminado. Solo puede ser un "error" si debería funcionar en primer lugar.
Por lo tanto, presentar tickets de error generará métricas incorrectas después. Muchos tickets de errores significan que los desarrolladores necesitan trabajar mejor. Pero en este caso, ni siquiera habían terminado todavía. Entonces sus métricas están sesgadas.
Pero como siempre en Scrum: discútalo con el equipo, vea lo que todos tienen que decir y encuentre una solución que funcione para todos.
Es bueno que tenga un propietario del producto que quiera participar en el desarrollo del producto y el proceso de QA/UAT. Sin embargo, si bien la colaboración es excelente, las pruebas no forman parte del rol del propietario del producto en Scrum.
La Guía Scrum dice:
El propietario del producto es la única persona responsable de gestionar la cartera de productos. La gestión de la cartera de productos incluye:
- Expresar claramente los elementos del Product Backlog;
- Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones;
- Optimizar el valor del trabajo que realiza el Equipo de Desarrollo;
- Asegurarse de que el Product Backlog sea visible, transparente y claro para todos, y muestre en qué trabajará el Equipo Scrum a continuación; y,
- Asegurarse de que el equipo de desarrollo comprenda los elementos de la cartera de productos al nivel necesario.
Lo que está haciendo su Product Owner no es intrínsecamente hacer ninguna de estas cosas, y no está aprovechando los procesos y prácticas del marco para garantizar la calidad.
El propietario del producto sin duda debe colaborar con el equipo de desarrollo. Esto incluye ayudar al Equipo Scrum a elaborar la Definición de Terminado, establecer los Objetivos del Sprint y participar en las Revisiones y Retrospectivas del Sprint. Sin embargo, el enfoque del propietario del producto está en definir el trabajo y optimizar el valor, no en realizar pruebas de aceptación o control de calidad.
Como propietario del producto, especialmente cuando formo parte de un equipo Scrum inmaduro, puedo pedirle al equipo de desarrollo que demuestre características críticas que cumplan con la definición de terminado a lo largo del Sprint en lugar de esperar hasta el final. O puedo pedirles que hagan una "demostración de preparación" dentro del equipo antes de la Revisión del Sprint formal para asegurarme de que todos estamos en la misma página.
Como propietario del producto, no puedo aprobar el trabajo. En su lugar, trabajo a través del Product Backlog para definir el trabajo y a través de la Definición de Listo para establecer expectativas sobre la calidad. Lo que es más importante, trabajo a través del Sprint Goal para establecer expectativas sobre lo que califica como un incremento de trabajo entregado o no entregado.
Si mi Sprint Goal se cumplió de acuerdo con la Definición de Listo, entonces el incremento de trabajo se entregó con éxito. Si no se ha cumplido el Sprint Goal, entonces el incremento de trabajo no se ha entregado correctamente. Eso no significa que no se haya hecho el trabajo, o que varias partes del trabajo no se hayan hecho correctamente; simplemente significa que la iteración no ha alcanzado el alcance y el valor planeado para ella.
Como Scrum Master, parte de su trabajo es educar al propietario del producto sobre las responsabilidades del rol. Ayude al propietario del producto a usar las herramientas del marco correctamente y a colaborar de manera efectiva con el equipo.
Si el Propietario del producto prueba de forma rutinaria el producto o sus características a través de cada Sprint, esto puede ser una indicación de que el Propietario del producto percibe un problema de calidad continuo o que no confía en el Equipo de desarrollo. Esta es una oportunidad para mejorar las comunicaciones, reevaluar la definición de hecho o, de lo contrario, inspeccionar y adaptar el proceso para aumentar la confianza entre los roles clave del equipo.
Del mismo modo, si el propietario del producto proporciona comentarios de forma rutinaria a nivel de implementación (en lugar de a nivel de sistema o función) dentro del Sprint, esto es un olor de implementación de marco que puede indicar un refinamiento deficiente de la cartera de pedidos, objetivos de Sprint deficientes, historias de usuarios que carecen de contexto o historias de usuarios que no cumplen con los criterios de INVEST. Si ese es el caso, trabajar con el propietario del producto y el equipo de desarrollo para mejorar los contenidos del Producto y los Sprint Backlogs, y para mejorar el cumplimiento de los criterios INVEST (especialmente el requisito Comprobable), a menudo generará una mejora significativa del proceso .
Además, la inspección por parte del desarrollador de un incremento que no sea en los puntos de inflexión del marco también puede conducir a la desviación del alcance. Por ejemplo, si el propietario del producto está inspeccionando una función que cumple con la definición de Listo pero solicita cambios en el Sprint, esto puede representar un cambio de alcance o diseño que no formaba parte de la planificación del Sprint de la iteración actual. Los desarrolladores deben colaborar activamente con el Product Owner para definir el alcance y los problemas de diseño, pero cualquier comentario que cambie el alcance o ponga en riesgo el Sprint Goal debe negociarse cuidadosamente. Un Sprint Goal obsoleto, o cambios significativos en el alcance, pueden requerir la cancelación del Sprint y volver a Sprint Planning.
En cada uno de estos ejemplos, el objetivo clave del Scrum Master es ayudar a todo el Equipo Scrum a generar seguridad y confianza. Esto significa:
Su objetivo como Scrum Master es facilitar la confianza, que se construye a través de la visibilidad, la transparencia y las comunicaciones abiertas. Aproveche la Retrospectiva de Sprint y otros elementos del marco tanto como sea posible, pero siempre asegúrese de estar resolviendo cualquier problema real subyacente de confianza y comunicación, en lugar de solo abordar los síntomas.
No veo cómo esto es un problema en primer lugar.
Si el problema es que el PO no está disponible para dar retroalimentación o responder preguntas, entonces este es un problema completamente diferente. Si el PO está probando cosas y encontrando errores, entonces le está ahorrando tiempo y esfuerzo a su equipo.
Entonces, si todavía están disponibles para hacer todas las cosas que usted necesita que hagan, déjelos hacer las pruebas que quieran y agradezca su aporte.
Mi idea es aconsejar al propietario del producto que comience a probar la experiencia del usuario y la funcionalidad una vez que tanto los desarrolladores como los probadores hayan completado la codificación y las pruebas. La responsabilidad principal del PO es descubrir cualquier diferencia en la funcionalidad según la historia del usuario. Por lo tanto, el precioso tiempo de PO se puede utilizar de manera eficiente.
Todd A. Jacobs lo logró. Encuentro que si un PO no confía en los equipos de desarrollo y prueba, hay un problema más profundo que debe resolverse. Esto podría dar lugar a problemas morales entre el personal, así como a la mala gestión de las funciones propias de la OP y del proyecto en su conjunto.
nvoigt
Ruán
nvoigt
Ruán
Roberto Anzaldúa
Ruán
nvoigt
Daniel
Húmedo