Ayúdame a entender cómo funciona QA en Scrum [cerrado]

Un poco tarde para la fiesta aquí pero aquí está mi opinión basada en lo que escribiste.

Ahora, Scrum es una metodología de gestión de proyectos, no de desarrollo. Pero es clave, en mi opinión, tener un proceso de desarrollo en marcha. Sin uno, pasas la mayor parte de tu tiemporeaccionando en lugar de construir.

He estado justo donde estás en esta metodología de desarrollo que llamo el Método de la Espiral de Muerte. Construí software para el gobierno (EE.UU.) durante años en un modelo de este tipo. No funciona bien, cuesta mucho dinero, produce código tardío, código pobre y no hace nada por la moral. No puedes hacer ningún progreso cuando pasas todo tu tiempo arreglando errores que podrías haber evitado hacer en primer lugar. Estaba absolutamente abatido por la aventura.

Usted no quiere QA encontrar sus problemas. Quieres dejarlos sin trabajo, de verdad. Mi objetivo es hacer que QA quede atónito porque todo funciona. Por supuesto, ese es un objetivo. En la práctica, encontrarán cosas. No soy súper humano. Cometo errores.

Volver a la programación...

En mi trabajo actual hacemos Scrum, simplemente no lo llamamos así. No estamos en las etiquetas aquí, pero estamos en la producción de código de calidad puntualmente. Todos están a bordo. Le decimos a QA lo que tendremos listo para probar y cuándo. Si llegan dos semanas antes, pueden hablar con la mano. Todo el mundo conoce el calendario, todo el mundo sabe lo que estará en el lanzamiento y todo el mundo sabe que el producto tiene que funcionar como se anuncia antes de que vaya a QA. Entonces, ¿qué significa eso? Le dices a QA "no te molestes en probar XYZ-está roto y no se arreglará hasta la versión C" y si van a probar eso, los señalas de vuelta a eso declaración y diles que no pierdan su tiempo. Duro, tal vez, pero a veces necesario. No se trata de ser grosero, pero todo el mundo necesita saber "las reglas" y lo que debe ser probado y lo que es un "problema conocido".

Su dirección tiene que estar a bordo. Si no vas a tener problemas. QA no puede ejecutar el programa y el grupo de desarrollo tampoco puede ejecutarlo por completo. Todos los grupos (incluso si esos grupos son solo una persona por grupo o un chico que usa varios sombreros) deben estar en la misma página: el cliente, el equipo de prueba, los desarrolladores, la administración y cualquier otra persona. Más de la mitad de la batalla es la comunicación, por lo general.

Tal vez usted está mordiendo más de lo que se puede lograr durante un sprint. Ese podría ser el caso. ¿Por qué haces eso? Para cumplir con un horario? Si es así, ahí es donde la administración debe intervenir y resolver el problema. Si usted está dando QA buggy código, esperar a tirar de nuevo. Mejor darles 3 cosas que funcionen que 8 cosas que están sin terminar. El objetivo es producir algún conjunto de funcionalidad que se implemente completamente en cada iteración, no juntar un montón de cosas a medio hacer.

Espero que esto se reciba como se pretende - como un estímulo no una diatriba. Como mencioné, he estado donde estás y no es divertido. Pero hay esperanza. Puedes cambiar las cosas en un sprint, tal vez dos. Tal vez no agregue ninguna funcionalidad nueva en el próximo sprint y simplemente arregle lo que está roto. Tendrán que decidirlo como equipo.

Un pequeño enchufe más para escribir código de prueba: Me he encontrado mucho más relajado y mucho más seguro en mi producto desde que adopté un enfoque de "escribir las pruebas primero". Cuando todas mis pruebas pasan, tengo un nivel de confianza que simplemente no podría tener sin ellas.

¡Mucha suerte!

Me parece que hay un problema de asignación de recursos en escenarios que requieren pruebas funcionales de control de calidad para que una característica determinada se 'haga' dentro de un sprint. Nadie parece abordar esto en cualquier discusión scrum relacionada con QA que he encontrado hasta ahora, y la pregunta original aquí es casi la misma (al menos relacionada), así que quería ofrecer una respuesta parcial y extender la pregunta un poco.

En cuanto a la pregunta original específica sobre las tareas de desarrollo que toman el sprint completo-parece que el consejo general de facilitar estas tareas tiene sentido si la prueba funcional por QA es parte de su definición de "hecho". Dado digamos que un sprint de 4 semanas, si se necesita alrededor de una semana para probar varias características de varios desarrolladores, entonces parece que las tareas de desarrollo toman alrededor de 3 semanas, seguido de una semana de retraso de las tareas de prueba que toman alrededor de 1 semana es la respuesta. QA, por supuesto, comenzaría tan pronto como sea posible, ya que reconocemos que desde el último conjunto de características entregadas, habrá una semana de retraso. Me doy cuenta de que queremos obtener características a QA lo antes posible para que no tenga este escenario similar a una cascada en un sprint, pero la realidad es que el desarrollo generalmente no puede obtener una funcionalidad real, que valga la pena entregar a QA hasta 1 a 3 semanas después del sprint. Seguro que hay trozos y piezas aquí y allá, pero la mayor parte del trabajo es 2-3 semanas de desarrollo, luego alrededor de una semana de pruebas sobrantes.

Así que aquí está el problema de asignación de recursos, y mi extensión a la pregunta-en el el escenario anterior QA tiene tiempo para probar las características planificadas de un sprint (3 semanas de tareas de desarrollo, dejando la última semana para probar las características entregadas en último lugar). También supongamos que QA comienza a obtener algunas características probables después de 1 semana de desarrollo, pero ¿qué pasa con la semana #1 para QA y qué pasa con la semana #4 para desarrollo?

Si las pruebas funcionales de control de calidad son parte de la definición de 'hecho' para una característica en un sprint, entonces parece que esta ineficiencia es inevitable. QA será en gran medida inactivo durante la semana # 1 y el desarrollo estará en gran parte inactivo durante la semana #4. Por supuesto, hay algunas cosas que llenan este tiempo de forma natural, como corrección de errores y verificación, diseño / plan, etc., pero esencialmente estamos scheudling nuestros recursos al 75% de capacidad.

La respuesta obvia parece ser la superposición de sprints para el desarrollo y QA, ya que la realidad es que QA siempre va a la zaga del desarrollo hasta cierto punto. Demostraciones a los propietarios de productos y otros seguirían el QA sprint ya que queremos características que deben probarse antes de mostrarse. Esto parece permitir un uso más eficiente de develoment y QA, ya que no tenemos tanto tiempo perdido. Suponiendo que queremos mantener a los desarrolladores en desarrollo y tester probando, no puedo ver una mejor solución práctica. Tal vez me he perdido algo, y espero que alguien pueda arrojar algo de luz sobre esto para mí - de lo contrario parece que este enfoque rígido para scrum es defectuoso. Gracias.

Con suerte, solucionarás esto abordando menos tareas de desarrollo en cada sprint. Lo que lleva a las preguntas: ¿Quién establece los objetivos del desarrollador? ¿Por qué Dev se está quedando corto de esos objetivos consistentemente?

Si dev no está estableciendo sus propios objetivos, es por eso que siempre llegan tarde. Y esa no es la forma ideal de practicar Scrum. Eso es solo un desarrollo incremental con grandes entregables impulsados por plazos y sin responsabilidad real de los accionistas por parte de los desarrolladores.

Si dev no puede establecer su propios objetivos porque no saben lo suficiente, entonces tienen que estar más involucrados en el frente.

Scrum depende de cuatro principios básicos, esbozados en el Manifiesto Ágil.

1. Las interacciones importan, lo que significa que el desarrollo, el control de calidad, la gestión de proyectos y los usuarios finales necesitan hablar más y hablar entre sí. El software es un proceso de codificación del conocimiento en el lenguaje arcano de las computadoras. Para codificar el conocimiento, los desarrolladores deben tener el conocimiento. [¿Por qué crees que ¿llamarlo "código"?] Scrum no es una metodología de" escritura spec - throw over transom". Es ANTI - "write spec-throw over transom"

2. El software de trabajo importa that eso significa que cada pieza que dev muerde tiene que conducir a una liberación de trabajo. No un conjunto de correcciones de errores para QA para luchar con, pero el software de trabajo.

3. Colaboración con el cliente: eso significa que dev tiene que trabajar con analistas de negocios, usuarios finales, propietarios de negocios, todos los que puedan ayudarlos a comprender lo que están construyendo. Los plazos no importan tanto como la próxima cosa entregada al cliente. Si el cliente necesita X, eso es lo más prioritario para todos. Si el plan del proyecto dice build Y, eso es un montón de tonterías.

4. Responder al cambio means eso significa que los clientes pueden reorganizar las prioridades de los siguientes sprints. No pueden reorganizar el sprint en proceso (eso es una locura), pero todos los siguientes sprints son candidatos para cambiar prioridad.

Si el cliente impulsa, entonces los plazos se vuelven menos artificiales "hitos del proyecto" y más "primero necesitamos X, luego Y, y esto en la sección Z, ya no necesitamos eso. Ahora que tenemos W, Z es redundante."

Las reglas Scrum dicen que todos los elementos de Sprint deben ser "completamente probados, características potencialmente implementables" al final del Sprint para ser considerados completos. Los sprints SIEMPRE terminan a tiempo, y el Equipo no recibe crédito y no se le permite presentar nada en la revisión de Sprints que no esté completo, y eso incluye QA.

Técnicamente, eso es todo lo que necesitas. Un equipo se compromete a una cierta cantidad de trabajo, finalmente lo consigue a QA dos días antes del final del Sprint y el QA no se hace a tiempo. Así que la salida del Sprint es cero, tienen que ir delante del Cliente y admitir que no tienen nada que mostrar durante un mes de trabajo.

La próxima vez, apostará a que elegirán menos trabajo y descubrirán cómo llevarlo a QA para que pueda terminarse a tiempo.

Hablando como QA que ha trabajado en proyectos ágiles durante 2.5 años, este es un tema realmente difícil y todavía no tengo todas las respuestas.

Trabajo como parte de un "triplete" (dos desarrolladores que emparejan programa + un QA) y estoy involucrado en tareas de historias y estimaciones en reuniones de planificación al comienzo de dos iteraciones de semana. Como Adrianh mencionó anteriormente, es esencial que los QAs hagan oír su voz en la planificación inicial del sprint. Esto puede ser difícil, especialmente si trabajar con Desarrolladores con personalidades muy fuertes, sin embargo, QAs debe ser asertivo en el verdadero sentido de la palabra (es decir, no agresivo o contundente, pero respetuosamente buscando entender la Verdad/PO y Desarrolladores/expertos técnicos mientras se hacen entender). Abogo por producir tareas de control de calidad primero durante la planificación para fomentar una mentalidad impulsada por las pruebas: el control de calidad puede tener que presentarse literalmente para que esto se adopte. Es opuesto a la cantidad de personas que piensan en el desarrollo de software funciona pero paga dividendos por varias razones;

1. QA es escuchado y no relegado a ser preguntado "entonces, ¿cómo vas a probar eso?"después de que los desarrolladores hayan dicho su pieza (mentalidad de cascada).

2. Permite a QA proponer ideas para pruebas que, al mismo tiempo, comprueban la probabilidad de los criterios de aceptación mientras la Verdad/PO está presente (dije que es esencial que estén presentes en la reunión de planificación, ¿no?!) para llenar cualquier vacío en comprensión.

3. Proporciona la base para un enfoque basado en pruebas - después de que el enfoque de prueba haya sido enunciado y asignado, los desarrolladores pueden pensar en cómo producirán código para pasar esas pruebas.

4. Si los pasos 1-3 son tu única actividad de TDD para el resto de la iteración, todavía lo estás haciendo un millón de veces mejor que el escenario postulado por Steve en el primer post; "Los desarrolladores se esfuerzan tratando de lograr sus tareas. Generalmente las tareas toman la mayor parte de el sprint para completar. QA molesta a Dev para liberar algo que puedan probar, Dev finalmente lanza algún código con errores a QA un día o dos antes de que termine el sprint y pasa el resto del tiempo arreglando errores que QA está encontrando "

No hace falta decir que esto viene con algunas advertencias para el QA;

1. Deben estar preparados para que sus ideas para las pruebas sean desafiadas por los desarrolladores y Truth / PO y para llegar a un compromiso; la actitud de "QA police" no se lavará en una metodología Ágil equipo.

2. Las tareas de control de calidad deben encontrar un equilibrio difícil para no ser ni demasiado detalladas ni demasiado genéricas (las tareas se pueden escribir en una tarjeta para ir en una "placa de radiador" y se discuten en las reuniones diarias de pie - necesitan ser movidas de "en progreso" a "completadas" DURANTE la iteración).

3. QAs necesita prepararse para las reuniones de planificación/estimación. ¡No esperes ser capaz de aparecer y producir un enfoque de prueba desde la parte superior de tu cabeza para historias de usuarios invisibles! Devs do seem para poder hacer esto porque sus tareas a menudo son mucho más claras-por ejemplo, "cambiar el módulo x a la interfaz con el componente z" o "refactor método y". Como QA, debe estar familiarizado con la funcionalidad que se introduce/cambia ANTES de planificar para conocer el alcance de las pruebas y qué técnicas de diseño de pruebas puede aplicar.

4. Es casi esencial automatizar sus pruebas y tener estas escritas y" fallando " dentro de los primeros dos o tres días de una iteración o al menos para co-incide con cuando los desarrolladores tienen el código listo. A continuación, puede ejecutar las pruebas y ver si pasan como se esperaba (QA TDD adecuado). Así es como se evita una mini cascada al final de las iteraciones. Realmente deberías demostrar la prueba a los desarrolladores antes o cuando empiecen a codificar para que sepan a qué apuntar.

5. Digo que 4 es "casi esencial" porque lo mismo a veces se puede lograr con éxito con listas de verificación manuales (me atrevo a decir scripts!) del comportamiento esperado - la clave es compartir esto con los desarrolladores antes de tiempo; seguir hablando con ellos!

Con respecto al punto 2 anterior sobre el tema de las tareas, he intentado crear tareas tan granulares como 1/2 hora a 2 horas de tamaño, cada una correspondiente a una pieza de trabajo demostrable, por ejemplo, "Agregar comprobaciones de contraseña incorrecta a auto test - 2 horas". Si bien esto me ayuda a organizar mi trabajo, ha sido criticado por otros miembros del equipo por ser demasiado detallado y tiene el efecto de levantarme ya sea moviendo múltiples tareas a través de para completar desde el día anterior o no ser capaz de mover ninguna tarea en absoluto porque no he llegado a ellos todavía. La gente realmente quiere ver una sensación de progreso constante en los stand-ups diarios, por lo que es más útil crear tareas en bloques de 1/2 día o 1 día (pero puede mantener su propia lista de "micro-tareas" para hacer hacia la finalización de las tareas más grandes que utiliza para COMUNICAR el progreso general en el stand-up).

Con respecto a los puntos 4 y 5 anteriores; los ensayos automatizados o manuales las listas de verificación que prepare temprano realmente deben cubrir solo los caminos felices o los criterios clave de aceptación. Una vez que estos pasen, puede haber planeado una tarea adicional para una ronda final de "Pruebas exploratorias" hacia el final de la iteración para verificar los casos extremos. Lo que los desarrolladores hacen durante ese tiempo es problemático porque en lo que a ellos respecta están "código completo" a menos y hasta que encuentre un error. Algunos profesionales ágiles abogan por ir a los casos edge primero, aunque esto también puede ser problemático porque si se queda sin tiempo, es posible que no haya asegurado que se hayan entregado los criterios de aceptación. Esta es una de esas decisiones finamente equilibradas que depende del contexto de la historia del usuario y su experiencia como QA!

Como dije al principio todavía no tengo todas las respuestas, pero espero que lo anterior proporcione algunos consejos nacidos de la experiencia dura!

Parece que su equipo de desarrollo podría no estar haciendo suficientes pruebas por su cuenta, antes del lanzamiento a QA. Si todas sus pruebas unitarias están pasando, el ciclo de control de calidad debería ser relativamente fácil, ¿no? Encontrarán algunos errores de integración, pero no debería haber muchos de esos, ¿verdad?

Creo que hay varios problemas aquí. Primero, creo que tal vez las tareas del desarrollador no son lo suficientemente finas, o tal vez no se estiman bien, o tal vez ambas cosas. Todo el propósito de los sprints en Scrum es poder demostrar el código funcional al final de los sprints. Ambos de los problemas que he mencionado podrían conducir a código con errores.

Si los desarrolladores lanzan código con errores hacia el final del sprint, también miraría:

• Son el producto los propietarios realmente responsabilizan a los miembros dev por realizar sus tareas. Ese es el trabajo del PO y si eso no sucede, entonces los desarrolladores se relajarán.
• Son los desarrolladores que usan cualquier tipo de TDD. Si no, eso podría ayudar mucho. Haz que los desarrolladores se acostumbren a probar su código. Tenemos este problema donde trabajo, y mi equipo está enfocado en hacer el TDD en las áreas importantes para que no tengamos que tener a alguien más que lo haga más tarde
• Son la tarea/usuario historias demasiado genérico? Margen de maniobra en los desgloses de tareas hará que los desarrolladores sean descuidados. Una vez más, esto es algo así como un problema PO.

Una idea que he escuchado en el pasado es usar a una persona de control de calidad como scrummaster. Estarán presentes para los standups diarios y pueden tener una idea de dónde están las cosas con los desarrolladores. Pueden abordar los problemas con el PO (suponiendo que el PO puede hacer adecuadamente su trabajo).

No puedo evitar sentir que necesitas más coordinación entre QA y sus equipos scrum. Parece que las pruebas solo ocurren al final, lo cual es un problema. Conseguir que QA forme parte del equipo ayudará a identificar las cosas que se pueden probar antes y mejor.

También siento que tienes un problema con el propietario del producto. Deben estar allí asegurándose de que todo el mundo está conduciendo en la dirección correcta. deben asegurarse de que existe una buena cooperación, no solo entre QA y devs, sino entre los devs mismos.

" ¿Cómo se supone que funciona scrum cuando Dev liberable ¿las tareas ocupan la mayor parte del sprint?"

Como has descubierto, no funciona muy bien: -) El proceso que estás describiendo no me suena mucho a Scrum, o al menos no a Scrum hecho bien.

No estoy seguro de lo que has descrito si los QA folk son parte del equipo o un grupo separado.

Si son un grupo separado entonces esto es probablemente una gran parte del problema. No se involucrado en el compromiso del equipo con la finalización de las tareas y la negociación del alcance asociado con el propietario del producto. Nunca he visto un grupo ágil tener éxito sin sus habilidades de control de calidad en el equipo. Ya sea por tener desarrolladores con muchas habilidades de prueba/control de calidad, o por tener una persona de control de calidad integrada o tres en el equipo.

Si están en el equipo, entonces necesitan que su voz se escuche más en la planificación inicial del sprint. Por ahora debería estar claro para el propietario del producto y el equipo que usted está sobreasignación.

Intentaría algunas cosas si fuera yo:

• Obtener QA/testing folk en el equipo si no están allí ya
• Tener una buena charla larga con el propietario del producto y el equipo sobre lo que cuenta como "hecho". Parece que algunos de los desarrolladores todavía están en la mentalidad pre-scrum de "entregado a QA "" = = hecho.
• Divide las historias en trozos más pequeños - hace que sea más fácil detectar errores de estimación
• Considere ejecutar sprints más cortos - porque poco y más a menudo es más fácil de rastrear y aprender de.

También puede encontrar estos consejos sobre cómo suavizar un scrum burndown útiles.

Resolvimos este problema de la siguiente manera: - Cada artículo en el backlog del producto debe tener criterios de ajuste o criterios de aceptación, sin ellos, no empezamos un sprint - Un probador es parte de nuestro equipo, para cada artículo de backlog de producto, crea tareas de prueba (1 o más, según los criterios de aceptación) junto con una estimación, y un enlace al artículo a probar - Durante el scrum diario, todas las tareas que se terminan se colocan en una columna 'Para probar' - Nunca hacemos tareas que demoren más de 16 horas; las tareas que se estiman más largas, se dividen

Divida las tareas en tareas más pequeñas.

También, QA puede crear casos de prueba para que Dev los pruebe.

Una idea a considerar es hacer que QA trabaje una iteración detrás del desarrollo principal. Eso funciona bien en nuestro entorno.

Aquí yo diría que, una talla no se ajusta a todos. Cada equipo trata el control de calidad de manera diferente. Depende mucho del proyecto en el que estés trabajando, ya sea pequeño o grande. Necesita una regresión extensa, aceptación del usuario y pruebas exploratorias o tiene muy pocos escenarios para probar. Permítanme reiterar que en Agile, generalista son preferidos en especialista. ¿Qué es aquello? Porque hay tiempo durante el proyecto en el que no tienes nada que Probar, por lo que en ese momento podrías estar haciendo algo más. También es posible que esté haciendo pruebas a pesar de que es un programador de núcleo duro.

¿Cómo lo manejamos? Tenemos sprint regular de 2 semanas. Las pruebas comienzan después de una semana en la tarea completada por los desarrolladores durante la semana. Ahora tester sigue agregando problemas a nuestro rastreador de problemas y los desarrolladores que han terminado con sus tareas de sprint comienzan a elegir esos errores. Al final del sprint, en su mayoría terminamos con nuestra tarea de sprint y todos los errores críticos y principales.

Entonces, ¿qué hace tester two en la primera semana del sprint?

Bueno, siempre hay cosas que probar. Tenemos tareas de prueba en el backlog, que pueden incluir algunas pruebas exploratorias. Muchas personas no valoran las pruebas exploratorias, pero eso es extremadamente importante para construir productos de calidad. Los buenos probadores crean tareas para sí mismos y encuentran las posibilidades donde las cosas salen mal y las prueban.

Espero que eso ayude!