Necesitas explicarle a tu abuela qué es MercadoLibre.com?

Este video puede ayudarte:

Imagen de previsualización de YouTube

No hay Comentarios

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

3 Comentarios

La historia de Google en un video de 2 minutos

Interesante… La historia de Google en un video de 2 minutos:

Imagen de previsualización de YouTube

Que lo disfruten.

No hay Comentarios

Navidad Solidaria en MercadoLibre

Sin duda, una de las cosas que me gustan de trabajar en MercadoLibre, son este tipo de propuestas:

MercadoLibre Navidad Solidaria

MercadoLibre Navidad Solidaria

No hay Comentarios

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…

Leer el resto de la entrada »

7 Comentarios

2008 Did You Know 3.0

Impresionante este video!

Imagen de previsualización de YouTube

1 Comentario

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” Leer el resto de la entrada »

3 Comentarios

¿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.

No hay Comentarios

Ejemplo de evaluación de desempeño a un líder

Cuando me encuentro evaluando el desempeño de un líder de equipo, existen algunas características adicionales que suelo considerar, como ser:

  • Establece acuerdos con otros líderes de la organización o es un jugador solitario?
  • Asume los compromisos o los esquiva?
  • Más allá de asumirlos… logra cumplirlos?
  • Se muestra en sintonía con el Norte de la Compañía o tiene sus intereses particulares que no lo hacen un jugador 100% leal?
  • Cumple con los procedimientos establecidos?
  • Da visibilidad sobre sus acciones y decisiones al resto de la compañía?
  • Es bueno motivando a su equipo?
  • Se comunica adecuadamente con pares, superiores y poderdantes?
  • La relación Productividad-Calidad de su equipo es la esperada?
  • Es realista y pragmático o pierde buenas oportunidades en búsqueda constante de la perfección absoluta?

En este post comparto con ustedes una versión del ejemplo de Evaluación de Desempeño, personalizada para evaluar a un líder de proyecto.

La estructura es bastante simple.

  1. Revisar la Guía de Evaluación donde se enumeran las características a evaluar. Ajustarla, asegurar que los evaluadores entiendan la descripción de cada uno de los aspectos que se consideran.
  2. Completar una planilla de Evaluación de Desempeño por cada persona evaluada.
  3. Completar la planilla de Ponderación de Métricas para reflejar la importancia relativa entre distintos conceptos (esto varía dependiendo de los valores y objetivos de la organización).
Para facilitar el ejemplo, he coloreado de amarillo las celdas que deberían completarse.
Espero que les resulte de utilidad.

20 Comentarios

Abrace a un desarrollador

Pablo Bossi, líder del equipo de desarrollo Core en OLX me envió hace unos días este video.

Me pareció divertido para compartir con todos aquellos developers que sigan el blog.

¿A quién no le pasó esto alguna vez?

Por favor, active Javascript y Flash para poder ver el vídeo Blip.tv.

10 Comentarios