Gestionando tareas con metodologías ágiles: Kanban

  • Marcos Bermejo

    Marcos Bermejo

    Es programador desde el 2005, ha trabajado en varios lenguajes, en especial VB.net y más recientemente PHP. En los últimos dos años, ha estado formándose y aprendiendo sobre metodologías ágiles, hizo el Professional Scrum Developer de la scrum.org impartido por José Luis Soria y el curso de Coaching de equipos ágiles de Ángel Medinilla. En la actualidad, trabaja en Runroom como Scrum master y también como programador desarrollando aplicaciones web.

  • Marc Florit

    Marc Florit

    Ingeniero en Telecomunicaciones de formación, gestor de proyectos y servicios informáticos de profesión y facilitador de vocación. Inició su camino profesional creando su propia empresa en 1997 para dar servicio de acceso a Internet a particulares y pymes de Barcelona. En el año 2000 fichó por una consultora en la que consiguió formar parte, a lo largo de doce años, de gran parte de los departamentos y roles productivos, finalizando esta etapa como gerente de operaciones. Este bagaje le ofreció una enorme experiencia que le permitió entender la manera en que las personas trabajan y colaboran para lograr los objetivos demandados.

    A principios de 2012 creó WynWin y desde entonces colabora con profesionales y empresas con el objetivo de lograr la excelencia de sus equipos y productos, y optimizar sus procesos operativos y de negocio mediante la adopción de metodologías y técnicas ágiles.

  • Ramon G. Sedó

    Ramon G. Sedó

    Licenciado en Comunicación Audiovisual y desde hace más de quince años trabajando en la Universidad Autónoma de Barcelona, en el Instituto de la Comunicación, como director de la Unidad de Comunicación y Gestión de la Información, departamento responsable de conceptualizar y desarrollar proyectos en línea. También trabaja como profesional independiente en diversas empresas e instituciones, nacionales e internacionales, haciéndose cargo de proyectos relacionados con Internet, las nuevas tecnologías de la comunicación y la gestión de información.

PID_00236258
Los textos e imágenes publicados en esta obra están sujetos –excepto que se indique lo contrario– a una licencia de Reconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 España de Creative Commons. Podéis copiarlos, distribuirlos y transmitirlos públicamente siempre que citéis el autor y la fuente (FUOC. Fundación para la Universitat Oberta de Catalunya), no hagáis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es

1.Introducción

Derivado de la combinación de las dos palabras japonesas, kan, que quiere decir ‘visual’, y ban, que quiere decir ‘tarjeta’, nace la palabra kanban, con la que se denomina una metodología de producción u organización del trabajo que se basa en señales visuales para gestionar el esfuerzo y dedicación del equipo de producción.
El Kanban permite al gestor del equipo de producción multimedia identificar atascos en la producción, mejorar el tiempo de servicio de tareas y mejorar la calidad en el proceso de producción.
El Kanban requiere una alta madurez y profesionalidad en el equipo y da como resultado una importante mejora en la capacidad de producción del equipo. En este módulo, vamos a ver cómo.
Para introducir al estudiante en la gestión de procesos Kanban, hablaremos de dos ejemplos reales, donde se aplica el Kanban de una manera muy sutil para obtener mejoras en la gestión del trabajo en curso.
Ikea
En la empresa de muebles Ikea, hay una gran guardería donde poder dejar a los niños pequeños mientras los adultos compran en el centro. En esta guardería, tienen un sistema muy curioso para controlar que nunca haya más niños de los que podrían asumir los monitores: disponen de cincuenta chalecos, que van colocando a los niños a medida que sus padres los van dejando en el parque de actividades. Cuando la guardería llega al máximo de su capacidad (están colocados los cincuenta chalecos), ningún niño nuevo puede entrar al parque sin que antes se haya liberado un nuevo chaleco. De esta forma, se aseguran de que el parque de actividades y los monitores (en definitiva, su equipo de producción) nunca asumirá más trabajo de su capacidad, ni por equivocación del equipo ni por influencia externa. A medida que profundicemos en el módulo, el estudiante entenderá la similitud de los chalecos de los niños y los monitores del parque con las tareas que va a desempeñar en un proyecto multimedia y el equipo de desarrollo.
Toyota
En un caso más complejo, en la producción de automóviles de Toyota, el sistema que controla la producción está basado en unas tarjetas que circulan por la cadena de producción, donde los trabajadores están organizados de tal forma que cada uno produce su parte siempre y cuando les llegue una tarjeta que les informe de que pueden producir. Si no les llega la tarjeta, tienen prohibido producir su parte de trabajo.
Tanto los chalecos del ejemplo de la guardería como la tarjeta en la cadena de producción de Toyota, ambos son los Kanban. La palabra kanban en minúscula la utilizamos para denominar esta señal visual que sirve para indicar al equipo (los monitores de la guardería o los ingenieros de Toyota) que el sistema organizativo de la empresa puede asumir un nuevo trabajo.
En un sistema Kanban, ningún trabajador puede producir si no le llega una nueva Kanban.

1.1.Diferenciando SCRUM y Kanban

Antes de empezar a trabajar con Kanban, es interesante ver qué es lo que diferencia esta metodología del SCRUM que hemos trabajado hasta ahora. Para hacerlo nos puede ser de mucha utilidad este cuadro, donde ya encontraremos elementos que iremos desarrollando en los próximos puntos de este módulo.

SCRUM

Kanban

Recursos

Pila de producto, historias de usuario

Tablón

Rutinas

Sprints, reunión de planificación, retrospectiva del sprint

Reuniones de planificación, de seguimiento, de retrospectiva

Operaciones

Sprints

Trabajo continuado

Estimaciones

Sí

No

Equipos

Multifuncionales

Especializados

Roles

Product owner, scrum master, equipo

Equipo más roles necesarios

Trabajo en equipo

Colaborativo según tareas

Cohesionado para lograr objetivos

WIP

Controlado por sprint

Controlado por ritmos de trabajo

Cambios

Se han de esperar a nuevo sprint

Se añaden a la lista de tareas a realizar

Pila de producto

Priorización

No necesariamente

Impedimentos

Se tratan inmediatamente

Se evitan

Fuente: Scrum Framework vs Kanban Method by Venkat SR Gogugu (http://www.slideshare.net/venkatsrg/scrum-vs-kanban-28410985)

2.Kanban como sistema de gestión del trabajo en curso

El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir.
El Kanban es un sistema de gestión del trabajo en curso (WIP (1) ), que sirve principalmente para asegurar una producción continua y sin sobrecargas en el equipo de producción multimedia. El Kanban es un sistema de gestión donde se produce exactamente aquella cantidad de trabajo que el sistema es capaz de asumir. El Kanban es un sistema de trabajo just in time, lo que significa que evita sobrantes innecesarios de stock, que en la gestión de proyectos multimedia equivale a la inversión innecesaria de tiempo y esfuerzo en lo que no necesitaremos (o simplemente es menos prioritario) y evita sobrecargar al equipo.
El Kanban es una aproximación a la gestión del cambio organizativo, no es un proceso de desarrollo de productos multimedia o de gestión de proyectos. El Kanban es una aproximación a la introducción de cambios en el ciclo de vida de desarrollo de productos multimedia o metodología de gestión de proyectos ya existente. Con el Kanban, empezáis con algo en lo que estás ahora mismo en la gestión de vuestro equipo de producción. No hay que empezar de cero en la organización de una empresa para adoptar el Kanban.
En la gestión del trabajo en curso con Kanban, se busca un concepto clave como es limitar el trabajo en curso. Está demostrado que, cuanto más trabajo en curso se gestione a la vez, los índices de calidad disminuyen drásticamente. En la producción de proyectos multimedia, aumentar el trabajo en curso implica aumentar la cantidad de errores que este proyecto multimedia tendrá como consecuencia de la poca capacidad de concentración que los desarrolladores podrán dedicarle a las tareas.
Limitar el WIP implica un aumento considerable de la calidad del software generado en la producción de un proyecto multimedia.
Limitar el trabajo en curso mediante la gestión del trabajo con Kanban también tiene una consecuencia importante y es que disminuimos el tiempo de servicio de una tarea desde que entra al sistema hasta que sale. Disminuyendo la cantidad de trabajo en curso, conseguimos que el enfoque en cada una de las tareas sea mayor y que el tiempo dedicado a todas ellas, sumado, sea menor que el empleado en asumirlas todas de golpe.
Por ello, podemos decir que el Kanban, pidiendo una estricta disciplina de limitar la cantidad de trabajo que el equipo lleva a cabo a la vez, nos retorna mayores índices de calidad y un tiempo de servicio bastante menor.

3.Aplicación práctica del Kanban

Para hacer más comprensible la aplicación práctica del Kanban, en este apartado vamos a imaginar un caso típico de la producción de proyectos multimedia, donde tenemos un equipo dedicado a dar servicio de esta clase de productos. En concreto, el servicio que proporciona este equipo se basa en el desarrollo de pequeñas tareas evolutivas de un producto ya instalado en casa del cliente. Nuestro equipo trabaja para diferentes clientes, que tienen contratado un servicio de mantenimiento donde desarrolla estos pequeños plug-ins a medida que los clientes van pidiendo.
El equipo está dividido en tres programadores, uno de ellos es analista-programador (el que tiene más experiencia) y un técnico experto en sistemas, este último es el que se dedica a solucionar problemas relacionados con configuraciones de servidor, además de pasar la fase de pruebas y calidad.
Supongamos que la realidad actual de este equipo es algo caótica. Están trabajando en varias tareas previstas para el mes que viene, además, día a día apagan varios fuegos debido a errores en desarrollos anteriores y podemos decir que el tiempo dedicado a testear es más bien corto, debido a las constantes tomas para cumplir los tiempos de entrega. Las predicciones y fechas de entrega no sirven, ya que se ven rotas por tareas más urgentes que les roban tiempo.
m1402_m4_002.gif
Entráis en este equipo y os piden gestionarlo. Por suerte, conocéis el Kanban y empezáis a aplicarlo.

3.1.El primer paso

Lo primero que tenemos que hacer en este equipo es representar su realidad actual de forma visual.
La forma más habitual de aplicar el Kanban en la producción de productos multimedia es mediante el visual management, es decir, la representación visual del flujo de trabajo mediante paneles que tienen que reflejar la realidad del equipo en cada instante.

  • Tenemos que dar luz a todas las fases por las que pasan las tareas desde que entran en el sistema hasta que salen.

  • Representar visualmente las tareas que el equipo está llevando a cabo ahora mismo.

  • Aporta mucha información visual indicar qué miembro del equipo está ejecutando cada tarea.

Aseguraos de que el panel Kanban refleja las fases, las tareas y el equipo.
Un panel Kanban típico se implementaría tal como se muestra en la imagen siguiente:
m1402_m4_003.gif
En esta imagen vemos un panel constituido por tres columnas, que representan las diferentes fases por las que una tarea tiene que fluir para ser desarrollada (análisis, desarrollo y puesta en marcha). Muy importante: este gráfico es una fotografía, una imagen fija de un momento determinado de la evolución del proyecto. Cada fase está subdividida en dos estados, que son en curso y lista, para pasar a la siguiente fase; esta división está representada por la línea discontinua de cada fase. El estado en curso significa que el equipo está actualmente trabajando en esta tarea, en esta fase y el estado lista significa que el equipo ya ha acabado el trabajo que tenía que ejecutar en esta fase y la tarea está esperando a que el sistema pueda asumirla para la siguiente fase. Esta división nos ayuda a localizar atascos en el proceso de producción, lo aprenderemos más adelante en el módulo.
Las filas podrían ser diferentes proyectos en los que la empresa está trabajando, pero lo más habitual es que las filas indiquen prioridad, donde las tareas más superiores son las más prioritarias.
Separar en cada fase las tareas en el estado en curso y lista nos ayuda a localizar atascos en el proceso de producción de productos multimedia.

3.2.Un panel Kanban para gestionarlos a todos

Nuestro panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que falten o sobren. Nunca hay que adoptar un panel como solución universal.
En la gestión del trabajo en curso con Kanban, no existe un único modelo de panel adecuado para todos los equipos ni que cumpla todas las necesidades de la empresa. Un error frecuente de aquellos que empiezan a implantar Kanban en el equipo es intentar adoptar las fases de un modelo de panel externo en la realidad de la producción de su equipo. No se trata de cambiar las fases por otras, sino de estudiarlas, comprenderlas y hacerlas visibles. Cuando adoptamos Kanban, el panel tiene que ser construido y mejorado constantemente. En la gestión ágil de proyectos, una de las claves fundamentales es la iteración constante y la mejora a cada iteración. Como buenos agilistas, nuestro panel Kanban tiene que ser estudiado y juzgado en cada iteración para detectar fases que nos falten o nos sobren.
En el Kanban no existe un único modelo de panel adecuado para todos los equipos ni todas las situaciones. Simplemente representa de forma fiel la producción del equipo.

3.3.Leyendo un panel Kanban

Al acabar el primer mes como jefe de proyecto en el equipo del ejemplo presentado en la introducción de este apartado, tenemos un bonito panel Kanban en una de las paredes de la sala donde tenemos representada la realidad de nuestro equipo. El equipo lo mantiene actualizado de forma constante para que realmente represente el estado actual de los proyectos en curso.
En el panel del ejemplo, tenemos tareas que fluyen de izquierda a derecha de la siguiente manera:

  • Los dos programadores están actualmente produciendo la funcionalidad de D, E y F en simultáneo. A la vez, el experto de sistemas está testeando en la actualidad la funcionalidad M.

  • Mientras tanto, el analista-programador ha hecho el análisis y la estimación de algunas tareas nuevas que les han encomendado, esta estimación es muy importante, puesto que en ella se basa el presupuesto que la empresa hace de las tareas que el equipo lleva a cabo.

  • A medida que el tiempo va pasando, los dos programadores van desarrollando a buen ritmo, tienen acabados seis módulos y están programando otros.

  • El experto en sistemas está teniendo problemas, el módulo M no pasa algunos de los requerimientos de calidad de la empresa y solo él sabe cómo se hace, además, tiene problemas para instalar algunas tareas ya terminadas (N) en algunos clientes debido a la configuración de sus servidores.

  • Solo una tarea ha sido registrada como finalizada en este mes (la tarea O) y, por lo tanto, solo un cliente ha recibido su petición con éxito.

El panel Kanban parece que señala el problema clave del equipo: ¿por qué seguimos programando más y más funcionalidades cuando muy pocas salen del sistema? En definitiva:
Un porcentaje muy bajo del esfuerzo y tiempo del equipo se está convirtiendo finalmente en ingresos y satisfacción del cliente.

4.Limitar el trabajo en curso (WIP)

En el Kanban, hay que hacer que los trabajadores del equipo solo produzcan si el sistema acepta más cantidad de este trabajo producido.
Una vez hemos representando la realidad actual del equipo, tenemos que actuar y aplicar la primera restricción del Kanban, que es limitar el WIP. Tenemos que hacer obligatorio que los programadores dejen de programar y se dediquen a acabar de terminar aquellas tareas que están bloqueadas. Hay que lograr que los trabajadores del equipo solo produzcan si el sistema acepta más cantidad de este trabajo producido.

4.1.Limitando el WIP

¿Cómo limitamos el WIP? Ya lo hemos mencionado antes, en la gestión ágil de proyectos la clave es experimentar empíricamente e iterar para mejorar decisiones tomadas con anterioridad. Así que lo que vamos a hacer será limitar el WIP en un número no demasiado pequeño al principio.
Al inicio de la adopción del Kanban en el equipo, es importante empezar con un límite de WIP suficientemente cómodo para que no sea demasiado traumático al principio.
La mejor opción es optar por un límite alto e irlo bajando a cada dos o tres semanas hasta encontrar el equilibrio.
4.1.1.Limitando el WIP en la fase de desarrollo
En el caso del ejemplo expuesto en el apartado "Aplicación práctica del Kanban", donde los programadores están llevando a cabo tres tareas (estado en curso) y tienen finalizadas seis (estado lista), una aproximación de límite del WIP puede ser de nueve tareas. Lo que estamos diciendo con este nueve es que no programaremos nada más hasta que alguna tarea de las que están en nuestra fase no entre en la fase siguiente.
Limitaremos a nueve todo aquello que estamos programando ahora más todo lo que está pendiente de ser asumido por la siguiente fase. Es decir, basándonos en el ejemplo, hasta que los programadores acaben de programar lo que ahora tienen entre manos no les permitiremos programar ninguna tarea nueva.
Límite WIP ≤ n.º de tareas en curso + n.º de tareas hechas pendientes
En este instante, los programadores no podrán programar nada más y su prioridad debe ser conseguir que las tareas fluyan hacia la derecha: ayudarán al experto de sistemas a acabar el trabajo pendiente.
4.1.2.Limitando el WIP a la fase de análisis
Debemos tener en cuenta que limitar el WIP no se aplica solo a la fase de desarrollo, sino que también las fases previas de definición y análisis de tareas deben tener un cierto límite WIP. En nuestro equipo ejemplo, nosotros, como jefes de proyecto, tendremos que limitar el WIP del analista-programador a un número más bien bajo (por ejemplo dos). Esta decisión nos dará como resultado dos consecuencias deseables:
Limitar el WIP a la fase de análisis
Limitar bajo el WIP de la fase más temprana en la producción de proyectos multimedia nos ayuda a blindarnos contra los habituales cambios de prioridad de última hora.
Si al departamento comercial de la empresa le decimos que solo se pueden estimar X desarrollos y que en ningún caso nos saltaremos esta norma, se lo pensarán más de una vez cuando prioricen una tarea. Y estaremos seguros de que lo que estamos haciendo es siempre lo más prioritario.
1) La primera y más obvia será que, como hemos estado diciendo, aumentará la calidad y el tiempo de entrega de las estimaciones y análisis del analista. Cuanto menos tareas esté estimando a la vez, más esmeradas serán.
2) La segunda es que los miembros de la empresa que actúan previamente al analista irán con más cuidado a la hora de priorizar el trabajo en el equipo.
En una organización de producción multimedia habitual, la persona que envía el trabajo al equipo de desarrollo no suele ser miembro de este equipo de desarrollo y suele enviar trabajo de forma continua, en paralelo, de forma más bien desorganizada y repriorizando constantemente. Las consecuencias negativas de esta falta de organización donde se trabaja con metodologías ASM (a salto de mata) son muy conocidas por todo el mundo (tareas hechas a medias debido al cambio constante de prioridades, bajos índices de calidad debidos a las prisas de última hora). Si limitamos el WIP al analista-programador, lo que conseguimos es decirle a esta persona que ahora mismo no aceptaremos ninguna petición de nueve análisis y le aseguramos que en el momento en el que haya un nuevo espacio en el Kanban en la fase de análisis se le informará. La primera reacción será de rechazo, pero estaremos seguros de que, cuando le avisemos de que el equipo está en condiciones de asumir una nueva tarea, esta persona incluirá la más importante (puesto que, en caso contrario, tendrá que volver a esperar) y poco a poco conseguiremos que las prioridades estén siempre muy definidas y estaremos seguros de que lo que entra en el equipo de producción es siempre lo más importante.
Un ejemplo representativo
En una importante empresa de software para la Administración pública donde el autor de este módulo trabajó, el equipo de desarrollo servía peticiones procedentes de seis personas distintas, directivos pertenecientes a áreas diferentes (área de contabilidad, área de expedientes electrónicos, área de documentación, área de tramitación, área de sistemas de gestión del territorio y área de ciudadanía) y el día a día de este equipo era de cambios de prioridades constantes: cuando el director A pedía algo, siempre era más urgente que lo de cualquier otro.
Durante un cierto tiempo, se optó por designar a una única persona que centralizaba las peticiones, pero como carecía de capacidad jerárquica y de decisión, no se convirtió en más que un mensajero y cada vez venía con unas prioridades diferentes.
La solución definitiva fue que el jefe de este equipo decidiera que solo se aceptarían cinco tareas en pendiente y solo cuando hubiera un espacio libre en el Kanban se podría asumir una tarea nueva y les informaríamos por e-mail. El efecto fue inmediato: los seis tenían reuniones diarias donde se priorizaban entre ellos la tarea más importante. Conseguimos orden en la ejecución de las tareas y comunicación entre los directivos de las diferentes áreas.

4.2.Multitarea y tiempo de switch

En las autopistas, a medida que aumenta la densidad de tráfico, la velocidad del tráfico disminuye. A priori, esta disminución de velocidad no tendría que ocurrir porque, si todos los coches fueran a la misma velocidad, no habría motivo para que el tráfico fuera lento o incluso se detuviera. El problema viene cuando los coches cambian de carril. Un cambio de carril hace que el coche que cambia reduzca la velocidad, por lo tanto, el de detrás también y esto se propaga hasta reducir considerablemente la velocidad de todo el flujo de coches completo. Esta es una buena analogía de cómo la multitarea afecta en negativo al tiempo de servicio en el Kanban.
Una gran densidad de tareas en desarrollo en el flujo del Kanban hace que la velocidad de servicio decrezca considerablemente.
Cuando se cambia de contexto entre una tarea y otra se consume un cierto tiempo, por lo tanto cuantas menos veces tengamos que cambiar de contexto, menos tiempo se perderá. Gerald Weinberg, en el libro Quality Software Management: Systems Thinking, sugiere que se pierde un 20% del tiempo por cada tarea adicional que asumimos a la vez.
Por lo tanto, podemos decir que una tarea en desarrollo consume el 100% del tiempo disponible, dos tareas consumirán el 40% de tiempo cada una (habiendo perdido el 20% de tiempo en el cambio de contexto) y tres tareas a la vez consumirán cada una el 20% del tiempo disponible en ser desarrolladas y el tiempo perdido al cambiar de contexto será del 40%.
m1402_m4_004.gif
A medida que tenemos más tareas a la vez, más tiempo se pierde al cambiar de contexto.
Además, desarrollar las tareas de forma secuencial y no en paralelo tiene como consecuencia obtener resultados antes. El diagrama siguiente muestra que desarrollar A, B y C en multitarea tiene como resultado que A se entrega mucho más tarde, incluso C se entrega más tarde aunque se empezó antes. Debajo, el resultado de desarrollar las tareas secuencialmente:
m1402_m4_005.gif

5.Los cuellos de botella

Una vez que la fase de desarrollo ha llegado al límite WIP, hemos llegado a tener un cuello de botella: la fase de puesta en marcha provoca un atasco.
m1402_m4_006.gif
Este gráfico es una fotografía, una imagen fija de un momento determinado de la evolución del proyecto. En ese momento, se pueden tomar tres decisiones diferentes:
1) La peor. Aumentar o sacar el límite WIP. Sabemos la teoría y sabemos que el Kanban limita el WIP, pero como no podemos, y es imposible, decidimos sacarlo y ponemos un límite WIP de 10, para más adelante subirlo a 15. Y realmente no ayuda en nada a la empresa y al equipo.
2) La mala. Contratar a gente para la fase en el cuello de botella. La solución en un equipo sobrecargado no siempre es poner más gente. Se debe tener en cuenta que incorporar personal nuevo necesita tiempo de dedicación, hay un periodo en el que se tiene que invertir tiempo en formar al personal nuevo (nunca nadie entra sabiéndolo todo, por muy experto que sea quien se contrata) y este tiempo lo estaréis robando de las personas que se encuentran justamente en la fase de la que depende el tiempo de servicio del equipo (en el ejemplo del apartado "Aplicación práctica del Kanban", el experto en servidores).
3) La buena. Poner a uno de los programadores a ayudar en la fase de puesta en marcha. Un buen equipo de alto rendimiento es aquel que está formado por personas expertas en alguna tarea, pero que conoce y se interesa por todas las que le rodean. Se le denomina trabajador T.
En el momento en el que al programador se le dice "deja de programar y ponte a testear" una respuesta muy habitual es "mi trabajo es programar, a mí me pagan por programar y programar es lo que voy a hacer". En ese momento, hay que tener muy claro que el objetivo de todo el equipo tiene que ser el servicio al cliente (es decir, facturar). Un trabajador que no está dispuesto a asimilar que el trabajo de programar no es lo que el sistema de producción necesita en ese momento (donde el panel Kanban refleja que tenemos nueve tareas programadas y solo una facturada), no le está haciendo un buen favor a la empresa.

6.Optimizando el equipo

Como hemos ido diciendo a lo largo del módulo, el Kanban es un espejo que refleja la realidad del trabajo que el equipo está desarrollando, refleja los flujos por donde pasan las tareas y el equipo en sí mismo. El Kanban nos hará aflorar ineficiencias en la gestión de los proyectos multimedia, pero también ineficiencias en el equipo.
Los equipos que trabajan en proyectos multimedia son multidisciplinares. El cambio constante es una de las características del sector y mercado multimedia. Esto también se refleja en la aparición de nuevos perfiles profesionales y en la adaptación de algunos existentes a las nuevas tendencias.
Existen en la red varios documentos que ofrecen información sobre nuevas profesiones surgidas en torno a la informática y las telecomunicaciones. Uno de los que creemos más interesantes es este disponible en este enlace: http://www.educastur.princast.es/fp/hola/ocupaciones/sectores.php?id=2
Algunos de los nuevos perfiles profesionales más interesantes que se detallan son los siguientes:

  • Programador/a de teléfonos móviles

  • Técnico/a en comunicaciones móviles

  • Jefe/a de proyecto de redes privadas

  • Técnico/a en redes privadas

  • Ingeniero/a de contenidos on-line

  • Webgardener

  • Ingeniero/a de e-learning

  • Especialista en la protección de datos personales

  • Ethical Hacker

  • Diseñador/a de publicidad on-line

  • Diseñador a de tiendas virtuales

  • Webmetrista

  • Experto/a en agentes inteligentes

  • Ingeniero/a para el acceso univers

  • Webmaster

  • Proyectista y controlador /a de redes

  • Experto/a en telemática de servicios de valor añadido

  • Animador/a 3D

  • Helpdesk

  • Experto/a en usabilidad

  • Animador/a de foros o gestor/a de comunidades virtuales

  • Gestor/a de contenidos on-line

  • Sector experto/a en política de la competencia en las TIC

  • Consultor/a en gestión del conocimiento

En este contexto puede ser de gran utilidad la existencia de trabajadores T en un equipo.

6.1.El trabajador T

Las personas T (2) tienen dos características fundamentales y se usa la letra T para explicarlas:
1) La parte vertical de la T es una habilidad concreta y trabajada, que les permite contribuir en el equipo como expertos en esta característica (diseñador web, programador PHP, servidores APACHE, entre otros).
2) La parte horizontal de la T representa la disposición a colaborar a través de otras disciplinas.
La personalidad de un miembro del equipo de tipoT tiene dos aspectos principales:
1) Dispone de una alta empatía por las demás personas, que le ayuda a ver los problemas desde otros ojos, imaginar el problema desde otras perspectivas y poder contribuir con su opinión en áreas en las que a priori no es experto. Por ejemplo, el diseñador web es experto en diseñar, pero puede contribuir a imaginarse cómo poder hacer la tarea más sencilla al programador y el programador es experto en su trabajo, pero tiene que poder ver el proyecto con los ojos del testeador y detectar posibles problemas de arquitectura antes de que los encuentre su compañero.
2) Además, tienen que ser personas muy entusiastas y sentir curiosidad por las disciplinas de los demás, lo que les impulsa a interesarse e incluso a aprender y practicarlas.
Las personas de tipo T tienen ambas características: profundidad en una disciplina e interés por todas las que le rodean. Aseguraos siempre de formar todo el equipo de personas T.

6.2.Los beneficios de desarrollar en parejas

Una práctica muy extendida y probablemente la más conocida de desarrollo ágil de productos multimedia es el pair programming (programación por parejas). Esta práctica es muy recomendada en equipos que aplican el Kanban, puesto que ayuda a hacer posible este movimiento temporal de personas entre fases para desatascar el flujo de tareas.
Se conoce el pair programming por ayudar a construir un mejor software: dos jefes son mejor que uno y dos jefes producen habitualmente un software de mejor calidad.
Practicar el pair programming (sobre todo de forma rotativa) expande la esfera de conocimiento de todos los desarrolladores de un equipo. Este conocimiento, propagándose y expandiéndose, ayuda a los programadores a localizar el código repetido por todo el producto multimedia que se está desarrollando y, de una manera continua en toda la ejecución del proyecto, los programadores pueden ayudarse mutuamente y diseñar un mejor sistema.
En una oficina llena de gente, es habitual que haya ruidos y distracciones. El pair programming ayuda a evitar estas distracciones: cuando dos personas trabajan juntas en una tarea, se suelen distraer mucho menos que una sola. En empresas que practican el pair programming, es habitual encontrar a dos programadores tan absortos por una tarea que se abstraen perfectamente del resto de la oficina.
Practicando el pair programming surgen conversaciones sobre la tarea que se está ejecutando y se abren debates que siempre son beneficiosos para que afloren problemas que a una persona sola se le podrían escapar.
Las nuevas incorporaciones al equipo se vuelven productivas mucho más rápido que trabajando solas. En equipos de desarrollo, es habitual encontrar a una persona que trabaja sola y es complicado integrarla en el equipo. El pair programming socializa a estas personas y saca lo mejor de ellas mismas.
La revisión y el testeo de la programación tiene lugar de forma continua durante el desarrollo de todo el proyecto. Teniendo a una persona al lado, el programador comete menos errores y pasa por alto muchas menos deficiencias técnicas.
Trabajar en pareja es motivador, tendréis al equipo mucho más contento y animado. Evitaréis oír aquello de “cuando programé esto tenía un mal día", puesto que el trabajo del programador no dependerá solo de él.
Lograréis que las personas de vuestro equipo se conviertan en personas de tipo T.
Como jefe de proyecto, conseguiréis no tener a una única persona que sepa sobre algún tema desarrollado. No tendréis que temer que tal persona se vaya de vacaciones o se ponga enferma. Reduciréis el bus factor.
El pair programming es una buena forma de conseguir esta unión en el equipo y la cultura y motivación necesarias para implementar el Kanban correctamente. Es una buena forma de implantar una cultura Kaizen.

6.3.El bus factor

Imaginad que estáis a medio camino de acabar un proyecto multimedia y aquella mañana vuestro equipo decide, como buen equipo Kanban que es, comer todos juntos. Tras comer, cruzan todos juntos por el paso de peatones cuando, de repente, un autobús alocado los atropella a todos. ¿Cuántas personas tienen que resultar gravemente heridas para que vuestro proyecto se tenga que cancelar?
Si respondiendo a la pregunta anterior habéis afirmado que una persona, actuad rápido y cambiadlo.
Como jefe de proyecto multimedia no debéis permitir que el éxito de un proyecto pueda depender de una persona. ¿Qué pasa si se pone enferma? ¿Y si se va de vacaciones o si le toca la lotería? ¿O si cambia de trabajo?
Procurad siempre mantener el bus factor muy elevado. En un equipo de cinco personas, es recomendable a partir de tres y, en un equipo de diez, como mínimo cuatro.

6.4.Kaizen: una cultura de mejora continua

La palabra japonesa kaizen significa literalmente mejora en el cambio.
La cultura en un puesto de trabajo donde la fuerza del trabajo está enfocada en la mejora de la calidad, la productividad y la satisfacción del cliente de forma continua durante todo el proceso de producción (no solo al principio o al final) se conoce como una cultura Kaizen.
Muy pocas empresas han llegado a este punto de cultura y la mayoría son de origen oriental.
Un ejemplo clásico de empresa con una fuerte cultura Kaizen es Toyota, donde la participación de los trabajadores en su dinámica de cultura corporativa es casi del 100%, donde tienen de promedio que cada empleado plantea como mínimo una propuesta de mejora al año.
En una cultura Kaizen, los individuos se sienten libres para emprender acciones y tomar decisiones, son siempre libres de hacer lo correcto por voluntad propia.
Espontáneamente, se forman grupos de discusión sobre problemas reales, tratan opciones e implementan soluciones y mejoras, entre todos deciden acciones concretas de mejora para la empresa. Los individuos tienen libertad de autoorganizarse (dentro de ciertos límites) en torno al trabajo que desarrollan y las tareas de desarrollo son autoasignadas por los trabajadores de forma voluntaria sin que haya ningún superior que las asigne. En esta cultura de empresa, la fuerza de trabajo no tiene miedo a tomar acciones voluntarias.
La norma subyacente es que la dirección sea tolerante a quiebras en experimentaciones e innovaciones si de esta acción se obtiene progreso y mejoras de rendimiento. Es una cultura de alta confianza, donde los trabajadores, sin importar su jerarquía, son los que tienen cuidado de la calidad y mejora de la producción y se involucran en un nivel de colaboración y una atmósfera donde todos cuidan del rendimiento del equipo y el equipo cuida del rendimiento propio.
Las estructuras organizativas de empresas con una cultura Kaizen, al contrario de las organizaciones en empresas de baja confianza, suelen ser muy planas, eliminan capas intermedias de dirección y control innecesarias y tienen como resultado una reducción importante de coste en coordinación.
Resulta bastante evidente que esta cultura de trabajo sea importada de culturas orientales, ya que en las occidentales nos enseñan desde pequeños a ser competitivos y a destacar de forma individual por encima de los demás, sobresaliendo en forma de héroes insustituibles alrededor de los cuales gira todo el resto. Cuanto más lejos nos encontremos de este modelo, mejor Kanban implementaremos.

7.Optimizando el flujo

Los tres pilares básicos del Kanban son los siguientes:
1) visualizar de forma continua el estado del equipo de producción,
2) limitar el WIP para mejorar la calidad y el tiempo de entrega, y
3) potenciar el flujo.
Como jefes de proyectos multimedia en un equipo Kanban, nuestro trabajo es conseguir que las tareas fluyan por el panel cuanto más rápido mejor. Tenemos que minimizar el tiempo que una tarea se queda en una fase.

7.1.Dividiendo fases para conseguir flujo

En nuestro equipo ejemplo del apartado "Aplicación práctica del Kanban", hemos tratado el caso en el que la fase de puesta en marcha se ha transformado en un cuello de botella; para hacerle frente hemos prohibido que ningún trabajo nuevo sea asumido por la fase de desarrollo y hemos puesto a los dos programadores a ayudar al experto en sistemas, así que podemos suponer que hemos conseguido desatascar el cuello de botella de la última fase. ¿Qué opciones de mejora podemos implementar ahora?
Muy probablemente, en este momento los programadores del equipo tengan unos conocimientos mínimos sobre las fases de calidad que tiene que pasar el experto de sistemas, quizás han aprendido algo sobre pruebas de rendimiento o cualquier tarea mecánica y sencilla que liberaría mucho trabajo al experto de sistemas.
Podemos dividir la fase de puesta en marcha en dos, podemos hacer aparecer la fase de revisión de calidad donde, por cada tarea desarrollada, uno de los programadores pasará aquellas pruebas de calidad que han aprendido del experto de sistemas.
Ahora, el experto se puede dedicar a aquellas tareas de especialista que solo él sabe hacer tan bien y las tareas pueden ser servidas al cliente con más rapidez.
Además, hemos podido disminuir el límite WIP de desarrollo de nueve a cinco, ¡casi la mitad! Ahora las fases están más claras, ninguna tarea será finalizada sin pasar esta revisión de calidad (llevada a cabo por los mismos programadores). Hemos ganado flujo en el panel.
Las acumulaciones de tareas en una fase son muy mala señal. Localizad qué tareas permanecen mucho tiempo en una fase, entended el porqué de esta acumulación y actuad en consecuencia.
7.1.1.Dividiendo fases para conseguir espacios
En apartados anteriores, hemos explicado los beneficios de cara a la organización de la empresa si limitamos el WIP de la entrada a producción (fase de análisis). Y hemos explicado que, a medida que las tareas se vayan sirviendo de izquierda a derecha, iremos obteniendo espacios libres y lo comunicaremos a los comerciales interesados en que un nuevo trabajo pueda ser asumido por el sistema.
Actitud agilizadora
Como agente catalizador del agilismo en vuestra empresa, debéis estar siempre abiertos a posibles mejoras y modificaciones del proceso de producción de proyectos multimedia.
Y nunca os limitéis a la gestión de solo el equipo de producción.
Incluid en el Kanban todas las fases que os afecten directa o indirectamente.
Si en esta primera fase detectamos una posible división (definición-análisis), podemos ganar flujo si adoptamos una fase nueva en el Kanban y solicitamos a la empresa esta nueva figura de analista funcional, aquella persona que puede definir qué tienen que hacer las tareas que se van a desarrollar.

7.2.Métricas en el Kanban

En este punto de madurez del Kanban en nuestro equipo de producción multimedia, podemos empezar a obtener datos estadísticos del equipo.
Una muy buena opción es anotar las fechas de entrada y salida de la tarea por cada fase. Así podréis ir obteniendo toda una serie de gráficos del tiempo que tardan las tareas en ser servidas y qué fases son las que más tiempo exigen.
Un simple gráfico acumulativo nos dará mucha información en un solo vistazo: ¿cuántas tareas pendientes hay a día de hoy? ¿Cuántas hay aproximadamente en producción? ¿Cuál tiene una pendiente más pronunciada? Si crecen más las tareas pendientes que las servidas al cliente tenemos un problema.
Toda esta información se puede extraer de multitud de gráficos usando todo tipo de herramientas para la gestión de proyectos.
m1402_m4_010.gif

8.Scrumban

Si recuperamos el cuadro del punto 1.1, más todo lo que hemos trabajado hasta ahora, podemos avanzar en el Scrumban.
La metodología Scrumban nace de la combinación de principios de los métodos ágiles de gestión de proyectos más importantes en la actualidad: Scrum y Kanban.
Aunque en principio pueden parecer iguales, las dos estrategias de gestión presentan diferencias en la manera de ejecutar el proyecto. Por esta razón el nuevo plan Scrumban encarga de combinar aquellos elementos que resultan complementarios.
Por ejemplo, una de las combinaciones más usadas en el ámbito empresarial es la de gestionar las tareas previstas con el método Scrum y planificar los errores con el método Kanban.
Sin embargo, la mezcla de una y otra implica una nueva forma de gestión.
El flujo de trabajo sigue siendo el mismo de Kanban (etapas relacionadas entre sí), aunque con la inclusión de algunos elementos de Scrum, como las reuniones diarias de quince minutos entre el grupo de trabajo y el gestor o los análisis retrospectivos para incorporar mejoras al proceso.
Por ello, hay ciertos proyectos que se adecuan mejor al método mixto. En general, se trata de aquellos con un mayor nivel de complejidad. Algunos ejemplos son:

  • Proyectos de mantenimiento: aquellos en los que resulta indispensable la presentación de resultados de forma parcial para seguir avanzando.

  • Proyectos en los que los requisitos varíen con frecuencia: aquellos en los que el cliente no tiene fijadas las condiciones y expectativas del proyecto y estas se van introduciendo a lo largo de las diferentes etapas.

  • Proyectos en los que surjan errores de ejecución: aquellos en los que haya que replantear el método usado y analizar retrospectivamente la evolución de las tareas.

En cuanto al plan de etapas, mapa o interfaz de la aplicación, ya no se limita a nombrar las tareas con los rótulos «sin empezar», «en progreso» o «finalizadas» de Kanban, sino que, tras la revisión de Scrum, añade otras categorías, tales como «probadas» o «entregadas».
Se consideran beneficios de la metodología Scrumban los siguientes:

  • Permite conocer en estado real el proceso de ejecución del proyecto.

  • Introduce soluciones oportunas ante eventuales errores.

  • Permite un mayor análisis de tareas realizadas.

  • Mejora la interacción entre los miembros de un grupo en las reuniones periódicas.

  • Aumenta la productividad de proyectos complejos o multiproyectos.

  • Favorece una mayor adaptabilidad de las herramientas a las exigencias del proyecto.

Bibliografía

agilescout: http://agilescout.com
Anderson, David J.; Reinertsen, Donald G. (2010). Kanban: Successful Evolutionary Change for Your Technology Business. Disponible en: http://www.amazon.com/kanban-successful-evolutionary-technology-business/dp/0984521402.
limitedwipsociety: http://limitedwipsociety.ning.com
Weinberb, Gerald M. (1991). Quality Software Management: Systems Thinking. Dorset House.
Martin, Robert C. (2012). Agile software development: principles, patterns, and practices. Upper Saddle River, N.J.: Pearson Prentice Hall.
Ruby, Sam (2009). Agile web development with rails. Raleigh, NC: Pragmatic Bookshelf.
Shore, James (2008). The Art of agile development. Beijing ; Sebastopol, CA: O'Reilly Media, Inc.
Anderson, David James (2004). Agile management for software engineering: applying the theory of constraints for business results. Upper Saddle River, NJ: Prentice Hall PTR, cop. 2004.
Highsmith, James A. (2004). Agile project management: creating innovative products. Addison-Wesley, cop. 2004.
Schwaber, Ken (2004). Agile project management with Scrum. Redmond, Wash.: Microsoft Press.
Schwaber, Ken (2002). Agile software development with Scrum. Upper Seadle River, NJ: Pearson Prentice Hall.