La empresa utiliza JIRA para sprints de 3 semanas.
Los miembros del equipo son virtuales con un evaluador de control de calidad que realiza todas las pruebas que documenta como subtareas para cada historia.
Los desarrolladores deben validar sus cambios haciendo sus propias pruebas unitarias en el producto y luego ella hace las pruebas de aceptación del usuario con los usuarios. Sé que esto es contrario a las pautas ágiles, pero su perspicacia técnica limitada significa que es incapaz de hacer nada más que pruebas de usuario.
Participa en todos los eventos -grooming, reviews y demos. Pero ella depende en gran medida de los otros miembros del equipo, convoca varias reuniones de "transferencia" para revisar los cambios más simples y envía una gran cantidad de mensajes de chat y correos electrónicos innecesarios.
Estos son disruptivos y molestos.
El gerente de desarrollo no hará nada porque le reporta al director (su jefe) y él es el tipo de gerente intermedio que nunca se quejaría.
¿Qué podemos hacer como equipo para manejar esto sin que parezca un montón?
Cada vez que me envía un mensaje de chat, le pregunto si le gustaría recibir ayuda. Por lo general, la respuesta es "No, solo quería actualizarte". y mi respuesta de "Ok, la próxima vez por favor actualice el ticket" ¡nunca funciona!
Una observación primero: esta persona no es "menos competente", simplemente tiene un trabajo diferente al tuyo.
Su trabajo requiere comunicación.
La pregunta es cómo lograr que se comuniquen de una manera que no te moleste.
Les has dicho lo que prefieres. Ellos no escucharon. El siguiente paso es mencionarlo en cualquier proceso de mejora que tenga en marcha. Una reunión retrospectiva, por ejemplo.
No apuntes con el dedo y mantente neutral. "Recibo muchos mensajes" es un problema más fácil de resolver que "Alicia me envía muchos mensajes". Uno es fáctico, el otro es acusatorio. Mantente objetivo y deberías poder resolver esto en tu proceso de retroalimentación.
Los desarrolladores deben validar sus cambios haciendo sus propias pruebas unitarias en el producto y luego ella hace las pruebas de aceptación del usuario con los usuarios. Sé que esto es contrario a las pautas ágiles, pero su perspicacia técnica limitada significa que es incapaz de hacer nada más que pruebas de usuario.
No entiendo esta afirmación. Si tiene a alguien en el equipo cuya función es hacer pruebas de usuario, entonces tiene sentido que esta sea su habilidad principal. Proporcionan la capacidad de prueba de usuario para el equipo.
Pero ella depende en gran medida de los otros miembros del equipo, convoca varias reuniones de "transferencia" para revisar los cambios más simples y envía una gran cantidad de mensajes de chat y correos electrónicos innecesarios.
No es inusual que las pruebas de usuario requieran mucha comunicación. La calidad y las pruebas son una actividad de equipo, no algo que se entrega instantáneamente a un evaluador. Es común una gran cantidad de interacción para garantizar que se comprendan los requisitos y que los lanzamientos en el sprint y los informes de errores se realicen de manera efectiva.
¿Qué podemos hacer como equipo para manejar esto sin que parezca un montón?
Por lo general, preocupaciones como esta se plantearán en la retrospectiva del equipo. Si le resulta difícil cubrir este tipo de problema sin "parecer un montón", entonces valdría la pena dar un paso atrás y ver cómo se ejecutan sus retrospectivas. Para que el equipo sea un éxito, debe poder abordar los problemas sin convertirlos en ataques personales.
Cada vez que me envía un mensaje de chat, le pregunto si le gustaría recibir ayuda. Por lo general, la respuesta es "No, solo quería actualizarte". y mi respuesta de "Ok, la próxima vez por favor actualice el ticket" ¡nunca funciona!
Uno de los valores de Agile son las personas y las interacciones sobre los procesos y las herramientas. Por lo general, fomentamos la comunicación y la apertura, en lugar de confiar en las actualizaciones de una herramienta como JIRA. Sin embargo, si la comunicación distrae, sin duda merece una discusión retrospectiva para ver si hay una manera de adaptar el enfoque del equipo para que esto sea un problema menor.
Declaración del problema: si entendí su problema correctamente, entonces es que el ingeniero de control de calidad no puede comprender y realizar las pruebas de manera eficiente sin múltiples entradas y canales de ayuda.
Análisis: Bueno, lo que falta es ¿Cómo se definen y comunican estas tareas? Si las historias de usuario están definidas en un buen formato que explica las tareas en una perspectiva funcional y técnica con documentos de respaldo, entonces se puede llevar al siguiente nivel. Es responsabilidad del equipo acordar y mantener los protocolos para las diferentes funciones. Al igual que la definición de tareas, debe incluir una historia de usuario que defina lo que se requiere con todos los documentos válidos de respaldo:
Sobre la base de la definición de la tarea, se deben definir criterios de aceptación claros y precisos. Con todas las entradas, el equipo de prueba debe poder elaborar un plan de prueba y casos de prueba, estos casos de prueba pueden ser revisados por los miembros del equipo de desarrollo para proporcionar confirmación o sugerir modificaciones. El equipo de prueba puede publicar un breve plan de ejecución de prueba y los pasos que pueden proporcionar información sobre cómo pueden validar el lanzamiento que se les hizo. Todo esto debería permitir que los miembros del equipo de pruebas entiendan fácilmente la tarea y el alcance de las pruebas. Capacitarlos con las herramientas adecuadas para usar y demostrar cómo se puede verificar la tarea en cualquier entorno dado una vez con pasos sugeridos para reproducir lo mismo en otros entornos y el formato de informe de prueba de control de calidad esperado puede ser muy importante para todos en el equipo.
Capacitación es la palabra más utilizada pero menos practicada. Publicar los pasos correctos y el documento para el desarrollo del equipo es tan complicado como cualquier otra tarea de desarrollo. Invierta tiempo en capacitación mediante la publicación de pautas y documentos correctos. Si el miembro del equipo aún no puede hacer frente, infórmelo de manera adecuada, ya que no le queda otra opción.
Ya que estás "atascado" con esta persona, tu otra opción es mejorar sus habilidades. Una posibilidad es emparejarlos con un desarrollador diferente en cada sprint, en la línea de mi respuesta aquí: https://pm.stackexchange.com/a/27497/37642 . Otra es incluir historias de entrenamiento cruzado, de modo que cada sprint incluya un entrenamiento cruzado formal entre un desarrollador y esta persona. Busque "Cross-Training" aquí en el sitio Full Stack Scrum (gratis y de código abierto).
Pero, en última instancia, según la filosofía Agile, la respuesta que mejor se adapta a un "equipo autoorganizado" podría ser: plantear el problema de manera abierta y honesta en una retrospectiva y dejar que el grupo lo resuelva. Comencé en la tecnología creando "equipos de trabajo autodirigidos", haciendo trabajo en equipo basado en la ciencia y, según sus comentarios, no creo que pueda resolver esto sin enfrentarse a algún conflicto. Cualquiera:
No sé dónde estás (en qué cultura estás), así que me doy cuenta de que esto puede parecer imposible. Si no puedes afrontar la situación, no veo otra opción que negarnos como equipo a darle a esta persona tareas que no puede hacer. Quizás la persona se aburra y se vaya sola.
En mis días de formación de equipos, escribí un libro sobre la creación de un equipo de alto rendimiento, que ahora regalo como un sitio web gratuito. Todavía uso su estructura con equipos Agile hoy. Puede encontrar útil la página Conflictos .
Todd A. Jacobs