Preparación (DoR/DoD)

DoR — Definition of Ready: lo que necesita estar listo para que el trabajo empiece. Existe para acabar con la demanda que entra en ejecución y vuelve en dos días porque faltaba el acceso, el dato o la decisión.
DoD — Definition of Done: lo que necesita estar hecho para que el trabajo se considere terminado. Existe para acabar con el "terminé" que todavía no fue probado, documentado ni comunicado.

Los dos son la misma idea aplicada en los dos extremos: escribir el acuerdo antes, para no discutir después. Y los dos son por ETAPA del tablero — cada columna puede tener el suyo.

Dos listas que el equipo acuerda una vez y usa siempre: lo que debe estar listo para que una demanda PUEDA empezar (Definition of Ready) y lo que debe estar listo para que se considere TERMINADA (Definition of Done). Es lo que evita la demanda que entra en el sprint sin alcance y la que "está lista" pero nadie probó.

Aquí registras un ítem del acuerdo de preparación del equipo (DoR/DoD): en qué etapa vale, si es condición para ENTRAR o para SALIR de ella, si vale solo para un tipo de demanda, el texto del acuerdo, si bloquea la salida de la etapa, el orden de visualización y si está activo. Es el checklist de calidad del flujo, ítem por ítem.

El campo "Entrar o salir" define de qué lado de la etapa vive el acuerdo. Un ítem de ENTRADA es Definition of Ready: lo que debe estar listo ANTES de que la demanda entre en esa etapa ("criterios de aceptación escritos", por ejemplo, antes de entrar en ejecución). Un ítem de SALIDA es Definition of Done: lo que debe estar hecho para que la demanda SALGA de la etapa ("code review aprobado"). El campo "Solo para el tipo" restringe el ítem a un tipo de demanda: un acuerdo de bug no tiene por qué valer para una mejora.

Usted escribe el ítem aquí una vez; se copia al checklist de la propia demanda cuando esta entra en la etapa, con la etiqueta entre corchetes (por ejemplo [DoD Em execução] testes automatizados verdes).

Note que no existe una segunda lista para marcar: quien trabaja marca en el mismo lugar de siempre, dentro de la demanda, y la verificación lee de allí. Una segunda lista significaría, en la práctica, una lista abandonada.

Es la parte más contraintuitiva. Al arrastrar una tarjeta de una columna a otra, el sistema verifica el DoD de la columna de la que está saliendo — porque la pregunta es "¿esto puede darse por terminado aquí?".

El DoR nunca bloquea. Entra como verificación de entrada, aparece en el checklist y sirve de recordatorio. Si usted marca el bloqueo en un ítem de DoR, el sistema lo desactiva y avisa.

Tres desenlaces posibles al mover: nada pendiente, y la tarjeta pasa; pendiente sin bloqueo, y la tarjeta pasa con aviso listando lo que quedó; pendiente con bloqueo, y la tarjeta vuelve a su lugar. Basta un ítem bloqueante abierto para impedirlo.

Un gate impuesto antes del acuerdo produce desvíos, no calidad: el equipo aprende a burlar el tablero. Escriba los ítems, deje que el equipo conviva con ellos algunas semanas y encienda el bloqueo solo en lo que se volvió hábito y aun así se escapa.

Dos límites honestos del gate, para que usted no confíe demasiado en él: solo actúa al arrastrar en el tablero — cambiar el estado por el formulario de la demanda, en lote, o por "finalizar" no pasa por aquí. Y, si la verificación falla por un error técnico, el movimiento pasa. Un gate que traba la operación por una falla de infraestructura es peor que el problema que evita.

El ítem y la marca se reconocen por el texto de la etiqueta. Al editar la descripción de un acuerdo (o renombrar la etapa, que entra en la etiqueta), el sistema deja de reconocer lo que ya estaba marcado: la marca antigua sigue visible en el historial de la demanda y el ítem nuevo entra pendiente.

Es el comportamiento correcto — cambió la regla, la verificación se rehace —, pero planifique el cambio: hacerlo en medio del sprint devuelve pendientes a todo el tablero.

Al guardar una vista con el botón Vistas, guarda cuatro cosas: el texto de búsqueda, los filtros aplicados, qué columnas aparecen (y en qué orden) y por qué columna está ordenada la lista. Aplicar la vista restaura todo de una vez — incluso reiniciando el orden y la página en que estaba, para que el resultado sea exactamente lo que la vista describe. Las vistas guardadas antes de esta versión siguen siendo válidas: lo que no guardaron simplemente no cambia al aplicarlas.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

El interruptor "Bloquea la salida" separa el acuerdo orientativo del acuerdo con dientes: un ítem bloqueante retiene la demanda en la etapa mientras no se cumpla; un ítem no bloqueante aparece como recordatorio del acuerdo del equipo, pero no impide el avance. Usa el bloqueo con moderación: bloquearlo todo convierte el flujo en burocracia e invita al equipo a marcar ítems sin mirar; el bloqueo vale para lo que realmente no puede pasar sin revisión, como "pruebas ejecutadas" antes de concluir.

En el panel de actividad del registro, cada anotación tiene "Convertir en demanda". El clic crea un ticket con el texto de la anotación, quién la escribió y el enlace de este registro — nada se vuelve a digitar. Úselo cuando la anotación es un pedido de acción ("alguien necesita revisar esto"); la anotación sigue donde estaba. El botón solo aparece con el registro ya guardado; una sesión de solo lectura (demostración) no lo crea.

Solo si usted deja el tipo en blanco — entonces es una regla general. Completando el tipo, el ítem pasa a valer solo para ese tipo de demanda (bug, mejora, soporte...).

Cuidado con una sutileza: una demanda sin tipo definido recibe solo las reglas generales. Si su DoD importante está atado a un tipo, la demanda sin tipo se escapa de él.

Abra el registro y mire la Línea de tiempo, a la derecha: muestra cada cambio como "de un valor a otro", con la persona y la fecha. Cuando hay muchos cambios, use los dos filtros de arriba de la línea de tiempo — uno por campo y otro por persona. La búsqueda se hace en la base de datos, así que un cambio antiguo aparece igual. También puede preguntarle a Tenkai: "¿quién cambió el contrato 482?".