En Scrum, ¿quién verifica "Hecho"?

13

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?

Eugene
fuente

Respuestas:

21

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.

Michael Borgwardt
fuente
+1 aunque el propietario del producto normalmente no se considera parte del equipo (s), generalmente se lo saca del círculo del equipo, pero tiene (o debería tener) algo que decir en la definición de hecho. Es la única forma en que el propietario del producto puede (puede) influir en la forma en que trabaja el equipo.
Marjan Venema
1
@MarjanVenema El propietario del producto se considera una parte muy importante del equipo Scrum. De hecho, sin el propietario del producto, Scrum tiene pocas o ninguna posibilidad de tener éxito.
Derek Davidson PST CST
1
@Derek: Creo que está teniendo un malentendido basado en una terminología poco clara. Hay un "Equipo Scrum" y un "Equipo de Desarrollo", siendo este último parte del primero, así como el Propietario del Producto y el Scrum Master.
Michael Borgwardt
2
@MichaelBorgwardt Es por eso que fui tan claro en mi respuesta que el Dueño del Producto es parte del Equipo Scrum . Estoy de acuerdo en que el propietario del producto no forma parte del equipo de desarrollo, pero el contexto no lo dejó claro. Esperaba despejar la confusión. Parece que sin querer he creado algunos :)
Derek Davidson PST CST
6

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".

akton
fuente
4

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.

Bryan Oakley
fuente
Necesito revisar las pruebas, de lo contrario no sabría si se escribieron las pruebas correctas. La definición de "Listo" no incluye las pruebas exactas que deben escribirse.
Eugene
@ user3251930: ¿por qué necesita revisarlos? ¿No confías en tu equipo? Sin embargo, si realmente necesita revisarlos, haga parte de la definición de hecho "las pruebas han sido revisadas por el usuario3251930".
Bryan Oakley
Si los clientes obtienen algo que no se probó por completo, sería realmente malo. Tal vez con el tiempo pueda confiar en el equipo, eso espero.
Eugene
1

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

Neo
fuente
0

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.

Sherbert
fuente
¿Es esta solo su opinión personal o puede respaldarla de alguna manera?
mosquito
-1

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.

keshlam
fuente