Cómo ajustar las pruebas en los sprints de Scrum y cómo escribir historias de usuarios en Scrum

Soy el líder del equipo de desarrollo de un nuevo proyecto en mi empresa. Este es el primer proyecto donde la compañía usará Scrum. Tenemos un SDLC en cascada / iterativo. Los BA escriben documentos de requisitos, se entregan al desarrollador y a la prueba, el desarrollador comienza a desarrollarse y se lanzará a la prueba en iteraciones. Los probadores tardan mucho tiempo en probar una versión mediante la cual los desarrolladores continúan el desarrollo, pero también corrigen errores para la versión actual. Tengo algunas preguntas

1. En un sprint con digamos 5 historias, ¿cuándo se libera para la prueba? ¿Es tan pronto como el desarrollador completa una historia o después de que se completan todas las historias, pero antes del final del sprint, da el tiempo requerido para la prueba?
2. Si el BA escribe historias de usuarios, ¿cuál debería ser el detalle? Tradicionalmente, lleva mucho tiempo escribir una especificación con todo el diseño de la interfaz de usuario, el comportamiento, el texto, etc. para finalizar. Supongo que mi pregunta es cómo escribir historias que sean implementables y comprobables.
3. Nuestro equipo de prueba no es técnico. Qué importante es tener pruebas de IU automatizadas para Scrum. La interfaz de usuario se basa en WPF.

Tengo una sólida experiencia de desarrollo utilizando métodos ágiles (TDD, revisiones de código, refactorización, etc.) pero nuevo en scrum.

editar: Por iteraciones me refiero a que si hay 100 requisitos, podemos lanzar a la prueba cuando hayamos terminado 30, 35, 35 requisitos en lugar de esperar hasta que se hayan completado los 100 requisitos.

Si las pruebas están separadas del desarrollo, tiene dos equipos scrum separados. Es una mala idea tener una mano trabajando para la otra.

Sus desarrolladores deben escribir sus propias pruebas, separadas de este otro equipo. Debe tratar a este otro equipo de "prueba" como sus clientes.

En un sprint ... ¿cuándo se libera para la prueba?

Cuando termina el sprint. Totalmente hecho Eso significa que ha realizado su propia prueba de unidad y está seguro de que funciona. Después de que su equipo de desarrollo haya terminado, lo libera a otros equipos para "probar" o "implementar" o cualquier otra cosa que suceda en la organización.

Supongo que mi pregunta es cómo escribir historias que sean implementables y comprobables.

Eso varía de un equipo a otro. El BA es parte del equipo de desarrollo. Tienes que trabajar en eso como un equipo (BA más desarrolladores) para obtener la cantidad correcta de detalles. Es un esfuerzo de equipo obtener la información correcta de BA para el resto del equipo.

Qué importante es tener pruebas de IU automatizadas para Scrum.

Esencial. Completamente necesario para cualquier desarrollo de IU. Los desarrolladores deben hacer todas las pruebas ellos mismos antes de entregarlo al "equipo de prueba". Si hay una IU, deben probarla. Si no hay interfaz de usuario, no se requieren pruebas de interfaz de usuario automatizadas. Se requieren pruebas y se debe probar una IU. Las pruebas automatizadas son la mejor práctica actual.

Línea de fondo. Un equipo de "prueba" separado y un BA que escribe cada pequeño detalle no es una organización óptima para Scrum. Scrum significa que debe repensar su organización y sus procesos.

La mayoría de las respuestas que voy a dar se relacionan con un método ágil de desarrollo de software versus un método de cascada iterativa. Scrum resulta ser una implementación ágil popular.

1. En Scrum típico, no hay una fase de prueba separada, porque las pruebas formales deben realizarse durante todo el sprint. Cuando un desarrollador termina una historia de usuario, el recurso de control de calidad ya debe tener sus casos de prueba preparados y comenzar a probar en ese punto. Si sus casos de prueba pasan, aceptan la historia del usuario y pasan a la siguiente. Una vez que todas las historias de usuario se hayan completado y aceptado, el sprint habrá terminado y comenzará la siguiente. Por supuesto, todo esto depende de la integración continua, por lo que los cambios de desarrollo están disponibles de inmediato para el control de calidad. El desarrollo posterior debe seguir las pautas de TDD para garantizar que las pruebas de regresión sean lo más rápidas e indoloras posible.

2. Es una buena idea que los BA escriban historias de usuarios, pero para un control más detallado y específico, las Historias de usuarios pueden acompañar documentos formales de Requisitos. La historia del usuario debe escribirse desde la perspectiva de un solo usuario por rol. Expresa una necesidad desde el punto de vista del usuario, por lo que, naturalmente, si el software actualmente satisface todos los aspectos de esa necesidad, la historia del usuario se está cumpliendo. Las historias de usuario pueden estar formadas por historias de usuarios secundarios y tareas asignables. Puede haber superposición en Tareas para múltiples historias de usuario.

3. Las pruebas automatizadas de IU pueden ser algo bueno, pero personalmente creo que es más importante un mayor esfuerzo en los métodos TDD y una cobertura de prueba de unidad del 100% de toda la lógica empresarial. Parece que la mayoría de los equipos de desarrollo de software no pueden lograr una cobertura del 100% de Business Logic, por lo que, en mi opinión, las pruebas automatizadas de IU serían una pérdida de tiempo valioso que podría usarse para escribir más pruebas unitarias para BL. Es un lujo, no es una necesidad en mi opinión.

1. En Scrum, se supone que debes producir un incremento de software potencialmente enviable al final de cada sprint. Como resultado, Scrum promueve el concepto de equipo completo o equipo multifuncional en el que cada habilidad requerida para liderar una historia de usuario determinada debe estar presente en el equipo.

   En mi proyecto actual, dado que una historia completamente probada es parte de nuestra definición de hecho, hemos incorporado probadores en los equipos. Durante los primeros días de un sprint, mientras los desarrolladores comienzan a trabajar en las primeras historias de usuarios, los evaluadores prepararán escenarios de prueba y configurarán algunos datos de prueba. Tan pronto como el desarrollador de una de las historias de usuario haya terminado, lo probarán.

2. Esta es una de las mayores dificultades en Scrum IMO. Debe encontrar la cantidad correcta de especificación necesaria para obtener una historia de usuario implementable y comprobable. Demasiado análisis inicial, documentación y especificación darán como resultado un plan rígido que inevitablemente resultará incorrecto en el transcurso del sprint. Por el contrario, una historia de usuario que no ha sido claramente definida y expresada por el Propietario del producto conducirá a un ancho de banda de comunicación saturado entre los desarrolladores y la OP durante el Sprint y retrasará el desarrollo, mientras que la OP toma decisiones sobre las historias de los usuarios a mitad del sprint .

   En nuestro caso, hemos definido la cantidad correcta de detalles para una historia de usuario como 1 / una descripción en forma de "como ... quiero ... para que ..." y 2 / una serie de aceptación criterios Raramente hacemos maquetas de la IU de antemano, puede suceder durante las planificaciones de sprint, pero son más bocetos que luego se descartan.

3. En mi experiencia, las pruebas automatizadas de IU son extremadamente lentas y extremadamente frágiles. Hay formas de hacerlo en WPF, pero consideraría cuidadosamente el costo de mantenimiento de tales pruebas con los beneficios antes de seguir ese camino.

Trabajar en iteraciones cada vez más cortas hace que todas estas transferencias sean cada vez más caras. Puede reducir estos costos siguiendo una regla simple y estúpida: reduzca el tamaño de los lotes a la mitad, cambie la forma en que trabaja para hacerlo cómodo, repita hasta que esté satisfecho.

Tome su ejemplo de sprint de 5 pisos. Si sus equipos están acostumbrados a escribir el código para las 5 historias, luego probar las 5 historias, entonces el tamaño del lote es de 5 historias. Cortar eso por la mitad. En el próximo sprint, trabaje primero en las 3 historias más urgentes y prepárelas para la prueba lo antes posible. A medida que los evaluadores prueban esas 3 historias, el resto puede preparar las 2 historias restantes para la prueba. Esto causará algunos dolores de crecimiento. Cambia tu forma de trabajar para que esto sea más cómodo.

Por ejemplo, más personas trabajarán juntas en cada historia, así que intente más emparejamiento y vea si eso lo ayuda a trabajar de manera más constante. O, tal vez, los probadores encontrarán problemas en la historia 2 que distraen a algunos programadores mientras intentan trabajar en la historia 5, así que aliente a los programadores y probadores el próximo sprint para discutir antes cómo probar una de las historias en el "primer lote" "para que los programadores sean menos propensos a cometer un error que un probador puede detectar fácilmente con una prueba.

Puede tomar algunos sprints para resolver los grandes problemas asociados con los probadores que prueban un pequeño lote de historias mientras los programadores trabajan en el próximo lote de historias. Una vez que se sienta cómodo, corte el tamaño del lote por la mitad nuevamente. Y otra vez. Dentro de un año más o menos, el equipo probará cómodamente las historias a medida que los programadores crean que han terminado con ellas y probablemente cometerán menos errores en el camino. Cada historia se hará antes.

Por supuesto, en este punto, ahora puede hacer lo mismo con los lotes que el equipo recibe de los propietarios del producto, o que el equipo envía a la organización de operaciones. Y así. En este punto, puede abordar "¿cuántos detalles deben escribir los BA para las historias?" problema.

Por cierto: para que los evaluadores puedan reducir su tiempo de respuesta, tendrán que adoptar cierta automatización, mediante una combinación de aprender a automatizar y los programadores que los ayudan a automatizar. A medida que intente reducir el tamaño del lote, descubrirá cuándo debe solucionar esos problemas. No agregue la automatización solo porque un libro dice que la necesita.

Espero que eso te ayude.

Solo quiero compartir algunas experiencias como se muestra a continuación, espero que sea útil para usted.

En un sprint con digamos 5 historias, ¿cuándo se libera para la prueba? ¿Es tan pronto como el desarrollador completa una historia o después de que se completan todas las historias, pero antes del final del sprint, da el tiempo requerido para la prueba?

Para cada gran historia de usuario, debe desglosarse en muchas subtareas y cuando el desarrollador realiza las subtareas por completo, debe enviarlas al control de calidad para que las pruebe de inmediato. El defecto debe repararse después de que las pruebas de esas subtareas terminen las pruebas.

Si el BA escribe historias de usuarios, ¿cuál debería ser el detalle? Tradicionalmente, lleva mucho tiempo escribir una especificación con todo el diseño de la interfaz de usuario, el comportamiento, el texto, etc. para finalizar. Supongo que mi pregunta es cómo escribir historias que sean implementables y comprobables.

En Scrum, las historias de los usuarios deben estar en cualquier formato siempre y cuando no se espere que las conversaciones que rodean las historias se completen o sean estáticas. Una pequeña historia, llamada simplemente una historia de usuario, es una que se entiende bien y se puede implementar dentro de un sprint. La prioridad de una historia puede basarse en el ROI, el valor comercial o cualquier otra cosa que el usuario acuerde que es importante. Estas son actividades de PO.

Nuestro equipo de prueba no es técnico. Qué importante es tener pruebas de IU automatizadas para Scrum. La interfaz de usuario se basa en WPF

Aplicar las pruebas de automatización en Scrum es una actividad bastante difícil. Debido a que todas las funciones se implementan de manera incompleta y no son realmente estables para permitir que QC implemente el caso de prueba mediante alguna herramienta de prueba automática. Debe hacerse para un sprint llamado: regresión.