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 probadores, lo que es confuso. ¿Cómo pueden estar sugiriendo esto?
Significa que cualquiera de los dos:
Los evaluadores están integrados en el equipo de desarrollo: herramientas de creación para ayudar a los desarrolladores a probar y probar.
o:
El equipo practica el desarrollo guiado por pruebas, es decir, escriben pruebas automatizadas que ejercitan el sistema.
Cualquiera de estos significa que no hay necesidad de un equipo de prueba separado.
En su traducción literal, esto significa que no hay evaluadores, lo cual es confuso ... ¿Cómo pueden sugerir 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 del código y la calidad .
Esto no significa que el código no se haya probado, sino que las personas involucradas en escribirlo son las involucradas en la prueba; no hay una separación de responsabilidades.
El problema que trata de resolver este enfoque es la separación demasiado común entre los desarrolladores y los evaluadores, donde los desarrolladores escriben el código y lo "tiran por la pared" al otro equipo y luego van y vienen, retrasando la Proyecto y producción de software sub-estándar.
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 programador, es difícil o imposible 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 sabré cómo".
Del mismo modo, un analista de negocios está tratando de identificar los requisitos que el cliente realmente está solicitando. Esto requiere otra mentalidad de "la aplicación no funciona de esta manera, pero debería".
Para que un programador trabaje en cualquiera de esas otras capacidades, existe una posibilidad razonable de que las mentalidades entren en conflicto y el programador realice el sub-par:
Esto no quiere decir que todos los codificadores sean susceptibles a estos problemas (he cumplido con algunos tipos de codificadores / QA muy dotados ... aunque no para el código que escribieron).
Esto se extiende hasta el equipo de desarrollo también. 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).
Dice que no hay sub - equipo dedicado a las pruebas. Eso no significa que no hay pruebas realizadas en absoluto. 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 muy familiarizado con la metodología scrum, pero me arriesgaré y diré que el cliente también puede participar en las pruebas.
Creo que esto en parte significa que se espera que escribas pruebas para tu propio código para que sepas que funciona (si no, que realmente no lo hayas terminado) y en parte para que puedas esperar a ser un probador para otros Código de personas a veces.
En lugar de permitir que las personas descarguen el trabajo de calidad del software a otra persona e ignorarlo, 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.
Lea otras preguntas en las etiquetas scrum