5 Things I want to do today!

Two weeks ago I was in Edinburgh. I attended the Scottish Ruby Conference and it was awesome! I met a lot of great people and I enjoyed a lot of great talks. But I want to talk today about one of the lightning talks that I had the pleasure to attend. It was not about code, technology or robots, it was about how to manage your time and how to set your priorities.

The idea
The idea is very simple. Before going to sleep, you have to write down the 5 most important things you want to do tomorrow. Once you've written them down, you have to prioritize them. Then, the next day you have to do the first task in your list. Once you finish the first task, you have to start with the second task. It goes on and on until you finish the 5 tasks or the day ends :P

The reality (My reality)
I've been doing this for two weeks, so I'm not an "expert" :P but I have some conclusions to share.

First of all, I feel much more productive :D "Planning" what to do the next day helps me to focus on the important things and shows me how difficult it is to achieve everything I want to do (pretty obvious. You can't do everything you want in a day :D )

Second, it is not easy to follow your plan :D I always start with my first task, and most of the times I continue with the second one, but, eventually, I get distracted. The thing is, there are a lot of things I want to do, and limiting myself to only five is not easy. Also, some of the tasks on the list are really bored (but still important), so sometimes I just ignore them...
Some other times, I just "forget" the priorities :)

And last, but not least, is not easy to write down the five most important things you have to do the next day.

Anyway, I think that this simple method is helping me a lot, and I recommend all of you to give it a try. Even if you are not able to follow "the rules", it is a great exercise.

Continuous Delivery

Aunque parezca mentira, ya casi ha pasado un mes desde que llegué a Eden. Hoy comienza mi última semana como interno y, como todos los lunes, ya tengo mi tarea semanal. Tengo que leerme el "Continuous Delivery" y hacer un resumen durante mi presentación :) Tenía ganas de leerlo, ahora ya tengo excusa :P

Continuous delivery está escrito por Jez Humble y David Farley, ambos thoughtworkers, y el libro entra dentro de la serie firmada por Martin Fowler. Tal y como ellos cuentan al principio, el titulo lo han sacado directamente del Manifiesto Ágil, concretamente del primero de sus principios:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Lo primero que me ha venido a la cabeza cuando he empezado a leer el libro ha sido ¿por qué necesito leer este libro? Jez y David me han dado la respuesta:

Only when you have control over the progression of every change from introduction to release can you begin to optimize and improve the quality and speed of software delivery.

Solo cuando tengas el control sobre la progresión de cada cambio desde que lo introduces hasta que lo liberas, podrás empezar a optimizar y mejorar la calidad y velocidad de tus entregas de software

Aunque acabo de empezarlo y aún no he podido leer mucho, la idea central del libro es lo que ellos llaman el patrón "deployment pipeline" que, tal y como lo definen, es una implementación automatizada de las fases de build, deploy, test y release de la aplicación sobre la que se trabaja, es decir, automatizar al máximo todo el proceso a partir del commit.

El libro promete bastante, ya os iré contando. Un saludo.

PS: Hoy es el cumpleaños de Todd, felicitadle por twitter :D

Principios ágiles #6

Hace muuuucho tiempo comencé una serie de post sobre los principios ágiles que hay detrás del manifiesto ágil. No se por qué, dejé de escribir en el blog y la serie se interrumpió. Hoy, a lo Fronkonstoin, voy a devolver la serie a la vida hablando del sexto de ellos (esperemos que dure):

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

El método más eficiente y efectivo de comunicar la información a un equipo de desarrollo y entre los miembros del mismo es la conversación cara a cara.

Comunicar información
¿Por qué hay gente que oculta información, que no comparte? Quizás para hacerse indispensables (como bien dice David Bonilla en su entrada sobre cajas negras). Que no os engañen, no lo son y no lo serán. Lo único que van a conseguir es aislarse de sus colegas de profesión y perderse todas las cosas buenas que hay fuera de su cubículo. Van a quedarse obsoletos.

Como decía Newton (aunque la wikipedia dice que fue Chartres):

Si he visto más lejos es porque estoy sentado sobre los hombros de gigantes

Si es bueno para Newton (vale, Chartres. Creo que se nota que soy físico) es bueno para ti.

Hay que salir, enriquecerse. Hay que aprender a ser humilde, a compartir tus conocimientos. Hay que enseñar lo que sabes y aprender lo que no sabes. Para todo esto es necesario comunicarse. No te conviertas en una caja negra.

A un equipo de desarrollo
Como he dicho ya muchas veces en anteriores posts, es importante que el cliente esté en contacto continuo con el equipo. Que sea capaz de comunicar sus objetivos y preferencias es una parte imprescindible de dicho contacto. Esto implica un nivel de compromiso por parte del cliente en el proyecto muy alto, siendo éste uno de los problemas más comunes en los equipos ágiles (al menos en los que yo conozco). Veamos un dialogo tipo:

- Hola, ¿vosotros sois ágiles?
- ¡Sí!
- ¿Cómo habéis conseguido involucrar al cliente en el ciclo de desarrollo?
- Respuesta 1: A no, eso no lo hemos conseguido.
- Respuesta 2: Nuestro cliente es interno.

Mi experiencia personal es del segundo tipo, así que tengo suerte :P Sinceramente, no se cómo resolver el primer caso :( Lo que sí que tengo claro es que, si no consigues que tu cliente se comprometa en el proyecto vas a pasarlas canutas...

Entre un equipo de desarrollo
Está claro que un equipo de desarrollo, si es sano ,debe estar en continua comunicación. Cuando se trabaja en intervalos de tiempo cortos es necesario que todo el equipo esté sincronizado de forma que se evite el trabajo duplicado. Igualmente, es muy importante que los miembros del equipo se encuentren comodos entre si, de forma que no resulte extraño que alguien pregunte cuando no sabe algo (No hay preguntas tontas ni respuestas estupidas, ya sabéis). Básicamente, es necesario que los miembros del equipo creen relaciones de confianza que ayuden el desarrollo de su trabajo (Todos trabajamos mejor con amigos alrededor ¿no? Huy, me ha salido muy piruleta esto último...).

Conversación cara a cara
Lo más eficiente no es ni usar el teléfono, ni el e-mail, ni el wave, ni el twitter, ni el skype... lo más eficiente (y por tanto lo deseable) es la comunicación cara a cara.

Pensad en la cantidad de herramientas que propone el agilismo a los equipos para que mejoren su comunicación. Desde el ¡Sienta al equipo junto! de Henrik kniberg a las reuniones diarias de Scrum sin olvidarme de algunas de las prácticas XP como la programación en parejas. Todas ellas se basan en la comunicación cara a cara, lo que debe dar una idea de su importancia.

Conclusiones
El sexto principio ágil:

• Implica un alto nivel de compromiso en el proyecto por parte del cliente
• Necesita que se den relaciones de confianza entre los miembros del equipo (incluido el cliente)
• Señala la importancia de la relación directa entre las personas

Foto de "portada": Galería de Fernando en Picasa, bajo licencia Creative Commons.

Principios Ágiles #5

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del quinto de ellos:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Construye proyectos con profesionales motivados. Dales el entorno y soporte que necesitan, y confia en ellos para que realicen el trabajo.

Profesionales motivados
Cuando una persona encuentra un nuevo trabajo su motivación inicial es bastante alta. Si tiene experiencia previa probablemente haya conseguido un trabajo que le guste con un sueldo acorde a dicha experiencia. Estará contento y querrá demostrar que vale lo que le van a pagar. Si es un junior sin experiencia querrá aprender y prosperar en su carrera profesional. ¿Qué lleva a cualquiera de estas dos personas a desmotivarse? Pues multitud de causas. Falta de dirección (visión de empresa, visión de producto, abandono por parte de la gerencia...), mala cultura empresarial (mala relación entre compañeros, infraestructura deficiente, falta apoyo al aprendizaje), etc. Imagino que todos hemos pasado por algo así en algún momento, por desgracia.
Una vez que una persona pierde la motivación es muy complicado volver a motivarla, por lo que hay que esforzarse en evitar que ocurra.
¿Cómo se puede evitar la desmotivación?
Dan Pink lo explica muy bien en esta presentación (Si aún no la habéis visto ya estáis tardando :P)
Os escribo las conclusiones para los más vagos (aunque ya os digo que mola mogollón). Básicamente cuenta que, una vez resuelto el tema salarial (está claro que es un factor importante, pero no el único) los factores que ayudan a mantener la motivación son los siguientes:

• Autonomía. Muy en sintonía con la auto-organización de los equipos ágiles ;) Hay que confiar en que el trabajador es capaz de hacer su trabajo por si mismo.
• Maestría. Para los agilistas significa buscar la excelencia técnica (Sea lo que sea eso, que ya lo veremos en futuras entradas)
• Propósito. Contribuir a algo importante. En el caso de la agilidad sería equivalente a contribuir en la mejora del negocio del cliente. Aportar valor y tal :)

Estos tres factores ayudan a mantener la motivación de un profesional (no solo los profesionales técnicos, cualquier tipo de profesional) ya que crea un entorno en el que las personas son importantes y valiosas (Ya sabéis, personas sobre procesos...).

Crear un entorno y dar el soporte necesario
Tal y como hemos visto arriba, la cultura empresarial es muy importante a la hora de mantener la motivación.
Es necesario que la empresa proporcione un ambiente que favorezca el aprendizaje, que ayude a crecer profesionalmente a sus trabajadores, que confíe en ellos para realizar su trabajo, que les proporcione una infraestructura adecuada a sus necesidades, etc. Es decir, que se dedique a eliminar impedimentos externos del día a día para que los únicos problemas que se encuentren sus trabajadores sean los propios de su trabajo (Eliminar burocracia inútil, métricas absurdas, controles exhaustivos, etc).

Confianza
Todo lo anterior se basa en la confianza. Está claro que un buen profesional sabe hacer su trabajo. No necesita un jefe todo el día detrás suya, interrumpiéndole cada 10 minutos para preguntarle qué tal lo lleva. Ese micro-control, además de desmotivar, reduce la productividad.
Sin embargo, hay que tener claro que no todo depende de área de gestión, el empleado debe responder. Como dijo el Tío Ben :

Un gran poder conlleva una gran responsabilidad

Si queremos que nuestro trabajo mejore, que se nos trate como a verdaderos profesionales y que se confíe en nosotros, debemos responder con autentica profesionalidad. Si nuestra empresa fomenta el aprendizaje debemos aprovecharlo y mejorar. Si nuestra empresa nos permite autonomía debemos comprometernos. No podemos desaprovechar las (¿pocas?) oportunidades que se nos ofrecen.

Conclusiones
El quinto principio ágil:

• Busca fomentar la confianza
• Advierte que lo importante son las personas
• Pide que se eliminen los impedimentos externos
• Implica responsabilidad y profesionalidad

NOTA: Si os interesa más el tema de la motivación de un equipo os recomiendo el libro Peopleware. Yo aún no lo he podido leer, pero José Manuel Beas lo recomendó en la reunión que tuvimos sobre principios ágiles al hablar sobre este principio. El libro se lo dejó a Alfredo Casado, que nos ha ido contando algunas de las cosillas que ha ido leyendo. La verdad es que tiene muy buena pinta :)

Foto de "portada": Galería de Fernando en Picasa, bajo licencia Creative Commons.

Retrospectiva #2

Bueno, pues parece que hemos terminado la primera iteración del ScrumBlog :D Vamos a "retrospectivar" un rato sobre dicha iteración.

¿Por donde empezamos?
Vamos a empezar calculando la velocidad del equipo y su eficacia. Para ello vamos a basarnos en el burndown de la iteración. Podemos ver que la velocidad del equipo se corresponde a 11 puntos de historia y su eficacia es de un 100%. Estos datos nos servirán como base para la próxima planificación.

Parece que ha sido una buena iteración ¿no? Veamos que opina el equipo (Como ya hicimos en la retrospectiva anterior, vamos a hacer a basarnos en 3 preguntas para llevar la retro).

¿Qué nos ha gustado de este sprint y queremos seguir haciendo?

• El compromiso. Ha sido "duro", pero ha merecido la pena.
• Por fin hemos metido una historia técnica. No se si os habrá gustado, a mi sí :D. Me parece una idéa muy interesante, la verdad. Además, el tener una historia técnica me ha servido para iniciarme en git.

¿Qué estamos haciendo mal?

• La priorización de las historias. No puede ser que la segunda historia más prioritaria no pueda empezarse hasta un par de días antes del final de la iteración
• Aunque hemos aumentado la tasa de entradas, sigue siendo un poco baja.
• Los Scrum diarios no han sido tan diarios :D Ha sido un poco despendole...
• La plantilla del blog no permite leer bien el código :(

Acciones

• Las historias bloqueantes hay que priorizarlas teniendo en cuenta dicho bloqueo.
• Fijar una hora para realizar el Scrum diario. Si es posible, por la mañana
• Modificar la plantilla del blog para que el código se pueda leer decentemente.

¡Que poquitos problemas! :D Se nota que esta primera iteración ha salido bien. Veremos las siguientes...
Si queréis proponerme algún tema para la próxima iteración dejad un comentario en la entrada antes de la planificación de mañana :D De momento, en lo más alto de la pila están el quinto principio ágil y una introducción a FitNesse.

Principios Ágiles #4

Siguiendo con la temática de los principios ágiles, hoy voy a hablar del cuarto de ellos:

Business people and developers must work together daily throughout the project.

La gente de negocio y los desarrolladores deben trabajar de forma conjunta diariamente a lo largo del proyecto.

¿Gente de Negocio y gente de desarrollo?

Cuando se comienza un nuevo proyecto es lógico que el equipo de desarrollo (encargado de implementar una solución) no sea experto en el negocio del cliente. Por otro lado, un experto de negocio (encargado de explicar las reglas de negocio) casi nunca se interesará por el aspecto técnico (desde luego, ninguno que yo conozca). Ambos mundos están bastante separados, al menos sobre el papel, lo que provoca que sean incapaces de entenderse. No poseen un lenguaje común.

¿Por qué trabajar juntos de forma conjunta?
Obligar a que ambos mundos trabajen juntos de forma continua provoca que la separación entre ambos se reduzca. Obviamente, el objetivo no es que un desarrollador se convierta en un experto de negocio ni viceversa. Siempre existirá una cierta separación. El objetivo es construir un lenguaje común mediante el cual ambos grupos consigan entenderse y resolver sus dudas. Actualmente en el mundo ágil, dicho lenguaje común se plasma sobre todo en las pruebas de aceptación, definidas por la gente de negocio con ayuda del equipo técnico (Si queréis saber más sobre pruebas de aceptación pasaos por la próxima reunión de Agile-Spain Madrid).
Cuando ambos grupos empiezan a colaborar se empieza a reducir la brecha que los separa. Comienza a aparecer un sentimiento de equipo y una visión global del producto.

¿Por qué diariamente?
No vale con reuniones esporádicas, debe ser un esfuerzo continuo. No vale que los grupos se reunan una vez al mes para tratar ciertos temas y que después cada uno se marche a su cubículo. Si un desarrollador se encuentra con que tiene que tomar una decisión de negocio debe acudir a los expertos de negocio para que se la resuelvan. Si un experto de negocio quiere conocer que tal va el desarrollo de una funcionalidad X debe acudir al desarrollador para que le informe. Obviamente, esta colaboración no se puede llevar a cabo sin confianza y transparencia. No me sirve de nada que los desarrolladores estén siempre disponibles para el experto de negocio pero le mientan sobre el estado del proyecto.
Este trabajo diario no es sencillo de llevar a cabo. Muchas veces los desarrolladores no queremos levantar la cabeza del ordenador. Otras muchas los expertos de negocio no tienen tiempo (ni ganas) de reunirse con los "frikis". Por eso, es necesario un compromiso por ambas partes. Si alguno de los dos no se compromete se deja de ser ágil.

Conclusiones
El cuarto principo ágil:

• Busca que la gente de  negocio y la gente técnica hablen un lenguaje común que favorezca el entendimiento.
• Refuerza el sentimiento de equipo aumentando la confianza entre sus componentes.
• Implica compromiso.
• Obliga a la transparencia.

Imagen de "portada": Galería de thinkpublic, bajo licencia Creative Commons.

Retrospectiva #1

Desde que entré en esto del agilismo he aprendido muchísimas cosas. Una de las más importantes es kaizen, más conocido por mejora continua. En este caso, quiero mejorar mi forma de llevar el blog.
Una de las formas de mejorar es reflexionar sobre lo que has hecho. Para eso (y muchas más cosas) sirven las retrospectivas. Hay infinidad de formas de realizar una retrospectiva. Actualmente en los equipos en los que estoy lo hacemos como sigue:

1. ¿Qué estamos haciendo bien y queremos seguir haciendo? Empezar por lo que se hace bien ayuda a crear un buen ambiente en la reunión y sirve para celebrar los pequeños éxitos (a nadie le amarga un dulce)
2. ¿Qué estamos haciendo mal? Es necesario identificar en qué nos estamos equivocando para intentar evitarlo en un futuro.
3. Acciones para mejorar lo que hacemos mal. Si queremos mejorar debemos actuar. No vale con identificar los errores, hay que solucionarlos.

Siguiendo estos pasos voy a hacer una retrospectiva de lo que llevo de blog (un par de meses, creo). Animaos y contribuid a la retro, los comentarios están abiertos :)

¿Qué estamos haciendo bien y queremos seguir haciendo?

• Sin duda, lo mejor ha sido empezar el blog :D Pensaba que no iba a darle continuidad y, aunque debería escribir más, no está del todo mal. Ocho publicaciones en dos meses :)
  
• Otro puntazo fue que Lisa Crispin leyera el post sobre su libro y lo publicitara en twitter :) Que buena gente. Realmente, le pedí permiso y, tras dármelo, me pidió el enlace al post, pero aún así :D
• Publicitar las entradas en twitter me parece dabuti. Muchos de vosotros retwitteais y ayudáis a difundirlo. Gracias a todos ;)

¿Qué estamos haciendo mal?

• La periodicidad de las entradas. Hago una a la semana aproximadamente, pero es de milagro. De hecho, no me había dado cuenta hasta ahora... Menuda potra.
• Ningún contenido técnico de momento. Soy el programador féliz y todavía no he enseñado ni una linea de código... Eso no está bien.
• No aplico el agilismo a la hora de crear entradas. Voy a lo cowboy.
• La interacción con los lectores (clientes) es casi nula. ¡No se qué os gusta y qué no! :P
  

Acciones

• Aplicar Scrum con el blog. Ya tengo cliente (vosotros). Voy a tener una pila de producto, voy a hacer iteraciones y voy a hacer retrospectivas. Lo de hacer demo no creo :) Aquí tengo algunas dudas... 

• ¿Cuanto debe durar la iteración? Voy a empezar probando con iteraciones de un mes, a ver que tal.
  
• ¿Publico el plan de cada iteración? Voy a crear un post con el resultado del plan para cada iteración.
• ¿Hago reuniones diarias? En el post con el plan iré actualizando un burndown. A ver que tal sale :)
  

• En esa pila priorizaré algo de contenido técnico. Al menos una entrada técnica por iteración (menudo lío).
• Dado que voy a aplicar Scrum, necesito un dueño de producto. De momento, el dueño de producto seré yo, pero actuaré como proxy de mis verdaderos clientes, vosotros. Por eso, si tenéis en mente algún tema del que queráis que escriba no dudéis en escribir en los comentarios.

Pues nada, me estoy metiendo en un lío pero merece la pena.
La primera planificación la haré a lo largo de esta semana (Probablemente comience la iteración el miércoles 6 de Enero). Animaos y proponed historias para la pila de producto :D

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.

Principios Ágiles #2

Siguiendo con la temática de los principios ágiles, hoy voy a hablar de el segundo de ellos:

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Aceptamos requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

¿Por qué se aceptan los requisitos cambiantes?
Porque es la forma más sencilla de adaptarse a la realidad. Aunque exista un contrato firmado por el cliente en el que se fija el "alcance" del proyecto, lo cierto es que los requisitos cambian. Normalmente un cliente no sabe exactamente lo que quiere. Su conocimiento va aumentando según avanza el proyecto y es así como consigue definir realmente su objetivo. Dado que es imposible que el proyecto no cambie hay que hacer algo para que ese cambio no sea doloroso. Ahí es donde entra este principio. Aceptar los requisitos cambiantes significa que, si el cliente cambia de opinión, hay que hacerle caso y se debe modificar el desarrollo (Recordad que "nuestra máxima prioridad es satisfacer al cliente"). No hay que utilizar el contrato como escudo contra el cliente. Hay que utilizar al cliente como compañero para conseguir que el contrato llegue a buen puerto. Es decir, se debe establecer una relación de confianza entre el cliente y el proveedor para aprovechar las ideas de ambos.

¿Por qué no importa que los cambios lleguen en etapas avanzadas de desarrollo?
Porque, al tener "entregas continuas y tempranas de software valioso", es sencillo introducir los cambios que pida el cliente en cualquier etapa. La obligación de entregar software funcionando en cualquier momento del desarrollo hace que la complejidad al introducir cambios sea constante a lo largo del tiempo. Para que este modelo sea mantenible es necesario que el equipo de desarrollo se preocupe de que la base de código sea de calidad (Prácticas XP). Si no se mejora la base de código de forma continua, aceptar los cambios será cada vez más complicado, faltando así a este principio.

¿Cómo aprovechar el cambio para proporcionar ventaja competitiva?
Al aceptar el cambio lo que en realidad se está haciendo es aumentar la velocidad de reacción del cliente, que puede reaccionar antes a los proyectos de la competencia. Es capaz de adaptar su producto para eliminar las ventajas del rival y crear las suyas propias (o, al menos, intentarlo).


Conclusiones

El segundo principio ágil:

• se basa en abrazar el cambio. No hay que protegerse contra el cambio.
• introduce la colaboración con el cliente. Un cliente implicado que quiere la mejor herramienta posible.
• asume ciertas prácticas en el área de desarrollo (XP).
• aumenta la velocidad de reacción del cliente ante el mercado.

Principios Ágiles #1

Cuando uno entra en esto del agilismo lo primero que le cuentan es el Manifiesto Ágil. Conocer el manifiesto ágil es importante, pero no basta con quedarse ahí. Los autores originales del manifiesto se tomaron muchas molestias para redactar los 12 principios detrás del manifiesto y es necesario que nos los tomemos tan en serio como al propio manifiesto.
He decidido dedicar un post a cada principio. Empecemos por el primero:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Nuestra prioridad más alta es satisfacer al cliente mediante entregas continuas y tempranas de software valioso.

¿Por qué la prioridad más alta?
Es importante destacar que los firmantes del manifiesto ágil tienen un objetivo por encima del resto. Además, dicho objetivo no es negociable. Siempre debe estar presente y siempre debe cumplirse. Si no se cumple es un fracaso.Dicho objetivo es satisfacer al cliente.

¿Qué significa satisfacer al cliente?
A la hora de realizar un desarrollo es importante tener un cliente que lo demande (Cuando hablo de cliente me refiero a quien demanda dicho desarrollo. Por ejemplo, un cliente puede ser el propio desarrollador que necesita una nueva librería para un proyecto más grande. No tiene porque ser siempre un cliente que firma un contrato). Si no existe el cliente no existe el desarrollo. El cliente es el leitmotiv del desarrollo. Esto, que parece tan simple, se pierde muchas veces de vista a lo largo del desarrollo, provocando que se tomen decisiones sin contar con el cliente con lo que el desarrollo se va alejando de las necesidades de dicho cliente.

¿Por qué con entregas continuas y tempranas?
Por varios motivos. Deben realizarse entregas tempranas porque es una forma de involucrar al cliente en el desarrollo (Puede validar la usabilidad del desarrollo, puede opinar sobre el entregable, etc...). A su vez, deben realizarse entregas continuas porque de esa forma se es capaz de adaptarse a lo que el cliente quiere en cada momento. Los requisitos del cliente no son inmutables, por eso, cuanto antes se le enseñe software funcionando antes se podrá modificar de acuerdo a las nuevas necesidades del cliente.
Mediante este tipo de entregas se consigue un feedback del cliente que permite que el rumbo del desarrollo siempre apunte hacía donde el cliente desea.

¿Qué es software valioso?
Es software que funciona y que hace lo que el cliente necesita. Es fácil decirlo, pero no es nada sencillo conseguirlo.
Software que hace lo que el cliente necesita se puede conseguir mediante entregas continuas y tempranas, tal y como se ha explicado antes.
Conseguir software que funcione es mucho más complicado pero es condición necesaria para conseguir la satisfacción del cliente. Esto, que puede parecer algo obvio, se suele olvidar en la mayoría de los desarrollos. La "industria del software" (clientes y proveedores) está acostumbrada a rebajar las exigencias y a permitir errores en la mayoría de los proyectos que se realizan (ya sea por los tiempos de entrega, por la pobre formación de los desarrolladores, etc). A un desarrollo hay que exigirle que funcione y en eso es en lo que se centra el agilismo, en el software que funciona. Cualquier otra cosa dejará al cliente insatisfecho. Probablemente algún bug aparezca (ya sabéis, cualquier código contiene al menos un bug) pero se debe reducir la tasa de errores al mínimo (sobre todo en las funcionalidades principales). Es cierto que no todos los desarrollos tendrán la misma calidad (Siempre habrá desarrolladores mejores y desarrolladores peores, pero eso solo puede tener influencia en el tiempo que se tarde en realizar el proyecto, en lo fácil o difícil que sea mantener dicho proyecto, etc), pero es necesario exigirnos que funcionen (Un Seat y un Ferrari funcionan, la diferencia está en el proceso de montaje, en la calidad de los materiales, etc).

Conclusiones

El primer principio ágil:

• se basa en el la satisfacción del cliente.
• muestra como obtener un feedback periódico del cliente.
• indica la necesidad de entregar lo que el cliente necesita.
• avisa de la importancia que tiene el entregar software que funciona.