¿Cómo debemos planificar el trabajo en temas de soporte sin una "batería"?

¡Ningún trabajo invisible, nunca!

El trabajo es trabajo, ya sea en errores o en nuevas características. Por lo tanto, se debe realizar un seguimiento de todo el trabajo en los backlogs de Sprint y Product, independientemente de la fuente. Si está utilizando Kanban, ciertamente es posible tener una cola separada para errores frente a trabajo nuevo, pero a menos que tenga equipos de desarrollo y mantenimiento separados, no importa: todavía tiene cola y límites globales de trabajo en progreso. que hay que honrar.

Los errores deberían reducir la velocidad de las nuevas características

Los errores, la refactorización y otros tipos de reelaboración son una forma de deuda técnica. Dado que cuentan como trabajo, en realidad no deberían tener ningún impacto en la velocidad general si el trabajo se realiza un seguimiento adecuado.

La única vez que las correcciones y los parches de producción parecen reducir la velocidad de un equipo es si no se tiene en cuenta la deuda técnica. Si fueras contador, esto se llamaría "cocinar los libros" y sería ilegal, así que no lo hagas.

Por supuesto, las iteraciones tienen un límite de tiempo, por lo que el tiempo asignado para corregir errores o pagar la deuda técnica significa menos tiempo para nuevas funciones. Esto es correcto y una parte intrínseca del marco: identificar los límites de capacidad del sistema y presentar a la organización la oportunidad de inspeccionar y adaptar sus procesos.

Velocity no es un compromiso de fecha de entrega

Por supuesto, incluso si tu velocidad por Sprint tiene cambios bruscos, tu velocidad promedio debería permanecer bastante estable. Si no es así, entonces se debe revisar el proceso para descubrir el origen del problema: podrían ser estimaciones deficientes, trabajo invisible, deuda técnica, problemas de proceso u otra cosa. ¡Descubrir!

Más importante aún, si la velocidad promedio se ve afectada por interrupciones en el Sprint por trabajo de soporte o deuda técnica, ¡eso es genial! Eso significa que la métrica de velocidad está haciendo su trabajo de hacer que el impacto en el sistema de este retrabajo sea visible para la organización. Eso es todo para lo que realmente sirve la velocidad: medir la variación en el rendimiento del equipo e identificar los problemas del proceso.

No abuses de la velocidad

Si está utilizando la velocidad como un objetivo de administración de cuántas funciones se deben entregar en cada Sprint, en lugar de una herramienta de estimación y retroalimentación, entonces se está utilizando incorrectamente. La velocidad es para la estimación y proporciona una función secundaria como control de detección para identificar los cuellos de botella del proceso.

Opciones para administrar el soporte/mantenimiento

Tienes algunas opciones básicas aquí.

1. Trate los errores y el trabajo de soporte como elementos normales del Product Backlog, y solicite al Product Owner que los priorice junto con las nuevas características. En este caso, las revisiones no pueden interrumpir un Sprint sin una finalización anormal explícita por parte del propietario del producto y un regreso a Sprint Planning.

2. Tenga un equipo para soporte/mantenimiento y un equipo separado para desarrollo. Recomendaría adoptar Kanban o algún otro sistema pull en lugar de Scrum para la organización de soporte, ya que a menudo se adapta mejor a la cola de demanda basada en tickets, pero eso depende de usted.

3. Reduzca los límites de trabajo en curso (para Kanban) o los puntos de la historia por Sprint (para Scrum) para proporcionar suficiente holgura en su proceso, incluida la sobrecarga de cambio de tareas, para manejar las interrupciones impulsadas por la demanda, como las revisiones. Si el 30 % de su capacidad se gasta en deuda técnica sin seguimiento, entonces necesita reducir sus estimaciones de velocidad en un 35-50 % para tenerlo en cuenta. Es mejor realizar un seguimiento del esfuerzo directamente, pero los factores de elusión también pueden funcionar.

Educar a la Organización

En última instancia, el objetivo de la gestión de proyectos no es barrer el trabajo debajo de la alfombra, sino hacer que el costo del trabajo (en tiempo y dinero) sea visible para la organización para que se puedan realizar estimaciones precisas. Proporcionar métricas honestas y estimaciones precisas a la organización permite a los líderes empresariales tomar decisiones comerciales informadas , y cuanta más información tengan para alimentar el proceso de toma de decisiones, mejores pueden ser esas decisiones.

Asegúrese de que la gerencia comprenda que la velocidad es principalmente una herramienta de estimación y, en ocasiones, útil como control de detección. Velocity no es un sustituto de la planificación de la capacidad o la ingeniería de procesos. Parte de su trabajo como gerente de proyecto es explicar el valor y el uso adecuado de sus métricas a la organización.

Sea un intermediario de información honesto. Tomar decisiones comerciales acertadas que aseguren el éxito de un proyecto es el trabajo de la alta gerencia, y su responsabilidad es asegurarse de que estén lo más informados posible.

No haré una diferencia entre historias de usuarios y problemas. El propietario del producto debe saber si las nuevas características o los problemas son más importantes y debe ponerlos en el orden correcto . Con este enfoque no tienes que preocuparte por las baterías o la velocidad, porque son parte del trabajo diario. Según mi experiencia, los equipos necesitan entre 1 y 2 meses para acostumbrarse a esta idea, pero después de eso, el trabajo simplemente fluye (establecer criterios de aceptación para un problema a veces es más fácil que para una historia de usuario).

Se puede argumentar que un problema puede tener un tiempo de investigación más largo, lo que hace que el sprint sea impredecible. Esta es una situación complicada, porque no hay soluciones generales. Mi enfoque es verificar la naturaleza de los próximos problemas durante la planificación del sprint, verificar problemas resueltos similares y usar esta información para averiguar cómo encaja el problema en el sprint . A veces, la predicción está bien, a veces lleva más de un sprint resolver ese problema, pero lo mismo sucede con las historias de los usuarios.

A mis colegas les gusta la idea de tener un sprint y un equipo separados para resolver problemas de un sistema heredado. No me gusta el enfoque de equipo separado, porque con este enfoque el circuito de retroalimentación se corta en pedazos y los equipos de desarrollo no obtendrán suficiente retroalimentación sobre su trabajo, y cometerán los mismos errores una y otra vez . Cuando tiene una rotación de " sprint de funciones - sprint de problemas ", perderá la previsibilidad y la velocidad . Además, según mi experiencia, su equipo se cansará del cambio constante.

Digamos que mezclará las historias de los usuarios y los problemas. Al principio, la velocidad disminuirá, pero debido a la naturaleza de una implementación adecuada de Scrum, eventualmente acelerará, resolverá los problemas, podrá concentrarse en las historias de los usuarios y la velocidad volverá a aumentar.

Una cosa más. En este caso, creo que le ayudaría clasificar los problemas: problemas heredados y problemas de nuevas funciones. Si desea mejorar su calidad, debe centrarse más en los problemas de las nuevas funciones, ya que puede hacer algo al respecto.

Estoy de acuerdo con CodeGnome, pero también me gustaría agregar un poco sobre el código heredado.

¿Entonces heredaste una pila humeante? ¿O tal vez, sus equipos construyeron la pila humeante? Este es un riesgo para su proyecto, pero no es uno que deba ser "gestionado". Debería reducirse . Cada vez que crea una tarea que se ocupa de su código heredado, parte de esa tarea debe ser mejorar el código más allá de simplemente corregir rápidamente el error. Añadir pruebas unitarias. Agregue una capa de abstracción para desacoplar. Refactorizar algo. Todo lo que no sea entrar y salir lo más rápido posible. Si solucionar el problema rápidamente es su plan de juego para lidiar con su código heredado, comprenda que está aumentando la cantidad de código heredado con cada línea agregada, aumentando la deuda técnica de su equipo y, por lo tanto, aumentando el riesgo para su proyecto. Debería reducir activamente este riesgo. Pagará dividendos en menos "

Una sugerencia final: acorte sus ciclos de sprint y asegúrese de que los "problemas en vivo urgentes" sean realmente "urgentes". Si está ejecutando sprints de 1 semana, a menudo los propietarios de productos estarán satisfechos si el problema "urgente" se coloca en el sprint de las siguientes semanas.