¿Por qué la guía Scrum dice que no hay evaluadores?

14

He estado leyendo la Guía Scrum de scrum.org y dice:

Los equipos de desarrollo no contienen sub-equipos dedicados a dominios particulares como pruebas o análisis de negocios.

En su traducción literal, esto significa que no hay evaluadores, lo cual es confuso. ¿Cómo pueden estar sugiriendo esto?

scrum Pete2k
fuente
44
En su traducción literal, esto significa que tampoco hay programador. No hay analista de negocios. Una analogía acertada es que todos son sobrevivientes, cuyo trabajo es hacer (y aprender a hacer) todo lo necesario para ayudar a todos a sobrevivir.
rwong
3
No, esa no es la traducción literal en absoluto. Dice que no hay sub-equipos dedicados, eso es todo. Puede dividir su equipo en sub equipos para abordar los problemas, pero esos equipos deberían ser capaces de mezclar y combinar en un abrir y cerrar de ojos. No dice nada acerca de no tener probadores.
zzzzBov

Respuestas:

25

Significa que:

  1. Los probadores están integrados en el equipo de desarrollo, creando herramientas para ayudar a los desarrolladores a realizar pruebas y pruebas.

    o:

  2. El equipo practica Test Driven Development, es decir, escriben pruebas automatizadas que ejercitan el sistema.

Cualquiera de estos significa que no hay necesidad de un equipo de prueba por separado.

ChrisF
fuente
TDD sería un mejor enfoque para los equipos de inicio. Creo firmemente que cuando los probadores y desarrolladores trabajan juntos en equipos novatos, las pruebas se convierten en un problema. ¿Qué dices?
Maxood
44
@Maxood: Diría que TDD definitivamente no hace que las pruebas manuales sean superfluas. Si algo se convierte en un problema, lo resuelve; No empiezas a evitarlo.
Michael Borgwardt
@MichaelBorgwardt ¡Muy cierto! Pero, ¿qué sucede si encuentra que su probador está ocupado en pruebas unitarias, que es principalmente el trabajo de un desarrollador? Creo que la primera opción solo debería utilizarse cuando se trata de la optimización del código y la escalabilidad de la aplicación, etc. ¿Qué dice usted?
Maxood
77
@Maxood: los evaluadores no deberían, en mi opinión, tocar las pruebas unitarias. Deben trabajar en pruebas de aceptación, en cooperación con los desarrolladores, y tener la responsabilidad de las pruebas manuales / GUI. Las pruebas unitarias están en un nivel que solo es interesante para los desarrolladores. La pirámide de prueba ( blogs.agilefaqs.com/2011/02/01/inverting-the-testing-pyramid ) también tiene respuestas, pruebas unitarias = desarrolladores, pruebas de aceptación = compartidas, pruebas GUI = probadores.
martiert
12

En su traducción literal, esto significa que no hay probadores que es confuso ... ¿Cómo pueden estar sugiriendo esto?

Sí, esto es exactamente lo que sugieren. En otras palabras, los desarrolladores son los probadores y los probadores son los desarrolladores.

La idea es fomentar la propiedad y la calidad del código .

Esto no significa que el código no se pruebe, sino que las personas involucradas en escribirlo son las que participan en la prueba; no hay separación de responsabilidades.

El problema que este enfoque está tratando de abordar es la separación demasiado común entre los desarrolladores y los evaluadores, donde los desarrolladores escribirán código y lo "arrojarán por la pared" al otro equipo y luego va y viene, retrasando el proyecto y produciendo software de baja calidad.

Oded
fuente
2
Soy un gran defensor de que la persona A pruebe lo que la persona B desarrolló. ¿Qué tiene Scrum como consejo para evitar las trampas de la "ceguera al código propio" (donde si usted es tanto desarrollador como probador de la característica X, no ejerce el código en todos los aspectos porque sabe cómo está codificado y asume que debe trabajo, o inconscientemente evitar los puntos más débiles)?
Marjan Venema
1
@MarjanVenema: qué persona A escribió puede ser probada por la persona B, o las pruebas automatizadas pueden escribirse antes de que se escriba cualquier código.
Oded
55
Todos los desarrolladores tienen una ceguera de control de calidad que nunca desaparece. Lo que sucedió en la industria es que la gente fue demasiado lejos con el "QA versus Devs" y creó ese sistema de "tirar por la pared", y luego hay una reacción violenta. Los desarrolladores y el control de calidad tienen éxito y fracasan como un solo equipo, pero el control de calidad es un rol y una habilidad que es diferente a la codificación. Los codificadores necesitan pruebas de desarrollo, y las pruebas unitarias son parte del control de calidad, pero no es toda la función de control de calidad. Además, los roles de control de calidad a menudo implican la creación de documentación en lugares que no se han vuelto tan "ágiles" que han dejado de escribir documentación técnica.
Warren P
66
En mi experiencia, es exactamente la separación de roles lo que permite que un evaluador mire el software desde el punto de vista de un usuario final y encuentre muchos más errores que un desarrollador. El producto resultante definitivamente no es "subestándar".
Giorgio
2
El control de calidad y el desarrollo son dos roles distintos con dos conjuntos de habilidades diferentes (y escalas salariales). Un control de calidad excelente requiere un nivel de enfoque y especialización que simplemente no sucederá si alguien está cumpliendo una doble función como desarrollador y control de calidad.
17 de 26
2

La parte fundamental de esto es que la responsabilidad del codificador es crear un código que funcione y cumpla con el requisito. Esto requiere una mentalidad particular: "El código que estoy escribiendo hace lo que se supone que debe hacer".

Mezclar las responsabilidades del codificador significa que ahora se requiere que el codificador ingrese a otras mentalidades para otras actividades, sin embargo, como codificador, es difícil que uno se divorcie completamente de esa mentalidad.

La responsabilidad del probador es encontrar errores y lugares donde la funcionalidad se desvía de la funcionalidad requerida. Esto requería la mentalidad de "El código está roto y descubriré cómo".

Del mismo modo, un analista de negocios está tratando de identificar los requisitos que el cliente realmente solicita. Esto requiere otra mentalidad de "la aplicación no funciona de esta manera, pero debería".

Para que un codificador trabaje en cualquiera de esas otras capacidades, existe una probabilidad razonable de que la mentalidad entre en conflicto y el codificador realice un rendimiento inferior al siguiente:

  • Codificador / QA: "El código funciona perfectamente, y ya lo he codificado para manejar todas las formas posibles en las que pueda pensar que podrían romperlo".
  • Codificador / BA - "El código debería funcionar de la manera que yo quiero y sería bueno agregarle cosas que el cliente no pensó.

Esto no quiere decir que cada codificador sea susceptible a estos problemas (he conocido algunos tipos muy codificados / de control de calidad ... aunque no por el código que escribieron).

Esto se extiende también al equipo de desarrollo. La combinación de las responsabilidades y la mentalidad asociada de esas responsabilidades para un equipo de desarrollo compromete el producto final (el código).

geocodezip
fuente
1

Dice que no hay un equipo secundario dedicado a las pruebas. Eso no significa que no se realicen pruebas de ningún tipo. Solo significa que los miembros del equipo harán sus propias pruebas y, a menudo, probarán el código / características de otras personas. No estoy tan familiarizado con la metodología scrum, pero voy a decir que el cliente también puede estar involucrado en las pruebas.

marco-fiset
fuente
"El cliente también puede estar involucrado en la prueba" - sí, exactamente correcto, de lo contrario tiene un proyecto en cascada donde la definición de hecho es "hemos llegado al final del proyecto". Eso no es ágil.
Robin Green
1

Creo que esto en parte significa que se espera que escriba pruebas para su propio código para que sepa que funciona (si no, realmente no lo ha terminado) y en parte que es probable que a veces sea un probador del código de otras personas .

En lugar de permitir que las personas descarguen el trabajo de calidad del software en otra persona y lo ignoren, esto obliga a todos a pensar en el código que están escribiendo desde una perspectiva de calidad todo el tiempo, por lo que es una buena idea.

Matt Gibson
fuente
1

Esta declaración básicamente está tratando de evitar el trabajo en silos. Una parte de la solución a esto son prácticas como: Desarrollo impulsado por pruebas, Programación de pares, Solicitudes de extracción, Automatización de pruebas y similares que hacen que las pruebas sean una parte intrínseca del proceso de desarrollo en lugar de algo que se realiza de forma aislada 'después'.

Además, se habla muy poco sobre los roles en la Guía Scrum. De hecho, hablan sobre el equipo de desarrollo. Lo que quieren decir es que quieres un equipo fuerte y multifuncional. Esto significa que, dependiendo de lo que necesiten sus proyectos, necesita una variedad de habilidades, como UX, BA, QA / Tester, Ops, Coder, etc., etc.

Los equipos con los que trabajo ciertamente tienen un control de calidad como rol, ya que tenemos personas de DevOps. Pero todos ellos también son desarrolladores, solo con especialización en estas áreas. El truco realmente es no caer en los silos y trabajar de forma aislada.

usuario334514
fuente
1

No significa necesariamente que no haya evaluadores. Puede ser el caso de que un equipo Scrum tenga probadores dedicados o no.

Para mí, lo que significa esta afirmación sobre Scrum es que debes pensar en todo el proceso de entrega como un solo equipo. Ser parte del mismo equipo sugiere algunas cosas:

  1. Hay una sola estimación en una historia / error / tarea. No hay una estimación de desarrollo y una estimación de prueba.
  2. El equipo no estima una historia y se compromete a ella sin el probador presente.
  3. Si algo sale mal, no es más culpa del probador que del desarrollador. Es culpa del equipo .
  4. El equipo nunca necesita pedir prestados, solicitar o pedir evaluadores.
  5. La prueba es parte de la definición de hecho. El trabajo no probado es trabajo incompleto.
  6. Los desarrolladores deberían considerar la posibilidad de prueba a medida que diseñan su código.

Si están trabajando juntos en un solo equipo, entonces el equipo tiene éxito juntos y falla juntos. He estado en un equipo Scrum muy exitoso que tenía varios evaluadores. Los evaluadores estuvieron presentes durante todas las paradas, sesiones de preparación, planificación, etc. Si no estaba claro cómo evaluar una historia, el equipo no se comprometería a ello. Siempre hablamos con nuestros evaluadores cuando estimamos.

Posibles signos de que realmente no trate a los evaluadores como parte del equipo de entrega, incluso si cree que lo hace:

  1. Los probadores tienen un "QA standup" (sí, lo he visto).
  2. Los probadores tienen una estructura de gestión separada.
  3. Tienes un control de calidad.
  4. Depende en gran medida de las pruebas de extremo a extremo.
  5. Las pruebas se escriben el siguiente sprint.
  6. La mayoría de las pruebas se realizan el último día del sprint.

Estos son subjetivos y no necesariamente incorrectos. Sin embargo, son banderas rojas, en mi opinión.

Dicho todo esto, es completamente posible tener un equipo Scrum sin nadie que tenga un rol designado de probador. Eso también puede funcionar bien. Especialmente si automatizas las pruebas. TDD también ayuda.

Brandon
fuente