Visual Scrum - What you see is What you get

Visual Scrum - What you see is What you get Vanesa Tejada Muõz n vatemu@gmail.com Resumen La gestiń visual es una potente herramienta que permite a o desarrolladores, scrum master, l´ıderes de equipo y personal de direcciń, o conocer el estado de sus proyectos de una forma m´s r´pida y eficiente, de a a manera que la mayor parte de su tiempo se inviterta principalmente en la prevenciń de bloqueos en los equipos y toma de decisiones. Este art´ o ıculo presenta un conjunto de ideas para trabajar la gestiń visual, adaptadas o a los diferentes roles que existen en una empresa, y la informaciń que o necesitan para desempeãr su trabajo. n ´ Keywords: Agil, Scrum, Scrum board, mejora cont´ ınua, gestiń, infor- o maciń, estrategia, negocios, roadmap. o1 Introducciń oCuando las empresas contratan el desarrollo de un proyecto, ´ste forma parte de euna estrategia de negocio. Dados unos requisitos de un cliente, la empresa destinael proyecto a un equipo de trabajo, quienes se responabilizan del desarrollo delproducto. En esta simple definiciń de proyecto, vemos claramente la existencia de tres oroles: direcciń de empresa, cliente, equipo de trabajo. o Las metodolog´ ´giles resaltan el papel que juegan los equipos de desarro- ıas allo, un papel principal de todo el ciclo de vida del proyecto, quienes realmentelo hacen realidad. La involucraciń del equipo de trabajo en todo el proceso de odesarrollo debe ser completa. Esto quiere decir que el equipo debe conocer per-fectamente qu´ desea el cliente, validar con ´l las tareas que han implementado e epara poder solucionar los fallos, conocer el alcance del producto y deben ser ellosquienes principalmente, recojan este feedback para mejorar su siguiente entregadel producto. Durante el desarrollo del proyecto, equipos que trabajan con Scrum, utilizanuna pizarra para representar las tareas que deben llevar a cabo en un periodode tiempo concreto, un sprint. La pizarra de Scrum es un ejemplo perfecto degestiń visual. En ella el equipo tiene claramente definidos sus objetivos a corto oplazo correctamente priorizados para alcanzarlos. Diariamente el equipo trabajasobre este panel, representando en ´l su flujo de tareas por hacer, en progreso ey completadas, se comunica y tiene la capacidad de coordinarse y gestionarsepor s´ mismo, gracias a que tiene claras las metas hacia las que camina, y est´ ı ainvolucrado con el producto.

Al igual que el equipo de Scrum, el resto de los roles del proyecto necesitanconocer con cierta periodicidad el estado del producto. Habitualmente, se rea-lizan reuniones de seguimiento, se presentan documentos de texto, res´menes o ulistado de puntos a tratar. Aunque esta informaciń puede estar completamente ocorrecta, en este art´ ıculo se pretende mostrar el estado del proyecto con panelesadecuados a la informaciń que estos roles necesitan recibir, es decir, se desea opotenciar la gestiń visual para el resto de los roles involucrados en el proyecto, oadaptńdolas a su ´mbito de trabajo. a a2 Visual ManagementLa gestiń visual permite tener una idea completa del trabajo que estamos e- olaborando de una forma muy clara y eficiente. Hoy en d´ en el mundo de las ıa,empresas de software, son muchos los proyectos que estń en marcha al mismo atiempo, cada uno de ellos tiene un equipo o varios trabajando para sacarloadelante. Cada proyecto es un mundo, algunos son nuevos partiendo de cero, enotros casos los proyectos son evolutivos y tienen mantenimiento, incluso existenproyectos que s´lo tienen mantenimiento, pero lo que todos tienen en comń es o ula necesidad de una labor de gestiń. o La gestiń visual nos va a permitir mostrar las tareas que el equipo debe oabordar, de una forma clara, sencilla, para centrarnos en la gestiń de las mis- omas en funciń del tipo de proyecto que tengamos, logrando dar una mayor operspectiva y capacidad para llevar a cabo planes de acciń. o3 Visual ScrumEl concepto Visual Scrum, es una idea que surge de la necesidad de ampliara otros tipos de proyectos y otros roles involucrados en el producto, la gestińovisual respecto la metodolog´ ´gil de Scrum. El objetivo es ofrecer a cada role ıa ala informaciń que necesita sobre un proyecto en funciń de su perspectiva. o o La figura 1 muestra los roles que van a tomar parte en algunas de las propu-estas de la gestiń visual: o Los roles que aparecen son: personal directivo de una empresa centrados enlos objetivos de negocio, los product owner encargados de facilitar los requisitosde los proyectos a los equipos de desarrollo, y finalmente el equipo ´gil que aimplementar´ el producto. La perspectiva de cada role para una simple tarea en aesta jerarqu´ es completamente diferente, partiendo de un objetivo de negocio, ıaque se desgrana en un conjunto de historias de usuario, que finalmente, se dividenen un conjunto de subtareas que se deben implementar. Aunque todos los rolestienen su implicaciń en el proyecto, la informaciń que estos precisan no tiene o opor que ser la misma para todos en cada momento, al igual que puede no serigual su forma de acometer el proyecto. En funciń de estos roles vamos a presentar diversos escenarios de trabajo, ocon varios tipos de proyectos para ver c´mo podr´ o ıamos llevar a cabo una gestiń ovisual en cada caso.

Fig. 1. Jerarqu´ de roles ıa3.1 Scrum BoardUn equipo de desarrollo, lleva cabo un conjunto de tareas que se han planificadopara un sprint o iteraciń. Las tareas pueden ser mejoras, nuevas funcionalidades oo errores en el producto que deben solucionarse cuanto antes. Los equipos puedenadaptar el trabajo en una tablń que represente el ciclo de vida de una tarea, odesde que no hemos empezado a trabajar con ella, hasta que podemos decirque est´ terminada. Dado que conocen el alcance del proyecto, en su secciń de a obacklog ordenarń las tareas ań no planificadas. La figura 2 muestra un sencillo a upanel adaptado a esta situaciń de trabajo. o Fig. 2. Pizarra de Scrum Ahora imaginemos que el equipo decide que la persona que lleva a cabo eldesarrollo no sea la misma que haga la validaciń final antes de la demostraciń o o

con el cliente. Esta situaciń puede darse para mantener la transferencia de oconocimientos, ver c´mo se ha realizado la implementaciń y corroborar que la o otarea cumple con la definiciń de DONE (DoD) que se haya especificado a nivel ode equipo. De alguna manera ahora, se deben marcar las tareas para indicarquiń ha realizado su desarrollo y pruebas, y quiń ser´ el responsable de validar e e ala tarea completamente. Por otro lado, en ocasiones aparecen tareas no previstas, algo inevitablemuchas veces que se da en el d´ a d´ Puede deberse a algń problema grave ıa ıa. uen el producto o porque en la planificaciń del sprint se ha pasado algo por oalto. En este ultimo caso, es muy probable que ante un sprint ya planificado no éxista tiempo restante para abordar una tarea no prevista, pero en caso de tenerque hacerla obligatoriamente, se deber´ identificar en nuestro panel y otra tarea ıatendr´ que ser replanificada por este motivo. La figura 3 presenta como plasmar aen nuestro panel de Scrum los dos escenarios mencionados: Fig. 3. Pizarra de Scrum con tareas personalizadas y mantenimiento En en primer caso, las columnas de IN PROGRESS y TESTING identificanla persona que tiene la tarea asignada. Cuando una tarea cambie de estado elequipo decidir´ en la reuniń diaria quiń lleva a cabo la validaciń segń la a o e o ucarga de trabajo de cada miembro. El segundo caso puede hacerse de dos maneras, bien dejando una seciń oseparada en nuestro tablń para las tareas as soon as possible (ASAP), o bien, oponiendo la tarea no prevista encima de aquella que probablemente no se lleve acabo en el sprint, es decir, la tarea sacrificada. Es muy interesante evaluar en laretrospectiva del equipo, si existe alguna forma de evitar esas tareas no previstas,si durante varios sprints han sido este motivo el que no les ha permitido alcanzarsu objetivo o incluso si existe alguna forma mejor de que el equipo se coordinepara abordar estos casos sin que el sprint se vea afectado. Al final de toda iteraciń se obtiene como resultado un incremento del proyecto otal, que permitir´ poder presentar estas mejoras como producto terminado al ıa

cliente tan pronto como lo solicite. Generalmente en esta demostraciń se evalán o ulas funcionalidades delante del cliente, pero quiz´, haya otras maneras de poder ahacer un seguimiento intermedio de c´mo va la aplicaciń. Si nos imaginamos o oque vamos a hacer un nuevo proyecto web, para el cual se han definido unosrequisitos de usuario y se han llevado a cabo unos diseõs, podr´ n ıamos aãdir nalgo m´s a nuestros paneles de Scrum que las tareas. Los elementos que van aa componer la web junto con sus correspondientes funcionalidades, son lo quese definirń como historias de usuario, que una vez completadas indicarń que a aese botń, tabla o pestaã de informaciń ya est´ funcionando. En este caso o n o apodr´ıamos poner los diseõs de la web en nuestro panel, inicialmente en blanco, ny los componentes tenerlos a parte recortados. Cada vez que terminemos unahistoria de usuario, habremos completado la funcionalidad de uno de los compo-nentes, por lo que lo aãdimos a ese diseõ en blanco. De esta forma innovamos n nel modo en que el equipo crea esa nueva p´gina web, incluso si alguien pasara por anuestro panel o tuvi´ramos un seguimiento con el cliente, simplemente viendo eel diseõ con sus piezas, podr´ evaluar el trabajo que se est´ haciendo y lo que n ıa anos falta. En la figura 4 tenemos un ejemplo de c´mo ser´ el proceso: o ıa Fig. 4. User Story componen la web3.2 Scrum of ScrumLos proyectos en los que trabajamos no siempre se desarrollan dentro de unmismo departamento, en numerosas ocasiones es necesaria la implicaciń de ootros equipos. En estas situaciones la coordinaciń del proyecto es algo funda- omental, ya que el objetivo no es s´lo que las tareas salgan adelante, sino que opodamos identificar una linealidad a la hora de la planificaciń y trabajar para ola prevenciń de bloqueos y cuellos de botella, situaciones que se dan cuando ohay muchas dependencias externas y la gestiń no es la adecuada. o A continuaciń vamos a presentar varios paneles de Scrum con diferentes oopciones para la gestiń de un proyecto de estas caracter´ o ısticas. En estos paneless´lo se muestran tareas en un nivel de abstracciń superior al de los paneles o ode equipo, es decir, en estos paneles no se muestran las subtareas que puedencomponer las historias de usuario. La figura 5 presenta todas las acciones que debe llevar a cabo cada uno delos equipos involucrados en el proyecto y el estado en que cada una de ellas seencuentra. La visiń es muy global en cuanto a las tareas que cada equipo debe o

realizar, pero si existen tareas dependientes se pierde la relaciń entre ellas, y por otanto, existe una mayor dificultad a la hora de preveer situaciones de bloqueo. Fig. 5. Scrum Multiproyecto La figura 6, representa un diagrama de flujo de historias de usuario, condiferentes colores para identificar las que pertenecen a diferentes departamentos.En este caso s´ vemos las dependencias que existen entre ellas, por lo que podemos ıir un paso por delante en la gestiń de interrupciones. o Fig. 6. Scrum Multiproyecto con dependencias Cada una de las tareas tiene una marca de estado, en este ejemplo se hanutilizado s´ ımbolos de progreso, realizada, bloqueo y ayuda, para las que no tienenla definiciń de requisitos completa. o

La figura 7, representa un escenario en el cual, tenemos un proyecto con unadeterminada fecha de inicio y fecha de fin, se conocen todas las tareas que debenllevarse a cabo para su finalizaciń y esto nos permite, saber en cada sprint, olos objetivos que tenemos que completar. La visibilidad del proyecto en estecaso es completa (big picture), adem´s de permitir al equipo y product owner arevisar la planificaciń de sprints posteriores. En este caso podemos tener una osegunda utilidad para este mismo panel: si todas las tareas estń igual colore- aadas, podemos asociarlas a un mismo departamento, sin embargo, si las tareaspertenecieran a diferentes departamentos, s´lo tendr´ o ıamos que identificarlas concolores distintos. Fig. 7. Planificaciń completa de sprints de un proyecto o3.3 Scrum Roadmap BoardEn esta ultima secciń se propone c´mo elaborar un roadmap anual de una ´ o oempresa. La visiń de un gerente est´ centrada en los proyectos de negocio o aque proporcionan grandes beneficios a la empresa. Estos proyectos pueden estardesignados a un unico equipo de desarrollo o varios, y finalmente, cada uno de éstos proyectos se pretende completar un un trimestre en concreto. El d´ a d´ de los equipos puede hacer que una tarea de negocio se termine ıa ıaen el tiempo estimado, no se complete en la fecha deseada o que, por otrasprioridades que han ido apareciendo no lleguen a empezarse. Lo importante enestos casos, no son unicamente los motivos por los cuales esas tareas se han tenido ´que replanificar, lo verdaderamente urgente es redefinir una estrategia, ver losproyectos que se pretenden abordar en el aõ y evaluar si, alguno de los que nno se han podido empezar son m´s importantes que los que estń planificados a apara trimestres posteriores o si por el contrario, son m´s importantes los que aań no se han iniciado y el que se qued´ atr´s, se deja pendiente de planificar. u o aEl gerente debe tener una visiń m´s amplia, conociendo las tareas en curso y o a

posteriores, podr´ tomar decisiones sabiendo el impacto de ellas en cada uno de alos proyectos. Para que esta evaluaciń de cr´ o ıticas decisiones se haga teniendotoda la informaciń a la vista, podemos definir un panel de donde se muestren otodos los par´metros que necesitamos conocer. En la figura 8 se presentan las atareas estimadas para cada Quarter 1 (QX) y su transiciń de estados. Para odiferenciar el proyecto al que corresponde, se pueden usar diferentes colores. Fig. 8. Scrum Roadmap La figura 9 se presentan las tareas estimadas para cada QX en funciń del oproyecto, y para identifcar su estado se marcan con s´ ımbolos. Este ejemplo mues-tra una foto del estado de proyectos de negocio al completo. Fig. 9. Scrum Roadmap

4 ConclusionesLos equipos de trabajo mejoran en coordinaciń e implicaciń en el proyecto o ocuando obtienen una perspectiva mas amplia de todo el trabajo que tienen querealizar. Podemos obtener resultados similares en otras areas de la empresa in-corporando estas tcnicas en las reuniones de seguimiento. Es posible adaptarnuestras pizarras de Scrum de muchas formas en funciń de en qu´ queramos o ehacer incapi´. Hay m´ltiples tablones para que un equipo sepa en qu´ estado e u eest´ su trabajo y se involucre m´s, construyendo el camino hacia una meta. a a La informaciń visual tiene mucho potencial, simplemente de un vistazo, onuestros gerentes, directores de departamentos y product owners, podr´ saber ıanc´mo est´ un proyecto en un menor espacio de tiempo. Las reuniones de segui- o amiento ser´ m´s ´giles y productivas, dejando paso a pensar a futuro sabiendo ıan a alo que tenemos en el presente. Aunque el agilismo aporte muchas mejoras a laempresa, de cara a negocio, todos los agilistas, debemos realizar un gran esfuerzopor transmitir los principios a este ´rea, para que no quede en un concepto y asea algo que en el futuro nos defina como empresa y grupo. Este art´ ıculo muestra otras formas de presentar un conjunto de situacionesque podemos tener en el d´ a d´ y queremos gestionar de una forma m´s ´gil ıa ıa, a ay sencilla, donde no perdamos informaciń. Se prentede con este conjunto de opaneles dar un ejemplo de mejora continua, abriendo otras posibilidades a losequipos, scrum master, product owners, y responables de negocio, que puedenestar al d´ del estado de los desarrollos de una forma m´s sencilla y fćil de ıa a aasimilar.AgradecimientosGracias a los miembros de Agile-Spain, por llevar a cabo eventos en los quenumerosas personas, apasionadas por mejorar su trabajo, se unen para compartirexperiencias y enriquecerse mutuamente. Gracias por permitirme escribir esteart´ ıculo, sobre una de las sesiones presentadas en el evento de la Conferencia deAgile-Spain en Castellń en 2011. oBibliograf´ ıa1. David Sibbett: Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity. John Wiley, Canada (2010)2. Visual Management Blog. Using information visualization to manage agile projects. http://www.xqa.com.ar/visualmanagement/

Visual Scrum - What you see is What you get

by Agile Spain on Dec 20, 2011

Accessibility

Tags

Upload Details

Usage Rights

Statistics

Visual Scrum - What you see is What you get — Document Transcript