Product builder - Revision history

Mberne: /* El modelo de doble carril */

2026-05-21T08:25:04Z

El modelo de doble carril

← Older revision		Revision as of 10:25, 21 May 2026
Line 41:		Line 41:
	* '''Carril robusto (vibe engineering):''' implementación con estándares completos. Se aplican [[Spec-Driven Development (SDD)\|SDD]], [[Definición de hecho\|DoD reforzada]] y revisión humana rigurosa. El objetivo es que el incremento sea mantenible, seguro y desplegable.		* '''Carril robusto (vibe engineering):''' implementación con estándares completos. Se aplican [[Spec-Driven Development (SDD)\|SDD]], [[Definición de hecho\|DoD reforzada]] y revisión humana rigurosa. El objetivo es que el incremento sea mantenible, seguro y desplegable.

	La decisión de en qué carril operar en cada momento la toma el [[Product ~~Architect~~\|product architect]] en coordinación con el equipo.		La decisión de en qué carril operar en cada momento la toma el [[Product architect\|product architect]] en coordinación con el equipo.

	=== Rol en Spec-Driven Development ===		=== Rol en Spec-Driven Development ===

Mberne: /* Nuevas competencias */

2026-05-21T08:24:53Z

Nuevas competencias

← Older revision		Revision as of 10:24, 21 May 2026
Line 25:		Line 25:
	* '''[[Prompt engineering\|Prompt engineering]]:''' formular instrucciones efectivas para los modelos de lenguaje.		* '''[[Prompt engineering\|Prompt engineering]]:''' formular instrucciones efectivas para los modelos de lenguaje.
	* '''[[Context engineering\|Context engineering]]:''' gestionar el contexto que recibe el agente a lo largo de una sesión o proyecto para mantener la coherencia y reducir [[Alucinación de IA\|alucinaciones]].		* '''[[Context engineering\|Context engineering]]:''' gestionar el contexto que recibe el agente a lo largo de una sesión o proyecto para mantener la coherencia y reducir [[Alucinación de IA\|alucinaciones]].
	* '''[[~~Spec-Driven Development (SDD)\|~~Spec writing]]:''' escribir especificaciones estructuradas que definen con precisión qué debe generar el agente y con qué criterios de calidad.		* '''[[Spec writing]]:''' escribir especificaciones estructuradas que definen con precisión qué debe generar el agente y con qué criterios de calidad.
	* '''Revisión crítica:''' detectar en el código generado por IA los errores sutiles que tienen apariencia de solución válida: lógica de negocio incorrecta, casos extremos no cubiertos, duplicación no visible, vulnerabilidades de seguridad.		* '''Revisión crítica:''' detectar en el código generado por IA los errores sutiles que tienen apariencia de solución válida: lógica de negocio incorrecta, casos extremos no cubiertos, duplicación no visible, vulnerabilidades de seguridad.

Mberne: /* Véase también */

2026-05-20T13:10:39Z

Véase también

← Older revision		Revision as of 15:10, 20 May 2026
Line 105:		Line 105:
	[[Category:Glosario de términos]]		[[Category:Glosario de términos]]
	[[Category:Scrum]]		[[Category:Scrum]]
	[[Category:~~Practicas_agiles~~]]		[[Category:Prácticas ágiles]]

Mberne: /* Véase también */

2026-05-20T13:07:38Z

Véase también

← Older revision		Revision as of 15:07, 20 May 2026
Line 89:		Line 89:

	<div class="bok-tags">		<div class="bok-tags">
	[[Desarrollador]] [[Product ~~Architect~~]] [[Agile ~~Enabler~~]] [[Spec-Driven Development]] [[Definición de hecho]] [[Double-~~track~~]] [[Vibe coding]] [[Vibe engineering]] [[Revisión por pares]] [[Deuda técnica]]		[[Desarrollador]] [[Product architect]] [[Agile enabler]] [[Spec-Driven Development (SDD)]] [[Definición de hecho]] [[Double-Track]] [[Vibe coding]] [[Vibe engineering]] [[Revisión por pares]] [[Deuda técnica]]
	</div>		</div>

Mberne: /* El modelo de doble carril */

2026-05-20T13:07:10Z

El modelo de doble carril

← Older revision		Revision as of 15:07, 20 May 2026
Line 34:		Line 34:
	Esta capacidad de revisión crítica requiere conocimiento profundo del dominio del producto, de la arquitectura del sistema y de las formas en que la IA falla habitualmente. No es reemplazable por otro agente de IA: requiere el juicio de alguien que entiende el sistema como un todo.		Esta capacidad de revisión crítica requiere conocimiento profundo del dominio del producto, de la arquitectura del sistema y de las formas en que la IA falla habitualmente. No es reemplazable por otro agente de IA: requiere el juicio de alguien que entiende el sistema como un todo.

	=== El [[Double-~~track~~\|modelo de doble carril]] ===		=== El [[Double-Track\|modelo de doble carril]] ===

	Los product builders trabajan en dos modos según el carril:		Los product builders trabajan en dos modos según el carril:

Mberne: Created page with "{{Meta-bok|min=5}} El '''Product builder''' (también denominado ''Developer AI'' o ''desarrollador con IA'') es la evolución del rol de desarrollador en equipos que trabajan con herramientas de inteligencia artificial generativa. Es el profesional responsable de construir el incremento de producto combinando el uso de herramientas no-code, generación de código asistida por IA y comprensión profunda del producto y su arquitectura. El rol y su denom..."

2026-05-20T13:06:55Z

Created page with "{{Meta-bok|min=5}} El '''Product builder''' (también denominado ''Developer AI'' o ''desarrollador con IA'') es la evolución del rol de desarrollador en equipos que trabajan con herramientas de inteligencia artificial generativa. Es el profesional responsable de construir el incremento de producto combinando el uso de herramientas no-code, generación de código asistida por IA y comprensión profunda del producto y su arquitectura. El rol y su denom..."

New page

{{Meta-bok|min=5}}
El '''Product builder''' (también denominado ''Developer AI'' o ''desarrollador con IA'') es la evolución del rol de [[Desarrollador|desarrollador]] en equipos que trabajan con herramientas de inteligencia artificial generativa. Es el profesional responsable de construir el incremento de producto combinando el uso de herramientas no-code, generación de código asistida por IA y comprensión profunda del producto y su arquitectura.

El rol y su denominación han sido descritos por Scrum Manager en la guía ''Scrum en equipos con IA'' (v1.0, marzo 2026) y en ''SDD — Spec Driven Development en equipos ágiles''.

== Foco principal ==

El Product builder concentra su trabajo en cuatro áreas:

* '''Orquestación de IA:''' diseñar y gestionar el trabajo que los agentes de IA ejecutan, incluyendo la definición precisa de tareas, la supervisión del proceso y la integración de los resultados.
* '''Arquitectura:''' mantener la coherencia y la calidad estructural del sistema a medida que crece con contribuciones de agentes de IA.
* '''Spec writing:''' escribir las especificaciones que guían el trabajo de los agentes con el nivel de detalle y estructura necesarios para que los agentes produzcan outputs válidos.
* '''Revisión crítica del código generado:''' validar que el código generado por la IA cumple la [[Definición de hecho|DoD reforzada]] antes de integrarlo.

== Qué cambia respecto al desarrollador clásico ==

=== El valor se desplaza de implementar a orquestar ===

El desarrollador clásico aporta valor principalmente implementando: escribiendo código que resuelve el problema. El product builder aporta valor principalmente orquestando: diseñando la arquitectura, escribiendo specs que guíen a la IA, revisando y validando lo que genera, asegurando calidad y seguridad.

Este desplazamiento no significa que el product builder no sepa programar: significa que su tiempo de mayor impacto está en las decisiones de arquitectura, la definición precisa de los objetivos para la IA y la revisión crítica del output, no en la implementación línea a línea.

=== Nuevas competencias ===
El product builder necesita competencias adicionales a las del desarrollador clásico:
* '''[[Prompt engineering|Prompt engineering]]:''' formular instrucciones efectivas para los modelos de lenguaje.
* '''[[Context engineering|Context engineering]]:''' gestionar el contexto que recibe el agente a lo largo de una sesión o proyecto para mantener la coherencia y reducir [[Alucinación de IA|alucinaciones]].
* '''[[Spec-Driven Development (SDD)|Spec writing]]:''' escribir especificaciones estructuradas que definen con precisión qué debe generar el agente y con qué criterios de calidad.
* '''Revisión crítica:''' detectar en el código generado por IA los errores sutiles que tienen apariencia de solución válida: lógica de negocio incorrecta, casos extremos no cubiertos, duplicación no visible, vulnerabilidades de seguridad.

=== La revisión crítica como competencia central ===

La IA produce soluciones plausibles pero frecuentemente frágiles. El product builder es quien detecta los errores sutiles: el código que compila y pasa los tests pero que tiene una lógica de negocio incorrecta en los casos extremos; la función que duplica lógica existente en otro módulo porque el agente no tenía el contexto completo del sistema; la query que funciona con los datos de desarrollo pero falla con los de producción.

Esta capacidad de revisión crítica requiere conocimiento profundo del dominio del producto, de la arquitectura del sistema y de las formas en que la IA falla habitualmente. No es reemplazable por otro agente de IA: requiere el juicio de alguien que entiende el sistema como un todo.

=== El [[Double-track|modelo de doble carril]] ===

Los product builders trabajan en dos modos según el carril:

* '''Carril rápido (vibe coding):''' exploración ágil con IA para validar hipótesis. La calidad del código es secundaria; lo que importa es la velocidad de aprendizaje. El objetivo es generar evidencia de que vale la pena construir algo.
* '''Carril robusto (vibe engineering):''' implementación con estándares completos. Se aplican [[Spec-Driven Development (SDD)|SDD]], [[Definición de hecho|DoD reforzada]] y revisión humana rigurosa. El objetivo es que el incremento sea mantenible, seguro y desplegable.

La decisión de en qué carril operar en cada momento la toma el [[Product Architect|product architect]] en coordinación con el equipo.

=== Rol en Spec-Driven Development ===

En el marco SDD, el product builder es el orquestador de la implementación:

* Contribuye a refinar los requisitos con su conocimiento técnico (identificando inconsistencias, dependencias o riesgos técnicos en los requisitos).
* Diseña la solución técnica.
* Descompone el diseño en tareas atómicas que los agentes pueden ejecutar de forma autónoma.
* Orquesta la implementación delegando a agentes y revisando cada contribución.
* Es responsable de que el código generado pase la DoD reforzada antes de integrarse.

== La [[Definición de hecho|DoD reforzada]] como responsabilidad del product builder ==

Todo incremento que contenga código generado por IA debe pasar cuatro criterios adicionales bajo responsabilidad del product builder:

# '''Análisis estático:''' el código pasa linters y análisis automatizado sin errores críticos.
# '''No-duplicación:''' verificado que la IA no introdujo código duplicado (umbral < 5%).
# '''Seguridad:''' no se han introducido vulnerabilidades evidentes.
# '''Revisión humana:''' al menos una persona ha revisado el código con criterio técnico propio, no delegando la revisión en otra IA.

== Indicador clave ==

El valor de los product builders '''no se mide por la cantidad de código producido''' sino por la calidad, mantenibilidad y robustez de lo que entregan. Un equipo que genera muchas líneas de código en poco tiempo pero que acumula [[Deuda técnica|deuda técnica]] oculta no está siendo productivo: está acelerando hacia un problema mayor.

== Error frecuente ==

<div class="bok-aviso">
'''Asumir que la revisión de código generado por IA es equivalente a aceptar su output.''' Revisar significa entender, cuestionar y validar, no solo ejecutar los tests y aprobar si pasan. Un product builder que aprueba el código de la IA porque "los tests pasan y parece correcto" está delegando el juicio técnico en la herramienta. Los tests validan el comportamiento conocido; el juicio del product builder valida la coherencia con el sistema, la mantenibilidad a largo plazo y los casos que los tests no cubren.
</div>

== Recursos ==
<div class="bok-recurso">
📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum en equipos con IA''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
</div>
<div class="bok-recurso">
🏦 [https://scrummanager.com/skillarena/scrum-con-ia '''Scrum en equipos con IA''']<span class="detalle">Skill Arena · Scrum Manager</span>
</div>
<div class="bok-recurso">
📊 [https://scrummanager.com/website/c/info/resource.php?id=374 '''Guía didáctica SDD''']<span class="detalle">Recursos · Scrum Manager</span>
</div>
<div class="bok-recurso">
🏦 [https://scrummanager.com/skillarena/sdd-en-equipos-agiles '''SDD en equipos ágiles''']<span class="detalle">Skill Arena · Scrum Manager</span>
</div>

== Véase también ==

<div class="bok-tags">
[[Desarrollador]] [[Product Architect]] [[Agile Enabler]] [[Spec-Driven Development]] [[Definición de hecho]] [[Double-track]] [[Vibe coding]] [[Vibe engineering]] [[Revisión por pares]] [[Deuda técnica]]
</div>

<div class="bok-ecosistema">
<div class="texto">
<span class="titulo">'''¿Quieres avanzar en agilidad?'''</span>
<span class="sub">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 [https://scrummanager.com/skillarena/ '''Skill Arena''']: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.</span>
</div>
<div class="botones">
<div class="bok-btn-outline">[https://www.scrummanager.com/website/c/calendar/show-courses.php Buscar convocatorias]</div>
<div class="bok-btn-filled">[https://scrummanager.com/club/ Club Agile]</div>
</div>
</div>

[[Category:Glosario de términos]]
[[Category:Scrum]]
[[Category:Practicas_agiles]]