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.

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.

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