Tradicionalmente, la “fase de mantenimiento software” era aquella que ocurría típicamente en un ciclo de vida en cascada, una vez terminado y entregado el software, era la fase que ocurría después del desarrollo y el testing.
En numerosas ocasiones, dicho sea de paso, el mantenimiento era, por decirlo de una manera fina, un eufemismo, porque más que “mantener” se terminaba de desarrollar aquello que no había dado tiempo, ya que, como sabes, en un ciclo de vida tradicional cascada lo más importante era cumplir fechas a toda costa. Así, se hacía una entrega con lo que hubiera, en la fecha de entrega que se acordó muchos meses atrás, y lo que faltase se hacía en la “fase de mantenimiento”.
Cuando estudiábamos informática, y alguien te contaba algo del mantenimiento, siempre te decían que la “fase de mantenimiento” era la más costosa, la más larga, y se solía usar la ya milenaria definición de aquellos olvidados, y obsoletos, estándares de la IEEE, que buscando por la web, para este post, he vuelto a encontrar y de los que te extraigo la siguiente definición:
Software maintenance: Modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment
— IEEE Standard for Software Maintenance. IEEE Std 1219-1998 (destaco, del año 98)
Es decir, según lo anterior, mantenimiento es prácticamente todo lo que ocurre después de una entrega.
En un ciclo de vida cascada, con fases muy largas, que se hacen una única vez (en teoría), requisitos, diseño, programación, testing… y mantenimiento. Ahí, en teoría, estaba muy claro donde estaba el mantenimiento. Donde pintarlo en el Gantt. Donde empezar a facturarlo.
Pero qué pasa en un ciclo de vida ágil, en un ciclo de vida iterativo e incremental, con iteraciones lo más cortas posibles, en el que intento tener un prototipo potencialmente entregable, implementado, lo más pronto posible, siempre antes de terminar el Sprint, en ocasiones teniendo prototipos después de implementar una historia de usuario, en pocos días… ¿dónde está ahí la fase de mantenimiento?
Aquí ocurre un caso muy similar al de Testing, como cuando hablamos de No se puede ser ágil si se prueba en cascada (aunque uses Scrum, iteraciones o Sprints) o ¿Cuándo se hace el Testing en un proyecto ágil? ¿Todo el Testing se hace dentro del Sprint? En un ciclo de vida ágil no hay una “fase” de testing, hay “tareas” de testing, no planificadas de manera predictiva, que pueden ocurrir numerosas veces dentro del Sprint.
Si el mantenimiento es lo que viene después de una entrega, si se centra en adaptar el producto, en evolucionarlo, en corregir cosas y las entregas son constantes, frecuentes, y las tengo desde los primeros días, primeras semanas… el mantenimiento empieza casi que a los pocos días de empezar el “proyecto” (entrecomillo lo de proyecto, ya sabes).
Claro que sería un poco absurdo decir, por ejemplo, dos semanas después de empezar, trabajando de manera ágil, que “estamos en mantenimiento”, suena raro. En nuestras cabezas mantenimiento es algo que empieza “después”.
El caso es que en este contexto, en un ciclo de vida ágil, la palabra mantenimiento tiene poco sentido, o si queremos precisar, lo que desde luego tiene menos sentido es una “fase de mantenimiento”, más exacto sería decir “tareas de mantenimiento” que ocurren de manera frecuente, constante, casi desde el principio.
Pero, claro, dicho esto, quedan algunos cabos sueltos… ¿qué pasa entonces con los equipos de mantenimiento? ¿qué pasa con las incidencias (que sería un tipo de mantenimiento)?
Podría darse el caso de haber desarrollado un producto de manera ágil y que una vez “terminado” (entrecomillo de nuevo, ya sabes), muchos sprints después, otro equipo, o el mismo, se considere que ya sólo se va a dedicar a resolver incidencias, empezaría ahí el mantenimiento, el equipo de mantenimiento.
Lo anterior parece lógico, tan lógico que muchas empresas hacen lo anterior, pero queda raro. Raro, porque según lo anterior parece que las incidencias empiezan después de n sprints, pero… no puede ser, si hemos sacado MVPs de manera frecuente previamente, con funcionalidad parcial, para detectar necesidades del cliente… esos MVP tendrían incidencias, por lo que el “equipo creador” también ha resuelto incidencias, mantenimiento.
Y llegados al caso de que exista un segundo equipo que es “el de mantenimiento”… ¿tiene sentido que sólo se dedique a incidencias? ¿Qué servicio basado en software hoy se estanca funcionalmente y sólo tiene incidencias correctivas?
Más… ¿y tiene sentido que haya un equipo diferente sólo para incidencias? ¿por qué? ¿por qué es más barato? Menos sentido aún sería tener dos equipos, uno de desarrollo y otro de incidencias, soy escéptico sobre la multifuncionalidad de ese esquema de trabajo, entonces…
¿Qué sentido tiene el mantenimiento en un ciclo de vida ágil?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Yo creo que si te contratan para desarrollar un producto con una serie de funcionalidad…Una vez hecho y entregado, con sus testigos de que efectivamente lo que se ha ido entregando va libre de errores… No veo mantenimiento necesario. Si quisieran ampliar funcionalidad, serían tareas nuevas,un nuevo trabajo sobre otro ya existente. Ahí está de la mano del cliente volveremos a encargar o no de nuevo, o entregárselo a otro.Una pregunta, por qué no públicas nombres de empresas que trabajen así? A parte de kybele
Test, no testigos (autocorrector…) A modo de caja negra el cierre de la actividad (retrospectiva final del proyecto, si quieres): estos han sido los requerimientos, este es el producto, este es el test de cobertura funcional y este el de cobertura técnica (importante para lo que se llamaba «mantenimiento evolutivo»). El mantenimiento perfectivo no debería aplicar a un producto software, en mi opinión. O cubre o no cubre requerimientos (importantes las técnicas/normativas que se hayan seguido para garantizar la conformidad del producto y el grado de abstracción con el que se hayan contemplado).
En estos momentos, estamos inmersos en el «intento» de cambio a gestión ágil y dado que llevamos muchos años funcionando en cascada, necesitamos mantener un dpto. de mantenimiento/soporte para todo lo que ya existe; y evidentemente estar en contacto con ellos para que los diferentes sprints tengan en cuenta sus necesidades.
Nos es imposible encapsular el mantenimiento de proyectos antiguos en sprints de «desarrollo» dado que los sprints no avanzarían debido al volumen de incidencias; perdiendo el valor de «palpar» producto cada poco tiempo y a la imposibilidad de resolver incidencias y no entrarlas inmediatamente en producción (esperando a un final de sprint).
Entiendo que lo que propones funcione para «proyectos nuevos», pero lamentablemente hay veces que la historia del producto «pesa».
Finalmente, y a banda de la entrada, felicitaros por el blog.
Saludos
Todo suena bien, y estoy de acuerdo, pero hay cosas que considerar, es muy diferente cuando un producto ya esta en producción (y usado intensivamente) a cuando solo esta siendo observado por el PO y los stakeholders.
Cuando se llega a esa etapa, a pesar del agilismo es inevitable que aparezcan las dos velocidades, por un lado las funcionalidades que van por la cadencia de Sprints y por otro los bugs (que se espera sean menos) que si requieren ser corregidos a la brevedad.
Asi que si, con el agilismo probablemente haya que cambiar el nombre a la etapa, pero eso no quita que ya la forma de enfocar el proyecto cambia inevitablemente. Lo digo pues he trabajado en proyectos cascada y agiles y la situación siempre es diferente una vez que ya esta en uso el software.
Hola Javier,
Desde mi punto de vista, no es bueno tener un equipo para mantenimiento, a quien le gusta guardar las gracias del perro del vecino?.. Jejeje a nadie verdad, a lo que voy es que el equipo dedicado a esto, le resultará con el pasar de los días aburrido, ya que no tienen la posibilidad de realizar nuevas cosas, con nuevas tecnologías, con su propio criterio, lo que yo recomiendo y lo he trabajado es dejar ese mantenimiento distribuidos en los equipos, dichos equipos están organizados por líneas de negocio, de esta forma se hace más fácil la asignación, todo esto lo apoyamos en un triage de Bugs y mejoras, lo que nos ayuda a priorizarlos para la atención, de esta forma logramos avanzar en nuevos proyectos y darle mantenimiento a los antiguos, algo en lo que pensamos siempre fué que si un equipo es altamente comprometido debe importarle la calidad de los productos realizados, por eso delegar esa responsabilidad a otro equipo es también impactar negativamente la calidad.
Ahora como todo en el software depende del contexto.
Yo creo que depende mucho de si es un equipo de desarrollo de un producto interno (como en una startup, pej) o de productos externos (¿proyectos?) de clientes.
En este último caso, el proyecto sí que tiene un final, aunque el desarrollo haya sido ágil, y se puede entrar en una fase de mantenimiento y otra de soporte. De manera que se tiene un contrato tipo bolsa de jornadas de mantenimiento y de soporte.
En primer lugar, quisiera dar las gracias por compartir estos artículos que ayudan a reflexionar y buscar soluciones que a simple vista no parecen tan triviales.
Aquí tenéis mi visión, recién sacada de una sesión matinal de running. Se aceptan críticas y consejos.
Hacer mantenimiento implica que tendremos trabajo que hacer. En general, todo tipo de trabajo se realiza respectando convenciones, reglas de aceptaciones, etcétera…
Cuando hacemos mantenimiento, tenemos la obligación de respetar las normas definidas a nivel de organización y/o de equipo técnico (léase también como “DoD”).
Además, considerando la necesidad de “aligerar la agilidad” (esta citación me encanta), supuestamente habrá distintos tipos de trabajo de mantenimiento: 1) trabajo no prioritario que añadiremos al backlog; 2) trabajo urgente o critico que tendremos que hacer ASAP en el Sprint en curso; 3) trabajo de fácil implementación que podríamos hacer incluso en el Sprint en curso.
Así que una buena practica pasa por estimar el tiempo necesario para que el equipo técnico pueda realizar a lo largo del Sprint tareas de bug-fix, además de trabajar en las nuevas feature, y refinar el Backlog.
¿ Cuanto tiempo dedicar al trabajo de mantenimiento en uno Sprint? Depende del escenario donde estemos sin olvidar la experiencia y la observación de los hechos….