¿Cómo se manejan en Scrum las tareas que no encajan en un Sprint?
Veo el beneficio de entregar valor incremental en cada Sprint, pero no veo cómo se pueden reducir todas las tareas para que no tomen más de una o dos semanas (y supongo que una sola historia en un Sprint es un antipatrón).
Considere las siguientes tareas:
Cada una de estas tareas puede ocupar la mayor parte del tiempo de uno o más miembros del equipo durante varias semanas. Cualquier definición razonable de hecho, que se pueda lograr en una semana, no proporcionará ningún valor incremental.
En el capítulo 8 de "Scrum: El arte de hacer el doble de trabajo en la mitad del tiempo", Jeff Sutherland escribe:
Puede ser difícil imaginar lanzamientos incrementales [...] que no parecen [...] tener ningún valor hasta que están completos
[...]
Trate de pensar... ¿Qué es lo mínimo absoluto que puedo construir y seguir entregando valor a un cliente?
Sostengo la opinión de que algunas piezas de los sistemas que construyo, si bien brindan un valor tremendo, no se pueden entregar en pequeños incrementos.
¿Cómo encaja este tipo de tareas en Scrum?
(Si bien he usado el término tarea, supongo que 'historia' estaría más en la marca Scrum, aunque en mi opinión, el concepto de historias es una ayuda para comunicar tareas. Incluso si desea argumentar que mis ejemplos son épicos , o algo más, afirmo que no proporcionan un pequeño valor incremental al proyecto)
Editar en respuesta a Thomas Owens
Tampoco estoy convencido de que cualquier parte del trabajo sea grande o no se pueda reducir a algo que se pueda hacer dentro de un Sprint.
Esta es la respuesta a la pregunta que debería haber hecho. De la forma en que entiendo Scrum, cada tarea debe ser lo suficientemente pequeña como para incluirla en un Sprint y siempre brindar un valor incremental.
En mi experiencia, esto no es posible. También parece una afirmación muy fuerte. Trabajo principalmente en sistemas integrados y, según mi experiencia, este tipo de tareas de ejecución prolongada ocurren más en el lado integrado de los sistemas IoT que en la nube o en la interfaz.
Consideraré formular una pregunta más específica para un caso dado, aunque es difícil para mí asegurarme de no revelar información privilegiada. Este parece ser un ejemplo más específico en el que supongo que sería difícil entregar cada pieza de valor en pequeños incrementos.
No estoy convencido de que lo que describe se ajuste a la noción de "grandes tareas no reducibles". Hasta ahora, tampoco estoy convencido de que cualquier parte del trabajo sea grande o no se pueda reducir a algo que se pueda hacer dentro de un Sprint.
Corrección de un error crítico que es difícil de precisar y resolver
Los pasos aquí son bastante sencillos: Obtener pasos de reproducción. Reproducir en un entorno de desarrollo/prueba. Escribir casos de prueba fallidos. Arreglar. Implemente y verifique la solución en un entorno de prueba. Implementar en producción.
Recuerdo un error crítico que fue difícil de resolver debido a la falta de registro. Los pasos de reproducción estaban ahí, pero bajo algunas condiciones, no reproducían el defecto. Por lo tanto, implementamos observabilidad adicional en el entorno de producción a través del registro. Con el monitoreo del rendimiento de la aplicación y el registro yendo a un servicio central, pudimos esperar hasta que volvió a fallar y luego pudimos resolverlo de verdad.
El hecho de que un error sea crítico no significa que pueda resolverlo de inmediato. Dar el siguiente paso posible hacia una resolución probablemente debería ser lo más importante que haga, pero a veces necesita configurar la recopilación de información, esperar la información y luego continuar. Defina el trabajo para mejorar la observabilidad en el sistema, entregue eso y luego proceda con la corrección de errores real cuando pueda.
Seguimiento con un socio externo durante una revisión de seguridad o protección
No veo cómo esto es grande. Está enviando un correo electrónico o haciendo una llamada telefónica. Puede haber alguna iteración basada en los resultados. Tal vez la revisión de seguridad o seguridad encontró problemas. Seguimiento de cada paso. Es importante darse cuenta de que este tipo de trabajo tiene dependencias externas y es posible que no tengan la misma cadencia que el equipo que realiza el trabajo. Pero puedes descomponer el trabajo en partes más pequeñas.
Reemplazo de un componente comercial listo para usar con un componente autoconstruido después de que el componente autoconstruido alcance la paridad
Puede que no sea posible o deseable entregar esto en partes, pero el trabajo puede diseñarse, desarrollarse, integrarse y demostrarse en incrementos. Esta es una buena oportunidad para la priorización del trabajo basada en el riesgo. Encuentre el reemplazo que traiga la mayor cantidad de riesgo o incertidumbre, hágalo primero y genere confianza en que su reemplazo funcionará.
Algunas personas pueden argumentar que esto no es un "Scrum real", pero hay varios aspectos de Scrum que no siempre se alinean con situaciones o contextos del mundo real.
Implementar una función que puede parecer tan simple como presionar un solo botón desde la perspectiva del usuario, aunque una implementación mínima que lleva a cabo la tarea prevista por el usuario es muy compleja.
Tendría que entender más sobre el contexto, pero a menudo he podido dividirlos en piezas delgadas de un extremo a otro. Sin embargo, esta es una buena oportunidad para las banderas de características. Es posible que algunos segmentos delgados no permitan la robustez total o el manejo de errores. Ser capaz de implementar la funcionalidad en partes finas, activar la funcionalidad en entornos de demostración y prueba para obtener comentarios mientras se asegura de que esté integrado con el resto del sistema, y luego habilitar la función cuando sea lo suficientemente sólida es una buena estrategia.
usuario1380
Tomas Owens