Recientemente me han trasladado a un nuevo equipo. Hay muchas prácticas que creo que no están en términos con la Guía de Scrum, pero por ahora quiero discutir dos prácticas extrañas.
Planteé este punto con los QA y Agile Coach y la respuesta fue que Scrum nos permite cambiar ciertas cosas a medida que aprendemos de la experiencia, por lo que hemos introducido esta cosa. Quiero saber si esta práctica es correcta o incorrecta. Realmente no puedo hacer nada práctico al respecto excepto plantear el tema en la Retrospectiva.
En este momento, en nuestro equipo, si el control de calidad encuentra un problema con la tarea, mantienen las tareas en prueba, pero agregan un nuevo error como sub y se las asignan al desarrollador.
Mi pregunta es: ¿es correcto este enfoque? Por ejemplo, hay una tarea para cambiar el color de dos botones, uno ahora debería ser verde y el otro debería ser rojo. Un desarrollador trabaja en esta tarea, primero entiende la tarea. ¿Cómo deberían hacer esto, usar CSS o JavaScript (este es solo un ejemplo simple, así que tengan paciencia conmigo)? Cambian solo un botón, o se olvidan de cambiar otro botón, o cambian ambos, pero debido a una mala codificación, solo se cambia uno. Ahora, el desarrollador pasa esta tarea a prueba, el control de calidad prueba la tarea y descubre que solo se cambió un botón. Ahora, ¿debe enviarse el problema al desarrollador o debe informarse un error?
Ahora mi pregunta es: ¿cuál es el mejor enfoque para los dos casos anteriores?
El equipo de desarrollo debe tener todas las habilidades necesarias para convertir los elementos pendientes en incrementos de software funcional. Para que eso sea cierto, deben tener las habilidades para completar todas las pruebas en el equipo durante el Sprint.
El control de calidad separado no tiene sentido si su equipo de desarrollo crea software que funcione. Parece que hay una brecha en su equipo donde debería estar la prueba. Hablaría de esto en la retrospectiva e intentaría explorar por qué existe una dinámica de "nosotros contra ellos" entre el equipo de desarrollo y los individuos de control de calidad.
Primero, no existe una forma correcta de probar en Scrum, solo existe la forma que funciona para el equipo. Scrum no describe ninguna práctica cuando se trata de pruebas. Si cree que el camino no funciona, discútalo durante la retrospectiva.
Para responder a sus preguntas desde mi perspectiva como probador Agile:
La prueba en paralelo es buena, la creación de informes de errores no lo es. Como probador, crearía pruebas automatizadas para cubrir estos nuevos requisitos para que un desarrollador pueda implementarlos. Discutiría los hallazgos con el equipo y el propietario del producto. Los cambios de alcance deben ir a la cartera de pedidos. Defectos en la funcionalidad existente como tareas en el Scrumboard, pero preferiría una prueba automatizada.
En Scrum nunca asignas a un desarrollador, ya que es un sistema de extracción, el equipo extrae de la quietud para completar el trabajo para cumplir con el objetivo de Sprint. Cualquier desarrollador puede detectar los defectos si lo desea. Usaría una pizarra física y pondría un post-it con el problema en la pizarra. Informar sobre un defecto en un rastreador de defectos parece una pérdida de tiempo, ya que prefiero discutir el problema primero con el equipo y el propietario del producto.
Evite el ping-pong de QA<->DEV, permita que los evaluadores programen en pareja con los desarrolladores y asegúrese de que el retrabajo sea perfecto después de la primera vez. Esto podría ser algo para probar si esto sucede mucho.
Scrum es un enfoque de equipo, hablar con el equipo, resolver problemas con el equipo. Deje de pensar en un solo desarrollador.
Lea sobre el enjambre:
jason.t.knight