Tienes un CMMI implantado para desarrollo, bien, también una ISO 20000, o trabajas siguiendo ITIL, para la parte de explotación, servicios, etc., bien… ¿y nada más? ¿no te falta algo? ¿revisas la calidad de los productos software? Si tu respuesta es “sí, tenemos testing” y nada más… vas a tener un problema. Quizás ya lo tengas, y no seas consciente del mismo. Y el problema viene de que estas dejando pasar la parte más importante, calidad del producto software.
Y ese problema viene de que no estas revisando cómo está desarrollado el software, no sabes calidad del producto software, no has visto sus fuentes, no los has medido (y fíjate que para un vistazo rápido sólo necesitas dos métricas para hacerte una idea de la calidad del producto software), no conoces la calidad del diseño que de verdad te han implementado (y no hablo del que alguien pinto con un UML en un pdf, recuerda aquello de que la verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más), etc.
Y problemas de calidad del producto software… se traducen en software con tamaño excesivo, incomprensible, inmantenible, o si quieres que te lo explique de manera más pragmática… se traduce en que necesitas muchas más personas para mantenerlo, lo que se traduce en mucho más dinero para mantenerlo, en ocasiones tanto… que hay hasta quien se arruina.
6 razones por las que la calidad del producto software debiera preocuparte mucho
1 – Que el software «funcione» (lo que normalmente intentas saber con el testing) no significa que por ello… ¡el producto este bien hecho! Y si está mal hecho no te vas a dar cuenta si no lo miras por dentro (miras sus fuentes, código, diseño, cómo de mal o bien está programado, si está muy acoplado, etc.), es decir, si no miras lo que se llama calidad del producto software.
2 – Tener un CMMI o ITL, es bueno, pero no es suficiente. Si la calidad del proceso (CMMI, ITIL, etc.) busca procesos repetibles y tú vas y te quedas tan tranquilo con eso, y no revisas la calidad del producto software, es decir, la calidad de los productos resultantes de esos procesos, puedes acabar generando productos software malos… ¡de manera repetible!
3 – Porque la mala calidad del producto software (es decir, código espagueti, código repetido, diseño acoplado, etc.) siempre, siempre, alguien la paga (euros), tiene un coste (lo que llamamos deuda técnica). Y solo pueden pagarla uno de dos: el cliente o la empresa que desarrolló el software. Lo que nos lleva a que…
4 – Si el cliente detecta mala calidad del producto software será el proveedor quien acabe pagando el trabajo mal hecho, aunque lo normal es que el cliente no se de cuenta del mal desarrollo software por el que acaba de pagar y acabe pagando él mismo la mala calidad del desarrollador… que normalmente la paga en sobre exceso de horas y horas de mantenimiento.
5 – Tener un “sello” de CMMI no siempre asegura un producto software de calidad. Así es. El «sello» es una evidencia “indirecta” de calidad, la calidad del producto software es evidencia “directa”. El sello, la certificación, evaluación, o como cada uno lo llame (para más detalles tienes la guía de supervivencia CMMI), en modelos como CMMI…
a) Se basa en un muestreo (no se ven todos los proyectos de la empresa), así que puedes tener mala suerte y que te toque un proyecto – equipo de desarrollo que no se evaluó.
b) Las auditorías CMMI no miran la calidad del producto software, sólo miran si se cumplen buenas prácticas del proceso, si se gestionan requisitos, si se verifica, si se planifican los proyectos, etc., pero no si esos requisitos tomados están bien, si ese plan de proyecto está bien… y mucho menos ¡cómo está el código!
c) Si eres un cliente y contratas a alguien porque tiene algún CMMI te mostrará un “sello” concedido en el pasado, y tu producto te lo entregará muchos meses después de la concesión del “sello” y en ese tiempo… pueden pasar muchas cosas.
6 – Las buenas prácticas de ITIL, ISO 20000, son muy buenas para detectar que los usuarios están teniendo problemas con en el software, las incidencias que los usuarios tienen con él, para organizar los pasos a producción de los parches, controlar cuantas veces “se ha caído” el software en producción, su disponibilidad, etc. Pero por muchos y muy buenos indicadores que tenga “tu coche” sobre si se está “calentando el motor”, “el aceite que queda”, etc., los problemas se reparan en “el motor” (el desarrollo software) no poniendo indicadores del nivel de servicio. Y el motor se arregla trabajando la calidad del producto software.
Si te sigue interesando este tema de la calidad del producto software, te recomiendo…
– Te puedes venir a uno de nuestros cursos o charlas sobre calidad del producto software.
– Te puedes leer aquello de que no es lo mismo calidad del PRODUCTO software, que calidad del PROCESO software, que calidad del EQUIPO
– O lo otro de cómo estandarizar la evaluación de la calidad del producto software… la ISO 9126 y la ISO 25000 (1/2)
– La verdadera calidad software la tienes que ver en los fuentes, en el código. No te fíes de nada más
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.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Javier hablas de todo menos del eje princial o motor del tema de la calidad del software la Arquitectura del mismo.