COMO SE HACE LA TRADUCCION y ANALISIS Making Sense of Measurement for Small Organizations

Traducción y analisis del texto: “Making Sense of Measurement for Small Organizations”

TRADUCCIÓN

DÁNDOLE SENTIDO A LAS MEDICIONES EN PEQUEÑAS ORGANIZACIONES

CASO DE ESTUDIO

La clave para una medición exitosa de los programas es hacer las métricas significativas y adaptarlas a la organización, por pequeña que sea.

Aquí el autor explica de qué forma él ayudó a tres pequeñas compañías a reducir el tiempo dedicado a la manipulación de solicitudes de cambios, corrigiendo errores, generando versiones del sistema y liberando productos.

El desarrollador y el cliente apreciaron las prácticas de mejora.

La medición y las métricas de programas son fundamentales para la mejora del proceso de software, sin ellas, es difícil conocer como los esfuerzo de mejora realmente están afectando nuestro proceso. A pesar que las organizaciones grandes y con muchos recursos reportan sus experiencias de medición en periódicos y revistas, nosotros en general conocemos poco acerca de las mejoras en el proceso de software, y menos acerca de cómo las métricas son usadas en pequeñas organizaciones. Dado que en muchos países las organizaciones pequeñas constituyen la mayoría de las empresas de software, este conocimiento no solo es necesario sino que es vital para el campo.

En este artículo, describo mi experiencia trabajando con líderes de proyecto y equipos para desarrollar y utilizar programas de métricas de pequeña escala en tres pequeñas compañías de software. En cada compañía, implementamos programas de métrica para evaluar cómo las nuevas prácticas y herramientas para la gestión la configuración y el cambio afectan el proceso del software. Estas prácticas fueron acompañadas por nuevos procedimientos de producto y documentación de procesos.

En principio, los desarrolladores de software recibieron nuestras actividades con gran escepticismo, pero eventualmente lo aceptaron porque nosotros manteníamos las mediciones simples, adaptadas a cada organización y aseguramos que producirían valiosa información. Al fin, los programas proveían una base para el cuidado de los clientes y para la planificación y llevar a cabo trabajo futuro.

BASES DEL PROYECTO

Los programas se produjeron como parte de un proceso de mejoras promovido por el programa ESSI(Iniciativa Europea de Sistemas y Software). El objetivo de la ESSI es motivar a las organizaciones europeas de producción de software a probar e implementar mejores prácticas en el software. Bajo esta iniciativa, las organizaciones realizaron sus experimentos en proyecto comerciales de la vida real en un periodo de hasta dieciocho meses. Pudiendo emplear consultores e investigadores externos como apoyo.

Nuestro proyecto involucra tres compañías pequeñas que reciben el apoyo de la ESSI para realizar un proceso experimental enfocado en controlar el versionado de código fuente. La ESSI solicita que las compañías utilicen métricas para verificar y validar el efecto de las acciones de mejora. Yo fui parte de un equipo de investigadores contratados como consultores y mentores del equipo de proyecto con tal fin.

Las tres compañías tenían como mínimo cinco años de antigüedad y cinco empleados o menos. Cada una basaba sus negocios en el desarrollo de un producto principal, que era software del tipo administrativo o técnico. Todos en el equipo (incluido el fundador de la compañía) trabajaban como desarrolladores de sistemas. La experiencia de los miembros del equipo iba desde unos pocos meses hasta 10 años, pero pocos tenían una base formal como profesionales de software o de negocios, la mayoría fueron entrenados en ingeniería u otras ciencias naturales.

En cada compañía, un desarrollador Senior actuaba como líder local del proyecto y miembro principal del proyecto. Sus responsabilidades estaban en el desarrollo e introducir las rutinas de configuración y gestión de cambios, establecer el programa de métricas que iba a monitorear y controlar el impacto de las rutinas.

El líder de proyecto también era responsable de la recolección de los datos de medición. Otros desarrolladores en cada una de las compañías proveían retroalimentación acerca de la fiabilidad de las prácticas y los datos de medición. También participaron en las reuniones periódicas de los proyectos. El proyecto general fue coordinado en las reuniones de los investigadores y los líderes locales de proyecto, en el que discutimos cuestiones formales e informales, e intercambio de ideas.

DESARROLLO DE PROGRAMAS DE MÉTRICAS

Durante los primeros seis meses, definimos el esquema de métricas en paralelo con el desarrollo de las rutinas de configuración y gestión de cambios. El plan del proyecto original incluía una formulación de resultados mensurables, pero las primeras discusiones dejaron en claro que ni los líderes del proyecto, ni los otros desarrolladores estaban convencidos de los beneficios de un programa general de métricas. El estado de ánimo que prevalecía entre los desarrolladores era la resistencia y la duda. Dudaban si el trabajo de software era absolutamente mensurable, cuestionando la utilidad de la colección de datos y temían que la burocracia abrumara a su pequeña empresa. También expresaron su preocupación acerca de la carga de trabajo extra y ansiedad acerca de que las mediciones fueran utilizadas para controlar a los empleados.

Así, en vez de desarrollar un programa integral de métricas donde la pequeña cantidad de datos recogidos sería fructífero, seguimos las recomendaciones de Shari Lawrence Pfleeger y su colegas, y trabajamos con los profesionales para desarrollar programas de métrica simples, cuantitativos y a pequeña escala para cada una de las compañías. En las discusiones informadas por el trabajo real con las nuevas rutinas de configuración y gestión de cambios, los desarrolladores llegaron a un entendimiento compartido de las métricas y decidieron lo que sería interesante medir. La desconfianza desapareció gradualmente y los desarrolladores comenzaron a ver que se tomaron mediciones para controlar los procesos, no a la gente. Entonces ellos fueron claros al decidir qué mediciones eran más críticas para ellos.

Cada empresa tenía diferentes objetivos clave

- La compañía A quería que todos los desarrolladores trabajen en todas las partes de su producto, así reducían la dependencia del jefe de desarrollo.

- La compañía B quería incrementar el número de solicitudes de cambios aceptados, manejados en un cuadro de tiempo dado

- La compañía C quería reducir el tiempo que le tomaba manejar las solicitudes de cambio del cliente y finalizar para liberar versiones

Los datos correspondientes a cada proyecto se recogieron durante dos períodos: Período 1, que duró dos meses en el caso de la empresa C y cuatro meses para las empresas A y B, y el período 2, que duró seis meses para las tres empresas. Las cifras fueron agregadas a partir de datos existentes, que se reunieron fácilmente a partir de las bibliotecas de elementos de configuración y las bases de datos de solicitud de cambio. El uso de los datos existentes fue un compromiso; alivió las dudas que le quedaban a los desarrolladores sobre los beneficios de las mediciones y los liberó de la carga del aumento de trabajo diario que la recopilación de datos les demandaba.

...