El arte de gestionar correctamente la productividad en aplicaciones de TI

El objetivo ideal en el desarrollo de aplicaciones de IT es lograr una excelente calidad, que los productos se ajusten o incluso mejoren los objetivos para los que fueron creados, que sean lo más sencillos posibles a nivel interno, lograr una alta productividad en la construcción de aplicaciones, y que todas las personas involucradas en el desarrollo de proyectos disfruten en su trabajo.

Un mismo proyecto de software puede desarrollarse utilizando diferentes enfoques; de hecho, existe un alto componente de diseño artesanal en el desarrollo de soluciones de software. A nivel externo se verá el mismo producto pero el diseño técnico y el código software puede llegar a ser muy diferente.

¿Qué es más productivo, a) un equipo de desarrollo que construye en 100 horas una aplicación de software con 20 programas de 2.000 líneas de código cada uno, o b) un segundo equipo que construye en 80 horas la misma aplicación con 10 programas de 800 líneas de código cada uno?

El primer equipo ha creado una aplicación que contiene 20 programas y 40.000 líneas de código. El segundo equipo ha creado la misma aplicación con 10 programas y un total de 8.000 líneas de código. Un detalle a tener en cuenta es que el producto que solicitó el cliente es el mismo. Si hablamos de “Tamaño Funcional”, ambos proyectos son idénticos porque los dos hacen lo mismo; ambos tienen el mismo tamaño.

Algunas organizaciones miden el tamaño de una aplicación en base al número de “programas”, al número de “LOCs” (Lines Of Code), o al número de “sentencias” de la misma, llegando a provocar (sobre todo en los casos en los que la productividad es un objetivo) posibles situaciones de “engordar artificialmente” desarrollos para parecer ser más productivos, o incluso a crear fascinantes  controversias de por qué crear 8 programas cuando podrían haberse creado 6, o qué se considera una Línea de Código (por ejemplo en lo que respecta al código que se repite en muchos programas vs. crear un programa con dicho código y que los anteriores llamen a éste, o algo tan sencillo como contar o no los comentarios). Si medimos el tamaño según el número de programas creados, siguiendo el ejemplo anterior, el primer equipo ha sido el doble de productivo que el segundo. Si tenemos en cuenta el número de líneas de código, el primer equipo ha sido cinco veces más productivo que el segundo. Esas mediciones proporcionarán resultados erróneos y a su vez poco justos.

Si medimos el tamaño según las funcionalidades del proyecto las conclusiones cambian por completo: a) el tamaño del proyecto ofrecido por ambos equipos es el mismo, b) el primero ha creado cinco veces más de código para hacer lo mismo, c) por norma general, más código implica más errores, y d) más código significa por regla general más esfuerzo de mantenimiento durante el ciclo de vida del producto.

Podemos decir que el equipo más inteligente es aquel que crea la misma aplicación con menos código y de una forma más sencilla, ya que supone un ahorro de tiempo ahora y en el futuro. Cuanto más experiencia se tiene en una materia más capacidad se tendrá para convertir un problema complejo en una solución fácil, mientras que es posible que otros equipos sean especialistas en aplicar soluciones complejas para resolver cosas sencillas. Es el arte de hacer las cosas lo más sencillas posibles.

En Tecnologías de la Información (TI) medir el producto es sinónimo de medir el “Tamaño Funcional” del mismo. Si combinamos el Tamaño Funcional con el Esfuerzo del Proyecto obtendremos la Productividad (o PDR; Productivity Delivery Ratio/Rate). Este PDR es esencial para poder comparar los proyectos internamente, para analizar por qué algunos proyectos son más o menos productivos que otros, las razones de ello, para mejorar futuras estimaciones, para aplicar medidas que puedan ayudar a mejorar los proyectos, para proporcionar feedback a los clientes -especialmente cuando una productividad baja se deba a factores externos-, para comparar el grado de productividad y competitividad de nuestra empresa o departamento de TI con el mercado y con rangos estándares, etc.

Si combinamos el Tamaño Funcional con los Defectos y con una serie de atributos de éstos (tiempo de resolución, criticidad, impacto, etc.) obtendremos el “Defect Density”, o ratio que mide la calidad del producto antes o después de la instalación.

El objetivo ideal en el desarrollo de aplicaciones de IT es lograr una excelente calidad, que los productos se ajusten o incluso mejoren los objetivos para los que fueron creados, que sean lo más sencillos posibles a nivel interno, lograr una alta productividad en la construcción de aplicaciones, y que todas las personas involucradas en el desarrollo de proyectos disfruten en su trabajo. ¿Ficción? No, es posible.

En función de este Tamaño Funcional, se pueden obtener otros indicadores de referencia tales como el tamaño ideal del equipo, la duración óptima del proyecto, el número de casos de prueba planificados o simplemente el número coherente de páginas de análisis funcional/técnico, como se ha mencionado, únicamente como valores de referencia.

El Tamaño Funcional es el denominador común para poder tener métricas estratégicas tales, como se han mencionado, la Productividad o Densidad de Defectos. El método IFPUG CMC es actualmente la técnica de medición de tamaño más utilizada, reconocida por ISO/IEC como método para medir el tamaño de proyectos y aplicaciones de software (otros métodos también utilizados tales como COSMIC o NESMA son en parte variaciones del IFPUG).

El punto interesante de esto es que dos expertos diferentes en este método deberían obtener el mismo Tamaño Funcional de un proyecto determinado, independientemente de “cómo” se haya construido la aplicación. No importa si la aplicación se ha realizado con 20.000 líneas de código o con 200.000, pero sería interesante como mínimo preguntarnos por qué un equipo ha utilizado diez veces más código software que el otro.

Artículo publicado en MetricViews, publicación semestral del IFPUG (International Function Point Users Group). IFPUG es la organización líder mundial que tiene como misión difundir y fomentar la gestión de las actividades de desarrollo y mantenimiento de software mediante el uso del análisis de puntos de función y otras técnicas de medición de software. Encontrará el artículo completo en http://www.ifpug.org/Metric%20Views/MetricViewsJuly2014.pdf