Ene 08 2010

Jefes y libros

Categoría: Equipos, LibrosJuan @ 4:05 pm

Leyendo “The Pragmatic Programmer” me vino a la cabeza que este es un libro que daría a todo nuevo programador (especialmente a los que tengan poca experiencia) que fueran contratados por mi empresa. Esto, a continuación, me trajo recuerdos de uno de los mejores jefes que he tenido.

¿Qué hace de un jefe un buen jefe?. Una pregunta complicada que, seguramente, tendrá distintas respuestas dependiendo del carácter de la persona a quién preguntes. No creo que todos tengamos la misma idea de lo que es ser un buen jefe aunque, estoy seguro, habría muchas cosas en común.

En mi caso particular, esta persona era más otro miembro del equipo que un jefe típico que ve las cosas desde una perspectiva más alejada del trabajo diario del resto del equipo. Esto no quiere decir que no tuviera tareas distintas a las nuestras, que las tenía y muchas, pero siempre que podía, intentaba sacar tiempo y ayudarnos con nuestras tareas. Esta ayuda podía venir de muchas maneras: hablando sobre el tema, abriendo debate entre todos para ver cómo hacer las cosas mejor, cómo mejorar, haciendo preguntas incómodas (eso sí, dejando claro que quería saber por qué hacíamos esto y no lo otro y que no nos estaba desafiando. Decía: “I’m not challenging you, I only want to know why”), compartiendo su experiencia en temas parecidos, escuchando, mostrando apoyo, etc. Una persona que siempre estaba ahí para ayudar y sacar las cosas adelante cuando hacía falta y que marcaba cómo quería que fuese el equipo con ejemplo y hechos (no sólo con palabras).

Como os podéis imaginar, su relación con el equipo era más la de un colega (con el que salíamos a tomar cañas -por otro lado, debo mencionar que esto, en Finlandia, es bastante normal-) que la de un jefe, gerente o como lo quieras llamar y esto marca la diferencia. Algunos pensaréis que esto podría haber causado que perdiésemos nuestro respeto hacia él. Nada más lejos de la realidad. Lo que consiguió con esto fue un equipo muy cohesionado, que trabajaba muy bien junto y con un ambiente de trabajo excepcional.

También tenía las cosas muy claras y el carácter fuerte (lo que hacía que tuviese sus detractores en la empresa también, claro) pero esto, al menos para mi, no era impedimento para tener una buena discusión con él sobre cualquier tema aunque estuviese totalmente en desacuerdo conmigo. Nunca dijo, “esto se hace así porque lo digo yo” sino que intentaba convencer con razones y hechos y no con poder.

Cuando entramos en el equipo, lo primero que hizo fue regalarnos (de su bolsillo, por cierto), dos libros. Nunca he tenido una experiencia similar en ningún equipo o compañía en la que he trabajado. Fue un pequeño gesto (y esto, que quede claro, no le hace un buen jefe de por sí) pero, al menos para mi, marcó la diferencia y me causó una muy buena impresión.

P.D.: En caso de que os estéis preguntando, los libros fueron: “The fifth discipline” de Senge y “The Toyota Way” de Liker.


Ene 16 2009

Niveles de decisión

Categoría: Equipos, GestiónJuan @ 9:20 am

Cuando hablamos de organizaciones ágiles, métodos, etc., siempre suele haber distintos temas que aparecen regularmente en la conversación: integración continua, TDD, automatización, test unitarios… Sin embargo, cuando alguna metodología ágil es introducida en una organización normalmente hay confusión sobre que debería ser obligatorio y qué debería ser recomendado y quién debería promocionar o incluso exigir las nuevas prácticas o ideas. ¿Deberían ser la compañía per sé, los equipos, los gerentes (jefes de proyecto, dueños de producto…), etc.?

En mi opinión nada es blanco o negro y siempre hay muchos niveles de grises en el medio:

  1. Hay ciertas prácticas obligatorias que deberían ser decididas a nivel de compañía por alguien con suficiente poder de decisión al hablar de este nivel. Estas prácticas deberían ser seguidas por todo el mundo y los equipos o los individuos no deberían discutir sobre ellas. Por ejemplo, el uso de una herramienta de control de código (SVN, CVS, GIT, etc.) para cualquier proyecto de desarrollo de software. No creo que nadie esté en desacuerdo con la obligatoriedad de esta herramienta al desarrollar software. En mi opinión, lo mismo debería pasar con la integración continua, los test automáticos y un sistema de control de errores.
  2. Otras prácticas deberías ser decididas por el gerente de un producto aunque la idea pueda venir de abajo a arriba. En esta categoría, la decisión es tomada por el gerente ya que su decisión afecta a todo el producto (y no sólo un equipo si hay varios equipos trabajando para el producto) Esta persona debe decidir basándose en el esfuerzo que supondrá para los equipos, tiempo, coste, calidad, etc. En esta categoría se encontraría, por ejemplo, el configurar los equipos por componentes o por funcionalidades, la definición de aceptación, etc.
  3. Muchas otras son decididas por el equipo y no deberían ser impuestas por los gerentes o la empresa. Los gerentes puede pedir objetivos a más alto nivel (tener algo listo para producción al final de una iteración, ningún error abierto entre iteraciones, etc.) El equipo decide sus propias prácticas en base a estos requerimientos a lo que considera importante a la hora de producir software. El equipo decide la definición de hecho para sus tareas, si deben usar o no TDD. Si deben hacer UT para todo el código o sólo para las partes más importantes, trabajar por pares o no o cuando hacerlo, hacer revisiones de código sistemáticas, por relevancia o no hacerlas… El equipo debe darse cuenta por si mismo como llegar a ser (reflexionando sobre sus propios errores) un equipo excelente sin ser dirigido o impuesto en “como hacerlo” por el gerente.

Etiquetas: ,


Dic 17 2008

Equipos de mantenimiento

Categoría: EquiposJuan @ 2:19 pm

Equipos de mantenimiento sí o no, esa es la cuestión.

Hablo de un escenario específico donde hay varios equipos en un proyecto y todos ellos trabajan por funcionalidades y no por componentes. Esto quiere decir que todos los equipos son capaces de trabajar en todas las áreas del proyecto y por tanto empezar y acabar la funcionalidad (o lo que es lo mismo, no hay equipos que sólo trabajan en la interfaz de usuario o sólo en la librería X, etc)

Antes de seguir, con mantenimiento me refiero a todos aquellos errores encontrados después de una iteración cuando la historia o al trabajo se le considera “hecho”. Si los errores se encuentran durante una iteración y están relacionados con el trabajo que se está llevando a cabo, éstos se arreglan de inmediato.

A los equipos que trabajan por funcionalidades se les asigna, como hemos visto, una funcionalidad entera (ya sabemos que ésta está dividida en puntos o historias en la pila de producto) que puede tocar todas los componentes del proyecto y, por tanto, esto nos lleva a que los equipos pueden tocar el mismo componente a la vez. Así que, si se descubre un bug, ¿qué equipo debe arreglarlo si los dos han cambiado el código?

La situación ideal es que cualquiera de los equipos se pidan voluntarios para hacerlo o áquel que lo haya encontrado, claro. Sin embargo, una situación más realista y frecuente, por desgracia, es que todos los equipos digan que cualquier otro tiene que arreglar el error (tirar balones fuera, vamos) Así que, ¿cómo podemos evitar esto?

La primera solución sería coordinar quién arregla los errores en una reunión donde haya representantes de cada equipo. En esta reunión se revisarían los errores encontrados y se asignarían (si no hay voluntarios) al equipo que mejor le venga dependiendo en su disponibilidad y su trabajo en ese área. El scrum de scrums suena como un buen candidato, ¿no? El punto negativo es que esta discusión puede llevar mucho tiempo dependiendo de la actitud de los equipos. Si no hay voluntarios la asignación a dedo puede ser acertada o no e incluso algún equipo puede negarse a coger algún error a pesar de ser el mejor candidato. No parece la mejor solución si los equipos no son muy colaborativos.

Otra solución sería establecer de antemano quién va a arreglar los errores que se encuentren, es decir, crear un equipo de mantenimiento que, por cierto, debe rotarse después de cierto tiempo (uno o varias iteraciones). De esta manera siempre hay un equipo que se hará cargo de los errores ya que es su única función en la iteración y se evita que los equipos no lleguen a un acuerdo sobre quién va a arreglar cierto bug.

Etiquetas: ,


Dic 04 2008

Metodologías ágiles y cultura

Categoría: Equipos, MetodologíasJuan @ 10:43 am

Todas las metodologías ágiles proponen la interación y comunicación directa entre los miembros de un equipo. La idea es que es mucho mejor discutir cara a cara que por correo electrónico, por ejemplo.

Por esto, estas metodologías hablan de usar pizarras, post-its, notas de colores, grandes espacios para diseñar, escribir, dibujar, etc., dónde el equipo pueda, directamente y sin el uso de ordenadores o herramientas, interactuar y comunicarse de tú a tú.

Centrándome en Scrum específicamente, la misma idea viene con las reuniones diarias, las restrospectivas (que no nos únicas de scrum, que quede claro) con sus distintos métodos y juegos para hacer hablar, dialogar y discutir a la gente sobre problemas. Étcetera.

Ahora bien, ¿qué pasa si la tendencia general en un equipo es el ser tímido o más introvertido de lo deseable para estos métodos? Si la gente no habla tanto como se desearía, si no interaccionan tanto como se espera porque no se sienten agusto con este tipo de métodos extrovertidos, ¿se fuerza a la gente a ser como no es o se cambian los métodos?

Ahora mismo trabajo con un equipo donde la mayoría de los integrantes (todos menos uno) son muy introvertidos. Hablan lo justo y necesario y sólo si tienen algo que decir que crean que es realmente importante, si no es así… silencio. Me cuesta sudor y lágrimas el que tengan una discusión fluida, que se expresen en el “daily scrum” (reunión diaria de 15 minutos donde se dice qué se ha hecho desde la última reunión, que se va a hacer hasta la próxima y si hay algún problema) o que en una retrospectiva sigan los “juegos”.

Hablando con ellos uno a uno sobre esta situación, preguntándoles el porqué, cómo mejorarlo y que sugerencias tienen al respecto, uno de los miembros del equipo me dijo algo parecido a lo siguiente, lo cual me hizo pensar mucho en cómo es scrum: “[…] encuentro las reuniones útiles y no quiero que desaparezcan, sin embargo, no entiendo por qué no puedo estar en silencio si no creo que tenga nada que decir. Sé que hay que participar e iteractuar pero yo soy como soy y si no encuentro algo considerable que decir prefiero quedarme en silencio. Lo siento pero es mi forma de ser y no creo que pueda cambiarla […]”

En el OOPSLA de este año participé en un seminario sobre metodologías ágiles y cultura. Una de las tesis en ese seminario fue que hay que tener en cuenta que scrum tiene una cultura específica detrás (no hay que tomar “cultura” como “cultura nacional” solamente) y que en su invención esta cultura tuvo mucha influencia. Además, su forma original está enfocada a este tipo de cultura también debido a esta influencia. Por tanto, aplicar directamente scrum (o forzar su forma original) sin tener encuenta la cultura a la que va destinado puede ser una catástrofe y no funcionar en absoluto.

La pregunta ahora es, ¿cómo adaptar scrum o qualquier otra metodología a este tipo de equipos sin quitar el “jugo” de la metodología en sí? La respuesta no la sé, por desgracia, aunque estoy experimentando con varias ideas que darán sus frutos o serán una catástrofe (la persona que lleva la retrospectiva se rota para que cada uno de su “visión” o “forma”, que el scrum master tome un rol más activo en los meetings diarios…) Hay que esperar y ver qué pasa. ¿Tenéis vosotros alguna idea?, ¿habéis visto o estado en esta situación?

Antes de acabar quiero dejar claro también que, por supuesto, los miembros del equipo tienen que poner también de su parte para que esto funcione. No es sólo o la metodología o el equipo. Son los dos. Los dos tienen que adaptarse el uno al otro ya que es una relación bidireccional (o así lo veo yo)

Etiquetas: ,


Ago 29 2008

Las cinco disfunciones de un equipo

Categoría: Equipos, LibrosJuan @ 1:16 pm

Las cinco disfunciones de un equipo

Trabajar bien en equipo es difícil, perdón, muy difícil.

Un equipo no es solamente un grupo de individuos trabajando juntos por una meta común, hay mucho más detrás. De hecho, uno de los mayores problemas que un equipo puede tener es el que sus miembros trabajen sólo individualmente dentro del equipo, es decir, tener un equipo de cara a la galería pero trabajar individualmente internamente. O lo que es lo mismo “Tú tienes TUS tareas y yo las MÍAS. Punto.” cosa que, por cierto, he visto más de una vez.

Los equipos toman mucha más importancia en las metodologías ágiles que en las “clásicas” (véase cascada, modelo en V, etc). Diría, incluso (y sin él), que el equipo es lo más importante.

Esto viene, básicamente, de uno de los principios firmados en el manifiesto por el desarrollo ágil, “Individuos e interacciones sobre procesos y herramientas“. Es decir, trabajo en equipo “de verdad” donde los miembros están juntos, interactúan cara a cara lo máximo que sea posible, dialogan, discuten, bromean, se ayudan y se esfuerzan por alcanzar un meta común (la del equipo) y no por una meta individual. Un equipo cohesionado puede lograr cosas inimaginables por individuos trabajando por separado. Esto es un hecho.

Pero me estoy yendo de madre y como diría el autor del libro que quiero comentar si fuera Francisco Umbral, “yo he venido aquí a hablar de mi libro”.

Las cinco disfunciones de un equipo: una fábula de liderazgo” da un modelo para reconocer y resolver las cinco mayores disfunciones que un equipo puede tener según el autor, Patrick Lencioni, para convertirse en un equipo magnífico. La originalidad del libro viene en que el autor cuenta una historia (que ocupa la mayoría del libro) sobre un equipo de directivos para dar a conocer las disfunciones y cómo tratarlas de una manera práctica. Después de la historia, el autor desarrolla de una manera simple el modelo y las disfunciones, formas de reconocerlas y de como atacarlas.

Las disfunciones, simples y obvias a simple vista pero que no lo son tanto en el día a día de un equipo, son las siguiente (explicadas muy brevemente):

Continuar leyendo “Las cinco disfunciones de un equipo”

Etiquetas: ,