Documentación de Scrum: Proceso y ejemplo

Base de la documentación de Scrum

Lynn y su equipo han estado usando Scrum para implementar Agile durante el año pasado. El equipo se ha familiarizado y ha comenzado a adaptar los diferentes procesos para que se adapten mejor a ellos. Un aspecto que ha continuado siendo un tema de debate es la documentación. Lynn está tratando de encontrar el equilibrio entre su equipo que no quiere demasiada documentación y las partes interesadas de la empresa que no quieren demasiado poco. Confía en que el equilibrio se puede encontrar en Scrum.

Scrum es la forma más popular de Agile, que es una alternativa a las metodologías de proyectos tradicionales. La base de Agile implica valorar diferentes componentes del proyecto sobre otros. Este es un reconocimiento de que existen compensaciones dentro de un proyecto y que no se puede hacer todo en su máxima extensión. Dos valores ágiles en particular influyen en lo que se necesita para la documentación de Scrum.

El primer valor ágil que influye en la documentación de Scrum es el énfasis en las personas y las interacciones sobre los procesos y herramientas. El objetivo es que las diferentes personas involucradas en un proyecto alcancen un entendimiento común de lo que se necesita. El equipo de Lynn logra esto a través de la conversación y la colaboración, en lugar de que los miembros del equipo revisen de forma independiente la documentación escrita por una o dos personas.

En lugar de centrarse en producir documentación, un proyecto valioso produce un resultado tangible. Este es el segundo valor ágil, que implica dedicar tiempo y esfuerzo a la creación de software funcional en lugar de una documentación completa. Cualquier trabajo o tarea que Lynn y su equipo completen se hacen en lugar de otra cosa. En lugar de dedicar tiempo a documentar todo lo que podría estar involucrado con el proyecto, la atención se centra en la producción de software funcional, que cumple con el propósito del proyecto.

Ejemplos de documentación

Una vez que Lynn ayuda a todos a comprender la base de la documentación de Scrum, pasa a ejemplos de las diferentes formas que puede adoptar. Las formas de documentación de Scrum generalmente se enfocan en una de tres cosas. El primero tiene que ver con lo que debe producir el proyecto. El segundo gira en torno a cómo se producen estas cosas. El tercero incluye verificar que se haya producido lo necesario.

La primera forma de documentación, centrada en lo que debe producir el proyecto, es relativamente estándar entre los diferentes equipos que practican Scrum. La forma típica es una historia de usuario , que detalla la funcionalidad deseada para un usuario específico. En Scrum, estos los escribe el propietario del producto , que es la persona que solicita el proyecto. Si el equipo de Lynn estuviera trabajando en un portal de intercambio de archivos, un ejemplo sería: ‘Como usuario autenticado, puedo cargar documentos para que otros usuarios puedan acceder a ellos’. Las historias de usuario son requisitos de alto nivel, pero también contienen requisitos de bajo nivel, conocidos como criterios de aceptación.. Estos detalles detallan las acciones y los resultados que logran la historia del usuario. Para la historia de usuario de intercambio de archivos, un criterio de aceptación podría ser: «Cuando hago clic en Examinar, puedo seleccionar un archivo de mi computadora». Las historias de usuario y los criterios de aceptación son la forma principal de documentación de requisitos en Scrum.

Además de documentar lo que debería producir un proyecto, también es importante documentar cómo se producen estas cosas. Este tipo de documentación se suele llamar documentación técnica. A diferencia de la documentación de requisitos, la documentación técnica no tiene una forma común en Scrum. Algunos equipos escriben tareas para el lado técnico de las historias de usuario. Otros mantienen un documento formal de especificaciones técnicas. El equipo de Lynn usa ambos tratamientos según el proyecto que estén completando.

La última forma de documentación es la verificación de que se ha producido lo que se necesita. Esto está relacionado con las pruebas que se realizan para cada historia de usuario. La documentación de prueba implica casos de prueba específicos que se pueden agrupar en planes de prueba. Estos son típicos para la mayoría de las metodologías de proyectos, pero lo único de Scrum es que se toman principalmente directamente de los criterios de aceptación. La documentación de prueba a menudo se revisa con el propietario del producto para obtener la confirmación de que las historias de usuario están completas según lo solicitado.

Características de la documentación

Una vez que el equipo de Lynn comprende cómo los valores ágiles influyen en la documentación de Scrum y las diferentes formas de documentación, lo último que cubre son las características de la documentación de Scrum. El equipo puede usar diferentes formas de documentación en diferentes puntos, pero las características deben ser consistentes. La documentación de Scrum debe ser eficiente, una prioridad y completarse durante la duración de un proyecto.

La documentación de Scrum debe ser eficiente, además de una prioridad. Reservar tiempo para completar la documentación es una compensación. Es tiempo que podría dedicarse al trabajo del proyecto. Al completarse, es importante que la documentación sea una prioridad. No solo eso, sino que debe hacerse de manera eficiente. La documentación debe cubrir solo lo que se necesita, ni más ni menos. No solo eso, sino que no debería tomar un tiempo significativo para crear o un tiempo significativo para revisar la comprensión.

Además de ser eficiente y una prioridad, la documentación de Scrum debe completarse durante la duración de un proyecto. Exclusivo de Scrum es el desglose de la línea de tiempo del proyecto en ciclos repetidos más cortos, conocidos como sprints . La documentación también debe completarse en ciclos. Esto contrasta con las metodologías tradicionales que completan la documentación de una vez antes del inicio de un proyecto. En Scrum, a medida que avanzan los sprints y el equipo completa las historias de usuario, aprenden e identifican áreas de cambio, que deberían incorporarse en la nueva documentación.

Resumen de la lección

La base de la documentación de Scrum proviene de los valores ágiles y, en lugar de estar atados a procesos rígidos, las personas tienen conversaciones y colaboran para llegar a un entendimiento común. La atención se centra en producir software funcional en lugar de documentación funcional. Los formularios específicos en Scrum incluyen documentación de requisitos que puede tomar la forma de historias de usuario , que detallan la funcionalidad deseada para un usuario específico, y criterios de aceptación , que detallan acciones y resultados que logran la historia de usuario. La documentación también puede tomar la forma de documentación técnica que se puede escribir como tareas o un documento de especificación formal y documentación de prueba que se puede escribir como planes de prueba o casos de prueba. Estos tipos de documentación están escritos por elpropietario del producto , que es la persona que solicita el proyecto. Cualquier documentación que se considere necesaria, solo debe hacerse si es una prioridad y debe hacerse de manera eficiente. Además, debe realizarse durante todo el proyecto en un ciclo similar a los sprints del proyecto , que son ciclos más cortos y repetidos.

Rodrigo Ricardo Editor y fundador