Requisitos de Software
Suponga que tiene una visión para un nuevo producto y que su producto requiere algún software especializado para que esa visión se convierta en realidad. Si usted no es un desarrollador, necesita una forma eficaz de comunicar y priorizar sus requisitos críticos de software , mantenerlos bien organizados y hacerlos avanzar a través del desarrollo, las pruebas y la entrega final. En el ciclo de vida de desarrollo de software ágil (SDLC), querrá recurrir a un equipo que tenga las herramientas y los procesos adecuados para la gestión de requisitos básicos .
Proceso ágil de requisitos de software
La cartera de productos
Como equipo ágil, sus requisitos se capturan en lo que se conoce como la acumulación de productos . La mayoría de los equipos ágiles utilizan la acumulación de productos para capturar historias de usuarios . En lugar de crear un conjunto muy detallado de requisitos de software al inicio del proyecto, estas historias de usuario suelen estar escritas en un tono mucho más conversacional. De hecho, las historias de usuario a menudo las escribe el propietario del producto sentado con el cliente y conversando sobre el «quién, qué y por qué» de un requisito o característica en particular.
El propietario del producto también asignará una prioridad y, a menudo, un valor en la acumulación del producto a cada una de las historias de usuario. En conjunto, estos dos atributos ayudan al equipo a comprender en qué elemento de la lista de entregables se trabajará a continuación. En algunos casos, la historia con el valor comercial más alto será el siguiente elemento lógico de trabajo. Sin embargo, puede imaginar un caso en el que se requiera una pieza específica de código de infraestructura para que funcionen otras características, en cuyo caso, se le dará una mayor prioridad en su cartera de pedidos. Como ocurre con casi todo en ágil, estos atributos no pretenden ser valores estáticos. La preparación de la acumulación es un proceso que se utiliza para actualizar las historias de los usuarios y su prioridad y valor en un esfuerzo por garantizar que la acumulación se mantenga actualizada y precisa.
Tamaño de la historia de usuario
Otro componente clave de la historia del usuario es que se le asigna un tamaño . Es posible que se sorprenda al saber que el tamaño no es necesariamente el tamaño del requisito. En cambio, el tamaño es una medida sin unidades que generalmente se considera como puntos de la historia., a la que el equipo llega mediante una estimación consensuada en sus reuniones de planificación. Los equipos de proyecto estimarán la complejidad, el esfuerzo y las dudas asociadas a cada historia de usuario para determinar su tamaño o asignar puntos de historia. Un factor de esta estimación de tamaño que la hace única en la gestión de proyectos es que los puntos de la historia están destinados a reflejar la cantidad de incertidumbre o riesgo que encierra una historia de forma inherente. Un hecho clave para recordar es que, dado que todas las historias tienen el tamaño de la misma técnica de estimación, el valor relativo de cada historia se convierte en una herramienta de planificación útil, particularmente para determinar cuánto trabajo puede abordar el equipo en cualquier iteración.
Confirmación de una historia de usuario para una iteración
Una historia de usuario solo se vuelve realmente activa para el trabajo de desarrollo en una reunión de planificación de iteraciones . En este caso, el propietario del producto se toma el tiempo de revisar la historia del usuario con todo el equipo con cierta extensión, hablando juntos para que todos los miembros del equipo compartan una visión común de los detalles de la historia. A menudo, el equipo hará preguntas adicionales para mayor claridad, y esas preguntas y respuestas se capturarán como parte de la historia del usuario activo. La velocidad es la velocidad a la que el equipo puede desarrollar el software para una historia de usuario. Según el tamaño de la historia y conociendo la velocidad de iteraciones anteriores, se comprometen una o más historiasal equipo para su entrega durante esa iteración. Estas historias se mueven de la cartera de productos a la iteración activa a través de este proceso de compromiso.
Herramientas de gestión de requisitos
La cantidad de herramientas disponibles para administrar toda esta información ha crecido significativamente con el tiempo. Muchas de las herramientas disponibles comercialmente disponibles en la actualidad buscan proporcionar otras características de desarrollo de software además de la funcionalidad básica de gestión de requisitos. Por ejemplo, puede encontrar herramientas que brinden administración de defectos, herramientas de desarrollo y prueba, modelado de software, administración de carteras, administración de procesos comerciales y más.
En términos de una herramienta para utilizar la gestión de requisitos, tenga en cuenta los siguientes atributos generales:
- La herramienta debe ser fácil de usar para todos los miembros del equipo. Una herramienta que no se utiliza activamente aporta poco o ningún valor al equipo en su conjunto.
- La herramienta debe admitir todos los procesos básicos de gestión de requisitos. La captura de historias, el tamaño y la priorización de trabajos pendientes deben ser fácilmente accesibles.
- La herramienta que elija debe agregar algún valor de comunicación al proceso de gestión de requisitos. La comunicación es clave para la buena salud del equipo ágil, y querrá herramientas que lo ayuden a crear y luego compartir historias de usuarios con todo el equipo.
Resumen de la lección
En el desarrollo de software ágil, los equipos de proyecto recopilan los requisitos del software mediante herramientas y procesos específicos. La gestión de requisitos es compleja y cambia constantemente, y la forma en que un equipo gestiona los requisitos determinará si un equipo desarrolla un producto de calidad y oportuno. Los equipos desarrollan historias de usuarios que representan los requisitos del software y asignan valores a la historia mediante el dimensionamiento o la asignación de puntos de la historia . La preparación del trabajo pendiente es un proceso que el equipo utiliza para garantizar que el trabajo pendiente esté actualizado y sea preciso para priorizar el trabajo de forma continua. Durante las reuniones de planificación de iteraciones , valores como el tamaño y la velocidad de la historiase utilizan para determinar cuántas historias de usuario puede comprometer el equipo durante una iteración.
Continúa con:
- Profesiones
Médico de animales: requisitos para convertirse en veterinario
Un médico de animales es un veterinario que realiza controles de salud, diagnostica y trata...
- Enfermería
Dispositivos de asistencia al paciente: identificación y gestión
Introducción Como enfermero, atenderá a una gran población de personas con diversas necesidades, afecciones y...
- Marketing
Gestión de publicidad global
Publicidad global ¿Alguna vez se ha preguntado cuál es la diferencia entre la publicidad global...
- Enfermería
Gestión de pacientes para dispositivos de marcapasos
Breve descripción de los marcapasos Jerome es una enfermera encargada de administrar pacientes con dispositivos...
