El método
| Idea | Por qué |
|---|---|
| El proceso se acredita con evidencias, no con valoraciones | Una afirmación sobre el esfuerzo dedicado no es verificable; un tablero con marcas temporales sí lo es |
| Un fallo controlado comprueba el bloqueo | Probar en local es correcto; se demuestra la eficacia del check sin exigir fallos frecuentes |
| Las limitaciones se declaran de forma anticipada | Una limitación reconocida por su autor demuestra criterio; la misma limitación detectada por el evaluador constituye un defecto |
| Toda afirmación se acredita sobre la pantalla | Cualquier enunciado de la defensa consta registrado en algún punto del repositorio |
| Una pregunta de proceso no se responde con tecnología | Corresponden a dos ámbitos evaluativos distintos y su confusión es inmediatamente identificable |
El vocabulario de la unidad
| Concepto | Significa |
|---|---|
| Rastro | El conjunto de evidencias fechadas que deja el trabajo: issues, commits, pull requests, revisiones y ejecuciones |
| Trazabilidad | Poder ir de un cambio a la tarea que lo pedía, y al revés |
| Ritmo | Distribución temporal del trabajo. Es observable de forma directa en el registro y no admite reconstrucción posterior |
| Retrospectiva | Mirar hacia atrás para decidir qué cambiar en el siguiente ciclo, no para justificar el anterior |
Ya deberías ser capaz de
- Reconstruir el rastro de trabajo propio y analizarlo desde el criterio de quien evalúa.
- Explicar una decisión de proceso sin refugiarse en la tecnología.
- Defender una revisión hecha y una recibida.
- Leer un fallo del pipeline y explicar qué lo provocó y cómo se resolvió.
- Reconocer las limitaciones del propio trabajo antes de que las señale otro.