Mi primer proyecto con Scrum

Image from http://www.3news.co.nz
Imagen de http://www.3news.co.nz

En los últimos meses he estado trabajando en un nuevo proyecto. En este proyecto hemos tenido a dos personas externas. Uno de ellos tiene experiencia como Scrum master por lo que el equipo decidió el utilizar Scrum como metodología en el proyecto.
He leído bastante sobre Scrum y he utilizado partes en el pasado pero nunca había utilizado Scrum by the book.

A continuación, voy a comentar de forma resumida mi experiencia utilizando Scrum en este proyecto, que desarrollamos desde cero.
No voy a hablar sobre cuales son las prácticas de Scrum, por lo que si no lo conoces, un buen recurso es:

http://www.scrumguides.org/

donde hay guías oficiales en muchos idiomas, incluido en español.

Cosas buenas

  • Las retrospectivas realmente funcionan. En cada retro hemos ido viendo las dificultades que teníamos y hemos ido mejorando en esos aspectos. En nuestro caso, parte del equipo no trabajaba siempre en la oficina y eso causó problemas de comunicación. Este problema de comunicación disminuyó mucho gracias a las retros, y a los acciones que tomamos después de cada retro.
  • Formamos equipo. Todo el tiempo que pasábamos juntos hablando hizo que nos fuéramos conociendo y que poco a poco formáramos equipo. Soy nuevo en la compañía y no conocía a mis compañeros ni a la gente externa contratada pero gracias a las prácticas de Scrum a los pocos meses formamos un buen equipo.
  • El diseño de la aplicación es entendido por todo el equipo. Las reuniones de sprint permitieron que todos los miembros del equipo entendieran el diseño de la aplicación. El diseño mejoró debido a que las decisiones importantes las tomábamos en conjunto.

 

Cosas no tan buenas

  • Es muy fácil convertir Scrum en una herramienta de control. Podemos controlar hasta el mínimo detalle lo que hace cada miembro del equipo, si en las reuniones diarias solo se comenta el estado de cada uno, y en las retros se miran en detalle las estimaciones, . Es lo que se llama micromanagement. No es algo que halla pasado en el proyecto pero es algo que me di cuenta que podía haber pasado ya que pusimos al principio demasiado énfasis en que las estimaciones fueran las correctas.
  • Mucho feedback al final del proyecto. Al final del proyecto realizamos un test de aceptación en el que participó buena parte de la compañía y recibimos muchos comentarios interesantes. Lo veo como algo negativo porque no tuvimos tiempo para poder añadir los comentarios en la aplicación. Cada dos semanas hicimos demos para la compañía, en donde esas mismas personas que hicieron comentarios, asistieron pero no dijeron nada al respecto.

Además de las puntos comentados anteriormente, podíamos haber aplicado Scrum mejor, ya que, por ejemplo, al terminar el proyecto tuvimos que realizar documentación y otras tareas y deberían haber sido parte del proyecto.
Además, el principal problema que tuvimos con Scrum fue el product owner, debido a que no encontramos a nadie que encajara con el puesto, por lo que una persona sin la suficiente experiencia y poder (de tomar decisiones sobre el producto) tuvo que ejercer esta posición. Debido a ello, el mayor beneficio de Scrum y también de las demás metodologías Agile, que es el maximizar valor, se vio resentido.

Este artículo de Ron Jeffries explica muy bien qué es valor:

http://ronjeffries.com/xprog/articles/value-is-what-you-like/

Este mismo autor, ha sacado un libro con el título The Nature of Software Development que es una maravilla. Son ciento y pico hojas que explican de forma sencilla y sin palabras técnicas en que consiste el desarrollo de software. Perdón por el off topic pero acabo de terminarme el libro y me ha encantado.

Conclusión

Aunque podíamos haber utilizado Scrum mejor estoy contento con el resultado final del producto. Me encanta como ciertas prácticas de Scrum permiten el ir mejorando el funcionamiento interno del equipo y el proceso de desarrollo.

Scrum es una metodología genérica, que se puede utilizar en otros proyectos que no sean de software. Creo que por ello, echo en falta algunas prácticas específicas para programadores, que deberían estar incluidas. Por ejemplo, TDD e integración continua, porque estás prácticas son fundamentales cuando se realiza un desarrollo de un producto de forma iterativa e incremental, como en Scrum.
En este sentido, XP es mucho más completo porque incluye estas y otras prácticas específicas para nosotros, los programadores.