Archivo de la etiqueta: Task Board

Evolución del 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.

Pizarra Scrum

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.

Columnas en el Task Board

Uno de los temas a la hora de implementar Scrum, es qué columnas se van a usar en el task board. Algunos separan el task board en 4, 5 o más columnas. El task board debería ser una representación del estado del proyecto, que muestre a simple vista la situacion actual. Debería ser una referencia para saber en qué va la cosa con solo mirarlo. Por lo tanto, habría que tratar de mantener el nivel de complejidad al mínimo posible. De todas formas, como todo en Scrum, su implementación debería irse adaptando a las necesidades del equipo de trabajo.

Al principio de mi anterior implementación de Scrum, usábamos el pizarrón como Task Board. Más adelante, usamos un espejo que había en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida, pero ahora lo enfrentamos con más experiencia y otro conocimiento.

Usamos post-its de distintos colores para diferenciar tipos de tareas.
Referencia de colores:

  • Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint.
  • Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo.
  • También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre.

Todos los movimientos en el Task Board se relizaban únicamente en el Daily Meeting, de manera que todo el equipo estuviera al tanto de lo que sucedía con el proyecto, y por el compromiso que implica llevar una tarea a la columna de “finalizado”.

Así fue como decidimos usar el task board en ese momento, y era lo que nos sirvió. Cada equipo debe adaptarlo a sus necesidades y aprender de la experiencia en su uso diario.

La ciencia trás la gestión visual

Este video fue publicado originalmente en el blog de Xavier Quesada Allue, Visual Management Blog (lectura muy recomendada). Tenía ganas de pasárselo a un compañero de trabajo, pero el video está únicamente en inglés. Como Scrum se basa en gestión visual como parte del framework, está interesante compartir de qué se trata acá mismo. Lo que sigue es algo así como mis apuntes del video, traduciendo partes, y tratando de sacar el significado básico de lo que intenta transmitir en español.

En el video, el diseñador de información Tom Wujec habla sobre las tres áreas del cerebro que nos ayudan a comprender las palabras, imágenes, sentimientos y conexiones. Durante la charla pregunta: ¿Cómo podemos engranar nuestros cerebros de la mejor manera para ayudarnos a entender mejor grandes ideas?

Basado en la demostración de un proyecto de forma visual por medio de bocetos de artistas, aclararon la complejidad de su proyecto BigViz. Capturando la esencia de las ideas de cada presentador. consensuaron en que realmente funcionó. Entonces analizaron, ¿porqué funcionó? : Las representaciones visuales crearon el significado de lo que querían demostrar.

Para entender mejor esto, se planteó visualizar cómo el cerebro visualiza. El cerebro no ve las cosas como son, sino que crea modelos mentales a través de momentos de descubrimiento mediante varios procesos. El proceso comienza por los ojos que envía la información a la corteza visual en la parte trasera del cerebro:

Es la mas simple, temprana area visual cortical. Esta altamente especializada en el procesamiento de información acerca de los objetos estáticos y en movimiento y es excelente en el manejo de reconocimiento de patrones.

Wikipedia

Redirige información a otras partes del cerebro, que le dan más sentido a la información que recibió. Comenta sobre tres de estas partes del cerebro que analizan la información visual:

Ventral Stream

La parte del cerebro que reconoce “Qué” es algo, una mano, un control remoto, una silla, un libro. La parte del cerebro que se activa cuando relacionamos una palabra a un objeto.

Dorsal Stream

Localiza al objeto en el espacio físico corporal. Explica por ejemplo mirando el escenario donde está exponiendo su conferencia, uno se hace un mapa mental del escenario, y cerrando los ojos, podrían “navegarlo” mentalmente. En este caso estarían activando esta parte del cerebro.

Limbic System

El sistema límbico es un sistema formado por varias estructuras cerebrales que gestiona respuestas fisiológicas ante estímulos emocionales. Está relacionado con la memoria, atención, instintos sexuales, emociones (por ejemplo placer, miedo, agresión), personalidad y la conducta. Está formado por partes del tálamo, hipotálamo, hipocampo, amígdala cerebral, cuerpo calloso, séptum y mesencéfalo.

Wikipedia

La combinación de estos 3 centros de proceso nos ayudan a crear sentido de varias maneras distintas. ¿Cómo aplicar esto a la vista? ¿Cómo aplicar esto en la práctica? La vista interroga lo que miramos, el cerebro lo procesa en paralelo haciendo muchas preguntas para crear un modelo mental unificado. Explica con un ejemplo que un buen gráfico invita a recorrer y crear una lógica visual selectivamente, el acto de mirar, crea el sentido, es la lógica selectiva.

El acto de crear imagenes interactivas enriquece el significado activando una parte distinta del cerebro. El sistema límbico se activa al ver acción, colores, y hay formas y detección de patrones.

El punto de esto es: creamos significado viendo, a través del acto de interrogación visual. Las lecciones son 3;

  • Usar imágenes para aclarar las ideas
  • Interactuar con las imágenes para crear compromiso
  • Aumentar la memoria creando persistencia visual

Estas técnicas pueden usarse en varias áreas de resolución de problemas. Seguido de esto, muestra un video de la planificación estratégica visual que lleva a cabo en su compañía, donde todo el equipo participa en una pared gigante. Todos ven todo, y el equipo construye colaborativa y colectivamente. Se crea un modelo mental compartido de forma visual.

Esto es exactamente lo que busca Scrum con su taskboard. Por esto es importante que las reuniones de daily meeting se hagan entorno al taskboard. XQA también habla de esto en su post Daily Scrum against the board:

Un equipo que usa gestión visual para gestionar su trabajo siempre hará sus daily standup contra el tablero. Durante las reuniones diarias actualizas a tus compañeros de equipo sobre tu trabajo. Tanto el trabajo terminado el día anterior como el trabajo en progreso debe ser indicado claramente en el tablero. Solo tiene sentido ir sobre el tablero mientras hablas. Esto es tanto más fácil para tí como para los miembros del equipo. También ayuda a poner en contexto visualmente lo que estás diciendo.

Sprint heroico – Planificación y Task Board

Task Board Scrum

Task Board Scrum

Como comenté en una entrada anterior (Implementando Scrum: Cómo empezamos), nuestro Product Owner se encontraba hasta hace poco fuera del país. Recientemente volvió a trabajar desde nuestra oficina, lo que nos permitió realizar una primera planificación de Sprint con el Product Owner presente. Las ventajas de contar con su presencia saltaron a la vista, ya que la priorización y negociación de tareas se hizo de una forma muy fluída, así como también se despejaron algunas dudas instantáneamente durante la planificación misma.

Además de eso, este Sprint tuvo varias características que lo hicieron único respecto a los anteriores:

  • La planificación se realizó fuera de horario. Debido a complicaciones varias del lunes, nos juntamos en la tarde, mientras que los Sprints anteriores se hacían lo más temprano posible. Esto no cumple con el espíritu de Scrum en cuanto al enfoque de time-box, mantener el ritmo, la disciplina y compromiso. Sin embargo, hay que tomar lo que sirve, y en este caso nos sirvió hacerla tarde.
  • El equipo constaba de 7 programadores. Ahora se sumaron a la planificación los 2 diseñadores gráficos del proyecto. Estamos en etapa de maquetación e integración del código PHP con el diseño, por lo que volvimos a juntar a todos los responsables del desarrollo del proyecto. Además, el Scrum Master (yo) abandona temporalmente su puesto de director en el equipo, por razones planteadas en el siguiente punto, y se integra como un programador más.
  • Nos encontramos muy cerca a una fecha de entrega, dos semanas. Teníamos varias características del producto definidas para esta entrega, que veíamos difícil de implementar. Por esto, hicimos una planificación bastante profunda, para tratar de meter todas las tareas importantes en un Sprint que por primera vez contaría con dos semanas de duración. Esta era la idea inicial, pero al estar empezando con Scrum, decidimos que una semana permitiría estimaciones más precisas. Desde mi punto de vista, el equipo ya se encuentra en condiciones de planificar los Sprints a dos semanas. Además la presencia del Product Owner facilita las cosas.
  • Implementamos el Scrum Task Board. Como comenté, usábamos el pizarrón como Task Board. Ahora usamos un espejo que hay en la oficina de desarrollo. Ya lo habíamos usado en nuestra primer implementación fallida de Scrum. Usamos los post-it amarillos para mostrar las tareas que fueron estimadas y asignadas durante el planning del Sprint. Los post-it naranja son tareas nuevas que fueron surgiendo, y trataremos de mechar con otras, o realizar si da el tiempo. También agregamos post-it verdes, que son tareas opcionales, para tiempo que sobre. Todos los movimientos en el Task Board se realizan únicamente en el Daily Meeting, de manera que todo el equipo esté al tanto de lo que sucede, y por el compromiso que implica llevar una tarea a la columna de “finalizado”
  • En lo personal, es un Sprint más “feliz”, ya que dejé mi puesto de Project Manager y Director, para meterme de lleno en el código. Así que ahora estoy cumpliendo el rol de Scrum Master así como de desarrollador del equipo.

Lo interesante de la planificación fueron las etapas . En un principio se sentía mucha tensión, presión, nervios, miedo, stress… Pero la presencia del Product Owner (también jefe del equipo), se hizo notar, y las cosas llegaron a una buena conclusión. Demoramos algunas horas en definirlo, pero llegamos a una planificación completa de las dos semanas siguientes de trabajo. Esto fue el lunes de la semana pasada, y a más de una semana, puedo decir que ha resultado. Hoy el Task Board tiene mucho más tareas naranjas agregadas, así como algunas amarillas más (mayor granulación de algunas tareas), pero la columna de “terminado” está colmada.

Un Sprint muy especial, por todo lo comentado. En teoría, tendríamos un review y reflexión de este “Sprint heróico” el día 3 de agosto, así que ya comentaré cómo estuvo eso. Mientras tanto, ¡a programar!