VERSUS: Tablero Virtual VS Tablero Físico

En Paradigma tenemos diversos equipos aplicando Agile de diferentes maneras: Scrum, Kanban u otros frameworks que también funcionan. De la misma manera, a la hora de controlar y hacer seguimiento del proyecto hemos descubierto que cada equipo ha ido buscando la herramienta más cómoda, ya sea para controlar el Sprint Backlog, el Tablero Kanban o bien otros aspectos del proyecto.

También hay equipos muy fans de herramientas digitales, entre las más famosas encontramos Trello, Jira o Taiga. La otra alternativa que gusta mucho en la comunidad Agile es la implantación de Visual Management y llevar dicho control a tableros físicos.

En este Versus enfrentamos a Javier Martín de Agar, defensor de los paneles físicos y a Manuel Zaforas, que ve mayor utilidad y comodidad en los paneles virtuales. ¿Con cuál te quedas?

Tablero Virtual

Manuel Zaforas

Un tablero virtual es el reflejo de un tablero físico en el mundo virtual. Pueden servir para gestionar las tareas en Scrum o Kanban de la misma manera que un tablero físico, pero además nos aportan una serie de ventajas adicionales.

Para construir un tablero virtual usaremos aplicaciones específicas, generalmente ubicadas en la nube, como JIRA, Trello, Redmine, Taiga o Trac. Esto facilita el teletrabajo o los equipos disgregados en diferentes ubicaciones físicas, simplificando de esta forma la accesibilidad y fomentando la colaboración.

Si es necesario tener una visión física siempre podemos usar pantallas o monitores donde mostrar los dashboards que nos ofrecen estas aplicaciones o incluso acceder a las APIs que nos ofrecen para crear vistas personalizadas. En Paradigma varios equipos trabajan de esta forma.

Javi, no puedes negar que los tableros virtuales también tienen la ventaja de que fomentan la colaboración e interacción entre los miembros de un equipo, ya que la información y el estado puede ser actualizado de forma simultánea desde cualquier dispositivo.

Por otro lado estas herramientas nos proveen de características muy potentes como filtros o sistemas de búsqueda que nos ayudan a mantener la información mejor estructurada y ordenada y a localizar antes lo que necesitamos, siendo más eficientes.

Además, toda la actividad y cambios en el panel quedan registrados, esto es fundamental para entender a posteriori las decisiones que se fueron tomando y volver atrás si se comete algún error. También podemos guardar el estado o realizar un backup para no perder nada de información, algo que Javi, como bien sabes en un tablón físico es imposible, y en caso de accidente podríamos perder toda la información, lo que sería desastroso.

Los tableros virtuales nos ofrecen la posibilidad de tener una visión global de un vistazo, gracias a las métricas y gráficas automáticas que incorporan, de esta forma es muy sencillo conocer el estado del proyecto. Intentar obtener esta información a partir de un tablero físico supone una enorme cantidad de trabajo.

Hoy en día la integración es clave, las herramientas que soportan los tableros virtuales pueden integrarse con otras herramientas habituales en los equipos de desarrollo como GitHub, Jenkins o Slack. Esto facilita y agiliza el trabajo de los desarrolladores.

Por último no hay que olvidar que los tableros virtuales son más ecológicos, lo que también es importante hoy en día, ya que no hacen ningún gasto de papel ni materiales fungibles en contra de los físicos que suponen un gasto continuo en este sentido.

Tablero Físico

Javier Martín de Agar

Una de las mayores virtudes de un tablero físico es que permite la total autoorganización. El equipo se crea un panel con todas las tareas que tienen que realizar para la próxima iteración y se organizan como ellos mismos consideren. Una vez han arrancado, los miembros pueden analizar si lo están haciendo bien, el ritmo de trabajo y, sobre todo, cuánto les queda para terminar una tarea.

Manu, los seres humanos somos muy visuales, el disponer de una herramienta física es ideal porque podemos adaptarla a nuestras necesidades reales de un proyecto concreto. Cuando usamos herramientas software al final acabamos adaptando nuestro proyecto al software en vez de que la herramienta se adapte a nuestras necesidades.

Es parte de la filosofía de Agile, ser simple ante todo. Un software suele ser o demasiado simple como para ser útil, o tratar de cubrir tantas casuísticas que acaba siendo demasiado complejo.

Pero hay muchas más virtudes, Manu, aunque a ti te cueste verlas. Una de las ventajas que tenemos es que es una herramienta que se construye con el equipo. Esto permite un día más distendido donde la imaginación impera, donde podemos decidir cómo queremos que sea nuestro tablero, es una sesión colaborativa y permite la cohesión de los miembros del equipo.

También un tablero es nuestro lugar para hacer la Daily Scrum, de manera que podamos coordinarnos todos juntos con nuestro plan. Esto nos da la ventaja de poder tener una foto real de todo el trabajo pendiente y nos ayuda a tomar mejores decisiones. Generalmente en cualquier aplicación tenemos que estar usando el “scroll” para localizar tareas, lo que dificulta mucho el diálogo.

Muchas personas critican que el uso de tableros físicos no nos permite mantener un histórico de lo que hemos hecho. Recordemos que en Scrum y en Kanban ponemos el foco en el trabajo pendiente por hacer y no en el realizado. Realmente nadie utiliza el histórico de las tareas salvo para un motivo: poder “defenderse” ante una situación difícil con el cliente. El problema es que, cuando un equipo necesita hacer eso, realmente es un signo de que no hay confianza para poder hacer Agile y, por tanto, el tablero será el menor de nuestros problemas.

Incluso un tablero físico se puede utilizar con personas que están teletrabajando, ya que cualquier compañero puede comunicar perfectamente qué tareas irá abordando aunque no esté presente y puede solicitar por teléfono que se actualicen sus tareas.

Un argumento más a favor del tablero físico  es que, si alguien está de vacaciones, desconectará totalmente del proyecto al no tener un sitio al que mirar el estado actual.

Y tú, ¿cuál prefieres?

Manuel Zaforas es Ingeniero Superior en Informática por la UPM. Está interesado en HPC, IoT, Cloud, NoSQL, Big Data, Data Science, Machine Learning y Agile. Apoya activamente la implantación de software libre, la calidad en los procesos de desarrollo de software a través de la mejora continua y la innovación en las metodologías de desarrollo y gestión de equipos. Actualmente trabaja en Paradigma como Scrum Master y Arquitecto Software.

Ver toda la actividad de Manuel Zaforas

Soy un apasionado del mundo Agile. Actualmente participo con los diferentes equipos de Paradigma para ayudarlos a aplicar correctamente estas innovadoras técnicas. Además, colaboro con los clientes que lo soliciten para introducirles en el mundo del Scrum, Kanban o XP. Mi objetivo es mejorar la satisfacción de todas las personas que participan en un proyecto.

Ver toda la actividad de Javier Martín de Agar

Recibe más artículos como este

Recibirás un email por cada nuevo artículo.. Acepto los términos legales

Posts relacionados

2 comentarios

  1. José Ignacio Herranz Roldán dice:

    El punto que tiene un tablero físico que puedes tocar y sentir no lo tiene uno virtual, eso no lo podemos negar. Pero sopesando todos los pros y contras yo me quedo con el virtual.

    • Interesante artículo. Yo lo veo similar a José Ignacio Herranz Roldán sin embargo tengo algunos matices.

      Realmente son herramientas con propósitos distintos con conceptos mezclados. El tablero físico está más orientado a la colaboración y comunicación del día a día y alineamiento del equipo contra los objetivos. El poder tocar las tareas favorece la comunicación, ya que las tareas son objetos intangibles que en el momento que se pueden tocar y enseñar hace que la comunicación sea más efectiva. Lamentablemente esto no se consigue del todo con un tablero virtual, aunque en el futuro no te digo que no mediante la interacción con la pantalla esto pueda ocurrir con la misma efectividad.

      Por otro lado el tablero virtual, por ejemplo el que te ofrece JIRA sirve para tener en un sitio centralizado el avance del proyecto y del día a día. Es más una herramienta de reporting que una herramienta de comunicación, aunque como ahora más adelante explicaré hay casos y casos. JIRA no sólo es un tablero si no que te sirve para trazar tus épicas a historias de usuario, a tareas y permite ver un histórico y generar reportes. Si además lo combinamos con entrega continua y despliegue automático usando Bitbucket server (Stash) que es un sistema de control de versiones de Atlassian, Bamboo que es un equivalente a Jenkins de Atlassian, sonarqube, etc… podemos tener una trazabilidad de todo nuestro proyecto con mínimo esfuerzo, desde nuestras historias de usuario hasta cada cambio, cada build y cada puesta en producción (despliegues de bamboo). Pero esto no deja de ser reporting, trazabilidad, centralización de la información, etc.

      Pero como he dicho anteriormente hay casos y casos. Si lo que tienes es equipos deslocalizados por ejemplo, no puedes utilizar una pizarra física, y aquí es esencial el uso de herramientas como JIRA, Redmine o TFS. En estos casos, una herramienta de reporting, gestión e interacción, es esencial para tratar de mejorar la comunicación y el alineamiento de personas y equipos. No es tan efectivo como el face to face de las pizarras convencionales, pero es lo mejor que tenemos.

      De esta manera si combinas JIRA, Confluence (la wiki de Atlassian) y Hiptchat (o simplemente Skype), puedes conseguir que el equipo se coordine, y que la comunicación fluya correctamente, siendo esencial el uso de pizarras virtuales.

      Hay gente que piensa que se realiza doble trabajo en el mantenimiento de la pizarra convencional, depende del enfoque, recordad que si utilizáis ambas cosas, la información importante actualizada al día debería ser la de JIRA, es una cuestión de disciplina, de orden y centralización de la información. En este caso la pizarra física es una herramienta de comunicación face-to-face para los equipos localizados en un mismo área física.

      Normalmente se suelen combinar ambas tecnologías, teniendo acceso a JIRA durante las dailies para revisar información que se necesita en el momento y actualizando la pizarra en el momento (por eso es conveniente tener post-its y rotuladores cerca.

      He de reconocer que tiene un punto de duplicación tratar de mantener ambas pizarras al día, sobre todo si se trata de mantener las dos exactamente iguales, por eso lo mejor es no centrarse en que la pizarra física esté actualizada al 100% sino que muestre la información que se está hablando en ese momento y que cumpla su función para las dailies (podría ser incluso una representación distinta de la información, la que sea útil y de valor para el equipo). Esta pequeña duplicación merece la pena por los beneficios que proporciona al face to face. También se recomienda tener una pizarra cerca on rotuladores para expresar ideas, por el mismo motivo.

      En definitiva, ambos tenéis razón y quizá en el futuro la tecnología sea tan buena o más que el face to face y no sean necesarias las pizarras físicas.

Escribe un comentario