[bcn-pm] [offtopic] Evaluate productivity

Bruno brunorcagmail.com
Dma Gen 29 11:22:43 PST 2008


Hola

2008/1/29, Òscar Álvarez Vilaplana <oscar at poal.org>:
> Número de línies de codi, número de crides a funcions, número de bugs
> en un cert temps... no trobo que aixň tingui cap relació amb la
> qualitat d'una feina o la productivitat d'un programador.

Frederick Brooks: "Mythical man-month" [http://tinyurl.com/ypkg94]. Si
quieres medir la productividad de los programadores y todavía no lo
has leido, haz lo. Esperando hasta que el libro llege de amazon a tus
manos, puedes seguir con mis opiniones.

<opinion biased="yes" mode="heavily">

Eso depende de la metodología que se usa para mantener el proyecto,
pero me parece que contar la productividad en lineas del código no
tiene sentido en ninguna.

En caso de las metodologías agíles se puede mirar a los milestones.

Como siempre - si quieres medir algo, tienes que definirlo antes.
Entonces la pregunta fundamental es: ¿como se define productividad?

Hay gente que te dice, que el trabajo de los programadores es como el
arte (o la meditación de los monjes). Se puede reir de eso, pero una
cosa es segura: el código es solo la herramienta, no el efecto finál.
Usamos código, para pasar a ordenador las ideas de como resolver un
problema.

Entonces la productividad se puede definir como la capacidad de
resolver los problemas dados (con dedos :P). Y es una función muy
complicada de muchos factores. Lo que tiene de ver con arte es la
presencia de alguna "fuerza mayor", que a veces nos toca, augmentando
la productividad.

Otra cosa más: para medir algo se debe definirlo antes. Y para
definir, se debe entender. Puedes crear tu propia definición de la
productividad, medirla y poner los resultados encima del escritorio de
una persona, que no tiene ni idea (y no quiere tenerla!) sobre el
trabajo de los programadores.

Un ejemplo: hoy a las 9:30 por la mañana en Wrocław (Polonia) era 5
grados de temperatura, y en Barcelona también. Eso no necesariamente
significa, que éstas dos ciudades tienen el mismo clima. Pero usando
solo los resultados, sin contexto, se puede llegar a esta conclusión.

Y dos preguntas:
1. Como se puede medir la productividad de un médico? O un arquitecto?
O un político?
2. Disculpa, pero ¿somos obreros? Un par de días atras he visto
algunos articulos sobre el problema "Is the developer job white-collar
or blue-collar?". Nosotros no usamos ladrillos y nuestro trabajo es
más del mundo de calidad que cantidad (que para mi es la diferencia,
que separa los white-collars y blue-collars). Y como medir la calidad
del software? Parece, que no es tan fácil [http://tinyurl.com/yuvump].

</opinion>

Parece, que soy un guerilla del "arte de programación". Por otro lado
entiendo muy bién, que proyectos grandes (y de gran importancia)
necesitan algunos principles. Estos principles deberían ser claros
para los que miden - y los que son medidos.

Mira al Scrum, que puede ser una solución. El problema es, que no
sirve bién para los grupos grandes. Pero con el buen diseño se puede
modularizar el proyecto, y el desarrollo de los modulos conducir con
la metodología Scrum.

Quien llegó aquí y sobrevivó?

Saludos, Bruno


Més informació de la llista de correu Barcelona-pm