L A EXPERIENCIA S CRUM EN G OOGLE ( DICIEMBRE 2006)

Google ha trabajado siempre con principios de desarrollo ágil: pequeños equipos (tres personas), autogestionados y con elevado nivel de autonomía y capacidad de decisión. Sin embargo el crecimiento de la empresa le plantea retos importantes, porque cada vez son más y mayores los proyectos que tiene en marcha, cuenta con cinco centros de desarrollo repartidos en sedes diferentes, las funcionalidades a implantar se deben traducir a cada idioma, hay que mantener el material de marketing, etc.

Jeff Sutherland trabajó con el equipo del proyecto AdWords de Google para superar estos retos sin abandonar la organización ágil y con la experiencia preparó la charla "Lessons learned at Google" disponible en htttp://qcon.infoq.com/qcon/conference. En ella, tras una breve introducción en la que presenta los cuatro principios básicos del manifiesto ágil y un resumen de su charla sobre el origen de Scrum, da un repaso a los retos de crecimiento de Google.

Describe cómo para dar continuidad al propio espíritu ágil de Google, ha adaptado e implantado principios de Scrum en la organización. Cómo ha encajado la figura del propietario del proyecto o producto y del gestor o director de Scrum.

Los principios de Scrum que ha introducido en la forma de trabajar de Google han sido: • La gestión de los requisitos del sistema (backlog), con priorización y estimación

de cada funcionalidad.

• La reunión de seguimiento diario.

En la charla, comenta las dificultades iniciales. En el primer caso, los errores de los equipos al realizar estimaciones les llevó a retrasos en las planificaciones de desarrollo. Respecto a la resistencia contra las reuniones diarias, que las consideraban innecesarias, y los problemas habituales de tiempo y divagación.

Las prácticas estándar de Scrum que se han modificado para adaptarlas a las características de los proyectos y de la empresa han sido:

• Uso de un wiki para dar soporte a los requisitos del sistema (backlog). • Considerar como criterio de avance (gráficos de quemado o burn-down) la

ejecución de tareas en lugar del criterio estándar de Scrum de la ejecución de funcionalidades.

No se trata por tanto de la implantación del Scrum original en Google, sino del enriquecimiento de las prácticas de Google al incorporar y adaptar prácticas de Scrum.

Como Jeff expone en la charla:

Sabes que no estás realizando desarrollo iterativo cuando:

• Las iteraciones son de más de 6 semanas (Ken Schweber en Scrum Metodology habla de hasta 8 semanas).

• Las iteraciones no tienen el tiempo acotado.

• El equipo intenta cerrar todas las especificaciones antes de programarlas. • Las iteraciones no producen código terminado.

• Las iteraciones no incluyen pruebas. Sabes que no empleas Scrum cuando:

• Los requisitos del sistema (product backlog) no contienen estimaciones.

• No puedes generar un gráfico de avance del trabajo (burn-down) y por lo tanto no conoces la velocidad de avance.

• El equipo no sabe quién es el propietario del producto.

Termina la charla explicando las posibilidades de escalabilidad de Scrum para aplicarlo a equipos grandes que incluso pueden estar geográficamente dispersos, exponiendo brevemente el caso del desarrollo del proyecto ILS de SirsiDynix que presentó en ICCS2006. El video de la charla titulada “Scrum Tuning: Lessons learned at Google” también está disponible en http://video.google.es/videoplay?docid=8795214308797356840.

2.2.5. Limitaciones

Scrum es un método adecuado para equipos pequeños, de menos de 10 programadores. Schwaber y Beedle sugieren un equipo de cinco a nueve miembros del proyecto. Si deben trabajar más personas, deben formarse subequipos.

Pueden encontrarse esfuerzos por integrar XP y Scrum. Scrum proporciona el Project management framework, que se sostiene por las prácticas de XP. Uno de los beneficios de la unión es permitir escalar XP a proyectos mayores.

2.3. Familia de métodos Crystal

La familia de métodos Crystal11, definida por Alistair Cockburn (pronunciado “Coburn”, a la manera escocesa) en [Cockburn 2002], incluye diferentes métodos para seleccionar el más conveniente según cada proyecto en particular. Además de los métodos, el enfoque de Crystal incluye también los principios para adaptarlos a las circunstancias específicas variantes de cada proyecto.

Cockburn se llama a sí mismo etno-metodólogo, debido a su estudio de las “culturas” de los métodos de desarrollo de software. También ha vivido durante 15 años en ciudades de todo el mundo, lo que le ha hecho observar que a pesar de funcionar de maneras muy diferentes, las empresas de todas las culturas acaban funcionando. Considera que lo más importante es la relación entre las personas: “Pon de 4 a 7 personas que sean buenos ciudadanos (comportamiento hacia los otros) en una sala y obtendrás software.” Una de las tácticas que utiliza para trabajar en grupo es interpretar el lenguaje del cuerpo, la comunicación no verbal12.

Para Cockburn, las habilidades de una persona y las políticas (normas del proyecto dictadas por la organización) van en sentidos contrarios. Las políticas son específicas a un proyecto y no se transfieren. Sin embargo, las habilidades (cómo programar y crear tests, cómo diseñar la interfaz de usuario...) sí que son transferibles, aunque algunas, las que llama soft skills, no se pueden enseñar ni aprender.

El autor de los métodos Crystal considera una aberración la ingeniería de software, ya que ingeniería y desarrollo de software son muy diferentes. Por eso, se refiere al desarrollo de software como un juego cooperativo de invención y comunicación: todo lo que se hace es inventar y comunicar esa invención. Los programadores no son sólo su clientela, sino también su grupo de estudio para observarlos y aprender.

Los métodos se llaman Crystal evocando las facetas de una gema: cada faceta es otra versión del proceso, y todas se sitúan entorno a un núcleo idéntico. Hay cuatro variantes: Crystal Clear (Claro o transparente como el cristal) para equipos de 8 o menos integrantes; Amarillo, de 8 a 20; Naranja, de 20 a 50; Rojo, de 50 a 100. En un principio, Cockburn pretendía seguir con Crystal Maroon (100 a 200) o Blue (200 a 500), pero según dijo su creador, hasta que no esté en un proyecto que los necesite, no los crearía. Crystal no soporta equipos distribuidos. La metodología más exhaustivamente documentada es Crystal Clear (CC).

Cada miembro de la familia Crystal utiliza un color para indicar el peso de la metodología: cuanto más oscuro, más pesado. Crystal sugiere elegir el color apropiado para un proyecto basándose en su tamaño y criticidad. Los proyectos más grandes necesitarán más coordinación y metodologías más pesadas. Cuanto más crítico sea el sistema a desarrollar, mayor rigor se necesitará. Los caracteres C, D, E, y L indican las connotaciones que tendría un fallo del sistema (es decir, el nivel de criticidad): Comfort (C), Discretionary money (D),

Essential money (E) y Life (L).

11 _{http://alistair.cockburn.us}

Ilustración 37. Alistair Cockburn.

En otras palabras, criticidad C indica que una caída del sistema (system crash) debida a fallos, causa una pérdida de comfort (comodidad) para el usuario mientras que fallos en un sistema de vida crítico pueden causar literalmente la pérdida de una vida (sistemas de emergencia). Las dimensiones de criticidad y tamaño se representan con un símbolo que indica la categoría. Por ejemplo, D6 identifica un proyecto con un el máximo de 6 personas que entregan un sistema de criticidad máxima de dinero discrecional.

Ilustración 38. Dimensiones de las metodologías Crystal.

Existen ciertas reglas, características y valores comunes a todos los métodos de la familia Crystal. En primer lugar, los proyectos siempre usan ciclos incrementales de desarrollo, con un incremento máximo de 4 meses, pero preferentemente entre uno y tres meses. El énfasis se pone en la comunicación y cooperación de las personas. Los métodos Crystal no limitan cualquier práctica de desarrollo o herramienta, y también permiten, por ejemplo, la adopción de prácticas de XP y Scrum.

Además, la visión de Crystal plasma los objetivos para reducir los pasos intermedios y los desarrolla según evoluciona el proyecto. Las metodologías más comunes son Crystal Clear, y Crystal Orange. Crystal Orange Web no trata con un único proyecto sino con una cadena de iniciativas que luego se juntan.

Los siete valores o propiedades de Crystal Clear son:

1) Entrega frecuente. Consiste en entregar software a los clientes con frecuencia, no sólo en compilar. La frecuencia dependerá del proyecto, pero puede ser diaria, semanal, mensual, etc.

2) Comunicación osmótica. Todos trabajan en la misma sala. El Cono del Silencio se describe como una reunión separada para que los asistentes se concentren mejor. 3) Mejora reflexiva. Tomarse un pequeño tiempo (desde unas horas hasta alguna

semana o una vez al mes) para pensar con profundidad qué se está haciendo, cotejar notas, reflexionar y discutir.

4) Seguridad personal. Hablar cuando algo molesta: decirle amigablemente al manager que la agenda no es realista, o a un colega que su código necesita mejorarse. Esto es importante porque el equipo puede descubrir y reparar sus debilidades. No es provechoso encubrir los desacuerdos con gentileza y conciliación.

5) Foco. Saber lo que se está haciendo y tener la tranquilidad y el tiempo para hacerlo. Lo primero debe venir de la comunicación sobre dirección y prioridades, típicamente con el sponsor o Patrocinador Ejecutivo. Lo segundo, de un ambiente donde la gente no se vea obligada a hacer otras cosas incompatibles.

6) Fácil acceso a usuarios expertos. La importancia del contacto directo con expertos está contrastada. Un encuentro semanal o semi-semanal con llamadas telefónicas adicionales suele ser una buena pauta. Otra variante es que los programadores se entrenen para ser usuarios durante un tiempo. El equipo de desarrollo, de todas maneras, incluye un experto comercial.

7) Ambiente técnico con prueba automatizada, gestión de configuración e integración frecuente. Microsoft estableció la idea de las builds diarias, y no es una mala práctica. Muchos equipos ágiles compilan e integran varias veces al día.

2.3.1. Proceso

Todas las metodologías de Crystal proporcionan pautas de política de estándares, workproducts o artefactos, “local matters”, herramientas, estándares y papeles que se deben hacer en el proceso de desarrollo.

Crystal Clear se dirige a proyectos muy pequeños, de categoría D6, máximo seis programadores. Sin embargo, ampliando la comunicación podría aplicarse a proyectos E8/D10. Un equipo que use Crystal Clear debería estar en un espacio compartido dadas las limitaciones de la estructura comunicativa.

Crystal Orange se dirige a proyectos medianos, de 10 a 40 miembros (categoría D40), y cuando el proyecto dure de uno a dos años. Los proyectos categoría E50 también pueden utilizar Crystal Orange con ampliaciones en los procesos de verificación y pruebas. En Crystal Orange, un proyecto se divide para varios equipos con grupos usando la estrategia de Diversidad Holística (ver 2.3.3). Sin embargo, este método no soporta un entorno de desarrollo distribuido. Crystal Orange enfatiza la importancia del time-to-maket, es decir, el tiempo que se tarda hasta que el producto está en el mercado. El equilibrio entre muchas entregas y cambios rápidos en los requisitos y resultados obliga a reducir el número de deliverables, pero manteniendo la comunicación eficientemente entre los equipos.