¿Quieres ver cómo lucen requerimientos terminados? ¿Quieres tener un punto de referencia para comparar tu trabajo y ver cómo vas? ¿O sencillamente no sabes por dónde empezar? No te preocupes, te tengo una solución.
Sigue el link que dejé en la descripción para que puedas descargar de manera gratuita plantillas y ejemplos para documentar los requerimientos. documentos, plantillas e instrumentos que puedes utilizar para aprender más sobre la documentación de requerimientos. Así que ya sabes dónde encontrarlos, solamente sigue el link que está en la descripción.
No olvides suscribirte para seguir recibiendo las notificaciones cuando publiquemos contenido nuevo. ¡Vamos al video! ¡Vamos al video!
Este es Alan Turin, un Product Owner en la organización, quien es el responsable de liderar las actividades de análisis de sistemas. Alan ha sido asignado al desarrollo de un nuevo producto y la compañía tiene altas las expectativas, por lo que le han pedido que se le haga un nuevo producto. iniciar cuanto antes y contribuir para tenerlo listo en un tiempo razonable. Lo que Alan entiende muy bien es que tiene dos responsabilidades. Asegurar que el equipo comprende perfectamente las diferentes necesidades de los stakeholders del producto y asegurar que el equipo construye una solución que satisface correctamente esas necesidades.
La forma de conseguirlo la elegirá conforme comprenda mejor el proyecto y la forma de trabajo que el equipo decida. Alan sabe que primero debe entender la visión inicial de la solución, quiénes son los usuarios y para qué la utilizarán. Alan entiende que esta visión evolucionará con el tiempo, así que no dedicará mucho tiempo a obtener toda la información de los requerimientos, solo interesan inicialmente los objetivos y las actividades generales de los usuarios. Alan recolecta, junto con su equipo de trabajo, algo de información del entorno y del contexto.
¿Dónde están los usuarios? ¿Qué sistemas y productos están ya en uso? ¿Y en qué ambiente va a coexistir el nuevo producto? Comparte esta información con el equipo, quienes comienzan a bosquejar algunas de las necesidades técnicas y características no funcionales. Alan usa esta información para diseñar una estrategia, con la cual podrá alcanzar a sus usuarios cuando sea necesario obtener de ellos información más detallada.
No se limita a elegir una o dos herramientas de obtención de información. Alan sabe que su prioridad no es crear muchos documentos, así que elige la información que debe permanecer registrada y la coloca en la wiki del equipo. Al principio, un par de diagramas y algunas tablas definiendo a los stakeholders y sus objetivos.
Después de acordar la visión inicial y que el equipo ha entendido el contexto, objetivos y el ambiente del sistema, colaboran juntos para elegir la estrategia de desarrollo. Alan sabe que esto determinará cómo harán otras actividades a lo largo de la construcción, la obtención, el refinamiento y la validación de los requerimientos. Si el equipo elige un enfoque en cascada, sabe que habrá una documentación exhaustiva en la que requiere crear diagramas de procesos, casos de uso y especificaciones funcionales.
Si el equipo elige un enfoque iterativo ágil, sabe que las especificaciones se deben limitar a lo que es necesario en el sprint en desarrollo, como las User Stories, los Definition of Dawn y el Manual de la Arquitectura. Si el equipo elige un enfoque Lean o de entrega continua, sabe que las especificaciones se basarán, principalmente, en código que pruebe el producto automática y frecuentemente, en los scripts de deploy y en los manuales de arquitectura. Si el equipo elige una forma de trabajo híbrida y personalizada, en conjunto decidirán cómo gestionar la información de requerimientos. Alan es consciente de que no debe obsesionarse con documentar todo. toda la información.
Le comunica al equipo que solamente deben registrar los acuerdos que permitan dos cosas, el entendimiento común de lo importante y validar que lo que se hizo es correcto. Él y su equipo acuerdan que parte de la información será temporal, pues la estarán escribiendo en pizarras o en hojas de papel sueltas mientras exploran y toman decisiones. También acuerdan.
que las decisiones importantes sí serán documentadas permanentemente. Alan sabe que la validación de la solución requiere varios pasos, no solamente la aceptación del usuario, por lo que procura que algunos pasos sean automatizados en medida de lo posible para evitar procesos burocráticos o de alto costo. Alan hace acuerdos con los usuarios Champion sobre las necesidades de información que tiene el equipo de desarrollo. las fechas que podrán validar las funciones y los mantiene motivados e involucrados en el desarrollo. Aunque Alan no escriba una sola línea de código, la labor que hace incide directamente en la calidad del código que escribirá el equipo y en los aprendizajes que tengan para hacerlo mejor.
El trabajo de Alan es demandante, requiere que constantemente evalúe las circunstancias para adaptarse. pues siempre debe mantener el enfoque en sus dos responsabilidades. El equipo comprende las necesidades y valida que la solución la satisface. Si no se distrae con cosas como obligar a usar ciertos formatos, hacer siempre el mismo tipo de actividades u obsesionarse con la documentación, contribuirá al éxito del proyecto. ¡Suscríbete al canal