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