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

Comments

En primer lugar felicidades por el exito, que un equipo distribuido entre dos ciudades distintas, sin dedicación plena de sus miembros y trabajando en tecnologías dispares suena a "death march" que tira de espaldas, si habeís conseguido hacer algo que funcione en esas circunstancias desde luego se ha echo un buen trabajo.

Ahora un par de cosas que comentas que me rechinan un poco:

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).

Esto suena un poco a BDUF, más que escribir documentos estos sprints iniciales se pueden utilizar para construir el "walking skeleton" (practica propuesta por alistair cockburn en crystal), que consiste en montar un esqueleto de la arquitectura de la aplicación donde se implementan las historias más simples pero ya se montan todos los componentes de la arquitectura "end-to-end". De esta forma validas realmente la arquitectura echandola a andar y luego si tienen alguna utilidad documentas lo que has echo, la idea es no perder el tiempo escribiendo documentos sin validar las ideas en un sistema real y luego tener que rehacer los documentos cuando al ponerlos en practica descubras que se te olvido tal o cual detalle que echa abajo tus ideas iniciales.

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

Otra idea cuando se construye el walking skeleton es al mismo tiempo construir un entorno automatizado de build, deploy y testing (funcionales, tipo selenium o watir tratandose de un proyecto web) del proyecto, esto puede ser costoso y más en proyectos como el vuestro pero el valor que aporta durante el resto del proyecto es incalculable. Más aún con equipos distribuidos un entorno de Integración, despliegue y testing continuo me parece fundamental.

No penseis que el error esta en "no tener en cuenta las horas de integración", el verdadero error es que estas horas no deberían ser necesarias si se automatiza este proceso.

Hola Alfredo,

Ante todo gracias por tu feedback, seguro que contribuye a mejorar la comprensión de la situación.

El problema de los primeros sprints era que no había absolutamente nada definido, ni qué hacer ni cómo hacerlo, ni quién... partíamos de cero en lo que a requisitos se refería. Lo único que sabíamos era un comentario del director general transmitida hacia abajo: "one year, one platform" y una fecha, 1 de octubre. Ahora vas y te apañas. Posiblemente el error fue haber incluído esas tareas de análisis en el scrum, quizás habría que haberlo comenzado un mes después, pero imagínate el nerviosismo que había en todo el equipo, desde el propio CTO hasta los programadores de abajo de todo. Se empezó el análisis con lo que la gente con más experiencia conocíamos, se plasmó en documentación, en historias de usuario y se comenzó a construir el esqueleto básico tal como tú indicas, pero es que para llegar a ese punto hay que saber, al menos, qué es lo que quieres hacer, cuales son esas historias de usuario más simples, y ese era nuestro problema inicial, no lo sabíamos.

La idea del proyecto suponía un cambio radical en la estrategia tecnológica de la compañía que afectaría a oficinas de más de 50 países y que modificaría el sistema de trabajo de diversas áreas administrativas de la organización. En un principio este proyecto se pensó para abrir una nueva línea de negocio, pero llegados a este momento el requisito era que toda la organización debía trabajar sobre la misma aplicación independientemente de la línea de negocio. Todo esto implicaba que los requisitos a tener en cuenta fuesen muy dispares y se iban descubriendo sobre la marcha. Además, la implicación de los departamentos más interesados fue casi nula, fue la parte técnica la que puso todo su know how, a fin de cuentas es a nosostros a los que nos habían puesto la espada de Damocles sobre la cabeza. Nuestro equipo tenía el conocimiento para el desarrollo de la nueva línea de negocio mientras que el otro equipo lo tenía sobre el negocio in house que se estaba haciendo. Hubo que combinarlo todo y crear una herramienta polivalente.

A partir del tercer sprint ya teníamos una idea aproximada del alcance del proyecto y se comenzó a desarrollar la base, el esqueleto. Obviamente, aunque quizás no se llegue a comprender así en el artículo, la documentación no se escribió completamente al principio y se mantuvo hasta el final sino que se fue modificando y actualizando a medida que el desarrollo avanzaba, recogiendo modificaciones planteadas en las demos, nuevos requisitos que llegaban todas las semanas, etc. A mitad del proyecto se comenzó a enviar información del mismo a las oficinas de los países más interesados en la herramienta con lo que los requisitos comenzaron a llover sobre nuestras mesas. No se escribió ni por asomo una documentación completa sino algo para que los programadores supiesen qué tenían que hacer y cómo. En algunos casos ciertos requisitos o modificaciones implicaron grandes cambios, sobre todo, del modelo de datos, pero para eso se escogió scrum como metodología, no quiero decir, por tanto, que la documentación se cerrase esos primeros sprints.

En la segunda parte de tu comentario no tengo más que darte la razón. Por la parte que nos tocaba a nosotros no teníamos apenas problemas para preparar la demo, sin embargo, la otra parte del equipo, aún no sé por qué, sí que los tenía. Algo que funcionaba perfectamente en el entorno de preproducción les costaba muchísimo replicarlo en el de producción, no puedo dar más detalles porque no los conozco, sólo sé que para ellos las demos eran un infierno, en el cambio de entorno tenían (y tienen) muchos problemas que, la verdad, no alcanzo a comprender. A pesar de que el entorno de testing lo tiene montado y funciona, tienen problemas para la integración en producción. Si los problemas hubiesen sido aislados en algún sprint no habría pasado nada, pero al ser generalizados en todos, creo que se tendría que haber tenido en cuenta el tiempo perdido.

Espero haber aclarado un poco más los problemas que se tuvieron a la hora de arrancar el desarrollo puesto que creo que es lo que más experiencia nos ha aportado durante estos meses.

Tu comentario nos ayuda a enriquecer el articulo

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <tr> <td> <em> <b> <u> <i> <strong> <font> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <strike> <caption>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
Este formulario es para impedir el abuso de spambots.
Image CAPTCHA
Copy the image characters keeping the upper/lower case.