Definición de Terminado - El qué, el por qué y cómo hacer crecer uno

Team Management

Agile 101

Definición de “Done” (Hecho) – El Qué y por Qué y Cómo Hacerlo Crecer

Cuando uno mira las tarjetas de la columna Hecho de un tablero Kanban o Scrum de un equipo de desarrollo, ¿no puede evitar preguntarse qué es lo que aún no se ha hecho? Después de todo, un producto de software no es sólo el código. Si esto le resulta familiar, se beneficiará de una Definición de Hecho. DoD para abreviar. Permítame explicarle lo que necesita saber.

¿Qué Significa la Definición de Hecho en Ágil?

En Ágil, se utiliza una Definición de Hecho para decir qué se ha hecho y con qué nivel de calidad cuando se declara algo hecho. En términos más concretos, enumera los criterios que debe cumplir antes de afirmar que una historia de usuario o un informe de error puede enviarse (liberarse) a sus clientes. Quizá se pregunte cuál es la diferencia con los criterios de aceptación, que también especifican los criterios que debe cumplir para implementar una historia de usuario o corregir un error.

Luchando: Definición de Hecho vs. Criterios de Aceptación

Es una cuestión de alcance y enfoque.

  • La Definición de Hecho se aplica a todo su trabajo. Los Criterios de Aceptación sólo se aplican a un único elemento de su cartera de pedidos.
  • La Definición de Hecho aclara lo que se hace como equipo. Los Criterios de Aceptación aclaran lo que hace el producto – su funcionalidad.
  • La Definición de Hecho puede contener criterios para aspectos «no funcionales» y preocupaciones transversales. Los Criterios de Aceptación hablan de aspectos funcionales de un solo elemento de trabajo. Sólo en raras ocasiones se encontrarán aspectos no funcionales en ellos. Y cuando lo hacen, sólo enumeran las excepciones a los requisitos generales no funcionales, haciéndolos más estrictos o menos estrictos para ese elemento de trabajo.
Una vez aclarado esto, le explicamos por qué quiere claridad y transparencia en lo que hace como equipo.

¿Cuáles son los 5 principales beneficios de una buena definición de hecho?

Dod
Los beneficios de crear y utilizar una buena Definición de hecho son:
  • Transparencia de las responsabilidades
Usted sabe lo que tiene que hacer y entiende lo que no tiene que hacer. Por ejemplo, sabe que es su trabajo implementar un comportamiento correcto, pero crear vídeos de formación no lo es. Se volverá más predecible en lo que entrega.
  • Compromiso de sprint realista
Con una lista detallada de lo que tiene que hacer exactamente para conseguirlo, podrá evaluar mejor cuánto puede asumir de forma realista en un Sprint. Será más fiable.
  • Reducción del Riesgo de Reelaboración
Las listas de control funcionan. La aviación no sería tan segura sin ellas. Cuando se reduce el trabajo que queda sin hacer cuando se declara algo hecho, significa menos (riesgo de) retrabajo más tarde. Será más eficiente.
  • Mayor calidad, menos esfuerzo en todas partes
A medida que madure en sus prácticas de desarrollo, elevará el nivel de calidad que ofrece y reducirá la carga de trabajo del resto del personal. Por ejemplo, un menor número de errores que se escapan significa una menor demanda de personal de apoyo. Ofrecerá una mayor calidad y ayudará a su empresa a ser más eficiente.
  • Previsibilidad y ritmo sostenible
  • Menos defectos fugados significa que podrá crear valor con todo el equipo en lugar de tener que desviar a algunos de ustedes para resolver los errores. Será más productivo y predecible, y conseguirá trabajar a un ritmo constante y sostenible.
Todo esto ayuda a aumentar la confianza que siente un equipo en la entrega de software valioso y a aumentar la confianza que otros equipos y partes interesadas depositan en un equipo. Pero no se deje llevar todavía. Hay una trampa.
Cómo No Beneficiarse de una Definición de Hecho
Definition Of Done
Como con todo lo que merece la pena, sólo se obtienen los beneficios si se evitan los errores comunes.
  • Fuera de la vista, fuera de la mente
Tener un DoD digital en algún lugar significa que no es probable que lo convierta en una prioridad. No a propósito, sino porque hay muchas cosas que reclaman su atención.
  • Demasiado y muy pronto
Poner todas sus aspiraciones en su DoD significa que no puede lograr mucho de ello. Eso no es divertido. La evitará o tratará la mayor parte de ella como opcional, lo que le resta importancia. Seguro que se pregunta qué puede hacer para evitar estas trampas.

Cómo Crear y Adoptar una Definición de Hecho con Éxito

Adoptar una Definición de Hecho requiere un cambio de comportamiento, un cambio de hábitos. Para tener éxito, querrá tratarlo como tal. El truco está en mantenerlo en mente, hacerlo fácil — y divertido — y reforzarlo hasta que se convierta en una práctica establecida. ¿Cuál es la solución?

Cómo Crear y Desarrollar una Definición de Hecho

Bueno, vamos a desglosarlo:
  • Mantenga su recién acuñada Definición de Hecho a la vista en todo momento. Cuélguela en todas las paredes, péguela en el interior de las puertas del baño, cuélguela en el mostrador del café, etc. Querrá que sea difícil de perder y olvidar.
  • Consulte su DoD con frecuencia durante las reuniones. Haga que sea un tema natural a tratar cuando se alinee el progreso, se revise el trabajo y se planifique lo que viene después.
  • Haga que su Definición de Hecho inicial sea corta y dulce, y fácil de cumplir. Al principio querrá obtener victorias fáciles. Incluso con un simple «¡Sí!», celebrar cada una de ellas es crucial para establecer nuevos hábitos.
  • Sólo eleve el listón cuando esté cumpliendo con su DoD de forma consistente y vuelva a encender las celebraciones (si las deja escapar) cuando lo haga.

No es demasiado complicado, ¿verdad?

Pero, apuesto a que todavía tiene algunas preguntas. Como por ejemplo, quién escribe o define la Definición de Hecho, o cuándo es más apropiado que un equipo de desarrollo cambie la definición de hecho, y qué poner en ella.

Quién Escribe o Define la Definición de Hecho

a Guía de Scrum dice: Si «Hecho» para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe definir una definición de «Hecho» apropiada para el producto. Si hay varios Equipos Scrum trabajando en el sistema o la liberación del producto, los Equipos de Desarrollo en todos los Equipos Scrum deben definir mutuamente la definición de «Hecho». y: El Equipo Scrum se compone de un Product Owner, el Equipo de Desarrollo, y un Scrum Master. A partir de eso, es bastante claro que un Equipo de Desarrollo decide su DoD. No el Dueño del Producto, no el Scrum Master, no un Gerente de Proyecto, no el Gerente de Desarrollo, sino el equipo de Desarrollo. Usted quiere definir su DoD antes de trabajar en un producto como un equipo (o se arriesga a no hacerlo en absoluto). Pero ¿cuándo se actualiza?

Cuando Cambiar lo que está en una Definición de Hecho

Muchos dirán: «en una retrospectiva». Pero las retrospectivas están pensadas para tratar algo más que las acciones para completar un elemento de trabajo. Es más, su Definición de Hecho sirve como lista de control de calidad. Eso lo convierte en un esfuerzo de mejora continua que merece su propio ciclo de mejora. Y recuerde que un cambio no es necesariamente una mejora. Poner una acción de una retrospectiva directamente en tu DoD puede significar que cambiará la DoD más a menudo de lo que es prudente. Los cambios frecuentes — especialmente la eliminación de lo que has añadido hace poco tiempo — disminuyen la percepción que los demás tienen de tu fiabilidad. Así que, independientemente de la procedencia de los puntos de su DoD — una retrospectiva o algún otro esfuerzo de mejora, pruébelos primero. Ajústelos hasta que consigan lo que pretendía. Ahora, veamos qué hay en una buena DoD.

Ejemplo de lo que Contiene una Buena Definición de Hecho para un Equipo de Desarrollo

Code Quality

Staging

Usted personaliza una buena Definición de Hecho a la madurez de sus prácticas de desarrollo. Así que le daré lo básico y lo seguiré con lo que puede añadir a medida que madure.

Lo Más Básico

  • ¿Ejecución evaluada por un segundo par de ojos? Revisada por pares o programada por pares.
  • ¿Se cumplen todos los criterios de aceptación?
  • ¿Código integrado (fusionado)?
  • ¿No hay defectos conocidos?
  • Se han ejecutado las pruebas de mono?
  • ¿Se ha actualizado la guía del usuario (documentación del cliente) o se ha proporcionado información a otros?

Código de Calidad

  • ¿Sin errores de compilación, advertencias o sugerencias?
  • ¿Se sigue la norma de codificación?
  • ¿Métricas de análisis estático-iguales o superiores al objetivo?
  • Dependencias minimizadas?
  • ¿Se ha refactorizado el código para cumplir con los principios de diseño de código SOLID y otros?

Puesta en Escena

  • ¿Integración de errores, advertencias y sugerencias?
  • ¿Pasa la prueba de humo?
  • ¿Error de creación del paquete, advertencia y ausencia de pistas?
  • Paquete desplegado en el entorno o entornos de prueba?

Pruebas de Regresión Funcional

  • Cada elemento de los criterios de aceptación está cubierto por al menos una prueba de aceptación?
  • ¿Pasan las pruebas unitarias?
  • ¿Pasan las pruebas de integración?
  • ¿Pruebas funcionales o de sistema superadas?
  • ¿Se han ejecutado las pruebas en todas las plataformas compatibles??

Para todas las pruebas automatizadas:

  • ¿Cobertura en la norma o por encima de ella? (Por ejemplo, el 85%).
  • ¿Todas las unidades / integraciones / funcionalidades nuevas están cubiertas por las pruebas?

Para sistemas heredados (aplicaciones en las que las pruebas automatizadas no cubren grandes trozos de código):

  • ¿Golden Master actualizado con escenarios para la funcionalidad actualizada y nueva?
  • No hay diferencias o sólo se prevén diferencias al comparar los resultados de los datos de prueba de Golden Master del código de producción actual y

Eso es mucho, ¿verdad? Y seguir las prácticas de CI/CD y DevOps puede añadir aún más.

Pero estoy seguro de que entiendes el punto y puedes tomarlo desde aquí. Y…

Consiga que su definición de «Hecho» se haga realidad

Ya puede dejar de sentirse inseguro.

Ya sabe todo lo que necesita saber sobre la Definición de Hecho para que le resulte ventajosa. Para estar seguro de que cuando una tarjeta está en la columna de Hecho, realmente ha completado todo el trabajo, y su calidad es tan alta como la que usted es capaz de lograr actualmente.

Así pues, dé el primer paso. Reúna a su equipo y cree su primera versión de Definición de Hecho.

Medha Case Study

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.
 
Solicitar demostración