Colaboración real: lo que más cuesta lograr en los equipos

Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:

• Trabajan en iteraciones (o sprints)
• Planifican al inicio
• Revisan al final
• Hacen retrospectivas (a veces) y tratan de mejorar

En muchos casos también tienen su reunión diaria (la daily standup o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.

Antipatrón 1: cascada iterativa

Se nota al sincronizar que los miembros del equipo tienden a esperarse entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...

Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.

Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.

Antipatrón 2: sobre-especialización

También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.

En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.

La magia de trabajar de a pares

Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.

Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:

• Tratar de terminar cuanto antes lo que tiene más valor
• Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos
• Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.
• Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.

¿Todo hay que hacerlo de a dos?

No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.

Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.

Colaboración real en equipos

Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.

Lo que busca un equipo ágil es aplicar el principio de Pareto a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.

En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".

Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.

3 dudas sobre Extreme Programming

Esta semana una asistente a uno de mis talleres de Desarrollo Ágil de Software me envío estas consultas, que como acordamos, intento contestar aquí de manera abierta, para ella y para otros que puedan tener esas dudas.

Hola Martín!

Saludos desde Lima.

Disfruté mucho el taller de Desarrollo de software ágil, ya lo estoy recomendando.... al pasar los días me surgieron unas preguntas que cuando tengas oportunidad por fa me escribes...

Vale la pena aclarar que yo voy a dar mi opinión personal. Yo empecé a utilizar ideas de Extreme Programming (XP) a fines de los '90 y a principios de los 2000 me convertí (se ve que no había mucho más para elegir) en XP Coach de varios equipos. En todo ese tiempo he juntado muchas ideas y dudas nuevas, pero trataré de aportar alternativas y vías de exploración, ya que no creo en que haya UNA respuesta para estos temas.

 

1- Una vez que se decide adoptar XP. El pair programming se aplica todo el tiempo? O se da cabida a espacios para programar individualmente y mob programming?  

Aunque en los orígenes de XP esa era la idea, en la práctica y a medida que ha pasado el tiempo la práctica se ha vuelto más pragmática. Recordemos siempre que a pesar del nombre, XP está basado en principios y valores que son los que buscamos, y las prácticas son solo un reflejo adaptable de ellos.

Cuando la solución más sencilla (recordemos que la Simplicidad es primordial en XP) es escribir el código de a uno, no vale la pena buscar un par. Los casos típicos son los que son triviales: construir otra pantalla, adaptador o función que es una variante particular de otras que ya están hechas.

Cuando el desafío es bajo y las tareas son de muy bajo riesgo, podemos obviar el par. Ahora, cuando nos encontramos realizando tareas repetitivas pero que pueden ser críticas, podemos al menos mantener un criterio de revisión de a pares. Lejos de la programación, en Kleer siempre hacemos revisión de a pares para propuestas o presupuestos.

Mob Programming es todavía una técnica relativamente experimental como práctica continua, pero en varias oportunidades en distintos equipos en los que trabajé pasamos de programar de a pares a tríos o cuartetos. Cuando uno pasa ese límite es difícil trabajar con un monitor usual y el salto a un proyector o una pantalla grande  implica un reacomodamiento mayor. Un paso intermedio usual es realizar workshops de diseño en conjunto para definir componentes de arquitectura, refactorizaciones importantes a nivel de framework o para ensayar alternativas de diseño con todo el equipo.

En todos los casos lo que funciona es probar y aprender. Una de las premisas es que si no experimentamos en la búsqueda de mejores maneras de trabajar como equipo, siempre estaremos ocupados pero probablemente desperdiciando esfuerzo.

 

2- Se puede aplicar TDD o BDD a proyectos que ya han empezado de la manera tradicional (sin metodologia de desarrollo agil o casos de prueba?) o tiene que ser proyectos que aún no hayan arrancado?  

Claro que si. Lo más sencillo es usar TDD para código nuevo aunque la solución sea vieja. Un poco más complejo es construir la infraestructura de pruebas en el código antiguo. Para eso utilizamos una serie de técnicas especiales para romper dependencias fuertes en el código. La referencia canónica para esto es el excelente libro de Michael Feathers, Working Effectively with Legacy Code.

Básicamente, mientras haces TDD para el código nuevo, vas necesitando desacoplar la parte del código viejo con el que hay que interactuar, y para eso hay que ir logrando desarmarlo e ir dejando algunas pruebas que nos ayuden en esa tarea.

Algo que si desaconsejo es generar proyectos de "refactorización pura". Cuando nos ponemos exquisitos en cuanto a la calidad del código sin tener en cuenta las necesidades reales de la organización o sus clientes, nos arriesgamos a entrar en un proyecto con objetivos poco claros. Mejor que eso es comprometernos a usar estas técnicas para mejorar el código relacionado con la funcionalidad que necesitamos modificar, y esa manera, con el pasar del tiempo, las partes del código que requieren más cambios (lo que de alguna manera demuestra que son más valiosas) irán mejorando y serán más fáciles de entender, probar y extender.

 

3- Algunas empresas no les agrada mucho el aplicar Pair Programming porque tienen la idea que es menos productivo y que así los programadores charlarán entre ellos y no programaron. ¿ Qué argumentos se pueden utilizar para cambiar esas ideas? Y Cómo hacer para que los programadores efectivamente no se pongan en ese plan (pudiera pasar)  

Lamentablemente todavía hay organizaciones que dejan pasar las oportunidades de mejorar porque se enfocan en que la gente (a a que suelen llamar recursos) cumple un horario haciendo lo que suponen que es su tarea.

Si pensamos que la tarea de un desarrollador de software es programar, y no hablar, casi seguro obtendremos como resultado código que hace lo que el programador interpreta de un documento, sin entender lo que hace, y sin preocuparse por que lo que hace agregue valor. Para un desarrollador en esas situaciones siempre recomiendo tratar de generar evidencias de que hay maneras mejores de trabajar, y en último lugar recuerdo siempre el dicho "si no puedes cambiar tu trabajo, cambia tu trabajo". No me parece bien tomarse livianamente la ida de que la organización "es así", porque en muchos casos vi gente desde las posiciones más humildes e inesperadas generar una ola de cambio. 

Un buen desarrollador tiene que charlar con el resto del equipo y buscar soluciones apropiadas a las necesidades planteadas, y debe lograr entender el contexto de negocio y aportar su visión. Si limitamos a los desarrolladores a programar lo que otros le indican sin nada más, llegaremos siempre a soluciones mediocres o pobres. De la misma manera, si el equipo no entiende y no está conectado con los problemas que tiene que resolver, su motivación será obviamente más baja, y eso no lo compensa trabajar de a pares o no. 

Al revés, si el equipo está conectado con el negocio, al trabajar de a pares encontrarán mejores soluciones que trabajando solos. El principal problema de trabajar solo para un desarrollador es la facilidad para perder el foco o bloquearse en detalles menores, cosas que casi no suceden al trabajar de a pares.

En resumen, para mi un argumento fundamental es si queremos "cantidad de código" o "buenas soluciones".

Video: Programando de a pares con Emilio Gutter

En esta nueva sesión de programación de a pares me sumo a Emilio Gutter para hacer un ejercicio utilizando Java.

Conocí a Emilio a fines del 2006 cuando fuimos compañeros de equipo durante el curso de Certified Scrum Master dado por Tobias Mayer. Nos divertimos mucho durante ese curso, y varios de los que pasamos por ahí nos mantuvimos en contacto después a través de una primer lista de distribución que fue uno de los puntos focales de donde surgió el grupo de organizadores de la primer conferencia de la serie Ágiles: Ágiles 2008.

Emilio lleva más de 10 años trabajando en desarrollo de software y es un desarrollador trotamundos que ha trabajado en proyectos en Argentina, Brasil, UK, USA, Francia, Rumania y Bulgaria, por lo menos. Actualmente es uno de los líderes de su consultora 10pines, que brinda servicios de desarrollo, entrenamiento y coaching, con fuerte foco métodos ágiles, incluyendo un alto compromiso con la calidad y la cultura organizacional.

En el video podrán ver cómo hacemos un ejercicio de diseño en Java, usando Eclipse con JUnit 4 y la biblioteca de mock objects mockito y planeábamos utilizar también harmcrest,una biblioteca de matchers (o predicados) muy útil para realizar aserciones en las pruebas unitarias, pero no alcanzó el tiempo esta vez, así que quedará para más adelante.

Les dejo el video (de aproximadamente 25 minutos) y espero que lo disfruten:

Video: Programando de a pares con Mariano Koldobsky

Mi invitado esta vez es Mariano Koldobsky, un experimentado trabajador al que conozco desde hace años, a raíz de conocernos en una empresa en que él trabajaba y yo daba consultoría, y reencontrarnos más tarde en la comunidad ágil.

Tiempo después logramos trabajar juntos por un tiempo, hasta hace poco cuando Mariano empezó a trabajar para bvision, que tienen oficinas cerca de su casa en La Plata, capital de la provincia de Buenos Aires.

Con Mariano compartimos la pasión por la programación, la electrónica y recuerdos de nuestra generación, ya que somos los dos bastante veteranos. Pero casualmente esas dos primeras aficiones nos llevaron a elegir como tema de nuestra sesión un ejercicio de programación y cableado, utilizando una placa Arduino, que es una plataforma de hardware abierto, ideal para realizar prototipos e implementaciones sencillas y caseras de dispositivos de control.

Como verán en el video, la placa se conecta por USB (anteriormente por puerto serie) y se programa en un lenguaje de programación propio (una especie de Processing, pero basado en C++ en lugar de Java).

Algo interesante de Arduino es que es la plataforma que tomó de base Google para desarrollar su propio Android Open Accessory Development Kit, con lo que conocerla ahora puede significar algo más que un mero pasatiempo.

El video dura un poco menos de 15 minutos, y espero que les resulte tan divertido como a nosotros grabarlo. ¡Al menos por una vez van a ver algo más que código!

 

Video: Programando de a pares con Diogenes Moreira

En esa sesión mi par es Diogenes Moreira, amante de la Orientación a Objetos que a pasado por múltiples tecnologías desde Cobol y PowerBuilder hasta Java y C#, siempre con su corazón cerca de Smalltalk.

Diogenes trabaja actualmente para Ilon SA y aunque tiene múltiples responsabilidades no deja de programar junto a su equipo. Participó en varios proyectos de código abierto, incluyendo colaboraciones para Pharo.

Nos conocemos por amigos comunes y por el grupo Agiles de Buenos Aires, y casualmente durante una de las reuniones mensuales de éste nos escapamos un rato a grabar este video en que hacemos algunos ejemplos con Seaside, un framework web para Smalltalk.

Como acompañamiento del video, dejo esta presentación de Esteban Lorenzano, en la que se recorren varias de las características que Diogenes comenta mientras escribimos los ejemplos:

Sin más preámbulos, el video, que dura aproximadamente 35 minutos. Estoy usando un servicio que brinda mucho mejor calidad de video (sobre todo para el código), pero tengan paciencia porque el reproductor puede tardar varios segundos (a veces casi un minuto) en empezar.

 

Video: Programando de a pares con Gabriel Falcone

En esta oportunidad me reuní a programar con Gabriel Falcone, líder técnico en equipos de desarrollo de una empresa multinacional de origen argentino.

Conozco a Gabriel desde hace unos años, y compartimos el interés por el desarrollo de software y la dinámica de equipos. Gabriel también es ayudante de cátedra en FIUBA, con mi amigo y futura víctima de esta serie, Nico Páez.

En esta ocasión nos sentamos con Gabriel, en el laboratorio del MUG, donde recién terminaba de dictar una clase de su curso de C#, para recorrer algunos ejercicios basados en cosas que implementó recientemente en proyectos reales, utilizando técnicas de Reflection en .NET. En el video recorrimos dos ejercicios, pero en total hay tres que Gabriel tenía a mano, y que incluyo para quienes quieran jugar con ellos:

• Ejercicio 1: Serializando objetos en DataTables
• Ejercicio 2: Buscando clases con un atributo para invocar un método
• Ejercicio 3: Multimétodos en C# (no cubierto en el video)

Los ejercicios son en C#, utilizando Visual Studio 2010.

Video: Programando de a pares con Martín Alaimo

En este segundo video de la serie de sesiones de programación de a pares le toca el turno a Martín Alaimo, de Kleer.

Conocí a Martín en los comienzos de la comunidad Agiles.org en Argentina, cuando él todavía trabajaba en Accenture, y seguimos en contacto desde entonces, compartiendo varios eventos, viajes y peripecias del mundo del desarrollo.

Martín tiene algunas certificaciones más tradicionale como PMP (Project Management Professional) o Certified Java Developer, y varias dentro del campo ágil, como Certified Scrum Master Practitioner (la variante más concreta de esa certificación algo cuestionada) y más complejo aún, es uno de los pocos entrenadores certificados del curso de Scrum Development en América Latina (el único en Argentina y alrededores, hasta donde yo se).

Pero lo más importante no son los títulos sino la larga experiencia que demuestra desarrollando o enseñando, y la buena disposición para compartir esos temas con la comunidad, que lo han llevado a organizar los Yoseki Coding Dojo (de los que hablé en otro post) y asumir la responsabilidad de co-dirigir la organzación de Agiles 2011.

En esta sesión lo que tratamos de recorrer con Martín es el camino del diseño basado en dos prácticas complementarias pero que a veces parecen solaparse: TDD (Test-Driven Development) y ATDD (Acceptance Test-Driven Development).

Para el ejemplo, que codificamos en Ruby, usamos Cucumber para las pruebas de aceptación (ATDD) y RSpec para las unitarias (TDD).

Espero que les resulte interesante, y como siempre, esperamos feedback para saber por dónde continuar o qué temas tratar en más profundidad.

 

Video: Programando de a pares con Carlos Peix

Con este post comienzo una serie de entrevistas que tenía en mente desde el comienzo de este blog el año pasado, pero a la que no le encontraba el formato definitivo, hasta hace poco.
En realidad, me di cuenta que no quería hacer entrevistas convencionales, y me parece que lo mejor para nosotros desarrolladores es ver a otros en la práctica, así que estoy comenzando a grabar sesiones de programación de a pares.
La idea es aprovechar la excusa para darme el gusto de programar con amigos y conocidos de la industria regional. Algunos, como este primer caso con Carlos, serán sentados a la misma mesa, y algunos serán remotos, a distancias diversas según la ocasión. Como es tradición de este blog, tengo en mi backlog sentarme a programar en diferentes lenguajes, tecnologías, y en algunos casos tal vez no sea código sino diagramas en un pizarrón, o alguna charla más tradicional, pero siempre que pueda, será a código limpio.

---

Para iniciar la serie entonces, recurrí a varios amigos, y la primer víctima fue Carlos Peix. Nos conocemos desde hace más años de los que puedo recordar, a través de la comunidad Microsoft. Carlos es un desarrollador independiente con muchos años de experiencia y una actitud abierta a nuevas ideas, pero que no se deslumbra fácilmente con las nuevas modas y prefiere centrar su atención en las técnicas de diseño e implementación más perdurables. Es reconocido sobre todo como especialista en desarrollo web y el mundo .NET, pero siempre está mirando y practicando un poco de Java, Ruby o Smalltalk.
Carlos también participa activamente en la comunidad Agiles.org localmente y en la organización de Agiles 2011. Tiene un blog con varios videos muy interesantes que graba por iniciativa propia y al participar en otras comunidades, como Alt.Net Hispano, donde es presentador habitual.
En el video que grabamos (unos 20 minutos en total), Carlos trajo un ejemplo extraído de un caso real que le tocó, sencillo pero ya algo avanzado y con unas pruebas unitarias, y entre ambos hicimos una sesión de refactorización. El ejemplo es en C#, y usamos Visual Studio 2010 con ReSharper. Para quienes quieran ver el código con más detenimiento, dejo la solución al inicio del ejercicio, y la solución al final.