Vibe engineering - Revision history

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

2026-05-25T10:35:17Z

Véase también

← Older revision		Revision as of 12:35, 25 May 2026
Line 234:		Line 234:

	<div class="bok-tags">		<div class="bok-tags">
	[[Vibe coding]] [[Spec-Driven Development]] [[Spec]] [[~~Definition of Done~~]] [[Deuda técnica]] [[Agente de IA]] [[Prompt engineering]] [[Integración continua]]		[[Vibe coding]] [[Spec-Driven Development (SDD)]] [[Spec]] [[Definición de hecho]] [[Deuda técnica]] [[Agente de IA]] [[Prompt engineering]] [[Integración continua]]
	</div>		</div>

Mberne: /* Referencias */

2026-05-20T13:14:21Z

Referencias

← Older revision		Revision as of 15:14, 20 May 2026
Line 226:		Line 226:

	== Referencias ==		== Referencias ==

	* Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR.		* Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR.
	* Böckeler, Birgitta. (2025). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, MartinFowler.com.		* Böckeler, Birgitta. (2025). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, MartinFowler.com.
	* GitHub. (2025). “Spec Kit”, GitHub.		* GitHub. (2025). “Spec Kit”, GitHub.
	* Scrum Manager. (2026). ''Scrum en equipos con IA''. Scrum Manager.
	* Scrum Manager. (2026). ''SDD – Spec Driven Development en equipos ágiles''. Scrum Manager.
	* Veracode. (2025). “Insights from 2025 GenAI Code Security Report”, Veracode.		* Veracode. (2025). “Insights from 2025 GenAI Code Security Report”, Veracode.

Mberne: /* Recursos */

2026-05-20T13:13:48Z

Recursos

← Older revision		Revision as of 15:13, 20 May 2026
Line 224:		Line 224:
	📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum Master en equipos con IA''']<span class="detalle">Descarga gratuita · Scrum Manager</span>		📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum Master en equipos con IA''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
	</div>		</div>
	~~<div class="bok-recurso">~~

	== Referencias ==		== Referencias ==

Mberne: /* Error frecuente */

2026-05-20T13:13:42Z

Error frecuente

← Older revision		Revision as of 15:13, 20 May 2026
Line 213:		Line 213:

	== Error frecuente ==		== Error frecuente ==

	<div class="bok-aviso">		<div class="bok-aviso">
	'''Creer que vibe engineering es vibe coding con más cuidado.''' Vibe engineering no consiste en pedirle a la IA el mismo código y revisarlo un poco más. Implica cambiar el sistema de trabajo: escribir specs, preparar contexto, dividir tareas, aplicar controles técnicos, estimar revisión humana y asumir responsabilidad sobre lo que llega a producción.		'''Creer que vibe engineering es vibe coding con más cuidado.''' Vibe engineering no consiste en pedirle a la IA el mismo código y revisarlo un poco más. Implica cambiar el sistema de trabajo: escribir specs, preparar contexto, dividir tareas, aplicar controles técnicos, estimar revisión humana y asumir responsabilidad sobre lo que llega a producción.

Mberne: /* Recursos */

2026-05-20T13:13:34Z

Recursos

@@ Line 226: / Line 226: @@
 </div>
 <div class="bok-recurso">
 == Referencias ==

Mberne: /* Recursos */

2026-05-19T15:36:51Z

Recursos

← Older revision		Revision as of 17:36, 19 May 2026
Line 219:		Line 219:

	== Recursos ==		== Recursos ==

	<div class="bok-recurso">		<div class="bok-recurso">
	📄 [https://~~martinfowler~~.com/~~articles~~/~~exploring~~-~~gen~~-~~ai/sdd-3-tools.html Understanding Spec~~-~~Driven~~-~~Development: Kiro, spec-kit, and Tessl~~]<span class="detalle">~~Artículo de Birgitta Böckeler sobre SDD, niveles de adopción y herramientas · Martin Fowler~~ · ~~2025~~</span>		🏦 [https://scrummanager.com/skillarena/ia-aplicada-al-trabajo-agil '''IA aplicada al trabajo ágil''']<span class="detalle">Skill Arena · Scrum Manager</span>
	</div>		</div>

	<div class="bok-recurso">		<div class="bok-recurso">
	📊 [https://~~github~~.com/~~github~~/~~spec-kit Spec Kit~~]<span class="detalle">~~Toolkit open source para flujos de desarrollo dirigidos por especificación~~ · ~~GitHub~~</span>		📄 [https://scrummanager.com/files/scrumenequiposconia.pdf '''Scrum Master en equipos con IA''']<span class="detalle">Descarga gratuita · Scrum Manager</span>
	</div>		</div>

	<div class="bok-recurso">		<div class="bok-recurso">
	📄 [https://~~metr~~.~~org~~/~~blog~~/~~2025~~-~~07-10-early-2025~~-ai-~~experienced~~-os-~~dev~~-~~study/ Measuring the Impact of Early~~-~~2025 AI on Experienced Open-Source Developer Productivity~~]<span class="detalle">~~Estudio~~ sobre ~~productividad~~, ~~percepción~~ de ~~velocidad~~ y ~~coste de revisión con IA~~ · ~~METR~~ · 2025</span>		📄 [https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html '''Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl''']<span class="detalle">Artículo de Birgitta Böckeler sobre SDD, niveles de adopción y herramientas · Martin Fowler · 2025</span>
	</div>		</div>

	<div class="bok-recurso">		<div class="bok-recurso">
	📄 [https://www.veracode.com/blog/genai-code-security-report/ Insights from 2025 GenAI Code Security Report]<span class="detalle">Informe sobre vulnerabilidades en código generado por IA · Veracode · 2025</span>		📊 [https://github.com/github/spec-kit '''Spec Kit''']<span class="detalle">Toolkit open source para flujos de desarrollo dirigidos por especificación · GitHub</span>
			</div>
			<div class="bok-recurso">
			📄 [https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ '''Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity''']<span class="detalle">Estudio sobre productividad, percepción de velocidad y coste de revisión con IA · METR · 2025</span>
			</div>
			<div class="bok-recurso">
			📄 [https://www.veracode.com/blog/genai-code-security-report/ '''Insights from 2025 GenAI Code Security Report''']<span class="detalle">Informe sobre vulnerabilidades en código generado por IA · Veracode · 2025</span>
	</div>		</div>

Mberne: /* Relación con Spec-Driven Development */

2026-05-19T15:34:27Z

Relación con Spec-Driven Development

← Older revision		Revision as of 17:34, 19 May 2026
Line 159:		Line 159:
	== Relación con Spec-Driven Development ==		== Relación con Spec-Driven Development ==

	[[Spec-Driven Development]] es una de las prácticas centrales del vibe engineering.		[[Spec-Driven Development (SDD)\|Spec-Driven Development]] es una de las prácticas centrales del vibe engineering.

	SDD aporta el método: antes de generar código, el equipo define una spec que guía el trabajo del agente. Vibe engineering aporta el contexto de uso: esa práctica forma parte de un carril robusto orientado a producción.		SDD aporta el método: antes de generar código, el equipo define una spec que guía el trabajo del agente. Vibe engineering aporta el contexto de uso: esa práctica forma parte de un carril robusto orientado a producción.

Mberne at 15:33, 19 May 2026

2026-05-19T15:33:58Z

← Older revision		Revision as of 17:33, 19 May 2026
Line 1:		Line 1:
	{{Meta-bok\|min=4}}		{{Meta-bok\|min=4}}
	''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante [[Vibe coding\|vibe coding]], se convierte en software mantenible, seguro y liberable mediante [[Spec-Driven Development (SDD)\|Spec-Driven Development]], revisión humana, pruebas, QA y una [[Definición de hecho\|Definition of Done]] reforzada.		'''''Vibe engineering''''' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante [[Vibe coding\|vibe coding]], se convierte en software mantenible, seguro y liberable mediante [[Spec-Driven Development (SDD)\|Spec-Driven Development]], revisión humana, pruebas, QA y una [[Definición de hecho\|Definition of Done]] reforzada.

	Vibe engineering es el complemento del [[Vibe coding\|vibe coding]]. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.		Vibe engineering es el complemento del [[Vibe coding\|vibe coding]]. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.

Mberne at 15:33, 19 May 2026

2026-05-19T15:33:50Z

← Older revision		Revision as of 17:33, 19 May 2026
Line 1:		Line 1:
	{{Meta-bok\|min=4}}		{{Meta-bok\|min=4}}
			''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante [[Vibe coding\|vibe coding]], se convierte en software mantenible, seguro y liberable mediante [[Spec-Driven Development (SDD)\|Spec-Driven Development]], revisión humana, pruebas, QA y una [[Definición de hecho\|Definition of Done]] reforzada.
	~~<div class="bok-def">~~
	''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante [[Vibe coding\|vibe coding]], se convierte en software mantenible, seguro y liberable mediante [[Spec-Driven Development]], revisión humana, pruebas, QA y una [[~~Definition of Done~~\|Definition of Done]] reforzada.
	~~</div>~~

	Vibe engineering es el complemento del [[Vibe coding\|vibe coding]]. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.		Vibe engineering es el complemento del [[Vibe coding\|vibe coding]]. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.

Mberne: Created page with "{{Meta-bok|min=4}}
''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante vibe coding, se convierte en software mantenible, seguro y liberable mediante Spec-Driven Development, revisión humana, pruebas, QA y una Definition of Done reforzada.
Vibe engineering es el complemento del vibe coding. Mientras e..."

2026-05-19T15:33:15Z

Created page with "{{Meta-bok|min=4}} <div class="bok-def"> ''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante vibe coding, se convierte en software mantenible, seguro y liberable mediante Spec-Driven Development, revisión humana, pruebas, QA y una Definition of Done reforzada. </div> Vibe engineering es el complemento del vibe coding. Mientras e..."

New page

{{Meta-bok|min=4}}

<div class="bok-def">
''Vibe engineering'' es el modo de trabajo robusto en desarrollo asistido por IA: una idea validada, a menudo explorada antes mediante [[Vibe coding|vibe coding]], se convierte en software mantenible, seguro y liberable mediante [[Spec-Driven Development]], revisión humana, pruebas, QA y una [[Definition of Done|Definition of Done]] reforzada.
</div>

Vibe engineering es el complemento del [[Vibe coding|vibe coding]]. Mientras el vibe coding prioriza aprender rápido, el vibe engineering prioriza construir con rigor.

El término no debe entenderse como un estándar formal de la industria, sino como una etiqueta útil para describir el carril robusto de trabajo en equipos que usan IA generativa para construir producto. Su valor está en poner nombre a una transición crítica: pasar de “esto parece funcionar” a “esto puede mantenerse, auditarse y llegar a producción”.

== Por qué hace falta ==

La IA generativa ha reducido de forma drástica el coste inicial de producir código. Un equipo puede crear prototipos, pantallas, integraciones simples o pruebas de concepto en mucho menos tiempo que antes.

Pero esa velocidad inicial no resuelve los problemas clásicos de la ingeniería de software. De hecho, puede intensificarlos:

* código que funciona en el caso feliz, pero falla en escenarios límite;
* decisiones técnicas implícitas que nadie revisó;
* duplicación de lógica;
* dependencias innecesarias;
* errores de seguridad;
* integración deficiente con la arquitectura existente;
* pruebas generadas por la misma IA que produjo el código;
* falsa sensación de avance porque el prototipo “se ve bien”.

Vibe engineering responde a ese problema separando dos momentos que no deberían confundirse: exploración y producción.

== Diferencia entre vibe coding y vibe engineering ==

{| class="wikitable"
! Aspecto
! Vibe coding
! Vibe engineering
|-
| Propósito
| Aprender rápido, explorar ideas y validar hipótesis.
| Construir software de producción con estándares técnicos completos.
|-
| Resultado esperado
| Prototipo, prueba de concepto o evidencia de aprendizaje.
| Incremento mantenible, verificable y liberable.
|-
| Calidad del código
| Secundaria mientras el código no llegue a producción.
| Central: seguridad, mantenibilidad, testing, integración y trazabilidad.
|-
| Artefacto principal
| Conversación con la IA, prompts y pruebas rápidas.
| Spec, criterios de aceptación, tareas, controles y Definition of Done reforzada.
|-
| Riesgo principal
| Confundir una demo funcional con software listo.
| Convertir el rigor en burocracia innecesaria.
|}

Ambos modos pueden ser útiles. El error no está en usar vibe coding, sino en no reconocer cuándo una idea ya necesita pasar a vibe engineering.

== Cuándo pasar a vibe engineering ==

Una idea debería pasar del carril rápido al carril robusto cuando:

* la hipótesis ha sido validada con usuarios reales o stakeholders relevantes;
* el prototipo demuestra suficiente valor como para invertir en producción;
* la funcionalidad va a afectar a usuarios, datos, seguridad, permisos, pagos o procesos críticos;
* el código tendrá que mantenerse o evolucionar;
* existen requisitos claros que pueden convertirse en una [[Spec|spec]];
* la solución debe integrarse con una arquitectura existente;
* el riesgo técnico justifica testing, revisión y trazabilidad;
* el coste de rehacer bien la solución es menor que el coste de arrastrar un prototipo frágil.

El paso a vibe engineering no significa necesariamente reutilizar el código generado durante el vibe coding. A menudo, el prototipo sirve como aprendizaje, no como base técnica.

== Cómo funciona ==

Un flujo de vibe engineering puede organizarse así:

# '''Validar la oportunidad''': antes de construir con rigor, el equipo confirma que el problema merece inversión.
# '''Escribir la spec''': se define qué debe construirse, qué queda fuera, qué restricciones existen y cómo se verificará el resultado.
# '''Preparar el contexto para la IA''': el agente recibe arquitectura, estándares, APIs, modelos de datos, ejemplos, criterios de aceptación y límites.
# '''Dividir el trabajo en tareas revisables''': la implementación se descompone en unidades pequeñas, verificables y con criterios claros.
# '''Ejecutar con IA bajo control''': el agente genera código, tests, documentación o cambios técnicos siguiendo la spec.
# '''Aplicar sensores técnicos''': linters, tests, análisis estático, revisión de dependencias, comprobaciones de seguridad y validaciones de integración.
# '''Revisión humana''': un product builder revisa el resultado, valida las decisiones y asume responsabilidad operativa.
# '''Integrar y liberar''': el incremento entra en el flujo normal de entrega si cumple la Definition of Done.

La diferencia con “pedirle a la IA que lo haga” es que en vibe engineering la IA no opera en vacío. Opera dentro de un sistema de restricciones, controles y responsabilidad.

== Elementos principales ==

=== Spec ===

La spec es el artefacto que transforma una intención en un encargo verificable. No tiene que ser larga, pero sí suficientemente clara para evitar que el agente invente decisiones críticas.

Una buena spec incluye:

* comportamiento esperado;
* criterios de aceptación;
* límites de alcance;
* restricciones técnicas;
* casos borde;
* dependencias relevantes;
* requisitos no funcionales;
* señales para saber que el resultado es correcto.

=== Definition of Ready para IA ===

Antes de asignar trabajo a un agente, el equipo debe comprobar que tiene el contexto necesario. En un entorno humano, nadie esperaría que una persona nueva entregara bien sin onboarding. Con la IA ocurre lo mismo.

Un ítem está preparado para trabajo con IA cuando:

* la spec está completa y revisada;
* el agente tiene acceso al contexto relevante;
* los criterios de aceptación son verificables;
* existen estándares técnicos claros;
* se ha estimado el tiempo de revisión humana;
* el equipo sabe quién se responsabiliza del resultado.

=== Definition of Done reforzada ===

En vibe engineering, “done” no significa que el agente haya terminado de generar código. Significa que el incremento cumple los criterios técnicos y de producto acordados.

Puede incluir:

* análisis estático sin errores críticos;
* tests unitarios, de integración o end-to-end según el caso;
* revisión de seguridad;
* verificación de no duplicación;
* revisión humana del diff;
* comprobación de que el resultado cumple la spec;
* trazabilidad de qué fue generado por IA y qué fue revisado por personas.

=== Revisión humana ===

La revisión humana no es una cortesía. Es parte del sistema de calidad.

La IA puede producir soluciones plausibles pero frágiles. El product builder debe evaluar si el código encaja con la arquitectura, si cubre casos reales, si introduce deuda técnica y si puede sostenerse en producción.

=== QA y seguridad ===

El vibe engineering incorpora QA desde el diseño del flujo. No espera al final para descubrir si el incremento funciona.

Las comprobaciones pueden incluir:

* generación y revisión de casos de prueba;
* tests automatizados;
* análisis de vulnerabilidades;
* revisión de dependencias;
* validación de permisos y manejo de datos;
* pruebas sobre casos límite;
* revisión de logs, observabilidad y errores.

== Vibe engineering en Scrum con IA ==

En equipos Scrum con IA, vibe engineering se sitúa en el carril robusto del sistema de trabajo.

El [[Product owner|product owner]] o product architect decide cuándo una idea merece pasar del carril rápido al carril robusto. Esta decisión no se basa solo en si la idea gusta, sino en si hay evidencia suficiente para justificar el coste de construir bien.

Los product builders convierten esa decisión en specs, tareas, implementación revisada y controles técnicos. Su valor no está en producir más líneas de código, sino en asegurar calidad, mantenibilidad y robustez.

El scrum master o agile enabler facilita el sistema completo: ayuda a que el equipo no caiga ni en la confianza ciega en la IA ni en la desconfianza paralizante. También observa si el flujo genera cuellos de botella, especialmente en revisión e integración.

== Relación con Spec-Driven Development ==

[[Spec-Driven Development]] es una de las prácticas centrales del vibe engineering.

SDD aporta el método: antes de generar código, el equipo define una spec que guía el trabajo del agente. Vibe engineering aporta el contexto de uso: esa práctica forma parte de un carril robusto orientado a producción.

Dicho de forma simple:

* SDD responde a “¿cómo guiamos a la IA para construir con precisión?”.
* Vibe engineering responde a “¿cuándo y con qué rigor llevamos una solución asistida por IA a producción?”.

== Relación con la deuda técnica ==

Vibe engineering existe, en parte, para evitar que el vibe coding se convierta en [[Deuda técnica|deuda técnica]].

Un prototipo puede estar lleno de atajos aceptables si su objetivo es aprender. El problema aparece cuando esos atajos se conservan sin decisión explícita.

La deuda técnica no nace solo de escribir mal código. También nace de no distinguir entre:

* código para aprender;
* código para demostrar;
* código para operar;
* código para mantener.

Vibe engineering fuerza esa distinción.

== Métricas útiles ==

Algunas métricas ayudan a saber si el carril robusto está funcionando:

* '''Cycle time''': tiempo desde que se empieza la implementación hasta que llega a producción.
* '''Lead time''': tiempo desde que se identifica la necesidad hasta que se entrega valor.
* '''Tiempo de revisión humana por tarea IA''': permite detectar cuellos de botella reales.
* '''Ratio refactoring vs. código nuevo''': ayuda a vigilar salud técnica.
* '''Duplicación de código''': especialmente importante cuando se usa IA generativa.
* '''Defectos escapados a producción''': indica si los controles están siendo suficientes.
* '''Cambios rechazados en revisión''': señala problemas de spec, contexto o calidad del agente.

La métrica más peligrosa en este contexto es contar solo cuánto código genera la IA. Producir más código no equivale a entregar más valor.

== Señales de alarma ==

El vibe engineering está fallando cuando:

* el equipo genera specs largas pero poco útiles;
* las revisiones humanas se acumulan y bloquean el sprint;
* los agentes producen mucho código que luego se descarta;
* los tests los genera la IA y nadie los revisa;
* el equipo acepta código porque “pasa los tests”, aunque nadie entienda bien la solución;
* la Definition of Done se relaja para no frenar la velocidad aparente;
* el prototipo del carril rápido entra en producción sin reconstrucción ni revisión;
* cada cambio generado por IA introduce más deuda que valor.

Estas señales no indican que la IA no sirva. Indican que el sistema de trabajo alrededor de la IA no está suficientemente diseñado.

== Error frecuente ==

<div class="bok-aviso">
'''Creer que vibe engineering es vibe coding con más cuidado.''' Vibe engineering no consiste en pedirle a la IA el mismo código y revisarlo un poco más. Implica cambiar el sistema de trabajo: escribir specs, preparar contexto, dividir tareas, aplicar controles técnicos, estimar revisión humana y asumir responsabilidad sobre lo que llega a producción.
</div>

== Recursos ==

<div class="bok-recurso">
📄 [https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl]<span class="detalle">Artículo de Birgitta Böckeler sobre SDD, niveles de adopción y herramientas · Martin Fowler · 2025</span>
</div>

<div class="bok-recurso">
📊 [https://github.com/github/spec-kit Spec Kit]<span class="detalle">Toolkit open source para flujos de desarrollo dirigidos por especificación · GitHub</span>
</div>

<div class="bok-recurso">
📄 [https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity]<span class="detalle">Estudio sobre productividad, percepción de velocidad y coste de revisión con IA · METR · 2025</span>
</div>

<div class="bok-recurso">
📄 [https://www.veracode.com/blog/genai-code-security-report/ Insights from 2025 GenAI Code Security Report]<span class="detalle">Informe sobre vulnerabilidades en código generado por IA · Veracode · 2025</span>
</div>

== Referencias ==

* Becker, Joel; Rush, Nate; Barnes, Beth; Rein, David. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, METR.
* Böckeler, Birgitta. (2025). “Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl”, MartinFowler.com.
* GitHub. (2025). “Spec Kit”, GitHub.
* Scrum Manager. (2026). ''Scrum en equipos con IA''. Scrum Manager.
* Scrum Manager. (2026). ''SDD – Spec Driven Development en equipos ágiles''. Scrum Manager.
* Veracode. (2025). “Insights from 2025 GenAI Code Security Report”, Veracode.

== Véase también ==

<div class="bok-tags">
[[Vibe coding]] [[Spec-Driven Development]] [[Spec]] [[Definition of Done]] [[Deuda técnica]] [[Agente de IA]] [[Prompt engineering]] [[Integración continua]]
</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:Prácticas técnicas]]