Por el momento no tenemos nada “fisico” para mostrar, pero vamos a crear una comunidad en línea de aficionados y amantes del ciclismo.

Como ustedes se imaginarán, queremos hacerla con “todos los juguetes” y eso incluye también la metodología para la gestión del proyecto. Mi hermano sugirió el uso de Scrum y después de leer un poco mas sobre él, me di cuenta que era la mejor alternativa.

Les adelanto que apenas hoy me metí en el cuento de Scrum, por lo que no soy un experto en el tema. Nuestra meta es aprender de esta metodología a medida que vamos trabajando en el proyecto, para que cuando nos toque implementarlo en nuestros trabajos de verdad (aquí o acá) tengamos un poco de experiencia.

Para empezar, les cuento que Scrum se define como una metodología para el desarrollo ágil de proyectos tecnológicos.

En el mundo han surgido muchas metodologías de gestión, las cuales no sólo se han aplicado en proyectos de software sino en labores que requieran empujar átomos y no pixeles como la ingeniería civil.

El problema de algunas de ellas es que encuentra barreras en su aplicación para entornos donde los clientes y el mercado exigen resultados rápidos, donde a mitad de camino es posible que haya un cambio de requerimientos y en fin, todas aquellas situaciones que hacen de nuestro trabajo algo entretenido o completamente frustante (como cuando gracias a un test definimos a nuestro cliente como un completo idiota).

Por esta razón, surgen iniciativas como Scrum, que plantean un modelo ordenado y predecible para llevar a cabo nuestras tareas. Realmente estos modelos apelan en muchos momentos al sentido común, el que créanme, en el desarrollo de software muchas veces falta.

Pero bueno, vamos a lo que venimos, después de definir qué es Scrum, para empezar les cuento lo básico:

Scrum tiene dos elementos: Los actores y las acciones. Los actores se dividen en:

• Product owner: El dueño del producto o quien conoce mas de lo que vamos a hacer. Para el caso de nuestra comunidad, ese soy yo.
• Scrum master: Es el que tiene que velar por que en todo el proceso de desarrollo adoptemos la metodología, en este caso será Cavorite.
• El Scrum team implementa las funcionalidades. En nuestro caso, seremos – por lo pronto – mi hermano (dev) y yo (design).
• Los usuarios o clientes se vinculan en el proyecto aportando ideas. Somos nosotros junto con un par de amigos bikers a los que vamos a contarles nuestra idea cuando tengamos algo que mostrarles.

Ahora bien, Scrum tiene una serie de pasos que a continuación les presento (les repito, aún estoy aprendiendo de este cuento, así que es muy seguro que con el tiempo comparta con ustedes unas definiciones mas completas):

1. Product backlog: Es el listado de requerimientos y responde a la pregunta de ¿Qué espera recibir el cliente?
2. Sprint planning meeting: Define una serie de tareas y un objetivo (entregable o producto) por cumplir.
3. Sprint backlog: Grupo de tareas realistas que el grupo de trabajo (Scrum team) debe cumplir en un plazo de 2 a 4 semanas. ¿Porqué tan poco tiempo? La idea es generar entregables desde el mismo momento en que arranca el proyecto, así tenemos a nuestros clientes y jefes contentos pues saben que estamos trabajando.
   Las tareas deben ser cuidadosamente escogidas, pues se debe buscar cumplirlas en el plazo estipulado, ademas que una vez arranca el Sprint no hay marcha atrás; si una tarea quedó por fuera, lo siento mucho, pero va a un segundo Sprint.
4. Daily scrum meeting: Se trata de una corta reunión diaria donde cada uno de los miembros del Scrum Team cuenta tres cosas: ¿Qué ha hecho?, ¿qué va a hacer el día de hoy? y ¿en qué necesita ayuda del scrum master?
5. Una vez se cumple el Sprint (2 o 4 semanas) se hace una reunión que se conoce como Sprint Review donde se presentan los resultados esperados.
6. En esta reunión se hace un Sprint retroespective donde se revisan los objetivos planteados, se resalta para repetir los aspectos positivos y se determinan cuáles han sido los aspectos negativos.
7. Luego volvemos de nuevo al punto dos hasta cumplir con todos los requerimientos establecidos en el Product backlog.

Como pueden darse cuenta, el modelo es muy sencillo, casi obvio. Pero se trata de un procedimiento ordenado y muy claro. Al aplicarlo, nos dimos cuenta de la casi ausencia de documentación adicional (nada de gráficos y diagramas de flujo).

Personalmente me gusta mucho eso, pero nos dimos cuenta que hace falta un documento que explique objetivos y funcionalidades específicas. En nuestro caso no tuvimos mayores inconvenientes, pues Cavo también se dió cuenta que es mejor en bicicleta.

¿Además de Scrum qué estamos usando?

Queremos que el desarrollo de dandobiela.com sea eficiente (tiempos justos y presupuesto bajo), pues lo hemos tomado como un hobbie donde cada uno esta probando cosas.

Buscamos que la gestión del proyecto sea muy ágil y por tal razón estamos usando Google Docs como herramienta para la documentación y el seguimiento de actividades. No usamos un software de gestión de proyectos ni nada de cosas extrañas. Dado que no nos podemos reunir todos los días, vamos a usar un blog que funcione como bitácora diaria…. ¡Y hasta aquí llegamos! Nada mas.

Mientras el proyecto avance, voy a contarles en carloscaicedo.net y en Seesmic el desarrollo del proyecto y de la adopción de la metodología Scrum. Espero sus aportes y sus opiniones.

..Y si quieren ser usuarios beta que prueben como van las cosas, solo tienen que esperar a que cumplamos el primer Sprint, es decir, en una semana.