Después del post anterior ¿Cuál es la primera cuestión? alguien me preguntó si existían algunos procesos o buenas prácticas que permiten alcanzar estos dos objetivos: costes vs. riesgos.

¿Existe un “best of both worlds” con el fin de producir un código de calidad sin sobrepasar presupuestos y planificaciones?

De hecho, no es necesario buscar este “mejor de ambos mundos”. Por ejemplo, si tengo que realizar una auditoría de un sistema bancario, voy primero a verificar que las prioridades en términos de negocios son:

• Asset Management: time to market, no defectos que impiden o molestan el funcionamiento del sistema el primer día, ningun problema de rendimiento o de seguridad evidentemente. El presupuesto no es un problema: se puede doblar al equipo con el fin de respetar la planificación. La mantenibilidad no es una preocupación: esta aplicación puede ser obsoleta dentro de algunos años. Y en lo peor de los casos, podemos echarla y reescribirla, o comprar un software de empresa.
• Bank retail (servicio a particulares): sistemas antiguos, generalmente Mainframe-Cobol, a menudo en outsourcing para cuestión de costes. Los usuarios están acostumbrados a que la entrega se retrase 2 o 3 semanas, y no se sorprenden si unas funcionalidades no sean correctas cuando la aplicación se va en producción.

Es importante cualificar la alineación negocios/TI. Dígale al primer equipo en Asset Management que vas a medir las derivas de mantenibilidad con el fin de controlar el presupuesto, o al segundo equipo (Bank retail) que vas a poner en marcha una política de tolerancia cero con el incumplimiento de las buenas prácticas de rendimiento, y te van a responder “¿Qué importa? Eso no es un problema”.

No creo que existe una receta milagrosa que conduzca al “best of both worlds”. Sin embargo, imaginemos un momento que se te pide encargarte de un proyecto sin conocer su “alineación”, así lo haré yo.

1. “You cannot control what you cannot measure” (Tom deMarco). Empezaré primero por implementar una herramienta de análisis de código que permita dibujar una mapa de la calidad de la aplicación. Medir y controlar.

2. Definiré una estrategia para el mantenimiento de esta aplicación, con los expertos del proyecto. Esta área presenta riesgos: mejor evitar modificarla. Pero si hay que tocar á uno de estos componentes, entonces planificar pruebas exhaustivas. Tendremos que reescribir esta parte porque hay demasiado código duplicado y va a costarnos mucho esfuerzo para mantenerla. Es una prioridad de volver a desarrollarla en forma de componentes reutilizables. ¿Documentar esta parte? O.k., esto puede esperar. ¿Cuánto tiempo para hacer todo esto?
Esto permite conseguir un plan de acción con diferentes prioridades a diferentes costes a corto/medio/largo plazos. Hay que conocer cuál es la alineación de la aplicación para construir este plan.

3. Los defectos de programación son los más fáciles a identificar y resolver. Podemos efectuar regularmente análisis de código y definir un proceso de remediación de estas violaciones en el cual integramos el plan de acción. Estas medidas constituyen el primer paso hacia un proceso de Continuous Inprovement. Sobre esto: Mejora continúa de la calidad.

4. Los defectos de especificaciones (ausentes, erróneas o mal comprendidas) son los más costosos pero también los más difíciles a identificar. Implantar una metodología a base de revisión con usuarios, prototipo, métodos ágiles, etc. La que prefieres pero, en mi opinión, debe:

• Implicar al usuario: el debe validar la interfaz (usability) y las funcionalidades. Posiblemente usuarios finales o sus representantes, poca importancia tiene, pero deben ser integrados en el proyecto. ¿Cuántos ‘defectos funcionales’ son de hecho especificaciones que evolucionaron en fase de proyecto? Como responsable de esta aplicación, quiero que sea bien claro que no asumiré los costes.
• Ser compatible con la tecnología: no veo mucho a Scrum o métodos ágiles en proyectos Mainframe-Cobol.

5. Pruebas. Pesan mucho sobre el presupuesto y la planificación. Primero, definir el nivel de QA requerido. Si la aplicación no es muy voluminosa ni compleja, pruebas unitarias y de integración pueden ser suficiente. De hecho, la dificultad proviene de aplicaciones gordas y complejas: ¿cuánto invertir en la realización de los planes de prueba, en cargas de prueba y en herramientas?
Es cuando la colaboración entre el equipo de proyecto y los equipos de QA es importante. Por ejemplo, un cliente desea una auditoría sobre la escalabilidad de una de sus aplicaciones: los datos y el número de usuarios van a ser multiplicados por 3. Un primer análisis de código identifica los escapes potenciales de rendimiento, que se corrigen. El resultado de los análisis posteriores es compartido con el equipo de QA durante la fase de desarrollo, con el fin de prestarles asistencia en la definición de sus planes de prueba. Está decidido automatizar las pruebas de rendimiento y concentrar las pruebas manuales en las funcionalidades nuevas.

6. El feedback del terreno es siempre apreciable. Recuperamos el numero de defectos encontrados en producción y hacemos una correlación con los defectos encontrados durante los análisis de código. Podemos enseñar los resultados al equipo pero también a los usuarios y los gestores. Normalmente, debes poder demostrar que esto va en en el buen sentido y todo el mundo está contento de saber que esto va en el buen sentido.

7. Poner en marcha las herramientas adecuadas. Una herramienta de análisis de código conectada con la herramienta de desarrollo y de gestión de cambios/versiones, y herramientas de pruebas. Depende de las tecnologías.

8. Hará falta un equipo con un cierto nivel de madurez.

Esto puede tomar años antes de conseguir tal proceso que optimiza los costes y limita los riesgos. Pues es recomendable priorizar estas acciones según los objetivos y la alineación negocios/TI más bien que de apuntar primero al “best of both worlds”.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.