La armonía entre productividad y calidad
Productividad y calidad son dos métricas esenciales en cualquier proyecto de software. Siempre deberíamos ser capaces de responder, de forma concreta y mediante una simple consulta a una base de datos, a las preguntas: ¿cuál ha sido la productividad de este proyecto?, o ¿qué calidad tiene la aplicación desarrollada o las nuevas funcionalidades implementadas?
La respuesta no debería consistir en docenas de indicadores, muchos de ellos diferentes en función del proyecto y difícilmente comparables, sino en un simple dato aplicable a todos los proyectos, de la misma forma que cuando preguntamos por posibles desviaciones de esfuerzo esperamos un porcentaje (esfuerzo planificado vs esfuerzo realmente realizado) con independencia de la tecnología, el tipo de proyecto o el tamaño del mismo.
Si comparamos la calidad y la productividad de diferentes proyectos, debemos ser capaces de conocer por qué la productividad o la calidad de unos es mejor que la de otros. Esta cuestión, aparentemente sencilla (es decir, conocer el por qué), es esencial para llevar a cabo cualquier proceso de mejora, sobre todo si la información de base es fiable y se evita la tentación de aplicar previamente retoques estéticos para salir bien en la foto.
Productividad y calidad no deben caminar en solitario, la una sin la otra. Si se pone un gran énfasis en la productividad sin tener en cuenta la calidad del producto final corremos el riesgo de crear productos mejorables. Si, por el contrario, nos centramos únicamente en la calidad, podemos encontrarnos con productos poco competitivos, aunque evidentemente esto vendrá condicionado en ciertas ocasiones por la criticidad del producto como tal. El objetivo primordial es conseguir la mayor productividad y a su vez la mayor calidad.
Aunque inicialmente las métricas de calidad y productividad de un proyecto pueden dar la sensación de sencillas, no siempre lo son. Para cualquiera de ellas se necesitará el tamaño del producto software realizado, de la aplicación o de las nuevas funcionalidades implementadas. Por otra parte, es importante no asociar tamaño del producto a esfuerzo del proyecto: no siempre a mayor esfuerzo realizado el tamaño del producto realizado será mayor, o viceversa. Imaginemos por un momento un software idéntico desarrollado por dos empresas, aunque la primera empresa utilice un 10% menos de tiempo que la segunda para el desarrollo del proyecto, el tamaño de ambos productos será idéntico.
Entre los métodos más comunes para determinar el tamaño de una aplicación, de nuevas funcionalidades o de modificar funcionalidades ya existentes, encontramos aquellos basados en el código realizado: a más código creado o modificado, mayor tamaño. Entre ellos, el basado en Líneas de Código (LOC; Lines Of Code) y en el que a menudo existen criterios diferentes sobre qué se considera una línea de código, el basado en sentencias del mismo, o incluso el backfiring. Evidentemente estos métodos a menudo acaban beneficiando a aquellos que han complicado lo sencillo o no han estructurado el código correctamente, repitiendo las mismas instrucciones en diferentes ocasiones. Por otra parte, tendremos el tamaño funcional (FSM; Functional Size Measurement), definido como estándar dentro de la ISO/IEC 14143-1:1998 y 14143-1:2007, y basado en las funcionalidades que la aplicación proporciona al usuario. A su vez, los distintos métodos estándares de tamaño funcional están reconocidos como estándares ISO/IEC.
El esfuerzo combinado con el tamaño nos proporcionará la productividad. Será esencial comparar la productividad de diferentes tipos de proyectos: localizados vs deslocalizados, grandes proyectos vs pequeños, proyectos desarrollados en unas regiones del mundo vs los desarrollados en otras. También será necesario comparar la productividad de nuestros proyectos en relación a indicadores estándares, tendencias de productividad tras incorporar cambios en herramientas de desarrollo, metodología, etc. El objetivo desde el punto de vista de métricas será detectar oportunidades de mejora e incluso poder contestar a preguntas como: ¿en qué medida ha aumentado la productividad tras implantar una nueva metodología o aplicar una serie de cambios?, ¿en qué porcentaje son los proyectos Agile más productivos -o menos- que los Waterfall? Muchas de estas cuestiones evidenciarán claramente los ROIs de cambios y mejoras llevados a cabo, aunque esta productividad deberá caminar de la mano de la calidad, tal y como como hemos mencionado anteriormente.
En la mayoría de los casos, el indicador de calidad está asociado al concepto estándar “densidad de defectos”, el cual viene dado por la combinación del número de defectos y el tamaño del producto. Aunque estamos ante una métrica estándar de mercado (Defect Density), ésta, tomada como tal, puede ofrecer en muchas ocasiones resultados poco coherentes. En ese caso, será necesario refinar el concepto “defecto”, ajustando factores tales como número de defectos, ya que en ocasiones alguien podrá ver un defecto (por ejemplo, un listado que contiene 4 columnas alineadas erróneamente) mientras que otro podrá verlo como cuatro defectos (uno por cada columna, sobre todo si éstos han sido descubiertos en distintos momentos), o el esfuerzo necesario para resolver el defecto (no será lo mismo un defecto que se solucione en 15 minutos que otro que requiera invertir varios días). El impacto será otro eje fundamental: en algunos casos estaremos ante un defecto estético (la alineación de una columna, como en el ejemplo anterior), mientras que en otros el defecto puede llegar a tener consecuencias mucho más importantes (por ejemplo, un error de cálculo). Podremos incluir otros factores de ajuste tales como la fase del proyecto en el que se ha originado, el testeo necesario sobre otras partes de la aplicación (Regression test), la indisponibilidad del sistema, etc. Todo ello nos proporcionará los defectos ajustados, con una información más coherente y comparable.
Aunque actualmente estemos sumidos en una franja de baja productividad, mediante bajos costes productivos para poder ser competitivos, la armonía entre productividad (que pronto o tarde se traducirá en coste) y calidad es esencial para lograr la mejor relación calidad/precio, teniendo como objetivo conseguir la mayor productividad y a su vez la mayor calidad.
Pero para ello, como indicábamos anteriormente, deberemos ser capaces de responder con un simple dato a preguntas tan sencillas como: ¿cuál ha sido la productividad de este proyecto?, ¿qué calidad tiene la aplicación desarrollada o las nuevas funcionalidades implementadas?, o ¿en qué porcentaje ha aumentado la productividad y/o la calidad tras implementar determinados cambios?
