Visual Scrum - What you see is What you get

871 views
770 views

Published on

Vanesa Tejada

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
871
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Visual Scrum - What you see is What you get

  1. 1. Visual Scrum - What you see is What you get Vanesa Tejada Mu˜oz n vatemu@gmail.com Resumen La gesti´n visual es una potente herramienta que permite a o desarrolladores, scrum master, l´ıderes de equipo y personal de direcci´n, 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´n de bloqueos en los equipos y toma de decisiones. Este art´ o ıculo presenta un conjunto de ideas para trabajar la gesti´n visual, adaptadas o a los diferentes roles que existen en una empresa, y la informaci´n que o necesitan para desempe˜ar su trabajo. n ´ Keywords: Agil, Scrum, Scrum board, mejora cont´ ınua, gesti´n, infor- o maci´n, estrategia, negocios, roadmap. o1 Introducci´n 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´n de proyecto, vemos claramente la existencia de tres oroles: direcci´n 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´n 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´n 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.
  2. 2. 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´n puede estar completamente ocorrecta, en este art´ ıculo se pretende mostrar el estado del proyecto con panelesadecuados a la informaci´n que estos roles necesitan recibir, es decir, se desea opotenciar la gesti´n visual para el resto de los roles involucrados en el proyecto, oadapt´ndolas a su ´mbito de trabajo. a a2 Visual ManagementLa gesti´n 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´n 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´n es o ula necesidad de una labor de gesti´n. o La gesti´n visual nos va a permitir mostrar las tareas que el equipo debe oabordar, de una forma clara, sencilla, para centrarnos en la gesti´n de las mis- omas en funci´n del tipo de proyecto que tengamos, logrando dar una mayor operspectiva y capacidad para llevar a cabo planes de acci´n. 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´novisual respecto la metodolog´ ´gil de Scrum. El objetivo es ofrecer a cada role ıa ala informaci´n que necesita sobre un proyecto en funci´n 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´n 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´n en el proyecto, la informaci´n 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´n 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´n ovisual en cada caso.
  3. 3. 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´n. 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´n 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´n de a obacklog ordenar´n las tareas a´n no planificadas. La figura 2 muestra un sencillo a upanel adaptado a esta situaci´n 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´n final antes de la demostraci´n o o
  4. 4. con el cliente. Esta situaci´n puede darse para mantener la transferencia de oconocimientos, ver c´mo se ha realizado la implementaci´n y corroborar que la o otarea cumple con la definici´n de DONE (DoD) que se haya especificado a nivel ode equipo. De alguna manera ahora, se deben marcar las tareas para indicarqui´n ha realizado su desarrollo y pruebas, y qui´n 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´n problema grave ıa ıa. uen el producto o porque en la planificaci´n del sprint se ha pasado algo por oalto. En este ultimo caso, es muy probable que ante un sprint ya planificado no ´exista 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´n diaria qui´n lleva a cabo la validaci´n seg´n la a o e o ucarga de trabajo de cada miembro. El segundo caso puede hacerse de dos maneras, bien dejando una seci´n oseparada en nuestro tabl´n 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´n se obtiene como resultado un incremento del proyecto otal, que permitir´ poder presentar estas mejoras como producto terminado al ıa
  5. 5. cliente tan pronto como lo solicite. Generalmente en esta demostraci´n se eval´an o ulas funcionalidades delante del cliente, pero quiz´, haya otras maneras de poder ahacer un seguimiento intermedio de c´mo va la aplicaci´n. 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˜os, podr´ n ıamos a˜adir 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´n como historias de usuario, que una vez completadas indicar´n que a aese bot´n, tabla o pesta˜a de informaci´n ya est´ funcionando. En este caso o n o apodr´ıamos poner los dise˜os 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˜adimos a ese dise˜o 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˜o 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´n de ootros equipos. En estas situaciones la coordinaci´n 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´n y trabajar para ola prevenci´n de bloqueos y cuellos de botella, situaciones que se dan cuando ohay muchas dependencias externas y la gesti´n no es la adecuada. o A continuaci´n vamos a presentar varios paneles de Scrum con diferentes oopciones para la gesti´n de un proyecto de estas caracter´ o ısticas. En estos paneless´lo se muestran tareas en un nivel de abstracci´n 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´n es muy global en cuanto a las tareas que cada equipo debe o
  6. 6. realizar, pero si existen tareas dependientes se pierde la relaci´n 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´n 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´n de requisitos completa. o
  7. 7. 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´n 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´n de sprints posteriores. En este caso podemos tener una osegunda utilidad para este mismo panel: si todas las tareas est´n 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´n completa de sprints de un proyecto o3.3 Scrum Roadmap BoardEn esta ultima secci´n se propone c´mo elaborar un roadmap anual de una ´ o oempresa. La visi´n 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 ´estos 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˜o y evaluar si, alguno de los que nno se han podido empezar son m´s importantes que los que est´n planificados a apara trimestres posteriores o si por el contrario, son m´s importantes los que aa´n no se han iniciado y el que se qued´ atr´s, se deja pendiente de planificar. u o aEl gerente debe tener una visi´n m´s amplia, conociendo las tareas en curso y o a
  8. 8. posteriores, podr´ tomar decisiones sabiendo el impacto de ellas en cada uno de alos proyectos. Para que esta evaluaci´n de cr´ o ıticas decisiones se haga teniendotoda la informaci´n 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´n 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´n 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
  9. 9. 4 ConclusionesLos equipos de trabajo mejoran en coordinaci´n e implicaci´n 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´n 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´n 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´n. 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´cil 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´n 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/

×