Objetivos para el 2010

David Bonilla me ha "obligado" a postear el meme de los objetivos personales para el 2010. Nunca he sido de marcarme objetivos para el nuevo año (más que nada por lo vago que soy) pero esta vez haré una excepción. Hay van:

1. Continuar aprendiendo de (y compartiendo con) la comunidad ágil española. Estoy flipándola, de verdad. Creo que estamos creando entre todos una comunidad muy activa y divertida. Espero que este nuevo año sigamos mejorándola.
   
2. Leer muuucho. Tengo pendiente varios libros "profesionales" pero estoy empezando a echar de menos a Dostoyevski, Palahniuk, James, las Bronte, etc. Jo, que pedantón ha quedado eso. Os jodéis.
   
3. Ir a esquiar. Hace como un millón de años que no voy y tengo mazo de ganas. Ya no me acuerdo como se hace así que me romperé un brazo seguro (Eso por pedante, ahora me jodo yo).
   
4. Mejorar el blog. A principios de año publicaré una entrada con mi plan secreto... Es un experimentillo, a ver que tal sale.
   
5. Aprender un nuevo lenguaje de programación. Tengo ganas de meterme con los lenguajes dinámicos, aunque también me llama mucho Scala.
6. Mejorar mi ingles. Leer, escuchar y escribir va bien pero, cada vez que intento hablarlo se me seca la boca.
7. Mudarme de piso y, con un poco de suerte, hasta de continente :D De esto no hay nada definido, pero si salen un par de cosas bien a lo mejor me toca cruzar el charco :)
8. Quemar la Xbox360 dandole caña al modern warfare 2 y a todo lo que se ponga por delante.
   

No parece muy complicado conseguirlo ¿no? ¡Feliz año nuevo!

El coding dojo de agilismo.es

Por fin tengo un ratito durante las fiestas para hablar del  coding dojo que organizó agilismo.es. Fue en Okuri Spaces y fueron ayudados por Autentia (que, ademas de encargarse de la grabación del evento, nos pusieron unas cocacolas y unas pastas muy ricas).

Como he tardado unos días en escribir esto (lo siento, las comidas y cenas navideñas me han dejado KO) algunos de los asistentes ya han escrito sobre el tema. Podéis leer la opinión de Alfredo Casado y la de David Bonilla. Coincido con ellos en todo. Fue muy divertido y os recomiendo a todos que acudáis a los eventos de este estilo que se organicen cerca vuestra. No os vais a arrepentir.

De todas formas, como soy un pesado, voy a contar como fue el evento para mi.

Presentación del problema del pomodoro
agilismo.es preparó una kata nueva para este evento. Dicha kata consistía en crear una clase que representara un reloj pomodoro que sirviera para utilizarla en la técnica del pomodoro. Nos dieron unas especificaciones y nos pidieron que hicieramos dos equipos de voluntarios para codificar el pomodoro. Hay que señalar que había que hacerlo en Java sobre eclipse y haciendo TDD. Esto frenó a muchos de los asistentes pero 9 "valientes" nos animamos a mostrar nuestro Kung-Fu (Copyright de Xavi Gost). El primer equipo comenzaría el trabajo y el segundo continuaría por donde lo dejó el primero.

Aquí podéis ver al primero de los equipos planeando la estrategía:

Imagen Robada del blog de David Bonilla ;)

Los equipos dandole caña
Mi equipo fue el primero en entrar en acción. La idea era hacer programación por parejas de forma que uno de los dos componentes de la pareja hacía un test (Piloto) y el otro codificaba lo necesario para que el test pasara (Copiloto). Cada 5 minutos el piloto desalojaba, el copiloto se convertía en piloto y otro componente del equipo entraba como copiloto. Tengo que decir que contábamos con la ventaja de tener en nuestras filas a uno de los miembros de agilismo.es, José Manuel Beas, lo que nos ayudo a comenzar algo más rápido. Conseguimos crear pomodoros y asignarles una duración, aunque nos pusieron alguna pega por utilizar un operador ternario :D

Momento Ternario, con Xavi Gost metiendo el dedo en la yaga :D

No nos fue mal hasta que llegamos a la parte complicada del ejercicio, que era la parte en la que debíamos controlar que el tiempo del pomodoro se agotaba...

Momento marrón

Nos quedamos atrancadillos y les dejamos el marrón al segundo equipo que, al menos, fue capaz de volver a tener todos los test en verde.

Segundo equipo, enmarronado

La kata ejecutada por los maestros
Después de que los equipos hiciéramos lo que pudimos (no fue mucho, la verdad). José Manuel Beas se puso a los mandos del portátil para realizar el ejercicio en modo kata mientras Xavi Gost nos comentaba las discusiones de diseño que habían ido teniendo mientras preparaban el programa. Hay que decir que Beas tardo menos de 20 minutos en realizar el ejercicio y que lo enseñaron funcionando. Doy fe :P Se que van a subir el vídeo de la kata. Cuando esté actualizaré el post con el enlace. De momento os tendréis que fiar de mi :)

Agilismo.es en plena Kata

Además del vídeo de la kata creo que también iban a colgar el vídeo del evento. Cuando lo cuelguen actualizaré el post con el enlace y podréis ver a los equipos desplegar nuestro Kung-Fu, todo amenizado con los comentarios/puyas de Xavi (menudo crack). De momento podéis echarle un ojo a las fotos que han subido los chicos de Okuri Spaces aquí (Algunas os las he mostrado en el resumen) y al vídeo-montaje que han realizado los chicos de Autentia con todos los asistentes al evento.

En fin, fue un evento muy divertido. Espero que se organicen más. Mejoraré mi Kung-Fu para la próxima :D

Para mi fue todavía más molón porque Jose Manuel Beas me regalo esto:

Yo, féliz con mi pulsera

Toma pulsera de Clean Code :D Pedazo regalo de navidad.

En cuanto a la Pomodoro-Kata, prometo darle caña y mejorarla :P A ver si consigo picar a Alfredo y la hacemos en pareja.

Libros: Agile Testing (Parte 1)

Desde que volví del Agile Open Spain he intentado practicar el agilismo de guerrilla de Xavi Gost y, de momento, he conseguido que nos compren todos estos libros ¡Yuju! Algunos ya los he leido, pero me pareció buena idea tenerlos en la oficina por si, algún día, alguien se interesa y lee alguno. De entre los que aún tengo pendientes de leer me decidí por Agile Testing de Lisa Crispin y Janet Gregory (Si no os dicen nada estos nombres os recomiendo ojear sus twitters y blogs. Además, por si hace falta vender un poco más el libro, sabed que contiene un prefacio escrito por Mike Cohn y otro escrito por Brian Marick ¡ahí es nada!). Les pedí permiso para hacer un pequeño resumen en castellano de su libro y me lo dieron, así que... ¡Allá vamos!

Para empezar, el libro está dividido en 6 partes, así que dedicaré un post (mínimo) a cada una de las partes. Este, como ya os imagináis, está dedicado a la primera :D

Parte I: Introducción
En esta primera parte se hace un resumen de las principales diferencias entre el enfoque ágil y el enfoque tradicional basado en fases (algo que deberíamos tener todos bien claro ya). También se explora la idea del equipo multidisciplinar ágil desde el punto de vista de la calidad y las pruebas. Además, se define lo que debe ser la "mentalidad ágil para testing" y que hace que un tester tenga éxito en un equipo ágil.

Capítulo 1: De todos modos, ¿Qué es testing ágil?

Para ser ágil es necesario ser un equipo, y es necesario que todo el equipo sea consciente de la importancia que tienen las pruebas para alcanzar una calidad alta. Pero, si todo el equipo está preocupado de probar el desarrollo ¿Cómo cuadra un tester en un equipo ágil? Debe ser consciente de su situación. Cuando un equipo es ágil, los programadores prueban los casos límite (mediante TDD). Dado que el tester queda libre del trabajo de grano fino, puede centrarse en otro tipo de problemas que aporten un mayor valor al cliente (Exploratory testing, usabilidad de la aplicación, etc).

En un equipo ágil los testers no se sientan a esperar el trabajo, dan un paso adelante y buscan formas de contribuir durante todo el ciclo de desarrollo. Estas contribuciones pueden ir desde la automatización de las pruebas (en la medida de lo posible) hasta opiniones en las charlas de diseño para que el código sea más sencillo de testear.

Al ser un equipo ágil la colaboración con el cliente es la norma. El tester debe beneficiarse de esa colaboración para definir los test de aceptación de cada funcionalidad. Cuando los test demuestran que un mínimo de funcionalidad está completo el equipo puede considerar la historia terminada.
El tester de un equipo ágil debe conocer tanto el negocio como la tecnología. Debe ser el "traductor" entre negocio y tecnología.

Conclusiones del capítulo 1

• Un tester ágil debe seguir el manifiesto ágil (Individuos e interacciones, software funcionando, colaboración con el cliente y respuesta al  cambio).
• El testing ágil se centra en añadir valor al negocio y en entregar la calidad que el cliente solicita, diferenciándose así del testing tradicional, centrado en cumplir unos requisitos.
• Todos los miembros del equipo es responsable de entregar software de alta calidad.
• En caso de duda, volver a los valores y principios ágiles.

Capítulo 2: Diez principios para testers ágiles

¿Que es un tester ágil? Es un tester que acepta el cambio, sabe colaborar tanto con la gente de negocio como con la gente técnica y entiende como utilizar los test para documentar los requisitos y dirigir el diseño.

Un tester ágil no debe verse a si mismo como un policía de la calidad que protege al cliente de código inadecuado. Debe estar preparado para reunir y compartir información, para trabajar con el cliente y ayudarle a expresar sus requisitos de forma adecuada para que pueda conseguir las características que necesita y para proveer el feedback sobre el progreso del proyecto a todo el mundo.
Un tester ágil, al igual que sus compañeros de equipo, disfruta adquiriendo nuevas habilidades y no se limita a resolver únicamente problemas sobre testeo. Como cualquier otro miembro del equipo ayuda a la mejora continua tanto del proyecto como de dicho equipo.
Los 10 principios que debe seguir un tester ágil son:

1. Provee feedback de forma continua. Dado que las pruebas dirigen el diseño, es importante que el tester se centre en expresar los requisitos del cliente en forma de tests y que trabaje de la mano del cliente para que cualquier cambio en los requisitos llegue de forma rápida y clara al equipo de desarrollo.
2. Entrega valor al cliente. Un tester ágil permanece centrado en la visión global del proyecto. Si una característica se vuelve demasiado compleja debe analizar si conviene realizarla completa o simplemente hacer que funcione el camino normal (dejando los casos raros para otra iteración).
3. Posibilita la comunicación cara a cara. Si hay dudas sobre una cierta funcionalidad el tester debe reunir al experto de negocio y al programador para que lo discutan. Dado que el tester entiende el negocio pero también comprende la parte técnica, puede ayudar a crear un lenguaje común entre ambos mundos.
4. Ten coraje. Cualquier miembro de un equipo ágil debe tener coraje. Además, un tester ágil lo necesita porque, al ponerse en la situación del cliente, puede tener que decirle al equipo que algo no es correcto.
5. Mantenlo simple. Debe hacer las pruebas más simples posibles que verifiquen que una funcionalidad satisface las exigencias del cliente respecto a la calidad del producto. Esto no quiere decir que la funcionalidad esté implementada y que funcione, eso se presupone. Se refiere a temas como el rendimiento, la seguridad, etc.
6. Practica mejora continua. Debe buscar nuevas formas de ayudar al equipo (herramientas de automatización, unirse a listas de correo sobre testing, mejorar en el test exploratorio, leer artículos, libros y blogs para obtener nuevas ideas, etc).
7. Responde al cambio. Mediante la automatización de las pruebas es más sencillo responder al cambio. Si todas las pruebas que realiza son manuales será imposible adaptarse a los cambios a la velocidad que exige un equipo ágil.
8. Auto-organízate. Debe compartir con el equipo los problemas que encuentre de forma que el equipo se auto-organice para solucionar dicho problema.
9. Céntrate en las personas. En un equipo ágil todos sus miembros son igual de importantes y los tester no están infravalorados. Un tester ágil sabe que está ayudando al equipo de una forma única.
10. Disfruta. Trabajar en un equipo donde todos sus miembros colaboran, donde el tester está involucrado desde el principio del proyecto hasta el fin del mismo, donde los responsables de negocio trabajan junto al equipo de desarrollo y donde todo el equipo toma la responsabilidad tanto de las pruebas como de la calidad es un bonito lugar de trabajo para un tester.

¿Cómo añade valor un tester a un equipo ágil? Se está hablando de que, en un desarrollo ágil, las pruebas dirigen el desarrollo, pero se necesitan las pruebas correctas. El tester, con su capacidad para entender tanto el negocio como el lado técnico es capaz de aportar al equipo dichas pruebas.

Conclusiones del capítulo 2

• La mentalidad de un tester ágil está centrada en el cliente, es orientada a resultados, es colaborativa y tiene muchas ganas de aprender.
• La actitud es importante y difumina las fronteras entre los roles en un equipo ágil.
• Los testers ágiles aplican los valores y principios ágiles (feedback, comunicación, simplicidad, entrega de valor, etc) para ayudar al equipo a identificar y entregar los requisitos del cliente.
• Los testers ágiles añaden valor a sus equipos y organizaciones gracias a su punto de vista único.

Principios Ágiles #3

Después del 10º encuentro del grupo de Madrid de Agile-Spain en el que charlamos sobre los principios ágiles voy a continuar con mi serie sobre dichos principios. Hoy toca el tercero de ellos:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Entregamos software frecuentemente, desde un par de semanas a un par de meses, con preferencia por los periodos más cortos posibles.

Este principio va de la mano del primero. El primer principio introduce la idea de entregas continuas de software y este tercer principio especifica un poco más como realizar dichas entregas. De forma frecuente, en iteraciones cortas, entre la semana y el mes.

¿Por qué frecuentemente?
Ya lo he hablado con anterioridad pero, en el desarrollo ágil, el feedback que aporta el cliente es muy importante tanto para llevar el proyecto a buen puerto como para mejorar el producto final. Queremos entregar software que funciona frecuentemente porque aumenta el feedback que nos aporta el cliente.

¿Por qué mejor si los periodos son lo más cortos posibles?
Porque, cuanto más pequeño sea el ciclo de desarrollo, antes le entregaremos al cliente algo que no quiere, con lo que antes nos avisará de qué es lo que realmente quiere. Ya sabéis, la movida del feedback otra vez.
Ahora bien, es fácil decirlo pero entregar software que funciona cada poco tiempo es muy difícil.

Como dice Robert C. Martin (Uncle Bob):

Takes a real man to do a one week iteration!

¡Hay que ser muy hombre para hacer iteraciones de una semana!

No es sencillo entregar software funcionando y con nuevas funcionalidades cada poco tiempo. Cuanto más corto sea el ciclo de entrega mejores deben ser nuestras prácticas de desarrollo software (¡Aupa XP!). Si, por ejemplo, tu equipo hace Scrum pero deja de lado XP es muy probable que acabe por no soportar las iteraciones cortas o, peor aún, termine entregando software que no funciona.

Conclusiones
El tercer principio ágil:

• Obliga a que se entregue software que funciona cada poco (y por poco me refiero a un mes o menos).
• Necesita acompañarse de una serie de prácticas de desarrollo (XP) para soportar las frecuentes entregas en ciclos cortos.
• Apunta que ser ágil no es sencillo. Se debe entregar software funcionando cada poco y hay que pelear por conseguirlo. Es un objetivo ambicioso, pero es necesario.

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.