walkthrough

Recorrido del interesado

Los requisitos que nadie escribió salen a la superficie cuando alguien que no es el autor intenta hacer la cosa: el operador que instala el servicio, el científico que busca sus datos, el colega que configura un repositorio, el mantenedor que lee un registro a las tres de la mañana. Un recorrido hace eso en papel, con una persona con nombre y un proceso concreto, antes de que se especifique el cambio. Su resultado no es un diseño: son preguntas para el propietario, brechas y ejemplos de aceptación que las especificaciones y las pruebas pueden usar.

Dos hábitos tomados prestados, con agradecimiento: la entrevista con dos sombreros, el sombrero de producto (valor para el usuario, objetivos, éxito) y el sombrero de desarrollador (viabilidad, seguridad, casos límite), como hace la habilidad Feature Forge de jeffallan, con licencia MIT; y marcar lo que un interesado simulado "dijo" como de menor confianza que lo que dijo uno real, como hacen las habilidades de elicitación de requisitos de melodic-software.

Entradas

Acuerda esto con el usuario antes de caminar, y escríbelo al principio del resultado:

1. La persona. Quién es, qué quiere de este proceso, qué sabe y qué no sabe, qué tiene en su máquina y qué nunca leería. Prefiere el rol de una persona real en el instituto sobre un arquetipo; prefiere las respuestas de una persona real sobre tus suposiciones cuando puedas preguntar.
2. El proceso. Lo que están tratando de hacer, desde su primer paso hasta el momento en que lo consideran terminado. Ejemplos: instalar el rastreador en un servidor; encontrar la medición de la semana pasada en el índice; agregar un nuevo formato de archivo como colección externa; iniciar un nuevo repositorio para desarrollo con agentes; leer el registro de rastreo después de una ejecución nocturna.
3. Lo que existe. Los documentos, código, comandos y páginas que la persona encontraría, para que el recorrido pruebe la realidad y no un plan. Léelos como lo haría la persona: en el orden en que los encontraría, saltando lo que saltaría.

El recorrido

Toma el proceso un paso a la vez, en los zapatos de la persona. Para cada paso, escribe:

• Lo que hacen, concretamente: el comando escrito, la página abierta, el archivo leído, la persona preguntada.
• Lo que necesitan saber en ese momento, y si lo que existe se lo dice.
• Lo que sale mal aquí en la práctica: el fallo silencioso, el mensaje engañoso, la elección sin valor predeterminado, el paso que necesita permisos que no tienen, la espera sin retroalimentación.
• La pregunta que le harían al propietario si pudieran, en sus palabras.

Luego cambia de sombrero dos veces sobre todo el recorrido: con el sombrero de producto, pregunta qué quería la persona y si el proceso lo entrega, cómo se ve "terminado" para ellos, de qué se quejarían; con el sombrero de desarrollador, pregunta qué es inviable, inseguro, lento a escala o frágil en el orden de los pasos.

Donde el recorrido llegue a un punto que los documentos no cubren, no inventes la respuesta: regístralo como una pregunta, y si tuviste que asumir algo para continuar, dilo y marca el resto del recorrido como basado en esa suposición.

Sube un nivel cuando un paso revele algo general (cinco porqués): un mensaje confuso es un paso; "la herramienta nunca dice lo que hará antes de hacerlo" es un requisito.

Resultado

Escribe el recorrido en las notas de diseño del proyecto si las tiene (por ejemplo design/walkthroughs/<persona>-<proceso>.md), de lo contrario docs/walkthroughs/, y da un breve resumen en la respuesta. Plantilla:

# Recorrido: <persona> <hace proceso>

Persona: <quién, objetivo, conocimiento, entorno>. Confianza: <simulado | basado en entrevistas con ...>.
Lo que existe: <documentos, código, comandos leídos>.

## Pasos
1. **<paso>.** Hace: <...>. Necesita saber: <...>. Sale mal: <...>. Preguntaría: "<...>".

## Sombrero de producto
<lo que querían, cómo es "terminado" para ellos, de qué se quejarían>

## Sombrero de desarrollador
<inviable, inseguro, lento, frágil>

## Preguntas para el propietario
- <pregunta, en palabras de la persona, con el paso del que surgió>

## Brechas
- <requisito, comportamiento o documento que no existe; el paso que lo necesita>

## Ejemplos de aceptación
- Cuando <situación concreta>, entonces <resultado observable>.   (listo para un escenario de especificación o una prueba)

Reglas

• Di qué partes son simuladas. Un recorrido hecho por un agente encuentra las brechas que encontraría un colega cuidadoso; no sabe lo que valora la persona real. Entrega las preguntas a un interesado real cuando exista uno, y actualiza la línea de confianza.
• Mantente en los zapatos. Si sabes cómo funciona el sistema, la persona no; escribe lo que ven, no lo que sabes.
• Concreto sobre general. "El operador ejecuta modama-crawler crawl y no ve nada durante dos horas" es un hallazgo; "la retroalimentación podría mejorarse" no lo es.
• Las preguntas, brechas y ejemplos son lo que se entrega. No diseñes la solución aquí; el propietario decide qué se convierte en un requisito.
• Considera un par de ojos nuevos: para una herramienta que existe, un subagente al que solo se le dé la persona, el proceso y los documentos orientados al usuario, con la instrucción de ejecutar la herramienta, encuentra lo que el autor no puede desaprender. Esa es la habilidad hallway-test en este plugin; úsala cuando el recorrido se convierta en 'probémoslo'.