Roles: Difference between revisions
| (One intermediate revision by the same user not shown) | |||
| Line 30: | Line 30: | ||
== Evolución de los roles en equipos con IA == | == Evolución de los roles en equipos con IA == | ||
La guía ''Scrum en equipos con IA'' de Scrum Manager describe cómo evolucionan los tres roles cuando el equipo trabaja con herramientas de IA generativa: | La guía ''Scrum en equipos con IA'' de Scrum Manager describe cómo evolucionan los tres roles cuando el equipo trabaja con herramientas de IA generativa: | ||
* '''Propietario del producto → Product architect:''' el backlog pasa de ser una lista de features a un conjunto de hipótesis a validar. La pregunta estratégica ya no es "¿podemos construirlo?" sino "¿deberíamos construirlo?". Gestiona la paradoja de la productividad: el equipo produce más, pero eso solo genera valor si hay validación estratégica detrás. | * '''Propietario del producto → [[Product architect]]:''' el backlog pasa de ser una lista de features a un conjunto de hipótesis a validar. La pregunta estratégica ya no es "¿podemos construirlo?" sino "¿deberíamos construirlo?". Gestiona la paradoja de la productividad: el equipo produce más, pero eso solo genera valor si hay validación estratégica detrás. | ||
* '''Desarrollador → Product builder:''' el valor se desplaza de implementar a orquestar. Diseñar arquitecturas, escribir especificaciones que guíen a la IA, revisar y validar lo generado, asegurar calidad y seguridad. | * '''Desarrollador → [[Product builder]]:''' el valor se desplaza de implementar a orquestar. Diseñar arquitecturas, escribir especificaciones que guíen a la IA, revisar y validar lo generado, asegurar calidad y seguridad. | ||
* '''Scrum Master → Agile enabler:''' facilita no solo las interacciones entre personas, sino el sistema completo humanos + agentes IA. Es responsable de la gobernanza del uso de IA: políticas, límites, auditoría de outputs, rendición de cuentas. | * '''Scrum Master → [[Agile enabler]]:''' facilita no solo las interacciones entre personas, sino el sistema completo humanos + agentes IA. Es responsable de la gobernanza del uso de IA: políticas, límites, auditoría de outputs, rendición de cuentas. | ||
== Error frecuente == | == Error frecuente == | ||
| Line 45: | Line 45: | ||
== Véase también == | == Véase también == | ||
<div class="bok-tags"> | <div class="bok-tags"> | ||
[[Propietario del producto]] [[Desarrollador]] [[Scrum Master]] [[Artefactos]] [[Eventos | [[Propietario del producto]] [[Desarrollador]] [[Scrum Master]] [[Artefactos]] [[Eventos]] | ||
</div> | </div> | ||
<div class="bok-ecosistema"> | <div class="bok-ecosistema"> | ||
Latest revision as of 15:12, 20 May 2026
Los roles en el marco Scrum técnico son los tres perfiles con responsabilidades diferenciadas que conforman el equipo Scrum: el propietario del producto, el desarrollador y el Scrum Master. Cada uno aporta una perspectiva y unas responsabilidades distintas que, en conjunto, permiten al equipo construir valor de forma continua y autogestionada. Los roles en un marco de Scrum técnico son:
- Propietario del producto. Responsable de definir y priorizar las características del producto, asegurándose de que el trabajo del equipo de desarrollo se alinea con las expectativas del cliente y los objetivos del negocio.
- Desarrollador. Cada uno de los profesionales que realizan el incremento de cada sprint.
- Scrum Master. Es el responsable del cumplimiento de las reglas del marco de Scrum. Se asegura de que estas son entendidas por la organización y de que se trabaja conforme a ellas.
Comprometidos e implicados
Todas las personas que intervienen o tienen relación directa o indirecta con el proyecto se clasifican en dos grupos: comprometidos e implicados. En círculos de Scrum es frecuente llamar a los primeros "cerdos" y a los segundos "gallinas", aunque esta terminología fue eliminada de la Scrum Guide oficial en 2011 y no es de uso recomendado en entornos formales.
El origen de estos nombres está en la siguiente metáfora, que ilustra de forma gráfica la diferencia entre "compromiso" e "implicación" con el proyecto:
Una gallina y un cerdo paseaban por la carretera. La gallina preguntó al cerdo: “¿Quieres abrir un restaurante conmigo?”.
El cerdo consideró la propuesta y respondió: “Sí, me gustaría. ¿Y cómo lo llamaríamos?”. La gallina respondió: “Jamón con huevos”.
El cerdo se detuvo, hizo una pausa y contestó: “Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido, mientras que tu estarías sólo implicada”.
Los comprometidos (cerdos) son quienes tienen su trabajo y su reputación directamente vinculados al resultado: el equipo de desarrollo, el propietario del producto y el Scrum Master. Los implicados (gallinas) son quienes tienen interés en el proyecto pero no responden directamente de su resultado: directivos, clientes, usuarios finales, otros departamentos.
Esta distinción es relevante en las reuniones de Scrum: en la planificación del sprint y en el scrum diario, las intervenciones de los implicados deben ser limitadas para no interferir en el trabajo de los comprometidos.
Evolución de los roles en equipos con IA
La guía Scrum en equipos con IA de Scrum Manager describe cómo evolucionan los tres roles cuando el equipo trabaja con herramientas de IA generativa:
- Propietario del producto → Product architect: el backlog pasa de ser una lista de features a un conjunto de hipótesis a validar. La pregunta estratégica ya no es "¿podemos construirlo?" sino "¿deberíamos construirlo?". Gestiona la paradoja de la productividad: el equipo produce más, pero eso solo genera valor si hay validación estratégica detrás.
- Desarrollador → Product builder: el valor se desplaza de implementar a orquestar. Diseñar arquitecturas, escribir especificaciones que guíen a la IA, revisar y validar lo generado, asegurar calidad y seguridad.
- Scrum Master → Agile enabler: facilita no solo las interacciones entre personas, sino el sistema completo humanos + agentes IA. Es responsable de la gobernanza del uso de IA: políticas, límites, auditoría de outputs, rendición de cuentas.
Error frecuente
Tratar el Scrum Master como gestor del proyecto. El Scrum Master no asigna trabajo, no gestiona recursos ni toma decisiones de producto. Su rol es asegurar que el marco Scrum funcione correctamente, facilitar los eventos, eliminar impedimentos y proteger al equipo de interferencias externas. Cuando el Scrum Master empieza a comportarse como un gestor de proyectos tradicional, el equipo pierde la autogestión que hace eficaz a Scrum.
Recursos
📄 Scrum Master v.4.0Descarga gratuita · Scrum Manager
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.