SCRUM funciona!

En esta oportunidad quiero compartir mi muy agradable experiencia de implementar Scrum como metodología de gestión de proyectos en OLX.

ScrumCycle

Introducción

Empezaré presentando algunas definiciones para ponernos en tema:

  • Scrum es un proceso ágil de desarrollo de software, iterativo e incremental. En cada iteración se hacen variadas actividades de análisis, diseño, desarrollo, testing, implementación.
  • Scrum está enfocado a la gestión de los procesos de desarrollo y puede o no estar implementado en conjunto con otras prácticas ágiles como ser Extreme Programming (XP), Continuous Integration, Test Driven Development, etc.
  • Scrum suele vincularse al desarrollo de software, pero su aplicación es adecuada dentro de las especialidades más variadas que podamos imaginar.
  • Scrum es “liviano”, presenta simplemente un modelo de referencia que describe un conjunto de prácticas y roles que puede tomarse como punto de partida para definir el proceso de desarrollo.

Roles que Scrum propone:

  • El Scrum Master: Se asegura que se sigan los procesos, trabajando de forma similar al director de proyecto.
  • El Product Owner: Representa a los Stakeholders (clientes internos o externos).
  • El Team: Incluye a los desarrolladores, testers, diseñadores, analistas, etc.

Prácticas que Scrum propone:

  • Se realizan ciclos (o iteraciones) de duración fija llamadas Sprints. Se recomienda que la duración de un Sprint sea de 2, 3 o 4 semanas.
  • Durante el Sprint el objetivo del equipo es generar un incremento visible, utilizable, entregable.
  • Al inicio de cada Sprint se realiza una Planning Meeting durante la cual se revisa el Backlog de proyectos (listado de requisitos de alto nivel pendientes, previamente priorizados por el Product Owner). En esta reunión el Product Owner identifica los proyectos que quiere resolver y los describe al equipo. Entonces, el equipo determina cuáles de estos proyectos pueden ser comprometidos para el Sprint.
  • Durante el transcurso del Sprint no se puede modificar el alcance del mismo, es decir, se intentará mantener congelados los requisitos hasta que el mismo finalice. En la práctica, nos hemos reservado parte de nuestro tiempo para lidiar con urgencias que no pueden esperar un ciclo para ser resueltas.
  • Diariamente se realiza una Daily Meeting que no debe durar más de 15 minutos, donde cada persona del equipo comparte las tareas realizadas, lo que piensa hacer hasta la reunión del día siguiente y si se ha topado con algún impedimento que no le permita avanzar de acuerdo a lo comprometido.
  • Al final del Sprint, luego del Deploy / Release / Incremento en el producto, se realiza una Retrospective Meeting durante la cual el equipo comparte libremente opiniones sobre las cosas que salieron bien (y desean repetirse a futuro) y las cosas que salieron mal (y deben evitarse a futuro).

Ahora si, pasemos a mi historia…

Sigue leyendo

Tres ingenieros de Apple y tres ingenieros de Microsoft

Apple vs WindowsTres ingenieros de Apple y tres ingenieros de Microsoft deben viajar en tren a una conferencia.

En la estación, los tres ingenieros de Microsoft compran sus tres pasajes y ven como entre los tres ingenieros de Apple compran un único boleto.
“¿Cómo piensan viajar tres personas con un solo pasaje?” pregunta un ingeniero de Microsoft. “Mira y verás”, responde el ingeniero de Apple.

Todos suben a bordo del tren. Los ingenieros de Microsoft toman sus respectivos asientos, pero los tres ingenieros de Apple se meten todos juntos en uno de los baños y cierran la puerta detrás de ellos. Poco después de que el tren ha partido, el conductor comienza a recoger los boletos. Llama a la puerta del baño y dice: “Pasaje, por favor.” La puerta se abre sólo apenas y un solo brazo emerge con el billete en la mano. El conductor se lo lleva y se va. Los ingenieros de Microsoft ven esto y concuerdan en que era una idea muy inteligente.

Así es como después de la conferencia, los ingenieros de Microsoft deciden copiar los ingenieros de Apple (como siempre) en el viaje de regreso y ahorrar algo de dinero.
Cuando llegan a la estación, compran un solo pasaje para el viaje de regreso. Para su asombro, los ingenieros de Apple no comprar ningún boleto.
“¿Cómo van a viajar sin billete?” , pregunta perplejo uno de los ingenieros de Microsoft. “Mira y verás”, responde un ingeniero de Apple.

Cuando abordan el tren los tres ingenieros de Microsoft se meten en uno de los baños y los tres ingenieros de Apple entran a otro baño cercano. El tren parte. Poco después, uno de los ingenieros de Apple sale de su baño y se acerca al de los ingenieros de Microsoft. Llama a la puerta y dice: “Pasajes, por favor”…

Metodologías amigas – Metodologías enemigas

Supongo que fue a finales de los años ’90, que trabajando en el Banco Hipotecario con un equipo analistas y programadores a mi cargo, empecé a interesarme en el tema de las metodologías de desarrollo de software y de gestión de proyectos en general.

Resultaba evidente que para poder gestionar de manera eficiente el trabajo de muchas personas asignadas a muchos proyectos simultáneos, yo necesitaba establecer algún tipo de procedimiento “repetible” que nos permitiera ordenarnos (y sobrevivir).

Lección aprendida #1:
Un buen proceso metodológico es nuestro mejor amigo.

Por ese entonces – seguramente favorecido por la cultura bancaria y mi tendencia obsesivo-compulsiva – yo era partidario de aplicar el famoso proceso en cascada que incluso hoy en día se enseña en la mayoría de las universidades.

Por cada proyecto atravesábamos una serie de fases secuenciales, cada una con un entregable que permitiera avanzar a la etapa siguiente. Típicamente el ciclo incluía las siguientes etapas:
Priorización -> Relevamiento -> Análisis -> Diseño -> Desarrollo -> Testing -> Implementación

Sabíamos, sentíamos y sufríamos la limitación principal de este esquema de trabajo: Era habitual que los usuarios cambiaran de opinión durante cualquiera de las etapas por lo cual gran parte de nuestra energía se destinaba a la gestión del cambio. De más está decir que el proceso en cascada nos predisponía a resistirnos al cambio.

– “De vuelta cambiaron de opinión?”
– “Quéeeee? Tenemos que volver a revisar el documento de alcance del proyecto? Pero si ya lo actualizamos 3 veces!!!”
– “Desarrollémoslo como estaba originalmente planteado – incluso si no sirve para nada – y el mes que viene lo actualizamos”
– “Por qué habré decidido estudiar sistemas… debería haberme dedicado a la música” Sigue leyendo

¿Realidad o Ilusión? #3

Navegando un poco, me encontré otras dos ilusiones ópticas que me parecieron muy buenas.

En ambos casos tienen que mirar el centro de la imagen, dejar la mirada fija en ese punto y luego de algunos segundos verán como parte de la misma va desapareciendo.

Puntos rosa que desaparecen

Puntos rosa que desaparecen

Colores que desaparecen

Colores que desaparecen

Cosa de locos, no?
Habrá que al menos dudar un poco antes de podamos asegurar que todo lo que nuestros ojos ven es la realidad.

Dibujando con Arena – Kseniya Simonova

Me encantó este video!

Un poco de data obtenida de Wikipedia:

Kseniya Simonova (nacida en 1985 como Ксения Симонова) es una artista en animación en arena en Ucrania. Comenzó a dibujar en arena tras el colapso de su negocio como consecuencia de la crisis de crédito y menos de un año más tarde participó en el concurso Ukraine’s Got Talent. Resulto ganadora del concurso en 2009, construyendo una animación acerca de la vida en la Unión Soviética durante la Gran Guerra Patriótica contra el Tercer Reich en la Segunda Guerra Mundial.

Simonova ganó 1.000.000 Hryvnias ucraninanos (cerca de u$s 125.000) al obtener el primer lugar en el concurso.

Este video de su performance en YouTube ha recibido más de 9 millones de visitas.

Que lo disfruten.

Imagen de previsualización de YouTube