En ingeniería de software, ¿deberían incluirse requisitos no funcionales en la cartera de pedidos de un producto?

Gracias por el A2A. Jessica Falk y Brad Bigelow ya hicieron un excelente trabajo respondiendo a esto, pero aún daré mis propios pensamientos.

Sí, por dos razones:
1) ¿A dónde más irían? La cartera de productos proviene de usuarios, desarrolladores y propietarios de productos. Los usuarios y propietarios de productos contribuyen con más requisitos no funcionales que cualquier otra persona.
2) El propósito completo de la acumulación de productos es describir todo lo que definirá un producto terminado . Los requisitos no funcionales siguen siendo requisitos. No puede simplemente dejarlos fuera o colocarlos en otro lugar porque son un poco diferentes a otros requisitos.

Si está dividiendo correctamente el trabajo que se coloca en la cartera de pedidos, es posible que ni siquiera necesite los requisitos no funcionales enumerados explícitamente. Me gusta pensar que cada elemento de la cartera de pedidos es una porción vertical de funcionalidad. Entonces, cada capa del producto está encapsulada en cada historia potencialmente. Siguiendo este enfoque, encuentro que la mayoría de mis requisitos no funcionales terminan envueltos en estas historias.

Dicho esto, ocasionalmente tengo requisitos no funcionales que no encajan bien en una historia existente. Estos solo los agrego a la cartera de pedidos para que se realicen un seguimiento adecuado. Entonces sí, agregue todos los requisitos necesarios para la entrega exitosa del proyecto a la cartera y priorícelos adecuadamente.

A2A: Desafortunadamente, no tuve que escribir uno hasta ahora. Por lo tanto, podría ser mejor esperar otras respuestas, pero aún así le diré mi opinión.

Yo diría que sí. Después de todo, la cartera de productos representa los requisitos establecidos en un producto. Los requisitos no funcionales desempeñan un papel importante durante el desarrollo de un producto, ya que define criterios como la mantenibilidad, la seguridad, etc. Esas son todas las cosas que también son importantes durante la creación de un producto y desempeñan un papel en si un producto está realmente terminado. Entonces los agregaría a la cartera de pedidos.

¿Puedo pedirle que aclare lo que quiere decir con requisitos no funcionales? ¿Quiere decir, por ejemplo, código de prueba, código DevOps, código de migración y scripts de bases de datos, etc.? ¿Qué pasa con la deuda tecnológica?

La respuesta breve es que la cartera de pedidos de su producto debe consistir en todas las historias de usuario que deben completarse para entregar el producto según lo definido por el propietario del producto, pero me gustaría darle una respuesta mejor y menos concisa que esa. Aclare su pregunta con algunos ejemplos de requisitos no funcionales y analicemos al respecto. 🙂

A2A no funcional no es un requisito, sino la incapacidad de implementar algo en un producto existente. La acumulación de productos es una serie de errores o nuevas características. Si se supone que el producto hace algo y lo hace, es un error que debe corregirse; Si se trata de una solicitud de nueva funcionalidad, esto debe documentarse no solo en el trabajo atrasado de un producto sino en la siguiente especificación.

Cada producto exitoso tiene una cartera de pedidos que incluye la modificación de la funcionalidad existente o agregar nueva funcionalidad.

Si, deberia. Estar en el backlog no significa solo cosas “palpables” como un botón o un formulario. Los requisitos funcionales definitivamente forman parte del diseño general del producto. Y estar atrasado no significa que realmente se implementarán o incluso se considerarán, pero si se considera importante, deberían estar allí para recibir al menos una discusión justa antes de ser despedidos.

Me gusta la respuesta de Brad. Aquí están mis pensamientos con la advertencia de que tengo muy poca experiencia con el uso “oficial”, con lo que me refiero al uso en equipos que usan scrum de manera explícita y deliberada.

Tiendo a pensar en la acumulación de productos como un nivel (capa de abstracción) sobre una lista de tareas:
Volver a los conceptos básicos de Scrum: elementos de la cartera de productos frente a tareas

Por lo tanto, mi cartera de pedidos casi siempre contendrá requisitos no funcionales (refactorice el bloque de código x para que se ajuste a y [calidad de evolución], mejore la usabilidad de la forma z [calidad de ejecución]). Estos son elementos muy relevantes que impactan el proyecto, requieren esfuerzo y pueden dividirse en tareas del desarrollador, por lo que, en mi opinión, pertenecen al trabajo atrasado.

El mejor enfoque que he escuchado es ver los NFR como una forma de impuesto. Residen fuera de la cartera de productos, pero a medida que se agregan nuevos elementos, se deben aplicar los NFR. Cada elemento de la cartera de pedidos está etiquetado con los NFR que deben considerarse durante el desarrollo y las pruebas del mismo.
Como con cualquier trabajo atrasado, esto no es algo que se haya hecho nunca. A medida que se descubren nuevos NFR, los elementos de la cartera de pedidos existentes deberán revisarse.
Por lo tanto, se debe tener cuidado al mantener vivos demasiados NFR, ya que también son un impuesto en el proceso de gestión de la cartera de pedidos.

A2A: sí

Sí, por lo general, algunos de los requisitos no funcionales deben abordarse en la fase de diseño y descansar como entregas separadas.

si