Articles

Hacer “medible” lo que no lo es…

In Project Manager on noviembre 11, 2009 by racar

“Measure what is measurable, and make measurable what is not…”  Galileo Galilei.

La gestión del desarrollo del software requiere identificar métricas que caractericen los procesos  subyacentes involucrados en el desarrollo, de manera que faculten el control de los proyectos y permitan encaminar las acciones de mejora continua.

 

Como desarrolladores requerimos un conjunto de métricas que no agreguen carga innecesaria a las labores individuales del equipo, y por el contrario agreguen valor a la labor diaria de recolectarlas bien sea porque permiten evaluar nuestra madurez como desarrolladores (o del equipo de desarrollo)  o porque permiten hacer seguimiento al desempeño personal.

 

Hace poco mas de dos años, al leer el libro “Introducción al PSP”, de Watts Humphrey, empecé a trabajar en la definición de una serie de formatos de registro de actividades y planeación que, con el tiempo, han aportando datos para definir indicadores que a los gerentes con los que he trabajado les han parecido útiles. A continuación describo dicho indicadores:

 

Esfuerzo: Cantidad de tiempo dedicado a completar una tarea, un producto o servicio. Esta compuesto por el esfuerzo estimado antes de iniciar la tarea, que es calculado por el desarrollador en base a sus datos históricos o estadísticas;  y el esfuerzo Ejecutado, que se define como el tiempo real empleado para completar la tarea, y se obtiene del registro diario de tiempo llevado a cabo por el desarrollador.

 

Productividad: Se define como la cantidad de liberaciones o tareas que pueden ser entregadas por día, semana, mes, bimestre o trimestre. Se pueden calcular en varios niveles: individuo, por fases, por proyecto, tipo de labor, etc.

 

Este indicador depende de la forma en que gestionemos el proyecto. En el caso de un proyecto tipo cascada, podemos definir indicadores de productividad en cada etapa para, por ejemplo, levantamiento de casos de uso, construcción de artefactos de diseño o análisis, implementación de casos de uso, etc.

 

Para proyectos del tipo ágil, cuyas actividades del proceso de desarrollo se llevan a cabo cada vez que hacen falta, el indicador de productividad se realiza en base a las funcionalidades construidas y puestas en operación.

 

En cualquiera de los casos, la productividad es igual al esfuerzo planeado sobre el ejecutado, multiplicado por un factor calculado por la media (promedio) de duración de las tareas o entregas, sobre el tiempo de medida base.

 

Por ejemplo: Digamos que la media en terminar una historia de usuario es 3 semanas, para calcular la productividad por mes el factor será  4/3 (asumiendo que un mes tiene 4 semanas).

 

Así el factor será 1.33 historias de usuario por mes.

Y el esfuerzo es [lo planeado]/[lo ejecutado]*1.33

 

Idealmente [lo planeado] = [lo ejecutado], y nuestra meta es tener nuestro indicador sobre 1.33, pero, por supuesto, esto no será así y en una grafica obtendremos variaciones alrededor de la curva y generalmente por debajo del valor.

 

En la medida que hagamos uso de este indicador seremos capaces de “sintonizarlo” mejor, y podremos segmentar el trabajo de forma que nos quedará más fácil predecir las fechas de entrega de nuestros productos.

 

Progreso: El indicador de progreso se calcula en base a las tareas definidas por el backlog de producto para una iteración, contra las que están completadas. En caso de aproximaciones en cascada, el progreso se puede medir en término de casos de uso completados, numero de artefactos de análisis o diseño, construcción de casos de uno, y etc. Generalmente este indicador como desarrolladores no nos dice mucho (como si podría ser la velocidad), pero a los gerentes se les hace muy útil.

 

Para recolectar los datos, se utiliza unos formatos que nos describe Humphrey en su libro, para mi caso utilizo estos : El formato de registro de tiempo, El formato de plantación de actividades, el registro de productos y el back log de producto. Queda pendiente para una próxima entrega describir dichos formatos y como los uso.

 

Reflexiones finales: Hay dos tipos indicador, los que sugieren tendencias y los que entregan información sobre los productos. Los primeros permiten predecir cuando un proyecto se puede estar desviando, los segundos permiten medir la efectividad de las acciones de mejora; cada organización debe decidir cuales utilizará y para qué. Como desarrolladores, expertos en software, debemos hacer bien nuestro trabajo y ser transparentes al momento de informar el estado de los productos. Como Gerentes de proyecto debemos confiar en el equipo y definir indicadores que verdaderamente reflejen el estado del proyecto y no reducir la gestión a  entregas definidas en un calendario

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: