En la metodología de desarrollo ágil se usan varias técnicas diferentes. Si habéis escuchado algo sobre Scrum o XP, todas esas técnicas, o metodologías tienen algunos puntos básicos en común.

Aquí os voy a hablar de alguno de ellos:

• Backlog: El backlog es algo así como la “lista de tareas” que tenemos pendientes. Es el lugar donde almacenamos User Stories, Tareas y Reportes de bugs.
  Ejemplo de Backlog:

  
  Imagen tomada usando Caimito One Team

  El backlog es prioritizado por el Product Owner y los Stakeholders (clientes, usuarios finales, etc) de manera que los asuntos más importantes siempre están en la cabezera.

• Iteraciones:El motor del desarrollo ágil son las iteraciones. Ya sean de una semana, dos o tres… el desarrollo ágil tiene como uno de sus pilares fundamentales proporcionar software que funcione lo antes posible, de manera que el cliente o los usuarios tengan acceso al código que se está desarrollando.
  Podemos entender las iteraciones como “entregas”.

  Si bien esta aproximación es muy básica, nos da una idea que sí es bastante importante. Al final de una iteración el software debe estar listo para correr en un entorno de producción.

  Esto no quiere decir que lo que se entrega esté escrito en piedra, de hecho lo ideal es que el cliente pueda probar realmente el producto y proporcionar el feedback necesario para construir lo que realmente quiere.

  Un ejemplo de una iteración sería esto:

  
  Imagen tomada usando Caimito One Team

  Como podéis ver, una iteración se compone de los mismos elementos que teníamos en el backlog. Cuando los stories están listos para comenzar a trabajar con ellos y se tiene el suficiente material como para abarcar una iteración de trabajo, se genera la iteración y todo el mundo comienza a trabajar.

  Una iteración es un compromiso que el equipo de desarrollo establece con el cliente final. Se compromete a que todos esos puntos, que se han incluido en la iteración estarán listos y funcionando al final de la misma.

• User Stories: Un story es una breve descripción sobre algo que se debe desarrollar. No es tan extenso ni detallado como un Caso de Uso, en el que se listan de antemano todas y cada una de las posibles situaciones que deben estar contempladas. Más bien podríamos definirlo como una idea encapsulada en una breve frase, la cual pasará a ser desarrollada e implementada por el equipo de desarrollo.
  Una vez implementado y entregado al cliente, el story será evaluado por él y se decidirá si se requiere algún cambio adicional.

  La idea de esto es encapsular pequeñas funcionalidades que sean entendibles por los programadores y rápidamente implementables. De manera que si es necesario modificar o descartar el story no se deba emplear o se haya perdido mucho tiempo.

  Generalmente un story se compone de esta estructura:

  Siendo un [ rol ]
  Quiero que [ funcionalidad ]
  Para que [ valor de negocio ]

  
  De ahí el famoso As a… I want … so that … que seguramente ya habréis visto por internet.
  Aquí podéis ver un ejemplo de un User Story:

  
  Imagen tomada usando Caimito One Team

  Como podéis ver, el story no entra en detalles de cómo debe ser la implementación ni engloba todos los posibles casos de uso. Simplemente define un concepto de manera que el programador que vaya a trabajar en ese story tenga una idea de por donde comenzar a trabajar.
  A medida que comienza la implementación del story y surgen las dudas, el programador colaborará con el Product Owner para aclarar esas dudas, y finalizar exitosamente el story. (En el próximo post donde explicaré los roles dentro de un equipo ágil os explicaré que es esto del Product Owner, mientras tanto os puedo dar este link[ENG])

  Escribir buenos stories es todo un arte, aquí tenéis algunos consejos para escribir buenos stories. [ENG]

  En general un story debe ser lo suficientemente pequeño como para que un programador pueda realizarlo sin problemas durante una iteración, y lo suficientemente significativo como para que añada valor de negocio al producto. Es ese equilibro el que diferencia un buen story de otro no tan bueno.

  Una vez escrito el story, el equipo de desarrollo lo lee, conversa sobre él para asegurarse de que todo el mundo entiende lo mismo y procede a estimarlo. Sobre la estimación de un story hablaré algo más adelante en este post.
  Una vez ha sido estimado, está listo para ser introducido en la iteración y comenzar su implementación.

  Es importante que exista un test para cada story que se implementa. De manera que dichos test por un lado validan el correcto funcionamiento de la implementación, y por otro sirven de documentación para el mismo.
  Si al implementar un story nos vemos incapaces de realizar un test que lo cubra, probablemente estemos tratando de implementar un story demasiado grande.
  Estos stories reciben el nombre de Épicos, y deben ser subdivididos en otros stories más pequeños.

• Tareas y Bugs: Lo ideal cuando tenemos código listo para producción es que esté libre de bugs (errores), sin embargo suele ser común que existan casos para los cuales nuestro código no haya sido debidamente probado o situaciones en las que el equipo de desarrollo no haya pensado.

  Cuando se detecta un funcionamiento anómalo en el comportamiento de nuestro código se debe reportar y rellenar un reporte de error.
  Ejemplo de un Bug Report:

  
  Imagen tomada usando Caimito One Team

  De acuerdo con la idea de tener código listo para producción, al planear una iteración, todos los Bugs Reports que tenemos en nuestro Backlog, pasan automáticamente a la iteración, ya que antes de desarrollar nuevos stories es fundamental que el código que ya existe funcione correctamente.

  En cuanto a las tareas, podríamos definirlas como pequeños stories para los que no podemos realizar un test para verificar, o no tiene sentido estimarlas.

  Ejemplo de una tarea:

  
  Imagen tomada usando Caimito One Team

  Las tareas son un arma de doble filo, por su similitud con los stories en ocasiones no resulta tentador “disfrazar” stories como tareas. Tal vez para ahorrarse escribir los test, o para ahorrarse el proceso de estimación… sin embargo es importante limitar el número de tareas con las que se trabaja.
  Principalmente el hecho de que una tarea no tenga una estimación es peligroso, ya que el trabajo realizado no se refleja directamente en la velocidad del equipo a lo largo de la iteración. (hablaré de la velocidad más adelante)

• Estimación: Estimar los stories en los que vamos a trabajar no es un proceso trivial. Mucha gente asocia estimación con tiempo. Sin embargo nosotros preferimos estimar con complejidad.
  Cuanto se estima un story no se define si se va a tardar 2, 4 o 10 horas en tener el story terminado, si no cómo de complejo de implementar ese story.
  Habitualmente esta es una de las primeras cosas que chocan contra los principios del Project Management en general, ya que muchas de las compañías pagan a sus empleados por horas, y por tanto con un estimación basada en tiempos pueden saber aproximadamente cómo de caro es un proyecto.

  La experiencia empírica demuestra que este proceso está errado. En general las estimaciones basadas en tiempo suelen ser bastante inexactas, suelen “recortarse” por parte de ciertos comerciales para competir por vender un proyecto y eso devienen en un sin fin de problemas que básicamente terminan con un equipo de programadores trabajando hasta altas horas de la noche, molestos, desmotivados y sacando el trabajo como buenamente pueden.

  No hace falta ser un visionario para darse cuenta de que ese código no solo es propenso a errores, si no que un programador, trabajando en esas condiciones no puede dar lo mejor de sí.

  Estimar en complejidad, al principio resulta bastante incierto, pero en mi experiencia personal ha demostrado ser una medida bastante más fiable a la hora de saber qué cantidad de trabajo semanal soy capáz de llevar a cabo.
  Las métricas usadas dependen completamente del equipo o el software que se esté usando para estimar.
  One Team, por ejemplo, utiliza los valores: 10, 20, 40, 80, 1000000, siendo éste último el valor asignado a stories épicos.

  

  Al principio, para nuevos equipos, es bastante habitual que la velocidad del equipo (la suma de los valores asignados a los stories que se completan al final de la iteración) varíe. Pero con el tiempo, a medida que el equipo comienza a perfeccionar sus prácticas ágiles, es habitual tener una velocidad más o menos estable, permitiéndonos de esta manera, saber cuantas iteraciones nos hacen falta aproximadamente, para finalizar el proyecto (o al menos todos los asuntos que tenemos pendientes en en backlog).

Con estos conceptos básicos podemos comenzar a trabajar de manera ágil. Espero que os sirva de ayuda o de referencia para iniciaros en esta metodología

Ágil es una palabra de moda en el mundo del desarrollo de software si bien, esta metodología como tal, no viene diciendo nada nuevo.

Varios evangelistas y gurús se han alzado como portadores de esta “nueva” manera de construir software y diversas técnicas han surgido al rededor de este movimiento (con certificaciones y todo), afirmando ser la solución para todos los males.
En mi humilde opinión todo esto es (o debiera ser) mucho más simple.

Este es el primero de una serie de posts que voy a escribir a cerca de cómo entiendo la metodología ágil para el desarrollo de software.

Quiero dejar claro que no me considero ningún evangelista, ni ningún gurú, pero considero que puede resultar interesante y que cojones, me gusta hablar del tema

Todo este buzz de desarrollo ágil viene inspirado por este manifiesto:

• Valorar más a los individuos y su interacción que a los procesos y las herramientas
• Valorar más el software que funciona que la documentación exhaustiva
• Valorar más la colaboración con el cliente que la negociación contractual
• Valorar más la respuesta al cambio que el seguimiento de un plan

Lo cual fue tan revolucionario porque se da de lleno con las prácticas habituales en el desarrollo de software.

Recuerdo poco antes de salir de la universidad, cuando comencé a hacer prácticas para sacarme de encima esos créditos de libre configuración, que me llevé un severo desencanto en lo referente a mi futura profesión.
No había nada de planificación, todo se hacía deprisa y corriendo. A nosotros los becarios nos dejaban a nuestro libre albedrío, con poco más que un manual de actuación, unas pocas charlas sobre lo que necesitaban y una máquina para trabajar.
Ah!, y todo tenía que estar listo en 2 semanas.
No importaba como, no importaba la calidad y sobre todo no importaban las personas. Si te tenías que quedar haciendo horas extra (siendo becário!!!) pues te quedabas y punto.

A lo que voy es que generalmente, las llamadas “Empresas de Consultoría de Software”, en la mayoría de los casos no entendían el Software. Eran expertos en hacer dinero con el software (habitualmente subcontratando personal) dando lugar al llamado “Mercado de Carne“, en donde no importa lo que hagas, ni si estás bien o no. Lo único que importa es la diferencia entre:

a) El dinero en el que podamos venderte
y
b) El dinero que te damos a ti.

Si a - b es lo suficientemente lucrativo, entonces te contrataban. Si no entonces es que no habías pasado las pruebas psicotécnicas y demás…

Podría contar mil historias relacionadas con el mercado de carne madrileño, pero no viene al cuento.

Lo importante es que la llamada “revolución ágil” hacía una llamada al cambio.

Las personas son más importantes que los procesos y las herramientas.

Hazle entender esto a cualquier jefe de proyecto de la consultora Fulanez…

Ágil significa que un equipo de desarrollo de software, es el principal activo y como tal, las personas que conforman dicho equipo son lo primero. Todo lo demás viene a consecuencia de dichas personas. Y eso creo que nunca será suficientemente matizado:

Los programadores programan!

Si tu compañía vende “código”, ya sea en forma de servicios o de productos o de lo que sea… cuida de la gente que genera ese código.
Tiene sentido no?

Como ya escribí anteriormente, es difícil enseñarle trucos nuevos a un perro viejo, y es que como se suele decir “bad habits die hard”

En grandes compañías de software hay toda una serie de jerarquías, estándares y procedimientos establecidos que, en mi opinión, sólo sirven para mantener las cosas a raya.

Si nos abstraemos un poco y nos enfocamos en lo que es la estructura a nivel de corporación, es difícil percibir la diferencia entre una compañía que genera sofware y otra que vende lavadoras.
Y esto no sería grave si el software fuera como una lavadora, pero afortunadamente no lo es.

Según lo veo yo, el software es algo vivo. Algo que uno crea pero que, llegado el momento, cobra vida propia y comienza a demandar cosas en las que jamás habríamos pensado inicialmente. Y lo genial del Software es que podemos proveer soporte para esas necesidades de manera relativamente sencilla!
Una lavadora podrá tener más o menos programas, pero no dejará de ser una lavadora.

Esta diferencia fundamental radica que el software es, por así decirlo, un “producto” que reside más en el plano de las ideas, que en el plano físico, y tratar de controlar este tipo de productos usando viejas metodologías bien conocidas en otras industrias, en mi humilde opinión es un craso error.

Os diré qué es el infierno para mi:

• Programar algo usando especificaciones escritas en piedra.
• No poder mostrar tu trabajo al cliente a medida que lo desarrollas para saber si es eso lo que quiere.
• Después de haber trabajado en algo durante meses, que el jefe de turno me diga que hay que tomar otra alternativa.
• No poder avanzar en un proyecto porque “los jefes y el cliente” se encuentran discutiendo re-negociando los términos del contrato.
• No poder programar algo chulo y que sé que le va a proporcionar valor agregado al cliente, porque no se encuentra en el documento de especificación.
• Asistir a aburridas reuniones en las que los “los jefes y el cliente” se la pasan discutiendo quién tiene la culpa del retraso en el proyecto.
• Que el manager de turno nos diga que tenemos que trabajar más horas porque “vamos” con retraso.
• Tener que llevar traje y corbata al trabajo

Si alguno de vosotros ha trabajado en un proyecto de este estilo seguro que entiende a lo que me refiero, los que no… no importa como trate de explicarlo, nunca podré llegar a expresar con palabras el estrés y sobre todo la frustración que eso genera.

Por qué uso una metodología ágil?

• Puedo participar en el diseño de manera directa, dando mi opinión y modelando las tareas que van a terminar dando forma al proyecto.
• No más Proveedores vs Clientes. Prefiero Proveedores + Clientes, mucho mejor.
• Puedo enseñar periódicamente lo que estoy haciendo al cliente, de manera que él puede decidir si vamos por el buen camino o no, y sobre todo, puede inspirarse y darse cuenta de lo que realmente quiere.
• Si la cosa no funciona, si hemos escogido un camino que resulta no ser el bueno, es mejor caer cuanto antes (el principio “fail fast”). Si lo que estoy haciendo no es lo que el cliente quiere, prefiero haber gastado una semana a varios meses de trabajo.
• Prefiero pactar un número de iteraciones con el cliente, que un contrato escrito en piedra y lleno de cláusulas. Si mi trabajo gusta a mi cliente, y si ve el avance en el proyecto, acordamos más iteraciones. Si no, es mejor buscar otro proyecto u otro cliente, que establecer una relación de “te odio pero te necesito”.
• Puedo colaborar con un cliente ofreciéndole ideas y opciones en las que él no había pensado y enseñárselas en un pequeño demo. Si le sirve y si le gusta, podemos pasar esas ideas a la lista de cosas que hacer en sucesivas iteraciones.
• Mi cliente puede usar su producto, aquello por lo que está pagando, desde el primer momento! Y creo que esto, desde el punto de vista de alguien que está invirtiendo un montón de dinero en algo es fundamental.
  Ofrecer la posibilidad de “jugar” con el producto a mi cliente desde el final de la primera iteración y desde ese momento recibir su feedback, es algo impagable.

El desarrollo ágil ofrece diversas técnicas para llevar a cabo estas y muchas otras prácticas, generando unos resultados bastante menos estresantes, menos frustrantes y sobre todo más divertidos y con el tiempo iré contándoos las que yo uso para trabajar.

Debo reconocer que Tapestry me ha gustado más de lo que esperaba.

Tratándose de un framework para J2EE, esperaba tener que escribir líneas y líneas de XML para configurarlo adecuadamente, pero afortunadamente Tapestry 5 permite gestionar prácticamente toda su configuración a través de notaciones, agilizando bastante el desarrollo y permitiendo que el código sea bastante más legible.

Para aquellos que no conozcáis Tapestry os recomiendo el libro Tapestry 5: Building Web Applications

El cual nos lleva de la mano por cada uno de los capítulos recorriendo las diversas opciones que Tapestry pone a nuestra disposición a la hora de construir interfaces.

La única pega que le encuentro al libro es que en varias ocasiones (sobre todo a partir del capítulo 6) omite los paquetes que deben importarse para poder usar las diversas clases que se mencionan en el libro. Lo cual si os encontráis sin internet para consultar es bastante molesto, claro que siempre os podéis descargar el código fuente de los ejemplos (altamente recomendable para descubrir los dichosos paquetes).

En general Tapestry me ha causado una grata impresión. Le encuentro ciertas similitudes con Rails en el sentido de que nos permite usar componentes bastante interesantes y potentes con un par de líneas de código, pero no llega a abarcar tantos aspectos como Rails.
Tapestry 5 es para interfaces y poco más (lo cual no es poco).

Una herramienta curiosa y bastante ágil y útil si os toca programar con J2EE.

VS

Hace algunos días, Miguel Rodríguez hacía esta pregunta en su twitter:

¿Está Rails listo para las empresas? la pregunta correcta es ¿Las Empresas estan lista para el desarrollo AGIL en Rails?

Esto es algo en lo que llevo pensando los últimos meses, no específicamente con Rails, pero sí con el desarrollo ágil en general.

Paradójicamente la industria del software, que debiera adaptarse mejor que cualquier otra industria a los cambios teniendo en cuenta el producto que manufactura, es en cierto modo reticente a los cambios drásticos.
Pero cuando hablo de industria de software me refiero tanto a proveedores como a clientes.

Parece mentira que a día de hoy, sigan existiendo empresas que utilicen el desarrollo en cascada para desarrollar sus proyectos.

Esto está empíricamente probado que no funciona!

Entonces la pregunta que yo me hago es:

¿Qué impulsa a las empresas y a los clientes a usar metodologías viejas y obsoletas, blindarse con contratos de desarrollo y entregas definidas en fechas a priori sin tener especificaciones detalladas o en ocasiones, sin conocer realmente el producto que se desea desarrollar ?
Este tipo de proyectos y contratos suelen acabar en frases como esta por parte del cliente:
“Esto es justo lo que te pedí, pero no es lo que quiero”

El software desde mi humilde punto de vista, es como la materialización digital de una idea.
Pero trabajar con algo tan abstracto como una idea requiere agilidad, adaptación, imaginación… algo que desde mi punto de vista choca frontalmente con reglas fijas, diseños “grabados en piedra”, documentos de funcionalidad intocables, etc.

Cualquiera que sepa algo de tecnología, o haya tenido algo de experiencia, por poca que sea, en el desarrollo de software debe saber que el software jamás queda “escrito en piedra”, está en su naturaleza mutar, evolucionar (si, algo así como los pokemons) y en general estar sujeto a todo tipo de cambios.

Poco a poco han surgido diferentes metodologías, y frameworks que, una vez comprobado que lo rígido no funciona, han desarrollado una tendencia ágil para desarrollar software.

En general estas metodologías y frameworks, se adaptan en mayor o menor medida al desarrollo en espiral el cual es mucho más flexible en cuanto a incorporar cambios a nuestro producto.

Imagen cortesía de la Wikipedia

En concreto Rails, es un framework ágil para Ruby, uno de los lenguajes que considero que tiene más potencial de cara al futuro (flame wars aparte)

Rails es uno de tantos frameworks (Grails, Spring, Tapestry…) que ayudan a incorporarse en esta nueva tendencia del desarrollo ágil, pero de nada sirve tener un buen framework si no modificamos nuestra mentalidad en cuanto al desarrollo de software.

Documentación sobre desarrollo ágil hay a patadas, Extreme Programming, Scrum son sólo algunos ejemplos de los muchos que se pueden encontrar.

Pero mi punto es que, de nada sirve (o al menos de muy poco) la revolución ágil, si la industria (aka. proveedores y clientes) no cambian hacia lo ágil, y en mi opinión esta es una asignatura pendiente para las grandes corporaciones y en los programadores.

Poco a poco se está demostrando que pequeños grupos de trabajo entregados al desarrollo ágil, con clientes que apuesten por éste y se involucren en el proyecto, resultan mucho más productivos y sus productos mucho más satisfactorios que aquellos gestionados/implementado con viejos estándares, cláusulas, y documentos de funcionalidad “escritos en piedra”.

Pasará como con los dinosaurios y las grandes corporaciones de software estarán condenadas a la extinción?

Cambiar hacia lo ágil está lleno de retos, hay q cambiar de mentalidad, eliminar la pereza de modificar las cosas ya realizadas y probadas, adaptarse a los cambios del cliente, e incluso incentivar a éste para que participe, se involucre, pruebe, haga y deshaga…
No hay nada escrito en piedra, todo está sujeto al cambio, es más, el cambio es el motor del mismo desarrollo…

Es la revolución ágil, te apuntas?

Si hace algunos días hablaba de Beginnig Ruby, from Novice to Professional, hoy me encuentro con RailsSpace, uno de los libros más completos que he encontrado de Ruby on Rails.

RailsSpace nos lleva de la mano a través de los pasos para implementar una red social usando RoR.

Podéis encontrar más información de este libro aquí, y podéis leer la versión online aquí

Desde que mi amigo Stephan me pasara el libro de Beginning POJOs debo admitir que me aficioné a la editorial Apress.

En general los libros que publican son bastante buenos desde el punto de vista técnico, si bien en algunos casos se quedan algo cortillos, pero en general no son tan duros de leer como los de Wrox.

En concreto últimamente he estado trabajando con Beginning Ruby, from Novice to Professional y la verdad es que estoy encantado con el librito.

Hasta la fecha es lo más entretenido que he encontrado para ponerle las manos encima a Ruby.

Si estás aprendiendo Ruby créeme que no te va a decepcionar el librito.
Puedes encontrarlo en Amazon, con la curiosa oferta de comprarlo en Pack junto con Beginning Rails, from Novice to Professional.

Este todavía no ha caído en mis manos, pero todo llegará