Categoría: planificación_proyecto

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

How to create your project map

See below some slides of the English translation of a successful session at CAS2012 (Agile Spain Conference). Full slide deck can be found here.

product_map-prioritization

 

product_map-scheduling

 

product_map-real_example

 

 

Full presentation in english can be found here.

La presentación en español se puede encontrar  aquí.

 

See also

 

Videos cortos sobre planificación ágil

A continuación se muestra una lista de posibles técnicas a utilizar y pasos a realizar en una planificación de proyecto, en forma de videos cortos (en castellano, con subtítulos en inglés):

videos_cortos_planificacion_agi

 

Video

Descripción

1 – Identificar el alcance del proyecto (7′)

Se muestra una técnica sencilla para identificar de manera ágil el alcance de un proyecto a nivel funcional y técnico, su complejidad y sus riesgos, en un workshop conjuntamente con el cliente.

2 – Planificación ágil (I) – Ordenación (3′)

Se muestra una técnica sencilla para ordenar los requisitos de un proyecto en función de su valor, coste y riesgo, en un workshop conjuntamente con el cliente.

3 – Planificación ágil (II) – Product Backlog (4′)

Se muestra una técnica sencilla para planificar un proyecto de manera ágil, iterativa e incremental, en un workshop conjuntamente con el cliente. Como resultado, se crea una visión a alto nivel de iteraciones y entregas (Product Backlog).

  

 El detalle de esta técnica se puede consultar en la siguiente presentación en Slideshare: Crea tu mapa de proyecto para llegar a buen puerto

 La presentación en inglés se puede encontra aquí: How to create your project map.

 

Artículos relacionados

 

Planificación ágil con mapas de producto

“No false dichotomy”: no puede haber sólo cambios sin plan, ni tiene sentido un plan sin cambios (Agile Manifesto). Los cambios son necesarios y también es necesario saber a dónde se dirige el proyecto para no estar navegando sin rumbo o tardar mucho más de lo esperado en desarrollar un producto coherente. El control del alcance para entregar un buen producto en un tiempo razonable se vuelve especialmente crítico en proyectos cerrados y en contratos ágiles con requisitos remplazables (la evolución ágil de los contratos cerrados).

En la Conferencia Agile Spain 2012, se presentó una técnica relacionada con User Story Mapping a la que se ha denominado “Mapa de producto”. La técnica consiste en workshops (donde participan usuarios finales, stakeholders, Product Owner y equipo de desarrollo) cuyo principal objetivo es que todos los participantes compartan un mismo objetivo de proyecto, la misma visión de su alcance, riesgos/dificultades y acciones de mitigación, desde el inicio del proyecto, de manera que se generen sinergias y sentimiento de equipo para conseguir un mismo objetivo.

CAS2012-mapas-producto-sesion

 

mapa-producto-priorizar

 

mapa-producto-planificar

mapa-producto-ejemplo-real

A continuación aparece el enlace a todos los slides de la sesión «Crea tu mapa de proyecto para llegar a buen puerto»:

Versión en español

Versión en inglés

 

Artículos relacionados

 

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

Priorización de prácticas ágiles en desarrollo de producto – XI encuentro ágil en Barcelona

En este encuentro se utilizó un diagrama de prácticas ágiles para priorizarlas considerando su aplicación en el desarrollo de producto en su punto inicial (por ejemplo, en una startup).

La priorización de las prácticas difiere del caso tratado en el encuentro anterior, en que se evaluaron el uso de estas prácticas en el caso de un proyecto “corto”, de 3 meses, y sin evolución posterior. Los factores que más condicionan esta diferencia de priorización son la duración del proyecto y, por consiguiente, el grado de responsabilidad del equipo sobre su calidad técnica (la facilidad de mantenimiento/crecimiento del producto a posteriori).

Hacer clic en la imagen para ampliarla

priorizacion-practicas-agiles-producto

 

A continuación se muestran las principales diferencias en la priorización de prácticas:

 

  • Demo cada 2 semanas y cliente siempre disponible. Pasan a ser un Must. el éxito en desarrollo de producto depende del enfoque en proporcionar valor al usuario / consumidor final por parte de todos (tanto del cliente como del equipo, al cual se está pagado con stock options). Es por eso que la métrica de proyecto de valor entregado por unidad de tiempo también pasa a ser un Must. Por el contrario, en un proyecto corto, su éxito suele depender más de la visión del cliente. Él tiene que saber qué quiere obtener en ese espacio de tiempo, por que no hay mucho margen para una gran innovación o cambios radicales (eso no quita que existan proyectos cortos en que el equipo tiene que aportar mucho en definición de producto, incluso más que el cliente).
  • Historias de usuario. Pasa a ser un Must. Es muy importante tener foco en el valor aportado al usuario final o consumidor. Como se ha comentado anteriormente, en el caso del desarrollo de producto hay mucho más interés en este valor que en un proyecto de 3 meses. Asimismo este valor será de gran ayuda para priorizar el Product Backlog.
  • Modelo de Dominio. Pasa a ser un Must. Es un mapa conceptual que permite tener un vocabulario común entre las personas de negocio y el equipo de desarrollo, por lo que debe estar claro y bien definido. Se elabora en la iteración 0 para dar soporte a la primera release y se va refinando cada iteración. En el caso de un proyecto corto donde sólo se utilizaba durante 3 meses era un Have por que podría bastar con el esquema de base de datos.
  • La gestión de cambios de requisitos deja de ser un Have, dado que no hay que negociar desviaciones con un cliente externo. El control de los resultados del proyecto, del valor proporcionado, es una responsabilidad interna en la empresa, con lo que todos los cambios, modificaciones y adiciones de funcionalidad se entienden como necesarios.
  • Move people around y propiedad colectiva del código. Pasan a ser un Must. En la construcción de producto hay que asegurar el collective ownership y no perder conocimiento si en algún momento desaparece algún miembro del equipo. En un proyecto corto esto era menos perjudicial, dado que es inferior la probabilidad de que marche alguien con un conocimiento exclusivo y muy grande del producto.
  • Paso sostenido 40 horas a la semana. A corto plazo es un Have en una startup donde para aumentar su implicación el equipo incluso está pagado con stock options, con lo que puede “apretar” más para sacar la primera release. A medio/largo plazo debería ser un Must.
  • Hoja de cálculo o aplicación para seguimiento del Sprint. Deja de ser un must si se utiliza un Tablero de Tareas.
  • Los spikes (también llamados “balas trazadoras” o pruebas de concepto), aún sin aportar valor de negocio, son de especial importancia en el desarrollo de producto, dado que permiten desechar o validar soluciones tecnológicas (por ejemplo averiguar si un Framework va a mejorar la velocidad de desarrollo o si va a llevar a un callejón sin salida por que no soluciona una problemática), así como obtener una estimación del coste de un desarrollo masivo de aspectos concretos del producto. Es importante que un spike se realice dentro de un timebox, para forzar la toma de decisiones.
  • El refactoring sin miedo pasa a ser refactoring sin piedad, dado que el equipo se juega poder construir de manera sostenida en el futuro.
  • Peer reviews. Pasan a ser un Must. Dado que la empresa va a tener que vivir de este producto durante varios años y es muy posible que en siguientes iteraciones el código lo tengan que ver otras personas (en parte debido a las prácticas de Move people around y propiedad colectiva del código).
  • Gestión de defectos. Pasa a ser un Must. Posiblemente ya no sea suficiente o posible resolver los defectos ASAP para olvidarse de ellos, por lo que es importante disponer de un soporte electrónico adecuado para gestionar  defectos y obtener estadísticas que permitan averiguar qué está sucediendo.
  • Pruebas de rendimiento. Pasan a ser un Must.
  • Métricas de proceso. Pasan de no ser especialmente relevantes en un proyecto corto a ser un have en desarrollo de producto.
  • Programación en parejas. Es conveniente ir realizando esta práctica aunque sea de manera ocasional, planificando un número de horas por iteración o escoger para ello historias de usuario concretas. 

 

Otras observaciones:

  • En el caso de desarrollo de producto en un entorno competitivo, es especialmente importante construir con calidad interna para tener “cintura” a la hora de hacer cambios y conseguir un paso sostenible.
  • Los casos de prueba de aceptación sirven como checklist de completitud de las historias de usuario, aunque no deben de servir como excusa ni “descarga” para decir “he probado lo que había escrito, si no funciona es por que no estaban todos los tests identificados”.
  • Los casos de prueba de aceptación también actúan como TDD. El hecho de escribirlos y pensar en cómo se probará una funcionalidad, cómo debe comportarse el sistema (o BDD, Behaviour Driven Development),  permite evitar la aparición de errores por malos entendidos y evitar retrabajar (siguiendo los principios Lean). Por ello es recomendable no empezar a desarrollar en una iteración sin antes haber escrito los casos de prueba, especialmente por que es más barato escribir texto y pensar en cómo desambiguar los requisitos que arreglar errores importantes debido a su mal entendimiento.
  • La estimación siempre debe ser realizada por el equipo que vaya a ejecutar el proyecto. De esta manera será más realista, por tener en cuenta sus diferentes conocimientos, experiencias, fortalezas y debilidades. Recordar que como característica básica de los métodos ágiles, la estimación y planificación ágil permitirá calcular el ROI en función del tiempo y del gasto, así como saber qué cabe en cada release.

 

Artículos relacionados

 

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.

Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

 

 

 

Nota del system administrator de ProyectosAgiles.org:

Si estás viendo este artículo a través del RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: /wordpress/rss.xml

Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.

Priorización de prácticas ágiles en un proyecto corto – IX y X encuentros ágiles en Barcelona

 

En estos encuentros ágiles se elaboró un diagrama de prácticas y se hizo una priorización considerando un proyecto sin evolución posterior y de corta duración.
 
La priorización de las prácticas ágiles a aplicar en un proyecto puede depender de diferentes factores:
  • El tipo de proyecto, respecto a si no va a tener evolución posterior, o bien si se trata del desarrollo de un producto.
  • Su tamaño (esfuerzo necesario a realizar), su complejidad, el número de personas implicadas.
  • El conocimiento de la tecnología y del dominio (tipo de negocio) por parte del equipo.
  • El conocimiento del proceso de trabajo.
  • El conocimiento entre los miembros del equipo, si han trabajado anteriormente juntos.
  • El tipo de aspecto a mejorar dentro del proyecto (calidad, tiempos de entrega, productividad, etc.).
 
Hacer clic en la imagen para ampliarla
 
 priorizacion-practicas-agiles-proyecto-corto
 
 

 
Comentarios sobre las prácticas
 
A continuación se enumeran algunos de los comentarios que se hicieron en el encuentro:
  • Visión compartida. Es muy importante que el equipo tengo una visión compartida de los objetivos (mediante el Product Backlog) y de las tareas a realizar (mediante el Sprint Backlog).
  • Propiedad colectiva del código. Hay que erradicar la costumbre de que “esta tarea la tendrá que hacer esta persona por que fue él quien hizo esta parte del producto”. Cuanto más se tarde en erradicar, peor será. Para dar soporte a esto, existen prácticas que definen los estándares de trabajo del equipo (estándares de codificación, patrones de diseño) y prácticas de transferencia de información y conocimiento (peer reviews, pair programming, etc.).
  • La inversión en Unit Testing se recupera pronto, a partir de los 2 meses.
  • Aunque el cliente tenga poca disponibilidad para asistir a demostraciones (por ejemplo sólo puede hacerlo 1 vez al mes al mes), es importante hacer demostraciones internas (por ejemplo cada 15 días) para cerrar objetivos y tener estabilizado el producto.
  • El Scrum Master debe detectar quienes trabajan de manera más solitaria y no son suficientemente transparentes con el trabajo que están realizando. En esta línea, se pueden fomentar las peer reviews.
  • Es más barato y produce un mejor resultado hacer pruebas unitarias automatizadas que funcionales.
  • En el tipo de proyecto que se trató en el encuentro (sin evolución posterior y de corta duración, no desarrollo de producto), puede no ser necesario hacer diseño funcional ni diseño técnico. Puede ser suficiente la propia documentación del código y la que proporcionan automáticamente las herramientas de desarrollo (esquema de base de datos, etc.).
  • Se comentó que la calidad interna debería ser siempre alta (aunque se tratase de un proyecto sin evolución posterior y de corta duración), ya que esto facilita desarrollar incrementalmente, encima de código ya escrito, y el equipo también tiene que estar a gusto con lo que se está haciendo.
  • Hubo una propuesta de no utilizar una gestión de defectos (bugs) formal. Para que no fuese necesaria, se planteó el resolverlos lo antes posible y/o gestionarlos directamente en el sprint backlog.
 
 
Para saber más
  • Agile Adoption Patters – Amr Elssamadisy
  • Patterns of agile development adoption – The technical cluster – Amr Elssamadisy
 
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.
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles:http://agile-spain.wikidot.com/quedadas-barcelona
 
 
 
 
Nota del system administrator de ProyectosAgiles.org:
 
Si estás viendo este artículo mediante el RSS de ProyectosAgiles.org, asegúrate de estar accediendo a través de la siguiente URL: /wordpress/rss.xml 
 
Se ha detectado que (por razones históricas) también se está accediendo desde: http: //www.proyectosagiles.org/taxonomy/term/11/0/feed, que sólo muestra un conjunto muy reducido de artículos.
 

 

Gestión ágil de proyectos con Activecollab, Googledocs y Yammer – VIII encuentro ágil en Barcelona

En este encuentro Alexis Roqué de <Undefined> explicó su ecosistema ágil. Se hizo hincapié en el ecosistema como soporte a la comunicación entre los actores que participan en un proyecto (incluyendo al cliente), en la necesidad de un jardinero del ecosistema (en función de su complejidad) y en lo interesante que puede ser disponer de un buen sistema de gestión y push de conocimiento a nivel de empresa. Finalmente se subrayó que un cambio en la manera de trabajar siempre implica formación, perseguir e ir mejorando.

La presentación que se utilizó se encuentra aquí: http://www.slideshare.net/alexisroque/agile-development-ecosystem
 
foto-grupo-gestion-agil-activecollab
 
 

 
Objetivo de un ecosistema ágil
 
El objetivo de un ecosistema ágil es que todo fluya para poder proporcionar resultados y productividad. Un ecosistema de herramientas da soporte a una metodología determinada y a sus prácticas; en el caso de las metodologías ágiles, especialmente es un soporte a la realización de tareas de manera eficiente basándose en la comunicación entre todos los actores [1].
 
Por ello, el ecosistema ágil debe ser:
  • Un canal de comunicación entre los miembros del equipo y también con el cliente.
    • Un repositorio de información.
    • Una agenda / planificador que permita monitorizar / hacer seguimiento.
    • Accesible remotamente y a la vez tangible, que casi se pueda tocar físicamente.
  • Aceptado por el equipo, que perciba su beneficio.
    • Con la entrada de datos muy automatizada.
    • Que facilite el aprendizaje del equipo, que vaya mejorando en su manera de trabajar [2].
 
La participación del cliente
 
La participación del cliente es especialmente importante cuando se trabaja con metodologías ágiles. Por ello es importante considerar cómo este actor puede interactuar con él:
  • Consultando el estado de los objetivos/requisitos, burndowns, e incluso creando los objetivos/requisitos.
  • Se puede asignar tareas al cliente como, por ejemplo, que suba al gestor de contenidos información relevante del proyecto.
 
El jardinero del ecosistema
 
Puede ser necesaria una figura que se encargue de mantener suficientemente pulcro el ecosistema, especialmente es complejo por que existen muchos módulos, algunos sin integración automática. Esta persona se encarga de:
  • Estructurar la información.
  • Quitar ruido.
Para reducir su labor al mínimo, es recomendable que existan procedimientos de trabajo con el ecosistema y guías de uso de las herramientas.
 
Este jardinero del ecosistema, entre otras cosas, puede ser la misma persona que se encarga de recoger las retrospectivas de cada proyecto y difundir sus conclusiones poniéndolas en un Wiki global, o bien quien se encargue de avisar a quienes no están reportando las horas de trabajo pendiente (que permiten crear el burndown).
 
 
Ejemplo de ecosistema ágil
 
En el encuentro se presentó el siguiente ecosistema:
 
Tipo de Herramienta
Producto
Observaciones
Content Management Server
ActiveCollab
Ficheros binarios (documentos, imágenes)
Wiki
ActiveCollab
Versionado, comentarios, discusión, etiquetas, búsquedas.
Sirve también como repositorio de lecciones aprendidas.
Project Management
ActiveCollab
 
Issue Management
ActiveCollab
 
Software Configuration Management
Subversion
Está desligado de ActiveCollab. La trazabilidad se mantiene de manera manual.
Continuous Integration Server
Maven
 
Communication Booster
Gmail + GTalk
Twitter o Jammer
 
Demo / Preproduction Server
 
 
Sprint Backlog
GoogleDocs
Con burndowns.
ActiveCollab es fácil de desplegar (incluso existe el formato ASP). Da un buen resultado (Pareto 80/20). Sus principales problemas son:
  • Wiki y calendario limitados.
  • No dispone de una visión multiproyecto.
  • Hay un Wiki por proyecto. Esto impide disponer de un repositorio de lecciones aprendidas (ni gestión del conocimiento) para toda la organización si no es haciendo una copia manual de las lecciones de cada proyecto hacia un Wiki corporativo.
  • No es Open Source.
  • No hay charting.
  • No es un tablero de tareas físico, con lo que se pierden los efectos de radiador de información y psicológico de ir moviendo las tareas a estado “hecho”.
Se propusieron otras herramientas, en función de la tecnología de desarrollo y el precio de las herramientas: Redmine, Jira + Confluence + Greenhopper, Team Foundation Server (Microsoft).
 
 
Twitter / Jammer
  • Se utiliza para toda la empresa, para solicitar ayuda (por ejemplo indicar en qué estás atascado) y/o que fluya información de interés. Incluso se plantean incentivos para quien realice el mejor post. El problema es que como gestor de conocimiento es limitado. Una alternativa es utilizar una delicious como gestor de conocimiento con Twitter como push.
  • Por otro lado, es muy necesario tener disciplina en lo que se escribe y no hacer ruido. Para ello ayuda que los gestores y jefes de proyecto estén suscritos J
  • NO se utiliza para comunicarse dentro de las tareas propias de un equipo. Los miembros del equipo deben ser capaces de comunicarse de manera más directa, especialmente si están co-localizados.
  • Jammer dispone de un Niko Calendar. Dentro de la empresa se considera “obligado” empezar el día indicando cual es tu estado de ánimo, para que si tienes algún problema otra persona se de cuenta, pueda interesarse por ti y ayudarte.
 
Inconvenientes para la implantación de un sistema
 
Finalmente se mencionó que el principal inconveniente para la implantación de un sistema es, como siempre, el cambio en la manera de trabajar, que implica formación en el sistema y perseguir su uso. Una vez implantado, hay que ir mejorando el sistema.
 
 
Artículos relacionados
 
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.
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona

 

Métricas ágiles y valor – Resultados del sexto encuentro ágil en Barcelona

En este encuentro se compartieron experiencias sobre los siguientes temas:

  • Se debe tener sólo las métricas realmente necesarias.
  • Deben estar “balanceadas”, para detectar si se está obteniendo unos resultados a costa de otros.
  • Las métricas ágiles más importantes son: el valor que se va entregando el cliente y la velocidad de desarrollo.
  • Las métricas se pueden ampliar cuando se quiere ver la evolución de un problema. Una vez solucionado, se dejan de recoger.
  • Los criterios básicos de planificación de objetivos/requisitos de proyecto son el valor y el coste, a los que se puede añadir: riesgo, integraciones y madurez.
  • La percepción del valor de los requisitos puede ir cambiando según avanza el proyecto. Esto se gestiona en la replanificación que se hace al inicio de cada iteración.

 

priorizacion-encuentro

 

Métricas básicas en un proyecto ágil
  • Se debe tener sólo las métricas realmente necesarias, dado el coste que implica tanto recoger como interpretar cualquier métrica.
  • Cuando se recoge una métrica, las personas intentan quedar bien respecto a esa métrica. Por ello, es conveniente disponer de un conjunto de métricas “balanceadas” que detecten si se está obteniendo unos resultados a costa de otros. Por ejemplo, puede ser que la productividad esté aumentando pero a expensas de un descenso de calidad.
  • Notar que las métricas también permiten tener una proactividad y detectar un posible problema antes de que se manifieste completamente.
  • Las métricas ágiles más importantes son:
    • El valor que se va entregando el cliente (Product Owner), que permite saber:
    • La velocidad de desarrollo del equipo, que permite:
      • Extrapolar la fecha de finalización del proyecto y/o saber de qué objetivo/requisitos se dispondrá en una fecha determinada.
      • Planificar un nuevo proyecto a partir de la historia anterior.
      • Medir le aprendizaje del equipo, ya que es una métrica que debería aumentar con el tiempo.
    • Métricas de calidad como el número de defectos.

graficos-velocidad-valor-coste

 
Ampliación de las métricas
  • El conjunto de métricas se pueden ampliar cuando aparece un problema a solucionar y se quiere ver su evolución. Por ejemplo:
  • Dado que la recolección e interpretación de métricas tiene un coste (no sirve de nada disponer de un gráfico de tendencia si no se hace un análisis causal de por qué se está dando esa tendencia), una vez solucionado el problema (cuando la métrica ya es estable o el equipo ya ha aprendido), estas métricas se dejan de recoger (a menos que su recolección sea automática y su observación fácilmente discriminable).
 
La métrica “valor”
 
Aunque el cliente (Product Owner) es el responsable de determinar el valor de cada objetivo (requisito, funcionalidad, feature o historia de usuario), en el encuentro también se apuntó que el equipo (o empresa ejecutora del proyecto) también valora qué le aporta el proyecto. Por ejemplo, unos objetivos determinados (o un proyecto entero) pueden tener relativamente poco retorno de inversión para el cliente, pero mucho valor para el equipo, ya que le permite adquirir conocimiento, experimentar con nuevas tecnologías, ganar algún premio o reconocimiento, etc.
En el encuentro se mencionaron diversos ejemplos sobre cómo el cliente puede indicar el valor de cada objetivo:
  • Si no se conoce suficientemente cual va a ser el retorno de inversión, para cada objetivo el cliente indica en forma de dinero el valor que le aportará o lo que pagaría por él, por ejemplo: 1500 €, 1000 €, 750 €, 750 €, 500 €, 500 €, 500 €, etc.
    • De esta manera queda de manifiesto el orden de desarrollo que necesitaría el cliente (en Scrum se planifica el proyecto a partir del valor y del coste de desarrollo de cada objetivo, construyendo la lista de objetivos priorizada o Product Backlog) y qué objetivos tienen para el cliente un valor semejante.
    • Otros criterios de planificación que también se mencionaron fueron los riesgos asociados a cada requisito, las integraciones a realizar con otros equipos y la madurez de cada requisito (de manera que se aprovechase el tiempo del proyecto para que el cliente fuese conociendo más el producto e ir aclarando los requisitos menos maduros).
    • Las metodologías ágiles hacen explícito el balance entre valor y coste de desarrollo, hace más difícil que el cliente priorice igual requisitos que tienen el mismo coste pero valor muy diferente. Por ejemplo, en una web de contenidos multimedia no priorizará igual poder reproducir vídeos (funcionalidad que dispara el número de usuarios) que poner documentos (funcionalidad que con un coste similar que apenas incrementa el número de usuarios).
  • Otra posible medida de valor es cómo se espera que cada funcionalidad contribuya a conseguir una meta de la empresa. En el encuentro se comentó que en Google se mide el valor de nuevas features o aplicaciones en función del número de usuarios que se espera que las vayan a utilizar. Para conseguir la mejor aplicación posible, así como el compromiso y la aportación de los miembros del equipo, se cobra una bonificación en función del cumplimiento de este objetivo.
  • Se mencionaron técnicas de planificación como el Priority Poker (como el Planning Poker pero con cartas del 1 al 9) y el Kano Model con la clasificación de requisitos según sean:
    • Mandatory – Requisitos necesarios que por ellos mismos no aportan valor (por ejemplo que un móvil pueda realizar llamadas).
    • Lineal – Cuantos mejor es el resultado del requisito, más valor tiene el producto (por ejemplo la duración de una batería de móvil).
    • Exciter – El usuario se encuentra con una funcionalidad que no esperaba pero que le gusta mucho.
  • En casos de priorización más complejos y/o con un número de stakeholders alto, puede ser conveniente combinar varias técnicas de priorización por valor. En este caso, puede ser conveniente minimizar el número de stakeholders que intervienen, dado que si sus intereses son demasiado diferentes harían que todos los requisitos acabasen teniendo un grado de prioridad semejante [en Scrum sólo puede haber un único representante de todos los stakeholders, el Product Owner].
El cliente debe poner los medios para ir midiendo el valor que realmente va aportando el proyecto y de esta manera ir aprendiendo cómo asignar valor en próximos proyectos.
 
Hay que notar que la percepción del valor de los requisitos puede ir cambiando según avanza el proyecto (el cliente entiende mejor qué es lo que realmente necesita, la competencia ha sacado una nueva feature al mercado que hay que desarrollar, etc.), lo cual se gestiona en la replanificación que se hace al inicio de cada iteración.
 
Se mencionó la dificultad del trabajo de Product Owner dado que debe predecir cuanto y cómo se consumirá un producto, así como tener ideas brillantes y rompedoras. Esta predicción del futuro consumo (aunque se sirva de técnicas de investigación de mercado y competencia, focus groups, etc.), en principio parece más difícil que gestionar una reunión para que sea productiva (trabajo del Facilitador o Scrum Master) o sea desarrollar una pieza del producto (trabajo del equipo). Si no hay concepto de producto, no hay inversión. Y sin dinero no hay proyecto.
 
Agradecer a DoubleYou, agencia de publicidad que utiliza prácticas de Scrum y XP en sus proyectos, la cesión de sus instalaciones, la transmisión en directo del encuentro, los snacks y las bebidas.
 
Para apuntarse a los próximos encuentros en Barcelona sobre temas ágiles: http://agile-spain.wikidot.com/quedadas-barcelona
 
Para saber más
 

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+D, que 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