Categoría: ejemplos

Scrum en clases de Formación Secundaria (ESO)

Anotaciones sobre una de las sesiones que tuvieron lugar en el encuentro de “Clases ágiles en Educación Secundaria”, al que asistieron unos 50 profesores y contó con la imprescindible aportación de Arno Delhij, uno de los creadores de EduScrum, quien nos explicó lo que se muestra a continuación. Muchas gracias Arno por el tiempo dedicado a mostrar otras posibilidades de enseñanza!

clases-agiles-1

¿Por qué Scrum en la escuela?

Por que el aprendizaje tradicional, del siglo XX, basado en logros individuales, puede mejorarse 🙂

  1. En lugar de clases unidireccionales, es mejor si los alumnos tienen autonomía en su manera de aprender y se incorpora diversión. Todo esto redunda en una mayor motivación en el aprendizaje.
  2. Por que el mundo de la empresa está cambiando, de basarse en la individualidad hacia el trabajo en equipos multidisciplinares.

 

El método funciona para proyectos o para asignaturas completas.

 

Roles:

  • Product Owner: Profesor, da los objetivos de aprendizaje con criterios de aceptación, el QUÉ.
  • Equipo: Los alumnos, identifican y hacen el CÓMO.
  • Scrum Master: En el inicio el profesor asume también este rol (dado que los alumnos todavía no conocen el proceso), aunque al cabo de un tiempo se puede llegar a crear el rol de Facilitador del método (y de “creación” del trabajo en equipo) dentro de cada uno (ojo, no confundir con team lead que decide qué trabajo es el que hay que hacer y lo divide en tareas para personas, eso sería la antítesis de lo que estamos buscando, equipos auto-organizados con un facilitador que les ayuda a pensar a todos juntos para obtener un resultado mejor). A las chicas se les suele dar muy bien ese rol 🙂

 

Proceso:

edu-scrum-board

Inicio:

  • Equipos de 4 personas, con diversidad:
    • Niños y niñas.
    • Diferentes skills para poder realizar el proyecto.
    • No amigos!
    • Se pueden autoformar. Ejemplo:
      • El profesor escribe 10 características que tiene que tener el equipo.
      • Cada alumno escribe en un post-it las 3 que más le representan. Detrás escribe su nombre.
      • Anónimamente se crean los equipos, de manera que se cubran al máximo todos los skills necesarios.
    • Los equipos permanecen estables durante el proyecto, o el cuatrimestre. Los niños pueden pedir cambiar los equipos si justifican bien la razón (e.g. necesitan algún skill concreto).
  • Las 2 o 3 primeras clases son para explicar el método a los niños.

 

Ciclos (Sprints):

  • Duración:
    • Por ejemplo de 8 semanas o un cuatrimestre (o lo que sea necesario).
      • En el primer caso, si tuviésemos 3 clases por semana, un Sprint podría contener 18 clases de trabajo real (8 semanas x 3 clases/ semana menos las de hacer el backlog y las de review + retrospectiva). (*)
    • Planificación:
      • Los alumnos identifican las tareas (post-its).
      • Estiman el trabajo de cada tarea, para ver si todo el trabajo les cabe en el Sprint. La estimación es de manera relativa (lo más sencillo es utilizar tallas S, M, L) aunque también se pueden utilizar puntos relativos.
      • El resultado se pone en el tablero del equipo. De esta manera, en la clase se puede ver cómo están avanzando todos los equipos simultáneamente.
      • Una diferencia importante con el método tradicional (donde los contenidos se van descubriendo de manera secuencial, página por página) es que les hace comenzar viendo todo el Sprint (o toda la asignatura) con una perspectiva global.
    • Stand-ups:
      • 5 minutos al empezar cada clase para que los alumnos actualicen el tablero.
    • Diagrama de Burn-down:
      • Permite que el equipo vea cómo va su progreso en el Sprint, si va retrasado (tienen que “ponerse las pilas”) o avanzado (lo cual les motiva también para avanzar más).
      • Puede ser sencillo (no hace falta contar puntos de complejidad de cada tarea/historia), basta contar los postits que todavía no están acabados en el Sprint.
    • Revisión:
      • El equipo demuestra qué ha aprendido. Opciones:
        • Pasar un test (opción “tradicional”).
        • Hacer una “presentación”.
        • Hacer un trabajo (documento).
        • Identificar preguntas de test para el global de los alumnos de la clase.
      • Retrospectiva:
        • Qué les ha funcionado en ese Sprint / qué tienen que mejorar.
        • Cada alumno también puede analizar si está aportando los skills que se suponía que iba a traer al equipo.
      • Y vuelta a empezar del ciclo 🙂

Sobre el rol del profesor

  • El profesor intenta que los niños aprendan cómo hacer el trabajo de la manera más autónoma (crear capacidad de aprendizaje). Un ejemplo sencillo: si hay alguna tarea (CÓMO) que no se están dando cuenta que tendrían que identificar, en lugar de decírselo al equipo, por ejemplo le puede sugerir que vayan a ver los tableros de otros niños, para que vean qué tipo de tareas están generando y reflexionen sobre ello… o les deja que por ellos mismos descubran, al cabo de unos días, que se den cuenta de que les faltaba esa tarea por identificar (lo cuál reforzará su aprendizaje).
  • El hecho de que los alumnos vayan trabajando en las tareas de manera autónoma, donde puede haber momentos en que todos los equipos están trabajando en la clase, proporciona al profesor un tiempo extra para poder ir a ver cómo trabaja cada equipo, solucionar problemas específicos que esté teniendo, una atención más a medida.

 

Y una idea adicional: el aprendizaje es tanto mayor conforme tiene un propósito (por ejemplo un proyecto) y si además ese proyecto es multidisciplinar (confluyen varias asignaturas), por ejemplo ¿cómo funciona un teléfono móvil? (matemáticas, física, química, sociales, …).

 

(*) Este método de trabajo es más productivo que la clase tradicional, produce mejores resultados de aprendizaje y además… hace crecer los soft skills de trabajo en equipo!!

 

Finalmente, y en línea con las ideas con que empieza este post,  lo más importante no ha sido tanto conocer el método si no ver que hay profesores realmente motivados en mejorar el sistema de aprendizaje de los niños, para crear mejores personas en el futuro, más preparadas y con más habilidades para tratar unas con otras, profesores que han dedicado su tiempo personal de un sábado por la mañana para aprender y compartir. Muchas gracias a todos por este esfuerzo para hacerlo real, y a la organización y ponentes por contribuir a este propósito.

 

Si eres profesor y has llegado hasta aquí leyendo, sería estupendo si pudieses poner en práctica alguna de estas ideas. “¿Por qué no probarlo?” 🙂

clases-agiles-2

Para saber más:

  • Las anteriores notas son fruto de la asistencia a una sesión de 20 minutos (muy resumida) sobre cómo funciona eduScrum (una adaptación de Scrum para el ámbito educativo). Para una visión completa del método, consultar la Guía en español de EduScrum así como la propia web de EduScrum, con videos y otros materiales.

 

La empresa Ágil

A continuación se muestran los principios básicos de funcionamiento y organizativos de una empresa ágil.

 empresa-agil-principios

equipos-multi-disciplinares

equipos-auto-organizados

 equipos-estables

conectar-no-coordinar.jpg

 principios-trabajo-equipo

simplicidad.jpg

ley-conway

celulas-autonomas

 organizacion-flujo-valor

 celulas-responsables

aprender-mejorar

manager-facilitador-organizativo

 lugar-motivante

motivacion-intrinseca

mundo-complejo

agile-menor-complejidad


Artículos relacionados

Productividad y ejemplo de organización ágil

 

La mejora de la productividad está en boca de todos, pero …

¿Qué entendemos por productividad?

… ¿todos pensamos en el mismo concepto? ¿Sabemos medirla? ¿Qué alternativas tenemos a las palancas “tradicionales”?

Para conseguir grandes mejoras en productividad, no basta con eficientar lo que ya hacemos, tenemos que hacer cambios profundos en la manera en que entendemos las organizaciones.

Por otro lado, es necesario volver a las raíces:

Lo que hace ganar dinero a una empresa son los productos / servicios que proporciona a sus clientes.

Para que la cadena de valor sea efectiva, se necesita máxima comunicación en todas las personas que contribuyen a la creación, operación, servicio y soporte sobre un producto. Para ello, es fundamental hacer pivotar a la empresa alrededor de los productos que proporciona, cambiando el sistema productivo e introduciendo nuevos modelos mentales y culturales que apoyen ese cambio.

En la CAS2013 – Conferencia Agile Spain 2013  se desarrolló  una ponencia al respecto con los siguientes contenidos:

 

Visión de la productividad

Una visión más allá de la común “unidades entregadas” o “complejidad resuelta” por lapso de tiempo.

productividad

 

 

Factores de mayor impacto en la productividad

Factores de mayor impacto en la productividad (fruto del análisis de diversos estudios sobre centenares de proyectos) con el objetivo de hacer reflexionar sobre cuáles no se está actuando lo suficiente, qué factores son irrenunciables y qué sería conveniente priorizar en equipos y empresas.

factores-productividad

 

 

Modelo organizativo Agile – Lean para una empresa ágil.

enterprise-improvement-backlog

 

 

Framework Agile – Lean de mejora de productividad

Principios y prácticas en el marco del modelo de empresa ágil anterior.

organizacion-procesos-tecnicas

cultura-competencias-motivacion

 

 

Cuadro sencillo de métricas balanceadas

Conjunto de métricas para evaluar el efecto productido por los cambios realizados sobre los factores de productividad.

cuadro-mandos-balanceado

 

 


 

La presentación completa en español (con las últimas actualizaciones) se puede encontrar aquí.

Please find English version here.

CAS2013-presentacion-modelo-organizativo-productividad

El video de la ponencia, donde se explican los slides, se puede visualizar aquí.

CAS2013-agile-lean-productivity-improvement-framework-video

 

Artículos relacionados

 

Video y slides de la mesa redonda sobre Agile en PYMEs

 

Enlace a los slides de introducción a Agile y Lean: http://www.slideshare.net/xalbaladejo/breakfast-la-salle-agile-y-lean-v10-11647149

Enlace al video de la mesa redonda: http://www.youtube.com/watch?v=tL7sWkROOuA

 

El 14 de febrero tuvo lugar en La Salle de Barcelona una mesa redonda donde se habló de Agile en PYMEs: factores críticos de éxito, beneficios, dificultades y cómo superarlas.

scrum

La mesa redonda contó con la participación de:

  • Adrian Perreau de Pinninck, Artificial lntelligence Researcher y Project Manager de Intelligent Pharma
  • Miquel Mora, CIO y socio fundador de yaencontre.com
  • Carlos Iglesias, consultor tecnológico y en marketing online, co-fundador de Runroom.
  • Laurentiu Neamtu, coordinador del postgrado Métodos Ágiles en La Salle Campus Barcelona y director del capítulo Barcelona del Project Management Institute (PMI).

La mesa redonda fué moderada por Xavier Albaladejo, profesor de La Salle Campus Barcelona así como Agile-Lean Coach y experto en Gobierno TI de everis.

Los ponentes hicieron tangibles los planteamientos ágiles con historias reales, cercanas, desde la experiencia, hicieron “tocar” al casi centenar de asistentes cómo trabajan con Scrum y Kanban en sus PYMEs, mostrando que hay otra manera de entender el trabajo, en la cual se puede dar un servicio mejor a tus clientes y, a la vez, disfrutar en tu día a día. Con este objetivo, paso a paso, se pueden ir cambiando los modelos productivos de las PYMEs, con planteamientos que pueden ser diferenciales y que, a la vez, favorecen la innovación.

breakfast-la-salle 

 

Enlace a los slides de introducción a Agile y Lean: http://www.slideshare.net/xalbaladejo/breakfast-la-salle-agile-y-lean-v10-11647149

Enlace al video de la mesa redonda: http://www.youtube.com/watch?v=tL7sWkROOuA

 

Artículos relacionados

 

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

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 completado: 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
  • 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

Técnicas ágiles y CMMi nivel 2 en un proyecto de Banca

Introducción

Recientemente en Biko obtuvimos la certificación CMMI nivel 2. Tras un periodo de estudio de los procesos convenientes para el funcionamiento de la organización, estos fueron validados y aprobados mediante el SCAMPI.

Este nivel de la metodología formal se centra en determinadas áreas, como planificación, gestión de requisitos, métricas, y verificación y validación.

En Biko, CMMI ha servido para uniformizar criterios importantes sobre la gestión de los  proyectos, que dada la heterogeneidad de los múltiples proyectos desarrollados en la organización, ha sido un hito muy importante.

Pero CMMI en su nivel 2 no especifica nada sobre las metodologías de desarrollo o gestión del equipo, ni del proceso concreto de creación de software. Es por eso por lo que hemos ido un paso más allá, y hemos buscado técnicas para el mejor control del desarrollo.

Las metodologías ágiles de desarrollo van hacia otro objetivo que las metodologías formales. Se centran en los individuos y sus interacciones más que en procesos y herramientas. Algunas de las más importantes son las basadas en el concepto de “Lean development”, u otras más concretas como pueden ser “Scrum” y “XP”.

Nuestra idea era empezar a experimentar con los desarrollos con metodologías ágiles, en concreto con Scrum, para poder mejorar la eficiencia del equipo. En este artículo presentamos la primera aproximación que realizamos, nuestra implementación y conclusiones.

 

Escenario

Tras un proyecto desarrollado con algunos problemas para un cliente de Banca, se nos plantea hacer un segundo desarrollo. Es entonces cuando buscamos la solución que mejor pueda solucionar los problemas encontrados anteriormente.

Los problemas a los que intentamos dar solución:

  • Pérdida de control del proyecto por los desarrolladores. Conocen parte del proyecto, pero a veces repetimos soluciones diferentes para el mismo problema.
  • Se intentó entregar por iteraciones, pero estas nunca quedaban definidas, y pronto se perdió el control exacto de las funcionalidades incluidas en cada entrega.
  • Las peticiones de cambio generadas por un cliente muy pendiente del desarrollo del proyecto, eran muy numerosas. La gestión de requisitos mediante una hoja Excel no ayudaba demasiado.
  • El cliente quedó medianamente satisfecho con el producto final, pero éste quedó con carencias importantes. Además, la etapa de desarrollo fue muy dura tanto para el equipo como para el cliente.

Organización y Gestión

Para el segundo proyecto nos planteamos utilizar metodologías ágiles, para mejorar la eficiencia del equipo. ¿Por qué? Estos son algunos de los puntos que tomamos en cuenta como punto de partida, donde las metodologías ágiles podían ayudarnos más:

Como primera experiencia nos basamos en Scrum. Pero no la implementamos al 100%, realmente la adaptamos. Así que “no decimos que usamos Scrum”. Pero, ¿por qué lo modificamos?

  • El alcance ya estaba definido con el cliente. Los contratos a precio cerrado no son el mejor encaje para las metodologías ágiles.
  • Requeríamos un análisis previo, para la validación por el cliente, una fase inicial donde estudiásemos la globalidad del proyecto. En ese momento nos pareció la mejor solución para evitar los continuos cambios que se habían sucedido anteriormente. Cerrar el alcance en el inicio de una manera más clara no es un concepto demasiado ágil, pero las presiones por las desviaciones en proyectos anteriores nos hicieron pensar que podía ser útil.

Como este proyecto era la continuación tecnológica de uno anterior, minimizábamos el riesgo, y podíamos extrapolar mejor las conclusiones de la implantación.

  • Proyecto tecnológicamente conocido: El primer proyecto fue el que estableció las bases tecnológicas, y salvó los escollos más importantes en esta área. Teníamos mucho trabajo por hacer, para mejorar la plataforma creada, pero consistía en refactorizar elementos.
  • Cliente recurrente: conocíamos cómo trabaja, y podíamos adaptar nuestra manera de desarrollar para su satisfacción.

El equipo

El equipo, visto desde el prisma de sus roles tradicionales ha sido: dos desarrolladores, un diseñador, y un analista funcional y un jefe de proyecto. Realmente el equipo que trabajó bajo las premisas de gestión ágil de dedicación a tiempo completa al proyecto fueron todos excepto la gente de diseño, puesto que trabajaron en momentos más puntuales.

Los perfiles eran bastante distintos en cuanto a experiencia, conjugando dos personas con un año escaso, con otras de casi 10 años en el desarrollo de software. La autogestión del equipo fue un hecho desde el primer momento, teníamos claro qué tareas se debían realizar, y cada persona era autónoma para decidir cuáles realizar, compartiéndolo con el equipo o discutiéndolo. Las reuniones diarias y de planificación de iteración (Sprin) eran una asignación de tareas por acuerdo.

Desarrollo

La idea inicial era utilizar Scrum para el desarrollo del proyecto. Sin embargo, echando la vista  atrás no podemos decir que lo hayamos utilizado, puesto que hemos hecho modificaciones importantes, y no hemos aplicado todas sus técnicas.

Antes de empezar el ciclo de iteraciones hicimos una fase cero del proyecto:

  • Arranque del proyecto: Preparación del catálogo de requisitos (Product Backlog).
  • Fase 0: Análisis funcional, y diseño de la interfaz y su arquitectura. Esta fase fue requerida por el cliente para su validación.
  • Fase N, Iteraciones semanales: Trabajo definido por el equipo. Cierre con demostraciones de la versión y puesta en desarrollo para el cliente.

Nuestro grado de avance y situación lo llevamos simultáneamente en una herramienta de gestión de proyectos (JIRA) y en una pizarra blanca:

image005(1)

  • La pizarra proporciona una inmediatez del trabajo efectuado/restante que da una sensación de control del proyecto muy importante. Es un mapa del site que se puede ver con solo girar la cabeza, y ¡no hay que hacer un solo click! Scrum recomienda un tablero de tareas con “post-it”, pero creemos que esto es igual de útil.
  • JIRA nos proporciona soporte para asociar a las tareas documentación, partes de horas, comentarios de los desarrolladores, enlaces al código de Subversion…, a costa de un mayor gasto de gestión, pero que, una vez habituados a la herramienta, es muy escaso. Además también nos proporciona el EDT (Estructura de Desglose de Tareas) actualizado, basándonos en las tareas cerradas/abiertas y sus estimaciones.

    También sustituimos la gestión de cambios de requisitos, pasando del “Excel” a la gestión de tareas identificadas como “Nuevos Requisitos” en JIRA.

Por tanto, teníamos la información duplicada, en la pizarra y en JIRA, pero el coste de mantener ambos no es elevado. La pizarra proporciona inmediatez en la visión del proyecto, y JIRA nos proporciona trazabilidad con el código.

Por cada iteración definíamos qué trabajo íbamos a realizar para entregar (Sprint Backlog) como resultado de esa semana (Sprint).

Cada 15 días, además, realizábamos una reunión de seguimiento con las personas no directamente implicadas: gerente y diseñador. Estas reuniones se hacían de manera bastante informal, pero eran una práctica acordada en el desarrollo de CMMI. Daban más visibilidad del desarrollo a las partes implicadas.

Conclusiones

Este ha sido un proyecto de introducción de novedades en gestión del equipo de desarrollo de software. Estamos aplicando por ejemplo en otros proyectos una aproximación mucho más estricta de Scrum. Pero he aquí algunas conclusiones que podemos extraer:

  • Las iteraciones semanales son demasiado cortas. Este proyecto era de duración reducida, pero unas iteraciones tan cortas introducen mucho “ruido” del cliente demasiado cerca de la siguiente finalización de la iteración.
  • No aceptar cambios en el plan de iteración (solo corrección de “bugs” de la iteración anterior, para lo que se deja un tiempo) es una gran idea. Puedes controlar cómo funcionas respecto a tu planificación.
  • El equipo controla todas las partes del desarrollo. Las reuniones diarias de 10’ son puestas como ejemplo y destacadas por los integrantes del equipo como una maravillosa práctica. Los perfiles de menos experiencia se benefician en gran medida de las reuniones diarias, donde se les resuelve el 90% de sus problemas. Nunca se bloquean en un trabajo más de 8 horas sin que el equipo lo sepa. Todo el equipo involucrado ha destacado la utilidad de las reuniones diarias, especialmente la gente con menos experiencia.
  • El problema de un proyecto con horas cerradas sigue pendiente. Tienes unas horas de una estimación inicial al inicio de proyecto, que engloban a todas las funcionalidades, y realmente no ves y estimas adecuadamente las tareas hasta el principio de cada iteración.
  • La primera iteración o fase 0, es muy interesante, porque proporciona una base común para el trabajo posterior. En este caso no teníamos problema para la solución técnica, pero si no hubiese estado hecha en un proyecto anterior, posiblemente la hubiésemos planteado aquí. De esta manera podemos establecer una base de cómo realizar las cosas, útil especialmente trabajando con desarrolladores más inexpertos.

 

Artículos relacionados

 

El jardín (un ejemplo de Scrum fabulado)

La nueva propietaria de la casa de campo se dio un paseo por los jardines. Algunas partes estaban en muy mal estado. Llamó a su capataz y le dijo lo preocupada que estaba: se había comprometido con su circulo de negocios a dar una recepción en un mes, y tenía serias dudas de si eso sería posible.

Esa misma mañana, el capataz hizo unas cuantas llamadas a otros colegas suyos. Le confirmaron que, aunque contratase a la mejor empresa de jardinería de la provincia, tenerlo todo listo le llevaría como mínimo dos meses. Tan sólo la elaboración del plano del nuevo jardín, con el detalle de las diferentes zonas, tipos de plantas y ornamentos, le llevaría casi tres semanas, contando con que la propietaria pudiese dedicar suficiente tiempo a la revisión y aprobación del estudio.
 
El capataz se dirigía al despacho de la propietaria cuando el teléfono sonó. Uno de sus colegas había recordado que un amigo suyo había pasado por un problema similar y que se lo había resuelto una nueva empresa de jardinería que trabajaba de una manera bastante diferente a las demás. El capataz se hizo con el teléfono y los llamó.
 
El planteamiento que esa empresa le ofrecía era el siguiente: vendría un equipo de 7 personas, cada una especializada en áreas concretas de creación de jardines. Se entrevistarían con la propietaria durante una mañana entera para entender qué era lo que necesitaba y conocer mejor cómo era el jardín. Como resultado, redactarían una lista con las cosas que la señora necesitaba. En este punto, sería muy importante lo siguiente:
  • Explicarían a la propietaria cuantos días de trabajo serían necesarios para hacer cada elemento del jardín. Con esta información, y conociendo el servicio que cada uno de estos elementos ofrecería, la señora debería elegir en qué orden se debería arreglar el jardín, concentrándose sobre todo en tener el máximo de cosas importantes en la fecha de la recepción.
  • Cada 15 días el equipo enseñaría a la propietaria los elementos del jardín que habría podido completar. Viendo el progreso real del trabajo, la señora no se llevaría a engaños. Además podría realizar ajustes de lo que le enseñasen (de hecho, ella todavía no se veía capaz de imaginar cómo quedaría todo el jardín) y, lo que era mejor, podría cambiar sus ideas sobre las siguientes zonas, tipos de plantas y ornamentos, dado que todavía no se habría empezado a trabajar en ellos. Únicamente necesitarían una mañana para enseñarle el estado del jardín y entender (tanto ella como el equipo) cuáles deberían ser los objetivos de la siguiente quincena. Durante este tiempo también sería necesario poder contactar con ella para preguntas puntuales.
  • Por otro lado, el equipo no conocía bien los problemas con que podría encontrarse en una vez en el jardín: canalizaciones de agua en peor estado del que esperaban, aptitud de las tierras y orientación respecto a los nuevos tipos de plantas deseados, búsqueda de herramientas específicas en las que todavía no podían pensar, etc. Por esto, al principio de cada quincena sería el propio equipo quien decidiría cuántas cosas se vería capaz de completar. Durante este tiempo, y para poder respetar el compromiso adquirido, sería muy importante que la propietaria no realizase cambios sobre lo que se acordó hacer. Es decir, antes de cada quincena la señora debería tener claro qué sería lo más importante para ella. El propio equipo la ayudaría, si fuese necesario.
El capataz pensó que estas reglas eran bastante razonables y que, con esa manera de trabajar, su jefa podría tener el mejor jardín posible para la recepción que tenía que dar en un mes, con lo que contrató a la empresa.
 
El equipo se reunió con la señora durante toda una mañana. A partir de las necesidades de la propietaria se elaboró una lista de 50 puntos con los elementos de jardín y tareas que las cubrían. Para estimar rápidamente cuantos días de trabajo serían necesarios para completar cada punto, su jefe los iba leyendo en voz alta y ellos indicaban con las manos el número de días de trabajo. Si había una diferencia importante entre lo que decían dos personas, cada uno de ellos explicaba en qué se había basado su estimación. Finalmente, se vio que para arreglar todo el jardín serían necesarios dos meses y medio aproximadamente.
 
La señora escogió qué puntos necesitaba que estuviesen listos en la fecha de la recepción, es decir, en un mes. Debían incluir arreglar las partes más importantes de los jardines de la entrada principal, el acceso hasta la casa y la parte de detrás de la casa. En los laterales apenas se haría nada: allí donde tuviese que pasar un número alto de invitados se haría un arreglo rápido para dar un aspecto más regular, siempre que ese arreglo fuese el máximo de compatible con el trabajo a realizar en esa zona en la siguiente quincena .
 
El equipo preguntó y acordó con la señora los detalles necesarios para empezar el trabajo de los primeros quince días (los jardines de la entrada principal y la parte de detrás de la casa, donde se haría el convite, cosas que representaban los primeros 10 puntos de la lista). El equipo después realizó un plan de trabajo: detalló la lista de tareas necesarias para poder completar cada uno de los elementos que habían escogido con la propietaria, se repartieron las tareas y se pusieron a trabajar.
 
Cada día por la mañana, nada más llegar, el equipo se juntaba 10 minutos. De pie, se explicaban en qué cosas habían estado trabajando el día anterior, en qué iban a trabajar ese día y qué problemas tenían. Tras esa mini reunión, algunos seguían pensando sobre cómo resolver alguna situación concreta, mientras que su jefe llamaba por teléfono a su empresa, proveedores de maquinaria o herramientas, o iba directamente a hablar con el capataz para conseguir algo que su equipo necesitaba.
 
El equipo decidió rehacer las canalizaciones de sólo esas primeras zonas y de la bomba de riego que conectaba directamente con ellas. No rehizo las canalizaciones circundantes, sino que hizo lo mínimo necesario para que siguiesen funcionando y que no fuese difícil poner las nuevas cuando la señora decidiese la quincena en qué trabajar en esas zonas no prioritarias.
 
Tras los primeros 15 días, recorrieron el jardín con la señora enseñándole lo que habían completado. Sólo había quedado por terminar 1 punto de los 10 primeros acordados. La señora pensó que en la siguiente quincena (en la que el jardín debería estar listo para la recepción) era más importante no hacer el punto pendiente y escoger bien los siguientes. El equipo consensuó con ella hacer sólo 9 puntos de la lista y así asegurar más la calidad de cara a la recepción. Después de hablar con la propietaria, los miembros del equipo dedicaron un par de horas a analizar cómo habían estado trabajando esa quincena, qué problemas eran los más importantes que se estaban encontrando de manera repetitiva (y que habría que resolver en la siguiente quincena) y qué nuevas técnicas o alternativas querían probar.
 
En el día previo a la recepción apenas hubo que hacer unos retoques finales del trabajo realizado en la segunda quincena.
 
La recepción fue todo un éxito. Los invitados felicitaron repetidas veces a la propietaria por los hermosos y acogedores jardines de su casa, cosa que la hizo sentir especialmente bien.
 
Cada quincena el equipo repitió el mismo proceso: daban una vuelta por el jardín con la señora, le enseñaban cómo habían resuelto cada punto de la lista, consensuaban cuales serían las cosas más importantes a hacer en la siguiente quincena y preguntaban el detalle necesario. Cada vez el equipo conocía mejor el jardín, con lo que su velocidad de trabajo (y el número de elementos que completaba) era mayor.
 
Llegó la última quincena de trabajo. Los puntos que quedaban en la lista apenas tenían importancia. La propietaria pensó que no valía la pena perder tiempo y dinero en detalles que apenas nadie tendría en cuenta. Por el contrario, le convenía más hacer un gran cambio en una zona del jardín en la que ya se había trabajado: necesitaba darle un aspecto un poco más oriental, ya que tras la recepción había empezado a hacer negocios con personas de China y Corea, y sería muy distendido tener conversaciones con ellas en aquella parte del jardín.
 
La propietaria había entendido que la flexibilidad para hacer cambios y el hecho de tener un jardín siempre preparado para nuevas recepciones era lo que más se adaptaba a sus necesidades, con lo que convocó al equipo para contratar y planificar los siguientes meses de trabajo.
 
 

Otras fábulas y ejemplos

 

 

Recursos sobre Scrum

Los siguientes recursos están más enfocados al desarrollo de software, aunque se pueden extraer técnicas y conceptos aplicables a otros tipos de negocio:

 

Sitios web

 

Cursos

 

Libros

 

En español:

En inglés:

    • The Agile Samurai: How Agile Masters Deliver Great Software –  Jonathan Rasmusson
    • Succeeding with Agile: Software Development Using Scrum – Mike Cohn.
    • Collaboration Explained: Facilitation Skills for Software Project Leaders – Jean Tabaka. Cómo ser un buen Facilitador y cómo guiar actividades de colaboración y trabajo en equipo (como las de Scrum).
    • Agile Estimating and Planning – Mike Cohn.
    • User Stories Applied: For Agile Software Development – Mike Cohn. Técnicas para la creación de la lista de requisitos priorizada (Product Backlog).
    • Agile Retrospectives: Making Good Teams Great – Esther Derby.
    • The Art of Agile Development – James Shore, Shane Warden.
    • Agile Software Development with Scrum – Ken Schwaber.
    • Agile Project Management with Scrum – Ken Schwaber. Experiencias de solución de problemas aplicando Scrum.
    • Agile Adoption Patterns: A Roadmap to Organizational Success – Amr Elssamadisy. Técnicas y estrategias de implantación en función de los principales problemas de negocio a resolver.
    • The Enterprise and Scrum – Ken Schwaber. Cómo escalar y implantar Scrum a nivel organizativo.

Adicionalmente a los libros anteriores, la biblioteca de agile-spain contiene referencias a libros de relacionados con el desarrollo ágil de software: ingeniería, eXtreme Programming, Lean Software Development, etc.

 

Presentaciones

 

Blogs

 

Podcasts

  • Podcast sobre el postgrado en métodos ágiles (Scrum, Lean, Kanban, XP).
  • Principios de agilidad – JavaHispano Podcast – 045 – El manifiesto del desarrollo ágil, el valor de las personas, incrementar la comunicación y la confianza, la disciplina, automatizar lo más posible y evitar la grandes tareas con largos plazos creando más iteraciones con tareas más pequeñas.
  • Principios básicos de Scrum – 32 minutos.net – 02
  • Agilidad vs PMI  – Java @ Chile # 6 – Que es la Agilidad, Cual es el origen de la Agilidad, Diferencias entre PMI y Agilidad, Se puede aplicar PMI Ágil.
  • Por qué cuesta introducir la agilidad – Java @ Chile # 7 – Diferencias entre la gestión normal y la gestión ágil, Por que en chile cuesta la agilidad, En que están las Universidades con la Agilidad, Cual es el futuro de la comunidad Chile Ágil.