Recientemente he ido en vivo con un gran proyecto. Para cumplir con un plazo ajustado, se acumuló cierta deuda técnica, pero el verdadero alcance solo se hizo evidente después de la puesta en marcha.
Como se pretende que sea una aplicación escalable, estos problemas que podrían estar profundamente arraigados en el código deben resolverse.
¿Deberían agruparse estos problemas en historias de usuarios/tareas tecnológicas secundarias y tenerse en cuenta dentro del proceso de sprint? Creo que no, ya que está arreglando la funcionalidad existente y debe registrarse como tareas / tareas secundarias fuera del proceso de sprint. ¿O debería agregarlos para dar cuenta de lo que está haciendo el equipo?
Muchas gracias.
¿Deberían agruparse estos problemas en historias de usuarios/tareas tecnológicas secundarias y tenerse en cuenta dentro del proceso de sprint?
No. Oh, hay algunos casos en los que se deben agregar algunas tareas pequeñas al Sprint Backlog para cumplir con el Sprint Goal, pero solo las historias aceptadas del Product Backlog por el Equipo porque creen que encajarán en el Sprint actual deben generar tareas en el Sprint Backlog. La deuda técnica, especialmente la deuda técnica de iteraciones pasadas, siempre pertenece al Product Backlog.
Advertencia menor: la deuda técnica en la que se incurre dentro del Sprint actual y que se puede corregir dentro del mismo Sprint sin poner en peligro el Objetivo del Sprint, se puede agregar al Sprint Backlog. Sin embargo, las historias inconclusas (incluidas las historias sobre la deuda técnica) se remontan al Product Backlog al final de cada Sprint.
La deuda tecnológica se incurre con mayor frecuencia cuando se toman atajos o las historias están implícitas en lugar de explícitas. Algunos ejemplos podrían ser:
Sin duda, hay otras formas en que la deuda técnica puede colarse. Sin embargo, el punto es que la deuda técnica no solo afecta al equipo, sino que afecta a todo el proyecto .
El objetivo de Scrum no es mantener una velocidad dada; El objetivo de Scrum es hacer que el proceso de desarrollo sea transparente en toda la organización. Como resultado directo de esto, la deuda técnica debe hacerse visible en el único artefacto que cuenta en toda la organización: la cartera de productos.
Además de la visibilidad, la deuda técnica suele frenar el desarrollo. Esto sucede al hacer que los nuevos cambios sean difíciles o al reducir la velocidad de las nuevas funciones al requerir que los recursos se gasten (visiblemente) en corregir errores o fallas. A menos que estés barriendo los errores debajo de la alfombra (pista: ¡no hagas eso!), entonces tu velocidad probablemente no cambiará mucho a menos que tu Product Owner se niegue a agregar historias de deuda técnica a la Lista de Producto.
Recuerda, el Product Backlog pertenece al Product Owner. Eso no significa que el equipo no pueda recomendar que las historias se agreguen a la cartera de productos y se prioricen; simplemente significa que el Product Owner tiene la última palabra sobre lo que hay en el Product Backlog y cómo se prioriza cada historia.
Asimismo, el Equipo es la única entidad que puede estimar historias y determinar qué encajará dentro de cada Sprint. Eso significa que, a medida que se acumule la deuda técnica sin abordar, un equipo que esté estimando con precisión tendrá en cuenta la deuda en sus estimaciones de la historia. Esto reducirá (correctamente) la velocidad, que es cómo la organización puede ver el impacto de la deuda en el proyecto.
Supongamos que tiene un servidor de integración continua que no tiene suficiente potencia. Esto está ralentizando la prueba de nuevas funciones y correcciones de errores, lo que hace que la velocidad del equipo disminuya a medida que lleva más y más tiempo completar cada nueva historia. Digamos también que el esfuerzo de construir una nueva infraestructura de IC es algo que requeriría un esfuerzo sustancial.
Lo correcto sería crear una historia de usuario sobre la actualización de la infraestructura de CI. Puede haber tareas e historias adicionales asociadas con esto, así que captúralas todas. Estas historias deben pasarse al propietario del producto para su inclusión en la cartera de productos.
Ahora, si el propietario del producto hace de esto una prioridad, será un contratiempo que se solucionará en el próximo Sprint. Sin embargo, el propietario del producto puede decir: "No, esto no es lo suficientemente importante como para priorizar. Aceptaré el costo del proyecto de menor velocidad para priorizar otras características que son más importantes para las partes interesadas".
¡Esta bien! No significa más trabajo para el equipo, solo significa una producción reducida del equipo a cambio de priorizar alguna otra necesidad comercial según lo determine el propietario del producto. Esto es legítimo y transparente , y por lo tanto demuestra el valor del marco.
Cuando estima historias durante la planificación de Sprint, la deuda técnica pendiente será un lastre visible para las estimaciones de la historia. Algo que pudo haber sido una historia de 1 punto sin la deuda puede convertirse en una historia de 5 puntos porque la deuda sigue sin pagarse.
Recuerde, los puntos de la historia son una medida del esfuerzo relativo. A medida que aumenta el esfuerzo por ofrecer funciones, las estimaciones también deberían aumentar. Como resultado, la velocidad real del equipo rara vez cambiará como resultado de la deuda técnica, a menos que esté haciendo un mal uso de la velocidad o permitiendo que otros fuera del equipo proporcionen estimaciones. Lo único que disminuirá es la tasa de nuevas funciones, y priorizar las historias de deuda para mejorar la tasa de entrega es trabajo del propietario del producto.
Su trabajo como Scrum Master es asegurarse de que el propietario del producto y el equipo de desarrollo brinden suficiente información sobre cómo usar el proceso Scrum para comunicar estos problemas de manera efectiva. El Product Backlog es la herramienta adecuada para abordar la deuda técnica, pero la comunicación es el mecanismo esencial mediante el cual la deuda técnica pasa de ser un obstáculo invisible a un elemento procesable.
Cada tarea que el equipo va a realizar debe documentarse y contabilizarse en cada sprint. Ya sea una historia de usuario, un error o una deuda técnica, a cada elemento se le deben asignar los puntos apropiados para que el equipo continúe monitoreando su velocidad adecuada. Otra ventaja de esto es que todos los interesados saben qué se está haciendo y por qué.
Para los problemas que ha encontrado, se deben crear nuevas historias/tareas de deuda técnica y agregarse a la acumulación de sprint (según la velocidad del equipo). Esto puede hacer que algunas historias de usuario (tal vez solicitudes de funciones) se envíen a futuros sprints, lo cual está bien siempre que las partes interesadas estén de acuerdo en que pagar la deuda técnica proporciona más valor que las solicitudes de funciones.
¿Deberían agruparse estos problemas en historias de usuarios/tareas tecnológicas secundarias y tenerse en cuenta dentro del proceso de sprint?
depende (qué tan grandes y críticos son estos errores)
si el elemento es lo suficientemente grande (el error crítico y la corrección requerirán modificar mucho código), entonces parece una historia (o incluso épica)
por otro lado, es posible que tenga un montón de elementos independientes más pequeños, simplemente colóquelos todos en el cuadro de "errores activos" y trabaje en ellos cuando tenga tiempo
jmort253