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…

Continuar leyendo “SCRUM funciona!”

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” Continuar leyendo “Metodologías amigas – Metodologías enemigas”

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

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.

Diferencias entre programadores Junior, Semi Senior y Senior

¿Cuáles son las principales diferencias entre un programador junior, un semi senior y un senior?

Durante las últimas semanas recibí algunas consultas sobre este tema, lo que me motivó a escribir este artículo.

No es un tema de simple respuesta. Incluso buscando en Google no se encuentran respuestas maravillosas sobre el asunto.

Lo que sucede en realidad es que las diferencias entre los distintos “niveles” dependen de las necesidades y la cultura de cada organización y de cada equipo. En distintos entornos lo que diferencia a un senior de un junior puede variar.
En algunas organizaciones la diferencia solo está dada por la cantidad de años de experiencia laboral que la persona tenga, en otros casos depende del grado de conocimiento técnico y en otros está asociado a la capacidad de la persona de gestionar proactivamente su trabajo.

Lo que no tiene cuestionamientos es que se trata de una temática sumamente sensible. Habitualmente la remuneración del ingeniero de software se asocia a su nivel de seniority, así que seré lo más cuidadoso posible al presentar el tema.

En este artículo comparto algunos de los criterios que pueden ayudar a definir el nivel de seniority de una persona. Cada uno de los indicadores puede tener más o menos importancia de acuerdo a cada organización (al final del artículo incluiré una encuesta para conocer tu opinión).

Si el lector es el Gerente del equipo, podría asignar una ponderación a cada uno de los indicadores antes de aplicarlos.
Si en cambio es un programador, mi sugerencia es que intente dominar todos los aspectos, aprovechando las oportunidades que se le presenten para su desarrollo.
Si el lector es el Gerente de Recursos Humanos, mi consejo es que ayude a comunicar dentro de la compañía cuáles son los aspectos que más se valoran. Continuar leyendo “Diferencias entre programadores Junior, Semi Senior y Senior”

Consejos para dar feedback

En artículos anteriores presenté algunos consejos para conducir entrevistas, sugerencias para realizar evaluaciones de desempeño e incluso presenté un ejemplo de evaluación de desempeño para programadores.

En esta oportunidad – y relacionado al tema de evaluaciones de desempeño – quiero compartir algunas prácticas que me son de utilidad a la hora de dar feedback a un miembro del equipo.

Dar feedback en el ámbito laboral tiene como principal objetivo informar al receptor acerca de la percepción que tenemos de su desempeño sobre una tarea o gestión realizada y el grado de acierto alcanzado respecto a lo que originalmente esperábamos.

Sin ser el mayor experto en el tema, ni mucho menos, considero que se trata de una herramienta fundamental para incrementar las fortalezas del empleado. Dar feedback adecuadamente es una habilidad valiosa para un líder, que puede ayudarlo a mejorar el desempeño de su equipo.

El feedback puede ser implícito o explícito. El implícito es el que se da a través de gestos, tonos de voz, expresiones y cualquier otra señal no verbal.

Además puede ser positivo o negativo. Normalmente cuánto más feedback positivo se recibe, mayor es la satisfacción (a menos que uno esté atravesando una etapa masoquista). El feedback negativo suele percibirse como amenazante y por ende tiende originalmente a desmotivarnos. Sin embargo el feedback negativo es fundamental para que podamos superarnos y evolucionar!!!

Continuar leyendo “Consejos para dar feedback”

¿Así viviremos en el futuro?

Vamos a llegar al tema de a poco…

Introducción
La semana pasada estaba almorzando con Edu, Pablo y Javier. Como debe suceder con gran parte de los Argentinos, nuestra conversación giraba en torno al conflicto del Gobierno con el Campo.

Cuál es la historia del campo en la Argentina, los poderosos, los pequeños y medianos productores.
Cómo el ex-ministro de economía antes de asumir y recomendar la suba de las retenciones, había escrito un libro donde sugería exactamente lo contrario.
Por qué pensamos que el gobierno tiene mayor responsabilidad y debe ceder en pro de resolver el conflicto.

Ya a la altura de los cafés, la conversación había derivado a temas más genéricos, como ser la forma ineficiente en la que elegimos a quienes nos gobiernan.
Después de todo, los gobernantes son nuestros empleados, ¿no?  y deberían representar la voluntad de la mayoría.
Si existiera un método económico, rápido y auditable de pedir la opinión de la población, muchos de los conflictos serían resueltos de otra forma.

Continuar leyendo “¿Así viviremos en el futuro?”