Jerarquía de requisitos, lo que debe ser escrito por cada nivel y por quien

 (Berlín, Alemania) A veces, los conceptos Agile más obvios no son tan fáciles de aplicar cuando necesitamos hacer un uso práctico de ellos. Especialmente si necesitamos lograr una visión coherente y común de la visión de un producto o cartera para su posterior implementación. Mi objetivo con esta publicación es compartir una opinión muy personal sobre cómo y quién debe cumplir con los niveles de requisitos Agile.

La ingeniería de requisitos incluye niveles de detalle incrementados, desde la estrategia con descripciones de nivel superior de la cartera o la visión del producto, hasta niveles expertos de requisitos para implementar adecuadamente el producto, la característica y la historia.

Nivel de detalle incremental de requisitos desde la estrategia / visión hasta la implementación

Aprendemos con Agile y Design Thinking que los objetivos cortos y pequeños están configurando gradualmente la estrategia en productos reales. Vimos lo importante que es probar el concepto en una pequeña prueba de conceptos, una vez que llegamos a los niveles de producto y características. Pero, en Agile, los niveles estratégicos en la jerarquía también tienen un papel que cumplir con los requisitos de soporte.

Saga

A través de Sagas, nuestros gerentes deben comunicar no solo la visión de la cartera, sino también:

  • La diferenciación deseada en comparación con los competidores;
  • El rendimiento incremental;
  • Las funcionalidades incrementales;
  • La ambición de la innovación;
  • Las reducciones de costes;
  • Los criterios de distribución del presupuesto;
  • Los objetivos compartidos entre productos: calidad, reducción de costos, optimización arquitectónica o componentes compartidos, negociación de contratos con proveedores comunes, etc.

En resumen, saga es el nivel de los requisitos utilizados para expresar los requisitos de la cartera y las optimizaciones y sinergias deseables entre los productos de propiedad.

Quién debería escribir Sagas?

Desde mi punto de vista personal, las Sagas deben escribirse en el nivel estratégico superior de la organización hasta el nivel de gestión de la cartera de productos.




Epic

Qué deberíamos escribir en el nivel Epic de requisitos?

Los Epics son, en mi opinión, el nivel de requisitos para los productos. Debe escribirse, tanto como sea posible, respetando la misma estructura de la user story: ¿Quién? ¿Qué? ¿Por qué? ¿Cómo?

Contenido típico para un Epic:

  • Aquí es donde el propietario del producto debe expresar su ambición por el producto.
  • En mi opinión, el nivel de requisitos de Epic es el nivel más adecuado para explicar al equipo el contexto de negocios para requerir el conjunto de características o requisitos agrupados en este nivel.
  • Algunas características son tan complejas que representan por su cantidad de historias o por la complejidad de una sola Epopeya.
  • Un Epi también debe reflejar los requisitos provenientes del nivel superior, del nivel de Cartera, expresados ​​por Sagas. Especialmente para requisitos compartidos entre productos en la misma cartera.
  • También deberíamos incluir requisitos no funcionales particulares que se aplicarán directamente para la característica o conjunto de características descritas: Garantía de calidad, seguridad, requisitos legales, etc.

Quién debería escribir epics?

En mi punto de vista personal, las epopeyas deben escribirse en el nivel de Producto. Y de quién depende la industria y cómo está estructurada la organización. Si estamos en industrias de software o digitales, normalmente el propietario del producto es quien conoce el producto y conoce los procesos, el mercado y la forma en que debe manejarse el negocio. Si estamos en industrias más tradicionales, donde el negocio principal no es el software sino que está respaldado por un software, a menudo podemos encontrar un propietario del producto que representa al Negocio y un propietario del producto del departamento de TI que configura los requisitos técnicos específicos. Esta función de Propietario de producto de TI puede ser realizada por el mismo propietario de un producto de TI, por un Scrum Master o por un Arquitecto senior. Normalmente, este es un rol para el recurso de mayor jerarquía capaz de estructurar los requisitos para ser “consumido” / comprendido por el Dev Team.

Debo decir que los requisitos de escritura son probablemente uno de los roles más importantes en la organización y deben ser realizados por quién posee el conocimiento y no por el grado más alto en la jerarquía. Pero la gran cosa con la transformación ágil es la siguiente: desde los niveles estratégicos, los requisitos deben guiar la implementación.




User Stories, tareas y sub tareas

Qué deberíamos escribir en el nivel de user story de los requisitos?

Personalmente, diría que una historia es el nivel más bajo de requisitos detallados. La naturaleza del requisito, como en los niveles anteriores, puede variar: historia técnica / no funcional o funcional y con impacto directo para el usuario, para el producto, para la función. A menudo, debido a la complejidad de algunas características, pueden ser desglosadas en diferentes historias. Y que, vinculados, agrupados, relacionados.

Agile no sobrevive sin Calidad y Pruebas, y los defectos o errores también deben escribirse, describirse adecuadamente para ser replicados. La responsabilidad de informar errores y defectos no solo está restringida a los ingenieros de pruebas. Esta es una responsabilidad general y todos deben escribirlos.

Con respecto a las tareas y tareas secundarias, diría que no son parte de los requisitos, sino simples pasos para respaldar la implementación.

¿Quién las escribirá?

En mi opinión, todo el equipo debe escribir historias, por supuesto considerarlas o no para la implementación es una decisión del Product Owner, tal como su priorización es su responsabilidad.

Libertad para personalizar tipos de problemas por equipo u organización

Debo decir que la personalización de los elementos en backlog varía mucho de una organización a otra. Pero la parte importante aquí es que todos los grupos implicados en un backlog deben compartir los mismos significados para cada elemento o problema de tipo.




Dejar una respuesta

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.