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

 

Scrum con dos equipos en distintas ciudades

Autor: Jesús Iglesias

Xavier Albaladejo me ha pedido que publique aquí uno de mis últimos artículos, así que aquí os lo transcribo tal cual. Espero que os sea de utilidad.

 

El proyecto

El pasado mes de mayo comenzamos el desarrollo de un nuevo proyecto que ha terminado recientemente, al menos la primera fase del mismo. Partimos casi de cero, los requisitos eran muy básicos y poco documentados, pero parte del equipo teníamos en la cabeza exactamente lo que teníamos que hacer. De hecho era plasmar en una única aplicación todo nuestro trabajo de los últimos cuatro años.

En el proyecto participaron dos equipos de desarrollo en localizaciones diferentes: uno en Valencia, de 6 personas, y otro en Madrid, en el que llegaron a trabajar más de 30. Ninguna de estas casi 40 personas tenía disponibilidad completa para este proyecto sino que hubo que redistribuir toda la carga de trabajo para, con el mismo equipo, asumir un nuevo proyecto de cinco meses de duración. Salió bastante bien :P.

En la parte tecnológica teníamos otro grave problema: desde Madrid desarrollaban en .NET y desde Valencia en PHP.

Scrum

Desde el principio nadie tuvo dudas: Scrum era la mejor metodología posible para cumplir los plazos que nos habían impuesto.

Planteamos sprints de dos semanas y reuniones diarias de sincronización ("dailys") a las 10 de la mañana de alrededor de 10 minutos. Como Scrum Master se quedó uno de nuestros project managers y como product owner otro del departamento de operaciones. La mayoría nos habíamos leído ya el Scrum desde las trincheras, pero una cosa es la teoría y otra muy diferente la práctica, y ahí casi nadie teníamos experiencia.

No trataré en este artículo de enseñaros Scrum, no soy un experto, como mucho un poco “evangelizador” :P , simplemente trataré de explicar mis sensaciones tras cinco meses de Scrum intensivo.

 

El Equipo

Los dailys se hacían vía conferencia entre una sala de reuniones en Madrid y otra en Valencia.

Se hicieron, además, infinidad de reuniones a dos bandas entre los dos equipos para decidir funcionalidades, discutir los puntos donde no había acuerdo y resolver dudas. No sólo participaban desarrolladores sino también jefes de equipo, project managers, diseñadores, “expertos” en usabilidad, gente de testing y calidad, documentalistas, gente de sistemas, de datawarehouse…

La tecnología

Como he comentado, en la parte tecnológica teníamos otro grave problema: desde Madrid desarrollaban en .NET y desde Valencia en PHP. ¿Cual es el problema? :P . Se diseñó la arquitectura de manera que la aplicación trabajase indistintamente en uno u otro lenguaje.

Dentro de un mismo entorno web, unos módulos se cargan de un lado y los otros del otro de forma completamente transparente al usuario. Se diseñó un sistema de single sign on que pudiesen compartir y consultar ambas tecnologías y, asociado a éste, todo un mecanismo de seguridad de acceso a distintos menús y opciones de la aplicación.

El resultado fue formidable, todo funciona perfectamente de una manera integrada, robusta, eficiente y segura.

La Pila de Producto (product backlog)

Con la poca documentación que se tenía al principio se elaboró una pequeña pila de producto que fue creciendo a medida que las tareas de análisis evolucionaban. A esto debemos sumar requisitos que iban llegando por parte de los departamentos comerciales y de operaciones. Al final el product backlog era considerable. En agosto hubo que decidir quitar algunas historias de usuario ya que era imposible acometer todo lo que se quería, de hecho los requisitos a estas alturas eran infinitamente superiores a los que se habían supuesto en mayo. Aún así, eliminando cosas, se hizo un producto mucho más ambicioso de lo esperado. Las historias de usuario eliminadas no se olvidaron, simplemente se trasladaron a una segunda versión.

Para el seguimiento del proyecto, en vez del clásico tablero de tareas, y dada la dispersión de los equipos, decidimos utilizar una herramienta software. Comenzamos con un sencillo Excel y a mitad del proyecto incorporamos ScrumWorks. No creo que sea el programa ideal pero cumple su función.

Los Sprints

Los tres primeros sprints fueron prácticamente de análisis. Se hicieron documentos funcionales y orgánicos de todos los módulos requeridos y se perdió bastante tiempo definiendo la arquitectura de la aplicación, en realidad de las dos aplicaciones (.NET y PHP). Todo esto nos llevó a plantarnos a mediados de junio, tras 3 sprints, con muy poco que mostrar en las demos, y nos condujo a la consabida reprimenda de los que mandan, puesto que nos estábamos desviando (teóricamente) de la planificación estipulada. Sin embargo el tiempo nos daría la razón: el tiempo perdido en el diseño de la arquitectura se recuperó con creces en sprints siguientes y llegamos a la fecha con el proyecto terminado. Bueno, en realidad dejamos para el final un pequeño detalle, el rendimiento, que se solucionó en un sprint adicional.

A todo esto hemos de añadir, como ya he dicho, que el equipo no estaba dedicado al proyecto, cada día variaba la gente que entraba al daily ya que no todos estaban trabajando en el proyecto en ese momento. A eso hay que sumarle lo que llamo “contingencias del trabajo diario“, es decir, nuevos proyectos que van surgiendo durante todo ese tiempo y que implican dedicarle tiempo que tienes que quitarle a lo verdaderamente importante. Por si eso no fuera poco, a finales de junio se nos informa que una parte de la aplicación, un módulo de reporting, tiene que estar operativa a finales de julio puesto que se necesita para dar servicio en otros proyectos. Esto, que de palabra suena sencillo, nos obligó a modificar la planificación, la pila de producto y la pila de sprint ya que el funcionamiento de este módulo implicaba a otros (login, seguridad, diseño…). Y aún así cumplimos todos los plazos, increíble. Eso sí, otros proyectos tuvo que decidirse entre descartarlos o aprobar una desviación de una o dos semanas en el proyecto del que hablamos, con lo que de igual manera fueron descartados :P .

Las Estimaciones

Uno de los mayores problemas es, sin duda, estimar las horas de las tareas. Comenzamos quedándonos cortísimos y terminamos quedándonos cortos también. Creo que rara vez se hizo una estimación cercana a la realidad. Sin duda, es muy complicado.

Las tareas de análisis se sobrestimaron en su mayoría y las de desarrollo (la mayoría) se quedaron cortas. Para planificar los primeros sprints utilizamos Planning Poker, pero acabamos haciéndolo directamente de viva voz ya que decidimos que no aportaba nada. En los primeros sprints hubo que arrastrar bastantes tareas de uno a otro porque se habían estimado muy a la baja. Sin embargo, hacia el final se recuperó el tiempo perdido y las estimaciones no eran tan malas.

Las Demostraciones

Las demostraciones al cliente (interno en nuestro caso) eran el peor momento del sprint. No pocos días nos tocó quedarnos hasta altas horas de la noche para llegar a la demo del día siguiente con el trabajo terminado o, al menos, visible. Si esto lo hacíamos cada dos semanas, imaginaos que hubiese pasado si utilizásemos metodologías tradicionales: hubiésemos llegado al final del tiempo de desarrollo sin hacer ninguna demo, sin haber probado las cosas de una manera real. Habría sido imposible. De hecho, es lo que ocurre habitualmente :P .

En nuestro caso nos sirvieron no sólo para ver la reacción del cliente ante el avance del producto sino también para ver las fortalezas y debilidades del trabajo que estábamos desarrollando y reorientar los siguientes sprints.

Las demos están para que el cliente vea el avance del producto que se le está desarrollando. El cliente en nuestro caso era una persona en representación de uno o varios departamentos internos de la organización. ¿Qué utilidad tienen las demos si sólo asiste el product owner? Digo esto porque de vez en cuando aparecía por allí algún despistado que se dedicaba a criticar el producto, en concreto partes del mismo que llevaban dos o tres meses terminadas y validadas por el product owner. ¿Por qué esa actitud revienta-demos? O mejor aún, ¿por qué no le prestas el debido interés a un producto en el que se basará todo tu trabajo los próximos años? Ah, ya, es más fácil dejar la responsabilidad al product owner y después quejarse. Sin la implicación de toda la organización da igual qué metodología se utilice, ninguna conseguirá triunfar. Estamos hablando de media hora cada quince días, sólo eso. 

Otro punto importante a tener en cuenta es la opinión. La gente que asiste a la demo debería estar obligada a decir algo y no quedarse callados como si no fuera con ellos porque al final ocurre lo mismo, cuando tienen que opinar no opinan y después, cuando ya no se puede hacer nada, es cuando hablan.

Las retrospectivas

Las reuniones de retrospectiva fueron bastante interesantes. Por un lado comentábamos la indiferencia de los asistentes a las demos y por otro discutíamos sobre los problemas que se habían presentado durante el sprint, unas veces con más energía y otras con menos. En realidad casi podríamos decir que servían como válvula de escape al pasotismo de los asistentes a la demo.  Las retrospectivas son necesarias, sirven precisamente para evaluar no sólo lo que ha ocurrido sino también los ánimos del equipo.

La planificación

Tras la retrospectiva llega la reunión de planificación de sprint. Tal como indicaba más arriba, las estimaciones se hicieron muy complicadas: muchísimas tareas por historia de usuario, muchísimas dependencias entre ellas y no siempre tenemos todos en la cabeza las implicaciones que pueden tener unas con otras, lo que termina en estimaciones muy poco aproximadas por no decir aleatorias. Aún así poco a poco se fueron afinando bastante. En las reuniones de planificación se ponían sobre la mesa también nuevos requisitos que habían ido surgiendo y modificaciones sobre los ya terminados que obligaban a modificar las prioridades de la pila de producto ajustando el calendario a las nuevas necesidades y objetivos hasta llegar a la siguiente pila de sprint.

Conclusiones y lecciones aprendidas

Sin duda la experiencia de utilizar Scrum ha sido muy positiva. En otras ocasiones habíamos hecho intentos de aplicar Scrum a determinados proyectos que resultaron en utilizar solamente algunos conceptos de Scrum, pero la falta de implicación del cliente (casi siempre interno) restaba utilidad a la metodología. En esta ocasión se hizo una aplicación completa de todas las prácticas, real y efectiva, implicando a todos los elementos de la organización que tuviesen algo que decir dentro del proyecto y, aunque siempre se pueden hacer críticas a la implicación de algunos, podemos afirmar que, en general, todos cumplieron con su parte.

Una de las cosas de Scrum que todos alabamos cinco meses después son, sin duda, los dailys. Nos sirvieron a todos los partícipes del proyecto para conocer de buena mano qué estaban haciendo los demás, qué problemas había,  cuándo se iban a resolver, etc. Creo que cualquier equipo de desarrollo, independientemente de la metodología que utilice, debería realizar reuniones diarias para compartir ideas y problemas.

La idea de tener demostraciones del producto cada dos semanas obliga a todo el equipo a pensar más en hacer cosas que funcionen que en ir avanzando en tareas: es más importante terminar dos historias de usuario para presentar al final del sprint que comenzar 20 tareas que no se terminen.

Uno de los puntos que nos desviaron del objetivo en cada sprint fue el proceso de integración y preparación para la demo. Cometíamos el error de no tener en cuenta estas horas, que al final implicaban bastante tiempo de todo el equipo ya que al realizar la integración siempre había cosas que no funcionaban bien. El último día estaba dedicado casi íntegramente a estas labores que nunca estaban planificadas en la pila del sprint.

Los que me conocen saben que llevo ya unos años defendiendo Scrum como metodología adecuada para el desarrollo de software. Esta experiencia no ha hecho más que confirmar esta opinión: la adaptación del producto al cliente que se consigue no se podría lograr con metodologías clásicas en las que la más mínima modificación de las tareas a realizar puede provocar una desviación enorme.

Supongo que nosotros pagamos algo cara la falta de experiencia, sobre todo al principio, pero aún así logramos el objetivo. Seguramente con un poco más de experiencia el resultado habría sido aún mejor.

Por cierto, no hemos dejado Scrum: el proyecto sigue y ya trabajamos en la siguiente release, así que seguimos liados con dailys, sprints, estimaciones…

 

Artículos relacionados

Métricas de iteración (Scrum sprint metrics)

Autor: Jordi Salvat i Alabart

(Esta es la traducción al castellano de mi blogpost http://jordionsoftware.blogspot.com/2009/10/simple-metrics-for-scrum.html)

 

Al terminar mi charla en la Barcelona PHP Conference recibí varias preguntas sobre las métricas que utilizamos: como construimos nuestros gráficos de burn-down, etc.

Esto es lo que estamos haciendo a día de hoy. Es una mezcla de ideas de "Scrum and XP from the Trenches", "Agile Estimation and Planning" [1], y las nuestras propias:

 

  • El Product Backlog (PBL) se estima en Story Points sin dimensión utilizando Planning Poker. Para ello hacemos por lo menos una sesión de planning poker en cada sprint. Estas estimaciones solo se usan para la planificación a largo plazo[2].
  • Antes de cada reunión de planificación de Sprint, calculamos de cuantas horas·hombre disponemos en el siguiente sprint. Después multiplicamos por un factor de foco (actualmente 55%). Hasta hace un par de sprints, utilizábamos el factor obtenido en el sprint anterior, pero eso no funcionaba bien y causaba sprints alternados de carga demasiado grande/demasiado ligera. Así que decidimos fijar un valor en la parte baja del rango y subirlo lentamente cuando tengamos confianza en que podemos hacerlo. Creo que aún no hemos terminado de experimentar en este área.
  • En cada reunión de planificación de sprint, seleccionamos (el equipo y el Product Owner) unos pocos ítems del principio del PBL, identificamos sus tareas (en post-its amarillos), y estimamos cada una en horas (horas ideales, para ser preciso). Decidimos qué (y cuantos) ítems incluir en base a estas horas: el total no debe exceder el producto calculado en el paso anterior. Los post-its para los ítems elegidos van a la columna "Pendiente" en el tablero de tareas.
  • La suma de las estimaciones de las tareas seleccionadas es el primer punto del gráfico de burn-down.
  • El equipo actualiza cada día el tablero de tareas como sigue:
    • Escribiendo dos números en cada una de las tareas en las que han trabajado: horas trabajadas en ella desde el sprint previo y horas estimadas que quedan para completarla.
    • Moviendo cada tarea completada a la columna “completada”.
    • Añadiendo un post-it azul por cada tarea que ha sido adicionada “con disposición” en el sprint. Por supuesto, sólo hacemos esto cuando estamos claramente avanzados respecto al plan (“con disposición” significando que tenemos la elección de cogerla o no, en contraste con el “forzada” que indico más abajo).
    • Añadiendo un post-it rojo (con una estimación) en la fila superior (etiquetada “fuera de sprint”) para cada tarea no planeada que ha sido "forzada" a ser introducida en el sprint. Preferiríamos evitar esto, pero el negocio necesita que cojamos algunas de ellas (son mayoritariamente tareas de valor añadido que no pueden ser planeadas por que dependen de eventos externos como ventas de campañas de publicidad). Los errores en producción también son tratados de esta manera.
    • También ponemos con un post-it rojo las tareas que deberían formar parte del sprint pero que no fuimos capaces de identificar durante la planificación, sólo que van en la fila correspondiente a su ítem de producto.
  • Después sumo la última estimación disponible para cada tarea en la parte "viva" del tablero de tareas (eso es: todas las tareas salvo las completadas) para obtener una estimación del trabajo que falta. Ese es el valor que pongo cada día en el gráfico de burn-down. La suma manual es engorrosa, pero solo me toma un par de minutos, que contribuyo contento a cambio de las muchas ventajas de usar un tablero de tareas de verdad y no una herramienta electrónica.
  • Al final de cada sprint produzco un pequeño conjunto de estadísticas que publico en la página wiki de ese sprint (indicando al lado de cada una el valor del sprint anterior para poder comparar, aunque sería mejor usar gráficos):

 

ESTADÍSTICAS INICIALES (calculadas al principio del sprint)

A. Velocidad objetivo: suma de los "story points" de todos los items del PBL inicialmente incluídos en el sprint.
B. Horas estimadas: suma de las estimaciones en todos los post-its amarillos al principio del sprint. Como he dicho antes, este es el primer valor que dibujo en el gráfico de burn-down.
C. Horas diponibles: total de horas·hombre disponibles para el sprint.
D. Factor de foco objetivo (B/C): como un %

 

ESTADÍSTICAS FINALES (calculadas al terminar el sprint)

E. Velocidad real: suma de los "story points" realmente completados en el sprint

F. Horas reales: número real de horas dedicadas al sprint (eso es: C – bajas médicas y similares + horas extras si las hubiera)
G.Total estimaciones tareas previstas en sprint completadas: suma de las estimaciones iniciales de los post-its amarillos y azules que realmente completamos. Eso es: B + post-its azules – trabajo excluído del sprint.
H. Factor de foco (G/F): como un %

J. Horas cargadas a tareas planeadas: recuento de todas las horas reportadas en todos los post-its amarillos y azules completados en el sprint. Este es el más pesado de calcular, pero no son más de dos o tres minutos por sprint, así que deja de gimotear. Incluso mi hija de 9 años puede sumar eso sin necesidad de un ordenador.
K. Horas cargadas a tareas no planificadas "dentro del sprint"
L. Error de estimación ((J+K)/G-1): como un %
M. Factor de foco real ((J+K)/F): como un %

N. Horas cargadas a tareas no planificadas "fuera de sprint": con frecuencia las descompongo en categorías tales como bugfixes, soporte, operaciones, publicidad,…

P. Total de horas cargadas (J+K+N)
Q. Error de reportado (1-P/F)

 

Son un montón de valores, y la nomenclatura de los varios "factores de foco" puede ser confusa, pero nos permiten dilucidar, cuando hay problemas de planificación, si fue por un exceso de trabajo no planificado, estimación inválida (hubo tareas que no supimos identificar), o estimación imprecisa. Los dos últimos valores (P y Q) son solo un "checksum" para alertarnos si nos ponemos vagos y dejamos de reportar las horas adecuadamente.

 

Para saber más

 

 

Retrospectivas ágiles – Resultados del septimo encuentro ágil en Barcelona

En este encuentro se presentaron dos tipos de retrospectivas, a las que se llamaron “Express” (para iteraciones cortas, de 2-3 semanas) y “full equipe” (para iteraciones de 1 mes, releases, fin de proyecto o empresa).

Se expuso la conveniencia de utilizar el principio de Pareto en la resolución de los problemas de un proyecto, es decir, unas pocas causas producen los problemas con más impacto. Por ello, y para ser más efectivos en las retrospectivas, se consideró de especial importancia ir haciendo “shortlists” de los resultados de las actividades típicas (identificación de problemas, causas y soluciones).
Se hizo una simulación de retrospectiva “full equipe”. Se partió de un “blind brainstorming” para decidir el tema a tratar (“Nuevos negocios, la mayoría mueren en el primer año”).
Se señalo la importancia de transmitir el conocimiento generado en las retrospectivas al resto de equipos y se finalizó haciendo una retrospectiva del encuentro.

 
Objetivo de una retrospectiva
NO se está haciendo Scrum, no se puede ir mejorando de manera continua, si regularmente no se dedica un tiempo de calidad para que el equipo reflexione sobre cómo está trabajando y aprenda a ser más efectivo y eficiente, todo ello disfrutando de su trabajo. Es decir, el equipo debe ir mejorando de manera gradual respecto a:
  • El servicio ofrecido al cliente, la calidad que percibe del producto.
  • La productividad del equipo.
  • La calidad interna del producto (que sea mantenible para poder crecer de manera sostenida).
  • Qué es aquello que le molesta, qué no deja disfrutar al equipo en su trabajo.
Si no se dedica 1 o 2 horas cada 2 semanas (o 3 o 4 horas al mes) a hacer retrospectivas, los problemas se repetirán iteración a iteración, lo cual producirá frustración en el equipo.
 
Enfoque constructivo y positivo
  • Es importante dedicar una parte de la retrospectiva a reconocer las cosas que se hacen bien, para no caer en el pesimismo y derrotismo. Respecto a la otra parte de la retrospectiva, la dedicada a las cosas que no funcionaron, en lugar de hablar de “cosas negativas” es conveniente hablar de “cosas a mejorar”.
  • En lugar de buscar culpables, el equipo tiene que pensar qué parte del proceso de trabajo hay que cambiar para que el problema no vuelva a suceder.
  • El Scrum Master es el “engrasador” que evita que se produzcan conflictos entre personas durante la retrospectiva. Identifica a tiempo que se está entrando en conflicto destructivo para pararlo.
 
Tipos de acciones de mejora
Las acciones de mejora que se identifican en una retrospectiva se pueden dividir en dos grupos:
  • Soluciones paliativas, aquellas que tenemos que tomar para vivir mejor a corto plazo pero que no solucionan el problema de base.
  • Soluciones “core”, aquellas que necesitan más tiempo pero que a medio plazo solucionarán el problema.
Dependiendo de su alcance, las acciones de mejora se incorporan a los sprint backlog de las siguientes iteraciones y/o a la lista de impedimentos del Scrum Master.
 
Ayuda externa
En la retrospectiva el equipo puede verse limitado en su capacidad para dar soluciones. Dado que siempre “golpea” de la misma manera, con el mismo martillo, el equipo puede encontrar como solución la participación de algún experto externo que les ayude en su trabajo, e incluso que acuda a la retrospectiva para ofrecer alternativas.
Retrospectiva Express

 retrospectiva-express

  • Se empieza pintando en el whiteboard una línea horizontal que simboliza las 2-3 semanas de la iteración. Esto nos ayuda a recordar y situar los eventos más significativos que ocurrieron.
  • En la parte superior el equipo escribe las cosas positivas que sucedieron: qué está funcionando, reconocimientos a personas, etc.
  • En la parte inferior el equipo escribe los problemas a mejorar, los efectos negativos que estamos experimentando en nuestros objetivos (ver apartado “Objetivo de una retrospectiva”).
  • Cada persona del equipo puede poner hasta 3 puntos positivos y negativos en cada evento.
  • Primer shortlist: nos quedamos sólo con los 2 o 3 problemas que el conjunto del equipo está considerado más importantes en este momento (en el futuro pueden cambiar). Si es necesario, se puede registrar el resto de problemas para en el futuro comprobar si permanecen a lo largo de las iteraciones y para recordar que de manera explícita se decidió no hacer nada con ellos en esta retrospectiva.
  • Nos preguntamos cuáles son las causas de estos problemas y hacemos el segundo shortlist: nos quedamos con las 2 o 3 causas más importantes.
  • Pensamos en las acciones que puede solucionar estas causas y hacemos el tercer shortlist: nos quedamos con las 2 o 3 acciones que tienen un mejor ROI (esfuerzo a dedicar por beneficio a obtener). Notar que en principio NO ejecutaremos todas las acciones que hayan aparecido por que:
    • El principio de Pareto también aplica a los problemas de un proyecto, es decir, será suficiente con acometer acciones muy concretas sobre las causas que producen los problemas con más impacto.
    • No tenemos todo el tiempo ni recursos del mundo para arreglar todos los problemas de nuestro proyecto.
    • Tenemos que producir para nuestro cliente, no sólo dedicarnos a mejorar.
Poco a poco, iteración a iteración, iremos arreglando los problemas más importantes que vayamos encontrando en cada momento.
 
Retrospectiva “full equipe”
retrospectiva-full-equipe.jpg
Se hizo una simulación de retrospectiva “full equipe”. El tema se eligió haciendo un “blind brainstorming”: para que nadie se sienta cohibido con su propuesta respecto a los demás, las propuestas se escribieron de firma anónima en papeles. Tras hacerse públicas, se agruparon y se votaron para ver cual era la más interesante para todos.
El tema elegido fue: “Nuevos negocios, la mayoría mueren en el primer año”.
blind-brainstorming
Las causas que se identificaron fueron:
  • Business plan incorrecto (especialmente por falta de conocimiento del negocio y falta de suficiente dinero inicial).
  • Problemas con los socios.
Alexis Roqué hizo la siguiente metáfora:
  • Un buen business plan es la hoja de ruta.
  • El conocimiento del negocio es como el carné de conducir.
  • El dinero inicial es la gasolina.
retrospectiva-full-equipe-simulacion 
Retrospectiva de la retrospectiva
Siguiendo el principio de “inspeccionar y adaptar”, para ir aprendiendo a hacer retrospectivas, al final de cada una se hace una retrospectiva de la retrospectiva.
En el caso del encuentro, lo que más gustó fue haber podido practicar lo que se había explicado (una retrospectiva), que la gente se soltó, participó, que hubo un buen dinamizador, lo sencilla que era la retrospectiva Express, la idea de cortar y simplificar (“shortlistear”) en todas la actividades de la retrospectiva y el haber hecho timebox de las actividades del encuentro.
En lo que hay que seguir enfocándose es en tener encuentros menos teóricos y más prácticos.
 
Gestión del conocimiento
Es importante transferir el conocimiento adquirido en una retrospectiva (las “best practices”) al resto de equipos, para tener una mejora continua de la organización.
Por ello hacemos estos resúmenes 😉
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
 
Artículos relacionados

Agilidad es calidad y competitividad

Este artículo se tomó como base para el mini keynote de apertura del Agile Open Spain 2009.

Agilidad es calidad

 

La agilidad es mayor satisfacción para TODOS los que participan en un proyecto:

    • Nuestros clientes, que reciben un mejor servicio.
  • Los trabajadores (nosotros), que podemos realizarnos profesionalmente en nuestro trabajo y que disfrutamos más.

Esto es lo que venden muchas las metodologías, pero con diferencias fundamentales en cómo entendemos y conseguimos esa calidad:

  1. Calidad es satisfacer las expectativas de nuestros clientes, y para ello no hay nada mejor que priorizar los objetivos del proyecto en función de los que aportan más valor al cliente, enseñarle de manera regular el producto final (una aplicación funcionando) y siendo flexibles a cambios (control empí­rico en contraposición al control predictivo de metodologías más tradicionales, que suponen que es posible conocer desde el principio todos los detalles del sistema a construir y que, por tanto, estos no van a cambiar durante el desarrollo).
  2. Calidad es que lo que nuestros productos puedan crecer de manera sostenible, que estos cambios tengan un impacto controlado, de manera que estos cambios sean baratos. Para ello:
    1. Utilizamos prácticas de ingeniería (patrones de diseño, peer reviews, pair programming, coding standards) y cuidamos la calidad interna de nuestros productos empezando primero por las pruebas (TDD, refactoring).
    2. Mientras construimos nuestros productos, comprobamos de manera continua que se comportan de  manera adecuada. Para que esas comprobaciones sean baratas (dado que hay que repetirla infinidad de veces) automatizamos integraciones y pruebas.
  3. Las metodologías ágiles no se olvidan del capital humano que lo hace posible. Nosotros creemos que la calidad de un proyecto depende de la calidad de TODAS las personas que trabajan en él y de cómo colaboran, mucho más que de tener procesos bien definidos y documentados.

 

Agilidad es competitividad

 

Por otro lado, nunca podremos competir con India o China en precio. La agilidad nos puede ayudar a tener un país más competitivo, es decir, a ser más innovadores, a proporcionar mayor calidad y a ser más productivos. Necesitamos adoptar modelos de gestión que nos permitan adaptarnos de manera continua a un entorno de incertidumbre, en continua evolución, y ser muy ágiles en el desarrollo de iniciativas. La clave vuelve a ser:

  • Modelos dirigidos por valor.
  • Flexibilidad a cambios.
  • Potenciación del equipo, multidisciplinar y autogestionado, para que aporte creatividad en el producto y que sus sinergias y la mejora continua le hagan más eficiente a través de la colaboración de sus miembros.

 

¿Qué se necesita para que una empresa sea ágil?

 

Para que una empresa empiece a ser ágil es conveniente realizar los siguientes requisitos:

  • Un cambio de cultura profundo en individuos y organizaciones, y especialmente en las direcciones y los gestores de las empresas. En lugar del ordeno y mando, para poder crear este tipo de equipos superproductivos y motivados se necesita cambiar a un modelo de gestión basado en la facilitación de la colaboración entre las personas que participan en los proyectos, así como el coaching del equipo, para que adquiera conocimiento de forma colaborativa, que desaprenda, se equivoque y que vuelva a aprender.
  • En esta misma lí­nea, hay que transformar las relaciones de cliente/proveedor en relaciones de socios de proyecto en que todos tenemos que colaborar y todos  tenemos que ganar.
  • A nivel de ingeniería, facilidad para realizar cambios.
  • Enfocarnos en proporcionar valor en todas las tareas que hacemos, desde que aparece la idea del producto hasta que el usuario final o consumidor lo reciben.
     

Todo esto acabamos de ver es, esencialmente, el Manifiesto Ágil, Scrum, eXtreme Programming y Lean Software Development.

 

¿Quien hace Agile?

 

Hoy dí­a, las metodologí­as ágiles se están extendiendo en paí­ses punteros en tecnología (EEUU y su área de influencia, países del norte de Europa y potencias emergentes como India o China).

 
Entre las empresas que han realizado este cambio de paradigma para ser más competitivas y atraer talento podemos encontrar a Google, Amazon, Nokia, British Telecom, Microsoft, SAP, IBM, Bank of America, General Dinamics, Blizzard, Ubisoft, etc. y españolas como Telefónica I+D, Double You, Plain Concepts, Proyectalis, Biko2, Gailén, Autentia, etc.

De cualquier manera, en España las metodologías ágiles todavía son poco conocidas. En poco tiempo, nuestros profesionales y empresas pueden no ser competitivos y ni siquiera colaborar con empresas extranjeras porque no nos habremos adaptado a estas nuevas formas de trabajar.
 

En resumen

 

La agilidad es una gran oportunidad para tener empresas más competitivas y a la vez disfrutar más de nuestros trabajos, oportunidad que no deberí­amos perder para no quedarnos atrás como país.

 
 

Para saber más

 

 

El expendedor – Juego de simulación de Scrum

“El expendedor” es un juego de 75 minutos para equipos a los que se explica por primera vez Scrum. Permite que hagan una simulación de creación de la lista de objetivos priorizada (Product backlog) y de ejecución del propio proceso de Scrum, de manera que puedan compararlo con el desarrollo tradicional (en cascada/waterfall), comprobando cuáles son los principales beneficios de Scrum, especialmente los referidos a alineamiento con las expectativas del cliente, flexibilidad y retorno anticipado de inversión.

El juego también permite entender diversos conceptos que facilitan el desarrollo ágil: alcance variable, minimizar el número de objetivos en curso (WIP), integración continua de componentes, etc. Para ello, se incluye como factores de complejidad diversos cambios de objetivos durante el proyecto y un problema tecnológico.

Todo ello construyendo un expendedor con papel, tijeras, cinta adhesiva y globos.

expendedor-simulacion-juego-scrum-1
Puedes bajarte las reglas del juego y las tarjetas de objetivos de cada equipo a partir del siguiente enlace. El tamaño del fichero es unos 400 Kb.
descargar-material-juego-simulacion-Scrum

El contexto del juego es el siguiente: nuestro cliente, una gran marca deportiva, quiere lanzar un producto para deportes marinos inexistente en el mercado. Con el fin de dar una mayor imagen de innovación, este producto se venderá mediante un expendedor automático.
Nuestra visión será: Construir un expendedor automático de un producto deportivo.
En el juego participan dos tipos de equipo: un equipo que ejecuta un proceso ágil y otro equipo que NO seguirá el proceso iterativo, sino que construirá el expendedor simulando un proceso en cascada/waterfall tradicional.
La duración del juego es de 75 minutos. Gana el equipo que haya aportado el máximo valor y satisfacción de las expectativas del cliente en el mínimo tiempo.
Roles en el juego
 
Actividades del juego
Minutos
Actividad
Quien
4
Planificación de la iteración: El cliente presenta la lista de objetivos pendientes repriorizada y con nuevos objetivos (a partir de la segunda iteración).
El equipo selecciona los objetivos a completar en la iteración y los miembros se autoasignan tareas.
Equipo y cliente
6
Ejecución de la iteración. Construcción del expendedor*.
Equipo
3
Demostración. El equipo hace una demostración de los objetivos completados*, el cliente los acepta (si cumplen sus expectativas).
Equipo y cliente.
3
Retrospectiva. Identificación de lo que ha funcionado bien y de lo qué es necesario mejorar en el proceso de trabajo.
Equipo
*Definición de hecho (DoD): el objetivo ha sido construido y preparado para ser entregado al consumidor (no queda nada pendiente respecto a ese objetivo y ya está integrado en el expendedor), documentado (con el detalle adicional proporcionado por el cliente y el que sea necesario para facilitar su futuro mantenimiento) y probado (cumple los requisitos que proporcionó el cliente).
 
  • 10 minutos para reflexionar una vez ha finalizado en juego.
 
 
Lista de objetivos/requisitos (product backlog)
Los objetivos/requisitos que debe cumplir el expendedor son los siguientes:
ID

 

Valor

Equivalente web

 

Requisitos iniciales

1

Marca de cliente: El consumidor podrá ver con claridad el nombre de la marca deportiva y una foto o dibujo de temática marina desde una distancia de 3 metros.

1000

Página Home

2

Producto: El consumidor podrá recoger el producto de una cajita específica.

900

Contenidos o servicios de la web

3

Hucha: El consumidor podrá pagar el producto depositando un billete en una cajita específica.

800

Módulo de pago

4

Transporte: Un transportista (por ejemplo el propio cliente) podrá trasladar el expendedor al lugar de venta, una mesa que diste 3 metros, sin que se rompa.

700

Pruebas de estrés y subida a producción.

5

Globos: El consumidor verá en cada uno los 2 laterales del expendedor 3 globos de 40 centímetros de diámetro (6 globos en total), para dar una imagen de diversión del deporte náutico.

300

Estilo de la interfase de la web.

6

Barcos: El consumidor verá en los 2 laterales del expendedor 3 barcos de papel (6 barcos en total), para reforzar la imagen de deporte marino y hacer marketing de próximos productos.

100

Promoción de próximos servicios.

 

Requisitos adicionales para la segunda iteración

 

 

7

Nuestro cliente, al ver los colores con que se está elaborando el expendedor, se da cuenta de que debería predominar el color negro, en línea con la próxima campaña de cambio de imagen corporativa en la que predomina este color.

Color negro: El consumidor verá que el color negro predomina en el expendedor, en línea con la nueva imagen de marca.

600

Cambios de contexto del proyecto, del mercado, entendimiento del producto por parte del cliente.

8

Foto de experto: El consumidor verá en el expendedor una foto de un experto del deporte con un texto donde explique las excelencias del nuevo producto, para dar confianza al consumidor.

200

Sección de marketing de la web.

 

Requisitos adicionales para la tercera iteración

 

 

9

El departamento de marketing de nuestro cliente ha ideado otro producto que es una variante del anterior y tiene mucho interés por saber cual de los dos se venderá más.

Producto adicional: El consumidor podrá recoger otro tipo de producto de otra cajita específica.

500

Nuevos servicios relevantes para la web que aparecen en medio del proyecto y que aumentan mucho su valor.

10

Algunos consumidores han comentado que el expendedor podría ser más atractivo.

Globos grandes*: El consumidor verá en cada uno de los 2 laterales del expendedor 2 globos de 80 centímetros de diámetro (4 globos en total), en lugar de 4 de los anteriores de 40 cm, para reforzar la imagen de diversión del deporte.

150

Mejora del estilo de la web. Asimilable a un “capricho” tecnológico del cliente poco relevante para el producto.
 
Retorno de Inversión (ROI) anticipado
Uno de los mensajes que se quiere transmitir en el juego es que antes de que el proyecto esté finalizado es posible comenzar a recuperar la inversión o obtener feedback de un grupo de clientes o de usuarios beta.

Para tener información real de la acogida de los consumidores respecto al nuevo producto de deportes marinos, así como del concepto de expendedor automático, nuestro cliente quiere hacer una prueba de concepto en tiendas escogidas para tal efecto (equivalente a una salida en beta de una web).

Para ello, cuando se haya conseguido el objetivo 4 (el cliente ha comprobado que es posible trasladar el expendedor hasta el punto de venta sin que se rompa), y si los objetivos 1, 2 y 3 también esté aceptados, cada vez que finalice una iteración (incluyendo la iteración en curso) el facilitador del juego (o el cliente) pondrá dinero de juguete en la hucha y recogerá parte de las tarjetas de productos marinos.

 
expendedor-simulacion-juego-scrum
Comparativa de desarrollo ágil con desarrollo tradicional
Reglas para el equipo “tradicional”
  • Uno de los equipos NO seguirá el proceso iterativo, sino que construirá el expendedor simulando un proceso en cascada/waterfall tradicional con las siguientes fases:
 
ID
Fase
Quien
Entregables
1
Recogida de requisitos, análisis y diseño
JP/analista y cliente.
– Documentos de análisis funcional y diseño técnico.
2
Planificación
JP/analista
– Documento de planificación con tareas, duración y asignaciones.
3
Construcción y pruebas.
Equipo
– Documentación de casos de prueba con sus resultados.
4
Aceptación
JP/analista y cliente.
– Expendedor.
 – Documento de aceptación del proyecto.
 
  • El equipo se descompone en:
    • Jefe de proyecto (JP) / analista. Es el único que puede preguntar y escuchar respuestas del cliente. Con la información que obtiene del cliente elabora la documentación de fase 1.
    • Tester. Elabora la documentación de fase 3.
    • Resto del equipo. Construye el expendedor. Ni el JP/analista ni el tester pueden participar.
  • El JP/analista recibe los objetivos SIN el valor que tienen para el cliente. Por ejemplo, el cliente le entrega lista inicial de 7 objetivos desordenada.
  • El tester y resto del equipo no pueden escuchar al cliente en ningún momento. Antes de empezar la fase 3 deben leer la información generada en la fase 1. Si tienen dudas sólo pueden preguntar al JP/analista, quien preguntará al cliente si es necesario.
  • Las fases se ejecutan de manera secuencial. Para poder finalizar las fases 1 y 3 el cliente debe leer la documentación de la fase y aprobarla mediante firma. Notar que el cliente puede solicitar modificaciones en la documentación, por ejemplo si no está conforme con la descripción del expendedor.
  • El cliente no podrá ver el expendedor hasta la fase 4 (aceptación). Deberá ser aceptado por el cliente mediante firma.
  • Todo cambio debe ser escrito por el JP/analista, planificado y aprobado por el cliente mediante firma antes de iniciarse su desarrollo.
 
Reglas para el facilitador del juego
  • El equipo “tradicional” recibe el requisito adicional 9 (“producto adicional”) en el mismo momento que los equipos ágiles.
  • El equipo “tradicional” recibe los nuevos requisitos 7 (“color negro”) y 10 (“globos grandes”) en la fase de aceptación, dado que hasta ahora nuestro cliente sólo ha leído documentación y no ha podido ver la aplicación real funcionando. En este momento se ha dado cuenta de que estos otros objetivos también deberían estar incluidos para que la subida a producción tenga sentido para su negocio.
  • El juego (construcción del expendedor por los equipos) termina cuando se llega a los 45 minutos (3 iteraciones de los equipos ágiles) o bien después de que el equipo “tradicional” haya desarrollado todos los objetivos y el expendedor haya sido aceptado por el cliente. Notar que el cliente puede solicitar cambios si el expendedor no cumple sus expectativas.
  • Recordar que gana el equipo que haya aportado el máximo valor y satisfacción de las expectativas del cliente en el mínimo tiempo.
 
Métricas
En cada iteración el facilitador del juego elabora las siguientes gráficas para cada equipo:
  • Valor acumulado (suma de los valores de los objetivos completados y aceptados por el cliente).
  • Taskboard de objetivos pendientes.
 
Aspectos sobre los que reflexionar una vez finalizado en juego / Debrief
  • En Scrum el alcance es variable. Dada una fecha donde es necesario entregar el resultado de un proyecto, al cliente le conviene que el equipo trabaje orientado a completar objetivos prioritarios y que sea flexible a cambios. Puede estar más que satisfecho si en la fecha de entrega del producto quedan fuera objetivos poco relevantes, o que hayan sido intercambiardos por otros más importantes.
  • De manera similar, al completar objetivos por orden de prioridad y balancearlos en función de su coste de desarrollo, el cliente dispone de una mejor visión del proyecto y puede solicitar entregas anticipadas con las que comenzar a recuperar su inversión (Return of Investment, ROI).
  • Las demostraciones regulares de producto final permiten que nadie se lleve a engaño respecto a la velocidad del proyecto y a los resultados (producto de que va a disponer). De manera regular los puede ir alineando con sus expectativas y también incorporar cambios de contexto que se produzcan durante el propio proyecto (introduciendo cambios en el inicio de cada iteración y replanificando los objetivos pendientes).
  • Al equipo le conviene trabajar en el menor número posible de objetivos de manera simultánea (minimizar el Work In Progress, WIP), para:
    • Tener más posibilidades de poder completar objetivos cada iteración.
    • Respecto al modelo tradicional, permitir que el cliente haga cambios sobre objetivos futuros, dado que todavía no se ha empezado a desarrollar nada al respecto.
  • Integración continua. Cada vez que el equipo finaliza un objetivo, este debe estar perfectamente integrado y probado de manera que el producto sea susceptible de ser entregado al cliente con el mínimo esfuerzo. Sería un riesgo dejar para el final de la iteración la integración de todos los objetivos desarrollados en ella, dado que podría no quedar tiempo suficiente para arreglar todos los problemas de integración.
Puedes bajarte las reglas del juego y las tarjetas de objetivos de cada equipo a partir del siguiente enlace. El tamaño del fichero es unos 400 Kb.
descargar-material-juego-simulacion-Scrum
Para cualquier mejora en el juego, no dudéis en enviar vuestros comentarios a la dirección contribuir (arroba) proyectosagiles (punto) org
 
Reconocimientos
Este juego obtiene parte de su concepto de los siguientes juegos:
  • El XP Game, donde aparecen los objetivos de construir barcos de papel y globos.
  • El Train Game, donde aparece la idea de que un equipo simule el desarrollo tradicional (en cascada/waterfall), para comparar la velocidad con que proporciona valor al cliente y qué metodología (ágil o tradicional) proporciona un producto que cumple mejor con las expectativas del cliente.
 

Artículos relacionados

Scrum: un proceso de trabajo 3.0

Autor: Xavier Albaladejo

Revisor: João Gama

Scrum es un conjunto de prácticas especialmente combinadas para dar soporte a la creación de productos innovadores y enfocar el trabajo del equipo en producir valor directo para el cliente final. El uso regular de estas prácticas (entregas frecuentes priorizadas por valor, potenciación del equipo de trabajo, mejora continua de producto y de proceso, etc.) permite que los cambios dentro de un proyecto sean aceptados de manera natural y proporciona al cliente margen para flexibilidad e innovación así como productividad y calidad.

Las metodologías tradicionales ya mencionaban las prácticas y conceptos utilizados en Scrum, llegando a utilizarlos en mayor o menor medida y prometiendo también un mejor resultado en los proyectos. Pero una cosa es reconocer que estas prácticas son buenas y otra muy diferente es actuar en consecuencia [1], es decir, utilizar todas estas prácticas situándolas en el centro del proceso. 

  • El desarrollo iterativo e incremental ya existía antes. La diferencia es que en Scrum la planificación del proyecto hace explícitos los objetivos del cliente y los prioriza en función del ROI (Return of Investment), es decir, balanceando el valor aportado al cliente respecto a su coste de desarrollo, y minimizando el trabajo en curso (Work In Progress) necesario para obtener un resultado. Si en las metodologías tradicionales el cliente tenía que esperar a tener todo el valor de un proyecto el último día de la última fase, habiendo acumulando todos los retardos de todas las fases, en cambio con Scrum el cliente puede dirigir de manera sistemática y regular (cada iteración) los resultados que va obteniendo del proyecto. De esta manera (y siguiendo la ley de Pareto en que el 20% del esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto al que sólo le faltan características poco relevantes, puede sacar al mercado un producto antes que su competidor, puede ir adaptándolo mejor a las necesidades de los clientes y hacer frente a urgencias o nuevas peticiones.
  • La orientación a personas ya se practicaba antes, sólo que se basaba en aspectos relacionados con la ejecución de cada persona y condicionados a la subjetividad del evaluador. En Scrum, en cambio, dado que el equipo es multidisciplinar (incluye a todas las personas necesarias para llevar a cabo el proyecto) el planteamiento es de potenciación del equipo (team empowerment), de darle responsabilidad y autoridad para que decida cómo funcionar de la manera más eficiente posible, mejore su entorno de trabajo y pueda mostrar resultados de manera regular, así como permitirle aportar innovación al producto que está desarrollando, cosa que facilita la motivación y realización personal de cada uno de sus miembros.
  • La planificación con tareas, tiempo y personas ya se hacía antes, sólo que en las metodologías tradicionales las tareas, las asignaciones y los tiempos las decidía un jefe de proyecto. Sin embargo, en Scrum la planificación de proyecto se hace orientada a objetivos del cliente (y no a tareas) y la realiza el equipo utilizando técnicas muy rápidas de estimación (por ejemplo planning poker). Asimismo, la planificación de iteración también la hace el equipo, quien identifica y estima de manera conjunta las tareas a realizar y se las autoasigna. De esta manera, las estimaciones son mucho más fiables por que se realizan en base a las experiencias e información de todos los miembros del equipo y dado que las han proporcionado ellos se convierten en compromiso.
  • El control del progreso del proyecto orientado a tareas ya se hacía antes, con el jefe de proyecto preguntando a cada persona el estado en que se encuentran sus tareas. Sin embargo, en Scrum el equipo se compromete y reporta diariamente su avance y problemas respecto al resto de miembros del equipo, con lo que la sinergia, la transferencia de información, de experiencias y de soluciones es mucho más alta. En Scrum, en lugar de un responsable del equipo/proyecto hay un facilitador que garantiza la colaboración entre todos los participantes.
  • La gestión de cambios ya existía antes, era un control férreo para impedir que el proyecto se moviese tanto en alcance, como en tiempo como recursos. En cambio, el planteamiento que se hace en Scrum, es el de aceptar que los cambios son naturales y permitirlos en el inicio de cada iteración (ya que todavía no se ha desarrollado nada respecto a futuros objetivos), una vez se ha demostrado al cliente los resultados obtenidos en la iteración anterior, para darle más flexibilidad en la adaptación del producto a sus necesidades (siguiendo unas reglas de alcance variable que permiten que tanto el cliente como el proveedor ganen [2]).
  • Las retrospectivas y los análisis “post mortem” (para mejorar los proceso de trabajo) ya se hacían antes, sólo que normalmente al final de un proyecto o  de una gran fase. Sin embargo, en Scrum las retrospectivas se hacen al final de cada iteración, de manera que el equipo pueda aprender y sea más productivo dentro del mismo proyecto.
  • El timeboxing era una herramienta conocida anteriormente. La diferencia ahora es el uso de timeboxing para todas las actividades de Scrum, de manera que facilite el enfoque en resultados y la toma de decisiones.
El enfoque de Scrum exige utilizar estas prácticas de manera regular y frecuente para así proporcionar flexibilidad , productividad, innovación y calidad, teniendo como base la colaboración entre las personas que participan. En el pensamiento ágil prima la colaboración y transparencia con el cliente y entre el equipo, para así reducir riesgos, cubrir al máximo posible las expectativas del cliente, mejorar de manera continua los productos y procesos, ganar en creatividad y disfrutar más en la realización del trabajo [3].
 
Aplicar estas prácticas de forma sistemática en el día a día de los proyectos puede no ser fácil (e incluso puede no ser idóneo), bien por que la cultura de la empresa no está alineada (no se trata de una cultura colaborativa [4]) o bien por qué se desconocen las técnicas sobre cómo aplicarlos. Afortunadamente, para iniciarse en el mundo ágil actualmente ya existe abundante material [5], tanto gratuito como de pago, así como comunidades y eventos para el intercambio de experiencias.
 
 
[1] Esta manera alternativa de realizar proyectos proviene de un estudio sobre equipos altamente productivos e innovadores que produjo un cambio de enfoque en la aplicación de estas prácticas.

Para saber más

Agradecer a João Gama, Product Owner y coach, las matizaciones en el enfoque de este artículo.

Agradecer a Gemma Hornos la recomendación del libro de Juan Carrión «Culturas innovadoras 2.0», donde he visto bastante reflejada mi vida anterior y de donde he sacado bastantes ideas para el futuro.

Agile Open Spain en Madrid – 23-24 octubre 2009

El próximo octubre va a tener lugar el primer evento nacional sobre metodologías ágiles organizado por Agile-Spain con la colaboración de la Universidad Politécnica de Madrid. Es un evento gratuito muy participativo (en formato Open Space) de manera que personas expertas puedan intercambiar experiencias así como que aquellos que se estén iniciando o tengan curiosidad por conocer en qué consiste la alternativa ágil puedan preguntar dudas. A continuación se reproduce parte del texto original que aparece en la propia web de Agile-Spain:

agile-spainCon los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

Si quieres:

  • Compartir tus experiencias como experto o principiante en el uso de prácticas Ágiles.
  • Escuchar a algunas de las personas que más saben de metodologías ágiles en España.
  • Encontrar el futuro antes de que éste te encuentre a ti.

entonces, inscríbete aquí (notar que el evento es gratuito pero las plazas son limitadas).

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