Articulo- Midiendo la productividad de un Equipo de Software

Publicado en: Julio/2015

Publicación: Revista FATTO em foco Ano 01 I Nº 01

Tiempo de lectura: 5min

 

 

Autor: Carlos Eduardo Vazquez, CFPS, Socio-director de FATTO

 

“Muchas veces el interés no es evaluar si un equipo es productivo o no, pero: ¿Cuánto más productivo el equipo necesita ser? ¿Cómo es el desempeño en comparación con otros en el mercado?”


Organizaciones que desarrollan o contratan el desarrollo de software, deberían tener como uno de sus objetivos alcanzar niveles máximos de productividad en los equipos movilizados en estas iniciativas.


Para este fin, hay importantes reflexiones que deben ser hechas por los executivos responsables por la gestión del desarrollo en estas organizaciones. Son ellas: conocer y evaluar diferentes alternativas para garantizar que aquellos equipos sean productivos, y tener estrategias de cómo mejorar el desempeño del grupo para alcanzar mayores niveles de eficiencia y cualidad. Todas las reflexiones citadas serán discutidas en este artículo.

 

¿Qué significa un equipo de software ser productivo?


Las personas me preguntan:


“¿Qué significa un equipo de software ser productivo?”. La respuesta: “! Es un equipo que produce resultados!”. Esta respuesta parece demasiado simple como la respuesta clásica “42” de Deep Thought en el libro The Hitchhiker’s Guide to the Galaxy al ser cuestionado sobre la respuesta a la pregunta sobre la vida, el universo, y todo lo más. Por esto, podemos explorar esta pregunta un poco más antes de llegar a una conclusión.


El término Software se refiere a una variedad de diferentes productos que tienen naturalezas diferentes, como programas de computador, scripts de configuración, especificaciones de interface con el usuario, documentos de requerimientos, planos de diseño y arquitectura, casos de prueba, entre otras representaciones del software. Por esto, al realizar el planeamiento y la evaluación de la productividad, es necesario establecer un panorama más amplio y completo a fin de evaluar de manera consistente cuánto productivo es un equipo cuando es comparado a una escala de referencia.


La escala de referencia es una parte necesaria de este panorama, porque muchas veces el interés no es evaluar si un equipo es productivo o no, pero: “¿El cuál productivo es el equipo?, ¿cuánto más productiva a equipe precisa ser?, ¿Cómo es el desempeño de la productividad del equipo en comparación con otras en el mercado?”.


“Hay actividades de mantenimiento en que el resultado de su realización no está asociado a la producción de algo nuevo o al perfeccionamiento de algo existente. En estos casos, el resultado está asociado a la mantenimiento de niveles de servicio ofrecidos por el producto de software en producción”


En caso de que la administración escoja por una escala de referencia basada en una perspectiva de negocio, en lugar de una perspectiva técnica (que requiere muchos más detalles sobre el proyecto y la implementación del software, problemas relativos a estos ítems ya resueltos y refinados en un nivel que permite su comprensión detallada), entonces la elección apropiada es la funcionalidad entregada o impactada por un proyecto. Para actividades de mantenimiento de software, esto es posible en determinados casos y la funcionalidad en el alcance de esa actividad de mantenimiento serían las funcionalidades añadidas, excluidas, modificadas o probadas por el proyecto asociado.

 

ATIVIDADES DE MANTENIMIENTO Y PRODUCTIVIDAD


Existen diferentes tipos de actividades de mantenimiento de software. Entre ellas: la corrección de bugs en la solución de incidentes, la introducción de mejoras que modifican la configuración de las funcionalidades ofrecidas por el software, la actualización de un producto para soportar una nueva tecnología de hardware o software, etc. Es posible medir la productividad asociada a todas ellas. Sin embargo, primero, es preciso determinar lo que se espera recibir y los resultados relativos a cada tipo de mantenimiento.


Hay actividades de mantenimiento en que el resultado de su realización no está asociado a la producción de algo nuevo o la mejora de algo existente. En estos casos, el resultado está asociado al mantenimiento de niveles de servicio ofrecidos por el producto de software en producción. El principal interés de la administración en estos casos es la capacidad de respuesta en un corto intervalo de tiempo. Para esto, debe haber disponibilidad de recursos aunque no haya necesariamente trabajo planeado para movilizar estos recursos. Actividades de mantenimiento como esta son las correcciones de bugs (Cuando ya no son cubiertas por garantías), la prestación de servicios de help-desk de tercer nivel y otras actividades de soporte a la aplicación después de su transición del desarrollo para la producción plena.


Cuando no hay ocurrencias o incidentes que demanden esas actividades, el equipo no consume esfuerzo directo para llegar al resultado deseado. Sin embargo, cuando lo hace, él debe ser lo suficientemente rápido para restaurar la normalidad del funcionamiento de los sistemas en un tiempo que disminuya el impacto negativo en los negocios. Normalmente, estos resultados son definidos anteriormente en la forma de acuerdos de niveles de servicio (o SLA).
Por lo tanto, en este segmento del mantenimiento, gestionar la productividad es observar los acuerdos de nivel de servicio; no se trata de una línea de montaje sujeta a una planificación y control de la producción como ocurre en el desarrollo de sistemas o en los demás tipos de mantenimiento.


PRODUCTIVIDAD COMO UN ATRIBUTO DE PROCEDIMIENTO


El concepto de medir la productividad de un equipo es, de hecho, una simplificación. En realidad, el interés más amplio de la administración es evaluar el desempeño de un proceso productivo (en el caso, un proceso de software). Por lo tanto, no se deben mezclar datos relativos a la medición de actividades de sustentación, como las descritas anteriormente con un proyecto de desenvolvimiento para un nuevo sistema.


Cada proceso productivo de software tiene factores de costo únicos y las producciones derivadas de estos factores de costo siguen una distribución de probabilidad específica. Por ejemplo, los procesos de desarrollo de una nueva aplicación y el mantenimiento en aplicación existente son diferentes.


Para que una única medición sea bien utilizada en ambos procesos, la Asociación de Medición y Análisis de Software da Holanda (NESMA) desarrollo el Punto de Función de Mejora (EFP) y el Punto de Función de prueba (TFP). El EFP no es más que el punto de función predeterminado ajustado por un factor de impacto conforme al grado de cambio en una funcionalidad y el TFP considera en su alcance las funcionalidades incluidas, alteradas y probadas (desconsiderando las excluidas que, al final, no podían ser probadas).


De manera similar, Q/P Management Group ha puesto a disposición la solución adoptada por su empresa en la medición de demandas que no implican crear o modificar funcionalidad de la aplicación. El denomina la unidad resultante de la medición utilizando esta solución de Punto de Impacto y consiste en aplicar el método estándar considerando no la funcionalidad incluida, alterada o eliminada, sino la funcionalidad impactada por aquella actividad.


Un ejemplo muy completo de la segmentación de procesos productivos en que se mantienen una misma unidad de producto es la ruta de Métricas de Software del SISP, que bebe de todas esas fuentes citadas. Este guion es aplicado en la mejora de desempeño del software en determinadas funcionalidades.


Algunos procesamientos tardan hasta 48 horas para completarse. La misión es reestructurar la arquitectura y la implementación de los programas, de modo que después de su conclusión, estos mismos procesos (considerando una perspectiva funcional) no demoren más de 24 horas.


El proceso asociado no es el de un proyecto de mejora y, por lo tanto, el patrón de IFPUG indica que este tipo de actividad no sea medida como tal. La funcionalidad no cambia. Cambia elementos de configuración del software asociados al proyecto (a la arquitectura interna) y a la implementación.


En un escenario como este se podría comparar este tipo de proceso al método estándar de desarrollo y concluir que representa, por ejemplo, el 70% del esfuerzo que demandaría un nuevo desarrollo. De ahí, si el alcance impactado se mide como 100 PF; se considera para evaluación del desempeño en ese proceso una producción equivalente a 70 PF.


“Un ejemplo muy completo de la segmentación de procesos productivos en que se mantiene una misma unidad de producto es la ruta de Métricas de Software del SISP que bebe de todas esas fuentes citadas”


VENTAJAS DE USAR APF EN LA MEDICIÓN DE PRODUCTIVIDAD


Es importante indicar que Análisis de Puntos de Función (APF), técnica que produce unidades representativas de medición del tamaño funcional, es un método con un alto nivel de madurez, cuenta con el mayor número de profesionales cualificados en su aplicación y posee una amplia gama de organizaciones que la utilizan. No hay otro método en el mercado que se compare a ella en estos tres puntos destacados.


Esta también el Grupo Internacional de Usuarios de Punto de Función (IFPUG), organización responsable por su mantenimiento y evolución desde 1986.


El uso de medición funcional utiliza como entrada los requerimientos funcionales - relacionados a las tareas y servicios del usuario - como definido en la segregación de roles y responsabilidades por la estructura organizacional; como los organizados por el flujo operacional que describe los procesos de negocio. Son informaciones disponibles tempranas cuando un desarrollo en contraste con las decisiones de implementación del proyecto tomadas mucho más adelante en comparación.


Si algún otro método de medición que considera aspectos internos o técnicos fura usado, entonces no sería posible para el cliente auditar los resultados presentados por el equipo de desarrollo. Esto por si solo ya es una razón lo suficientemente grande para desalentar su utilización para fines de evaluación de la productividad.


Usar una métrica funcional equilibra las diferentes tendencias en acción cuando se planea y evalúa la productividad. Hay una tendencia, natural, por parte del equipo de desarrollo, para inflar el uso de recursos, mientras que el cliente tiene una tendencia a imponer presión en el sentido opuesto para aumentar la producción. Sin una métrica funcional como el APF, no hay referencia con un significado común para todos los involucrados.

¿UN PROFESIONAL QUE NO SEA DEL ÁREA DE TI PUEDE USAR APF?

Algunos pueden pensar que si la persona no es del área de Tecnología da Información (TI), entonces no podrá usar APF. Este pensamiento está equivocado. He capacitado a miles de personas en APF hace más de 20 años y puedo decir, con seguridad, que cerca de la mitad del tiempo usado fue dedicado a apoyar los profesionales de TI a desaprender el tener solo una visión técnica de software y aprender a tener una visión del software en el ámbito de un procedimiento operacional en el negocio.

 

 

 

 

.

 

.