El ciclo de desarrollo de software suele explicarse como una secuencia de fases: analizar, diseñar, implementar, probar y desplegar. Esa forma de contarlo sigue siendo útil, pero oculta uno de los puntos donde más se deterioran los proyectos reales: la transición entre fases.
Muchas veces el problema no está en que análisis, arquitectura, desarrollo o QA trabajen mal por separado. El problema aparece cuando el conocimiento que produce una fase llega incompleto, ambiguo o deformado a la siguiente.
KEEL no propone otra lista de fases. Propone una forma de gobernar las transiciones entre fases.
KEEL es mi metodología personal desarrollada para estructurar el ciclo de desarrollo software desde la intención del producto hasta la validación de lo construido. Su tesis es sencilla: cada fase puede trabajar con libertad, pero debe producir una salida que la siguiente fase pueda recibir, entender, derivar y validar.
Desde esta perspectiva, KEEL propone mantener conectadas la intención, la especificación, el modelo técnico, la planificación, la ejecución y la validación mediante artefactos, contratos, trazabilidad y evidencia.
El problema actual no es elegir entre cascada, agilidad, DevOps o desarrollo asistido por IA. La cuestión es cómo mantener continuidad metodológica cuando el conocimiento cambia de manos, de forma y de nivel de detalle a lo largo del ciclo.
KEEL parte de esa preocupación. No lo entiendo como una ruptura con la ingeniería del software anterior, sino como un paso natural en su evolución. Conserva la disciplina de las metodologías clásicas, acepta la iteración de los enfoques modernos, se beneficia de la automatización y abre la puerta a la colaboración con agentes de inteligencia artificial. Pero su núcleo sigue siendo metodológico: artefactos, contratos, trazabilidad, evidencia y transición gobernada entre fases.
El ciclo de desarrollo no falla solo por ejecutar mal
Durante años hemos explicado el desarrollo de software como si el reto principal estuviera en pasar correctamente de requisitos a código. Esa explicación tiene parte de verdad, pero simplifica demasiado.
En proyectos reales, muchas desviaciones no nacen en la implementación. Nacen antes:
- Cuando una conversación se interpreta como requisito.
- Cuando una observación se convierte en decisión sin pasar por análisis.
- Cuando el modelo técnico introduce restricciones que nunca vuelven a la especificación.
- Cuando el backlog se llena de tareas que solo entiende quien estuvo en una reunión.
- Cuando las pruebas validan que algo funciona, pero no que funciona como debía funcionar.
La ingeniería del software lleva décadas intentando ordenar este problema. Roger S. Pressman e Ian Sommerville han explicado el proceso de software como un conjunto de actividades conectadas: comunicación, planificación, modelado, construcción, validación y evolución. Esa visión sigue siendo válida porque recuerda que el software no se construye solo programando.
Winston Royce, con el enfoque que después se asoció a la cascada, puso sobre la mesa la necesidad de no saltar directamente a construir sin entender antes qué se quiere hacer. Barry Boehm, con el modelo en espiral, introdujo una visión más realista basada en iteración y gestión del riesgo. Frederick Brooks explicó en No Silver Bullet que la dificultad esencial del software está en comprender y representar la complejidad del problema, no solo en escribir código. David Parnas defendió la modularidad como forma de controlar conocimiento y dependencias, no como simple reparto de archivos.
KEEL recoge esas intuiciones, pero las lleva a una preocupación muy concreta: cómo mantener continuidad metodológica entre fases cuando el conocimiento madura por capas y cuando cada fase puede ser trabajada por personas, equipos, proveedores o agentes distintos.
El desarrollo de software no necesita solo mejores tareas. Necesita mejores transiciones.
Tres ideas para entender KEEL
Para no convertir la explicación en una lista interminable de fases, conviene reducir KEEL a tres ideas principales.
| Idea | Qué significa | Por qué importa |
|---|---|---|
| Cadena de transformación del conocimiento | No se pasa de “idea” a “código”, sino de necesidad a observación, especificación, modelo, trabajo ejecutable, implementación, evidencia y validación. | Permite entender el desarrollo como maduración progresiva del conocimiento. |
| Flexibilidad interna, salida gobernada | Cada fase puede usar técnicas distintas, pero debe producir un artefacto de salida con contrato. | Evita tanto la rigidez metodológica como la informalidad. |
| Coordinación metodológica | La coordinación no depende solo de reuniones, sino de artefactos que conectan fases. | Permite trabajar con equipos, tiempos y niveles de contexto distintos. |
El ciclo de desarrollo software como cadena de transformación del conocimiento
La primera idea es que KEEL entiende el desarrollo como una cadena de transformación del conocimiento.
No se pasa de “idea” a “código”. Se pasa de necesidad a observación, de observación a conocimiento estructurado, de conocimiento estructurado a especificación, de especificación a modelo técnico, de modelo técnico a trabajo ejecutable, de trabajo ejecutable a implementación, de implementación a evidencia y de evidencia a validación.
KEEL es flexible pero exige cumplir contratos
La segunda idea es que KEEL es flexible en cómo se trabaja dentro de cada fase, pero estricto en los artefactos que permiten salir de ella.
No impone una única forma de identificar actores, derivar reglas, redactar requisitos, modelar arquitectura o crear backlog. Propone caminos, criterios y prácticas razonables, pero entiende que cada organización, producto y equipo tiene condicionantes distintos.
Lo que no deja abierto es la salida metodológica. Si una fase debe producir un artefacto, ese artefacto debe cumplir un contrato. Debe representar un tipo de conocimiento concreto, tener límites claros, mantener trazabilidad y habilitar la siguiente fase.
La coordinación operativa no es suficiente
La tercera idea es que KEEL busca coordinación metodológica, no solo coordinación operativa.
No presupone que todo lo haga el mismo equipo, en la misma sala, en la misma empresa o en la misma ventana temporal. Al contrario: asume que en proyectos reales puede haber negocio, análisis, arquitectura, desarrollo, QA, seguridad, operaciones, proveedores y mantenimiento participando en momentos distintos.
La coordinación no puede depender solo de reuniones. Tiene que quedar sostenida por artefactos que permitan que una fase entienda la salida de la anterior y pueda continuar sin reconstruir la intención desde cero.
KEEL es una metodología pensada para humanos en la era de la IA
Hay un matiz importante.
KEEL no debe presentarse como una metodología para que agentes de inteligencia artificial desarrollen software. Esa lectura es demasiado estrecha.
KEEL es una metodología de desarrollo de software pensada para equipos humanos en la era de la inteligencia artificial.
La diferencia importa.
Los equipos humanos siguen siendo responsables de entender el problema, tomar decisiones, interpretar contexto organizativo, priorizar, negociar alcance, validar intención y ejercer criterio técnico. La inteligencia artificial puede ayudar mucho en tareas de extracción, análisis, detección de inconsistencias, generación de propuestas, formalización de artefactos, implementación acotada o producción de evidencias.
La IA como ejecutora, no como decididora
Pero la IA no sustituye la responsabilidad metodológica.
La IA acelera ejecución, no sustituye responsabilidad.
Este punto es clave porque muchas conversaciones actuales sobre desarrollo asistido por IA se centran demasiado en la generación de código. Es comprensible, porque es lo más visible. Pero si lo que aceleramos es una cadena de trabajo mal gobernada, no obtenemos mejor ingeniería. Obtenemos errores más rápidos, más convincentes y más difíciles de detectar.
El problema ya existía antes de la IA. Los equipos humanos también inferían, rellenaban huecos, tomaban decisiones tácitas y confundían conversaciones con acuerdos estables. La IA simplemente amplifica ese riesgo porque puede convertir una ambigüedad en texto, artefacto o código con mucha velocidad.
Por eso KEEL se vuelve especialmente relevante en esta etapa. No porque la metodología dependa de agentes, sino porque necesitamos un sistema de gobierno más explícito cuando parte del trabajo puede ser asistido, acelerado o ejecutado por ellos.
Un equipo humano puede aplicar KEEL sin agentes. Puede elicitar fuentes, estabilizar conocimiento, especificar requisitos, modelar técnicamente, planificar tareas, ejecutar cambios, producir evidencias y validar resultados. La metodología sigue teniendo sentido.
Lo que ocurre es que, si además participan agentes de IA, estos ya no actúan como herramientas libres. Operan dentro de un método que les dice qué fuente manda, qué artefacto deben consultar, qué pueden derivar, qué no pueden inventar, qué tarea pueden ejecutar y qué evidencia deben producir.
La aportación práctica: contratos de artefactos
La parte más importante de KEEL no está en decir que existen fases. Eso ya lo sabemos.
Lo importante es cómo se conectan esas fases.
En muchas organizaciones, cada fase produce algo, pero no siempre produce algo que la siguiente fase pueda usar bien:
- El análisis produce documentos narrativos.
- Arquitectura produce diagramas o decisiones técnicas.
- Producto produce tickets.
- Desarrollo produce código.
- QA produce casos de prueba.
- Operaciones produce runbooks o incidencias.
El problema no es que existan esos artefactos. El problema es que muchas veces no comparten una lógica metodológica común.
| Artefacto habitual | Riesgo cuando no tiene contrato |
|---|---|
| Documento de análisis | Puede ser correcto para quien lo escribió, pero inútil para derivar tareas. |
| Backlog | Puede organizar sprints, pero no reconstruir la intención funcional. |
| Diagrama técnico | Puede reflejar una arquitectura, pero no explicar qué requisito o restricción la justifica. |
| Test o caso de prueba | Puede comprobar una salida, pero no decir qué regla de negocio protege. |
KEEL refuerza de forma estricta los contratos de artefactos porque entiende que ahí se juega la continuidad del ciclo.
Qué es un artefacto KEEL
En KEEL, un artefacto no es un documento decorativo ni una entrega administrativa. Es una pieza de conocimiento con una función metodológica concreta: representar una parte del producto de forma suficientemente clara para que otra fase pueda usarla sin reconstruir la intención desde cero.
Un artefacto debe responder, al menos, a preguntas como estas:
- Qué representa.
- Qué puede contener.
- Qué no debe contener.
- De dónde deriva.
- Qué habilita después.
- Qué relaciones de trazabilidad mantiene.
- Qué incertidumbre deja visible.
- En qué fase puede usarse.
- Bajo qué condiciones permite avanzar.
Esto puede sonar formal, pero es profundamente práctico.
No buscamos pureza: buscamos sostenibilidad.
Un contrato de artefacto evita que la siguiente fase tenga que adivinar qué recibió. Permite que un equipo de modelado entienda qué viene de especificación. A su vez, hace que desarrollo entienda qué tarea deriva de qué regla, contrato o decisión técnica. Permite que QA valide contra criterios explícitos. Permite que mantenimiento reconstruya meses después por qué existe un comportamiento.
El contrato no está para imponer burocracia. Está para evitar pérdida de intención.
Flexibilidad dentro de cada fase
Una metodología demasiado rígida termina fallando porque intenta controlar realidades que no conoce.
No todos los equipos trabajan igual. Ni todos los productos tienen el mismo dominio. No todos los sistemas tienen el mismo riesgo. No todos los proyectos necesitan el mismo nivel de formalización en cada punto.
Por eso KEEL no debería interpretarse como una receta cerrada para ejecutar cada fase de una única manera.
| Actividad | Técnicas posibles |
|---|---|
| Elicitación | Entrevistas, revisión documental, análisis de procesos, talleres, revisión de incidencias, lectura de contratos o inspección del comportamiento actual. |
| Identificación de actores | Stakeholders, casos de uso, journeys, mapas de proceso o eventos de dominio. |
| Derivación de reglas | Políticas internas, restricciones legales, decisiones de negocio, comportamiento observado, casos límite o errores históricos. |
| Modelado técnico | Domain-Driven Design, arquitectura hexagonal, arquitectura modular, clean architecture, microservicios, componentes frontend, pipelines de datos o enfoques más simples. |
| Creación de backlog | Historias de usuario, tareas técnicas, slices verticales, casos de uso, unidades de entrega o paquetes de trabajo. |
Todo eso es flexible. Lo que no es flexible es que el resultado de una fase quede en una forma ambigua, no trazable o imposible de usar por la siguiente.
Flexibilidad equilibrada: libertad en cada fase el Ciclo de Desarrollo Software, rígido en sus transiciones
La lógica puede resumirse así:
- Trabajo interno flexible.
- Artefacto de salida gobernado.
- Transición metodológica fiable.
Este equilibrio evita dos extremos.
El primer extremo es la metodología rígida que intenta imponer una técnica única para todos los casos. Ese camino suele fracasar porque la realidad del proyecto termina desbordando el método.
El segundo extremo es la informalidad donde cada equipo documenta como puede, planifica como quiere y valida como recuerda. Ese camino funciona solo mientras el contexto es pequeño, estable y compartido. En cuanto entran más equipos, más tiempo, más deuda, más rotación o más automatización, la continuidad se rompe.
KEEL intenta situarse en medio: libertad razonable dentro de la fase, rigor contractual en la salida.
Las fases del ciclo según KEEL
Desde esta perspectiva, el ciclo de desarrollo de software puede organizarse en cuatro grandes calles de trabajo:
- Especificación.
- Modelado.
- Planificación.
- Ejecución y validación.
Esta representación no debe leerse como una cascada irreversible. KEEL no presupone que todo se define una vez, se modela una vez, se planifica una vez y se ejecuta una vez.
Lo entiende como un sistema de calles conectadas.
| Calle | Responsabilidad principal | Salida esperada |
|---|---|---|
| Especificación | Convertir fuentes reales en conocimiento gobernado. | Requisitos, reglas, escenarios, criterios, incertidumbres, etc. |
| Modelado | Traducir la especificación a una forma técnica viable. | Capas de arquitectura, componentes UI, casos de uso, agregados de dominio, etc. |
| Planificación | Convertir conocimiento en trabajo ejecutable. | Stories y tareas trazables con alcance claro, dependencias y criterios de aceptación. |
| Ejecución y validación | Construir, evidenciar, revisar y realinear. | Implementación, evidencias, validación y cierre o realineación. |
Cada calle tiene una responsabilidad donde cada una puede tener técnicas internas distintas. Cada calle debe producir artefactos compatibles con el método y cada transición debe estar gobernada. Toda vuelta atrás debe dejar rastro.
La pregunta no es solo “en qué fase estamos”. La pregunta correcta es:
¿En qué calle estamos, qué contrato aplica, qué salida necesitamos y qué transición queda justificada?
Especificación: convertir fuentes reales en verdad operativa
La primera fase es la especificación. Su objetivo no es escribir requisitos cuanto antes. Su objetivo es transformar fuentes reales en conocimiento gobernado.
En muchos proyectos se habla de requisitos como si estuvieran esperando a ser capturados. La realidad suele ser menos ordenada. Lo que tenemos al principio son documentos, conversaciones, procesos, decisiones previas, sistemas heredados, restricciones de negocio, incidencias, contratos, expectativas y lagunas.
KEEL trata todo eso como materia prima.
¿Qué se contempla en la fase de especicación?
Dentro de la especificación podemos distinguir tres movimientos:
- Elicitación o extracción.
- Análisis o estabilización.
- Especificación formal.
La elicitación captura conocimiento desde fuentes reales. Aquí observamos, registramos y separamos señales relevantes. Pueden aparecer actores, entradas, salidas, reglas candidatas, restricciones, entidades, procesos, errores, dependencias o preguntas abiertas.
La clave es no confundir observación con decisión.
Que una fuente diga algo no significa automáticamente que eso sea una regla estable del sistema.
Puede ser una preferencia, una excepción, una contradicción, una deuda histórica o una interpretación local.
Después viene el análisis o estabilización. Esta parte consiste en ordenar, clasificar, consolidar, eliminar duplicidades semánticas, detectar conflictos y mantener visible lo que todavía no está claro.
Aquí el conocimiento empieza a madurar. Todavía no estamos implementando. Tampoco estamos diseñando técnicamente. Estamos haciendo que la información dispersa pueda convertirse en una base fiable para especificar.
Finalmente aparece la especificación formal. Aquí el conocimiento estabilizado se expresa en artefactos operativos: requisitos, reglas, procesos, contratos, escenarios, criterios de aceptación, planes de validación o cualquier pieza necesaria según el caso.
La especificación formal debe permitir responder:
- Qué debe hacer el sistema.
- Bajo qué reglas.
- Con qué entradas y salidas.
- Qué errores contempla.
- Qué comportamiento se espera.
- Qué incertidumbre sigue abierta.
- Qué evidencia permitirá validar después.
El valor de esta fase no está en producir documentación por producir documentación. Está en construir una base de verdad operativa.
Una especificación que no sirve para modelar, planificar, ejecutar o validar no está gobernando el desarrollo. Solo lo está acompañando.
Modelado: traducir la especificación a una forma técnica viable
La segunda fase es el modelado.
Esta fase es imprescindible y suele estar mal contada cuando explicamos el ciclo de desarrollo. Muchas veces se pasa de “tenemos requisitos” a “vamos a implementar”, como si entre ambos mundos no existiera una transformación técnica compleja.
El modelado es precisamente esa transformación.
Su función es convertir una especificación suficientemente madura en una forma técnica viable, mantenible y verificable.
¿Qué se contempla en la fase de modelado?
Aquí entran decisiones sobre arquitectura, stack tecnológico, módulos, bounded contexts, servicios, componentes, adapters, persistencia, APIs, colas, eventos, integraciones, infraestructura, reglas técnicas, restricciones de runtime, convenciones del repositorio y estrategia técnica de validación.
KEEL no impone una arquitectura concreta.
Puede convivir con Domain-Driven Design, arquitectura hexagonal, arquitectura modular, clean architecture, microservicios, monolitos bien estructurados o enfoques más pragmáticos. La metodología no se casa con una solución técnica universal.
Lo que exige es que las decisiones técnicas relevantes no queden en la cabeza de una persona, en una conversación o en una convención implícita.
| Si ocurre esto… | Entonces debe pasar esto… |
|---|---|
| Una integración externa condiciona el diseño. | La restricción debe quedar visible. |
| Un adapter existe para proteger una frontera. | Su función debe entenderse. |
| Una decisión de persistencia afecta a reglas funcionales. | La relación debe trazarse. |
| Una restricción de runtime condiciona el backlog. | Debe llegar a planificación. |
| Una regla técnica limita la implementación. | Debe conocerse antes de ejecutar. |
El modelado también puede revelar problemas en la especificación.
Esto es normal. Al bajar una intención funcional a una forma técnica, aparecen tensiones: una regla no estaba bien definida, una frontera no era tan clara, una integración impone un límite, un dato no existe, una operación no puede ser transaccional como se esperaba.
En un proceso débil, esas tensiones se resuelven de forma local y silenciosa.
En KEEL, deben provocar realineación. La especificación puede cambiar, el modelo puede ajustarse, una decisión puede registrarse o una incertidumbre puede bloquear la transición.
Esta es una de las formas en que KEEL se mantiene pegado a la realidad. No finge que todo se sabe al principio. Pero tampoco permite que los descubrimientos técnicos se conviertan en decisiones invisibles.
Planificación: convertir conocimiento en trabajo ejecutable
La tercera fase es la planificación. Planificar no es hacer una lista de cosas pendientes. Esa es una versión demasiado pobre del concepto.
Desde KEEL, planificar significa transformar especificación y modelo en trabajo ejecutable, trazable y validable. Una tarea debería poder responder:
- Qué unidad implementable afecta.
- Qué comportamiento construye o modifica.
- Qué requisito, regla, contrato o decisión técnica la justifica.
- Qué dependencias tiene.
- Qué criterios de aceptación aplican.
- Qué evidencias serán necesarias.
- Qué incertidumbre la condiciona.
- Qué alcance no debe sobrepasar.
Backlog y fuente de la verdad
Esto cambia la naturaleza del backlog. El backlog no es la fuente de verdad del sistema. Es una derivación operativa de esa verdad.
Cuando el backlog sustituye a la especificación, el proyecto se empobrece. Los tickets empiezan a mezclar intención, solución, prioridad, conversación, deuda y detalles técnicos. Durante un tiempo parece práctico, pero a medio plazo se vuelve difícil saber qué se decidió, por qué y contra qué debe validarse.
KEEL separa responsabilidades:
| Elemento | Responsabilidad |
|---|---|
| Especificación | Define qué vamos a constuir y qué debe cumplirse. |
| Modelado | Define cómo lo vamos a construir u cómo se organizará técnicamente. |
| Planificación | Define qué trabajo puede ejecutarse. |
| Ejecución | Materializa. |
| Validación | Contrasta y certifica. |
El backlog puede adoptar formas distintas: historias de usuario, tareas técnicas, slices verticales, casos de uso, unidades de entrega o paquetes de trabajo. La metodología no necesita imponer una única taxonomía para todos los equipos.
Lo que exige es que cada unidad de trabajo tenga suficiente contexto para ser ejecutada sin inventar.
Una tarea como “hacer login” puede valer como recordatorio interno en un equipo pequeño, pero es débil como pieza metodológica. No dice qué comportamiento incluye, qué reglas aplican, qué errores contempla, qué contrato se toca, qué evidencia cerrará el trabajo ni qué queda fuera.
En KEEL, una tarea debe ser una puerta de entrada a ejecución, no una nota mental compartida.
Ejecución y validación: construir, evidenciar y realinear
La cuarta fase agrupa ejecución y validación.
Aquí el sistema se materializa, pero KEEL no considera que algo esté terminado solo porque haya código nuevo, una rama mergeada o una prueba pasando.
La ejecución sigue una secuencia gobernada:
- Trabajo registrado.
- Preparación.
- Implementación.
- Evidencia.
- Revisión.
- Validación.
- Cierre o realineación.
Antes de ejecutar, debe existir trabajo registrado, alcance claro, contexto suficiente, artefactos relevantes disponibles y ausencia de incertidumbres críticas que invaliden el paso.
Durante la ejecución, el operador —humano o agente— debe respetar el alcance. No debe inventar comportamiento no especificado, ignorar reglas activas ni introducir decisiones de alto impacto sin realineación.
Esto no significa que el desarrollador no piense. Al contrario. Significa que cuando detecta algo relevante, lo trata como parte del sistema y no como un ajuste privado.
| Si aparece… | La respuesta metodológica es… |
|---|---|
| Una duda funcional | Volver a especificación. |
| Una restricción técnica | Volver a modelado. |
| Un cambio de alcance | Volver a planificación. |
| Una divergencia | Abrir realineación. |
| Falta de evidencia suficiente | Bloquear el cierre. |
Validar la evidencia cierra el ciclo de desarrollo
La evidencia es fundamental.
Puede tomar muchas formas: pruebas automatizadas, resultados de ejecución, logs, capturas, validaciones contractuales, revisión estructural, comprobaciones manuales justificadas o cualquier otro soporte adecuado.
Lo importante es que sostenga una afirmación verificable.
No basta con decir “está hecho”. Hay que poder defender qué se hizo, contra qué se hizo y cómo se sabe que cumple.
La validación, además, no debe confundirse con probar que el código funciona. Esa es solo una parte.
La pregunta correcta es:
¿Funciona como debía funcionar según la verdad vigente del sistema?
Un cambio puede compilar, pasar pruebas unitarias y estar bien escrito, pero seguir siendo incorrecto si implementa una interpretación equivocada, ignora una regla de negocio o rompe una intención de producto.
Por eso KEEL conecta evidencia con especificación, modelo, tarea y criterio de aceptación.
La validación no debería cerrar contra percepción o sensación de avance. Debería cerrar contra la verdad operativa vigente: especificación, modelo, tarea, criterio de aceptación y evidencia disponible.
Las calles del método
Una de las ideas más útiles de KEEL es pensar el desarrollo como calles conectadas. El flujo normal puede parecer lineal:
- Especificación.
- Modelado.
- Planificación.
- Ejecución y validación.
Pero en un proyecto real aparecen retornos legítimos, por ejemplo.
| Situación | Retorno metodológico |
|---|---|
| Ejecución detecta una laguna funcional. | Vuelve a especificación, se actualiza el artefacto afectado, se replanifica si procede y se retoma ejecución. |
| Modelado descubre una restricción técnica. | Se registra la decisión, se ajusta el contrato afectado, se revisa el backlog y se ejecuta con nuevo contexto. |
| Validación detecta una divergencia. | Se abre realineación, se corrige implementación o especificación, se produce nueva evidencia y se valida de nuevo. |
Esto es importante porque evita una falsa alternativa.
No tenemos que elegir entre cascada rígida e improvisación ágil. Podemos aceptar que el trabajo vuelve atrás, pero exigir que vuelva atrás con trazabilidad.
KEEL no intenta impedir el movimiento. Intenta gobernarlo.
Cada calle tiene reglas y cada transición debe estar justificada. Toda salida debe cumplir contrato. Cada divergencia debe tratarse. y cada avance debe sostenerse.
Un ejemplo mínimo: una aplicación GTD
Pensemos en una aplicación sencilla de GTD para gestionar captura, proyectos, acciones siguientes, contextos y revisión semanal.
Un enfoque débil podría crear directamente tareas como:
- Crear inbox.
- Añadir proyectos.
- Crear acciones.
- Filtrar por contexto.
- Hacer revisión semanal.
No está mal como lista inicial, pero no es suficiente para sostener el ciclo completo.
Desde KEEL, el recorrido sería distinto.
| Fase | Aplicación al ejemplo GTD |
|---|---|
| Especificación | Extraer qué significa capturar una idea, qué diferencia hay entre bandeja de entrada y acción siguiente, qué convierte algo en proyecto y qué papel tienen contextos, energía y revisión semanal. |
| Estabilización | Resolver o dejar visibles dudas: si una acción sin proyecto puede existir, si los contextos son etiquetas libres o catálogo controlado, si la revisión semanal cambia estados o solo genera recomendaciones. |
| Formalización | Producir reglas, requisitos, criterios de aceptación y contratos. Por ejemplo: un elemento capturado en inbox no debe considerarse acción siguiente hasta haber sido aclarado. |
| Modelado | Decidir cómo representar técnicamente inbox, proyectos, acciones y contextos. Puede que el modelo de dominio distinga CaptureItem, Project y NextAction. |
| Planificación | Formular tareas trazables, por ejemplo: implementar la captura de elementos en inbox según el contrato correspondiente, con persistencia, validación mínima, estados permitidos y evidencia esperada. |
| Ejecución y validación | Comprobar que la implementación no permite saltarse reglas clave, como marcar directamente un elemento capturado como acción siguiente si antes debe pasar por aclarado. |
Este ejemplo es pequeño, pero muestra el punto: KEEL no añade ceremonia por gusto. Añade estructura para que cada fase pueda sostener a la siguiente. Para cada fase o artefactos podrás encontrar artículos que explican el detalle y las razones de cada uno.
Coordinación metodológica entre equipos
En proyectos reales, pocas veces todo el ciclo lo ejecuta un único grupo compacto de personas con el mismo contexto.
Puede haber:
- Negocio definiendo objetivos.
- Un equipo de análisis trabajando requisitos.
- Arquitectura tomando decisiones técnicas.
- Un proveedor desarrollando.
- QA validando.
- Seguridad revisando.
- Operaciones desplegando.
- Mantenimiento recibiendo el sistema meses después.
Esos equipos no siempre trabajan juntos. No siempre están en la misma empresa. Ni siempre coinciden en el tiempo. No siempre comparten la misma cultura técnica.
Por eso la coordinación no puede depender solo de reuniones, buena voluntad o documentación narrativa.
Necesitamos coordinación metodológica.
Esto significa que cada equipo debe saber:
- Qué recibe.
- Qué debe producir.
- Qué contrato debe cumplir.
- Qué incertidumbre debe dejar visible.
- Qué decisiones ha tomado.
- Qué fase queda habilitada por su salida.
Esta es una justificación práctica de KEEL.
Los contratos de artefactos no existen para controlar a los equipos. Existen para permitir que equipos diferentes trabajen sobre una misma visión sin tener que estar permanentemente sincronizados por conversación.
| Equipo o rol | Qué debería poder reconstruir |
|---|---|
| Desarrollo | La especificación, aunque no haya participado en la elicitación. |
| Arquitectura | Las reglas y restricciones, aunque no haya estado en las entrevistas. |
| QA | Los criterios claros contra los que validar, aunque no haya escrito los requisitos. |
| Mantenimiento | Las decisiones relevantes, aunque no haya vivido el proyecto. |
En ese sentido, KEEL no busca que todos trabajen igual. Busca que todos puedan conectar su trabajo a una misma cadena metodológica.
Qué toma KEEL de las metodologías anteriores
KEEL no aparece en el vacío.
| Tradición o referencia | Qué toma KEEL | Qué añade KEEL |
|---|---|---|
| Enfoques secuenciales | La disciplina de no ejecutar sin una base suficiente. | No presupone cierre absoluto al inicio, sino transiciones gobernadas. |
| Boehm | La importancia de iterar y gestionar riesgo. | Exige que la iteración actualice artefactos y deje rastro. |
| Brooks | Comprender el problema como parte esencial del trabajo. | Convierte esa comprensión en artefactos operables. |
| Parnas | Fronteras y ocultación de información. | Lleva esa idea al plano metodológico mediante unidades implementables, contratos y trazabilidad. |
| Ingeniería de requisitos | Elicitación, análisis, especificación, validación y gestión del cambio. | Conecta esos elementos con modelado, planificación, ejecución y evidencia. |
| Agilidad | Adaptación y feedback. | No acepta que la flexibilidad se convierta en informalidad. |
| DevOps | Flujo continuo, automatización y validación frecuente. | Pregunta no solo si el sistema funciona, sino si funciona de acuerdo con la verdad vigente. |
| Specification-Driven Development | Construir desde especificaciones. | Pregunta cómo nacen esas especificaciones, qué contratos cumplen y cómo evolucionan. |
SDD nos recuerda que la especificación importa. KEEL añade una pregunta anterior: cómo producir, validar y conectar esa especificación con el resto del ciclo de desarrollo.
Nuestra lectura es que KEEL no sustituye esas tradiciones. Las reordena alrededor de un problema actual: cómo sostener continuidad metodológica en un ciclo donde el conocimiento cambia, los equipos se fragmentan y la IA puede acelerar tanto la calidad como la deriva.
Qué hacer ahora
Si tuviera que aterrizar esta visión en un equipo real, empezaría por algo muy concreto:
- Identificar qué artefactos existen hoy y cuáles solo viven como conversación, tickets o memoria informal.
- Revisar qué transiciones entre fases se rompen con más frecuencia: análisis a arquitectura, arquitectura a backlog, backlog a ejecución o ejecución a validación.
- Definir contratos mínimos para los artefactos críticos, aunque al principio sean simples.
- Separar explícitamente observación, decisión, especificación, modelado, planificación y ejecución.
- Exigir evidencia suficiente antes de considerar cerrado cualquier trabajo relevante.
No hace falta empezar con un sistema perfecto.
De hecho, intentar implantar una metodología completa de golpe suele producir rechazo. Es mejor empezar por el punto donde más se pierde intención:
- En algunos equipos será la especificación.
- En otros, el paso a arquitectura.
- En otros, el backlog.
- En otros, la validación.
- En otros, la falta de trazabilidad entre todo lo anterior.
KEEL tiene sentido cuando se aplica para resolver una pérdida real de continuidad, no cuando se introduce como una capa estética de documentación.
Implicaciones para el equipo
Aplicar KEEL exige cambiar algunas costumbres.
| Costumbre que conviene revisar | Cambio metodológico necesario |
|---|---|
| Tratar el backlog como centro del universo. | Entenderlo como derivación operativa, no como única fuente de verdad. |
| Cerrar incertidumbre por comodidad. | Registrar la incertidumbre y decidir si bloquea o si permite avanzar con límites claros. |
| Mezclar fases sin darse cuenta. | Separar observación, decisión, diseño y planificación cuando aparezcan juntas en una conversación. |
| Considerar preparada una tarea porque alguien la entiende. | Exigir contexto, alcance, reglas y criterios suficientes. |
| Esperar que la IA corrija un mal proceso. | Asumir que la IA acelera el proceso existente, para bien o para mal. |
Este artículo deja abierta una continuación necesaria: bajar los contratos a ejemplos concretos sin convertirlos todavía en plantillas de implementación. Cómo debería verse un artefacto de especificación, cómo se expresa un modelo técnico, cómo se formula una tarea ejecutable, cómo se registra una evidencia y cómo se gestiona una realineación son preguntas importantes, pero conviene tratarlas en piezas posteriores.
Cierre
El ciclo de desarrollo de software no necesita otra forma bonita de nombrar fases. Necesita una forma más robusta de conectar unas fases con otras.
Esa es, para mí, la aportación principal de KEEL.
KEEL entiende el desarrollo como un proceso de maduración del conocimiento y materialización controlada del sistema. No se limita a decir que hay que especificar, diseñar, implementar y probar. Pregunta qué conocimiento existe, qué falta, qué artefacto lo representa, qué contrato cumple, qué fase habilita y qué evidencia permite cerrar.
Su enfoque es práctico porque acepta cómo funcionan los proyectos reales: equipos distintos, tiempos distintos, herramientas distintas, niveles de contexto distintos y, cada vez más, colaboración con agentes de inteligencia artificial.
Pero no entrega el gobierno del proceso a la herramienta, al ticket, al documento libre, al prompt o a la memoria del equipo.
Lo entrega a una cadena de artefactos contractuales.
Por eso KEEL puede ser flexible sin volverse informal. Puede aceptar iteración sin perder trazabilidad y aprovechar IA sin ponerla en el centro. Puede coordinar equipos sin exigir que todos trabajen igual y permitir cambios sin dejar que se conviertan en deriva.
La idea de fondo es sencilla, pero exigente:
Cada fase puede tener libertad para trabajar como necesite, pero debe producir una salida que la siguiente fase pueda recibir, entender, derivar y validar.
Ahí es donde el desarrollo deja de ser una sucesión de actividades y empieza a comportarse como ingeniería.