Archivos mensuales: junio 2009

Enlaces sobre Scrum I

Como bien dice Alan Cyment en su sitio web, al tomar la certificación de Scrum Master “la travesía del alumno recién comienza”.

El curso de Certified Scrum Master se encarga de hacernos entender la esencia y el espíritu de Scrum, y porqué sirve o no, según el caso, depende. Después sigue una etapa de irse zambulliendo en Scrum. Para esto, nada mejor que leer, estudiar, participar en foros, y obviamente, aplicar Scrum.

Como parte de este camino, se empiezan a investigar nuevas fuentes de lectura, sitios relacionados, etc. A continuación les dejo algunos enlaces que he empezado a visitar seguido, a medida que vaya encontrando más iré ampliando.

Enlaces recomendados:

Blogs sobre Scrum y Agile:

En inglés:

  • Jeff Sutherland, uno de los inventores de Scrum junto a Ken Schwaber.
  • Visual Management Blog, espacio de discusión de ideas y ejemplos de Gestión Visual aplicada a equipos ágiles y gestión ágil de proyectos.
  • Implementing Scrum, su nombre lo dice, el autor es Coach (Certified Scrum Practitioner), además publica un conocido cómic con personajes animales que implementan Scrum:

    El cerdo y la gallina

    El cerdo y la gallina

En español:

  • Café Bar Ágil – Llegué a este blog a través de la lista de correo de foro-agiles. El autor es Martín Alaimo, miembro de la comunidad Ágil Latinoamericana, y el objetivo de su blog es prácticamente el mismo que este.
  • Planeta Scrum: El agregador de contenidos en castellano sobre Agile y Scrum. Hay muchos blogs que leía, así que me ahorro ponerlos a mano uno a uno.

Primera reflexión del equipo de desarrollo

El pasado viernes tuvimos la primera reflexión o retrospectiva de Sprint. Por lo menos la primera “formal”, ya que el viernes anterior faltó el Scrum Master (ver entrada anterior para leer más sobre como vamos implementando Scrum ). No he leído de técnicas específicas para la reflexión, así que me basé en la teoría, y debatimos los problemas que habíamos tenido durante el proceso de trabajo.

Este viernes marcaba el final del primer Sprint. Los problemas que saltaron y que se plantearon durante la reunión fueron los siguientes:

  • Subestimamos o sobreestimamos tareas.
  • No granulamos lo suficiente como para hacer estimaciones más precisas.
  • No detectamos falta de documentación en tiempo lo que puede atrasar un poco el trabajo.
  • Tuvimos un deploy desordenado.
Pizarrón Primer Planning

Pizarrón Primer Planning

Como conclusión llegamos a una serie de implementaciones que pueden ayudar a reducir el impacto de los problemas encontrados:

  • Análisis inicial más extenso: extender la duración de la reunión de planning, para entrar más en detalles de análisis de las tareas a realizar, para poder estimar mejor. Esto también permite detectar faltas de documentación sobre el proceso a trabajar.
  • Formalizar deploy, con la posibilidad de implementar un servidor de Integración Continua para el proyecto.

El lunes de esta semana ya arrancamos dedicándole un poco más de tiempo. Además tomamos en cuenta implementaciones que traían mucha documentación nueva. Para estas, se ingresó como tarea el análisis y posterior diseño de lo escrito en la documentación, y el martes se hizo un nuevo sub-planning para estas tareas específicamente.

Se notó una diferencia en densidad de análisis respecto al anterior el lunes:

Pizarrón Segundo Planning

Pizarrón Segundo Planning

El martes se agregaron muchas tareas más seguidas del sub planning. Todavía tenemos pendiente la implementación del Task Board en reemplazo del pizarrón.

Usando el pizarrón como Task Board

Mientras vamos agarrándole el ritmo a Scrum, vamos implementando algunas de las herramientas recomendadas. Entre ellas el Daily Meeting o Daily Scrum, el Planning de principio de Sprint, el review y la reflexión.

Lo que no hemos implementado completamente todavía, es el Task Board. En nuestra primer implementación fallida de Scrum hace unos meses lo habíamos implementado. Usamos un espejo grande en la parte de desarrollo, dividimos con cinta aisladora en columnas, y pegábamos los Post-It ahí. Algunos errores que cometimos:

  • No incluir una columna con el Product Backlog. Directamente pegábamos las tareas en “To-Do”. Ahora creo que sería más eficiente tenerla, e ir desprendiendo tareas de ahí.
  • No definir el concepto de “tarea lista”. Incluímos una columna de tareas “para testing”, que debían pasar esa aprobación para quedar en “terminadas”. Esto se transformaba en un cuello de botella… nadie quiere testear.
  • El pasaje de tarjetas entre columnas se hacía en cualquier momento del día. Esto tiene la desventaja que no todos están atentos, por lo que se pierde en parte el compromiso de definir una tarea como “lista” frente a los compañeros de equipo, y la transparencia, ya que no todos se enteran de los cambios al momento de realizarlos. Por eso es más efectivo, a mi parecer, hacer estos movimientos únicamente en el Daily Scrum.

Todo esto fueron errores que vengo viendo ahora, que en mi opinión son errores, pero pueden resultar efectivos en otro equipo distinto de trabajo, depende.

Hoy en día venimos usando el pizarrón. Los lunes de mañana hacemos el planning anotando lo que hay pendiente en el backlog. De ahí se desprenden tareas y vamos acotando qué partes del backlog entran al Sprint, y que seguirán incluyéndose en siguientes Sprints hasta terminar ese tema.

Task Board Pizarrón

Task Board Pizarrón

Estimamos por cada uno la cantidad de tareas que se asigna, y el tiempo que le va a llevar. Para eso tenemos el calendario de la semana en columnas, e incluimos un título de la tarea y el nombre del programador el día en que estima que la tarea estará terminada. Algo que aprendimos que puede resultar útil también es incluir la hora aproximada de terminación de la tarea.

En los Daily Scrum revisamos vemos cómo va progresando cada uno con las 3 preguntas. Cuando una tarea debía estar pronta y se atrasó, escribimos un punto rojo. Si se termina en tiempo, se escribe un punto verde. En caso de haber sobrestimado la tarea, y terminarla antes, se agrega al punto verde y un “+n” siendo n la cantidad de días a favor.

Por ahora es lo que nos viene sirviendo, pero probablemente re implementemos el task board con los post it a corto plazo. Tampoco estamos llevando por el momento gráficas de burn down, pero posiblemente lo hagamos también.

Implementando Scrum: Como empezamos

Como comenté en la entrada anterior, uno de mis objetivos para el curso de CSM era terminar de convencerme si Scrum era la solución para el equipo de desarrollo en el que trabajo o no. Después de lo aprendido concluí que sí, que era la solución. Este post está basado en un mail que envié al grupo foro-agiles, contando cómo empezamos con la implementación de Scrum.

Muchas de las recomendaciones y prácticas sugeridas por Scrum ya las veníamos implementando. El equipo cuenta con 7 programadores y yo, que asumo el rol de Scrum Master. El perfil general del equipo apuntaba a que Scrum era una buena idea.

En un momento del proyecto, llegamos a una etapa de re organización de nuestra forma de trabajo. En esta reunión abierta del equipo de desarrollo, sugerí utilizar Scrum y argumenté las razones. Estaba convencido que era una solución conveniente para este proyecto en particular. En ese mismo momento surgió una charla sobre Scrum para transmitir lo aprendido en el curso. Para esto, se llamaron a los distintos encargados de departamento y se juntó al equipo de desarrollo.

En aproximadamente una hora y media, intenté transmitir la mayor cantidad de conocimientos e ideas adquiridos en el curso. Me enfoqué más en la filosofía, espíritu, e ideas de Scrum, que en la implementación misma, aunque esto también fue mencionado. La meta era que los programadores entendieran la filosofía de trabajo, la esencia de Scrum, y la confianza que se les tiene para implementar correctamente la metodología. Estuvo bueno porque tanto los desarrolladores como el resto de la empresa estuvieron de acuerdo en la implementación de Scrum y lo encontraron beneficioso para el proyecto.

Así que de a poco empezamos a usar las herramientas de Scrum para llegar a implementar lo que consideremos necesario. En un principio, hicimos un working agreement. El working agreement, o acuerdo de trabajo, es una serie de reglas, o normas a seguir por el equipo. El compromiso y disciplina de los miembros del equipo es una parte importante de la implementación de Scrum. Así que se realiza este documento, con la participación y aceptación de todos, y luego se imprime/escribe en algún lugar que sea visible para todos. En nuestro caso lo imprimimos y colgamos en la cartelera del departamento de desarrollo, además de publicarlo en el blog interno de la empresa para darlo a conocer al resto. El documento está abierto a modificaciones (ya agregamos un ítem más desde su creación… tengo que imprimir eso de nuevo!).

El segundo paso fue definir la visión del equipo de desarrollo. Conocíamos la visión de la empresa, y del proyecto, pero debíamos definir una visión propia. Llegamos a algo nuestro y compatible totalmente con la visión del proyecto y la empresa.

Para la gestión de tareas veníamos usando Trac. Como Project Manager tenía que obtener las tareas a partir de la documentación, y asignársela a cada programador. Implementando Scrum, esto ya no es tan necesario, ya que el equipo auto organiza el trabajo. Además se evita el cuello de botella que generaba el hecho de que todo pasara por una persona. De todas formas, Trac puede ser una opción como herramienta para gestionar el trabajo del Sprint.

Empezamos un martes, e hicimos un “mini-planning” para definir el trabajo en los siguientes días de la semana, definiendo el viernes como final de Sprint, con la respectiva reflexión y review del cliente. Esa misma semana caí enfermo, y tuve que faltar los días jueves y viernes. Me perdí tanto los daily meetings como el review y reflexión del viernes. La reflexión no se hizo muy detalladamente, simplemente se repasó lo que se hizo y lo que quedó pendiente.

El lunes siguiente arrancamos con un planning más detallado. Como recién venimos empezando, estamos haciendo todo cada una semana.

Una de las particularidades de nuestro caso es que el Product Owner se encuentra actualmente fuera del país, por lo que llevamos la comunicación entre el Scrum Master y él a través de correo, mensajería instantánea, skype, etc. , apoyado con documentación post-planning y los reviews online. Actualmente, el no participa en el planning del Sprint. La idea que estamos implementando para solventar su ausencia en los planning es:

Definimos Sprints con comienzo el lunes, y review y retrospección el viernes. Comenzando con Sprints cortos creemos que tenemos más posibilidades de hacer una estimación precisa. Probablemente a la larga los extendamos a dos semanas, arrancando un lunes y terminando el viernes de la siguiente semana. Los jueves, el Scrum Master agrupa las “user stories” que van a ser planteadas en el planning del lunes. Este mismo día se realiza una videoconferencia con el Product Owner, y se definen las prioridades y tareas a incluir en el Sprint. Y así lo venimos llevando por el momento.

Cómo empecé con Scrum

Comencé a trabajar hace varios meses en una empresa de desarrollo de software. “Caí accidentalmente” en el puesto de Project Manager, y encargado general del departamento de desarrollo. Al principio me costó bastante adaptarme al puesto siendo programador, pero después de un tiempo me voy amoldando.

Mi primer contacto con la programación ágil fue en una conferencia de lo que en algún momento fue la “Red Tecnológica del Este”, un grupo de usuarios que se juntaba una vez por mes en conferencias técnicas sobre programación. En una charla sobre refactoring, mencionaron el libro Essential Skills for Agile Development de Tong Ka Iok. Teniendo el título del libro, lo descargué (gratis desde su sitio web), e investigué un poco aprendiendo lo que era el desarrollo ágil, el manifiesto ágil, y de qué venía la cosa en general. Comenté sobre el libro en Picando Código: Técnicas esenciales para el Desarrollo Ágil de Software

Más adelante asistí al JAVAUY 2007, el evento anual del JUGUY, donde asistí a una conferencia sobre Integración Continua.  Esta una práctica de desarrollo de software fue introducida por Martin Fowler y Kent Beck y es una de las tantas herramientas relacionadas al mundo ágil. Materia pendiente que tengo que estudiar para una posible implementación en el trabajo.

Seguí leyendo cada tanto sobre XP y Scrum. Gracias a recomendaciones, en un momento hicimos el intento en la empresa de implementar Scrum como metodología de trabajo. El equipo tenía la cantidad justa de gente, y el proyecto se prestaba para una metodología ágil. Sin embargo la falta de conocimiento y experiencia, y algunas malas prácticas, llevaron a que lo abandonáramos.

Hace poco tiempo, me certifiqué como Scrum Master. Texto obtenido del Grupo de Usuarios Scrum del Uruguay:

Los días 14 y 15 de mayo de 2009 tuvo lugar en Montevideo-Uruguay el primer curso de Certificación Internacional de la Scrum Alliance. Fué organizado por la empresa AQuA.it. A partir de este evento hay 24 Scrum Master Certified, aprovechamos para felicitar a cada uno de ellos, son los primeras personas que pudieron obtener esta certificación en nuestro país.

Tomé el curso y recibí la certificación. Mi objetivo asistiendo al curso fue no solo aprender Scrum, sino sacar mis conclusiones de si era la metodología indicada en los proyectos en los que estaba involucrado. El curso fue realizado por Alan Cyment el único Certified Scrum Trainer en español, Ariel Ber y Gabriel Ledesma. Una (de las tantas) particularidades del curso, fue que se realizó implementando Scrum. Los asistentes cumplíamos el rol de Stake Holders, mientras que los 3 responsables del curso eran el equipo de desarrollo.

Fue un curso muy dinámico, totalmente diferente a cualquier curso que haya tomado antes. Hubieron muchas dinámicas de grupo, de esas que dejan grabadas las ideas. Me hizo acordar a los libros “Head First” de O’Reilly, y su manera de abordar los temas de forma poco convencional, pero que dejan grabados los conceptos. No quiero contar demasiado para no arruinar la experiencia a aquellos que lo vayan a tomar., aunque cada curso es diferente al otro (depende mucho de la gente que lo vaya a tomar también). Si tienen la oportunidad, les recomiendo que asistan a uno de los próximos cursos certificados de Scrum en español.

A partir de entonces, la cosa cambió. Todo mi conocimiento previo sobre Scrum se basaba en las prácticas o herramientas que usa Scrum. Pero salí con un fundamento teórico mucho más amplio, y un conocimiento más específico de la esencia o espíritu de Scrum. Esto me resultó mucho más importante que las herramientas para implementarlo, ya que cada equipo elige las herramientas que le sirvan según el caso, depende (palabra que se usó mucho). El primer día aprendí mucho, pero salí con más dudas que respuestas. Después de digerir las ideas, y asistir a la segunda jornada de Scrum, despejé mis dudas, y salí convencido de que Scrum era la solución ideal para muchas cosas (incluyendo el proyecto en el que venía haciendo de PM), pero no para otras.

A partir de ahí, empecé a implementar Scrum en mi trabajo, asumiendo el rol de Scrum Master, y en mi proyecto de final de carrera para recibirme de Analista Programador. Y así fue que empecé con Scrum. El siguiente paso fue mi Hola mundo ágil.