¿Cuáles son algunas buenas definiciones de Done in Agile Software Development?

Hicimos dos listas de verificación en nuestra empresa: Definición de Hecho para un Sprint y para una Historia de usuario.

Un ejemplo de DoD de Brainhub

Cuando decidimos crear el DoD en nuestra empresa, preparamos juntos una breve lista de áreas, que deberíamos controlar, para ofrecer el software de mayor calidad posible. Creamos dos listas de verificación , que nos ayudan a verificar nuestro trabajo en dos etapas del proceso de desarrollo de software.

Definición de la lista de verificación para la historia del usuario

El primer nivel, y el más básico, es una sola historia de usuario, donde verificamos el cumplimiento de los supuestos iniciales de un solo elemento de la cartera de pedidos, que se describieron en él. En esta etapa también controlamos la calidad del código escrito y verificamos si se llevaron a cabo todos los elementos necesarios de nuestro proceso (por ejemplo, sesión de control de calidad o pruebas en el entorno de prueba).

1. Código producido para presuntas funcionalidades
2. Suposiciones de los Estados Unidos se reunieron
3. Proyectos construidos sin errores
4. Pruebas unitarias escritas y aprobadas
5. Proyecto implementado en el entorno de prueba idéntico a la plataforma de producción.
6. Pruebas en dispositivos / navegadores enumerados en los supuestos del proyecto aprobados
7. Sesión QA (Garantía de calidad) realizada
8. Problemas de la sesión de QA resueltos
9. Refactorización completada
10. Cualquier configuración o cambios de compilación documentados
11. Documentación actualizada (si existe)
12. PCR (Peer Code Review) realizada

Definición de la lista de verificación para Sprint

La segunda etapa, que decidimos controlar es Sprint, donde verificamos la mayor parte de nuestro trabajo. Aquí podemos ver si todas las características implementadas cumplen con sus supuestos originales y si se cumplieron todas las condiciones requeridas para el despliegue de producción.

1. DoD de los EE. UU. Se reunió por cada EE. UU. Incluido en el Sprint
2. Todo ‘para hacer’ en el código completado
3. Todas las pruebas unitarias pasan
4. Backlog del producto actualizado
5. Proyecto implementado en el entorno de prueba idéntico a la plataforma de producción.
6. Pruebas en dispositivos / navegadores listados en la documentación aprobada
7. Pruebas de compatibilidad con versiones anteriores aprobadas
8. Las pruebas de rendimiento superadas
9. Todos los errores arreglados
10. Sprint marcado como listo para la implementación de producción por el propietario del producto

Si desea leer más sobre nuestras mejores prácticas y la definición de hecho y descargar esas dos listas de verificación, simplemente lea más aquí

¿Busca desarrolladores de software con un enfoque ágil probado? Más aquí.

Estoy sorprendido con la respuesta de Marcas Neal y estoy de acuerdo con él. Sorprendido porque la mayoría de las definiciones de hecho incluyen condiciones sintéticas, por ejemplo, automatización de pruebas, etc. que no tienen nada que ver con la naturaleza del desarrollo de software. El desarrollo de software es un proceso empírico (en oposición al definitivo / rígido). Por definición, no puede crear criterios para un proceso empírico. Sin embargo, la mayoría de los equipos e ingenieros ágiles presentan criterios para medir el hecho.

La definición que me gusta es ‘deberías detenerte cuando creas razonablemente que la probabilidad es baja de que el producto todavía tenga problemas importantes sin descubrir’. (Lección 185 – Dejaré de lado la referencia para evitar apelar a la autoridad). Por supuesto, la decisión es altamente subjetiva. Esa es la naturaleza del desarrollo de software. Tratar con él. Desafortunadamente, muy pocas personas en desarrollo ágil estarán de acuerdo con esto.

Hay algunas implicaciones de lo que dije: debe preguntarse cómo sabe lo que sabe. Necesita saber cómo lidiar con la incertidumbre. ¿Qué es la competencia? Creo que esto es aún mejor que vivir bajo la ilusión de que algunos criterios te dirán cuando hayas terminado.

Editar:
Aquí hay algo más de la escritura:
Lección 184:
No existe una fórmula universal para saber cuánto desarrollo o prueba es suficiente (Nilanjan agregó las palabras en negrita)
creemos que es mejor vivir con incertidumbre sobre el desarrollo que aceptar la certeza falsa. (Nilanjan cambió las pruebas al desarrollo)

Este puede ser uno de los problemas más difíciles en Agile para muchos equipos. obtener definiciones de hecho suele ser fácil, pero hacer que todas las partes estén de acuerdo con ellas puede no ser siempre fácil. por lo tanto, he encontrado usando una lista de verificación de tipos de hecho:

Los desarrolladores a menudo considerarán ‘hecho’ como cuando se envía una confirmación al repositorio de código o se pasa una prueba unitaria.

El control de calidad tenderá a verificar el cambio en busca de regresiones, no se han creado errores y la función coincide con la solicitud de función o la historia del usuario.

El propietario / gerente de un producto se asegurará de que el cambio coincida con su solicitud y brinde el valor comercial que estaban proponiendo a partir del cambio.

Esas definiciones de hecho juntos, generalmente hacen una definición más oficialmente hecha.

Se puede denominar como una lista de verificación de los entregables de un producto y una forma de informar el estado de estos entregables debido a otros miembros del equipo.

La definición de una definición clara de hecho en un proyecto facilita el seguimiento del progreso y permite al equipo concentrarse en completar las tareas para construir el producto con una visión clara al eliminar actividades no importantes que se suman como un desperdicio. Los miembros del equipo no pierden tiempo y esfuerzo en identificar la exactitud de las historias de los usuarios, lo que no crea confusión.

Ejemplos de definición de hecho:

• ¿Todas las tareas son priorizadas por el propietario del producto?
• ¿Las historias de los usuarios son asignadas y estimadas por los miembros del equipo?

Puede encontrar en detalle la definición de hecho y su META-PREGUNTA-MÉTRICA en este artículo

‘Definición de hecho’ – Lista de verificación para un proyecto

La definición “real” nunca es, porque el usuario y / o el equipo de desarrollo siempre pueden agregar nuevos requisitos.

• Aquí está la definición que le interesa al cliente: ¿Cumple el sistema con los requisitos siempre cambiantes del cliente?

Lamentablemente, dado que el cliente no puede ver los problemas subyacentes, la percepción del cliente de “hecho” rara vez se alinea con lo que el equipo de desarrollo considera hecho.

La definición de “hecho” de los equipos de desarrollo incluye lo que hay que hacer para facilitar la próxima ronda de cambios para el equipo de desarrollo.

Sin embargo, los clientes quieren ……… (ver primer párrafo). El truco es saber que los clientes nunca saben lo que quieren hasta que ven lo que no quieren.

Creo que este artículo cubre todo lo que necesita saber sobre el tema de DoD: profesionales en startups y tecnología