Archivo por meses: febrero 2010

Nuevo curso de Certificación Scrum Master en Montevideo, Uruguay

Cursos, , ,

La empresa AQuA.it, encargada del primer curso de Certified Scrum Master en Uruguay, está realizando una segunda instancia este año. Alan Cyment vuelve a cruzar el charco, lo que seguramente de lugar a algún otro tipo de evento con la gente que ya hizo el curso el año anterior:

Estamos organizando el segundo curso en Uruguay con certificación internacional otorgada por la Scrum Alliance de la metodología ágil de gestión de proyectos llamada SCRUM.

La palabra SCRUM fue utilizada como nombre para esta metodología con el mismo significado que tiene ella en el Rugby. En este deporte se utiliza a la unión de todos los integrantes del equipo, como si fuera un solo hombre, para “cruzar” la cancha y poner la pelota en meta contraria. Para ello se basan en táctica y estrategia. De manera análoga un equipo de trabajo que utiliza SCRUM debe ir generando “puntos” durante el proyecto hasta finalizarlo. La metodología es un framework que describe el camino para poder lograrlo, es decir, la táctica y la estrategia.

Contenido del curso

Enseñar todos los fundamentos y conceptos de Scrum: Roles, Rituales y Artefactos.

Existen 3 roles en Scrum: Team, Product Owner y ScrumMaster. Se explicará las funciones de cada rol y su interacción, dependencias, etc. Dedicando más tiempo al rol del ScrumMaster.

Los Rituales se describirán detalladamente, respondiendo; ¿qué son?, ¿para qué sirven? ¿cómo se implementan? ¿cuál es la agenda de cada una? ¿y su frecuencia? ¿cuál es su input/output? ¿cuál es el objetivo concreto de cada una? Todas éstas respuestas determinarán el buen uso de la metodología y el éxito de su aplicación.

El ciclo de vida de Scrum está basado en Sprints, éstos permiten hacer entregas periódicas del producto en lapsos muy breves, en donde se parte de la base que el producto nunca está definido completamente, por el contrario, es entiende que su definición es evolutiva. Por tal razón será una parte fundamental del curso comprender y practicar el ciclo de vida que propone esta metodología.

Se mostrarán los documentos y gráficas que existen en Scrum para poder mostrar datos del proyecto que permitan tomar métricas de gestión.

Aunque no es parte de Scrum, también se explicará como combinar este framework con otras metodologías ágiles, por ejemplo XP. Dentro de este marco se utilizaran las User Stories, ¿cómo aplicarlas? ¿cuál es su formato? etc.

Se expondrán las grandes diferencias, ventajas y desventajas de esta metodología y las tradicionales.

Dada la experiencia del entrenador internacional, responderá cualquier consulta que los participantes tengan y enriquezcan el curso.

Dinámica

Es un curso totalmente interactivo, en donde se forman equipos para ir aprendiendo Scrum para practicar los conceptos. Asimismo el entrenador utiliza novedosas técnicas para sugerir cómo abordar los cambios de paradigma que se necesitan.

No se pueden utilizar teléfonos celulares ni portables durante el dictado del curso.

Entrenador Oficial

El Sr. Alan Cyment estará encargado de dictar este curso. Tiene varios años de experiencia en Scrum, en varios proyectos desarrollados en diferentes países. Es un entrenador certificado por la ScrumAlliance quién es la entidad que evalúa y otorga las certificaciones en esta disciplina. Alan es un investigador graduado en Ciencias de la Computación, título otorgado por la Universidad de Buenos Aires. Actualmente está escribiendo un libro con uno de los practicantes más reconocidos en éstas metodologías, el Sr. Tobias Mayer. Además, Alan es el único entrenador oficial de Scrum de habla hispana, con cualquier otro el curso sería dictado en inglés.

Agenda

Fecha de comienzo: Jueves 22 de julio de 2010.

Fecha de finalización: Viernes 23 de julio de 2010.

El curso se dictará en dos días consecutivos en el Hotel Ibis de Montevideo (A Confirmar).

Cada jornada comenzará a las 9am en punto y finalizará a las 6pm.

Mecanismo de evaluación

Examen escrito al finalizar el curso. Quienes lo aprueben recibirán una notificación por mail para descargar el certficado oficial de la ScrumAlliance y además una membresía gratis por un año.

Costos

El costo del curso son 600 dólares americanos +  impuestos.

(No está incluído el almuerzo, solo coffee break)

Única forma de pago: Depósito en la cuenta dólares 8640416, Banco ITAU, Sucursal Aguada.

CSM Gabriel Ledesma

Primer planificación de Sprint

Planificación del Sprint, ,

El lunes pasado tuvimos el primer Sprint Planning de la reimplementación de Scrum. Estuvo bastante bueno, como siempre, una de las principales ventajas de Scrum es que se comience una nueva etapa en la comunicación y colaboración del equipo. Ese cambio de cabeza, de perder el rol de «jefe», y pasar a que el trabajo de cada uno sea responsabilidad del equipo hace a un cambio general en el ambiente, no tanto en el plano personal del trato entre los miembros del equipo, sino la forma de encarar el trabajo en sí. Se hace mucho más dinámico y efectivo, además de organizado. Estoy hablando de un equipo donde anteriormente no se usaba una metodología específica de desarrollo, sino que se iba sacando el trabajo.

Va costando un poco, uno de los temas complicados es que un equipo pase de no tener horarios a cumplir con el timeboxing. Si bien los horarios de las reuniones se eligen en equipo, a algunos les sigue costando, por lo que a veces caemos en el error de esperar 5 minutos a que llegue un miembro u otro al Daily Meeting.

Algo que me dió la impresión durante esta primera planificación, es que el Product Owner cayó en la idea que su trabajo no es para nada trivial, sino que acarrea una responsabilidad bastante grande. Si bien demuestra que se nutrió bastante con la metodología, leyendo varias documentaciones y recursos, dió la impresión de que en ese momento realmente asimiló la cantidad de trabajo. Recordemos que el rol del Product Owner conlleva muchas funciones. Debe actuar como filtro y representante de los stakeholders, así como negociar y priorizar elementos del backlog. En fín, al igual que el resto de los integrantes, irá aprendiendo en el camino.

Y es que Scrum es una metodología ideal para ir aprendiendo sobre la marcha. Hemos estado pasando enlaces con documentos y demás y transmitiendo la idea, pero es un proceso evolutivo. Somos dos los que venimos oficiando de Scrum Master, retroalimentándonos en el rol, y tratando que los demás asimilen la esencia de Scrum para aplicarlo en armonía con el ideal que lo hace tan efectivo y productivo.

Todavía falta transmitir algunos conceptos fundamentales, y el equipo se va a ir amoldando. Algunos puntos importantes que quedaron en el tintero para ir mechando durante las reuniones fue la visión del equipo y el working agreement. Si bien no son imprescindibles para implementar la metodología, creo que sirven para afianzar la confianza y el respeto entre los miembros del equipo, y permite concretar un primer proyecto en común.

Pero ya estamos usando la gestión visual del proyecto con un task board. Usamos un pizarrón con 4 columnas:

  • Backlog: En esta columna pegamos post-its amarillos grandes, con varias tareas (a alto nivel) que se fueron determinando en el primer planning. Obviamente está abierto a más post-its en el futuro, ya que es el backlog general del producto.
  • Sprint Backlog: Es el «TO DO», lo que hay por hacer, las tareas comprometidas para este Sprint.
  • En proceso: Las tareas en las que se está trabajando.
  • Terminado: Tareas prontas.

Como referencia, ya que no estimamos esfuerzo por cada tarea, vamos marcando un punto rojo por día transcurrido de la tarea en la columna «En proceso». Al no haber estimado, no tenemos todavía un Burndown chart, pero los puntos rojos van a ayudar a empezar a estimar más adelante.

Este primer Sprint, como experiencia, lo hicimos de corta duración. Empezamos el lunes y terminamos el viernes. El lunes siguiente haríamos una retrospectiva y review del sprint, y un nuevo planning. Dependiendo de cómo nos vaya, lo haremos de una o dos semanas de duración. Iré comentando nuevas experiencias y observaciones a medida que vayan surgiendo.

Scrum fomenta la comunicación y colaboración

Ventajas, ,

Parte del espíritu de Scrum es la colaboración entre los miembros que asumen cada rol de la implementación. Así que es lógico que esto se cumpla. Pero además de esa «teoría» que nos dice Scrum es colaborativo, está bien compartir experiencias que dan valor de verdad a estas definiciones.

Trabajo colaborativo
Trabajo colaborativo

Como comenté en una entrada anterior estoy trabajando en un nuevo equipo. El pasado lunes hubo una reunión general de todos los integrantes, donde pasamos a explicar varios temas y cambios en la forma de trabajar. Scrum implica un cambio tanto en la estructura y metodologías de trabajo, como en la forma de encarar el trabajo por parte de cada individuo.

En esta reunión, comentamos sobre algunas herramientas que usamos y vamos a integrar en nuestra metodología de trabajo: Subversion, Trac y Scrum. Subversion (además de ser mi sistema de control de versiones preferido) es el servidor que se viene usando para mantener los fuentes versionados. Trac es un sistema de gestión de tickets (bugs, arreglos, etc.) y un gestor de proyectos con integración con Subversion. Y Scrum, va a ser el framework que englobe todo el trabajo.

Comprobamos que el simple hecho de reunir a la gente, hacerla participar y contar apenas unos conceptos clave de la nueva forma de trabajo (roles, horizontalidad, participación, auto organización, etc) logró cambios en la interacción del equipo. En estos pocos días que han pasado desde el lunes, la comunicación entre todos los miembros del equipo ha sido mucho más fluída. Se escuchan conversaciones del proyecto entre varios miembros, todos participan. Y la colaboración ha sido un punto fuerte también. Hay más personas del equipo trabajando en equipo, pidiendo ayuda y ayudando.

Basado en esta experiencia, puedo afirmar con total seguridad:
Scrum fomenta la comunicación y colaboración de forma orgánica. Esto sin siquiera haber comenzado formalmente la implementación, sin task board, ni daily meetings. Solo un planning improvisado, y una introducción a algunos conceptos en una nueva forma de trabajo.

Sprint Planning – Planificación de Sprint

Planificación del Sprint

Acá les dejo un material que repartimos al equipo antes de la primer reunión de planificación de Sprint. El lunes comienza la reimplementación de Scrum. Es para tener una idea general del Sprint Planning, basado en apuntes e ideas obtenidas a lo largo de este tiempo:

Para cumplir con el criterio de Timeboxing, debe definirse una duración inicial para la reunión de planificación. Es importante que se cumpla con esta duración, y la reunión no profundice en temas que no son importantes al momento. El objetivo de esta reunión es obtener la planificación del Sprint.

Duración del Sprint

Mínimo 1 semana, máximo 1 mes.
Esto puede variar a medida que el equipo se adapte a Scrum, o de acuerdo a las entregas que quieran realizarse del producto.

Product Owner

Debe filtrar todos los intereses de jefes, directores, gerentes, de distintas áreas y con distintos intereses hacia el equipo. Para evitar el ruido, el Product Owner es el único que transmite las necesidades del producto al equipo, basado en el retorno de inversión.

Tiene que tener preparado para la reunión el backlog del producto: la lista de funcionalidades que hay que implementar. Durante la primera parte de la reunión, el P.O. explica el backlog.

El equipo

Una vez armado el backlog, el equipo debe seleccionar las funcionalidades con las que se va a comprometer a terminar en el Sprint. El objetivo es tener un producto potencialmente entregable al final del Sprint, y que la funcionalidad sea demostrable. Debe analizar y estimar qué se puede hacer, y despejar dudas sobre funcionalidad con el P.O..

Definiendo el Sprint

El Product Owner y el equipo deben definir juntos el trabajo a realizar en el Sprint. El P.O. es el responsable de elegir la prioridad, y el equipo de elegir cuánto trabajo va a poder terminar en esta etapa. De esta forma, se define el objetivo de cada Sprint. Su éxito será determinado al final del Sprint en una reunión de review. De esta manera, se arma un backlog para el Sprint.

Estimando el Sprint

Una vez definido el backlog del Sprint, cada tarea debe ser estimada, y dividida en partes que puedan ser medidas idealmente en 1 día o menos de trabajo. Cuanto más pequeño sea el alcance de cada tarea, más fácil de estimar.

Reimplementando Scrum

Scrum
Duke Trabajando
Duke Trabajando

Hace ya 2 meses que cambié de trabajo.

Hasta ahora los posts relacionados a la implementación de Scrum en este blog habían sido siempre en la misma empresa. El cambio de trabajo debe ser uno de los momentos en que queda más evidente la utilidad de haber hecho este blog plasmando mis experiencias con Scrum.

Si bien no escribí tanto como me hubiera gustado desde mayo cuando empecé el blog, hay muchas cosas útiles que vi en su momento, que aprendí, que apliqué, que me pueden servir hoy en el nuevo trabajo. Links, recursos, artículos y demás. Si bien no ha sido tanto como esperaba, algo se ha ido guardando.

En este nuevo trabajo estamos por empezar una nueva implementación de Scrum. Por lo tanto, a partir de ahora, reimplemento Scrum.

Una de las ventajas es que trabajo con otro Scrum Master certificado. Ya han habido ideas de Scrum y agilidad en la empresa, pero aparentemente no se ha llegado a hacer una implementación completa.

Prometo en esta nueva instancia de implementación de Scrum, comentar más experiencias en el blog.