AOS2012, mi visión

El pasado 22 y 23 de Junio tuvo lugar el cuarto Open Space general organizado por algunos voluntarios alrededor de la Agile-Spain. Lo que más debemos admirar y agradecer de todo esto, es que haya gente cada año, dispuesta a meterse en el follón de organizar un sarao. Bien un Open Space, o bien una conferencia a nivel nacional como la CAS. Yo solo sé mis razones por las que lo he hecho en otras ocasiones, pero intuyo que son poderosas en todas y cada una de las personas que lo hacen. Bravo por ellos. El año que viene en Canarias, el AOS2013, que ya tenía ganas el #comandomuyayo.
¿cómo fue el AOS de este año? Para mi un Open con la gente de nivel que había junta alrededor de un panel, es prácticamente imposible que salga mal. Puedes equivocarte escogiendo sesión, pero siempre puedes cambiar. Puede no salir el tema que necesitas hablar, pero siempre puedes proponerlo. Lo peor sería que la gente de alrededor no fuese interesante, y eso, en este AOS, no fue así.
Yo asistí a las siguientes sesiones, os cuento un poco cada una, por que para saber qué me gustó y qué se podía mejorar, lo podeis encontrar en el hilo del grupo de Agile-Spain, con el que intenté recabar precisamente un poco una especie de retrospectiva y poder sacar acciones más formales. Espero que sirvan a los organizadores del AOS2013.

• Kaizen + Kaikaku, esta charla de Ariel Ber y Jose Manuel Beas, intentaba mostrar los dos tipos de cambios que se pueden introducir. Podemos introducir los cambios de manera gradual, o de manera radical, rompedora. Cada tipo tiene sus beneficios y sus contras, y en general, creo que depende mucho del contexto. Particularmente, siempre me inclino más por el cambio gradual, que de tiempo a la gente a asimilar lo que se está haciendo, pero nunca se sabe...
• Core Protocols, esta charla la propuse yo y hablamos de los protocolos y compromisos del libro "Software for your head". He hablado varias veces en este blog del mismo, y pronto pondré otro post un poco más extenso sobre esta sesión, y publicaré los protocolos que tengo traducidos.
• Teatro del oprimido: Aquí pudimos ver todas las "virtudes" del modelo de empresa tóxica representados en un teatro, y pudimos hacer de espect-actores. Fue propuesta por Alan Cyment. Trabajamos un situación de dificultades laborales, muy típicas de algunas empresas en nuestro sector. En general, lo pasamos genial, y creo que se pudo entrever el potencial de esta técnica. Ahora bien, se la voy a dejar a psicólogos o especialistas, la verdad, por que me parece que puede ser brutal para situaciones de conflicto.
• Estais Condenados, con ese título, solo podía ser de Xavi Gost. Xavi es el caballero negro con antorcha intentando quemar a los campesinos que adoran al rey. Así que intenta que creemos algo nuevo, algo donde podamos sustentar un crecimiento diferente, que no dé de comer al rey sus lacayos, las organizaciones malignas. Me hubiese gustado que esta sesión hubiésemos concretado un poco más en qué se puede hacer y cómo darle forma: redes de profesionales, organizaciones ¿diferentes?, cooperativas,... 
• Agile Coaching, esta sesión la propusimos entre Ariel Ber y yo. Francamente, ninguno de los dos quedamos demasiado contento con cómo nos salió. Así que espero que a alguno de vosotros que acudisteis os sirviese de algo. Nosotros al menos, aprenderemos un poquito, y la próxima vez que colaboremos, ya tenemos dónde mejorar... ah, y lo haremos pronto ;)

Lamentablemente no pudimos quedarnos la "kuadrilla" a las cervezas del sábado, pues había que volver pronto a casa.

Me encanta volver a estos saraos y ver a mucha gente con la que comparto intereses, inquietudes, filias y fobias. Me encanta ir con amigos, evento tras evento. A los que faltaron, les echamos de menos ;)

Gracias a la organización, y por cierto, la aplicación para ver la parrilla en el móvil, simplemente genial. Ojalá la reaprovechen futuros eventos, y se vaya completando.

Metodologías Agiles y coaching

Este post tiene como raíz las conversaciones con Visi Serrano, otra emprendedora como profesional independiente, psicologa y facilitadora de procesos participativos, colaborativos y autogestionados y muchas cosas más que me sorprenden desde mi visión de ingeniero.

En las metodologías ágiles se habla mucho de la figura del Agile Coach, casi como el nirvana de la figura de un Scrum Master. El coaching aporta un valor inmenso a los que los que ayudamos en la implantación de metodologías ágiles, por su caracter enfoque de conseguir metas o habilidades personales.
En las metodologías ágiles, no es suficiente con hablar de procesos a seguir. Hay que hablar de principios y valores. Y es ahí donde el coaching más nos ayuda.
De todas maneras, siempre que me preguntan por al Agile Coaching, suelo indicar que no es realmente coaching. No el coaching que la mayor parte de las personas piensan cuando oyen esa palabra. El otro día, Tobias Mayer comentaba en Twitter:

for those who asked, Agile Mentor, Agile Guide or even Agile Sherpa are more accurate descriptors than Agile Coach, in almost all cases. https://twitter.com/#!/tobiasmayer/status/173280854108409856

   Y en general estoy de acuerdo con él. Lo que muchas veces llamamos coaching en el mundo de las metodologías ágiles, es realmente un mentoring, una guía, o simplemente una formación. Las diferencias fundamentales, 

• que el coaching trabaja con que la solución sale del coachee. Como Agile Coaches, muchas veces debemos forzar las soluciones, enseñar un camino claro.
• que el coaching no dirige, va donde el cliente quiere. Sin embargo, en el caso de un agile coach, obviamente, no se puede ir donde quieras. Si te dicen que quieren hacer waterfall, ¿les dejas? :D ¡No! 

   Y aún así, me he ido a recibir formación en coaching -un curso sobre coaching co-activo, por cierto, muy interesante. Me parece una de las herramientas más potentes para provocar el cambio en las personas. El conocimiento y las técnicas que aporta me resultan útiles para entender a los clientes, para entender a los equipos y para entender a las personas (no quiero decir que los clientes no sean personas! ;) ). El cambio cultural para una implantación de metodologías ágiles es un cambio imprescindible, y desde la perspectiva que nos proporciona el coaching, más facil de atacar y conseguir.
   A raíz de unos mensajes cruzados en Twitter, por intereses comunes -si no recuerdo mal fueron a partir de charlar sobre "Open Space Technology"- Visi Serrano y yo llevamos unas semanas preparando unos temas, donde podremos aunar la experiencia en metodologías ágiles de uno, y la experiencia en coaching y cambio organizacional de otra. Hemos visto claro que los dos campos son muy complementarios. Así que para centrarnos en la primera linea del manifiesto, una de las primeras cuestiones que deberíamos entender es como trabajar con personas, y eso es precisamente donde observo que el coaching más nos ayuda. Nos ayuda a ver las cosas desde la perspectiva de otras personas, a entenderlas y escucharlas. La creación de equipos auto-organizados siempre ha sido una especie de mito, y no es nada fácil de conseguir. El trabajo con un coach especialista en estas tareas, puede facilitar la labor de manera importante.
   Como autodenominados Agile Coach, sabemos hacia donde debemos dirigir a las personas y los equipos. Sabemos qué valores creemos, y debemos transmitirlos. Sabemos el por qué de estas metodologías y debemos cambiar nuestra parcelita del mundo. El coaching nos ayuda a que otras personas descubran y transiten ese camino más fácilmente, y nos da mejores herramientas para acompañarles.

   A raíz de las conversaciones con Visi, he visto que el coaching ontológico, y con su experiencia en trabajo de cambio en organizaciones,  podemos ofrecer las dos caras de la moneda que se complementan perfectamente. Pronto, más en sus pantallas y sus organizaciones ;)


PD: Este es el post cruzado de Visi: Psicología y Scrum: desarrollo ágil de equipos.

   

Organización ágil: de lo racional a la inspiración

En una organización ágil la cuestión que deberíamos creer es en las personas, que son capaces de hacer aquello que se proponen. Que son capaces de aprender para hacerlo. Y que tienen ganas de hacerlo.
Recientemente he leido un artículo, cuyo título es muy relevante: Knowledge workers respond to inspiration, not supervision. Y esa idea subyacente prevalece en el agilismo, en su manifiesto. Y responde a un principio básico de Lean: "Respeto a las personas".

Professionals require little direction and supervision.
What they require is protection and support.

Sin embargo, muchas veces actuamos más controlando el trabajo del resto de la organización, de nuestros subordinados, o incluso de los propios compañeros. Controlando en el sentido de querer que hagan las cosas como nosotros las haríamos. Esperando que respondan univocamente a nuestras órdenes o deseos, cuando no nos damos cuenta que es muy probable ni siquiera las hayamos expresado correctamente.
La pregunta que sale siempre tras este planteamiento es: ¿realmente podemos creer en todas las personas? Y si vemos que una persona no es capaz de seguir al resto, o boicotea al equipo, o simplemente consideramos que su rendimiento no es suficiente... ¿hasta cuando le tenemos que aguantar? La respuesta es muy sencilla... ¡depende! Intenta conocer las verdaderas motivaciones o problemas, el contexto que le mueve a comportarse de una manera u otra, y piensa primero por qué está sucediendo eso. La mayoría de las veces se le podrá poner remedio, y si no, soluciones drásticas en cuanto creas que no hay otra posibilidad. En una organización es cierto que hay una exigencia mínima, que de hecho es la que inicialmente crea el compromiso personal.
Un equipo es una pieza clave en el desarrollo de software, y las habilidades técnicas son tan importantes como las interpersonales. Tú, ¿de cual te olvidas?

Libros en castello (original) sobre agilismo

El otro día preguntaba por Twitter sobre libros, originalmente escritos en castellano, en el tema de desarrollo de software ágil. No iba la pregunta por buscar material en castellano, si no por ver la fuerza que tenemos los hispano hablantes de generación de contenido en este mundillo. De momento tengo estas referencias:

• Navegapolis: Juan Palacio tiene el primer libro que yo me compré sobre este tema. Aunque en realidad era una recopilación de sus posts, era contenido original y de gran calidad (y tenemos versión actualizada en su blog). Actualmente no lo encuentro en la web, pero dispone de otro "Flexibilidad con Scrum"
• Diseño ágil con TDD: Carlos Ble escribio este magnífico libro sobre desarrollo guiado por tests. Tuve la suerte de poder ayudarle un poquito con la revisión del mismo.
• Ingeniería de software ágil: No conocía este libro, y no lo he leido (todavía). ¿alguien que pueda decirnos algo?

Así que no tenemos mucho material, aunque supongo que se me pasa más de uno. ¿no generamos libros la comunidad hispanohablante por que somos todavía más consumidores de conocimiento/experiencia? ¿ conocéis más libros sobre metodologías/gestión ágil/Lean originalmente escritos en castellano?

Mi "elevator pitch" del agilismo

Si solo dispusiese de unos segundos para explicar los beneficios de sumarse al agilismo, diría algo parecido a esto: 

La clave con el agilismo es proporcionar el marco adecuado para que los trabajadores puedan demostrar todo su potencial. La gestión por control permite un trabajo tan bueno como lo es el que ordena y controla (o menos!). El cambio de paradigma hacia lo ágil permite multiplicar la potencialidad de los equipos al multiplicar las de sus integrantes.

 Para dejar que un equipo madure, debes permitirles fallar y que encuentren su propio camino. Las metodologías ágiles fomentan el fallo temprano, para minimizar riesgos. 

 Además, los principios ágiles fomentan la creatividad (personas sobre procesos), la búsqueda de resultados (software que funciona sobre documentación) , la mejora continua y la excelencia (responder al cambio sobre seguimiento del plan) y la orientación al cliente (colaboración sobre negociación).

Resumen AOS2011

Pues por fin pasó el #aos2011 que tantas horas de sueño me ha hecho "perder" :) Mi primera impresión es que el evento ha sido muy satisfactorio para la gran mayoría de asistentes. Como organizador, eso es lo que más tranquilo me deja. Y como propio asistente a uno de ellos, la verdad que también me fui muy contento, con el desarrollo de mis dos sesiones, con las que acudí y, por supuesto, por la gente con la que conversé.
Durante la recepción del viernes estuve un poco nervioso ante tanta gente, culpa mía, ya que debía haber preparado un poco más el guión :). Pero salvo que he aprendido que si tu hablas con la persona de la derecha, el de la derecha debería hablar con el de su izquierda, creo que fue bastante bien :o)
La gente del CEIN se portó de manera impresionante con el tema de la logística, y las instalaciones inmejorables, estuvieron siempre perfectas gracias a ellos.
Os cuento un poco las sesiones por las que pasé durante el sábado:

• Taller de retrospectivas: Mi primera sesión fue una sorpresa hasta para mi, pues algún elemento de agile-norte salio en mi nombre a presentarla el viernes. Y fue bastante votada. :) Así que después de cenar, y antes de dormir (¡la una de la mañana!), tuve que preparar brevemente lo que iba a hacer, a ¡primera hora del sábado! Se me ocurrio que podría hacer una retro sobre cómo hace la gente la retros. Yo no tenía que currar demasiado ;) y el resultado podía ser interesante.
  Intenté hacer los típicos pasos de las retros según la biblia de las retrospectivas, Agile Retrospectives, e ir usando una técnica que me gustase en cada uno de ellos, trabajando en grupo. Además, intenté dar alguna idea que les aportase un poco más de valor según mi experiencia. Espero haberlo logrado.
  La imagen muestra el diagrama de Ishikawa del más común del problema en las retros: la confianza.
  Creo que este taller en un formato de 3/4 horas puede quedar perfecto. Con una hora creo que parecí una ametralladora, pero al menos, obligue a todas las personas a fijarse una acción concreta para llevarse a casa. :)

• Seducir a las empresas: Raquel y Amalia proponían que nos planteasemos el modo que accedemos y que nos mostramos a las empresas en las fases de selección de personal. Me gustó por que salio el concepto de marca personal, y se abrió un debate interesante sobre el valor que podemos y queremos mostrar de nuestro trabajo, mucho antes que una entrevista tradicional. Se debe trabajar de manera constante tu imagen, puesto que vas a ser buscado en Google en cuanto llegues a manos del seleccionador de la empresa. ¿Has probado a "googlearte"? Ten en cuenta la imagen que transmites, pues llegará a la empresa que te entreviste.

• Talento: La tercera fue conducida por Raquel e Israel, donde debatimos de la idea de qué era el talento, si lo necesitamos en las empresas y cómo conseguirlo o retenerlo. Bajo mi punto de vista quizás abundaron un poco demasiado los tópicos, pero fue interesante. La idea que me quedó, es que la gente con talento va donde quiere, cuando quiere y como quiere. :)

Después de esas tres charlas por la mañana, la última sesión matutina me la tome de descanso y estuve charlando por los pasillos. En realidad, una de las sesiones más interesantes, hablando con Xavi Gost, GermanDZ, Teresa Oliver o D.Bonilla entre otros... 

• El equipo eres tú: Mi segunda charla volvía a sacar mi tema favorito: la construcción de equipos. Quería debatir la idea desde el punto de vista de alguien dentro del equipo, de las acciones que podía tomar una persona para llegar a mejorar y crear equipo de alto rendimiento. Raquel tiene un verdadero conocimiento de estos temas, y demostró su capacidad de análisis de las situaciones complicadas. Así que trabajamos sobre la pizarra las ideas para que funcionen los equipos de alto rendimiento, y las acciones que podía tomar una persona para dirigirse hacia ello. Confianza y un objetivo comun parecen las claves.

• Comunidades ágiles: Por último asistí a la sesión que charlamos sobre las comunidades locales. Salieron acciones concretas que podeis encontrar en los post-its :)

Así que terminamos las sesiones y pasamos a la retrospectiva. Hicimos un sencillo ejercicio, identificando lo que queríamos dejar atrás, lo que nos llevábamos, y lo que no había habido pero nos gustaría. La gente salio a comentar sus temas, y salieron ideas interesantes. Por supuesto, tratamos de fijar acciones concretas como una buena retro, y algunas cosas ya salieron. Podeis ver el acta (1, 2 y 3), con unas preciosas notas de Xavier Verges.
Intenté que salieran directamente voluntarios para el siguiente AOS, pero lo que salieron fueron dos lugares como candidatos: Zaragoza o las islas Canarias. Bonita pugna :) No les envidio en la organización, que el listón está muy alto :P
Y con esto terminamos este largo AOS2011. Agotador. Enriquecedor. Un poco sorprendente, y muy estimulante.

NOTA: Podéis encontrar mucha más información en el site de agile-spain. Y Carlos Ble grabó un podcast especial de podgramando con algunos de los protagonistas.

Eventos en zona norte:

Este mes y poco que resta hasta finales de Junio se presenta muy intenso, te invito a que te unas a cualquiera de estos eventos que tenemos por esta zona del norte, donde podremos coincidir!

• 28/Mayo: Katayuno y Merendojo, donde estaré haciendo un pequeño taller de historias de usuario (esa es la presentación en que me basaré), cortito pero intenso, ya que Luis me lo propuso. Te puedes apuntar!
• 1/Junio: Reunión habitual de la zona norte de agile-spain. Más info en el blog apuntado.
• 3/Junio: Reunión del grupo The Mêlée, al que tenía demasiado abandonado lamentablemente, y resulta que ahora vuelvo con charlita incluida :) , acompañando a Guillermo que nos hablará de control de versiones.
• 17-18 Junio: El Agile Open Spain vuelve con fuerza, tras vender en 4 horas (¡4!) las 150 entradas disponibles. Este año he vuelto a colaborar con la organización de tan magno evento, así que... ¡¡Allá nos veremos!! Quizás esteis a tiempo de apuntaros en la lista de espera si no lo habeis hecho ya.

Creo que me toca sudar la camiseta antes de las merecidas vacaciones.

Peligro, las herramientas te cambian de objetivo

Generalmente buscamos en las herramientas que empezamos a utilizar la respuesta a un problema. Tenemos una necesidad que queremos cubrir, y creemos que una determinada herramienta la cubre: necesidad de llevar el control de incidencias, necesidad de orden en el desarrollo, necesidad de comunicarnos,...

Generalmente estas herramientas acaban fagocitándonos y cambiandonos el objetivo que queríamos alcanzar con ellas. Nos olvidamos de nuestra necesidad inicial, y alimentamos al monstruo en que se convierten.

En vez de minimizar las incidencias, nos quedamos satisfechos con que estas estén en la herramienta de control. En vez de procurar aprender a desarrollar software, nos quedamos tranquilos sabiendo que seguimos los pasos de una metodología -herramienta- que nos dicen que es buena. En vez de hablar, nos comunicamos por messenger o por correo electrónico.

¿cuando ha sido la última vez que pensaste que las herramientas te dominaban?

¿Es TDD la hermana pequeña de la validación formal?

Hace un tiempo, al crear el grupo de TDD en castellano, hacía esta pregunta del título. ¿Es TDD la hermana pequeña de la validación formal? Hay un artículo del gran E. W. Dijkstra, "Sobre la crueldad de verdaderamente enseñar ciencias de la computación" que me parece muy revelador tal y como hoy entendemos la ingeniería del software, y cómo se veían las cosas hace tan solo poco más de 20 años.
Básicamente Dijkstra proponía enseñar a los estudiantes de informática, como introducción en el primer curso, la validación formal de los programas sin siquiera tocar un ordenador para programar. Bastante sorprendente.
¿podremos un día verificar formalmente que un programa hace lo que esperamos que haga, y nada más? Lo que pasa, que el principal problema no es verificar, si no CONOCER, aprender, asimilar, conceptualizar lo que tiene que hacer.
Os dejo con este video, del 2001, con una pequeña entrevista a tan interesante personalidad.

Podeis encontrar todos sus manuscritos, algunos de ellos traducidos a castellano en la universidad de Texas.

Computer science is no more about computers
than astronomy is about telescopes

E. W. Dijkstra

Siempre me ha intrigado el verdadero sentido de esa frase...

Agilismo como proceso de innovación

Siempre he tenido bastante claro que el desarrollo de software es un proceso de aprendizaje. Los desarrolladores no podemos plasmar en código aquello que no hemos aprendido de un sistema o del dominio del negocio. Ahora también lo veo como un proceso de innovación. Todo desarrollo de software es en sí mismo innovador, por que no existe antes aquello que quieres construir, teniendo cada desarrollo particularidades, que precisamente, llevan a tener que construir de nuevo por n-sima vez, un ERP.

Ser ágiles nos proporcionará un marco para la innovación, y para el aumento de la productividad en pos de la misma.

Para innovar, algunas recomendaciones pueden ser:

1. Fomentar la creatividad. La creatividad no tengo muy claro cómo fomentarla, pero sí cómo liquidarla: con un poco de "command&control". Se debe permitir a la gente equivocarse, reforzar el poder de los equipos para que sean sitios seguros.
2. Excelencia como hábito de trabajo. Debes cuidar cada detalle, huir de la mediocridad en cada cosa que haces. Si no, nunca inventarás el iOS.
3. Orientarte a resultados: La innovación debe producir algo tangible, y en estos tiempos, cuanto más rápido mejor. Mejor producir valor poco a poco, que hacerlo tarde.
4. El feedback hoy en día es fundamental. Para a analizar cómo lo estás haciendo, y reorientate de nuevo, hacia el buen camino.

Si te encajan esas cuatro recomendaciones en busca de la innovación, también verás que están algo dirigidas hacia donde me interesa: los principios ágiles. Y es que refuerzan, o se apoyan, no sé en qué orden :), en los cuatro principios básicos de todo agilista.

Hay muchos más consejos alrededor de la búsqueda de la innovación que encajan como un guante en los principios. O quizás, es que los principios son una base sólida para fomentar la innovación.

Agilismo a nivel táctico

Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

• Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.


• Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...


• Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.

Un saludo a mis colegas de Biko, que sé que me leen ;)

Equipos, equipos, equipos,... y luego ágil

El ideal de los equipos autoorganizados, es eso, casi siempre -me temo-, un ideal. En mi personal investigación sobre el tema de los equipos de alto rendimiento (¿alguna vez habeis participado en uno? - la sensación es "diferente"-) estoy trabajando en dos areas principalmente:

1) La organización de las personas como equipo. Es decir, ¿qué diferencia un grupo de personas trabajando juntas, de un equipo? En esta linea, estoy otra vez releyendo el libro "Software for your Head". Libro difícil de leer donde los haya, pero que da la impresión de esconder un tesoro oculto entre sus páginas.

Las mecánicas de un equipo de alto rendimiento ¿se pueden reproducir, inducir, insertar en cualquier grupo de personas con un objetivo común? La charla de Jim McCarthy en Agiles2008, me parece interesantísima.

Por otro lado, me pregunto si el equipo autoorganizado no es una quimera. Por ejemplo, asistí a una charla sobre "Tácticas para liderar equipos interfuncionales", dónde el ponente dijo que no puede haber equipo autoorganizados sin lider, excepto en casos dónde todos los componentes del equipo son expertos en la materia en la que trabajan. Así que esta idea refuerza la labor del ScrumMaster como lider-y coach- dentro de un equipo que utilice Scrum.

2) Elevar el nivel de las personas de cada equipo. A mayor nivel personal y técnico de cada individuo, el equipo ganará exponencialmente comunicación, colaboración, y por tanto, velocidad de desarrollo.

"Oh, you want to be an artist? A great artist?" "Yes" "That's easy! Become a great human being and then paint."

Supongo que aplica lo mismo a un gran desarrollador.

No se puede ser un gran equipo de desarrollo ágil, sin ser antes un gran equipo.

Testeo defensivo, o que disparen a ese API

A raíz de una entrada de @sergioazo y su correspondiente conversación, he recordado una técnica que leí en algún sitio para minimizar los problemas en el trabajo con librerías externas de terceros en tu proyecto.

Se puede usar para varias cuestiones:

• Comprender el funcionamiento real de una librería (no el esperado)
• Defenderte frente a cambios en el comportamiento futuro de la librería
• Documentar el uso de una librería, su API.

Se puede decir que vamos a generar test unitarios, en los que no podemos escribir el nombre del método de test hasta el final. Si hacemos TDD, el nombre del test deberá indicar que comportamiento queremos asegurar, y después programamos ese test. En este caso, podremos poner un nombre al método realmente coherente al test, cuando ya tenemos los assert ejecutando y comprobados en verde. Quizás coincida con lo esperado, o quizás no. Sugiero que se guarden los dos nombres, para comprender las diferencias encontradas, que probablemente también desconcierten al próximo programador que coja tu código que usa esa librería.

Si tenemos tests de los usos que hace nuestra aplicación de una librería, el cambio de versiones de la misma, puede ser testeado. Basta con ejecutar nuestra suite de integración, para que nos corrobore si la librería sigue funcionando tal y como esperamos.

Veamos un ejemplo. Imaginemos que tenemos un API tal que así:

public String guardaDocumento(String docType, byte[] data);

public byte[] obtenerDocumento(String docCode);

Y no tenemos más información, parece bastante obvio lo que hace, pero queremos asegurarnos, y sobre todo tener cuidados con los cambios con esa librería que se está desarrollando. Podemos hacer un test de la siguiente manera:

public void deberiaDevolverElMismoDocumentoPorCodigo(){

        Repositorio repositorio = new Repositorio();
      String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
      assertArrayEquals("Hola Mundo".getBytes(),
                  repositorio.obtenerDocumento(docCode));

  }

Pero, este test, tan simple como almacenar un documento y obtenerlo de nuevo, se queda en rojo. ¿por qué? Por que resulta que el código necesita después, no es el mismo código que devuelve

Por lo que finalmente tras unas pruebas (o un telefonazo a alguien harto de tus preguntas) llegamos a la conclusión, que el código que necesita el "obtenerDocumento" es la concatenación del tipo de documento y el código devuelto al guardarlo.

Por tanto, modificamos el test, y después modificamos el nombre del test.

/**

* was:deberiaDevolverElMismoDocumentoPorCodigo

     */
   @Test
   public void deberiaDevolverElMismoDocumentoPorTipoDocumentalYCodigo(){
      
       Repositorio repositorio = new Repositorio();
       String docCode = repositorio.guardaDocumento("tipo1", "Hola Mundo".getBytes());
       assertArrayEquals("Hola Mundo".getBytes(),
                   repositorio.obtenerDocumento("tipo1" + docCode));

}

¿conseguimos con esto los objetivos inicialmente planteados?

(nota:basado en hechos reales)

Coderetreat y TDD, en Donosti

El sabado estuve en el #coderetreat de Donosti. Contamos con la presencia de Enrique Comba, que hizo de maestro de ceremonias, planteando el problema y dándonos los pasos a seguir para las prácticas en cada iteración.

Os animo desde aquí a que os organiceis un evento de estos dónde podais, en realidad no hace falta traer a ninguna estrella, solo tener ganas de aprender un día, y de pasarlo bien.

Ha sido un día muy interesante, practicando un poco de programación, con TDD. Me he dado cuenta, primero, de que estaba muy oxidado, y segundo, de que tengo mucho que practicar para comprender en profundidad las implicaciones de TDD. Por que hacer bien TDD implica programar bien, preguntándote en cada momento por qué estás poniendo el código que estás escribiendo, y entendiendo las razones del diseño.

Lo que hicimos este día fue intentar resolver el juego de Conway. Es un problema sencillo de entender, pero con suficiente complejidad para que pueda salir un bonito diseño orientado a objetos, merezca más de una discusión trabajando el diseño desde TDD.

Las dos primeras itearaciones, que eran libres, sin "putadillas" sugeridas por Enrique, creoq ue casi todos empezamos a diseñar o un Tablero, un universo, unas celdas, etc... hubo quien diseño a un dios contemplando el juego :)

Mi principial descubrimiento es que empezabamos a hacer TDD desde un punto del problema en el que para empezar los tests habíamos tomado decisiones de diseño de modelado del problema. Sí, antes de empezar siquiera con los tests.

Esto ya me puso nervioso y en la segunda iteración, con @sharpbites propuse empezar por lo que sería el inicio, una interfaz del juego, que resolviese el asunto. Un test de aceptación, vamos, más en la linea (creo) de un enfoque BDD. Y nos atascamos, vaya si nos atascamos. ¿por qué? Por que intentábamos llegar a la solución que teníamos en la cabeza. En general, a todos nos resultaba más facil empear desde niveles inferiores de la solución, con un enfoque bottom-up.

Enrique propuso una solución que me convenció, pero que tendré que poner en práctica unas cuantas veces. Se trata de partir del test de aceptación, de la definición del problema (top-bottom), y realizar un rápido desarrollo que nos lleve a una primera solución, aunque sea grosera. Después, hacer el bottom-up e ir completando los desarrollos que falten para tener la certeza de tener suficientes casos de prueba y un buen diseño generado.

Lo que conseguimos es tener enseguida una primera versión, y después fortalecer el diseño y desarrollo con el detalle.

Definitivamente, fue un día muy aprovechado, por compartir experiencias con otra gente, y por aprender algo de cada uno de ellos. Tendremos que hacer más de estas por la Zona Norte :), no os las perdais, seguid informados en Agile-Spain.

Gracias a todos los asistentes, y a Gailen por patrocinar el evento, que pudimos comer de gorra! ;)

Apúntate a la CAS2010. Inscripciones

Resucito un rato este blog para anunciar que ya se ha abierto el plazo de inscripción de la conferencia Agile-Spain.

Se ha configurado un panel de sesiones y talleres que va a ser muy interesante. Se recibieron muchas sesiones que lamentablemente han tenido que quedar fuera, y han generado un nivel muy alto. Henrik Kniberg también ofrece un taller, pero rápido, que solo para 15 personas.

Podeis apuntaros desde aquí.

Libro de TDD en castellano

El primer libro sobre Desarrollo Guiado por las Pruebas (TDD) en castellano acaba de ver la luz. Carlos Ble junto a algunos colaboradores ha editado un libro más que recomendable para cualquiera que esté interesado en esta metodología de desarrollo, o en las metodologías ágiles en general.
Es un libro que además aporta conocimientos generales de diseño basado en objetos, o metodologías ágiles. Hace un repaso con ejemplos de cómo desarrollar con TDD, e introduce el desarrollo guiado por las pruebas de aceptación (ATDD).
Sin duda un libro que debes descargar, es de libre distribución, y estudiar con profundidad. Seguro que aún mejor si se lo compras o le haces una pequeña donación :), que merece la pena. Yo he tenido el placer de poder seguir el proceso de creación del libro como pequeño revisor, y el material creado por Carlos es muy bueno, espero impaciente su próximo libro ;)

• Diseño Ágil con TDD

Aprovecho para recordaros la existencia del grupo de TDD en castellano!

Primer Agile Open Spain: Fabuloso #agileopenspain2009!

Pues finalmente llegó el Agile Open Space, y pasó rapidisimo de lo interesante que resultó.
Después de unas semanas de ajetreo con la organización, finalmente validamos nuestras expectativas. Afluencia masiva de los inscritos, y muchísimo nivel en las charlas organizadas el sábado.
El viernes, tras los últimos detalles de preparación del evento, empezó a llegar la gente hacia las 18:00, y a las 18:30 empezó la presentación del evento. Agustín Yagüe hizo de maestro de ceremonias, ya que se celebraba en "su casa", y Jose Manuel Beas y Xabi Albaladejo dieron unos pequeños discursos de presentación de Agile-Spain y la agilidad. Creo que Jose Manuel Beas estaba realmente emocionado de ver tanta gente congregada en este evento, y no era para menos.

Así que tras las presentaciones y un pequeño piscolabis -- gracias a los patrocinadores, de los cuales Biko era uno de ellos-- , se procedio a presentar los spaces que cada uno quería hacer. Aquí fue cuando realmente respiré tranquilo, y se vio que el evento iba a funcionar: una cola de gente para presentar y finalmente más de 50 sesiones ("únicamente" había 30 slots de tiempo disponibles). Tras preparar las sesiones para el sábado en el panel, se cerró el día.
La gente de la organización nos fuimos a cenar el viernes, me encantó volver a charlar con los que un día nos juntamos hace 7 meses para mover el tema de Agile-Spain, conocer a Carlos Ble y disfrutar de una cena muy agradable, aunque fuese de trabajo! :)

El sábado empezó con el desayuno en la UPM, para tomar fuerzas mientras podías repensar las sesiones a las que asistir mirando el panel. Se habían distribuido 6 sesiones simultaneas, durante 5 franjas temporales, 3 por la mañana y 2 más retrospectiva después de comer.
Las sesiones a las que asistí fueron muy interesantes y participativas. Además se respiraba camaradería y ganas de aprender. Nos movíamos rápidamente entre el panel para tomar las últimas decisiones de asistencia y las salas de los spaces. Se compartieron muchas experiencias, conocimientos y también muchas preguntas interesantes.
Las sesiones a las que asistí fueron:

• Lean: Era una sesión propuesta por Robyn Dymond, que lamentablemente no llegó a tiempo. Pero X. Quesada condujo la sesión a buen puerto. Hablamos de los principios de Lean, y nos preguntamos cómo aplicarlos a la empresa.
• El factor humano: Daniel Lopez (creo que era su nombre) nos habló de las personas, que son las que soportan las cabezas pensantes de los desarrolladores, y hay que tenerlas en cuenta. Hizo una dinámica muy divertida, como ejemplo del castigo contra el premio como forma de motivar a las personas.
• Telefónica: Mónica Izquierdo y Carmen Lasa nos hicieron una presentación sobre la implantación de Scrum en Telefónica I+D. Muy interesante por que ciertamente va muy en paralelo con la implantación que estamos haciendo también en Biko, y charlamos un rato después durante la comida, y los problemas y retos son muy parecidos.
• Agile Coaching: Se trataba de debatir sobre las funciones de un Agile Coach, y ciertamente lo que más claro quedó, es que no estaba claro. Había varias versiones sobre lo que se suponemos que hace un coach Agile, yo creo que se perdio un poco el rumbo de la sesión por que se mezcló con la idea de un coach personal o de marca propia.
• Externalización y outsourcing: Angel Medinilla condujo una sesión para contar experiencias sobre proyectos de este tipo, sacando unas conclusiones finales.

En definitiva, una experiencia como conferencia. Podeis buscar más comentarios, fotos, etc. en la web de agile-spain. Pronto tomará forma la asociación, y ya estamos preparando nuevos eventos, así que no descansamos ;). Súbete al carro del agilismo, y únete a Agile-Spain!

Artículo en REICIS

Han publicado la revista REICIS --"Revista Española de Innovación, Calidad e Ingeniería del Software"--, y en este número me han incluido un artículo, titulado "Las metodologías ágiles como garantía de calidad del software". Espero que os guste!
Lo podeis encontrar en: http://www.ati.es/spip.php?article1328
Muchas gracias a Jose Manuel y Carlos, que me ayudaron a darle el toque final de calidad ;)

Ven al Agile Open Spain: 23 y 24 Octubre

Se va a organizar el primer evento a nivel nacional de Agile-Spain, os copio el texto que podeis encontrar en la propia web.

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

Si quieres:

• Compartir tus experiencias como experto o principiante en el uso de prácticas Ágiles.
  
• Escuchar a algunas de las personas que más saben de metodologías ágiles en España.
• Encontrar el futuro antes de que éste te encuentre a ti.

entonces, inscríbete aquí (notar que el evento es gratuito pero las plazas son limitadas).

Computación y Ajedrez

Ciertamente tengo el ajedrez bastante olvidado, y hace años -demasiados- que no juego ni una partida. Un día volveré a recuperarlo de mis aficiones, al menos para enseñarle lo básico a mi hijo. Pero el ajedrez y sus conexiones con la informática son bastante interesantes. Ya hace unos meses escuché la historia de Deep Blue de mano de uno de sus "entrenadores", Miguel Illescas, y resultó muy entretenido.
Ahora el CEIN, en Pamplona, organiza el Campeonato del Mundo de Ajedrez con Ordenadores y una Conferencia Internacional sobre Juegos y Computación -¿los ordenadores hacen deporte? :P - y lo arropa con varios eventos dignos de asistencia, os copio un extracto del anuncio en CES.

Tanto desde el BSC [¿Qué es la supercomputación? Una explicación orientada al mundo empresarial.] como desde el CESGA [Necesidades de supercomputación en la empresas españolas.] sólo nos ofrecieron facilidades para venir a contarnos a qué se dedican. Y lo mismo podemos decir de las empresas que vendrán a explicarnos cómo la aplican en su día a día.

¿Pero tan importante es el ajedrez en el campo de la computación? ¿Y realmente sirve para algo más que calcular miles, millones de variantes de una posición? La respuesta nos la dará Leontxo, el jueves 14 de mayo.
Y ya que CEIN anima el espíritu emprendedor, uno de ellos (editor, gran maestro, entrenador de un antiguo campeón mundial) nos contará cómo hay mecanismos que se aplican en las partidas de ajedrez que pueden aplicarse en un tema clave en la gestión empresarial: la toma de decisiones.

Espero veros por ahí!