¿Qué se espera que hagan los desarrolladores durante las pruebas en la última mitad de cada Sprint?

Cuando utiliza el marco Scrum, un ciclo de Sprint implica desarrollo y control de calidad. Al final del Sprint, las tareas trabajadas y probadas se muestran y se publican.

Por lo general, para un equipo de 3 a 4 desarrolladores, habría 1 recurso de control de calidad. ¿Qué se espera que hagan los desarrolladores cuando se realiza el control de calidad? Dado que la cantidad de desarrolladores es mucho mayor que la cantidad de evaluadores de control de calidad, las correcciones de errores se realizan muy rápido y los desarrolladores no tienen nada que hacer hacia el final del Sprint.

¿Qué se espera de los desarrolladores durante esta prueba de control de calidad mientras siguen Scrum?

El proceso descrito suena más como un enfoque en cascada. Cada sprint tiene un objetivo de sprint, y hasta que se logre ese objetivo, el trabajo no puede detenerse. Entonces, el proceso ágil comprende un equipo interfuncional, que trabaja de forma iterativa, lo que implica probar y corregir hasta que se alcanza el objetivo y se establece la definición de hecho.

Respuestas (7)

TL; DR

Su pregunta incorpora algunas suposiciones falsas sobre la naturaleza lineal de las pruebas dentro de un proceso ágil. Un equipo ágil maduro con conjuntos de habilidades multifuncionales trata el desarrollo y las pruebas como actividades entrelazadas en lugar de actividades secuenciales.

Debe esforzarse por integrar el desarrollo y las pruebas para que no sean flujos de trabajo fundamentalmente separados. En su defecto, debe aceptar formalmente los riesgos y los déficits de proceso asociados con el flujo de trabajo actualmente implementado.

El control de calidad debe estar integrado, no una pista de proceso separada

Por lo general, para un equipo de 3 a 4 desarrolladores, habría 1 recurso de control de calidad. ¿Qué se espera que hagan los desarrolladores cuando se realiza el control de calidad? Dado que la cantidad de desarrolladores es mucho mayor que el control de calidad, las correcciones de errores se realizan muy rápido y los desarrolladores no tienen nada que hacer hacia el final del sprint.

No estás haciendo Scrum, estás haciendo cascada. Las actividades deben ser multifuncionales y aprovechar un enfoque de equipo multifacético para todas las tareas.

Como un ejemplo, los probadores y los desarrolladores deben trabajar al unísono a lo largo de un Sprint. Los probadores deben participar desde el principio y con frecuencia, ayudando a los desarrolladores a diseñar características comprobables trabajando en criterios de prueba desde el principio antes de que se escriba una sola línea de código y ayudando a garantizar que las pruebas se escriban primero.

La gente de control de calidad debe ejecutar la integración continua todos los días, de modo que haya un ciclo de retroalimentación estrecho (e idealmente inmediato) entre el desarrollo y las pruebas. Al trabajar con los desarrolladores, en lugar de tratarse como una actividad de seguimiento separada, el control de calidad se convierte en una parte intrínseca de los ciclos de diseño y desarrollo en lugar de una externalidad.

Los desarrolladores y el control de calidad deben asociarse para las pruebas

¿Qué se espera que hagan los desarrolladores cuando se realiza el control de calidad? Dado que la cantidad de desarrolladores es mucho mayor que el control de calidad, las correcciones de errores se realizan muy rápido y los desarrolladores no tienen nada que hacer hacia el final del sprint.

Así como se espera que los evaluadores se involucren con los desarrolladores desde el primer día, se espera que los desarrolladores trabajen con el control de calidad durante las tareas de prueba. En lugar de arrojar el código por encima de la pared a los probadores, los desarrolladores y los probadores deben trabajar juntos en el proceso de prueba para que los errores se corrijan a medida que se descubren.

Imagine un escenario de programación en pareja donde un probador y un desarrollador trabajan juntos en un conjunto de pruebas. En lugar de que un desarrollador descargue un muro de código en el probador y luego espere los resultados, los dos podrían trabajar juntos en pruebas y refactorizaciones. Por ejemplo:

  1. Control de calidad: el widget X falló la prueba de aumento.
  2. DEV: Ups. De acuerdo, refactorizaré la clase embiggener mientras pruebas el generador de insultos para el usuario final.
  3. QA: Lo haré. ¡Oh, mira, el generador de insultos pasó!
  4. DEV: ¡Genial! Mientras trabajabas en eso, amplié el embiggener. Vuelve a intentarlo.
  5. QA: Ahora se está agrandando correctamente. ¡Pasemos juntos al siguiente conjunto de especificaciones!

Cuando todo lo demás falla, arroje luz sobre el proceso disfuncional

Si por alguna razón su equipo no puede o no quiere cooperar en actividades relacionadas con las pruebas, entonces el proceso debe hacer que ese costo sea visible para el equipo. Si los desarrolladores y el control de calidad insisten en jugar voleibol con tareas lanzando cosas de un lado a otro sobre una red en lugar de integrarse para realizar el trabajo juntos, entonces simplemente hace que ese proceso (potencialmente disfuncional) sea completamente visible.

¿Los probadores realmente no tienen nada que hacer durante la primera fase de un Sprint? No, pero si ese es su proceso, entonces reconoce que tener probadores inactivos en el equipo durante medio Sprint es uno de los costos de hacer negocios. Del mismo modo, si los desarrolladores realmente no tienen nada que aportar al proceso de prueba en la segunda mitad de un Sprint, entonces usted reconoce explícitamente que a sus desarrolladores se les paga para pasar el rato en Facebook el 50 % del tiempo, y puede aceptarlo como tal. un costo de hacer negocios dentro de su proceso elegido.

Los equipos saludables tratan a todos los miembros como recursos multifuncionales, con valor para agregar durante cada paso del proceso. Incluso si elige no integrar completamente las pruebas como una actividad de primera clase dentro de sus Sprints, los evaluadores y los desarrolladores pueden turnarse para ayudarse mutuamente en las tareas actuales. Por ejemplo, durante el desarrollo, un probador puede trabajar en colaboración para diseñar dispositivos de prueba mientras el desarrollador escribe la característica; luego, durante la prueba, el desarrollador puede ejecutar un análisis de cobertura de código o trabajar para convertir los resultados de la prueba en documentación mientras el probador ejecuta las pruebas.

Si el equipo no puede o no quiere trabajar cooperativamente de esta manera, entonces la organización simplemente puede aceptar el hecho de que algunos roles dentro del equipo estarán inactivos en ciertos puntos del proceso. Si bien no es lo ideal, podría ser políticamente necesario simplemente reconocer que el 50 % de sus roles estarán inactivos en un momento dado y que este es un costo aceptable de hacer negocios dentro de su proceso de desarrollo actual. Si bien personalmente considero que esta es una opción subóptima, aún es mejor que caer presa de la falacia de utilización del 100% que intenta mantener a todos ocupados incluso cuando hacerlo es un desperdicio y no genera valor... y, a veces, incluso puede reducir activamente productividad.

Tiene sentido @codegnome, lo que está sugiriendo es que QA y Dev sigan cada uno sus roles (que pueden tener una fortaleza sobre el otro) pero que colaboren de una manera más efectiva directamente desde el comienzo del sprint hasta ¿el fin?
@Tivep Eso es exactamente correcto. Está bien tener tiempo de holgura en un Sprint; de hecho, la holgura suficiente es esencial para la agilidad, pero demasiada holgura suele ser una señal de que el equipo necesita más colaboración, emparejamiento o enjambre.

Podrían estar haciendo varias cosas. Lo que deberían estar haciendo depende de la madurez de Scrum/XP de su organización, pero aquí hay algunos elementos comunes:

  • El control de calidad funciona: sí, los desarrolladores pueden realizar el control de calidad, ya sea escribiendo nuevas pruebas automatizadas, aumentando la cobertura de prueba existente o reduciendo la complejidad de la prueba, realizando pruebas manuales o pruebas de rendimiento/carga, los desarrolladores pueden y deben realizar el control de calidad. Todo el equipo es dueño de la calidad del producto. Los desarrolladores especialmente disciplinados usarán TDD, por lo que la mayoría de las pruebas se realizan antes de que la historia pase al control de calidad. Los equipos Scrum con 0 recursos de control de calidad son bastante comunes.

  • Deuda tecnológica/Refactorización/Corrección de defectos

  • Picos para historias funcionales más grandes que vienen en el próximo sprint

  • Aprendiendo nuevas habilidades tanto blandas como técnicas. El final de un sprint es un buen momento (como cualquier otro) para que se produzca una mejora continua. Tener un desarrollador que piense que no es su trabajo probar. Emparéjelo con un recurso de control de calidad durante la segunda mitad del sprint.

  • Preparar el trabajo atrasado/trabajar con PO para obtener consideraciones técnicas.

  • Aprender a escribir y preparar historias/tareas que son pequeñas para que no todas las pruebas ocurran en la segunda mitad de la iteración.

  • Mejorar herramientas o procesos en torno a la integración continua.

Para llevar, si sus desarrolladores están inactivos durante la segunda mitad de su iteración mientras el control de calidad realiza las pruebas, tiene algunas oportunidades para aprovechar los beneficios de las verdaderas prácticas de scrum/XP en lugar de vivir el mini-scrum en cascada.

Gracias por eso. Hay algunos puntos interesantes allí @WBW, sin embargo, TDD sería parte de la actividad de desarrollo y no una actividad posterior al desarrollo durante el control de calidad. Además, las pruebas unitarias y las pruebas impulsadas por un control de calidad serían extremadamente diferentes. El hecho de que los QA dedicados no simpaticen con las dificultades de programación les permite asumir el papel de un usuario. Los desarrolladores que son muy buenos tienen un vínculo emocional con el código y rara vez pueden convertirse en pseudousuarios. Estos dos (QA y Dev) no siempre pueden ser la misma persona, de hecho, esa decisión dependería de la naturaleza del proyecto.
Correcto, el TDD tradicional ocurre antes del desarrollo. Hay una forma más suave de TDD que consiste en que el control de calidad y los desarrolladores trabajen juntos antes de codificar para definir los casos de prueba (por lo general, son versiones más detalladas de AC que también entran en casos extremos). Hace maravillas para que los desarrolladores y el control de calidad comiencen a colaborar más. También genera menos defectos a largo plazo, ya que los desarrolladores comienzan a apreciar no solo el código, sino también el negocio detrás de él. Desafiaría sus suposiciones sobre los QA que no simpatizan y los programadores que solo son buenos porque están emocionalmente vinculados al código.
Date permiso para construir un verdadero equipo interfuncional de individuos en forma de T y serás recompensado con un producto de mayor calidad y, a menudo, equipos hiperproductivos que pueden hacer un 300-400 % más de lo que pueden lograr los equipos especialistas tradicionales de mini-scrum en cascada.
Intentaré agregar el elemento TDD suave. Con respecto al equipo multifuncional, como mencioné en otro comentario, eso dependería de en qué le gustaría crecer al control de calidad. Si él / ella está buscando crecer para convertirse en un Analista de negocios, sería más resistente a la programación en profundidad, lo cual es completamente justo. Necesito tener en cuenta los deseos de crecimiento y no puedo obligar a un QA o incluso a un diseñador de UX a convertirse en un desarrollador de pleno derecho. Cada rol tiene algo único que ofrecer. Además, esto también sería una pesadilla de reclutamiento.
Impresionante respuesta @WBW. Apoya completamente esto. Justo ayer estaba dando esta charla de entrenamiento a un desarrollador sénior de un equipo.

"Por lo general, para un equipo de 3 a 4 desarrolladores, habría 1 recurso de control de calidad"

Ahí está tu problema. Hay tres roles en Scrum , Product Owner, Scrum Master y Development Team Member. Su equipo de desarrollo está destinado a ser un equipo multifuncional que trabaja hacia los mismos objetivos. Está bien tener personas con diferentes habilidades (en control de calidad, en desarrollo), pero si tiene miembros del equipo que solo pueden hacer cosas muy específicas (como evaluadores que solo pueden realizar pruebas manuales), ese es un problema que debe solucionar. La automatización de pruebas es un terreno común útil entre desarrolladores y probadores.

El control de calidad como función requiere mucho menos conocimiento técnico, incluso si realizan la automatización. Cuando los QA prueban, son una extensión de los usuarios finales. Están más estrechamente conectados con los usuarios finales. Los desarrolladores saben cosas desde una perspectiva algorítmica. Hacer que Devs y QAs se fusionen en el mismo grupo de personas no ayudará.
Si no es QA, entonces los desarrolladores tienen que asumir una velocidad reducida para interactuar con los clientes/usuarios para crear escenarios de prueba, trajes de prueba, etc. Esto no es implementable porque un equipo grande aún tendrá una velocidad muy baja y el cliente se enfadaría bastante.
@Tivep Estoy preguntando por personas en forma de T. Tener un experto en control de calidad para escenarios de prueba, trajes de prueba está bien. Sus desarrolladores probablemente deberían estar hablando con los clientes de todos modos. No veo cómo tener un equipo capaz trabajando juntos en todo momento disminuiría la velocidad.
Son técnicamente capaces. Pero no podrá interactuar constantemente con el cliente, ya que también necesita estar codificando constantemente. Solo hay un número fijo de horas al día, por lo que para involucrarse más funcionalmente necesitan reducir un poco la velocidad.
en efecto, no puedo usar scrum si no tengo gente tecno funcional. Si hay Alan Turings en el equipo, pueden ser fantásticos en el aspecto técnico, pero Scrum me impedirá usar a esa persona de manera efectiva. :(
@Tivep Preferiría que tu actitud fuera: "Voy a incentivar y entrenar a mi equipo para que sea mejor". Scrum ha hecho evidente una deficiencia en un equipo, pero depende de usted cómo actuar al respecto.
Ver @Nathan ese es el problema. Si bien puedo sentir que estoy mejorando a un desarrollador al hacer que se concentre en UX, dominio, pruebas funcionales, etc., también tendré que considerar si el desarrollador quiere hacer eso. En la mayoría de los casos, no quieren dividir su tiempo en partes iguales entre el aprendizaje y la implementación de tecnologías y la experiencia en el dominio. Necesito honrar eso. Lo mismo se aplica a un QA / BA que está más interesado en el producto y su hoja de ruta. La entrega de una aplicación web consta de roles como UX, UI, App Dev, QA. Desafortunadamente, una persona nunca puede desempeñar todos estos roles indistintamente, especialmente UX, ya que no es tecnología.
@Tivep: Nadie dice que todos deberían ser intercambiables/igualmente buenos en todo. El miembro ideal del equipo es un experto en una o dos áreas, y puede realizar trabajos sencillos/gruesos en las otras áreas a medida que surja la necesidad (como si fueran muy jóvenes). Si no hay trabajo de desarrollo que realizar, un desarrollador debe estar dispuesto/preparado para ayudar al experto en control de calidad a probar el producto, por ejemplo, mediante la ejecución de casos de prueba predefinidos. Puede llevar más tiempo trabajar fuera de su área de especialización, pero eso no debería ser un cuello de botella para hacerlo.
"Son técnicamente capaces. Pero no podrán interactuar constantemente con el cliente, ya que también necesitan estar codificando constantemente". @Tivep tenga cuidado con la falacia de utilización del 100 %. También tenga en cuenta que la mayoría de la programación no consiste en golpear un teclado. Es entender un problema. La velocidad es un vector. No importa qué tan rápido vayas si vas en la dirección equivocada. No olvide que "Semanas de codificación pueden ahorrar una hora de planificación". s/planeando/hablando con tu usuario
@Tivep Cuando todo lo que desea haber hecho debe pasar tanto por la tubería de desarrollo como por la tubería de prueba, la más pequeña determinará cuánto se hará y la más grande desperdiciará capacidad. No hay forma de evitar esto. Dado que agregar más evaluadores probablemente conducirá al problema opuesto, la solución canónica es la funcionalidad cruzada. Puede atenuar este problema acoplando a sus evaluadores más estrechamente con los desarrolladores para que las pruebas puedan comenzar antes.

Parece que en realidad no estás practicando scrum sino 'cascada de tiempo'. Con este enfoque, cada sprint es su propio proyecto de mini cascada, con desarrollo al frente y pruebas al final. Como ha identificado, esto da como resultado una pérdida de tiempo, ya que los probadores tienen poco que hacer al comienzo del sprint y los desarrolladores tienen poco que hacer al final del sprint.

En cambio, el equipo debe trabajar para garantizar que todos estén lo más empleados posible ( tenga en cuenta que no se utiliza al 100%, consulte los comentarios a continuación). Durante los standups diarios y en la planificación del sprint, su equipo debe tratar de averiguar cómo pueden entregar algo a los evaluadores de inmediato, y luego repetirlo durante el sprint para que los evaluadores puedan probar la funcionalidad en partes a medida que se entrega.

Una parte común del standup podría ser que un probador diga que no tiene nada en lo que trabajar más tarde ese día. Tal vez un desarrollador se ofrezca a corregir un par de errores que saben que luego pueden cerrar esa mañana en lugar de comenzar algo más grande. Eso luego llena un vacío para el probador mientras otro desarrollador está terminando un trabajo para que comiencen a probar mañana. Nadie se está rompiendo el estómago, pero tienes un mayor rendimiento de trabajo.

Entiendo. Pero cuando un sprint dura 2 semanas, se vuelve muy difícil tener tareas comprobables que duren 2 días. Para que los controles de calidad realicen pruebas desde los primeros días, las tareas individuales deberían ser tan pequeñas como 2 días. Aunque esto no es práctico :(
Esta respuesta es una variación de la falacia de utilización del 100 % . El objetivo nunca debe ser "garantizar que todos estén lo más empleados posible". Ese es un olor a proyecto particularmente rancio y, por lo general, un signo de una implementación ágil profundamente defectuosa.
@CodeGnome No estoy de acuerdo, un poco. Decidí no entrar en el concepto de <100% de utilización como ideal, ya que habría confundido la respuesta a la pregunta que se hacía. Es por eso que dije "tan completamente empleado como sea posible" en lugar de simplemente "100% empleado". Editaré la respuesta para asegurarme de que nadie me malinterprete. Sin embargo, diría que toda esta respuesta no es una variación de esa falacia. Si sus sprints son mini cascadas, no está utilizando completamente el tiempo de los equipos. Tratar de arreglarlo entregando más trabajo antes no significa que haya cometido esta falacia.
@Tivep La última empresa en la que trabajé hizo sprints de 2 semanas y logró entregar fragmentos comprobables en el primer o segundo día del sprint casi siempre. Su situación puede ser diferente, pero pensaría muy bien en cómo podría hacer que esto sea posible. ¿Realmente no hay una pequeña parte de esa gran mejora que se pueda poner a prueba antes que el resto? Muchas empresas hacen esto todos los días, antes de decidir que es imposible piénsalo un poco.
He tenido una experiencia similar. La mayoría de las tarjetas deben estar en el rango de 1 a 3 días.

Es una configuración un poco inusual la que tiene allí, pero lo que los desarrolladores pueden hacer es comenzar a prepararse para el próximo sprint, solucionar los desafíos técnicos con las nuevas historias de usuario o refactorizar la base de código existente.

Segunda opción, el "Libro Scrum" sugeriría que los desarrolladores también deberían hacer pruebas (modismo de equipo interfuncional), por supuesto, un desarrollador no puede probar lo que implementó.

Tercera opción, es posible que desee pensar en tener dos sprints paralelos pero desplazados. Uno para control de calidad y otro para desarrollo. El control de calidad comenzaría medio ciclo más tarde que el desarrollo. Con esta configuración, los desarrolladores y el control de calidad trabajarán sin estar inactivos durante mucho tiempo. Solo asegúrese de tener capacidad en cada sprint para corregir errores, de lo contrario, la calidad del código disminuirá.

Cuarta opción, puede contratar otro control de calidad para acelerar las pruebas.

¿No debería QA ser parte de los sprints idealmente?
Depende de tu configuración. Uno dice que el debe ser, otros dicen que pueden tener su propio sprint. Es una camarilla, pero Agile se trata de descubrir qué es bueno para ti . Si tiene problemas con QA+Dev en un Sprint, pruebe algo más y discuta los resultados en una retrospectiva.
No. Esto no. La guía de scrum tiene solo 16 páginas y descarta explícitamente tanto dividir equipos según la especialidad ( "Sin excepciones" ) como trabajar en cosas fuera del sprint. Si cree que Scrum está mal y está sugiriendo algo diferente, sea más explícito.
Nadie pagará por desarrolladores inactivos a largo plazo. O convencen a los desarrolladores para que hagan control de calidad, que es un trato difícil, o cambian la forma en que funcionan. Eventualmente, llegarán a un punto en el que la desviación de "según el libro Scrum" es inevitable. Creo que depende de @Tivep cómo continúan.
@Nathan, ¿sería correcto decir que el modelo Scrum no permite evaluadores dedicados? ¿Los desarrolladores deben duplicarse como probadores?
@Tivep Sí. En la práctica, el rol de desarrollador contiene una gran variedad de responsabilidades (para pruebas automatizadas, compilación e implementación, entornos, etc.) que tener forma de T suele ser un problema mayor para otros miembros del equipo. Trabajo en un equipo de scrum y siempre estoy trabajando para lograr los objetivos del sprint, incluso después de verificar la última función: hoy realicé un montón de mejoras de pruebas automatizadas y tfs build magic. Sospecho por lo que ha estado diciendo sobre el control de calidad y el desarrollo, usted trabaja en un lugar que realiza muchas pruebas manuales: lo arreglaría lo antes posible.
@Nathan, sería bueno tener tales desarrolladores, pero por lo general los desarrolladores tienden a centrarse más en los matices de la programación, los marcos, etc. Ejecutan POC constantemente para evaluar la solución técnica. Son extremadamente productivos en este papel. Cuando tienen que tener el ojo del usuario, eso requiere un conjunto diferente de habilidades. Aquí necesitamos un buen ojo en UX, experiencia en el dominio, enfoque funcional, etc. Por lo general, es extremadamente difícil encontrar personas que se destaquen en ambos. Esta falta de disponibilidad de individuos hará que Scrum sea indefenso.
Un equipo multifuncional no significa que cada persona en el equipo tenga que usar todos los sombreros. Simplemente significa que el equipo en su conjunto contiene todas las habilidades y funciones esenciales necesarias para completar cada función.
No escribí que cada persona debe usar todos los sombreros.
@Tivep Scrum no le impide tener recursos dedicados en un equipo. Sin embargo, lo que sí dice es que todo el equipo es responsable de todos los entregables. En otras palabras, "Joe" podría ser su experto en la materia de control de calidad, pero todo el equipo es responsable de garantizar que se realicen pruebas para cada historia. Nadie puede decir "Oh, ese es el trabajo de Joe, porque él es el tipo de control de calidad". Habiendo dicho eso, tener roles dedicados en lugar de personal con capacitación cruzada en el equipo garantiza que tendrá problemas de cola y limitaciones de recursos, por lo que debe...
...acepte la reducción de la productividad o entrene a los miembros de su equipo para que todos puedan contribuir donde sea necesario, incluso si no son la PYME para ese dominio de conocimiento.

El desarrollador puede trabajar para mejorar tanto el proceso como el equipo a través de varias acciones requeridas para el final del sprint, tales como:

  • Análisis de la velocidad real frente a la esperada para mejorar la confianza
  • Categorización de las causas raíz de los defectos para evitar errores repetidos
  • Preparación de una lista de artículos para la retrospectiva para mejorar la colaboración.
  • Codificación de pruebas manuales en scripts automatizados para mejorar la eficiencia

Referencias

desafortunadamente, todo esto puede suceder solo después de que se haya realizado el control de calidad. El control de calidad es integral para tener estas discusiones. No tendría sentido dejarlos fuera.
@Tivep En cuanto al último, se realiza en el código de producción que el control de calidad ya ha verificado, por lo que se pueden omitir.

Soy un desarrollador.

Déjame decirte, lo que estás haciendo mal...

¡Nada! Así es como se diseña Scrum, y ningún sistema es perfecto. No es de extrañar que esté leyendo mi respuesta en este momento porque es un problema universal de scrum.

Esto es lo que no debes hacer:

  1. ¡No contrate más control de calidad!
  2. No pida a los desarrolladores que prueben, a pesar de que el código debe probarse durante el desarrollo y durante las revisiones de relaciones públicas.
  3. No pidas a los desarrolladores que ayuden a otra persona con sus historias, no, no necesitan ayuda a menos que se comunique correctamente.
  4. No, los desarrolladores no deberían realizar "pruebas en pareja" como algunas respuestas sugirieron "trabajar juntos" en las pruebas. Los miembros de control de calidad están probando mi código. Me proporcionarán errores para corregir cuando hayan terminado, y yo lo arreglaré y continuará. NO HAY NADA QUE PUEDA O DEBERÍA HACER mientras están probando mi código, ¡pero ESPÉRALES EN ELLOS! Lo que nos lleva de vuelta a donde empezamos con la pregunta.

Esto es lo que encontré que funciona mejor:

  1. Los desarrolladores deben trabajar con anticipación en sus elementos del próximo sprint.
  2. Es triste que sugiera estar disponible para la colaboración, porque este debería ser el caso durante el sprint desde el primer día.
  3. Trabaje en tareas en las que no puede trabajar durante la rutina diaria para completar las cosas a tiempo.
  4. En una empresa anterior, este tiempo se dedicaba a la formación.
  5. Tenga historias más pequeñas que terminen en diferentes etapas del sprint para que no cree un cuello de botella en el control de calidad si la mayoría del código se prueba cerca del final del sprint.

Realmente, el n.° 1 (TRABAJO ADELANTE) es lo que mejor me sirvió, porque los n.° 2, n.° 3 y n.° 4 deben realizarse durante todo el sprint, ¡no solo cuando el control de calidad prueba el código!

Además, el #5 es evidente.

Entonces, sí... ¡Adelante!

Cuando termino mis historias en el sprint actual, pregunto en qué historia debo comenzar desde el siguiente sprint.

Comienzo una historia del siguiente sprint, y como comencé temprano antes de que comience el sprint, termino mis próximas historias de sprint (aunque no todas a la vez), poco después de que comience el siguiente sprint, a la mitad del próximo sprint o unos pocos días antes de que finalice (no uno o dos días antes de la revisión del sprint).

Esto le da a QA mucho tiempo para probar mi código y tengo tiempo suficiente para responder a sus comentarios. Además, trabajar con anticipación proporciona tareas de prueba para el control de calidad durante todo el sprint, ¡no solo en los últimos días! Esto hace que la carga de trabajo del control de calidad esté equilibrada, y no todo hacia el final del sprint.

Una vez más, la respuesta es ¡TRABAJAR ADELANTE!

¡Esto garantizará la implementación de funciones a lo largo del ciclo de sprint, lo que equilibrará la carga de prueba durante todo el sprint!

Aquí hay un buen artículo que escribí sobre mi experiencia con el tema: ¡Resolví el problema del cuello de botella de las pruebas ágiles!

https://medium.com/@salibsamer/i-resolvió-scrum-sprint-end-testing-bottleneck-problem-bfd6222284a1

Quien haya dado a esto un -1, realmente me gustaría saber por qué crees que mi solución práctica simple no está a la altura de tus estándares ágiles jajaja
gracias por la respuesta. Para que quede claro, no fui yo quien dio el -1. Pero puedo adivinar la razón. La idea es tener la respuesta en esta página y no tener que ir a otro enlace para leerla. Por lo tanto, sería útil resumir el contenido de la respuesta y, para obtener la versión detallada, siempre puede navegar a los artículos.
Tiene sentido. Realmente pensé que estaba proporcionando una respuesta simple y directa. Gracias. Actualicé mi respuesta.
¡Hombre! Obtuve un segundo -1... ¡Actualizando mi respuesta nuevamente! Sí, es personal que alguien realmente escuche lo que he aprendido de la experiencia para evitar el estrés ágil innecesario que resulta de la ignorancia de las reglas de scrum.
¿Qué se espera que hagan los desarrolladores durante las pruebas en la última mitad de cada Sprint?
RespuestasAquíPolítica de privacidad1y, 0v