¿Cómo mantener una discusión sobre la recopilación de requisitos enfocada en las necesidades del negocio y no en los detalles técnicos?

La forma más fácil es organizar una serie de entrevistas con sus clientes. Durante la primera sesión, hablas sobre el producto, creas algunos bocetos en papel o en la pizarra sobre cómo debe funcionar el producto (puede ser una buena idea grabar la sesión con el permiso de los clientes). Después de eso, vuelves al equipo y juntos crean algunos pretotipos basados ​​en los datos recopilados y juegan con ellos.

Los pretotipos deberían darte ideas sobre el trabajo al que te enfrentas, y lo más probable es que también tengas muchas preguntas. Llamas a la segunda sesión, donde entregas los pretotipos a tus clientes y haces tus preguntas. La sesión debe terminar con un conjunto de casos de uso en orden de prioridad. Estos casos de uso serán sus requisitos. Si te enfocas en los casos de uso, puedes evitar hablar de detalles técnicos.

Como mencionó Zsolt, no hay otra forma de recopilar requisitos que ponerse en contacto con el negocio.

Como mencionó que es un recién graduado, aún puede considerar confundir las diferencias entre las especificaciones técnicas y funcionales. Si ese es el caso, puede echar un vistazo a este artículo de Joel: Especificaciones funcionales indoloras - Parte 1: ¿Por qué molestarse?

En algún momento, establece claramente la diferencia entre las especificaciones funcionales y técnicas (esa podría ser la más obvia para todos, pero no la había escuchado hasta que leí este artículo):

• Las especificaciones funcionales definen QUÉ va a hacer la aplicación;
• Las especificaciones técnicas definen CÓMO se van a construir las cosas.

Espero que ya hayas visto esta definición en otro lugar. Si no, espero que te ayude ahora.

"Entonces, ¿cuál es la mejor manera de recopilar los requisitos comerciales?"

Como han dicho otros, trabajar directamente con las empresas, los gerentes y el personal (PYME) es la mejor manera. Dado eso, no puedes simplemente preguntarles lo que quieren; esa es una pregunta abierta. La creación de un prototipo es una buena manera de dar retroalimentación sobre los requisitos, pero es mucho mejor si tiene una comprensión de los requisitos primero, o puede terminar en un ciclo interminable de creación de prototipos.

Por lo tanto, pregunte a la empresa qué deben hacer y qué información necesitan para hacerlo; esta publicación, Ataque de requisitos lo dice bastante bien.

Traducción de requisitos con historias de usuario

En lugar de intentar responder a toda la pregunta, voy a responder solo la parte sobre la traducción de los requisitos porque creo que a menudo es la que menos se entiende. Tu preguntaste:

¿Existe una buena manera de traducir los requisitos comerciales en requisitos de desarrollo de software?

Hay muchas maneras de hacer esto, pero una de las técnicas ágiles más útiles es la historia del usuario . Una historia de usuario contiene una perspectiva ("Como..."), un resultado ("Quiero...") y algo de contexto ("para que...") que proporciona un marco sólido para definir el alcance y los aspectos técnicos. tareas que cumplan con los requisitos del negocio.

Por supuesto, como técnica ágil, las historias de usuario son inherentemente iterativas. Mike Cohn señala que:

[Una] historia de usuario... está incompleta hasta que ocurren las discusiones sobre esa historia.

En otras palabras, si bien las historias de los usuarios son un excelente punto de partida para generar valor, no reemplazan la necesidad de una interacción continua y comentarios de rutina entre el equipo de desarrollo y los usuarios finales (o sus representantes, como el propietario del producto).

No importa qué tan lejos llegues a la madriguera del conejo, aún necesitas un circuito de retroalimentación. Por ejemplo, convertir historias de usuarios en pruebas de aceptación con Cucumber a menudo genera un acuerdo inicial (idealmente utilizando un lenguaje específico del dominio apropiado para el negocio) sobre lo que realmente significa la especificación. Sin embargo, todavía es extremadamente común descubrir casos de uso adicionales o requisitos ocultos solo después de que se cumple un requisito, que luego requiere refinamiento o refactorización.

He aquí un ejemplo concreto. Tuve un cliente que especificó que quería que todos los registros de una tabla de base de datos estuvieran disponibles en una sola pantalla de interfaz de usuario --- sin paginación, sin Ajax o llamadas a procedimientos remotos, solo acceso local a todos los registros entregados en un solo lote al cliente . La función se entregó, habiendo cumplido con todos los criterios de aceptación especificados originalmente... y luego se rediseñó porque no cumplía con las expectativas de rendimiento de los usuarios finales.

A veces esto sucede porque el resultado final es inesperado o imprevisto y, a veces, sucede porque la organización acepta el riesgo empresarial, apostando a que un atajo valdrá la pena. Cualquiera que sea la razón, sin embargo, es bastante común que el refinamiento y la reevaluación continuos se integren en marcos de desarrollo ágiles.

Los requisitos deben ser documentos vivos

La mayoría de los problemas con la gestión de proyectos provienen de tratar el documento de requisitos (ya sea una especificación formal o un conjunto de historias de usuarios) como un artefacto histórico. Las historias de usuarios hacen que tratar los requisitos como documentos vivos sea más intuitivo y fomentan debates informados sobre el alcance, el riesgo y la facilidad de uso.

Si los usuarios finales y los desarrolladores no se mantienen comprometidos entre sí de forma rutinaria en un ciclo de retroalimentación estrecho, prácticamente se garantiza que:

1. El negocio pedirá las cosas equivocadas.
2. El equipo de desarrollo entregará cosas inutilizables.

Los documentos de requisitos son, desde un punto de vista, un indicador de las expectativas del usuario final. Si crea un buen circuito de retroalimentación en su proyecto y revisa los requisitos a lo largo del ciclo de vida de su proyecto, estará en una mejor posición para administrar esas expectativas con éxito.