Soy gerente de control de calidad / pruebas en mi organización y hasta hoy verifiqué la calidad del software (pruebas escritas y ejecutadas y errores corregidos). ¿Quién 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 un proceso de verificación de que "Listo" es "Listo". ¿Que sugieres?
Respuestas:
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 mediante una lista de verificación.
Pero para reducir la posibilidad de que algo se escape, tiene mucho sentido tener una regla que la verificación de "hecho" sea realizada por alguien que no sea la persona que implementó un elemento, o un tipo de control de calidad designado como tú (pero eso corre el riesgo de hacerte un cuello de botella)
En caso de duda, discuta con el equipo y el Scrum Master y decidan juntos.
Creo que hay una suposición implícita en la pregunta. Hay una diferencia entre "aceptado", cuando un Propietario del producto declara que un elemento o tarea pendiente ha satisfecho al Propietario del producto, y "hecho", lo que significa que todo el trabajo asociado con el elemento atrasado está completo.
Sin embargo, regularmente hay más en una tarea que la que puede ver el propietario del producto, por lo general alguien semi-técnico en el mejor de los casos, que incluye pruebas (automatizadas y manuales), documentación y revisión. El propietario del producto rara vez está en condiciones de 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 cotejar y hacer cumplir la lista.
En su ejemplo, como administrador 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, si se cumplen los requisitos de seguridad, si el producto está internacionalizado, si la documentación está completa o si se considera que está "hecho".
El único concepto de "hecho" es si se completa o no una historia en su conjunto. El equipo debería haber creado una definición de hecho que diga cuándo sienten que una historia está terminada o no. Por lo general, esto incluirá cosas como "se ha revisado el código", "se han realizado pruebas nocturnas", "se han cumplido todos los criterios de aceptación", etc. Cuando se han logrado estas cosas, el equipo puede sentirse seguro de que han hecho todo Se esperaba de ellos que terminaran una historia.
Durante un sprint, si está tratando de determinar si se ha logrado uno de esos elementos en la definición de hecho, solo pregunte. Scrum and Agile tiene que ver con la comunicación abierta. Si usted es parte del equipo, pregunte a sus compañeros si alguien ha escrito las pruebas, o las ha ejecutado, o ha creado el trabajo nocturno, etc. Si usted es una parte interesada, pregúntele al scrum master.
Si se sienta fuera del equipo pero aún debe revisar las pruebas, haga que el equipo agregue "las pruebas deben ser revisadas por el usuario user3251930" como parte de la definición de hecho. Si eso es lo que se necesita para que se haga una historia, sea honesto y hágalo parte del proceso. El objetivo de la "definición de hecho" es que el equipo pueda saber con certeza que ha hecho lo que se requiere para entregar un 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 el Scrum Master ? en caso afirmativo.
En scrum, los procesos son controlados y gestionados por el Scrum Master.
Cómo lo haces:
En la fase de requisitos, puede utilizar las historias de usuario para cada una de las pruebas que debe verificarse.
En cada Sprint, los elementos de trabajo se extraen de la cartera de pedidos del producto y son dirigidos por el propietario del producto. Cada uno de ellos también tendrá criterios de verificación.
Ahora, en Scrum, los requisitos no cambian después de que el sprint ha comenzado. Al final del Sprint puede analizar la verificación de acuerdo con los criterios para cada elemento realizado.
Si está hecho, solo puede encontrarlo la respuesta del propietario del Producto.
Recuerda que en Agile "abrazas el cambio" incluso tarde en la fase de desarrollo
El equipo decide. Yo uso una lista de verificación, para lo que se considera 'Hecho'. ¿Qué se hace por historia, por sprint, por lanzamiento?
Como otros han mencionado, en última instancia, la decisión recae en el propietario del producto.
Acuerde que esto es algo que el equipo de desarrollo / prueba necesita definir, dependiendo de sus propias prácticas. Algunos proyectos son tan ágiles que están dispuestos a arriesgarse a liberar errores en su secuencia alfa; algunos consideran que cualquier error que sale del grupo de desarrollo es un fallo del proceso.
El proyecto en el que estoy trabajando requiere una revisión por pares de los cambios de código, y requiere que quien escribió el código proporcione / actualice las pruebas de regresión o explique por qué no es posible hacerlo. (Ellos y sus revisores también deben certificar que han verificado las malas prácticas conocidas. En general, somos mucho más felices si pueden demostrar que ejecutaron el conjunto de pruebas completo y obtuvieron un resultado limpio (o un módulo limpio conocido problemas abiertos, al menos) El código tiene que sobrevivir a la unidad intensiva automatizada y a las pruebas funcionales en múltiples plataformas para demostrar que no causa ninguna regresión en contra de ellas, y un sistema automatizado de análisis de código comprueba aún más los antipatrones comunes. luego lo aceptamos en la secuencia de desarrollo principal y marcamos el elemento de trabajo completo.
Obviamente, eso no garantiza que nadie encuentre una nueva forma de fracasar, pero reduce el riesgo a un nivel aceptable sin obstaculizar en gran medida la velocidad de desarrollo.
DoneyUndone