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 más grandes los proyectos que tiene en marcha, cuenta con cinco centros de desarrollo repartidos en sedes diferentes, las funcionalidades tienen que implantarse traducidas a cada idioma, hay que mantener el material de marketing, etc.
Jeff Sutherland lleva algunos meses trabajando con el equipo del proyecto AdWords de Google para superar estos retos sin abandonar la organización ágil; y con la experiencia ha preparado la charla "Lessons learned at Google" que dará en marzo en QCon , pero que es posible ver ya sin tener que esperar, porque hace unos días la dio a un grupo de empleados de la empresa y está colgada en Google video.
En ella, tras una breve introducción en la que presenta los cuatro principios básicos del manifiesto ágil y un resumen sumario de su charla el origen de Scrum, da un repaso a los retos de crecimiento de Google. Describe cómo para dar continuidad al mismo 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 y del gestor de Scrum. Los principios de Scrum que ha introducido en la forma de trabajo 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 por los errores de los equipos al realizar estimaciones que les llevó a retrasos en las planificaciones de desarrollo; y en la resistencia a las reuniones diarias, que las consideraban innecesarias, y los problemas habituales de tiempo y divagación en las primeras.
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 (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 de Scrum original de libro 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 no por lo tanto no conoces la velocidad de avance.
- El equipo no sabe quién es el propietario del producto
- Hay un gestor de proyecto que está implicado en el trabajo del equipo.
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 SrisiDynix que presentó en ICCS2006 (v. artículo: En ICCS2006 se afirmará que Scrum es la metodología más eficiente )
Vídeo de la charla "Scrum Tuning: Lessons learned at Google " Blogalaxia Tags: agilidad software scrum google gestión+de+proyectos
|