Comparto con ustedes mensaje del grupo de Scrum Uruguay:
Mañana entre las 18:00 y 18:30 Alan Cyment, el instructor del curso de Scrum Master, los invita a concurrir al Hotel Ibis para intercambiar opiniones y experiencias sobre el uso de Scrum.
La idea es intercambiar opiniones con los participantes del curso del año pasado sobre como les ha ido con el uso de la metodología.
Para concurrir no es necesario haber participado del curso anterior, cualquier persona que tenga experiencia para aportar o quiera acercarse a la comunidad Scrum en Uruguay está invitada.
Saludos y nos estamos viendo mañana
Alejandro Mateo, CSM
El Hotel Ibis se encuentra en:
Calle La Cumparsita 1473 Rambla República Argentina Mapa
Este jueves voy a participar de una reunión junto a otros Scrum Masters. En ellaexpondremos varios temas entorno a Scrum, la metodología ágil de desarrollo, y cómo ha cambiado nuestra forma de trabajar.
Si están interesados en aprender un poco sobre Scrum desde la experiencia de otros, tienen dudas respecto al curso, etc. esta es la oportunidad para preguntarlas:
El 24 de junio a las 19.45 horas en el Salón Azul de la Facultad de Ingeniería de la República se desarrollará una charla abierta en donde profesionales de nuestro medio expondrán su experiencia en el uso de Scrum luego de haberse certificado como Scrum Master el año pasado.
El evento es gratuito pero hay cupos limitados, por inscripciones eventoscrum@aquait.com.uy
ACTUALIZACIÓN: La agenda del evento
19:40 – Inicio del evento, breve overview de Agile + Scrum (Gabriel Ledesma).
19:50 – Orador: Diego Garagorry
20:15 – Orador: Gabriel Centurión
20:40 – Orador: Fernando Briano
21:05 – Orador: Carlos Acle
21:30 – Cierre del evento, preguntas e intercambio general.
Va a ser algo dinámico, distinto, más parecido a Scrum, menos parecido a una típica conferencia técnica. No se lo pierdan.
El elemento que ha ido mutando mucho con cada Sprint es nuestro Task Board. En un principio nuestro pizarrón se dividía en cuatro columnas (ver más en este enlace: Primer planificación del Sprint): Backlog, Sprint Backlog, En proceso y Terminado.
Post-its
Un primer cambio fue separar el Backlog del pizarrón. Durante el Sprint, las tareas del Backlog no son tan importantes, y agregan ruido al panorama. Las tareas a finalizar en cada Sprint están en el Backlog del Sprint, por lo que los otros Product Backlog Items no hacen más que mostrar que todavía queda mucho por hacer…
Pegamos unas hojas blancas con cinta en la pared, al lado del pizarrón, y movimos todos los PBI del Backlog para ahí. Esto nos dió más espacio, bienvenido a medida que se fueron atomizando las tareas (lo que se traduce en más post-its).
Agregué una referencia visual aprovechando el pizarrón. En la columna de Terminado, escribí los objetivos del Sprint, y los días que faltan para que termine, cambiando este número en cada Daily Meeting (todavía tengo pendiente el Script para cambiar automáticamente el día en el pizarrón 😛 ). Esto nos permite ver cuál es el objetivo que queremos alcanzar a diario, para no desviarse de la dirección del Sprint, y cuánto tiempo nos queda.
También estamos usando referencias de colores en los post-its para identificar distintos tipos de tareas. Los post-its amarillos grandes son las historias de usuarios. Los amarillos más chicos definen las tareas. Los rojos son usados para errores y control de calidad y los verdes para tareas sin prioridad. Además, como todavía no hemos aplicado la estimación de tareas (lo hacemos de forma muy especulativa en cada planificación), le agregamos un punto rojo por día de trabajo a cada tarea en la columna de «En progreso». De esta manera podemos identificar las tareas con problemas de forma ágil.
Contamos ahora con un control de calidad y testing. Uno de los integrantes del equipo se encarga de esto, por lo que se agrega para historias de usuario o tareas específicas, la tarea «Control de calidad». Por esto debimos agregar un renglón en la columna de «en proceso», donde los desarrolladores colocan sus tareas cuando a su criterio están terminadas. Cuando una tarea está «pronta», se pasa a testing, y el tester saca tareas rojas (errores) si son necesarias, pasando la tarea a finalizado cuando se deba.
En un principio traté de seguir la filosofía minimalista en el task board. Esto por influencia directa de XQA quien en su blog de gestión visual comenta en la entrada Etiquetas de estado y las tres columnas (en inglés):
«Menos es más». Has oído esto antes, ¿cierto?
Esto aplica particularmente a la gestión visual (…) cualquier elemento visual que no agregue valor es desperdicio.
Sin embargo, nuestra aplicación de Scrum hizo que el task board fuera agregando nuevas separaciones. Otra sección nueva fue la de GUI, en la columna de en proceso, para que los encargados de la GUI agregaran elementos o arreglos a las interfases gráficas. Cada miembro del equipo que necesite algún cambio / mejora / nuevo elemento en una interfaz, ingresa una tarea en esta nueva separación. Si al equipo le queda más cómodo trabajar así, agrega valor.
Una unidad de trabajo puede tener tres estados básicos: «No comenzado», «En progreso» y «Terminada». La mayoría de los taskboards que tienen más de tres columnas están dividiendo «En progreso» en fases intermedias secuenciales. Ejemplo típico: «A validar».
Hay muchas razones por las cuales intentaría evitar usar columnas adicionales (…) pero lo más importante desde el punto de vista de gestión visual – es que crea elementos visuales extra (más columnas). También usa más espacio del taskboard, el cual puede ser escaso.
XQA plantea una solución más eficiente para este asunto, que podríamos llegar a poner en práctica, usar etiquetas de estado.
Como nos enseñaron en el curso de CSM, Scrum no tiene una sola forma de implementarse. Según el equipo y el trabajo a realizar, las distintas columnas del taskboard y otras referencias visuales pueden ayudar o no, depende. Es una metodología bastante evolutiva, ya que cada equipo y Scrum Master la va adaptando a sus necesidades según le venga mejor.
En primer lugar, tras una intervención en la forma en como veníamos haciendo las planificaciones de Sprint, las hemos optimizado mucho. Un error que tuvimos era comenzar la reunión sin ningún tipo de «agenda». Si bien no es necesaria la formalidad, desde el último Sprint Planning comenzamos a seguir un hilo conductor. El Sprint Planning se puede dividir en dos partes:
¿Qué se tiene que hacer?
Participan el Product Owner y el equipo. Definimos qué objetivos queremos lograr en este Sprint. En esta instancia el Product Owner participa definiendo las prioridades como siempre. Los objetivos son definidos y explicitados de manera que todos seamos concientes del objetivo del Sprint.
¿Cómo se tiene que hacer?
En esta etapa, el equipo granula un poco más las historias de usuarios de manera de obtener tareas específicas. Parte de este trabajo se hace en esta etapa inicial, pero otra gran parte se va realizando en los Daily Meeting, a medida que se van definiendo bien las tareas.
El error más grande que tuvimos en nuestro primer Sprint, fue la estimación de las tareas. Siendo ésta la segunda aplicación de Scrum, puede identificar un patrón. Es muy difícil para un equipo estimar el tiempo que le va a llevar realizar el trabajo, si nunca lo hizo antes. Además, se cae en dos errores aparentemente comunes:
No definir el alcance de una tarea: Las tareas se definen a muy alto nivel. Por ejemplo «Alta, baja y modificación de Usuarios» puede sonar a tarea sencilla. Pero puede afectar varias áreas: el análisis del modelo de negocios, la interfaz, el acceso a base de datos, etc. Por esto, uno de los primeros aprendizajes fue definir el alcance y limitaciones de una tarea, y tratar de definir todo el trabajo que abarca que un ABM de usuarios esté terminado.
Sobrestimar capacidades o subestimar tareas: Esto sucede sobretodo en equipos nuevos o con poca experiencia. El equipo con el que contamos se consolidó recientemente (aproximadamente cuando comenzamos a implementar Scrum) y la arquitectura y tecnologías con las que trabajamos deben ser asimiladas y comprendidas por cada integrante del equipo.
A medida que el equipo se va introduciendo en el ritmo, todo se va mejorando de a poco. Todavía queda trabajo por hacer, pero es bueno ver que no nos estamos quedando en la zona de confort.
A unos dos o tres Sprint desde que comenzamos a aplicar Scrum, hemos evolucionado bastante. Se nota el progreso de cada Sprint con respecto al anterior. Comencé este post como un resúmen general de todas las cosas que hemos ido cambiando, pero quedó bastante largo, por lo que decidí ir publicando de a uno los aspectos de Scrum que han evolucionado, y de qué manera. Así resulta mas cómodo de leer, y cada aspecto queda atomizado en su post.
Estuve leyendo Scrum and XP from the Trenches (Scrum y XP desde las trincheras) de Henrik Kniberg. Saqué muchas ideas de ahí, quienes lo hayan leído las podrán detectar. El libro es bien práctico y explica como Kniberg aplicó Scrum en su equipo. Es sumamente recomendable, una vez que hayamos adquirido la teoría de Scrum, darle una leída para ver cómo solucionó distintas partes de aplicar Scrum. La otra opción es buscar más libros, comunidades y blogs de Scrum (como éste 🙂 ) que comenten sobre sus aplicaciones para aprender y nutrirse de la experiencia de otros. Hay una versión gratuita para descargar en InfoQ (también ahí pueden comprarlo) o en español.
Todavía no estamos utilizando estimación ni burndown charts, pero ya habrá tiempo. Cada Sprint ha sido mejor que el anterior, tanto en la gestión del Scrum, como la agilidad del equipo. Así que habrá tiempo para ir perfeccionándolo.
