Monthly Archives: junio 2009

Productividad de los desarrolladores de software

Hola de nuevo.
Llevo tres posts en pocos dias. Estoy consiguiendo todo un record personal. 🙂

Hace un par de dias leí un post de Martin Fowler, gurú del desarrollo agil, sobre que es imposible medir la productividad de un desarrollador. La entradas son:
http://martinfowler.com/bliki/CannotMeasureProductivity.html
o en español
http://www.dosideas.com/liderazgo/439.html?joscclean=1&comment_id=687

Este post habla muy inteligentemente de los problemas que tiene los sitemas de medir la productividad:
Por lineas de codigo: Más lineas de código no significa un producto mejor o con más funcionalidades. En ocasiones incluso es lo contrario. Un par de lineas bien escritas puede ser un trabajo mucho más productivo que hacer copy-paste de varios proyectos a uno sin saber exactamente qué se está haciendo.
Por puntos de función: Un mayor numero de puntos de funcion no significa un incremento en lo que un desarrollo puede aportar al cliente o a la empresa, que es de lo que se trata cuando se quiere medir la productividad.

Entonces, ¿no se puede medir? Hace tiempo que veo de vez en cuando lo que las metodologias como Six Sigma o Lean quieren aportar al mundo del desarrollo. Estas se basan en sistemas de producción tradicionales y estudian el numero de outputs validos respecto a la entrada y numero de outputs no valido (errores). Si no se puede medir el desarrollo, ¿no se puede mejorar?

Realmente si que hay maneras de evaluar la productividad de un desarrollador, pero no son cuantificables de modo sencillo. Voy a comentar una:
En el equipo en el que trabajo hay varios desarrolladores de varia indole: ingenieros en informatica, ingenieros tecnicos y telecos. Cada uno aporta un lobulo de lo que sería el cerebro general que representa al equipo de desarrollo. Igual que ocurre en la serie House, cada integrante tiene una especialidad en la que aporta sus herramientas, pero además debe ser capaz de entender el problema que se le presenta y aportar soluciones racionales que lleven al objetivo final. Es importante la funcion de mentor y de aprendiz en todos y cada una de las materias que se tocan en el desarrollo. Cuando ocurre un problema en su area debe ser capaz de exprimir al maximo todas las posibilidades y pruebas antes de quedarse en blanco. Debe aportar sus conocimiento de testing unitario/refactorizacion/patrones de diseño/punteros/base de datos… ya sea en su propio desarrollo o colaborando en el desarrollo de otro.
Esto… dificil de evaluar cuantitativamente y por lo tanto mejorar. Pero quienes entamos en direccion de proyectos o de departamentos de desarrollo lo vemos dia a día. Quizá de aqui pronto salga un diagrama o tabla en la que poder hacerlo.
Espero vuestros comentarios.

Anuncios

Poker Planning o juguemos a estimar proyectos

Hace poco un compañero me pasó un link. Hablaba de un tipo de planificación usada en desarrollo agil. Acabo de encontrar el link de una pagina que habla solo de eso. La pongo para quien quiera profundizar pero voy a comentar como la realicé yo.

http://www.planningpoker.com/

El tema es sencillo. Se hacen unas tarjetas como cartas en las que ponga los numeros de la serie de Fiabonacci. 1-2-3-5-8-13-21 . Estos numeros es porque la imprecision va aumentando segun el tiempo de estimacion aumenta. Tambien se añade una carta que ponga NPI. NPI significa (no literalmente) que no se tiene suficiente informacion en ese momento para realizar una estimación concreta. El significado literal ya lo sabreis.

De esas cartas se hace un mazo por compontente del grupo de desarrollo. Yo actué como Scrum Master y no debia hacer estimaciones. Los que van a trabajar directamente en el proyecto son los que deben comprometerse con una estimacion.

Se va tarea por tarea haciendo una estimacion que debe ser consensuada entre todos los miembros del equipo de desarrollo. El procedimiento es el siguiente: cada uno pone una carta boca abajo con su estimacion. Todos le dan la vuelta y se busca el menor y mayor valor. Esos quien han hecho las estimaciones extremas deben explicar al resto el por qué piensan en ese valor. Despues de aclarar los puntos de vista se hace otra tirada y se repite el proceso hasta que se llega a un consenso (todos con el mismo valor)

Ventajas de este sistema:
– Toda la estimacion proviene del equipo que se compromete en ella
– Todos acaban entendiendo los pormenores de cada tarea.
– Se sacan a la luz codigos de ejemplo/ideas ya existentes que ayudaran a desarrollar más rapido.

Es importante tener toda la informacion posible para la estimacion. Un caso que ocurrió es que uno de los miembros hizo una estimacion alta. No sabia que uno de los compañeros de otra oficina tenia un codigo de ejemplo. Como no estabamos seguros de si el codigo era realmente tan iluminador como esperabamos el resto llamamos por telefono en ese momento al desarrollador de la otra oficina. Su llamada confirmo que aunque existia el ejemplo, era un codigo antiguo y no usado por lo que podia tener problemas.

Es importante hacer iguales todas las tarjetas. La ventaja de tirar todas las cartas boca abajo hace que todos pongan su punto de vista sin fijarse en algun desarrollador mas experimentado pero que quiza no tiene toda la informacion sobre la tarea en cuestion.Cuando yo lo hice, algunos se fijaban en el tamaño de las tarjetas del resto para adivinar cual era su estimacion.

Ventajas inesperadas:
– Más cohesion en el grupo. El compartir todos los puntos de vista hace que empiecen a trabajar más como equipo que como conjunto de individuos.
– No deja de ser un modo divertido de hacer estimaciones. Se empieza el proyecto con buen humor.
– Se trabaja de modo más comprometido ya que todos y cada uno han apoyado la estimacion. No se la han impuesto.

Ha sido una gran experiencia y se la aconsejo a todos los jefes de proyecto/Scrum Masters/jefes de desarrollo etc. Normalmente se ve asociado a desarrollo agil pero no es necesario que el proyecto sea agil sino que se puede hacer con proyectos con metodologia más lineal.

Espero vuestros comentarios.

Analogias de Scrum y partida de Rol

Hace ya más de un año que llevo mirando temas de gestion de proyectos. Empecé mirando la certificación Six Sigma para la optimización de procesos pero decidí empezar a aprender qué se mueve en concreto en la gestion de proyectos software. Lo que he ido encontrando lo pondré en este blog en breve pero primero quiero poner unas analogias que se me ocurrieron entre la metodogia Scrum y lo que se mueve en un juego de rol.

Hay muchos que como yo, hemos pasado una parte de nuestra juventud jugando a juegos de rol. De algun modo el rol/comics/informatica esta raramente conectado. Bien, empecemos:

Scrum Team/ jugadores de rol

El scrum team es un grupo heterogeneo de especialistas que se compromenten en conseguir un objetivo en un tiempo dado (un sprint). Ese grupo puede estar compuesto por programadores/testeadores/expertos en BD,…

En el rol hay pocas cosas más heterogeneas que un grupo de rol (paladin, orcos con mala leche, elfos con más pluma que las de sus flechas,…). Ese grupo tiene una misión para hacer en un tiemplo dado (una partida).

Scrum Master/ Dungeon Master o Máster

El Scrum Master está a disposición del equipo. Les ayuda a elegir un grupo de tareas para completar en un sprint. Les ofrece toda la ayuda que está en su mano para que el equipo lo unico que tenga que hacer es centrarse en el objetivo. Es el interfaz entre el equipo y el resto de interesados en el proyecto y con la dirección.

El Dungeon Master les plantea el escenario a los jugadores y se preocupa en que el juego sea dinamico y que vayan avanzando en la misión con los personajes y situaciones que se inventa durante la misión. Normalmente es el que pone la casa, aporta las patatas fritas, hojas, lapices, refrescos ….

Daily Scrum/Turno

El Scrum Master se reune a primera hora de la mañana con el equipo y estos cuentan 3 cosas: qué han hecho desde la anterior reunion, qué haran hasta la proxima y qué dificultades tiene para  realizar ese trabajo.

En cada turno el master pregunta a cada uno de los jugadores qué va a hacer en ese turno y le cuenta las consecuencias de su elección hasta el siguiente turno.

Gestion de proyectos/Llevar una partida de rol

Scrum: Se debe conocer muchas metodologias y herramientas pero sólo usarlas si ayudan a realizar mejor su trabajo, que es el objetivo de esa misión. No intenta preveer al detalle todo el trabajo a realizar y realizar un analisis exaustivo sino saber responder rapidamente a las necesidades del equipo y ayudarles a orientarse.

Rol: El master conoce las normal del juego en cuestion pero las ignora cuando molestan. Si estan en plena batalla no se pone a hacer tiradas de probabilidades de que les salga un erpes labial aunque en el libro ponga que el contacto tiene 2/100 de que se les contagie. Esto puede afectar al objetivo principal de cualquier juego de rol (pasarlo bien). No tiene un mapa detallado de todos los puntos por los que pasaran con todos los PNJ y sus personalidades sino que se va inventando lo necesario y moviendo de sirio los lugares que ha ideado.

Si a alguien se le ocurren más analogias que me las comente y las voy añadiendo a la entrada.