Categoría: planificación_iteración

Agile White Book de AXA liberado

AXA (EMEA-LATAM Emerging Markets) ha liberado su Agile White Book, descargable en el siguiente enlace : http://www.slideshare.net/AXAEMEALA/documents

awb-axa-emeala

Este libro es una guía de Agile que cubre los conceptos fundamentales y proporciona una terminología común para los diferentes países de la región EMEA-LATAM (aspecto importante dados sus diferentes niveles de madurez en Agile). Sirve como punto de entrada para futuros Scrum Masters que van a empezar a trabajar en Agile en AXA y esperamos que pueda servir también a otras organizaciones que están comenzando en este camino basado en personas y trabajo en equipo“.

Algunos ejemplos de contenido:

readiness-criteria

metrics-balanced-scorecard

También cuenta con varios checklists que puede ser útil consultar:

PBL-Refinement-checklist.jpg

Planificación ágil vs planificación tradicional

La planificación ágil parte de la idea de planificar en función de objetivos de negocio en lugar de tareas (a diferencia de la planificación tradicional), priorizando los que aportan más valor, y esperando a dar detalle a objetivos y tareas conforme se va acercando el momento de construcción de estos objetivos, cuando la indeterminación se va reduciendo, de manera que se amortiza el esfuerzo de planificar de manera detallada.

A continuación se muestran los conceptos comunes y las especificidades de cada uno de los planteamientos de planificación mencionados.

 

Conceptos comunes

Para la planificación de un proyecto existen varios conceptos básicos:

  • El triángulo de hierro, como metáfora de la relación que existe entre los  objetivos del proyecto (alcance), tiempo y coste, de manera que cualquier modificación en el alguno de estos parámetros implica la variación de otro.
    • Si se quiere negar esta relación y cambiar alguno de estos parámetros forzando mantener fijos los otros, se produce un impacto en calidad, entendida ésta como (1) proporcionar al cliente lo que espera, (2) minimizar defectos y (3) disponer de una buena calidad interna del producto, de manera que se puedan hacer modificaciones o mejoras en el producto con un coste acotado.
  • Los riesgos asociados y las acciones a realizar para mitigarlos.
  • Hitos externos que van a condicionar entregas parciales, versiones o fases.
  • Las dependencias funcionales y las dependencias e integraciones entre componentes técnicos, las cuales introducen precedencias a considerar en la planificación.
  • La cohesión de los distintos trabajos que se van realizando, de manera que se ahorren esfuerzos por abordar determinados trabajos de manera conjunta.

 

Planificación tradicional

planificacion-tradicional

La planificación tradicional toma como base el control predictivo de un PROYECTO, con lo que:

  • Está basada en la identificación inicial de las TAREAS necesarias para elaborar el producto (EDT o WBS), planteamiento que se va modificando (replanificando) según el devenir de acontecimientos durante el proyecto.
  • Realiza pocas entregas de producto durante el proyecto (normalmente realiza una única entrega en su finalización), con lo que el feedback que se genera es tardío y, dado que se ha construido mucho producto sin haber verificado su adecuación, los cambios que sean necesarios (si grandes y caros) pueden comprometer los plazos y el presupuesto del proyecto.
  • A lo sumo realiza una única retrospectiva (post-mortem) al finalizar el proyecto, con lo que las lecciones aprendidas ya no son aplicables en el propio proyecto.

 

Planificación ágil

planificacion-agil

La planificación ágil toma como base el control empírico de la construcción de producto (inspección y adaptación), por lo cual:

  • Plantea un faseado basado en OBJETIVOS DE PRODUCTO (desarrollo iterativo e incremental) priorizados balanceando beneficios de negocio respecto a sus costes de desarrollo.
  • Realiza un faseado muy intenso (de 2 a 4 semanas) con demostraciones al cliente de ese incremento de producto, de manera que se facilita el realizar cambios [1] que consigan el máximo el alineamiento con sus expectativas y se cree un espacio natural para la replanificación estratégica de los objetivos todavía no abordados.
  • Dispone de varios niveles de planificación, dado que asume un horizonte de incertidumbre a partir del cual no tiene sentido planificar tareas detalladas:
  • Realiza retrospectivas durante todo el proyecto, de manera que se mejore la productividad y calidad dentro del propio proyecto.
  • Hace partícipe al equipo en el proceso, tanto en la planificación (de proyecto e iteraciones) como en la mejora del procedimiento de trabajo (retrospectivas), añadiendo como parámetro de calidad la satisfacción del equipo, que se consigue mediante su participación activa, de manera que su implicación y motivación revierta en el resultado del proyecto.

 

Artículos relacionados


 

Ejemplo de uso del tablero o pizarra de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteración (Product Backlog Items) se puede gestionar mediante un tablero o pizarra de tareas (Scrum Taskboard) que actúa como radiador de información. A continuación se muestra cómo construirlo y un ejemplo de su uso.

Construcción del tablero

Material

  • Cartón pluma 100 cm x 70 cm. En su defecto, se puede utilizar una pizarra blanca, papelógrafo o corcho, marcando las áreas del tablero con cinta adhesiva de colores.
  • Rotuladores permanentes de color negro, rojo y verde.
  • Regla de 50 cm.

 

 Dimensiones 

 scrum-taskboard-dimensiones

 

La distribución de zonas se ha realizado de la siguiente manera:

  • En la parte superior se dispone una fila específica para tareas no planificadas, aquellas que no son parte de los requisitos/objetivos de la iteración pero que es necesario hacer de manera urgente (errores en producción, urgencias del cliente, etc.). De esta manera podremos visualizar cuanto somos de reactivos en lugar de planificados dentro de la iteración.
  • A continuación hay una fila reservada para la mejora continua, donde se podrán las tareas fruto de retrospectivas anteriores y que queremos que realizar en esta iteración. Sólo pondremos aquí aquellas tareas que no sean asociables a un objetivo propio de la iteración.
  • Se ha dejado más espacio para la columna de tareas no iniciadas, de manera que quepan todas las que se identifican en la reunión de planificación de la iteración (sprint planning). Notar que el espacio para tareas en curso es menor, dado que deberían ser las mínimas posibles para favorecer el flujo eliminando el multitasking. Similarmente, el número de objetivos abiertos en curso (WIP, Work In Progress) debería ser el mínimo posible y ser resueltos de arriba a abajo, según la prioridad indicada en el Product Backlog.
  • La zona de impedimentos está destinada a la lista de obstáculos que pueden impedir que el equipo avance, que consiga los objetivos de la iteración o del proyecto, u otros riesgos que requieren una atención especial. Es conveniente indicar quien es el responsable de su solución (un miembro del propio equipo o el Facilitador (Scrum Master), dado que es una de sus principales atribuciones). Se gestionan de manera similar a las tareas (pendientes, en curso, hechos).
  • La zona de retrospectiva servirá para ir anotando durante la iteración los aspectos que están funcionado bien (+, Pluses) así como los problemas que vamos identificando (Δ, Deltas).
  • En la zona libre de la derecha situaremos, encima, información propia del proyecto y, debajo, información propia de la iteración (explicado más adelante).

 

Resultado de la construcción

 scrum-taskboard-carton-pluma

Las ventajas de utilizar como base el cartón pluma son:

  • Su poco peso, lo cual permite llevar el tablero fácilmente desde la zona de trabajo del equipo a una sala para, por ejemplo, hacer la reunión de planificación de iteración (sprint planning).
  • Su modularidad, que permite adaptarlo a diferentes tamaños de equipo (las dimensiones del tablero de este ejemplo son las adecuadas para un equipo de 5 personas). Además de existir formatos de tamaño mayor e inferior, si es necesario en nuestro proyecto, podemos utilizar varios tableros y disponerlos uno al lado de otro, cambiar su orientación (horizontal-vertical), etc.

El tablero como radiador de la información de referencia para el equipo

El tablero es un radiador de información,  difunde el estado actual de la iteración (actualizado en la reunión diaria de sincronización (Scrum daily meeting), por lo que debe estar visible desde los puestos de trabajo del equipo con sólo hacer un movimiento de cabeza. También es especialmente útil en las reuniones que realizamos durante la iteración,  por lo que en él ponemos aquella información que queramos  consultar fácilmente cuando tengamos conversaciones delante del tablero:

  • La leyenda con el nombre de los miembros del equipo, su código de colores, fotos.
  • Información general del proyecto
    • La definición de hecho, que nos servirá como base inicial para hacer el despiece de objetivos de la iteración en tareas durante la reunión de Planificación de la iteración (Sprint planning).
    • La lista de objetivos priorizada del proyecto (Product Backlog).
    • Modelos del producto que se está desarrollando, a los que referirnos cuando expliquemos algo a los demás. De esta manera todos los miembros del equipo tendrán una misma visión, les sirvirá de apoyo cuando comuniquen cosas y ayudará a que utilicen una misma nomenclatura. Típicamente: diagrama de entidades del dominio, procesos o bloques funcionales e integraciones, etc.
    • Indicadores del proyecto: Product Backlog Burndown Chart, tendencias de defectos, etc.
  • Información propia de la iteración
  • Cualquier otra información que nos interese tener muy a mano.

scrum-taskboard-planificacion-iteracion-inicio

Planificación de la iteración (Sprint Planning)

Durante la reunión de planificación de la iteración, se va incorporando al tablero siguiente información:

  • En la columna de la izquierda se irán situando los objetivos de producto (Product Backlog Items) que el equipo se compromete a completar en la iteración, ordenados por prioridad para el cliente (Product Owner). Estos objetivos se pueden redactar, por ejemplo en formato de historias de usuario o, simplemente, con un título y un detalle (preferiblemente que indique qué pruebas se van a realizar para demostrar que el objetivo está conseguido).
  • A la derecha de cada objetivo se pondrán, en la columna “pendientes”, las tareas necesarias para poder completarlo, indicando las horas estimadas para su resolución, que iremos actualizando en las reuniones diarias de sincronización (Scrum daily meetings).
  • En su zona específica, dispondremos las tareas de mejora continua que se han derivado de la retrospectiva de la iteración anterior, que queremos resolver durante esta iteración y que, por tanto, consumirán tiempo de alguna persona.

De esta manera visualizaremos todos los tipos de tareas en que trabajan los miembros del equipo.

 scrum-taskboard-planificacion-iteracion-final

 

Ejecución de la iteración

  • Ponemos en color rosa las nuevas tareas que vayan apareciendo, sean:
    • Tareas  asociadas a objetivos / requisitos / historias de usuario que no fueron identificadas en la reunión de planificación de la iteración.
    • Tareas inesperadas y no asociadas a objetivos pero que exigen nuestra resolución dentro de la propia iteración (en la zona “no planificado”).
      • De esta manera podremos obtener métricas de trabajo no planificado [2] y en la retrospectiva revisaremos cuáles son las tareas que han aparecido de color rosa, lo cual nos permitirá saber, por ejemplo, si es que tenemos que mejorar nuestra definición de hecho o bien si tenemos que reflexionar y realizar alguna acción para intentar minimizar tareas no previstas.
  • Marcamos con un gomet rojo los objetivos y/o las tareas con más riesgos, aquellos que queremos tener controlados con más atención.
  • Cuando suceda alguna cosa que queramos comentar en la retrospectiva, la ponemos en su zona específica, en función de que sea una cosa que se está haciendo bien y se quiere recordar para memorizar y/o incluir como buena práctica (+, Plus) o bien una cosa una cosa a mejorar (Δ, Delta).
  • Ponemos los impedimentos, riesgos o cualquier otra cosa crítica que se tenga que ir resolviendo en la zona a tal efecto, especialmente las acciones a realizar que están fuera del alcance del equipo y que sean para el Facilitador (Scrum Master). Los gestionamos de la misma manera que cualquier otra tarea, poniéndolos como pendientes, en curso o hechos.
  • Podemos poner en otro color, por ejemplo en azul, los objetivos de la iteración siguiente que iniciamos en la iteración actual, para saber que estamos avanzando, pero también para no perder el foco en que lo primero que tenemos que completar son los comprometidos para la iteración. De esta manera podremos obtener métricas de trabajo avanzado [2] y reflexionar en la retrospectiva.

[Los colores aquí indicados para objetivos de la iteración (ítems del Product Backlog) y para las tareas son orientativos y se pueden ampliar en función de otros aspectos que queramos señalizar de manera especial (ítems de temas diferentes, tareas de corrección de errores, etc.)].

 scrum-taskboad-ejecucion-iteracion

 

Trucos (sólo si es necesario)

  • Utilizar una marca específica para las tareas más prioritarias (reservar el color rojo para indicar problemas o riesgos).
  • Poner colores diferentes en función del tipo de tarea (análisis/diseño, construcción, errores).
  • Poner 1 punto negro por cada día que una tarea se retrasa, para que el equipo vea si hay algún peligro y para poder reflexionar en la retrospectiva.
  • Poner 1 punto naranja cada vez que un objetivo/tarea se reabre por que no pasa las pruebas / control de calidad / aceptación y vuelve “hacia atrás”.
  • Sólo mover tareas a “Hechas” en la reunión diaria de sincronización, para que todo el mundo sea conciente del avance. Para ello, cuando alguien acaba una tarea, la marca como “hecha” pero no la mueve.
  • Una vez acabada una tarea, si es necesario que otra persona haga control de calidad (peer review y/o pruebas), se puede marcar la tarea indicando “Revisar”, por ejemplo con un post-it más pequeño. Se puede utilizar el siguiente convenio: un gomet a la izquierda para identificar a quien “hará” y otro a la derecha para identificar a quien “revisará”.
    • Notar que la marca “Revisar” es equivalente a tener un estado de tareas (columna) llamado Revisar, por lo que evita crear una “tarea Y” específica para hacer el control de calidad de la “tarea X” o tener una columna específica de “Revisar”, especialmente si este estado no es  aplicable a la mayoría de tareas. Sin embargo, se podría utilizar alguno de estos sistemas de control si se considera necesario, por ejemplo si el 80% de las tareas necesita revisión.
  • Poner un número en las tareas para indicar el orden.
  • Poner en las tareas el ID o nombre abreviado de la historia de usuario (por si se caen).
  • Tener una zona de Parking para los siguientes objetivos si no caben en el tablero o para tareas que el equipo va detectando que sería necesario hacer antes de finalizar la iteración pero que todavía no han sido clasificadas en objetivos.

 

Material para trabajar con el taskboard

  • Post-its rectangulares: 13 x 7,5 cm,
    • 2 paquetes color amarillo
    • 1 paquetes color azul (o verde)
    • 1 paquete color rosa (o naranja)
  • Post-its cuadrados, 7,5 x 7,5 cm, a ser posible: super sticky
    • 4 paquetes color amarillo
    • 2 paquetes color verde
    • 2 paquetes color naranja
    • 1 paquete color lila
    • 1 paquete color rosa (o rojo)
    • 1 paquete color azul
  • Post-its pequeños 5 x 4 Etiquetas post-its (2,5 x 7 cm), en 2 o 3 colores diferentes.
    • 6 paquetes color amarillo.
    • 1 paquete color rosa (o naranja)
    • 1 paquete color azul (o verde)
  • Cinta adhesiva transparente.
  • Cinta adhesiva  de color o negra, 3M Temflex 1500 o TESA 4204.
  • Tijeras.
  • Gomets pequeños para asignación de 7 personas: 7 colores + rojo = 8 colores. Si es un tablero de corcho: marcas/papelitos de colores y chinchetas.
  • Rotuladores normales: negro, rojo, verde, azul.
  • Rotuladores de pizarra blanca: negro, rojo, verde, azul.
  • Borrador de pizarra blanca.
  • Caja donde guardar todo el material anterior.

 

Agradecimientos

Me gustaría agradecer a las siguientes personas las ideas y consejos que me han ido proporcionando en estos años de uso de tableros de Scrum:

scrum-task-board

Estimación y planificación ágil – Resultados del quinto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Gestión de dependencias entre objetivos de proyecto.
  • Estimación del proyecto por parte de todo el equipo, utilizando días ideales o bien puntos de historia de usuario.
  • Planning Poker para hacer una estimación inicial del proyecto rápida y fiable.
  • Uso de la velocidad de desarrollo para ir proyectando el final del proyecto.
  • Pruebas de concepto para realizar estimaciones.
  • Estimación y planificación de iteración basada en compromiso.
  • La estimación ágil ayuda a crear “conciencia de equipo”
Foto de grupo estimacion y planificacion agil
 

 
Estimación y planificación de proyecto
 
 
Dependencia entre objetivos del proyecto
 
  • Los objetivos (en forma de historias de usuario) que forman la lista de objetivos priorizada del proyecto (Product Backlog) deben ser lo más independientes posibles, para poder demostrarlas y enseñarlas al cliente con la seguridad de que están completadas. De esta manera, el cliente puede tomar decisiones objetivas basándose en los resultados que ya está obteniendo del proyecto y en la velocidad de desarrollo del equipo.
  • Si hay objetivos que son muy dependientes, se puede hacer varias cosas:
    • El objetivo que genera más dependencias se pone antes en el Product Backlog. Los objetivos dependientes se sitúan en algún punto por detrás.
    • En alguna situación puede ser interesante juntar varios objetivos dependientes en uno. Sin embargo, con objetivos excesivamente grandes es más difícil medir el progreso del proyecto y cuesta más tiempo completarlos, por lo que si hay un retraso se tarda más en que sea visible. Por ello, para observar un avance regular en el proyecto, es mejor que los objetivos tengan un tamaño similar y no sean demasiado grandes.
 
La estimación la lleva a cabo el equipo
 
  • La estimación no la realiza el cliente / Product Owner, por que no es él quien se va a “ensuciar las manos” y luchar por cumplir con fechas.
  • Todo el equipo realiza la estimación para:
    • Reforzar el compromiso de todo el equipo respecto a las fechas que dan al cliente.
    • Reforzar el compromiso de cada miembro del equipo respecto al resto.
    • Hacer que todo el mundo se sienta oído.
  • La estimación se puede realizar utilizando alguna de las siguientes unidades:
    • Días ideales: los días necesarios para que el equipo pueda completar un objetivo, sin considerar interrupciones. Para pasar a días reales hay que aplicar un factor de corrección que puede ir del 60 % al 70 % de dedicación real al proyecto. Asimismo, habrá que tener en cuenta un margen para imprevistos como bajas por enfermedad, etc.
    • Puntos de historia de usuario: la complejidad que tiene cada historia de usuario. Un equipo en un proyecto determinado es capaz de completar un número semi-regular de puntos de historia cada iteración (“velocidad”).
 
Planning poker
 
La técnica de planning poker permite hacer una estimación inicial del proyecto rápida y fiable, dado que todos los miembros del equipo comparten sus diferentes informaciones y expresan su opinión sin sentirse condicionados por el resto.
A continuación se puede ver diferentes barajas de cartas de planning poker.
 
cartas-planning-poker
 
Cada número significa un peso / esfuerzo / complejidad para completar un objetivo (historia de usuario). La numeración de las cartas está basada en la sucesión de Fibonachi. La distancia entre números crece conforme se hacen mayores. De esta manera, se facilita la decisión sobre qué tamaño tiene un objetivo.
¿Es un 5 o un 8?. No vale la pena entretenerse en pensar si es un 5 o un 6, ni en el error por no intentar buscar esta precisión, dado que se compensará por encima y por debajo con el resto de estimaciones.
 
 
jugando-planning-poker.jpg
José Raya, Jordi Pradel y Alexis Roqué haciendo una demostración de Planning Poker
 
Planning Poker es un proceso iterativo de planificación. Funciona de la siguiente manera:
  • El cliente lee un objetivo (historia de usuario escrita en una tarjeta).
  • El equipo le hace preguntas para entender su alcance.
    • Las respuestas importantes se pueden apuntar en la propia tarjeta como detalles del objetivo o condiciones de satisfacción.
    • Pueden aparecer nuevas historias de usuario.
  • Cada miembro del equipo piensa en el esfuerzo necesario para completar el objetivo y todos muestran sus tarjetas simultáneamente, de manera que no están condicionados por las estimaciones de los otros.
  • Las personas que están más alejadas del consenso explican por qué su votación es más alta (hay algún problema en el que nadie más ha pensado o el resto no ha tenido en suficiente consideración) o más baja (conocen una manera sencilla de resolver el problema, resolvieron algo muy parecido en un proyecto anterior, etc.).
  • El equipo vuelve a votar, hasta que alcanza un acuerdo. No hay democracia, dado que todos deberán comprometerse a que ese objetivo se va a acabar con el esfuerzo acordado (se supone que no hay una persona que siempre vota de manera singular y a la que nunca se puede convencer).
Diversas personas manifestaron que con esta técnica el equipo ha ido mejorando mucho la precisión de sus estimaciones. De hecho, existen diversos estudios que concluyen que la sinergia que produce esta estimación conjunta es mucho mejor que la de una única persona por separado (típicamente la del jefe de proyecto o un senior en un proyecto tradicional).
 
Algunos consejos y trucos:
  • Elegir un objetivo de tamaño típico en el proyecto como patrón con el que comparar el resto de objetivos y asignarle una puntuación de carta también media (por ejemplo un 5).
  • Puede ser conveniente no jugar con las cartas más altas, ya que el error de estimación es mucho mayor (además, objetivos tan grandes dificultan ver el progreso y se tarda más en hacer visible si existen problemas en el proyecto). Notar que en la fotografía de las barajas se han apartado las cartas más altas para no jugar con ellas.
  • Dada la dificultad de empezar a trabajar con puntos de historia y no con esfuerzo en días ideales, para facilitar el empezar a utilizar Planning Poker se puede hacer el símil de que, por ejemplo, dos puntos de historia corresponden a un día ideal.
  • Comparar el tamaño que se va dando a cada objetivo respecto al de otros (triangulación). Ver ejemplo en [2].
 
Velocidad de desarrollo
 
Los puntos de historia permitirán medir la velocidad que tiene el equipo completando objetivos a lo largo e las iteraciones (puntos de historia por iteración) y de esta manera ir proyectando el final del proyecto.
  • Las 2-3 primeras iteraciones la velocidad es más inestable (debido a la complejidad propia de un proyecto: dominio/ requisitos nuevos, tecnología nueva, personas nuevas) y después se va estabilizando, con lo que ya es posible utilizarla para hacer predicciones. Si no se estabiliza, posiblemente es por que existen problemas subyacentes que lo impiden (en la organización, en la estabilidad del equipo, etc.) y que habrá que solucionar.
  • Las estimaciones (y la velocidad) se ven afectadas cuando se introducen nuevas tecnologías o conceptos de negocio en medio del proyecto, aunque después se vuelven a estabilizar.
 
 
Pruebas de concepto para realizar estimaciones
 
  • Si existe incertidumbre para realizar una estimación de un tipo de objetivos (historias de usuario), se puede hacer un spike o prueba de concepto extremo a extremo en una iteración anterior a su desarrollo. Esta investigación permite conocer el grado de dificultad de completar algo y poder estimar mejor las siguientes iteraciones, donde se desarrollarán las historias de usuario reales.
  • La prueba de concepto debe realizarse dentro de un timebox, para obligar a tomar decisiones y no dedicar un tiempo excesivamente largo a investigar.
 
 
Estimación y planificación de iteración basada en compromiso
 
En la reunión de planificación de iteración (Sprint Planning) el equipo va seleccionando objetivos del Product Backlog (historias de usuario) y descomponiéndolos en tareas. Escoge tantos objetivos como cree que es capaz de completar en una iteración (commitment driven sprint planning). La velocidad permite verificar (checkpoint) que el total de puntos de historia de la nueva iteración es congruente con las anteriores iteraciones, si están escogiendo demasiados objetivos o demasiado pocos.
Cada miembro del equipo que escoge una tarea hace su estimación en horas delante de todos, de manera que:
  • Se compromete respecto a sus compañeros.
  • Evita estimaciones demasiado optimistas (que comprometerían las fechas del proyecto) o demasiado pesimistas (que atentarían contra la competitividad de la empresa). De esta manera se disminuyen y ajustan los buffers.
 
La estimación ágil ayuda a crear “conciencia de equipo”
 
Como consecuencia de las técnicas descritas, la estimación ágil crea conciencia de equipo. Todos participan, tienen voz y voto. Cuando se produce una equivocación en una estimación, se ha equivocado todo el equipo. Por ello, no es para individualistas. No sirve que alguien diga “Yo he hecho mi parte de la historia de usuario”.
 
 
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, los snacks y las bebidas.
 
Agradecer a Telefónica I+Dque también utiliza prácticas de Scrum y XP en sus proyectos, las barajas de cartas de Planning Poker que regaló a los asistentes.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
 
Para saber más