Table of Contents
Definición de hecho es crucial en un equipo Agil. Es la clave para entregar productos de alta calidad y contentar a tu manager o cliente en términos de gestión de proyectos y resultados. Para conseguir esto, tienes que asegurarte que entregas características que están completamente acabadas, no solo en términos de funcionalidad, sino en calidad también. Además, es importante mencionar que algunas veces las características son iterativas, siempre hay algo más que añadir o comprobar, por lo que definir aquello terminado es extremadamente importante para entender el proyecto y estar todo el equipo en la misma pagina. Es fácil de decir y muy complicado de ejecutar, nuestro equipo Agile ha preparado algunos ejemplos que te ayudaran a entenderlo mejor.
¿Que es Definición de hecho ?
Empecemos por lo básico, ¿que es DoD o Definición de hecho exactamente? Definición de hecho para que todo el mundo entienda aquello que hace falta trabajar más para finalizar. Siendo honesto, cada equipo Agile tiene su propia definición de DoD o Definición de hecho. Básicamente, un equipo pone en conjunto todos los conceptos y los comparte en un canal como Slack, Google Drive, donde sea, una lista de criterios que han de conseguirse antes de incrementar un producto. Normalmente hay una historia de usuario y debería haber una definición clara de cuándo puede considerarse como terminada.
En otras palabras, Definición de hecho es una lista con objetivos y actividades, por ejemplo, escribir código, comentarios de código, pruebas unitarias, pruebas de integración, notas, diseñar documentos, etc. cualquier lista que demuestre el valor de tu producto. Centrarse en los pasos del valor-añadido permite al equipo concentrarse en aquello que debe completarse para obtener un software que funcione mientras se eliminan ejercicios inútiles que solamente complican los esfuerzos del desarrollo de software.
Bien, Definición de hecho es un buen mecanismo de informes para los miembros del equipo. Ayuda a decir “esta característica está terminada”! Mediante Definición de hecho como referencia un miembro del equipo puede mantener a sus miembros del equipo y al cliente actualizados.
Definición de hecho: ejemplos
Definición de hecho puede ser diferente, pero es importante notificar, es que la primera Definición de hecho tiene que estar definida antes del primer Sprint.
Veamos distintos tipos de Definición de hecho:
- Definición de hecho para una Característica ( historia de usuario o una lista de características de producto)
- Definición de hecho para un Sprint (conjunto de características desarrolladas en un Sprint)
- Definición de hecho para una entrega (estado potencialmente listo para enviar)
Por ejemplo, en software, una Definición de hecho podría ser: “Estándares codificados, revisados, implementados con pruebas de TDD, testeado con 100% de automoción, integrado y documentado”.
En contexto de servicios, puede que sea de la siguiente manera: “ Acabado significa que cada tarea bajo la historia de usuario esté completada y que cualquier trabajo creado esta adjunto a la historia de usuario para que el cliente o propietario del producto pueda revisarlo y asegurarse que llegue a sus expectativas”.
La idea de Definición de hecho es que se asegura de que todo el mundo en el equipo sepa exactamente aquello que se espera de ellos. Transparencia y calidad a favor del producto y la organización. Mejor incluso, ticks con acabados, motiva a los equipos y los hace más eficientes.
Echemos un vistazo a algunos ejemplos de definición de hecho por cada uno de ellos.
1.Definición de hecho para historias de usuario
Este es el primer y más básico nivel, historia de usuario. Donde comprobamos las asumpciones iniciales de la lista de detalles, aquellas descritas en el. En este nivel también controlamos la calidad del código escrito y comprobamos si todos los elementos necesarios de nuestro proceso de consiguieron, por ejemplo:
- Producir codigo para unas funcionalidades supuestas.
- Asumpciones en la historia de usuarios conseguidas.
- Construir el proyecto sin errores
- Pruebas unitarias escritas y comprobadas.
- Proyecto desplegado en los test del entorno idéntico a la plataforma del producto.
- Testear los dispositivos en la lista de asumpciones del proyecto.
- OK de diseñador UX
- QA realizado & errores resueltos.
- Características testeadas con criterios de aceptación.
- OK de Product Owner
- Completar la refactorización.
- Cualquier configuración o cambios realizados ha de estar documentado
- Documentación actualizada.
- Peer Code Review realizado y ejecutado.
2. Definición de hecho para los Sprints
La segunda parte son los Sprints, donde comprobamos la mayor parte de nuestro trabajo. Aquí podemos comprobar si todas las características implementadas cumplen con sus asumpciones iniciales y si las condiciones requeridas para la entrega del producto se cumplen.
- DoD para cada historia de usuario, incluidos en el Sprint conseguidos.
- Tareas “Para hacer” completadas.
- Todas las pruebas unitarias completadas.
- Product backlog actualizada.
- Entrega del producto en el test de entorno identico al de production.
- Testear los dispositivos en la lista de asumpciones del proyecto.
- Test de compatibilidad al revés completada.
- Test de rendimiento completada.
- Todos los bugs corregidos.
- Sprint marcado como listo para ser comprobado por el cliente.
3. Definición de hecho para una entrega
- Codigo completado
- Entorno preparado para entrega
- Todas las pruebas unitarias y prubas funcionales están en verde
- Criterios de aceptación cubiertos
- QA completado & todos os problemas resueltos
- Todas las tareas por realizar completadas
- OK del equipo: diseñador UX, desarrollador, arquitecto de software, manager de proyectos, cliente, QA, etc.
- Confirmar que trabajo en progreso todavía sin integrar se ha dejado aparte en un entorno de desarrollo o estacionamiento.
- Confirmar que TDD e Integración Contínua esta verificado y trabajando.
Preparar definición de hecho que pueda llevarse a todas las situaciones es imposible. Cada equipo debería colaborar y elaborar la definición que mejor concuerde con su entorno unico. Los equipos que acaban de empezar con Agile puede que encuentren difícil llegar de inmediato a un nivel más maduro; por lo que, deberían seguir los pasos, sprint por sprint, para mejorar su definición de DoD. Espero que estas definiciones de definición de hecho hayan sido útiles! Por cierto, no te olvides de retrospectividad, feedback de reuniones retrospectivas deberían ayudarte también a definir tu concepto de acabado.
¡Espero que este artículo te haya sido interesante! Si estás interesado en el mundo de tecnología, innovación, te recomiendo que te suscribas nuestro newsletter mensual para recibir las últimas noticias en la industria.
Si te gustó este artículo, te puede gustar:
Los beneficios de la tecnología Scrum
Beneficios de la tecnología Agil
Metodo Kanban Principios y Ventajas
La importancia de las retrospectivas en la metodología Ágil
