Archivo de la etiqueta: Scrum

Evolución del Task Board

Gestión visual, Task Board, ,

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
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.

Reimplementación de Scrum: Perfeccionando la planificación de Sprint

Planificación del Sprint,

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.

Progreso de la reimplementación de Scrum

Scrum

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.

Pizarra Scrum

Task Board,

Me compré una pizarra de corcho para usar de Task Board y comenzar a implementar Scrum en casa. Como comenté en el post anterior, pienso aplicar Scrum para estudiar. Para empezar, compré unos post-its amarillos, y esta pizarra de 45×60 cm:

Pizarra Scrum
Pizarra Scrum

Estamos avanzando bien con la implementación de Scrum en el trabajo. Hemos ido aplicando algunas cosas interesantes, y se viene mejorando el proceso de a poco. Ni bien tenga tiempo, escribo un  resúmen de cómo ha ido.

En cualquier momento empezaré a trabajar en la aplicación de Scrum para mis estudios, y ahí empezaré a contar cómo lo voy manejando y qué voy aprendiendo.

Estudiar con Scrum

Scrum,

El siguiente post es solo una idea, que pienso probar de poner en práctica, y ver si me funciona. Estoy retomando los estudios en la Facultad de Ingeniería. Además de eso, estoy trabajando y tengo unos cuantos proyectos más en la lista de cosas para este año. Si bien pienso dedicarle tiempo a la facultad, soy conciente que con la cantidad de cosas que tengo arriba, no voy a poder dedicarle una cantidad importante de tiempo.

Por esto, tengo que exprimir el tiempo que le dedique a los estudios, usándolo de manera efectiva y aprovechando cada minuto. Se necesita una buena gestión de la cantidad de trabajo, priorizándolo según el retorno de inversión de tiempo que tenga cada tarea. Así que sin pensar demasiado el tema, puedo perfectamente aplicar Scrum para organizar de manera efectiva mis estudios.

Esto sería una aplicación de Scrum personal, donde yo mismo ocuparía el rol de Scrum Master, Product Owner y equipo. Como Product Owner, voy a saber cuáles son las tareas que me interesan más, según su retorno de inversión, poniéndolas por delante de aquellas que me resulten más fáciles o simples. Como Scrum Master voy a ser responsable de que mi Scrum se realice de manera positiva, y como equipo, voy a estar encargado de realizar mis tareas.

Es algo que estoy considerando, debería probarlo por un tiempo. Tendría además que obligarme a cumplir las instancias de Scrum: Sprint Planning, Daily Meeting, Retrospectiva y Reflexión.

Sprint – Debería hacer los Sprints de corta duración: 1 semana; ya que de a poco voy a ir viendo qué hay por estudiar por cada materia. Además, podré priorizar los temas a estudiar según los resultados que vaya obteniendo: «En esta materia me fue mal en el parcial, tengo que dedicarle más tiempo». El Sprint Planning debería hacerse todos los lunes o domingos, ya que es cuando comienza la semana de clases. Incluso podría hacer un burn chart, donde detectaría qué materias me cuesta más estudiar basado en los resultados que obtenga.

Daily Meeting – Como en un equipo de trabajo, se trataría de verificar la cantidad de tareas estimadas contra las realizadas, detectar problemas, y comprometerse con nuevas tareas.

La retrospectiva y reflexión serían bastantes personales, ya que yo mismo estaría revisando si los resultados obtenidos son satisfactorios.

Es importante tener un backlog, donde pueda ir pegando tareas «por realizar», para ir incluyendo en Sprints siguientes.

Todo esto requeriría un compromiso personal con el trabajo (el estudio), y demandaría bastante disciplina de mi parte. Es algo bastante complejo, creo, pero sencillo a la vez. Me mantendría fuera de la zona de confort, y como siempre digo: usar Scrum para gestionar el trabajo es mejor que no usar nada.

En fin, realmente lo estoy considerando aplicar. Voy a ver si consigo un pizarrón, unos post-it, y empiezo. También voy a incluir tareas de otros proyectos, reuniones y demás, para gestionar el tiempo completo de forma realista. Al igual que en los proyectos de software, en la vida diaria aparecen muchas tareas no planificadas. Por esto, estoy pensando si usar una referencia de colores de post-it según el área a la que involucren: estudio (incluso por materia), trabajo, otros, etc. o según tareas planificadas, no planificadas, etc.

Creo que podría usar post-it amarillos para tareas que se desprenden de la planificación y post-it rojos para tareas que surjan de apuro. Como referencia, puedo usar los post-it más chicos que hay de distintos colores, para identificar a qué área pertenecen. En fin, por ahora esto es solo una idea, pero creo que por lo menos voy a probarlo…