.

La Definición de “Completo” para Scrum

actitud positiva

Debe existir un entendimiento común entre los miembros del equipo Scrum de lo que significa que una pieza de trabajo este “Completa”. Esta definición de “Completo” debe ser discutida y acordada por el Equipo Scrum al comienzo del proyecto a fin de que los incrementos futuros puedan ser entregables.

Cuando varios equipos Scrum están trabajando en un mismo proyecto, puede que no sea posible que todos los equipos utilicen la misma definición de “Completo”, ya que podrían estar trabajando en unidades de diferente naturaleza. En tal caso, cada Equipo Scrum establecerá su propia definición de “Completo” y entregará sus elementos en función de dicha definición. Sin embargo, la integración de las definiciones de “Completo” debe ser capaz de generar un Incremento potencialmente entregable a nivel de proyecto.

Generalmente una definición de “Completo” contiene:

-. Los procesos de desarrollo (especificación, diseño, programación, integración, prueba, documentación);

-. Los procesos organizacionales (otras cosas podrían tener que hacerse en base a las directrices de la organización);

-. Requisitos no funcionales (rendimiento, seguridad, escalabilidad, facilidad de mantenimiento, facilidad de uso, extensibilidad, etc.);

-. Criterios de calidad (por ejemplo, los estándares de codificación).

A menos que haya una definición normalizada en la empresa del concepto de “Completo”, la composición de la misma es responsabilidad del equipo de desarrollo. El Dueño del Producto también es consultado al respecto.

Documentación

Una de los cuatro principios del manifiesto ágil es “valoramos el software funcionando sobre una documentación extensiva.

Digamos que esta es la manera Ágil de evitar documentación innecesaria, después de todo, muchos de los documentos del proyecto se preparan para ser utilizados como herramientas de comunicación con el cliente. Por ejemplo, una especificación de requisitos tradicional es un documento que se utiliza para recibir retroalimentación del cliente. Sin embargo, podemos utilizar el software funcionando para recibir dicha retroalimentación, que al respecto será mucho mejor, y por lo tanto no necesitamos generar esa documentación.

Además, en base a nuestro método de entrega no contamos con un diseño y planificación iniciales y por lo tanto podremos preparar esos documentos. Los requisitos, el diseño, y casi todo lo demás evolucionan a lo largo del proyecto.

Además de la documentación sobre el producto a entregar, con la que no contamos en los proyectos Agiles a menos que no obliguen a prepararla, existen entre otros: los manuales de operación, y los documentos para el seguimiento y la configuración. Este tipo de documentación si es necesaria en los proyectos Agiles, y por lo tanto hay que prepararla. Sin embargo, no es necesario que sean documentos; un manual de operación, por ejemplo, podría ser en formato de video.

Un mínimo de documentación suele ser necesaria para cada historia de usuario, y por lo tanto, la incluimos en la definición de Hecho.

Pruebas

Existen diferentes formas de realizar pruebas en los proyectos de desarrollo de software, y ya que nos basamos en un desarrollo iterativo e incremental, casi todas están integradas en la definición de “completo”; es decir, no esperamos a que una serie de historias de usuario estén completas para ejecutar las pruebas.  Las pruebas se ejecutan como parte misma de la definición de completo de cada historia de usuario.

Ya que en los ciclos iterativos necesitamos ejecutar pruebas con más frecuencia, es en estos casos aún más importante tener pruebas automatizadas y todas las herramientas necesarias para ello. Además, debemos aumentar la cobertura de código tanto como sea posible. La cobertura de código, o la cobertura de código de prueba, o cobertura de la prueba, es el porcentaje de código que participan en las pruebas. Cuanto más grande sea la cobertura del código, más fiable resultara.

Por otro lado piensa en la prueba de aceptación del usuario. ¿Es posible considerar una historia “completa”, sin haber comprobado la aceptación del usuario? Generalmente la respuesta es no. En este caso, la prueba de aceptación del usuario debe ser una parte de la Definición de Completo, y se ejecutará durante el Sprint. Una vez completada, nos ponemos en contacto con el cliente para que nos facilite usuarios con los que realizar la prueba, mientras todavía estemos en el Sprint.  Concluida la prueba y cumpliendo con el resto de especificaciones incluidas en la definición de “completo”, comprobaremos junto con el Dueño del Producto que todo está correcto y entonces podremos definirlo como completo. Es por esto, en parte, que decimos que el cliente debe colaborar en proyectos ágiles.

Post relacionados

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 qu...
5 errores frecuentes en la Planificación del Sprint Aunque por definición sencilla, muchas son los problemas y errores que se cometen durante la Planificación del sprint.  La Planificación del Spri...
Acontecimiento 4 de Scrum: Revisión del Sprint La duración de la reunión Scrum para la revisión del sprint  es normalmente de cuatro horas para Sprints de un mes. Si los Sprints son más cortos, la ...

Deja un comentario

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

AUTOR:  miguel

Dirección proyectos TI y #ecommerce bajo Prince2 o Scrum . Usabilidad, Conversión, Seo, AdWords, Marketing online, Analítica. Consultor y desarrollador.

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