Fernando Ruíz-Falcó
Hemos construido SSD (Steelmood Software
Development), trasladando al desarrollo de software de gestión a medida alguna
de las ideas básicas que han producido estas mejoras en los procesos de
fabricación e incorporando modelos para tratar sus peculiaridades, como que son
un proceso de producción a medida o que el producto final es digital.
Concretamente, hemos incluido ideas y modelos de:
- Deming sobre control estadístico de procesos.
- Noriaki Kano sobre el tratamiento de la calidad subjetiva (http://en.wikipedia.org/wiki/Noriaki_Kano).
- Lean Advancement Initiative sobre la necesidad de tener procesos ágiles y esbeltos desde el punto de vista del cliente (http://ssrc.mit.edu/programs/lean-advancement-initiative-lai).
- Watts Humphrey sobre PSP/TSP (http://en.wikipedia.org/wiki/Watts_Humphrey).
- Francis J. Goullart y James N. Kelly sobre transformación de organizaciones y Gestión del Cambio http://catalogue.nla.gov.au/Record/608659).
En esencia, el modelo consiste en emprender dos actividades:
- Registrar tiempo, tamaño y defectos de todos los artefactos producidos con granularidad y rigor estadístico
- Poner filtros a todos los pasos del proceso.
Ambas labores
se realizan desde los propios equipos de trabajo, lo que significa una gran
dificultad para su puesta en marcha pues implica un importante cambio de
paradigma para técnicos, supervisores y directivos.
El registro al que nos referimos no se parece en
nada a la típica imputación de tiempos a actividades y centros de coste, que
normalmente se realiza por motivos de control económico. Se trata de registrar con granularidad (por persona y todas las
personas) el tiempo real invertido en
producir cualquier artefacto (análisis funcional, diseño técnico, código, etc.),
el tamaño del artefacto producido y el número de defectos insertados y
removidos.
Para medir el tamaño es necesario definir un parámetro de medida por cada
tipo de artefacto: líneas o páginas de texto, líneas de código, puntos
función, etc. No es importante elegir una métrica u otra, sino que la medida
sea homogénea, para poder comparar y observar la evolución.
Para
los defectos, es necesario definir una taxonomía de errores para cada paso del ciclo de vida:
requerimientos (ortografía, sintaxis, ambiguo, etc.), diseño de alto nivel,
codificación, etc.
Además, para ser realmente útiles, los datos deben correlacionar desde el
punto de vista estadístico. De esta manera, nos aseguramos de la calidad de
los mismos y de que el proceso de registro no introduce ningún sesgo en ellos. Con
ello, la organización empieza a disponer de una base de datos completa que
refleja su comportamiento. A partir de aquí, todo es mucho más predecible y,
tanto personas como equipos, se encuentran inmersos en procesos de mejora
continua.
Por
último, los filtros durante el ciclo de vida evitan
arrastrar el defecto aguas abajo, hasta las pruebas. ¿Por qué entonces ponemos
hoy el énfasis de la búsqueda de errores en las pruebas? Es evidente que,
cuanto más tardemos en detectar y corregir un error, más caro será subsanarlo.
¿A algún fabricante de automóviles se le ocurriría que el filtro de calidad
fundamental lo realizara el cliente cuando va al concesionario a recoger su
coche?
El failure
appraisal ratio es precisamente el tiempo total dedicado a revisiones (la
misma persona que hizo el trabajo, lo revisa para buscar y eliminar errores),
inspecciones (lo realiza una persona distinta a la que hizo el trabajo) y
validaciones (con el cliente especificador del sistema) dividido por el tiempo
total dedicado a pruebas. De acuerdo con la literatura actual, el valor óptimo
para software de gestión está alrededor de 2, es decir, cuando dedicamos el
doble del tiempo en filtros intermedios que en pruebas.
¿Cuánto
es este ratio en su organización? Si es algún valor
entre cero y uno, como es habitual hoy, tiene usted ante sí una enorme
oportunidad de mejora. Desde luego que no será fácil conseguirlo, pero es
imprescindible intentarlo si uno quiere subsistir. Aunque, como le gustaba
decir al propio Deming, “al fin y al
cabo, subsistir no es obligatorio”.
Me surgen dos reflexiones de la lectura. Por un lado, es importante que los gestores y managers resistamos la necesidad casi imperiosa de utilizar esas métricas detalladas para evaluaciones de desempeño, premios o castigos. El hacerlo distorsionará la realidad y motivará a nuestros desarrolladores a maquillar sus números, "hecha la regla, hecha la trampa". Por otro lado, nos vuelve a resaltar la importancia del Business Analysis/ Gestión de requerimientos pues... ¿De qué nos sirve desarrollar un SW en tiempo, sin defectos ni desviaciones, si no cubre las necesidades reales del negocio? ¿Què opinan?
ResponderEliminar