Definición de Hecho

El equipo está de acuerdo, y muestra de forma prominente en algún lugar de la sala del equipo, una lista de criterios que deben cumplirse antes de que un incremento de producto “a menudo una historia de usuario” se considere “hecho”. El no cumplir con estos criterios al final de un sprint normalmente implica que el trabajo no debe ser contado hacia la velocidad de ese sprint.

También conocido como

Los desarrolladores de software tienen la reputación de ser un poco descuidados al responder a la pregunta “¿has terminado con esta función? Para ser justos, esta es una pregunta ambigua – puede significar “programación terminada” y esto es generalmente lo que un desarrollador tendrá en mente cuando responda. Sin embargo, el significado de interés suele ser “¿ha terminado de programar, crear datos de prueba, realmente probar, asegurarse de que es desplegable, documentar….”.

Proverbialmente, para obtener una respuesta a eso, la pregunta que hay que hacerse es: “Sé que has terminado, pero, ¿has terminado? Véase también “Listo para usar”.

Algunos equipos utilizan el término “Lista de Hechos” o “Lista de Verificación de Hechos”; el término menos difundido “sashimi de producto” ofrece una imagen convincente de rebanadas bien definidas de un producto.

Beneficios esperados

  • La Definición de Hecho proporciona una lista de verificación que guía de manera útil las actividades previas a la implementación: discusión, estimación, diseño.
  • La Definición de Hecho limita el costo de retrabajo una vez que una característica ha sido aceptada como “hecha”.
  • Tener un contrato explícito limita el riesgo de malentendidos y conflictos entre el equipo de desarrollo y el cliente o propietario del producto.

Obstáculos comunes

  • La obsesión por la lista de criterios puede ser contraproducente; la lista debe definir el trabajo mínimo que generalmente se requiere para conseguir que un producto pase al estado “listo”.
  • Las características individuales o las historias de los usuarios pueden tener criterios específicos de “hecho” además de los que se aplican al trabajo en general.
  • Si la definición de hecho es meramente un entendimiento compartido, en lugar de ser explicado y exhibido en una pared, puede perder gran parte de su efectividad; una buena parte de su valor radica en ser un contrato explícito conocido por todos los miembros del equipo.

Orígenes

  • 2002: Un primer artículo de Bill Wake llama la atención sobre las posibles inconsistencias que surgen de los términos comúnmente utilizados en los equipos, como “hecho”.
  • 2003: Los primeros materiales de formación de Scrum aluden a la importancia futura de la “Definición de Hecho”, inicialmente sólo en forma de un título de diapositiva: “La historia de Done”.
  • 2005: Los primeros ejercicios que invitan a los aprendices de Scrum a reflexionar sobre su “definición de lo hecho” (local) aparecen en iteraciones posteriores de los materiales de formación de Scrum.
  • 2007: En ese momento, la “Definición de Hecho” como una práctica en toda regla, y como una lista de verificación textual que se exhibe en la sala del equipo, se ha generalizado.

Señales de uso

  • A petición, el equipo puede señalar su definición explícita de “Hecho”.
  • El equipo utiliza la Definición de Hecho al final de un sprint para justificar la decisión de contar el trabajo hacia la velocidad o no.

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar