--- url: 'https://metadrop.net/es/quienes-somos/metodologia/tablero-kanban-agil' title: 'Tablero Agile Kanban | Nuestra Metodología de Proyecto' author: name: Root url: 'https://metadrop.net/es/sobre/metadrop' date: '2019-05-26T11:49:04+00:00' updated: '2026-06-29T09:39:58+00:00' type: article summary: 'Mira cómo Metadrop gestiona proyectos de Drupal en un tablero Kanban: columnas, límites WIP, puerta de QA y bucle KO para una entrega predecible. Descubre cómo.' image: 'https://metadrop.net/sites/default/files/styles/full/public/2026-06/agile-kanban-board.webp?itok=YzQW-4TP' published: true og: determiner: Automatic site_name: Metadrop street_address: 'Calle Manuel Luna, 12, 3 Dcha' locality: Madrid region: Madrid postal_code: '28020' country_name: España email: hola@metadrop.net phone_number: '910053180' schema: '@context': 'https://schema.org' '@graph': - '@type': Organization '@id': 'https://metadrop.net/#organization' url: 'https://metadrop.net/' name: Metadrop sameAs: - 'https://www.drupal.org/metadrop' - 'https://twitter.com/metadrop' - 'https://asociaciondrupal.es/partner/metadrop' - 'https://www.linkedin.com/company/metadrop' logo: '@type': ImageObject url: 'https://metadrop.net/themes/custom/mdrop_radix/logo-metadrop-500-500.jpg' width: '500' height: '500' - '@type': ItemPage '@id': 'https://metadrop.net/es/quienes-somos/metodologia/tablero-kanban-agil' breadcrumb: '@type': BreadcrumbList itemListElement: - '@type': ListItem position: 1 name: Inicio item: 'https://metadrop.net/es' - '@type': ListItem position: 2 name: 'Quiénes somos' item: 'https://metadrop.net/es/quienes-somos' - '@type': ListItem position: 3 name: 'Metodología de trabajo en Metadrop' item: 'https://metadrop.net/es/quienes-somos/metodologia' publisher: '@type': Organization '@id': 'https://metadrop.net/#organization' --- 1. [Quiénes somos](https://metadrop.net/es/quienes-somos) 2. [Metodología de trabajo en Metadrop](https://metadrop.net/es/quienes-somos/metodologia) # Agile - Tablero Kanban El tablero Kanban de Metadrop define estados de tarea, límites de trabajo en curso (WIP) y un control de calidad (QA) en cada ciclo de entrega de proyectos Drupal para obtener resultados predecibles y transparentes. [Habla con el equipo](https://metadrop.net/es/contacto)[Explorar](#scroll-to-content) Metadrop ejecuta cada proyecto de Drupal en un *tablero Kanban Agile*, un flujo de trabajo visual que mueve cada tarea a través de estados definidos con límites estrictos de trabajo en curso y un control de calidad. Los líderes digitales y de TI obtienen una entrega predecible y transparente, en lugar de un desarrollo opaco. ## Qué es un tablero Kanban y por qué lo usamos Un *tablero Kanban* es un **flujo de trabajo visual** que muestra cada tarea y su estado actual, desde la solicitud hasta la producción. Cualquiera que mire el tablero puede ver **en qué se está trabajando en este momento**. Se usa porque hace que la entrega sea **predecible y observable**. Las partes interesadas siguen el progreso real sin reuniones de estado ni persecución de actualizaciones. Para proyectos de Drupal, **las columnas, los límites de trabajo en curso y los criterios de salida** se corresponden directamente con cómo el código pasa de un elemento del backlog a una funcionalidad desplegada en vivo. El tablero es la capa operativa subyacente a la entrega ágil: las *ceremonias Scrum* marcan el ritmo, y el tablero Kanban gobierna el **flujo de trabajo** día a día. Habla con nuestro equipo. Mira cómo nuestra entrega mediante Kanban gobernado te ofrece proyectos Drupal predecibles y transparentes. [Habla con nuestro equipo.](#contacto) ## El tablero de Metadrop: del Backlog a Hecho Una tarea atraviesa seis columnas en orden. Cada columna tiene un **criterio de entrada y salida** claro, por lo que una tarjeta nunca avanza hasta haber alcanzado el siguiente estado. El ciclo de vida siguiente muestra cómo una solicitud se convierte en una funcionalidad activa y desplegada sin saltarse ningún punto de control. ## El ciclo de vida de las columnas del tablero Cada tarjeta se mueve de izquierda a derecha a través de estos seis estados, ganando la siguiente columna en cada paso. 1. ### Tareas pendientes Contiene tareas documentadas y priorizadas, así como historias de usuario con **criterios de aceptación** establecidos, listas para ser estimadas e integradas en un ciclo. 2. ### Por Hacer Contiene tarjetas aprobadas para comenzar. **Aún no se ha comenzado a trabajar**, por lo que todavía pueden intercambiarse por elementos del backlog con la misma puntuación si las prioridades cambian. 3. ### En Proceso Contiene tarjetas en **desarrollo pendiente de entrega** activo, además de cualquier tarjeta rechazada (*KO*) que se esté corrigiendo y reenviando para su revisión. 4. ### Garantía de calidad Almacena tarjetas en **validación** que han superado las pruebas automatizadas (*Behat*, *Unit*, *análisis estático*) y la **revisión interna** del equipo antes de mostrar cualquier cosa al cliente. 5. ### Desplegar Contiene tarjetas **aprobadas para su envío**, en cola para su lanzamiento a Producción. 6. ### Hecho Contiene tarjetas **finalizadas y desplegadas** en Producción. ## Límites de WIP: por qué limitamos el trabajo en curso ### Los límites están en proceso Un *límite WIP* establece cuántas tarjetas pueden estar en una columna a la vez, por lo que el tablero **evita que el equipo comience más de lo que puede terminar**. ### Identifica cuellos de botella Si QA está lleno, no se inicia nuevo desarrollo hasta que las tarjetas se liberan, por lo que los problemas se **arreglan en lugar de acumularse**. ### Rendimiento más estable Los clientes obtienen **un rendimiento más rápido y estable** y un ritmo realista y observable, en lugar de un aluvión de trabajos a medio terminar que se estancan cerca de una fecha límite. Los límites del WIP convierten un "estamos ocupados" en **"estamos realmente entregando"**. ## Qué ocurre cuando falla una tarjeta: el bucle de KO/rework Si una tarjeta no supera el control de calidad o el cliente la rechaza, se marca como *KO* y se envía **de vuelta a En Progreso**. Nunca se cierra ni se oculta silenciosamente. El mismo desarrollador **corrige el problema**, y la tarjeta vuelve a entrar en QA para ser **revisada desde cero** con las mismas pruebas automatizadas e internas. Una tarjeta solo llega a Deploy cuando **supera limpiamente**, por lo que los defectos se detectan **dentro del equipo**, no por los usuarios ni en Producción. Este bucle es la razón por la que la entrega tiene **bajo riesgo por diseño**: el rework es un estado esperado y registrado, no una emergencia. ## La puerta de control de calidad: cómo se garantiza la calidad antes de la entrega Cada tarjeta debe superar un **conjunto de pruebas automatizadas**, que cubren *Behat* (comportamiento), *Unit* (lógica) y *análisis estático* (estándares de código y tipado), antes de que una persona lo revise. Luego pasa por la **validación interna del equipo**: una segunda persona confirma que el trabajo cumple con los criterios de aceptación **antes de que el cliente lo vea**. Nada avanza a Despliegue solo por la palabra del desarrollador, porque el **tablero impone la puerta de control**, haciendo de la calidad un proceso en lugar de una promesa. Para obtener información completa sobre las pruebas y el pipeline de CI/CD detrás de esta puerta de control, consulta la [metodología de control de calidad](https://metadrop.net/es/quienes-somos/metodologia/control-de-calidad). Discute tu proyecto. Háblanos de tu proyecto en Drupal y te mostraremos cómo este tablero mantiene predecible la entrega. [Discute tu proyecto.](#contacto) ## Entrega predecible frente a desarrollo ad-hoc El resultado es una **entrega transparente y de bajo riesgo**, la razón principal por la que los equipos empresariales confían en un socio gobernado en lugar de un proveedor no estructurado. ### Visible vs. opaco Las **agencias opacas** trabajan como una caja negra, donde se conocen los retrasos justo al final. Con nuestro tablero, **el progreso es visible a diario** y las sorpresas se detectan con antelación. ### Con puerta vs. ad hoc **Entrega ad-hoc** envía trabajo sin probar y lo corrige en Producción. Nuestro **control de calidad y bucle de KO** mantienen los defectos internamente y fuera de tu sitio en vivo. ### Terminable vs. infinito La **ausencia de control de WIP** significa que todo está "en progreso" y nada se termina. Los **límites de WIP** obligan a un flujo constante y finalizable, la diferencia entre movimiento y progreso. ## Por qué este modelo de entrega es importante para tu proyecto - **Más de 15 años entregando Drupal** como *Partner certificado Silver de Drupal*. Este tablero se refina en cada proyecto, no se improvisa por cliente. - Se aplican los mismos **estados, límites de WIP y control de calidad en cada ciclo de entrega**, por lo que el comportamiento es coherente tanto si el proyecto es un único sitio como una plataforma multisitio. - Respaldado por la **certificación ENS y un historial de cumplimiento de GDPR, WCAG y NIS2**, el control de calidad forma parte de cómo se cumplen esos estándares. - Utilizado en trabajos críticos de Drupal por organizaciones como **Saint-Gobain, Save the Children, Telefónica y UNICEF**. ## Preguntas frecuentes - ### ¿Qué es un tablero Kanban? Un tablero Kanban es un flujo de trabajo visual que registra cada tarea a través de estados definidos. En Metadrop, esos estados son *Backlog → To Do → In Progress → QA → Deploy → Done*, de modo que el **estado de todo el trabajo es visible de un vistazo** y el progreso se mide en tiempo real. - ### ¿En qué se diferencia un tablero Kanban de Scrum? Scrum establece el **ritmo** mediante sprints, planificación, revisiones y retrospectivas, mientras que Kanban gestiona el **flujo continuo de trabajo** a través de columnas y límites WIP. Ambos se utilizan juntos. Para el lado de las ceremonias, consulta la [metodología de reuniones Scrum](https://metadrop.net/es/quienes-somos/metodologia/agile-scrum-meetings). - ### ¿Cómo hacen los clientes para seguir el progreso de un proyecto? El tablero es la fuente de la verdad. Se puede ver **qué tarjetas están en desarrollo, en QA o desplegadas** en cualquier momento, sin necesidad de solicitar una actualización de estado. La visibilidad es continua, en lugar de un informe semanal. - ### ¿Qué sucede cuando una tarea no supera los controles de calidad? Se marca como *KO* y vuelve a En Progreso para su corrección, luego **vuelve a QA para ser revisado de nuevo** antes de poder avanzar. Una tarjeta solo llega a Producción cuando **supera la revisión sin errores**, por lo que los defectos se detectan dentro del equipo. - ### ¿Qué son los límites de WIP y por qué son importantes? Los límites WIP (trabajo en curso) limitan cuántas tarjetas puede contener una columna, lo que **evita que el equipo se sobrecargue** y revela los cuellos de botella de inmediato. El resultado es un **flujo de trabajo más estable y un ritmo de entrega predecible**. ## Ponte en contacto Ve cómo nuestra agencia Drupal convierte este modelo de entrega Kanban en una entrega de proyectos predecible y transparente para tu equipo. Explora nuestra metodología: [Reuniones Agile Scrum](https://metadrop.net/es/quienes-somos/metodologia/agile-scrum-meetings), [Aseguramiento de Calidad](https://metadrop.net/es/quienes-somos/metodologia/control-de-calidad), [Herramientas](https://metadrop.net/es/quienes-somos/metodologia/herramientas-agile) y [Entregables](https://metadrop.net/es/quienes-somos/metodologia/entregables). You must have JavaScript enabled to use this form. Nombre Email Organización Cuéntanos Escribe tu mensaje aquí... Política privacidad He leído y acepto [**la política de privacidad**](https://metadrop.net/en/politica-privacidad) respecto al tratamiento de datos. Deje este campo en blanco ## Metodología Cómo gestiona Metadrop proyectos Drupal complejos: ceremonias Scrum, tableros Kanban, control de calidad y entregables completos al cierre. - [**Control de Calidad**](https://metadrop.net/es/quienes-somos/metodologia/control-de-calidad "Cómo aseguramos la calidad del código: pipelines CI/CD, testing automatizado, análisis estático y revisión por pares en cada proyecto Drupal.") Cómo aseguramos la calidad del código: pipelines CI/CD, testing automatizado, análisis estático y revisión por pares en cada proyecto Drupal. - [**Herramientas**](https://metadrop.net/es/quienes-somos/metodologia/herramientas-agile "Las herramientas ágiles y DevOps de Metadrop: control de versiones, CI/CD, comunicación y gestión de proyectos.") Las herramientas ágiles y DevOps de Metadrop: control de versiones, CI/CD, comunicación y gestión de proyectos. - [**Entregables**](https://metadrop.net/es/quienes-somos/metodologia/entregables "Entrega completa de código fuente, documentación, credenciales y accesos para que tu equipo sea totalmente autosuficiente al cierre del proyecto.") Entrega completa de código fuente, documentación, credenciales y accesos para que tu equipo sea totalmente autosuficiente al cierre del proyecto. - [**Agile Scrum Meetings**](https://metadrop.net/es/quienes-somos/metodologia/agile-scrum-meetings "Cómo aplica Metadrop las ceremonias Scrum — dailies, planificación de sprint, reviews y retrospectivas — en nuestros proyectos ágiles de Drupal.") Cómo aplica Metadrop las ceremonias Scrum — dailies, planificación de sprint, reviews y retrospectivas — en nuestros proyectos ágiles de Drupal.