• Montar un club de lectura técnica. 1 libro al mes de programación, testing, etc. Con discusiones de capítulo semanales.
• Sesión de cine, con proyección de video katas o código por parte de programadores reconocidos.
• Programación por parejas, al estilo “reservo una hora de mi jornada a ayudar a quien me lo pida”
• Katas matutinas
• Crítica de código abierto: Abrir y leer durante 45 minutos un código de un proyecto (unas 100 líneas) y hacer una valoración
• Lightning talks, pequeñas charlas rápidas sobre algún tema que estemos tocando
• Startup launchs, preparar una idea sobre un proyecto, y hablar durante la comida de lo viable que pudiera ser.

Por cierto, si alguien no puede dormir o no tiene plan para un fin de semana, en la sala CIBALL hacen proyectos de colaboración y forum tecnológico.

Hubo un momento en el que Brian Marick hizo que la sala se pusiera de pie para bailar unos pasos de tango, intentando demostrar con ello que para realizar un trabajo en equipo, o en pareja, lo importante es saber reaccionar ante los cambios de tu pareja.  El liderazgo cambia, y hay que adaptarse y continuar, no pararse a razonar o discutir.

Las charlas continuaron después al ritmo del día anterior.  La primera a la que asistí fue sobre un caso práctico de teamwork: un análisis del trabajo llevado a cabo por dos grupos en una empresa noruega.  Se expusieron las características y metodologías de los dos equipos (del norte y sur de Noruega).  Poco a poco se van observando diferencias de trabajo y de comportamiento que llevan a los equipos a diferentes situaciones: mientras la zona sur funcionaba correctamente, la zona norte iba cada vez peor.  Los problemas indicados fueron:

• Los miembros escogen tareas pequeñas no prioritarias -> el trabajo de verdad no se realiza, pero el equipo se queja de estar saturado.
• El backlog se llena.
• La motivación baja en cada iteración

Puntos interesantes:

• Se observó que el equipo del norte realizaba las stand ups en tan solo dos minutos.  Las reuniones de retrospectiva trataban exclusivamente asuntos técnicos.  No había intercambio de información relativo al equipo humano.  Sin embargo en el equipo sur, las reuniones se realizaban con normalidad y se discutían asuntos sobre organización, se expresaban opiniones y las stand ups duraban un poco más.
• El equipo de desarrolladores de la zona Norte no tomaba café (!).  La explicación la encontraron al analizar el plano de la oficina.  Resulta que la zona de cafetería era colindante al área de soporte.  El equipo de desarrolladores no usaba la cafetería para así evitar entablar contacto con el equipo de soporte.  En resumen, un equipo de trabajo sin feedback.

Como conclusiones al estudio, el equipo del norte perdió la comunicación con el resto de la organización, la motivación era muy baja y al final la planificación (basada en Kanban) no tenía sentido.

Siguiendo los problemas derivados de una mala interpretación de las metodologías ágiles me metí a la siguiente charla sobre Scrum Zombies.  El scrum zombie se define como aquel miembro del equipo ágil que no “respira” sino que sólo sigue las normas.  Una persona que sólo comunica tareas hechas y por hacer, pero no expresa sus impresiones personales o sus dificultades, no está vivo, hablando en el contexto del equipo de trabajo.

Me gustó mucho este consejo para las reuniones: Hay que ir más allá de las tres preguntas en las stand ups.  Muestra tu trabajo, exprésate!

La metodología ágil consiste en obtener compromisos entre las dos partes: desarrollador y cliente.  Así que como mister de un equipo hay que conseguir el compromiso de cada uno de los miembros del equipo, si es necesario haciendo que firmen la iteración.  No es mal consejo, pero no es para todas las situaciones.

Otros consejos últiles:

1. Consigue que las tareas se discutan en abierto
2. No aceptes tareas grandes
3. Usa la última reunión de iteración para preparar la retrospectiva
4. Céntrate en lo que se ha hecho
5. Publica los resultados de la retrospectiva en la pared.  Que se vea.

Como conclusión final, me recordó mucho a la Paradoja de Zenón: Si te marcas como objetivo una meta que se mueve, nunca alcanzarás tu objetivo.  Para resolverlo, tienes que establecer un objetivo más allá de la meta actual.  Tienes que mirar más allá y mantener tu atención centrada allí.  Si no, nunca llegarás.

Las charlas siguientes trataron sobre historias de usuario. Definición de Listo y Definición de Acabado

Definición de Listo

Cómo podemos saber si una tarea está lista para empezar a trabajar en ella?  En métodos tradicionales, cuando un requisito llega a un programador, éste está “claramente” definido.  En metodologías ágiles no ocurre así y se trabaja con historias más abiertas, que hay que desgranar.  Entonces cómo saber si una tarea/historia está lista para entrar en el backlog?  Básicamente cuando el equipo sabe que se puede empezar a trabajar en ella.  Esto es curioso, porque:

• No necesita estar al 100% definida
• Sólo necesita estar definida lo suficiente como para saber que podrá ser realizada en el tiempo acordado -> estimación en equipo.

Así que, qué debe contener un backlog durante un sprint o iteración?

• Un backlog completamente priorizado
• El backlog contiene todos los bugs, historias, trabajo oculto, y tareas de mantenimiento asociadas
• Todas las user histories cumplen esta definición

Definición de Acabado

La definición de acabado está asociada a todo aquello que se entrega al product owner al finalizar la tarea.  Esto puede incluir documentación, empaquetado, limpieza, etc.  Todo aquello que hace falta para que un producto sea “distribuible”.

Si la definición no está clara, será dificil estimar, medir la velocidad, y los límites de trabajo (WIP Limits), y el cliente tendrá dudas sobre el trabajo.  El trabajo de validación debe tener una lista (más o menos estática) de cosas a auditar  para verificar si una tarea está lista.

Por último en este lote de charlas, me gustó la ponencia de Ken Power sobre una técnica llamada “Agrupación  Silenciosa de Historias”, en la que se realizó un role playing game en el que un grupo de trabajo estima el tamaño de una serie de animales sin mediar palabra entre ellos.

Partiendo del punto de escoger un primer animal y estimar su tamaño, el resto de animales se pueden categorizar fácilmente.  Cada miembro del equipo realiza una estimación, sin hablar con nadie más, y pasa el turno.  Después, todos juntos ante la primera fase de la estimación, y sin hablar, realizan cambios hasta que no se observan más cambios.  Se midió el tiempo en el que un equipo de 7 personas estimaban más de 30 animales usando esta técnica: 5 minutos en total.

A mi me gustó esta técnica.  Resuelve los problemas de discusión en equipos de trabajo, en el que la persona más carismática suele copar la mayor parte del tiempo de la reunión.

Durante la comida nos volvimos a juntar Rafael, Juan, Manuel y yo para charlar sobre las ponencias y compartir información.  Buffet de ensaladas y segundos platos.  Buena comida, buen ambiente y buena compañía.  A destacar los aguacates rellenos de gambas y el lacón que completé con piña.

¿Os acordáis que dije que hablaría más adelante sobre Rafael?  Pues bien, exponía por la tarde una ponencia muy valiente, que hablaba acerca de las bases de las metodologías ágiles, libertad, autoorganización, compromiso, velocidad.  Ver el manifiesto ágil (http://es.wikipedia.org/wiki/Manifiesto_%C3%A1gil)

Emparejando muy acertadamente estos principios con los principios filosóficos de la naturaleza humana definida por Humbolt (“Libertad y diversidad son precondiciones para la autorealización”) y las bases de la implantación del socialismo (“los errores cometidos durante los movimientos revolucionarios son infinitamente más frutíferos que la infalibilidad del comité central más inteligente” – Rosa Luxemburg, “Socialismo no puede ser impuesto por decreto, es un proceso de adopción empírico” – Salvador Allende), estableció la revolución que están acometiendo las empresas en su seno.  No se debe consentir ser esclavo en una sociedad moderna, en una sociedad global basada en la información.  Ya digo que la charla fue valiente.  La ponencia está en esta URL:

http://es.scribd.com/doc/54369597/Lightning-ScrumEssenciaHumanaNovoSocialismo-English-XP-Conf

Antes de esta charla, Angel Medinillas habló con su estilo directo, ameno e impactante, habló sobre cómo el sistema “Command & Control” mata la auto-organización y la motivación por la falta de confianza en tu equipo de trabajo.  Para solventar el problema, establece un plan en 12 pasos para salir de la “adicción” a controlar el trabajo de otros.  Divertida: http://www.slideshare.net/proyectalis/110501-xp2011-treat-them-like-addicts

Y por último estuve merodeando un poco por el OpenSpace, un área abierta, un foro romano, o un ágora griega donde la gente anunciaba un tema y a qué hora se iba a hablar.  Al final me quedé a una ponencia sobre acceptance testing y contract testing, que se basa en establecer tests por capas de interacción, ahorrando el número de tests que hay que realizar.

Con esto terminó mi asistencia a las charlas XP2011.  Viniendo desde un entorno diferente como son la seguridad informática, el soporte y la implantación de productos, esta metodología me recuerda cada vez más a lo que en entornos de help desk y soporte basado en niveles se lleva haciendo muchos años.  Quizás me anime a dar una charla sobre ello algún día.

Hoy ha sido un día muy largo y lleno de ponencias en el que he visto algunos defectos en la organización.  No por falta de previsión ni por falta de recursos, o de organización, sino porque los ponentes “estrella” no han tenido tiempo para exponer su presentación en condiciones, y la culpa ha sido de los teloneros, que se han tomado demasiado tiempo para las suyas.  Que ni eran tan interesantes ni han aportado tanto como las que venían detrás.

Por la mañana me metí en la sala de las charlas asociadas a metodologías, en las que Giulio Concas habló de una simulación realizada de forma matemática que demuestra que el diseño ágil es más rápido y controlado que el tradicional de cascada.  También hizo notar que Kanban es más efectivo que Scrum.  Fue divertido ver un enfoque orientado a dar respuestas en forma de gráficos y tablas.  Pero rápidamente se vio que todo estaba basado en un modelo teórico.

La siguiente charla fue sobre Function Points Analysis en Agile Projects, de un equipo brasileño.  La idea que subyace es cómo facturar correctamente un proyecto ágil, y este análisis aplica un enfoque basado en puntos de complejidad funcional, no funcional y de entorno que, ponderados a través de la experiencia, te da una fórmula mágica para realizar el cálculo.  No quedó muy claro, pero si es cierto que David Anderson puso muchas expectativas en cómo estaban trabajando los equipos brasileños en proyectos ágiles, y a esta ponencia le faltó un mejor ponente, que se dejó la fuente de alimentación en alguna parte y a mitad de la charla se le apagó el portátil, (ejem!).

A continuación fui a la charlas sobre Team Learning, en las cuales tenía interés por conocer a Patrick Kua (http://www.thekua.com/atwork/), el cual me ha llamado la atención por su exposición sobre los niveles de aprendizaje y qué se debe hacer en cada uno de ellos.  Pero antes había otra charla, sobre la implantación de proyectos ágiles en la BBC a nivel mundial.  Esta conferencia, sinceramente me defraudó.  Me interesaba ver datos prácticos, problemas y fases de resolución de los mismos, no una charla más sobre lo bonito y fácil que resultó todo el proceso.  Además sin datos, puesto que el caso de estudio tiene prevista fecha de publicación “Febrero 2012″.  Se tomó mucho tiempo para exponerla y fue bastante aburrida.

Patrick comenzó como digo falto de tiempo, y habló rápidamente sobre niveles de conocimiento y cómo aprender usando el método Dreyfuss (http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition).  Fue una conferencia muy rápida y amena, en la que destacaría básicamente lo siguiente:

Existe un camino a recorrer en el aprendizaje que se puede expresar como niveles: novato, principiante avanzado, competente, perito y experto.

En cada estado, tienes unas habilidades y una necesidades de aprendizaje específicas.

El camino no tiene porqué ser recorrido en su totalidad, puedes quedarte en un nivel (conductor habitual) o avanzar (en entrenamientos más específicos hasta llegar a nivel de competición).  Cualquiera de ellos está bien, pero debes saber qué necesitarías para pasar de un nivel al siguiente.  Este punto hay muchos managers que no lo suelen pillar, ¿verdad campeón? megaexperto en… (¿os suenan estos términos?)

No hubo mucho que se pudiera preguntar a Patrick, dado que apenas tuvo tiempo para explicar claramente los términos.  Lo cual fue una lástima porque habría sido interesante haber podido preguntar cómo enseñar una metodología a todo un equipo y medir los estados de aprendizaje de los miembros, para poder saber si se está implantando correctamente o no el método.

Para terminar esta ronda de charlas rápidas sobre Learning, vino Olaf (“Dude”) Lewitz, que se levantó del suelo en el pasillo donde repasaba su charla y la expuso tan tranquilamente como si nada.  Su tema: “An amazing dinner needs a cookbook, a chef and a kitchen” (http://hhgttg.de/blog/2011/05/11/a-cookbook-is-not-enough/) trataba principalmente de reanalizar el flujo de la información de un proyecto agil para realimentar el conocimiento de la empresa.  Un tema que me interesa mucho, la Gestión del Conocimiento.  Lo importante fueron las palabras con las que inició la charla: “¿Cuántos de vosotros guardáis la documentación en un servidor de ficheros donde nadie consulta nada?”

Los proyectos ágiles demandan mucha información, y ésta debe ser extraída muchas veces del conocimiento, archivado, de la organización. También se necesitan herramientas, infraestructuras, y alguien que sepa realizar un buen trabajo.

La información debe ser analizada y se deben recopilar los ejemplos buenos y los malos, y utilizarlos para rellenar la cultura de la organización y hacerla funcionar.

Después ya vino la comida, pero antes unas cervezas enfrente de la Monumental de las Ventas entre los que nos hemos ido juntando en estas jornadas: Juan, Rafael, Manuel y yo.  De comida buffet otra vez, con alguna variación, como ternera asada y cortada en tiras finitas, y unos canapes dulces de postre que no llegué a probar, pero que tenían una pinta tremenda

A la vuelta, me fui a la charlas de Kanban, pero entre que estaba hasta arriba y que lo que llevaba visto era muy similar a lo visto ayer, decidí cambiar a algo más visual, más práctico.  Asistí a la charlas de Marcus Ahnve sobre Behaviour Driven Javascript, que expuso la utilización de unos framework en Javascript para probar la navegación entre botones de una aplicación web y a la cual fui pensando que vería más la parte de Behaviour Testing pero fue muy escueto y se centró en realizar una demo.

Después decidí tomar un respiro y fui a la charla de Angel Medinilla (@angel_m) sobre Scrumban.  Creo que fue lo mejor del día.  Una charla rápida, concisa sobre los puntos en común y las diferencias entre Scrum y Kanban.

Aquí pongo la charla que dió, no sabría con qué parte quedarme, ya que me ha parecido que es de obligada lectura de arriba a abajo.  La charla hizo incapié en el realismo con el que hay que usar las metodologías y las concesiones que hay que hacer.

Y con todo esto, lo dejé por hoy.  Me sentía exhausto.  El formato de las charlas rápidas no me ha gustado.  He tomado muchos apuntes que a ver si tengo tiempo de poner en limpio y subirlos.

Veamos que contiene:

• tarjeta identificativa con los tickets de comida (guay!)
• 2 camisetas (gracias Paradigma Tecnológico)
• diploma acreditativo
• flyers varios de productos
• marca páginas con los shortcuts de eclipse y vi (gracias Autentia)
• 2 sets de cartas para el planning game (gracias Autentia y Microsoft)
• el libro de ponencias
• un mini boligrafo  (gracias Microsoft Azure Division)
• un pendrive de 4GB (gracias IBM)
• y una libreta estilo Moleskine (gracias Autentia)

Les pido una guía de ponencias y salas y ¡sorpresa! tienen.

Para comenzar, me meto en el workshop que dan sobre “Making feedback work in your teams” de Mark Needham (@markneedham) en equipos de trabajo (en inglés) y aunque me cuesta entender al ponente, al final termino participando exponiendo los problemas que puede tener un team leader ante la situación de que nadie quiera reconocer un error.  He hablado un poco con él y le he preguntado un par de cosas relativas a cómo abordar una ronda de reuniones con todas las personas de la organización para obtener feedback y también cómo mantener el flujo de información y la confianza una vez establecida.  Me ha recomendado el siguiente libro para que le eche un vistazo: “Discussing the undiscussable”.

El workshop termina temprano y nos vamos a tomar café.  Aquí ya coincido con un brasileño que anda tan perdido como yo, ya que se ha venido a la conferencia y  de vacaciones por España.  Ya os hablaré un poco más sobre él.

En el coffee break nos tomamos café (bueno), pastas (muchas y buenas), y zumo de naranja (regular).  Si, como veréis, voy a hablar de comida, porque es indispensable para aguantar varios días de charlas.

Después del coffee break y en vista de que el workshop había terminado, me voy a la charla de “Self-Organizing Agile Teams: Beyond the Buzzword” de Rashina Hoda y Esther Derby, pero está hasta arriba, así que miro en la de “Agile Software Development with Distributed Teams”, de Jutta Eckstein (http://www.jeckstein.com/) dado que posiblemente tengamos que implementar canales de comunicación con gente que no esté físicamente en la oficina o simplemente para facilitar el teletrabajo.  Esta conferencia me ha gustado mucho por los múltiples ejemplos que ha puesto la ponente y también por que ha tenido el apoyo de los asistentes para aportar ejemplos y opiniones.  Revisaré más adelante la ponencia para ver si hace referencia a las soluciones de las que se hablaban en equipos repartidos por distintas zonas horarias.

Puntos con los que me he quedado de esta reunión:

• La confianza está asociada a la proximidad, sin ella está casi demostrado que la confianza se mantiene entre 8-12 semanas.
• Es más difícil restablecer un vínculo de confianza que establecerlo por primera vez.
• Las diferencias culturales existen, pero hay que salvarlas centrándose en las similitudes.
• Un equipo necesita:

1. una visión común, unas reglas y unos valores compartidos, ya sea centralizado o distribuido
2. respeto mútuo y confianza

• Importancia de las retrospectivas en un equipo distribuido: redefinir las reglas y los valores comunes.  Reforzar la historia conjunta.
• División de la retrospectiva en equipos distribuidos: locales, virtuales, entre equipos y entre sedes.  Importancia del facilitador de la comunicación.

Y por último, mi favorito.  Está demostrado: las iteraciones, de dos semanas.  Resulta que es la duración ideal que hace balance entre garantizar la entrega de funcionalidades  y mantener un  bajo nivel de riesgo en el proyecto.

Sobre la comida, buffet libre para todo tipo de menus.  Nos sentamos a la mesa el brasileño, Rafael Viveiros (@rviveiros) y yo para charlar sobre la situación de los países y la complejidad de España.  También hablamos sobre metodologías ágiles y su experiencia en Brasil.  Me monté un par de primeros platos, consistentes en verduras frías y asadas, seguido de una paella y de postre unas natillas (o custard, que nos costó encontrar la traducción a inglés y eso que volvimos loca a una chica del catering, por cierto, muchas gracias).

Por la tarde comenzó la charla más larga de todas, “Getting started & leading a Kanban initiative”, de David J. Anderson (http://www.agilemanagement.net/) que nos habló de cómo afrontar un proyecto usando Kanban y cómo mejora la eficiencia y satisfacción mostrando métricas cuantificables generadas de sus proyectos y estableciendo SLA’s en base al conocimiento obtenido.  Muy revelador.  Ejemplo: un proyecto de 155 días usando metodologías más tradicionales, podía rebajarse a 25 días, garantizando la satisfacción del cliente haciéndole partícipe del proceso de creación y estimación de los requisitos.  ¿Locura?

De esta charla saqué tres páginas de apuntes, y varias fotos que publiqué en mi twitter (@jmoratilla) de distintos modelos de tableros Kanban.  Esto ayudará a la mejora de nuestro tablero y del uso que hagamos de tarjetas (la mayoría usa post-it de colores y actualizan la información en el mismo pegando otros post-it encima).  Con lo que me quedo es con lo siguiente:

Kanban ayuda a definir:

• tipos de items de trabajo (Change Requests, Requisitos o Epics o User stories) en base a: origen, destino y workflow ( a nivel de equipo de trabajo ) asociado.
• estados del workflow = columnas del tablero
• clases de servicio => ayuda a establecer contratos de nivel de servicio (SLA’s)
• cadencia en entrada (en el backlog) y salida (delivered features)
• métricas y generación de informes => ayudas al feedback.

Una idea con la que me quedo: “Definir el requisito con el cliente, delegarle la estimación al cliente”.  Afirma que las estimaciones realizadas de esta forma aciertan más de un 95% de las veces.

Se habló bastante sobre los límites del Trabajo En Progreso (WIP Limits), y las conclusiones fueron estas:

• Límites bajos son mejores, aunque el límite puede variar en base a la política de la organización y la experiencia empírica.  Valores más comunes: 2, 3, 4.  No más de 5.
• Comenzar siempre por una historia por persona.  Incrementar en base a las necesidades por proyecto y la capacidad demostrada del equipo.

Y al finalizar la charla, me quedé hablando con Miguel Miranda sobre herramientas de Análisis estático de código (parece interesante para temas de Q&A.  Un ejemplo sería KlocWork) y conociendo a gente como Roberto Canales (@rcanalesmora) que me ha dado algún consejo que otro que seguramente ponga en marcha desde ya (a ver dónde dejé el libro del “Arte de la guerra”…)

Al final del día he acabado con la cabeza llena de ideas, algunos cambios que podríamos comentar después de la reunión de cierre de iteración y ganas de tumbarme en un sofá con los pies en alto y degustar una cerveza al más puro estilo perl.

abstra·cc nace a partir de la necesidad de tomar un enfoque distinto para buscar la respuesta. No es cuestión de desarrollar bajo las premisas de una obra de arte o de un proyecto de ingeniería. Se trata de crear productos que cubran las necesidades del usuario final de la forma más intuitiva, optimizada y amigable.

Creemos firmemente en que, para conseguirlo, debemos proporcionar un entorno de trabajo adecuado. abstra·cc es una empresa developer-centric: el desarrollador es nuestro mayor activo. No es un recurso imputable por horas, ni una variable cuyo incremento acorta el plazo de entrega.

Maximizar productividad y calidad es un desafío que la gestión de proyectos tradicional aborda de una manera torpe. Somos fervientes conversos a las metodologías del Desarrollo Ágil. Pero tampoco dejamos de lado el análisis arquitectural y un control estricto del cumplimiento de nuestros objetivos.

Calidad e innovación son el foco de atención de nuestro trabajo, desde la primera línea hasta el soporte.