.

La Definición de Hecho

En nuestro última lección empezamos a estudiar los Artefactos de scrum, y vimos como se desarrollo scrum a través de estos. Por cierto, ¿recuerda a que nos referimos en scrum por artefacto? En esta lección nos centraremos en la definición de hecho (100% completo).

definición de hecho

La Definición de Hecho (completo al 100%)

La definición de hecho, o completo, se refiere al entendimiento común que debe existir entre los miembros del Equipo Scrum para considerar una pieza de trabajo como completa o hecha. Es por lo tanto una definición que debe alcanazrse, acordarse entre los miembros del Equipo.

¿Por que es necesario contar con esta definición? bien, de otro modo, sin una definición clara y detallada de lo que se entenderá por hecho (completo al 100%), que comparte toda el Equipo, resultaría imposible determinar cuando algo estará completamente hecho. Dicha definición, que siempre deberá estar documentada, recogerá todo lo que debemos hacer para considerar como completo cada uno de los elementos del Backlog de Producto.

¿Qué podemos encontrar en dicha documentación? Algunos de los elementos más comunes son:

  • Los procesos de desarrollo: análisis, diseño, programación, integración, pruebas, documentación
  • Los métodos de calidad y criterios de aceptación
  • Las características no funcionales

De los elementos anteriores, seguramente el único elemento que necesitemos aclarar es el concepto de características no funcionales.

Las características no funcionalesHistoria de ususario

Por características no funcionales me refiero, entre otras a las características de rendimiento, seguridad, escalabilidad o facilidad de mantenimiento. Puesto que no son funciones,
por lo general no podemos crear artículos no técnicos para incluirlas en el Backlog de Producto. Recuerda que el Backlog de Producto se compone principalmente de “historias de usuario”, y que estas se emplean pare expresas funcionalidades desde el punto de vista del usuario, y siempre de manera no técnica.

Por otra parte, las característica no funcionales deben ser considerados para todos y cada uno de los elementos del Backlog de Producto. Es por esto que la mejor manera de incluirlas es en la definición de “hecho”; pues todos y cada uno de los elementos debe cumplir con estas características antes de poder ser considerados como “hechos” o completos al 100%.

Es decir, todas las funcionalidades (elementos del Backlog de Producto) deben cumplir con unos requisitos de rendimiento, seguridad, escalabilidad, facilidad de mantenimiento… que son características no funcionales.

Saludos y hasta la próxima.

JLVG

QuieresCursoGratisImagen700X150_3

Otras lecciones de este curso

01. Curso Gratis de Introducción a Scrum

02. Entonces… ¿qué son los sistemas predictivos y adaptativos?

03. El Backlog de Producto

04. El scrum team: el Dueño del Producto

05. Los sprints

06. La estimación de los elementos de Backlog de Producto

07. Puntos de historia y velocidad

08. Póker de Planificación

09. El scrum team: el Scrum Máster

10. ¿Quien es el Project Manager en scrum?

11. ¿Cómo se desarrolla un sprint?

12. El desarrollo del sprint: medición y cancelación

13. Eventos scrum: el Scrum Diario

14. Eventos scrum (II): la Retrospectiva del Sprint

15. Artefactos scrum (I)

16. Artefactos scrum (II)

17. La “definición de completo”

18. ¿Cómo funciona scrum?

19. Certificaciones scrum

20. Referencias

Post relacionados

Los Sprints y su planificación Hola, tras la lección sobre el Dueño del Producto, hoy seguimos con la lección 5 de nuestro curso de Introducción a scrum. Al final del post tienes ...
Grandes proyectos con Scrum. Scrum de Scrums Cuando los proyectos son muy,muy  grandes, también podemos usar Scrum. La clave está en coordinar a los diferentes equipos scrum. Cada uno de los e...
Scrum: tres en uno Aunque Scrum es el marco de trabajo Ágil más conocido para desarrollar y gestionar proyectos de software, es mucho más que eso. Al respecto, Jeff Su...

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

AUTOR:  Juan Luis Vila Grau

PRINCE2® practitioner, Scrum Master (PSMI), EXIN Agile Scrum Foundation, AgilePM® Foundation, Management_of_Risk (M_o_R®) Foundation. and an enthusiastic of Agile management. Especialistas en técnicas participativas para la gestión de proyectos, y en el Enfoque del Marco Lógico (EML). Faclilitador certificado en el método LEGO® Serious Play®

Utilizamos cookies de terceros para mejorar nuestros servicios. Si continúa navegando, considera que acepta su uso. Más información aquí.  CERRAR