Estamos en la industria de la salud, donde los insectos pueden tener un impacto en la salud de las personas. Como resultado, comenzamos a congelar el código en el entorno de prueba para que el control de calidad probara cada compilación. Además:
Como resultado, el código que no se completó el jueves por la mañana no se publica en esa versión. En otras palabras, todo el código del desarrollador de código de jueves a viernes no se entrega en el sprint actual.
Por eso, propuse a las partes interesadas que consideraran separar el sprint de ingeniería y la entrega del código, estableciendo la entrega esperada del sprint unos días después de que finalice el sprint. Como era de esperar, recibí mucho rechazo de las partes interesadas, diciéndome que nunca habían oído hablar de algo así y que rompí el proceso de Scrum. El problema es que estoy de acuerdo con ellos, pero no se me ocurre otra forma, aparte de comprometerme con menos en cada sprint y hacer que los desarrolladores trabajen en otras cosas (soporte, tickets para el próximo sprint) en los últimos días.
Alguien con una configuración similar, ¿cómo lo resolvió?
Habiendo trabajado en dos entornos regulados (aeroespacial y farmacéutico/sanitario), he visto el problema de necesitar un control de calidad independiente en un producto.
Algunas cosas a considerar:
Incorpore tiempo de control de calidad en su Sprint. Mi organización actual solía ejecutar Sprints de dos semanas. Comenzamos un miércoles por la tarde (algunos equipos comienzan el jueves por la mañana) con Sprint Planning y tenemos desarrollo hasta el viernes de la próxima semana. El congelamiento de código fue el viernes por la tarde. El control de calidad tiene al menos 2,5 días (desde el lunes después de la congelación del código hasta el miércoles por la tarde) para realizar pruebas exclusivamente en una versión candidata. Recientemente modificamos esto para comenzar Sprints con Sprint Planning el miércoles por la tarde o el jueves por la mañana (según el equipo). Para un lanzamiento dado, el congelamiento de código ocurre con la Revisión de Sprint el miércoles. Si hay un lanzamiento programado (no lanzamos después de cada Sprint), esto se planifica como parte de Sprint Planning con el hecho de que el personal de control de calidad ejecutará casos de prueba manuales o los miembros del equipo de automatización y pruebas ad hoc revisarán y documentarán casos de prueba de rendimiento y aceptación automatizados. Cualquier capacidad y apoyo necesarios del equipo se conocen al entrar en la Planificación de Sprint.
Involucrar a QA en cada paso del proceso. Cuando su equipo de administración de productos comience a desarrollar ideas y requisitos (historias, elementos pendientes), involucre a QA para que puedan proporcionar comentarios sobre la capacidad de prueba. Cuando refine estos requisitos, involucre a QA para revisarlos. Si utiliza criterios de aceptación, solicite ayuda de control de calidad para escribirlos y asegurarse de que estén completos. Cuando está haciendo una estimación, incluyendo el esfuerzo de control de calidad en la estimación. Cuando planifique su trabajo, incluya control de calidad para garantizar que confíen en que el trabajo planificado se puede realizar (desarrollar, probar adecuadamente por parte del desarrollo y pasar por un proceso de control de calidad apropiado) dentro del Sprint.
Involucrar a los desarrolladores en la calidad. En un entorno en el que los desarrolladores no pueden probar su trabajo, aún pueden realizar un trabajo valioso después de una congelación de código. Pueden surgir errores (o preguntas): los desarrolladores deben trabajar con control de calidad para solucionar problemas y abordar inquietudes. De lo contrario, pueden mejorar la cobertura de pruebas automatizadas para evitar regresiones en cambios futuros o mejorar la infraestructura y las herramientas del desarrollador. Si no hay mucho en mejorar la calidad, los desarrolladores pueden enfocarse en la reducción de riesgos para el próximo trabajo aprendiendo y mejorando las habilidades o creando prototipos de la próxima funcionalidad.
Tienes que hacer cambios en Scrum para que funcione en un entorno regulado, pero no rompería Scrum. Asegúrese de que su incremento se realice (mediante desarrollo y control de calidad) al final del Sprint. Asegúrese de que su equipo de desarrollo incluya todas las habilidades necesarias para entregar el trabajo y que se consideren las estimaciones y el esfuerzo de todos.
A mi modo de ver, tu problema se reduce a la definición de hecho . ¿Su Departamento de Defensa contiene el requisito de que su código haya pasado el control de calidad?
Si es así, el tiempo que necesite su control de calidad para examinar la última compilación automáticamente se convierte en tiempo de inactividad para sus desarrolladores al final del sprint. Eso no es necesariamente algo malo. Puede hacer refinamiento de trabajos pendientes, investigación, aprendizaje, refactorización, etc. en ese tiempo (si no aparecen errores). Simplemente no puedes sacar nuevas construcciones. Todavía puede implementar el viernes en medio del sprint. Los errores simplemente se arreglarían cuando los desarrolladores regresen el lunes. Sin embargo, si así es como desea hacerlo, debe minimizar el tiempo que el control de calidad necesita para su trabajo. Su ciclo de retroalimentación debe ser lo más corto posible.
Si su Departamento de Defensa no contiene el requisito para las pruebas de control de calidad, entonces su solución propuesta es la correcta: su equipo lanzará nuevas compilaciones cada vez que las tenga. La última compilación que ocurre en los últimos días del sprint cuando terminas. Cualquier problema que encuentre el control de calidad se trata como nuevos elementos pendientes. Se incluirán en los sprints según su prioridad como cualquier otra tarea. Si el control de calidad encuentra un error particularmente crítico, el PO puede renegociar el alcance de su sprint actual para incluir ese problema (generalmente a expensas de otra cosa).
Cuando se trata de administrar la cadencia de lanzamiento, una empresa realmente solo tiene tres opciones, independientemente de la industria o el marco:
Si bien los entornos de alto cumplimiento no son ortogonales a la agilidad, las demandas de los requisitos de cumplimiento a veces pueden obligar a una empresa a enfrentar el hecho de que no puede tener procesos dispares que se mueven a diferentes velocidades al mismo tiempo. Los entornos de alto cumplimiento también tienden a ser víctimas de la falacia de utilización del 100 %, por lo que la idea de tener suficiente holgura en el proceso para permitir que procesos dispares se implementen con la misma cadencia no es realista.
El desacoplamiento, cuando está respaldado por la ingeniería y los controles de proceso correctos, suele ser la salida que preserva la cordura.
Si bien generalmente es mejor integrar el control de calidad directamente en sus Sprints, muchas empresas pasan por alto el valor de desvincular la entrega y la implementación del lanzamiento . Si bien Scrum exige que el resultado de un Sprint sea un incremento potencialmente entregable, en realidad no requiere que el incremento se envíe a los usuarios finales.
En un entorno regulado, los equipos ágiles siguen siendo responsables de entregar incrementos que cumplan con la Definición de Listo. Sin embargo, los procesos posteriores, como las pruebas de terceros o los lanzamientos de producción, no tienen que avanzar al unísono con el equipo de desarrollo.
Los principales problemas que probablemente enfrentará al desvincular las entregas de sus otros procesos son: la necesidad de negociar la corrección de errores con la empresa y la asignación de la responsabilidad de los lanzamientos fuera del equipo Scrum.
En Scrum canónico, los errores encontrados fuera del ciclo de desarrollo deben volver a ingresar al Product Backlog. Los contratos comerciales con el equipo de Scrum no eluden el proceso de acumulación y estimación, aunque las terminaciones anticipadas (por costosas que sean) ciertamente siguen siendo una opción.
Además, un plan de lanzamiento verdaderamente desacoplado significa que el control de calidad o algún otro equipo será el propietario del lanzamiento. Ya sea que la empresa intente (y probablemente falle) que cada incremento entregado sea probado y liberado, o si otorgan a los equipos de lanzamiento la autoridad para agrupar entregas en lotes y establecer su propia cadencia para etiquetar e implementar lanzamientos, es estrictamente una decisión de gestión.
Ciertamente, existen variaciones sobre estos temas, pero el principio fundamental es que cada Sprint debe mantener su integridad frente al trabajo no planificado, y que cualquier trabajo que se traslade fuera del equipo debe cumplir con eso. Mientras eso sea cierto, el desacoplamiento de las liberaciones es el enfoque que defiendo en los entornos gubernamentales y de atención médica.
¿No se puede integrar el control de calidad en su equipo de scrum? Esto no solo significa que integra a una persona que hace control de calidad, sino que también difunde el conocimiento de control de calidad en su equipo.
El objetivo principal de construir un equipo scrum es que el equipo pueda construir (o incluso mejor implementar) un incremento de producto por sí mismo. Además, no hay otros roles en el equipo que el de desarrollador. Por lo tanto, su equipo puede tener un especialista en control de calidad, pero todos los demás desarrolladores deberían poder brindar soporte en control de calidad. Al revés, su especialista en control de calidad debería poder respaldar el desarrollo. Quizás, para lograr esto, hay que gestionar la transferencia de conocimiento.
De esta manera, podría integrar completamente las tareas de control de calidad en su planificación de sprint. Cualquiera en su equipo podría manejar o al menos apoyar cualquier tipo de tarea, desarrollo y control de calidad. En cualquier momento del sprint, puede realizar el control de calidad de las funciones terminadas. En cualquier momento del sprint, puede reaccionar a los comentarios del control de calidad sobre el desarrollo.
Quizás también valga la pena definir lo que quiere decir con control de calidad. ¿Es realmente un control de calidad o más bien una prueba de aceptación del usuario/parte interesada?
Further there are no other roles in the team than developer. So your team can have a QA specialist, but all other developers should be able to support in QA.En entornos regulados, como la atención médica, esto es difícil. La prueba formal de un entregable debe realizarla alguien que no haya participado en el diseño y desarrollo de la función. Tener un control de calidad independiente que evalúe la calidad de los requisitos y/o los criterios de aceptación, escriba casos de prueba contra esos requisitos y criterios de aceptación, implemente pruebas de aceptación automatizadas y ejecute casos de prueba manuales es importante para el cumplimiento.
Balala
Kuf