miércoles, 21 de noviembre de 2012

¿6 Sigma en desarrollo de software? Eso es imposible

6 sigma

Todos los intentos de aplicar 6 Sigma al desarrollo y mantenimiento de software han sido un fracaso.

¿Cómo es posible que uno de los modelos más extendidos en la industria no se haya podido aplicar a la producción de software? ¿Tan diferente es nuestro negocio?

La razón no ha sido otra que la falta de medición de la producción software.

Uno de los principios de la Mejora Continua es partir de lo que no funciona y asegurarse que la solución propuesta sirve, al comparar los resultados de la situación previa y la creada tras aplicar la solución. Los japoneses llaman a esta práctica “el pequeño científico”, que no es más que darle las armas de los hechos y los datos al operario, en vez de esperar al ingeniero, que siempre está ocupado y que parte del diseño general, por lo que no se suele ocupar de los defectos individuales.

6 Sigma es una de las porciones de la Calidad Total en las que se ha ido trasladando poco a poco este sistema de gestión a occidente (parece que el cambio de mentalidad es tan grande que hemos tenido que comérnoslo en pequeñas dosis administradas durante casi 50 años). 6 Sigma es el nombre occidental del capítulo de Calidad Total llamado Cero Defectos y su objetivo es la eliminación del coste de la mala calidad introducido por los defectos (errores y variación del objetivo) en una actividad. 

Cero defectos es una aspiración y se considera que se ha alcanzado cuando aparece un máximo de 3,4 defectos por cada millón de piezas. Como en desarrollo de software aún vivimos una época artesanal (producción no automatizada, en la que el resultado depende fuertemente de la habilidad de las personas) debemos conformarnos con alcanzar 2 o 3 sigma (308 y 66 defectos por cada 1000 piezas respectivamente). 


Podemos poner en una columna de una hoja de cálculo los input del proceso y en otra los output del mismo. Los sucesivos cambios que vayamos introduciendo en la actividad producirán diferentes outputs y la comparación de los distintos rendimientos me indicará qué cambios tienen éxito y cuáles fracasan.

Voy a tratar de explicar esto contándoles una pequeña historia imaginaria, pero basada en hechos reales: 

Como resultado de la gran cantidad de errores que se introducen en el código pienso comprar una herramienta de inspección de código que va a ayudar a detectar los errores antes del Paso a Producción (PaP). Yo tengo clara la inversión, pero mi jefe me dice que le demuestre que ese cambio va a suponer un ahorro real y no una gollería técnica de la que el Director General está hasta el moño.

Con este dilema, decido hacer un experimento con una versión demo limitada a un par de lenguajes. Defino un piloto de unos meses en un área desarrollo y empiezo a tomar datos.

Tomo los programas que entran en producción durante un par de meses y mido las incidencias achacables a ellos en el periodo de infancia del software; después aplico la herramienta sobre los programas que entran en producción en los siguientes meses, corrijo las incidencias importantes que detecto y tomo nota de las nuevas incidencias achacables al periodo de infancia equivalente.

Cuando analizo los datos me encuentro que las incidencias han aumentado mucho. ¿Qué pasa? Nada, porque creo que la cantidad de software desarrollado es mayor en el segundo periodo, basta con ver que el esfuerzo (las horas * persona: pH) son casi el doble.

De modo que calculo la “densidad” de incidencias por pH y me sale un empeoramiento del valor del segundo periodo respecto del primero. ¡No puede ser!

Me reúno con los desarrolladores y me dicen que algunos de los PaP del segundo periodo estaban en desarrollo en el primero, y además, en el segundo periodo ya estaban en desarrollo algunos de los PaP del tercero (todo eso sin contar con las pH dedicadas a las pruebas de unos y otros PaP ya que tienen un desfase con el desarrollo), y que muchos de los técnicos trabajan a la vez en todo ello y después apuntan la pH que les viene mejor a los Jefes de Proyecto para cuadrar los presupuestos. Es decir, que las pH no me miden el tamaño del software desarrollado. ¡Qué fastidio!

No importa, ¡esto lo arreglo yo!: calcularé la “densidad” de incidencia por miles de Líneas de Código (KLoC), que para eso me proporciona amablemente su valor la herramienta demo.

Vuelvo a hacer los cálculos y, efectivamente, me sale una mejora. ¡Lo que yo decía! De modo que preparo el ROI del primer año para toda la instalación y lo comparo con el precio de la licencia de la herramienta de calidad de código más cara del mercado, y me sale que se amortiza en 2 años. ¡Qué bien! Voy a poder disponer de la herramienta que yo quiera, desde las de software libre a la más cara.

Cuando le presento los resultados a mi jefe, me dice:”muy buen trabajo; pero ¿cómo sabes que las KLoC representan el tamaño del producto? ¿No sabes que los analistas, como sabían que tú les ibas a mirar el código, decidieron revisarlo visualmente ellos antes? Por lo que dieron orden a los programadores de escribir más claro, lo que aumentó el número de KLoC y de comentarios”.

Mi jefe, que es perro viejo, concluye: “al aumentar las líneas, disminuye la densidad de incidencias por línea. Chaval, te la han jugado”. (Ver La loca historia de las líneas de código ). Mi jefe me ha dejado con la cara colorada.


Como no estoy dispuesto a rendirme, busco una nueva medida del producto. Preguntando al “Dr. Google” encuentro una cosa extraña: Puntos de Función  (FP en su sigla inglesa).

Me asesoro y llamo a un consultor certificado en IFPUG que amablemente me ayuda. En un par de sesiones mide los FP de los PaP del primer y segundo periodos.

Por fin calculo la densidad de Incidencias por Punto de Función y resulta que es verdad, los de desarrollo me había tomado el pelo, la mejora es bastante menor pero suficiente para justificar el gasto. Además, me señala que estamos en un estado 2 sigma y, con un par de consejos, me muestra el camino para llegar a 3 o 4 sigma, lo que producirá ahorros que se sumaran al ahorro actual. ¡Ahora sí que puedo ir a ver a mi jefe!

Hasta la aparición de los Puntos de Función era imposible la aplicación de los métodos fundamentales de 6 Sigma en el sector del Desarrollo y Mantenimiento de Software, porque faltaba la mitad de la ecuación: la medición del producto de forma fiable. 

Los métodos de medida del tamaño funcional del software han venido a ayudar a la profesionalización de la actividad y también a soportar la utilización de métodos de reingeniería, reducción de costes y defectos.


No hay comentarios:

Publicar un comentario

Related Posts Plugin for WordPress, Blogger...