11º Encuentro Agile-Madrid. Definition of Done (Pruebas de aceptación automatizadas)

Entre todos los asistentes a la reunión hemos creado un resumen en el sitio google del grupo. Leedlo antes de continuar :D

Dado que el resumen ya está hecho, voy a escribir un poco qué supuso para mi la reunión.

Preparativos
En un principio, mi labor para esta reunión era preparar un ejemplo de automatización de pruebas de aceptación en FitNesse y presentarlo (Tengo que decir que, aunque conocía FitNesse, nunca lo había usado y, esta reunión me ha servido para aprender un poco de que va ese rollo :D Me ha gustado bastante y puede que para la próxima iteración del blog escriba un "How To" sobre FitNesse).
Unos días antes de la reunión, José Manuel Beas me dijo que no iba a poder ir y me pidió que me encargarse yo de la charla. Me cedió tanto la presentación como el ejemplo de Concordion que iba a presentar.
No estoy acostumbrado a hablar en público y soy bastante tímido, así que me puse un poco nervioso. Aún así, el tema era muy chulo y me apetecía hablar de él, por lo que acepté :)

El encuentro
Acudimos unas 20 personas, entre las que había bastantes caras nuevas (lo que aumentó el miedo escénico :D). No se lo que piensan los demás, pero para mi la reunión fue bastante entretenida (Me sentí bastante cómodo mientras casi improvisaba la presentación) y la gente debatió bastante. Como ya he dicho, el resumen podéis leerlo en el sitio del grupo, pero os apunto las conclusiones a las que llegamos por si sois un poco vagos :P

• Las pruebas de aceptación deben comprobar las reglas de negocio (Qué y no cómo).
• Las pruebas de aceptación deben producirse mediante la colaboración de cliente y equipo (Negocio y desarrollo juntos).
• Es deseable que las pruebas de aceptación se escriban antes que el desarrollo, ya que ayuda a focalizar dicho desarrollo.
• Utilizar un framework que ayude a automatizar las pruebas de aceptación es deseable.
• Entre Concordion y FitNesse no sabemos con cual quedarnos. Ambos tienen aspectos positivos y negativos. Probadlos y decidid :D

Futuro
El haber dado esta charla me ha enseñado que no es tan duro hablar delante de la gente. Te puede salir mejor o peor, pero lo importante es compartir. La verdad es que me he animado bastante y creo que voy a proponer alguna charla más e, incluso, algún taller (A ver si hablo con Alfredo Casado y organizamos algo de TDD, que ya me lo ha dicho un par de veces. José Manuel Beas quiere montar uno sobre Concordion y creo que estaría muy bien).
Además, después de haber entrado un poco más a fondo en las pruebas de aceptación, queremos empezar a utilizar algún framework para automatizar las pruebas de aceptación en mi trabajo. Yo me decanto por FitNesse, que me parece más sencillo de cara a un usuario no técnico, pero algún que otro compañero prefiere Concordion. ¿Que haremos? De momento creo que vamos a probar FitNesse porque me voy a encargar yo de hacer esas pruebas :D Ya os contaré nuestros avances y nuestros problemas.

Animaos y venir a las reuniones, a los coding-dojos, a los talleres, etc. Son gratis y de verdad que merecen la pena.

10º Encuentro Agile-Madrid. Principios Ágiles

El pasado día 1 de diciembre tuvo lugar el 10º encuentro del grupo madrileño de Agile-Spain en las instalaciones de IPSA (me tocó hacer de anfitrión/portero :D ).

El tema de la reunión era "Los Principios Ágiles detrás del Manifiesto Ágil". Parece ser que el tema interesaba porque acudimos 12 personas, entre las cuales había varias caras nuevas (Mola que siga entrando gente nueva). Personalmente me interesaba bastante conocer que pensaba el grupo sobre los principios ágiles y si sus opiniones coincidían con las mías (las cuales podéis leer en mi serie de post sobre Principios Ágiles).

Como ya os dije en el post sobre el 9º encuentro, hemos cambiado el formato de las charlas y ahora comenzamos con una pequeña presentación introductoria. Esta vez, el encargado de hacer dicha presentación era José Manuel Beas y su presentación podéis verla aquí (Esta vez no hay vídeo de la charla porque el ordenador encargado de realizar la grabación se quedó sin espacio en disco :D La próxima vez ya no nos pasa).

Tras la introducción comenzó un debate del que salieron algunas preguntas y respuestas interesantes:

• ¿Son los principios ágiles de obligado cumplimiento para ser ágil? Obviamente sí, pero siempre teniendo en cuenta que son principios, es decir, guías. Para ser ágil es necesario practicarlos, pero más importante es entenderlos.
• ¿Cómo introducir los principios en la empresa? Dado que los principios representan un cambio de mentalidad, es importante practicar con el ejemplo. Además, un enfoque "de abajo a arriba" (bottom-up) parece más sencillo que "de arriba a abajo" (top-down).
• Los principios hacen hincapié en la autogestión (Principio #11). Esto puede provocar rechazo en la empresa porque saca a relucir puestos innecesarios y obliga a la gente a redefinir su trabajo.
• ¿Es necesaria una jerarquía en la empresa? Aquí hubo bastante discordia. Aparecieron dos bandos, "Sí hay autogestión mi jerarquía puede ser plana" y "Es necesaria una jerarquía que saque a la gente de la zona cómoda (comfort zone)". Yo, personalmente, soy partidario de la primera opinión. Los principios ágiles también piden autoexigencia y responsabilidad (Principio #9) por lo que de la "comfort zone" sales tú solito. Además, creemos en las jerarquías porque las empresas que conocemos funcionan (o no) así, pero ¿Que harías si montaras tu propia empresa? Quizás un modelo ágil más plano te funcione mejor. Aún así, en este punto no hubo acuerdo.

Una vez finalizado el debate sacamos unas pequeñas conclusiones:

• Los principios ágiles marcan el camino, pero dicho camino es duro y difícil de recorrer.
• Hay que creer (sin llegar al fanatismo). Es muy importante ser apasionado para conseguir convencer a otros.
• La confianza hay que ganársela. Además, es muy fácil perderla por lo que hay que esforzarse en mantenerla.
• Hay que invertir la polaridad en las relaciones de confianza, es decir, hay que empezar a confiar en la gente. Si no confías en la gente no esperes que la gente confíe en ti.
• Hay que ser exigentes con el cliente. No se puede renunciar a los principios ágiles porque el cliente no los comparta.
• Cuando hablamos de agilismo, a veces se nos olvida que negocio y tecnología deben ir de la mano, ser uno (Principio #4).
• La confianza es fundamental en el mundo ágil. Para conseguirla es necesaria la transparencia.
• Para ser ágil debes ser autoexigente y tener coraje y confianza(en ti mismo y en los demás).

Esto fue todo. Bueno, miento un poco. También hicimos una retrospectiva en la que nos comprometimos a:

• Tener una agenda para las próximas reuniones.
• Elegir los temas de forma que haya dos reuniones "teóricas" y un taller.
• Grabar en vídeo las reuniones.
• Crear un taller de ATDD. La propuesta la hizo Agustín Yagüe y, aunque quedamos en hacerlo fuera de las reuniones, nos pareció una muy buena idea.

Si os interesa, la próxima reunión será el día 19 de Enero de 2010 y el tema a tratar será "Definition of Done (Pruebas de Aceptación Automatizadas)". La charla la llevaremos a cabo Jose Manuel Beas (se encargará de hablar de pruebas en Concordion) y yo (hablaré de pruebas en Fitnesse), así que, os esperamos en la siguiente reunión del grupo.

9º Encuentro Agile-Madrid. Kanban

Ayer se celebró la 9ª reunión del grupo local de Madrid en las oficinas de 11870.com. El tema de la reunión era Kanban, un tema que, particularmente, me resultaba muy interesante (en mi empresa soy "Kanban-master" de un equipo). A la llamada acudimos 10 caras conocidas (todos eramos "habituales" de las reuniones, aunque yo falté a las dos últimas...) dispuestos a aprender y compartir experiencias.

La reunión comenzó con una charla de Agustín Yagüe sobre los fundamentos de Kanban (Aquí tenéis la página de la reunión. Están las transparencias de la presentación y las lecturas recomendadas. De estas, yo recomiendo ésta. Muy buen artículo. Además, José Manuel Beas ha colgado el vídeo de la presentación aquí). Normalmente no empezamos así las reuniones pero la verdad es que estuvo bien comenzar con una pequeña introducción sobre el tema porque nos hizo adoptar un vocabulario común (el expresado en la presentación). Además, la gente que no conocía Kanban pudo entender por lo menos de que se iba a discutir en la reunión.

Después de la presentación, Agustín preparó un pequeño ejercicio práctico en el que los asistentes simulábamos un proceso guiado mediante Kanban. La verdad es que fue muy divertido y bastante instructivo.

Lo que me llevo sobre Kanban de la reunión es lo siguiente:

• Kanban es un sistema pull, es decir, no se hace nada hasta que te lo pida la siguiente fase (y la fase final es el cliente que demanda un producto).
• Kanban está basado en señales. En el caso del desarrollo de software esas señales son los post-it con las tareas a realizar y los movimientos de dichos post-it que, al dejar un hueco indican la posibilidad de crear algo.
• Los pilares de Kanban son limitar el trabajo en progreso (evitar la sobreproducción, es decir, no hacer más de lo que el cliente pida) y la mejora continua del proceso (cualquiera de los miembros del equipo es capaz de descubrir posibles mejoras en el proceso).
• Kanban necesita un workflow para funcionar. Dicho workflow puede ser tan simple o tan complicado como se quiera (Desde el típico ToDo-Doing-Done hasta flujos complejos).
• Kanban dice que los equipos deben ser multidisciplinares ya que, cuando una de las fases se convierte en un cuello de botella, las personas bloqueadas por dicha fase deben hacer todo lo posible por desbloquearla (Ayudando a la persona que está en dicha fase). Sin embargo, el basarse en un workflow implica cierto grado de especialidad (Tú vas a estar más tiempo en la fase a la que pertenezcas y menos en las otras, ya que en las otras solo estarás si las cosas van mal).
• Que Kanban sea capaz de modelar flujos complejos puede llevarnos a pensar en desarrollo "waterfall" con equipos específicos para cada taréa. Si bien Kanban te permite modelar un proyecto a la "waterfall" no hay que olvidar que Kanban es simplemente una herramienta y que depende del que la usa.
• Kanban, al limitar el trabajo en progreso de forma explícita evita el multi-tasking en los miembros del equipo, no como Scrum en el que es el propio equipo el que se autogestiona y decide si hace o no multi-tasking (aunque está claro que es una mala práctica hacerlo ;) ).

Lo que me llevo del nuevo formato de la reunión, ya que no pude quedarme a la retrospectiva es:

• Empezar con una introducción/presentación me parece muy buena idea, aunque quizás debería haber sido algo más corta. Ayuda a que todos los asistentes sepan de que se está hablando.
• Aunque nos vamos de hora (yo me fuí a las diez menos veinte y todavía quedaba la retro) me quedo con ganas de más :D
• Me perdí las cañas :(

Agile Open Spain 2009

El pasado 23 y 24 de octubre se celebró en la Universidad Politécnica de Madrid el primer (y esperemos que no último) Agile Open Spain. Os presento mis recuerdos de las sesiones a las que asistí.

Lean in Agile Adoption

En un principio esta charla la iba a introducir Robin Dymond, pero no pudo asistir (Creemos que se quedó sobado, pero no estamos seguros) y Xavier Quesada se encargó de reemplazarlo. Xavier Quesada es uno de los impulsores del agilismo hispanohablante y siempre es un placer poder escuchar sus opiniones.

Estuvimos hablando un poco sobre los principios Lean y su posible mapeo al desarrollo de software, aunque teníamos claro que no había que tomarlos como reglas (por algo son principios).

Lo más interesante de esta charla fue cuando Xavier nos introdujo el concepto de Value Stream Mapping y como aplicarlo en tu empresa para eliminar tiempos de espera. En próximas entradas intentaré hablar de ésto con algo más de conocimiento porque la verdad es que merece la pena.

Caminos de adopción ágil

Esta sesión la presentaban Jorge Uriarte y Angel Medinilla. Tenía muchas ganas de conocerles y la verdad es que no me defraudaron. Son dos monstruos del agilismo español.

La sesión comenzó con la identificación de problemas a la hora de implementar una metodología ágil en tu empresa. Aparecieron cuatro grandes grupos de impedimentos:

• La gerencia no apoya el cambio. La causa principal de esta falta de apoyo se debe a que no sabemos venderle a la gerencia las virtudes del cambio ágil. Debemos aprender a hablar el idioma de la gerencia si queremos que nos hagan caso.
• Los compañeros no quieren modificar su forma de trabajar. Una parte de la plantilla teme que la transparencia que aportan las metodologías ágiles muestre su poca productividad. Se planteo que, a la hora de realizar cualquier cambio, primero hay que aliarse con los emprendedores de la empresa y después convencer a la gran masa de indecisos, de forma que los intransigentes al cambio no tengan más remedio que tragar.
• Los clientes no se implican. Se habló de que al cliente había que venderle las ventajas. Un cliente no va a decir que no a entregas mensuales, no va a decir que no a un informe diario del estado del proyecto, no va a decir que no a la posibilidad de modificar el proyecto si descubre que lo que pidió no le sirve, etc.
• El proceso de implantación no funciona. La mayoría de los problemas encontrados en este grupo se referían a la fase en la que ya hemos conseguido implantar la metodología en algún equipo pero se hacía difícil escalar a toda la empresa.

Agilismo de guerrilla

Xavi Gost, para mi el crack del evento, introdujo el tema de como implantar en el agilismo (y sobre todo las prácticas de XP) en una empresa sin permiso. Fue una charla espectacular. Manipulación, engaño, sabotaje... todo tiene cabida a la hora de implantar ágil :D

Los puntos más importantes de la sesión:

• Hay que ser valiente. Si nadie hace test, empieza tú. No han despedido a nadie por hacer test pero, si te echan, además de ser unos capullos, que lo pongan en la carta de despido. Es probable que te sirva como carta de recomendación en otra empresa :D
• No hay que esperar agradecimiento. Haces XP porque te gusta y porque quieres cambiar la industria. Si tus compañeros no hacen pair programming pideles ayuda con algo, aunque sepas hacerlo. Estarán haciendo pair programming sin saberlo.
• Haz integración continua. Aunque sea monta un Hudson en tu equipo. Cuando el equipo se acostumbre a él, quitaselo. Veras como empiezan a pedir un servidor de IC :D
• Un guerrillero no debe ir de cara contra el ejercito. Es decir, se sutil. No te lances al vacío. Ve poco a poco. Conquista primero a los que están más cerca y expándete poco a poco.
• A veces, un guerrillero tiene que sabotear por el bien común. Si un proyecto es un infierno en cuanto a mantenibilidad y consumo de recursos, haz que dicho infierno sea visible para la gerencia.
• Si tus compañeros se resisten al cambio, utiliza la manipulación. Si no quieren hacer reuniones diarias invítales todos los días a un café y que te cuenten en que andan.

Fue una charla muy divertida en la que se dijeron verdades como puños.

The rise of the agile hacker (o la charla del queso)

Luismi Cavallé propuso una de las charlas más interesantes del Agile Open Spain. Nos introdujo el movimiento ARxTA. Si visitáis la página veréis que la primera frase dice algo así como:

Nosotros creemos que el manifiesto ágil está siendo simplificado, su idea se está comercializando y está perdiendo su espíritu.

Brian Marick, uno de los firmantes originales del manifiesto ágil, está impulsando este movimiento debido a la creciente comercialización de la marca "Agile". El nombre completo de este movimiento es Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism.

• Artisanal: Se refiere a que el programador es más un artesano que un ingeniero. Este concepto ya apreció en varias de las sesiones del Agile Open Spain.
• Retro-Futurism: Es cierto que las personas son más importantes que la tecnología, pero también es muy importante el uso que esas personas le dan a la tecnología a la hora de desarrollar software. Además, la tecnología es necesaria. Por ejemplo, Ron Jeffries dice "si no haces XP, olvidate de hacer SCRUM" ¿Como haces XP con FORTRAN?
• Team-Scale Anarcho-Syndicalism: Es importante la autogestión a nivel de equipo, pero ¿por qué no pensamos más allá? ¿Son necesarios los jefes? ¿Por qué no es posible una comunidad de programadores artesanos capaces de autogestionarse a la hora de repartirse el trabajo existente?

A mi esta sesión me dejo trastocado. Salí emocionado y con ganas de trabajar e impulsar el movimiento ARxTA.

Mortal Kombat y Pair Programming
La sesión comenzó con un pequeño debate sobre si XP mola o no mola. La opinión generalizada es que es útil cuando los niveles de la pareja son aprendiz-maestro pero que realmente es poderosa cuando se realiza entre pares equilibrados.

Tras la pequeña discusión comenzó el combate entre José Manuel Beas y Xavi Gost. Hicieron una sesión de Ping-Pong Programming que dio mucho que hablar sobre estilo.

Conclusiones

Para mi ha sido una de las mejores "conferencias" en las que he estado. Espero que se repita y que, como dice Xavi Gost:

Mantengamos el Open Agile como un evento por y para la comunidad[...]
mantengamos el Open Agile lo mas "puro" posible y si se pudiera
financiar de los restos de otros eventos (conferencias , cursos,
jornadas) de pago , lo ideal es que no tuviera ni sponsors

Presentación: ¿Por qué un blog?

Porque después de estar en el Agile Open Spain 2009 tengo la necesidad de seguir compartiendo.

Porque creo que es necesario aprovechar el impulso y generar contenido en español tanto sobre metodologías ágiles como sobre buenas prácticas en el desarrollo de software.

Porque quiero una comunidad activa, que comparta y aprenda.

Porque, aunque aún se que tengo mucho que aprender, creo que puedo enseñar algo de lo que ya he aprendido.

Porque me apetece.

Mi nombre es Alberto Peña y soy agilista :D