Cómo escribir un documento de requisitos de negocios en ágil

Cómo un BRD establece expectativas

Un BRD describe el propósito comercial de un proyecto. Define cómo producir el producto, incluido su objetivo, cómo funciona y el uso previsto por el cliente. Con un BRD, una empresa puede evaluar los posibles factores de costo y las restricciones, y una línea de tiempo o cronograma para el proyecto de software. Un BRD representa un contrato básico entre el cliente y el proveedor; describe las expectativas y los entregables del proyecto. Además, establece los estándares para el éxito del proyecto.

Antes de que cualquier organización de TI cree una aplicación para los clientes o las partes interesadas del negocio, debe comprender cómo crear un BRD detallado, especialmente para que lo utilicen los equipos ágiles.

En qué se diferencian los requisitos funcionales y comerciales

Aunque los términos a menudo se usan indistintamente, los requisitos comerciales no son los mismos que los requisitos funcionales de un proyecto. Los requisitos comerciales describen los productos finales que los clientes necesitan, pero no cómo lograrlos.

Los requisitos funcionales cubren cómo satisfacer las expectativas del cliente con un producto de software. Puede haber documentación de requisitos de software separada para proyectos de desarrollo o una sección de requisitos funcionales en el BRD. Estos requisitos funcionales detallan cómo debe funcionar un sistema para cumplir con los requisitos comerciales.

Cómo utilizar BRD en el desarrollo ágil

En la metodología ágil, el propietario del producto o el representante del cliente normalmente define las características del producto. Las características se consideran una épica en ágil, y estas epopeyas abarcan todo lo definido en el BRD. El gerente de proyecto ágil trabaja con el propietario del producto para traducir el BRD en una serie de epopeyas que definen el producto. Estos dos luego traducen las características a historias de usuarios. Aquí, los desarrolladores cumplen los requisitos funcionales para cumplir con los requisitos comerciales.

Una historia de usuario describe brevemente algo de valor para un usuario objetivo o cliente. A continuación, se muestra un ejemplo del formato de historia de usuario:

«Como <tipo de usuario/rol>, yo <quiero/deseo>, de modo que <alguna razón/beneficio>».

La historia del usuario también incluye criterios de aceptación, que describen lo que debe lograr la función y cómo los desarrolladores pueden determinar si la historia del usuario tuvo éxito o fracasó.

Muchos grupos de desarrollo desglosan aún más las historias de usuario en tareas y/o subtareas que se centran en diferentes componentes del sistema. Por ejemplo, las tareas cubren el trabajo en la interfaz de usuario, el back-end o la base de datos que el equipo de desarrollo necesita terminar para completar la historia.

https://cdn.ttgtmedia.com/rms/onlineimages/software_quality-how_epics_become_agile_team_tasks-f_desktop.png

Cómo gestionar los cambios en el BRD

Muchos equipos no ágiles utilizan un proceso de gestión de configuración bien definido para realizar un seguimiento de los requisitos de un proyecto. Este proceso utiliza herramientas de gestión de requisitos automatizadas para hacer una referencia cruzada de cada requisito que los desarrolladores utilizan para crear una matriz de trazabilidad. Esta matriz ayuda a confirmar que el equipo de desarrollo abordó cada requisito y que el desarrollo solo crea artefactos vinculados a los requisitos. La gestión de los documentos y requisitos es responsabilidad de un tablero de control de configuración.

En ágil, el equipo mantiene la relación entre la función del producto de nivel superior y las tareas de desarrollo de nivel inferior a través de una relación padre/hijo. El gerente de proyecto ágil y el propietario del producto vinculan todas las historias de usuario a su historia principal, y todas las tareas y subtareas se conectan a su historia de usuario principal. Esta relación y flujo inherentes permiten al gerente de proyecto ágil rastrear fácilmente su progreso. La configuración también permite al propietario del producto administrar o reordenar el trabajo en función de las prioridades iniciales y cambiantes.

Cómo reaccionar a los cambios en los requisitos comerciales

Los clientes pueden realizar solicitudes de cambios (RFC, por sus siglas en inglés) y los proveedores pueden redactar y aprobar los requisitos comerciales revisados. Sin embargo, los RFC pueden significar costos adicionales y plazos más largos para los equipos de desarrollo. Además, la gestión de estos cambios es diferente en el desarrollo ágil y no ágil.

Los equipos de cascada y otros estilos de desarrollo a menudo controlan activamente los posibles cambios en los documentos de requisitos comerciales a través del panel de control de cambios. Este organismo aprueba previamente los cambios solicitados y, a veces, también confirma que los cambios aprobados se realizaron según las especificaciones de los clientes.

Los cambios en ágil toman forma ya sea como épicas adicionales o historias de usuarios adicionales según el alcance del RFC. No existe un tablero de control en los equipos ágiles, y el propietario del producto, que trabaja en conjunto con el equipo de desarrollo, cumple esa función. A medida que el cliente o las partes interesadas en el desarrollo están de acuerdo con los cambios de funciones, el equipo ágil escribe nuevas historias de usuario que el propietario del producto debe priorizar en el trabajo pendiente para los desarrolladores. Posteriormente, el equipo de desarrollo debe revisar esas historias en las sesiones de preparación de trabajos pendientes y crear las tareas necesarias. La matriz de trazabilidad de BRD es inherente a la relación padre/hijo entre épicas e historias.

Cómo medir el cumplimiento de los requisitos comerciales

Los equipos ágiles miden el éxito en cada nivel del proceso de desarrollo.

En el nivel de lanzamiento, el propietario del producto continuamente hace concesiones en el alcance, la fecha, el presupuesto y la calidad a medida que llega un flujo de información económicamente importante durante el desarrollo del producto. En última instancia, los equipos ágiles pueden medir el éxito en este nivel mediante la entrega a tiempo de las características del producto que el propietario del producto se comprometió a entregar.

Para llegar a esa entrega, el equipo ágil debe realizar las tareas, completar las historias de usuario y probar la aceptación de cada función. A nivel de tarea, las pruebas unitarias en el código verifican que cumple con el umbral necesario para comprometerse. A nivel de historia de usuario, los miembros del equipo utilizan criterios de aceptación para determinar si satisfacen el aspecto específico de la función. Cuando los desarrolladores completan todas las historias de usuarios con éxito, el equipo puede realizar pruebas de aceptación de usuarios en la función o en la épica.