En la medida que adquiría experiencia me daba cuenta que faltaba algo. Tenía la sensación que lograba las metas con un esfuerzo personal muy importante, pero mi equipo lo hacía de forma irregular.

Luego de decenas de proyectos comencé a buscar la verdadera razón del éxito. Comprendí que éste radica en la naturaleza de las personas que trabajan en él, sumado al conocimiento técnico adecuado. Por esta razón, siempre considere a mi equipo de trabajo como el “gran actor” de un proyecto y siempre intente generar el contexto más adecuado para obtener el mayor rendimiento de ellos, incluyendo la motivación personal.

También aprendí que si quieres hacer un proyecto exitoso debes estar dispuesto a darle paso a quienes te acompañan en el trabajo cotidiano. Sin importar el nivel jerárquico, todos quieren ser reconocidos, todos quieren proponer, todos quieren aportar al objetivo. He aquí lo difícil, intentar satisfacer estas necesidades. Siempre intente hacerlo, convencido que era fundamental para lograr el objetivo.

Hace un par de años atrás, descubrí que muchas de esas premisas, en las cuales yo me basaba intuitivamente, estaban plasmadas en algo llamado SCRUM. Comencé a leer con ahínco, y poco a poco me daba cuenta que había encontrando lo que desde hace tiempo buscaba. Un marco de trabajo que pone por escrito el sentido común, basándose en el valor que aportan las personas, el vínculo, la creatividad, la crítica constructiva, la auto-enseñanza y la auto-organización.

¿Acaso alguien cree que es un buen project manager por hacer cronogramas, calcular presupuestos, hacer cumplir órdenes? Si estás o has estado desempeñando este rol, seguramente pienses que nada de lo anterior fue fundamental en el éxito de un proyecto. En mi opinión, un buen project manager es quién logra llevar a cabo un proyecto sintiendo que realmente tuvo el control del proyecto, fue el gestor, pero sabe perfectamente que sin el equipo de trabajo, solamente con su aporte individual no lograba el objetivo.

Del análisis anterior surge el tipo de líder que propone SCRUM, el líder que articula, orquesta, comanda, pero prácticamente no aparece en escena. Logrando el compromiso profesional de su equipo de trabajo plasmado en productos tangibles, que agreguen valor al cliente. Todo esto, conjugado con ciclos de desarrollo cortos, permiten corregir en base al empirismo y siempre con riesgo de bajo costo.

Muchas veces, al hablar de metodologías ágiles, tales como SCRUM, los project manager pensamos en anarquía y poca intensidad, cuando en realidad es exactamente lo contrario. Para practicar correctamente SCRUM se exige disciplina e intensidad, sostenidas en el tiempo.

Podría haber escrito un artículo que explicara aburridamente SCRUM, pero iría contra la esencia de éste método, por tal razón, los invito a aprender SCRUM. Luego habrá tiempo para decidir si lo practican o no, pero no lo quiten de sus escenarios por desconocimiento. Piensen, por algo está siendo utilizado por las grandes empresas del mundo de tecnología; Google, Yahoo, Microsoft, HP, Novell, SAP, Nokia, Xerox, etc.

SCRUM es una metodología ágil que surge como una alternativa a las tradicionales. Las metodologías ágiles proponen un marco de gestión de proyectos más pragmático y menos burocrático. Surgieron a mitad de los años 80 en Japón, partiendo de la premisa que el valor agregado está en la gente y especialmente en la capacidad de auto-organización de las personas.

A continuación se citan las premisas en las cuales está basado SCRUM, llamado “Manifiesto Ágil”:

• Valorar mas a los individuos y su interacción que a los procesos y las herramientas.

• Valorar mas el producto que funciona que la documentación exhaustiva.

• Valorar mas la colaboración con el cliente que la negociación contractual.

• Valorar mas la respuesta al cambio que el seguimiento de un plan.

La palabra SCRUM significa lo mismo que en el Rugby, es decir, en este deporte se adopta una figura de juego en la cual un equipo tiene que actuar muy coordinado y con fuerza constante para lograr el balón. En la medida que se aprende y practica esta metodología esta palabra va tomando significado.

En resumen lo que propone SCRUM es un marco de trabajo, un camino simple y claro con una serie de artefactos, roles y rituales que permiten transitarlo en base a iteraciones basadas en inspeccionar y adaptar en donde cada vez que una culmina se debe haber alcanzado un producto que en sí mismo tenga retorno de inversión para el cliente.

ROLES

Scrum Master: Es ejecutado por un individuo, éste se encarga de facilitar absolutamente todo lo que se necesita para cumplir con las metas del proyecto. Su rol fundamental será hacer cumplir la metodología.

Product Owner: También es ejecutado por una sola persona, en general es alguién que conoce perfectamente cúal es el retorno de inversión de cada uno de los requerimientos que tiene el proyecto. Es decir, debe conocer muy bien el producto que se desea obtener.

Team: Es el equipo de trabajo, lo integran quienes vayan a implementar el proyecto. Se recomienda que no haya menos de 5 integrantes ni más de 9.

CICLO DE VIDA DEL PROYECTO

El ciclo de vida de un proyecto Scrum se basa en unidades iterativas que deben tener un tiempo fijo en las cuales se planifica, desarrolla y aprueba el resultado de esa iteración. Estas unidades iterativas se llaman SPRINTS. Se sugiere que un Sprint tenga una duración mínima de una semana y una máxima de cuatro.

RITUALES

Se les llama rituales a las reuniones que establece SCRUM que deben ser cumplidas en esta metodología.

Sprint Planning: Al comenzar un nuevo Sprint se debe tomar la lista de requerimientos (Product Backlog) y a partir de la prioridad de cada uno se debe seleccionar un conjunto de estos requerimientos los cuales serán ejecutados por el Team. Este subconjunto de requerimientos deben generar valor de retorno de inversión al cliente y debe ser un producto potencialmente entregable. En esta reunión participan el SM, PO y el Team. El tiempo de duración máxima son 2 horas.

Sprint Daily Meeting: Diariamente el Team debe realizar una reunión en donde cada integrante tiene 2 minutos para responder a las siguientes preguntas:

1. ¿Qué tareas comprometidas realizó?

2. ¿Qué impedimientos detectó al realizar estas tareas?

3. ¿Qué tareas se compromete a realizar mañana?

En esta reunión debe participar el Team y el SM. Se puede realizar en cualquier momento del día, eso lo define el Team, una vez definido no debería ser modificado.

Sprint Review: Al finalizar un Sprint se debe realizar una revisión del producto concebido en ese Sprint. Para ello deberán reunirse el Team, el PO y el SM. Esta reunión deberá tener como resultado una aprobación o reprobación del producto por parte del cliente. Se recomienda una duración máxima de 2 horas.

Sprint Retrospective: Luego de realizar el Sprint Review se deberá realizar otra reunión entre el SM y el Team. El propósito de esta es realizar un análisis para ver cómo se aplicó la metodología y realizar una evaluación del resultado en donde se deberán tener en cuenta las correcciones que se deben aplicar para la siguiente iteración.

ARTEFACTOS

Product Backlog: Es una lista de requerimientos que definen el producto que el cliente necesita. Cada requerimiento se llama Item Product Backlog.

Product Backlog Comprometido: Es un subconjunto de los ItemProductBacklog que están comprometidos para un Sprint determinado.

Charts: Scrum propone una serie de reportes o gráficas que permiten tomar indicadores del proyecto, alguno de ellos son:

• Burndown Chart: Permite ver cuanto falta para finalizar el proyecto.

• Velocity: Permite obtener una cuantificación de la velocidad de desempeño del Team.

REFERENCIAS

• Material de los cursos oficiales de Alan Cyment

• www.scrumalliance.org

]]> http://blog.aquait.info/2009/08/scrum-overview/feed/ 0