Buenas prácticas cuando se mantienen soluciones de software.

Resumen: Mantener soluciones de software es un trabajo muy crítico que a menudo se menosprecia  y se realiza con una ausencia total de procedimientos, roles, herramientas y gestión.

El mantenimiento de soluciones de software es un aspecto que no he tratado demasiado en este blog, no obstante, estas semanas estoy evaluando un servicio de mantenimiento que ofrece la empresa para la que trabajo y quiero aprovechar el momento y situación para dejar escritos algunos conceptos que creo que son vitales para ofrecer un servicio profesional y de calidad.

No escatimes en herramientas.

Las herramientas son los mecanismos de los que disponemos para realizar un buen trabajo y aportar ese grado de calidad y profesionalidad que nos diferencia.

No escatimes en herramientas, identifica tus necesidades y lucha por que se vean cubiertas. Haz que se vea el valor que tiene el disponer de varios entornos, disponer de los medidores necesarios para garantizar la calidad del software y por lo tanto confianza y tranquilidad en el cliente. Algunas que no nos pueden faltar son:

• Herramienta de gestión de incidencias: No tiene porque ser una aplicación en si misma, es decir, con una hoja Excel que te permita hacer un seguimiento de las incidencias que se crean, las que se cierran o asignarlas a una persona concreta te puede valer. No obstante, si tienes una herramienta mejor que mejor, ya que te ofrecerá además de esto muchas otras funcionalidades como informes y gráficas de la resolución de las mismas. Team Foundation Server puede ser una excelente herramienta.
• Datos de prueba: Tener una buena suite de datos de prueba te va ahorrar mucho tiempo y esfuerzo. Vas a poder identificar casuísticas que no esperas y como consecuencia mejorar el software que mantienes. Emplea todo el tiempo que sea necesario, e intenta reproducir todas las problemáticas que puede encontrar la aplicación mediante estos datos. Igual que creo que no funciona el Lorem Ipsun cuando se está trabajando en prototipos gráficos y diseño de interacción no funcionan los datos autogenerados, así que trata de que tus datos de prueba sean lo más reales posibles.
• Entornos: Si hay que luchar por tener una herramienta de indicencias y unos buenos datos de testing, también hay que luchar (a capa y espada) por que se nos proporcionen los entornos necesarios para desarrollar (control de fuentes, builds automatizadas, herramientas de medición de calidad del software etc.), entornos de Testing (donde seas capaz de validar que todo funciona), entornos de Preproducción y acceso a los entornos de producción.

No contar con alguno de ellos supone la asunción de muchos riesgos. Imagina resolver una incidencia y tener que desplegarla en producción porque no tienes un entorno de test. Pues estas cosas, en la vida real aunque no lo creas pasan.

No es posible mantener una solución sin unos buenos datos de prueba, sin una herramienta que gestione los tickets o incidencias o sin los entornos necesarios para gestionar el ciclo del software de forma eficiente.

Define roles y procedimientos.

Mantener una de solución de forma eficiente implica definir roles y procedimientos. No es posible que cuando se solventa una incidencia sea el propio desarrollador que la ha solucionado la persona que certifique que la solución es correcta.

Has de definir roles, con funciones y tareas concretas y sobre todo que se responsabilicen de la parcela que les toca.

Con los procedimientos sucede lo mismo, define cuales son los procedimientos a seguir para comunicar incidencias, para asignarles una criticidad, para resolverlas en función de esta criticidad, para testearlas, para validarlas y para finalmente desplegarlas en producción.

Si no lo haces encontraras funcionalidades que fallan desplegadas en entornos de producción, encontraras que el equipo no es eficiente, que el software no se prueba. Encontraras un ecosistema que es un autentico desastre con un equipo (tanto del cliente como tuyo) ineficiente y sobre todo que los problemas surgen continuamente.

Valora el servicio como se merece: Dimensiona correctamente el equipo de mantenimiento.

Normalmente, las soluciones que necesitan un mantenimiento son soluciones críticas, soluciones que gestionan aspectos vitales del negocio de una compañía y que por lo tanto es necesario que exista un equipo velando por el correcto funcionamiento de la solución.

El equipo que ha de mantener la solución, ha de estar correctamente dimensionado. Podríamos definir un equipo mínimo con un jefe de proyecto o líder tecnológico que se encargue de las relaciones con el cliente y sobre todo priorizar el desarrollo y solución de incidencias, así como la gestión del equipo en cuanto a vacaciones e imprevistos (por ejemplo una baja o el abandono de la compañía  de un miembro del equipo). Esta persona también deberá ser la encarga de establecer unos lazos o relaciones fuertes entre la empresa cliente y empresa proveedora de servicios.

Del lado del equipo de desarrollo, como mínimo debería haber dos personas siempre. Estas dos personas, deberán tener un conocimiento fuerte de la solución y serán las responsables de ejecutar la resolución de incidencias.

Si además de preventivo, el mantenimiento es evolutivo, deberás de proveer al cliente de equipo de desarrollo diferente. Este equipo puede ser itinerante siempre y cuando se getione debidamente y haya una persona que se responsabilice de los desarrollos relativos a nuevas funcionalidades.

Asegura la calidad del software.

Asegurar la calidad del software es una actitud. Todo buen profesional tiene que ser capaz de garantizar que el software que genera funciona y decir en mi equipo funciona no es garantía.

Utiliza pruebas unitarias y mantén un buen índice de code covegarage a lo largo de todo el servicio. Las pruebas unitarias no solo aseguran que el software funciona como se espera sino que además son reproducibles, automatizables y en muchos casos, lo documentan (y con lo documentan no me refiero a documentación funcional si no a documentación técnica).

Cuando veo el tiempo que ha dedicado el equipo (largas horas e incluso jornadas), debugando una solución para entender el comportamiento de la misma y asegurar que es correcto, me pregunto  cuánto tiempo va a pasar hasta que nos encontremos en la misma situación y tengamos que dedicar otras tantas jornadas de debug.

Dedicar las jornadas al debug de una solución para entender lo que hace es perder el tiempo y deja patente que la calidad del mismo tiende a cero. Esas pruebas, no quedan escritas, no son automatizables y no son reproducibles por lo tanto hay que evitarlas.

El code coverage, es un estupendo medidor de lo testeado que se encuentra la solución.

Gestión. Adelántate a las situaciones no deseadas.

La profesionalidad y calidad del servicio, no solo se mide se mide por la calidad de respuesta y software que se desarrolle. Una correcta gestión de la dedicación y sobre todo de los imprevistos permite generar confianza entre cliente y empresa proveedora.

Mitigar riesgos es tan vital como la propia resolución de las incidencias que surjan y gestionar correctamente las diferentes situaciones adelantándose a los imprevistos, supone minimizarlos, permitiendo que nuestros cliente este tranquilo y tenga plena confianza en nosotros.

Ahorrar costes, eliminando gestión es directamente proporcional a asumir riesgos (que como digo hay que mitigarlos), la existencia de problemas y en definitiva contratar un servicio pobre.

No existe un medidor más atronador que el silencio en relación a problemas e incidencias.

Anuncio publicitario