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.
La empresa AQuA.it vuelve a organizar una instancia del curso de certificación Scrum Master en Montevideo. Alan Cyment vuelve a visitarnos para certificar a una nueva generación de Scrum Masters uruguayos. Ya habían informado de una nueva instancia del curso en febrero de este año, pero ahora más cerca de la fecha confirman la agenda.
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.
A continuación los contenidos 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.
Personalmente, comprobé que a pesar de la teoría, el curso nos ayuda a concebir la esencia de Scrum. Pude entender porqué funciona, y cómo lo hace. Hubo definitivamente un antes y un después del curso en la aplicación de Scrum.
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.
En cuanto a la experiencia del curso, es interactivo y enriquecedor. Olvídense de las presentaciones en diapositivas, ni siquiera vimos una pantalla en los dos días. Va a ser algo distinto desde el primer momento, y va a valer la pena. Y en cuanto a Alan Cyment, el entrenador del curso:
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.
Los datos completos y actualizados de la agenda:
Fecha de comienzo: Jueves 8 de julio de 2010.
Fecha de finalización: Viernes 9 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 caja de ahorro en dólares nº 8640118, Banco ITAU, Sucursal Aguada.
En diciembre cambié de trabajo, dejé Maldonado, y me vine a vivir a Montevideo y a trabajar en una empresa nueva. Por lo tanto, comencé una reimplementación de Scrum. Así como cada Sprint se debería notar una mejora en el proceso de trabajo, en esta implementación de Scrum noté lo mismo con respecto a la anterior.
Es un equipo totalmente diferente, pero la experiencia adquirida hasta el momento permitió que esta nueva instancia de Scrum fuera más formal y se aplicara más ágilmente. Empezamos a difundir el conocimiento sobre Scrum con correos como el de planificaciones de Sprint, y Scrum empezó a trabajar por sí solo. Se fomentó la comunicación y colaboración en el equipo de forma orgánica. Y así logramos llegar a la primera planificación de Sprint.
Por ahí en el medio tuve la idea de estudiar con Scrum, tema pendiente. En verdad no llegué a organizar mi forma de trabajo en casa, ya que pensaba incluir estudios y trabajos freelance bajo un mismo Scrum, incluso tengo la pizarra. Pero está pendiente, así que espero poder concretar mi Scrum personal en el futuro próximo.
Aplicando Scrum - primer año
Hoy sigo usando Scrum en mi trabajo. Y sigo abogando por su uso como metodología ideal en un grupo de trabajo. Por lo menos de lo que conozco, es lo mejor. Scrum no resuelve problemas, pero los identifica rápido. Y es una metodología sincera, transparente y
Hace poco Tobias Mayer publicó algo en Twitter que me quedó grabado como una buena definición de Scrum: Scrum es un framework basado en valores; no es una metodología, ni un proceso, ni una herramienta.
Quedo en deuda con los lectores, de contarles un poco más cómo venimos usando Scrum. ¡Gracias por leerme!
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.
