Soy un QA / Test manager en mi organización y hasta hoy he verificado la calidad del software (pruebas escritas y ejecutadas y errores corregidos) ¿Quién va a verificar esto en Scrum? ¿Cómo sé que el equipo escribió y ejecutó todas las pruebas correctas? Por otro lado, me temo que si continúo haciendo la verificación, el equipo no se sentirá lo suficientemente capacitado. Pero necesito algún proceso de verificación de que "Hecho" es de hecho "Hecho". ¿Qué sugieres?
Una idea importante en Scrum es que el equipo debe acordar una "definición de hecho". Idealmente, esto es algo así como un conjunto de criterios objetivos que cualquiera puede verificar al revisar una lista de verificación.
Pero para reducir la posibilidad de que algo se resbale, tiene mucho sentido tener una regla que verifique que el "hecho" sea realizado por alguien que no sea la persona que implementó un elemento, o un tipo QA designado como usted (pero eso se arriesga a hacerte un cuello de botella).
Si tiene dudas, discuta con el equipo y el Scrum Master y decida juntos.
Creo que hay un supuesto implícito en la pregunta. Existe una diferencia entre "aceptado", cuando un Propietario del producto declara que un elemento o tarea atrasada ha satisfecho al Propietario del producto, y "terminado" significa que todo el trabajo asociado con el elemento de acumulación está completo.
Sin embargo, generalmente hay una tarea más que la que puede ver el propietario del producto, generalmente una persona semi-técnica en el mejor de los casos, que incluye pruebas, documentación y revisión (automatizadas y manuales). El propietario del producto rara vez puede conocer los aspectos técnicos, y mucho menos si se han completado.
Por lo tanto, en última instancia, depende del equipo determinar qué significa "hecho". La organización puede tener estándares y diferentes partes interesadas tendrán sus propios requisitos. El scrum master o los gerentes relevantes generalmente son responsables de compilar y hacer cumplir la lista.
En su ejemplo, como gerente de control de calidad / prueba, usted es quien dice si las pruebas están completas. Sin embargo, es posible que no sea la mejor persona para decir si el código ha sido revisado, se cumplen los requisitos de seguridad, el producto está internacionalizado, la documentación está completa o cualquier otra cosa que se considere "hecha".
El único concepto de "hecho" es si una historia en su totalidad se completa o no. El equipo debería haber creado una definición de "hecho" que dice cuándo sienten que una historia está terminada o no. Por lo general, esto incluye cosas como "el código ha sido revisado", "las pruebas nocturnas se han ejecutado", "se han cumplido todos los criterios de aceptación", etc. Se espera de ellos para terminar una historia.
Durante un sprint, si está tratando de determinar si uno de esos elementos en la definición de hecho se ha cumplido, simplemente pregunte. Scrum y ágil tiene que ver con la comunicación abierta. Si usted es parte del equipo, pregúntele a sus compañeros de equipo si alguien ha escrito las pruebas, las ha ejecutado o ha creado el trabajo nocturno, etc. Si es una parte interesada, pregúntele al maestro del scrum.
Si se sienta fuera del equipo pero aún debe revisar las pruebas, pídale al equipo que agregue "el usuario user3251930 debe revisar las pruebas" como parte de la definición de "hecho". Si eso es lo que se necesita para que se haga una historia, sea honesto al respecto y hágalo parte del proceso. Todo el punto de la "definición de hecho" es para que el equipo pueda saber con certeza que ha hecho lo que se requiere para entregar software de calidad. Si parte de eso es una revisión externa, que así sea.
En última instancia, es el propietario del producto el que firma una historia en particular, por lo que al final del día él o ella tiene la decisión final de si una historia en su conjunto se realiza o no.
Primera pregunta que debes hacerte
¿Eres Scrum Master ? si es así.
En Scrum los procesos son controlados y administrados por Scrum Master.
¿Cómo lo haces?
En la fase de requisitos, puede utilizar las historias de usuario para cada una de las pruebas que deben verificarse.
En cada Sprint Los elementos de trabajo se extraen de la cartera de productos y son dirigidos por el propietario del producto. Cada uno de ellos también tendrá criterios de verificación.
Ahora, los requisitos de Scrum no cambian después de que el sprint haya comenzado. Al final del Sprint, puede analizar la verificación de acuerdo con los criterios para cada elemento realizado.
Si se hace, solo se puede encontrar en la respuesta del propietario del producto.
Recuerde en Agile que "aceptó el cambio" incluso en la fase de desarrollo
El equipo decide. Yo uso una lista de verificación, para lo que se considera 'Hecho'. ¿Qué es 'Hecho' por historia, por sprint, por lanzamiento?
Como han mencionado otros, en última instancia, la decisión es del propietario del producto.
Acepte que esto es algo que el equipo de desarrollo / prueba necesita definir, según sus propias prácticas. Algunos proyectos son tan ágiles que están dispuestos a arriesgarse a lanzar errores a su flujo alfa; algunos consideran que cualquier error que salga del grupo de desarrollo sea un error de proceso.
El proyecto en el que estoy trabajando requiere una revisión por pares de los cambios de código, y requiere que quien haya escrito el código proporcione / actualice las pruebas de regresión o explique por qué no es posible hacerlo. (Ellos y sus revisores también tienen que certificar que han comprobado las malas prácticas conocidas. En general, somos mucho más felices si podemos demostrar que ejecutaron el conjunto completo de pruebas y obtuvieron un resultado limpio (o un módulo limpio conocido problemas abiertos, al menos) El código luego tiene que sobrevivir a pruebas funcionales y de unidades automatizadas intensivas en múltiples plataformas para demostrar que no causa regresiones en contra de ellas, y un sistema de análisis de códigos automatizado controla aún más los antipatrones comunes. luego lo aceptamos en el flujo de desarrollo principal y marcamos el elemento de trabajo como completado. Tenga en cuenta que completar un elemento de trabajo solo puede ser un paso para completar una tarea o historia a gran escala.
Eso obviamente no garantiza que nadie encuentre una nueva forma de fallar, pero reduce el riesgo a un nivel aceptable sin impedir en gran medida la velocidad de desarrollo.
Lea otras preguntas en las etiquetas scrum