IR: Dependency Spider

0

Este es el primer Information Radiator de la serie, por lo que estoy un poco nervioso. Ya veremos que tal sale. El primero es el Dependency Spider o, en castellano “Araña de dependencias”.

Un Dependency Spider es un diagrama en el que se representan todas las dependencias que tiene un equipo con otros equipos, y las tareas que están bloqueadas por estas dependencias.

Teóricamente un equipo ágil debería ser autónomo. Es decir, que todo el trabajo que tiene que realizar dependa del equipo y sólo del equipo. Pero esto es imposible. Continuamente nos encontraremos con tareas que dependerán de otros equipos, ya sean de negocio, de operaciones o de desarrollo. Si un equipo sufre mucho de esto, se encontrará que en su panel Kanban o en el panel de trabajo del sprint, muchos tickets están bloqueados y no pueden avanzar. Algunos equipos optan por crear una columna especial, un estado, para esas tareas. Otros equipos optan por algún tipo de marca, como una pegatina o un tipo de imán, para marcarlos. Otro modelo es con el diagrama de dependencias en forma de araña, el Dependency Spider:

La idea es reflejar en el diagrama las tareas que tienen que realizar otros equipos para nosotros. Así podremos darles seguimiento. Hay dos posibles maneras de utilizar este diagrama:

  • Combinando tareas: Las tareas son todas del equipo y entran en el kanban. Cuando una tarea requiere que otro equipo realice algo, se mueve al dependency spider. Cuando el otro equipo la desbloquea, vuelve a su lugar al kanban.
  • Con sus propias tareas: Una cosas son las tareas del equipo y otra diferente los bloqueos. Cuando una tarea se bloquea se queda en el kanban, y se crea un nuevo ticket para reflejar el bloqueo en el dependency spider.

Las maneras de usar el panel son muchas. El equipo que empiece a usarlo pronto descubrirá la mejor manera de hacerlo, y de qué manera le es más útil. Y también descubrirá si le aporta valor, o si debe retirarse.

Como todos los Information Radiators, este panel ocupa espacio y tiempo para mantenerlo. Sólo recomendaría utilizarlo si los bloqueos por terceros son algo habitual y se quiere hacer un seguimiento especial. No hay que olvidar que una misión de los Information Radiators no es sólo informar al equipo, sino a toda la organización. Así los otros equipos verán el impacto que nos están causando con sólo pasar.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

Sin comentarios