Intent Mediation Platform

El método

No se construye nada hasta que alguien ha leído el plan y ha dicho que sí.

El software escrito con una máquina se tuerce de una manera particular. Se tuerce rápido, con seguridad, y en frases que se leen preciosas. La velocidad no es el problema a resolver. El significado sí.

Primero: ¿esto ya está construido?

Antes de escribir nada nuevo, esa pregunta se le hace a la biblioteca y no a la memoria de alguien. Casi siempre la respuesta es sí, y el trabajo se convierte en conectar dos cosas en vez de inventar una tercera.

Luego: el plan, por escrito

Qué se quiere, quién lo quiere, y cómo sabrá alguien que funcionó — escrito en frases con las que puedes estar en desacuerdo. Ahí es donde también se eligen los nombres, porque un nombre es mucho más difícil de cambiar después que un plan.

Esta es además la parte que compras primero. Recibes el plan, lo lees, y es tuyo lo construyas con nosotros o no.

Luego: la prueba antes que la cosa

La comprobación que demuestra que un trabajo está terminado se escribe antes que el trabajo, y se espera que al principio falle. Una prueba escrita después tiende a describir lo que el código resulta que hace. Escrita antes, describe lo que alguien quería de verdad.

Luego: compruébalo, en lo real

No vale «compila». Todo lo que va a mirar una persona se abre en un navegador real, en el idioma en que lo va a leer. Una página que carga pero le falta la mitad de lo que se pidió se reporta como media hecha, porque lo está.

Luego: guarda lo que era general

Cuando el trabajo está hecho queda una pregunta más, y es la que compone interés: ¿algo de eso no era específico de este encargo? Si es así, va a la biblioteca, y el siguiente proyecto empieza con eso ya hecho. Esa costumbre es la razón de que haya 445 piezas y no 45.

Y todo esto se diseña a la vista

El proceso mismo se trabaja igual que el software. Aquí se está convirtiendo en algo que un programa puede ejecutar, etapa por etapa, con las piezas que todavía no existen anotadas como faltantes.

Una terminal con una sesión de diseño. Una tabla da cada estado de un sprint — preguntar, reconocer, planear, consenso, aprobar, despachar, construir, verificar, revisar y cerrar — junto al programa que produce su artefacto y la sonda que decide que está terminado. Encima, el principio: un sprint es una máquina de estados, no una conversación.
Diseñar el proceso mismo, a la vista. Cada etapa nombra el programa que la hace y la comprobación que decide que está terminada — y las que todavía no existen se marcan como pendientes en vez de describirse como si existieran.

La regla que hay debajo de todo

Lo que ocurre dos veces se convierte en un programa pequeño. La máquina nunca cuenta lo que puede contar el código.

Es la regla más barata del taller y la única que mejora con los años. Cada cosa resuelta una vez deja de ser algo que alguien tenga que volver a resolver.