Recientemente, se planteó un interesante problema en un foro de discusión sobre gestión de proyectos. La persona preguntó –
«Recientemente me he incorporado a una empresa y en uno de los proyectos en los que estoy comprometido tenemos este equipo Scrum que tiene un backlog mixto (USs y Bugs). El objetivo de este equipo es ir solucionando los bugs urgentes y cuando no lo son (no ocurre tan a menudo :)) deben trabajar en el incremento del producto.
Sin embargo este equipo no funciona correctamente y estoy dispuesto a cambiar esta estructura de equipo (creyendo que esta mezcla de atribuciones no está ayudando al rendimiento del equipo + no se ajusta a las iteraciones de Scrum), haciendo que el equipo trabaje exclusivamente en la corrección de errores, y dejando el incremento del producto a otro equipo (que ya lo hace pero en mayor proporción).
Mi pregunta es: ¿me estoy perdiendo algo que pueda hacer que este equipo funcione mejor y mantener esta estructura de soporte de la aplicación + incremento del producto mientras se usa Scrum?
Si no es así, creo que convertiré este equipo en un equipo exclusivo de soporte de aplicaciones y utilizaré Kanban en su lugar».
Esta es una situación muy común. Los equipos de software suelen gestionar productos, lo que significa que se espera que construyan nuevas características para el producto, así como que corrijan los defectos reportados en el producto. Dependiendo del contexto del equipo y del producto, es posible que tengan que hacer con frecuencia correcciones urgentes para abordar los problemas de los clientes mientras trabajan en las mejoras regulares del producto también. Frecuentemente, especialmente en un entorno Scrum, puede ser difícil hacer coincidir la cadencia de hacer ambas cosas. ¡Esta fue también la situación aquí – ¡y lo que sigue es mi respuesta, que el autor de la pregunta aceptó como la respuesta válida a su situación!
No hay que culpar a la gente – ¡Sino al sistema!
Cuando alguien dice «este equipo no funciona bien», me temo que no ha identificado el origen exacto del problema. ¿Se debe a que los miembros del equipo tienen problemas de multitarea entre las historias de usuario y los defectos? ¿Se debe a que su jefe no está estableciendo la prioridad correcta con la suficiente frecuencia? ¿Hay políticas explícitas definidas sobre cómo deben seleccionar el trabajo que realizan en el día a día? ¿Comprenden el impacto de no atender suficiente demanda de valor (historias de usuario o nuevas características) mientras dedican todo su tiempo a la demanda de fallos (defectos)?
Otro aspecto es: ¿por qué hay tantos defectos en primer lugar? ¿Qué prácticas de ingeniería y automatización hay que poner en marcha para reducir el número total de defectos y mejorar la calidad del código? Si no está haciendo un desarrollo dirigido por pruebas e insiste en la automatización de todos los casos de prueba, incluyendo todos los defectos encontrados, tal vez sea algo que tenga que implementar primero.
Estas son algunas de las cuestiones de alto nivel que deben abordarse para que el equipo «funcione correctamente».
En Digité, a lo largo de los últimos 15 años, hemos probado múltiples enfoques para mantener a los equipos motivados, que se apropien de sus productos y que entreguen de forma consistente y predecible, tanto desde el punto de vista del calendario como de la calidad. Creemos que no sólo no es justo hacer que un equipo trabaje sólo en los defectos mientras otro equipo trabaja en todas las cosas nuevas y geniales, sino que también es una mala práctica de gestión/ingeniería. Un equipo tiene que ser dueño del producto (o de una parte del mismo, dependiendo del tamaño total) y trabajar en él plenamente, tanto en las nuevas características como en los defectos. Esto les da la propiedad total del producto, y nadan o se hunden con él. Les permite conocer mucho mejor el código para entender por qué y dónde se producen los defectos y qué puede causarlos. Y, si se gestiona bien, hace que se sientan mucho más orgullosos de su trabajo y de su mano de obra.
No es Scrum o Kanban. ¡Scrum y Kanban!
En lugar de tratar de decidir «¿Kanban o Scrum?», yo recomendaría, de hecho, aplicar Kanban sobre sus prácticas actuales de Scrum. Esa es la definición fundamental de Kanban. No es un reemplazo de Scrum, más bien es una manera de mejorar casi cualquier proceso que pueda estar utilizando. En el caso de Scrum, mucha gente llama a la mezcla resultante Scrumban. Aplíquelo a sus procesos actuales para identificar los cuellos de botella y los problemas, y resuelva esos problemas.
Sólo para compartir nuestro enfoque, tenemos una situación algo similar a la suya. Tenemos 3 productos diferentes, y tenemos equipos de producto que poseen cada uno y hacen todo el trabajo – nuevas características y correcciones de defectos – para sus productos. No somos un taller de Scrum, pero tenemos un plazo razonablemente bien definido de 4-5 semanas en el que hacemos nuevos lanzamientos. Utilizamos nuestro propio producto t para gestionar nuestra hoja de ruta y el trabajo de desarrollo. La hoja de ruta se gestiona en un tablero Kanban «ascendente», donde hacemos nuestros temas -> épicos -> desglose de historias de usuario y luego transferimos las historias de usuario al tablero de desarrollo «descendente». Todos los defectos reportados por Soporte/Clientes o encontrados internamente durante las revisiones de código, las ejecuciones de automatización o la validación manual se registran directamente en la columna Listo del tablero de Desarrollo. El diagrama que se muestra a continuación le ofrece una imagen completa.
A medida que los miembros del equipo terminan en lo que están trabajando actualmente (Kanban desalienta la multitarea), recogen nuevo trabajo de la cola Listo en función de la prioridad que se discute en el Daily Standup todos los días. Por supuesto, los defectos críticos o de alta prioridad tienen prioridad sobre todo lo demás. Sin embargo, intentamos asegurarnos de que siempre haya una buena combinación de nuevas funciones en las que se trabaje.
Intentamos equilibrar entre un calendario de lanzamiento predecible y el tamaño de lote general para mantener las cosas manejables. Todas las funciones nuevas y las correcciones de errores se implementan en un servidor de ensayo interno de forma continua, y ese es nuestro ‘servidor de producción interno’ donde ejecutamos todas nuestras otras funciones, incluido el soporte y el marketing, etc., que es una excelente manera de identificar cualquier error que pueda deslizamiento (casi cero) y cualquier problema de usabilidad. Y como dije, implementamos una versión de SaaS cada 4-5 semanas y todo el trabajo se completa por completo en ese tiempo.
Le recomendaría que pruebe esto para analizar su situación general y usar Kanban de manera efectiva para descubrir todos los cuellos de botella de su proceso para una mejora general gradual en su operación. Sería genial para la moral y la productividad de su equipo. Podría significar hacer lo siguiente:
- Estudiar el patrón general de demanda en su equipo y decidir si trabaja con una placa de desarrollo, o también usa una placa ascendente para tratar mejor el trabajo entrante con sus partes interesadas.
- Definir un flujo de trabajo que refleje la forma en que trabaja su equipo y mapear todos los pasos en el flujo de valor, para que pueda estudiar completamente cuáles de estos podrían ser cuellos de botella y por qué su equipo dedica tanto tiempo a los defectos. La métrica de eficiencia de flujo de Kanban resalta cuántos tiempos de espera se construyen en todos nuestros flujos de trabajo, ya sea entre transferencias o esperando una entrada externa u otros problemas similares.
- Definición de límites de WIP en su cola Ready para diferentes tipos de trabajo (historias de usuario frente a defectos) para que cierta capacidad siempre se dedique a nuevas funciones.
- Mire sus procesos de desarrollo y opciones de automatización para reducir los niveles generales de defectos.
Estos son solo puntos de partida: ¡usted, por supuesto, tiene una imagen mucho más detallada de su situación! A medida que el equipo comience a analizar su proceso de manera regular, surgirán diferentes soluciones que deberá probar.
Si está ejecutando un equipo de soporte de aplicaciones y se ha enfrentado a situaciones similares, ¡me encantaría saber qué tipo de soluciones ha probado y cuáles funcionaron!
Mahesh Singh
Co-founder, Accredited Kanban Trainer/ Coach
Mi respuesta se publicó originalmente en respuesta a una pregunta aquí:
https://pm.stackexchange.com/questions/23245/scrum-for-kind-of-application-support-team/23260#23260
