User contributions for Mberne

12:0112:01, 20 May 2026 diff hist −45 Happy path →Véase también
12:0112:01, 20 May 2026 diff hist −30 Happy path No edit summary
12:0112:01, 20 May 2026 diff hist +3,359 N Happy path Created page with "{{Meta-bok|min=3}} <div class="bok-def"> El '''happy path''' es el flujo ideal de una funcionalidad: el escenario en el que el usuario sigue los pasos esperados, los datos son válidos, no hay errores y el sistema responde correctamente. Es útil para describir el comportamiento principal, pero no basta para validar una historia, spec o producto. </div> El happy path ayuda a entender cómo debería funcionar una funcionalidad cuando todo va bien. Es el primer camino qu..."
12:0012:00, 20 May 2026 diff hist +8 Always / Ask First / Never →Véase también current
12:0012:00, 20 May 2026 diff hist +2 Always / Ask First / Never →Relación con Definition of Done
12:0012:00, 20 May 2026 diff hist −24 Always / Ask First / Never No edit summary
11:5911:59, 20 May 2026 diff hist +4,558 N Always / Ask First / Never Created page with "{{Meta-bok|min=4}} <div class="bok-def"> '''Always / Ask First / Never''' es un sistema de límites para specs y agentes de IA. Define qué debe hacer siempre el agente, qué debe consultar antes de hacer y qué no debe hacer nunca. En Spec-Driven Development, ayuda a reducir ambigüedad, proteger decisiones críticas y evitar acciones no deseadas. </div> Cuando un agente de IA ejecuta trabajo, no basta con decirle qué debe construir. También hay que indicarle qu..."
11:5811:58, 20 May 2026 diff hist +6 Brownfield →Véase también current
11:5811:58, 20 May 2026 diff hist −24 Brownfield No edit summary
11:5811:58, 20 May 2026 diff hist +4,276 N Brownfield Created page with "{{Meta-bok|min=3}} <div class="bok-def"> '''Brownfield''' describe un proyecto que se desarrolla sobre un sistema, producto o codebase ya existente. En desarrollo con IA y Spec-Driven Development, los contextos brownfield requieren especial cuidado porque el agente debe respetar arquitectura, deuda técnica, contratos existentes y decisiones previas. </div> Un proyecto brownfield no empieza desde cero. Parte de algo que ya existe: código, usuarios, datos, integrac..."
11:5711:57, 20 May 2026 diff hist +8 Greenfield →Véase también
11:5611:56, 20 May 2026 diff hist +377 Greenfield →Recursos
11:5511:55, 20 May 2026 diff hist −185 Greenfield →Referencias
11:5511:55, 20 May 2026 diff hist +182 Greenfield →Recursos
11:5511:55, 20 May 2026 diff hist −30 Greenfield No edit summary
11:5511:55, 20 May 2026 diff hist +4,244 N Greenfield Created page with "{{Meta-bok|min=3}} <div class="bok-def"> '''Greenfield''' describe un proyecto que empieza desde cero o casi cero, sin una base técnica existente que condicione fuertemente la solución. En desarrollo con IA, los proyectos greenfield permiten explorar más rápido, pero también pueden generar deuda temprana si no se definen límites, arquitectura y criterios de calidad. </div> Un proyecto greenfield parte de un terreno limpio. No hay una codebase heredada que respeta..."
11:5411:54, 20 May 2026 diff hist −11 Spec →Véase también current
11:5411:54, 20 May 2026 diff hist −671 Spec →Recursos
11:5311:53, 20 May 2026 diff hist +2 Spec →Specs y Definition of Done
11:5311:53, 20 May 2026 diff hist −4 Spec →Specs y Definition of Ready para IA
11:5311:53, 20 May 2026 diff hist +18 Spec →Spec y Spec-Driven Development
11:5311:53, 20 May 2026 diff hist −24 Spec No edit summary
11:5211:52, 20 May 2026 diff hist +17,824 N Spec Created page with "{{Meta-bok|min=5}} <div class="bok-def"> Una '''spec''' es una especificación operativa que define qué debe construirse, bajo qué restricciones y cómo se verificará el resultado. En Spec-Driven Development, la spec funciona como puente entre la intención humana y la ejecución por un agente de IA: convierte una necesidad, historia o hipótesis en instrucciones claras, revisables y testeables. </div> En desarrollo asistido por IA, una spec no..."
11:5211:52, 20 May 2026 diff hist +171 WSJF No edit summary
11:5111:51, 20 May 2026 diff hist +177 ICE Score No edit summary current
11:5011:50, 20 May 2026 diff hist +1 MoSCoW →Recursos current
11:5011:50, 20 May 2026 diff hist +171 MoSCoW No edit summary
11:4811:48, 20 May 2026 diff hist +6 Gestión del contexto →IA y gestión del contexto current
11:4711:47, 20 May 2026 diff hist −30 Gestión del contexto No edit summary
11:4611:46, 20 May 2026 diff hist +5,227 N Gestión del contexto Created page with "{{Meta-bok|min=4}} <div class="bok-def"> La '''gestión del contexto''' o ''context management'' es la práctica de seleccionar, preparar y mantener la información que un modelo o agente de IA necesita para producir outputs relevantes. En equipos ágiles con IA, equivale a dar a la IA el onboarding necesario: producto, arquitectura, decisiones, criterios, restricciones y ejemplos. </div> La IA no trabaja bien solo porque el modelo sea potente. Trabaja..."
11:4211:42, 20 May 2026 diff hist +6 Tarea R&I →Véase también current
11:4211:42, 20 May 2026 diff hist +181 Tarea R&I →Recursos
11:4111:41, 20 May 2026 diff hist −24 Spec-Driven Development (SDD) →Véase también
11:4111:41, 20 May 2026 diff hist −860 Spec-Driven Development (SDD) →Recursos
11:4011:40, 20 May 2026 diff hist +2 Tarea R&I →Relación con Scrum
11:4011:40, 20 May 2026 diff hist −36 Tarea R&I →Véase también
11:4011:40, 20 May 2026 diff hist +210 Tarea R&I →Recursos
11:3811:38, 20 May 2026 diff hist −185 Tarea R&I →Referencias
11:3811:38, 20 May 2026 diff hist −5 Tarea R&I →Recursos
11:3811:38, 20 May 2026 diff hist +4,421 N Tarea R&I Created page with "{{Meta-bok|min=3}} Una '''tarea R&I''' es una tarea de revisión e integración dedicada a validar, corregir e incorporar outputs generados por IA. En equipos ágiles con IA, debe estimarse de forma explícita porque el coste de generar código, textos o pruebas puede ser bajo, pero el coste de revisarlos e integrarlos puede ser alto. En equipos que usan agentes de IA, una parte del trabajo puede producirse muy rápido: código, tests, documentación, p..."
11:3311:33, 20 May 2026 diff hist −12 Roadmap Now-Next-Later →Véase también current
11:3311:33, 20 May 2026 diff hist −846 Roadmap Now-Next-Later →Recursos
11:3311:33, 20 May 2026 diff hist −578 Outcome over output →Recursos current
11:3311:33, 20 May 2026 diff hist −585 Output →Recursos current
11:3311:33, 20 May 2026 diff hist −646 Outcome →Recursos current
11:3111:31, 20 May 2026 diff hist −30 Roadmap Now-Next-Later No edit summary
11:3011:30, 20 May 2026 diff hist +14,361 N Roadmap Now-Next-Later Created page with "{{Meta-bok|min=5}} <div class="bok-def"> Un '''Roadmap Now-Next-Later''' es un formato de roadmap de producto que organiza prioridades en tres horizontes: lo que se trabaja ahora, lo que probablemente vendrá después y las oportunidades futuras. A diferencia de un roadmap basado en fechas cerradas, comunica dirección, foco y nivel de incertidumbre sin convertir cada iniciativa en una promesa rígida. </div> El Roadmap Now-Next-Later es una alternativa a los roadmaps..."
11:3011:30, 20 May 2026 diff hist −111 Outcome over output No edit summary
11:3011:30, 20 May 2026 diff hist −30 Outcome over output No edit summary
11:2911:29, 20 May 2026 diff hist +13,736 N Outcome over output Created page with "{{Meta-bok|min=5}} <div class="bok-def"> '''Outcome over output''' es el principio de priorizar el impacto generado sobre la mera entrega de artefactos. En gestión ágil y producto, significa evaluar el éxito por cambios observables en usuarios, negocio o aprendizaje, no solo por funcionalidades, tareas o releases completadas. </div> Outcome over output no significa dejar de entregar. Significa recordar que la entrega es un medio, no el fin. Un equipo orientado a ou..."

20 May 2026