Dios los bendiga, nunca tuve mucho trabajo con el mantenimiento. Pero tengo curiosidad, ¿es posible personalizar Scrum para el mantenimiento?
En caso afirmativo, ¿cómo garantizar SLA (si los desarrolladores tienen Sprints fijos), por ejemplo? ¿O qué debe hacer el propietario del producto? ¿Reunir informes de errores o algo más?
Echaría un vistazo a Scrumban , combina lo mejor de ambos mundos , Kanban y Scrum .
Kanban le brinda una forma de planificación más oportuna en la que puede abordar los problemas que surgen lo antes posible. Combinar esto con los roles y reuniones de Scrum conduce a algo que se siente muy bien para los equipos de mantenimiento.
Los propietarios de productos deben desarrollar la visión a largo plazo y la lista de prioridades a corto plazo, como de costumbre. Pero en lugar de establecer reuniones de planificación de fecha fija. Realice sesiones de planificación justo a tiempo con el propietario del producto y haga una lista principal de elementos, repita esto cuando el trabajo pendiente a corto plazo esté casi agotado.
Hay una buena pregunta, ¿cuándo lanzar? Publique cuando el trabajo que necesita publicar esté terminado o publique todo lo que esté terminado en una fecha determinada. Concéntrese en hacer las cosas realmente y asegúrese de tener una rama que siempre esté en un estado liberable.
Lea también el libro electrónico gratuito: https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf
Tal vez también verifique esta pregunta , donde se explican las posibles formas de manejar el trabajo ad hoc durante un sprint.
Si bien es posible usar Scrum, los marcos basados en colas generalmente se adaptan mejor a los procesos de soporte. Las colas deben diseñarse en función de los tiempos de respuesta en lugar de los tiempos de entrega de la solución para obtener los mejores resultados.
Los límites de capacidad y trabajo en curso (WIP) también deben articularse claramente. También debe tener un plan claro sobre cómo manejar situaciones en las que los límites de capacidad o WIP son insuficientes para cumplir con sus Acuerdos de nivel de servicio (SLA) definidos.
Ciertamente puede adoptar prácticas ágiles para el mantenimiento, pero las garantías de SLA per se (por definición) no son iterativas ni ágiles. Los marcos ágiles tratan de mejorar las estimaciones y la mejora continua de los procesos; no están diseñados para garantizar tiempos de entrega fijos.
Dicho esto, si bien Scrum es un marco de gestión de proyectos, un marco ágil como Scrum o Kanban ciertamente se puede usar para soporte con una gran cantidad de advertencias. Scrum, en particular, se centra en gran medida en la estimación de la capacidad en función de las iteraciones en intervalos de tiempo, lo que no es particularmente propicio para tratar los problemas de alta prioridad que surgen a mitad de Sprint. Manejar el soporte mientras se desarrolla un producto es ciertamente parte de Scrum, pero no lo recomendaría para un proceso solo de soporte.
Kanban se adapta mejor a los procesos de soporte, en la medida en que se basa en colas. A medida que se encuentran problemas de mantenimiento, se ponen en cola. Con Kanban, tiene la flexibilidad de diseñar colas que se asignan a sus acuerdos de nivel de servicio, pero nuevamente con algunas advertencias. En particular, Kanban está optimizado para colas con una variabilidad predecible en el tamaño de la historia. Por lo tanto, los tickets de soporte y mantenimiento tendrían que administrarse agresivamente y descomponerse en partes pequeñas para mantener el flujo.
En mi experiencia personal, un SLA debería garantizar el tiempo de respuesta en lugar de prometer un plazo fijo para los resultados. Con Kanban, eso podría lograrse agregando algunas colas como "Triaje" y "Responder al cliente", y expulsando o pausando elementos de trabajo en curso (WIP) de otras colas cuando sus colas de alta velocidad están llenas.
Es importante entender que no hay almuerzo gratis. Independientemente de su metodología, su equipo debe tener la capacidad suficiente para administrar el WIP máximo que se espera que maneje dentro de su SLA. Si excede esos límites WIP, debe tener un proceso definido para administrar sus límites WIP. Esto puede ser a través de comunicaciones transparentes con su cliente interno o externo, o (en algunos entornos) puede manejarse como un riesgo comercial con los costos correspondientes, como los reembolsos al cliente. No importa cómo lo maneje o cuál sea su capacidad planificada, siempre es posible exceder el tamaño de la cola o los límites WIP, por lo que debe decidir con anticipación cómo manejar eso.
Scrum no es adecuado para el mantenimiento de software. Kanban es.
Kanban fue desarrollado en Toyota en Japón para mejorar la línea de ensamblaje de automóviles.
David Anderson escribió literalmente el libro sobre el uso de Kanban en Tecnologías de la Información (TI).
Kanban tiene solo unos pocos principios:
Visualiza el flujo de trabajo: No puedes mejorar lo que no puedes ver. El trabajo del conocimiento necesita una forma de mostrar visualmente el estado de cada tarea. Los tableros Kanban son una forma de mostrar este progreso.
Limite el trabajo en curso (WIP): Minimizar el WIP mejora el rendimiento.
Medir el tiempo de entrega: Los diagramas de flujo acumulativos son muy útiles para este propósito. Y busque formas de realizar mejoras continuas en pequeños incrementos.
Aunque estoy publicando una respuesta un año después de que se formuló la pregunta, parece ser una pregunta común y espero que mi experiencia ayude a algunas personas a tomar la decisión correcta para sus respectivas organizaciones.
Según yo, aquí hay una combinación que funciona mejor para proyectos de mantenimiento:
1). Defina un ciclo de sprint : una semana o un ciclo de 2 semanas según el volumen de trabajo, el tiempo que se tarda en corregir/probar/lanzar, la cantidad de recursos que tiene en su equipo y la perspectiva/expectativas del cliente.
2). Planifique y vuelva a planificar los sprints con la mayor frecuencia posible para estar al tanto de las estimaciones frente al estado actual. También llegará a la velocidad o capacidad para entregar en unas pocas semanas, lo que lo ayudará aún más en la planificación.
3). No recomendaría el uso de puntos de historia para el mantenimiento, ya que la estimación por hora funciona mejor en este caso, ya que sabe exactamente qué se debe arreglar y cuánto esfuerzo se requiere, en lugar de recurrir a técnicas de estimación relativa.
4). Use el Tablero Kanban para realizar un seguimiento del progreso de los tickets/incidentes.
5). Las reuniones de pie diarias ayudarían a resolver cuellos de botella más pequeños o urgentes, mientras que el análisis retrospectivo ayudaría a mejorar gradualmente el proceso.
6). Demasiado enfoque en el proceso también puede conducir a cuellos de botella a veces, ya que tiende a perder la flexibilidad y la agilidad. Recomiendo ser lo suficientemente flexible para adaptarse a los cambios en el sprint, siempre y cuando nadie (aparte del proceso) se lastime.
En pocas palabras, hay muchas herramientas, técnicas y procesos maravillosos disponibles, le gustaría elegir solo los que realmente lo ayudarían a usted y a su negocio.
Mejor, Nitesh
MCW