Priorizar los requisitos funcionales y no funcionales en Agile

Hay dos enfoques que he visto para esto.

1. El equipo de desarrollo posee calidad de ingeniería.

Con este enfoque, las partes interesadas no técnicas (y el propietario del producto si usa Scrum) se centran únicamente en los requisitos funcionales. El equipo de desarrollo posee el lado no funcional de las cosas, establecerá sus propios estándares no funcionales y agregará sus propios elementos de trabajo a la cartera de pedidos para cumplir con esos estándares.

Por ejemplo, un equipo de desarrollo podría decir algo como:

• El tiempo de respuesta de la página en un servidor representativo no será inferior a 4 segundos
• Todas las características clave serán monitoreadas
• Se realizará una copia de seguridad de todos los datos y se pueden restaurar en 8 horas o menos

Luego, el equipo trabajaría en los requisitos funcionales, pero siempre asegurándose de que se cumplan sus estándares de ingeniería.

2. Crear historias de usuario para requisitos no funcionales

En este enfoque, los requisitos no funcionales se representan en la cartera de pedidos. Esto podría incluir historias como:

Como usuario quiero que las páginas web vuelvan en menos de 4 segundos para disfrutar de mi experiencia de navegación

Como usuario, quiero estar seguro de que mis datos no se perderán en caso de que falle el servidor para no preocuparme por la pérdida de datos.

Como usuario, quiero estar seguro de que el informe de mi producto es preciso y que los números se concilian para poder utilizar los datos del informe con confianza.

Estas historias de usuarios se priorizarían junto con las funcionales en la cartera de productos.

Scrum se basa en los principios y fundamentos de la metodología Agile.

Un principio clave es el reconocimiento de que los clientes pueden, y probablemente cambiarán, de opinión (lo que quieren, cómo lo quieren y cuándo lo quieren). Esta volatilidad significa que los requisitos no pueden abordarse fácilmente de manera predictiva o planificada tradicional.

El Product Owner (PO) es uno de los tres roles definidos dentro de la metodología Scrum. Suele ser alguien con un conocimiento sólido del negocio, la organización y el mercado que representa a las partes interesadas en el proyecto.

PO es responsable de crear una lista priorizada de requisitos llamada acumulación de productos (puede trabajar directamente con un gerente de producto para poder evaluar los requisitos de la acumulación de productos). Estos requisitos están organizados por temas (agregación de requisitos), epopeyas (grandes requisitos que deben detallarse) e historias (requisitos detallados vistos desde la perspectiva del usuario del producto).

Luego, el equipo estima estos requisitos utilizando técnicas como el póquer de planificación.

Durante la planificación del sprint, el PO describe los requisitos prioritarios del equipo. Esta descripción permite una planificación más detallada de las actividades requeridas para desarrollar los requisitos prioritarios.

Para responder a su pregunta, la priorización de los requisitos se realiza en dos etapas diferentes

• Al crear la cartera de productos. Aquí tenemos a los interesados ​​con PO. La priorización aquí depende en gran medida de los objetivos que las partes interesadas están tratando de lograr. Supongamos que estamos creando dos aplicaciones (una para Android y otra para iOS) y las partes interesadas dan una conferencia (por el motivo que sea) en la que quieren mostrar el producto a una audiencia que utiliza principalmente iPhones, querrán dar prioridad a iOS. aplicación

• Durante la Planificación del Sprint. Aquí tenemos PO y equipo. Esta etapa sucede después de la mencionada anteriormente, por lo que los requisitos ya tienen una prioridad específica adjunta y acordada por las partes interesadas. No obstante, la prioridad para el sprint por delante puede cambiar debido a las limitaciones que surgen. Por ejemplo, trabajé como desarrollador con un equipo que tuvo que reorganizar ciertas prioridades porque las maquetas aún no se habían aprobado (fue un caso muy inusual en el que la solución se tuvo que hacer para ayer, las historias de usuario se crearon sin mucha información y diseño predefinido pero las cosas tenían que moverse debido).

PD: puede que le guste la siguiente pregunta que le he hecho .