¿Dónde terminan los requisitos y comienza el diseño?

Esta pregunta es un ejemplo perfecto que describe uno de los problemas de raíz y por qué a muchas empresas les gusta y se cambian al desarrollo ágil.

Si está familiarizado con algunos conceptos de desarrollo ágil, comprenderá mi respuesta tal cual. Si no, intente leer sobre scrum, acumulación de productos, definición de hecho, historias de usuarios, retrospectiva, revisión de sprint, etc.

Preguntaría por qué los requisitos tienen que terminar para comenzar el diseño. Esto es al respecto: Si hacemos una retrospectiva de nuestra propia experiencia pasada, podemos decir que los requisitos son elementos cambiantes del proceso de desarrollo de SW y, por lo tanto, también del diseño/desarrollo. Lo que generalmente sucede es que el propietario/gerente del producto comienza a discutir los requisitos y pronto el desarrollador comienza a hacer preguntas/aclaraciones. Muy pronto, los desarrolladores/técnicos en la sala comienzan a pensar en el diseño/desarrollo. en lugar de centrarse en qué y por qué, todos comienzan a pensar en cómo.

Así que aquí está mi sugerencia rápida.

pídale al propietario del producto que comience la discusión con una oración como esta:

I want to do<what> so that I can do <why>

por ejemplo

I want to <create some default users created in the system> so users can <login to the system using their own user credentials>.

ahora todos en la sala deben comenzar a pensar solo en este qué y por qué y pensar solo en las preguntas relacionadas con qué y por qué. por ejemplo, ¿por qué queremos que los usuarios predeterminados se envíen en el sistema? ¿No es la seguridad una preocupación? ¿Es un proceso difícil crear el tiempo de ejecución del usuario? ¿Quiénes serán esos usuarios predeterminados? ¿Qué tipo de permisos se deben otorgar a estos usuarios predeterminados? ¿Cuál debería ser la contraseña predeterminada para esos usuarios? ¿Cuál debería ser la caducidad de la contraseña? ¿Quién comunicará el usuario/pase predeterminado a esos usuarios?

Estas preguntas le dan a la audiencia la capacidad de comprender la utilidad real de la función que el propietario del producto solicita implementar y también todos en la sala permanecerán en la misma página para comprender la función completa y cómo se supone que debe usarse. Intente ceñirse al flujo de trabajo del usuario final y comprenda la necesidad/valor comercial de la función. este tipo de conversaciones las esperaría durante las sesiones de acumulación de productos.

Una vez que el equipo entiende el 60-75% de "qué y por qué", la función está lista para la estimación. En este momento, si las estimaciones de los miembros del equipo están muy alejadas entre sí, uno o más miembros pueden explicar a toda la sala cuál fue su pensamiento detrás de esa estimación y esto conducirá a una discusión de diseño/implementación. Una vez más, esta explicación y discusión del diseño deben tener un límite de tiempo y mantener un nivel muy alto para que todos se sientan cómodos con la solución, ya que para cuando el equipo realmente comience a trabajar en la característica, es posible que algunos requisitos hayan cambiado.

hay más cosas buenas más allá de esta explicación y estoy feliz de ser voluntario o guía si necesita más detalles. avíseme si esta información es útil y si cree que esto es algo que podría querer probar para su equipo.

Su problema tiene más de un aspecto, por lo que básicamente tiene dos preguntas en su publicación:

¿Dónde terminan los requisitos y comienza el diseño?

y

¿Cuándo son apropiadas estas discusiones?

Abordaré estas preguntas por separado:

¿Dónde terminan los requisitos y comienza el diseño?

Tomado literalmente, la respuesta a esta pregunta es: los requisitos no terminan cuando comienza el diseño. Una vez que haya completado sus requisitos iniciales, es muy probable que cambien, por lo que debe implementar un proceso de cambio (por ejemplo, una junta de revisión de cambios en la gestión de proyectos clásica o el mantenimiento de la cartera de productos en SCRUM). Además, cuando se completa el diseño de su producto, debe verificarlo con los requisitos.

Sin embargo, entiendo su pregunta en el sentido de "¿Cuándo terminan los requisitos iniciales?". La respuesta es: depende del enfoque de su proyecto. Si está utilizando un enfoque clásico como cascada o el modelo V, la respuesta es: una vez que se completa la especificación de requisitos. Si utiliza un enfoque ágil (como XP o SCRUM), los requisitos y el diseño se ejecutan en paralelo. Está preparando los requisitos para la próxima iteración mientras los desarrolladores implementan los requisitos actuales.

¿Cuándo son apropiadas estas discusiones?

Admito que la primera parte de la respuesta es un poco técnica y puedo ver que su verdadero problema radica en la forma en que se redactan los requisitos. Para responder a la pregunta, depende de los requisitos en los que esté trabajando:

1. Los requisitos comerciales de alto nivel.
2. Los requisitos de aplicación de nivel inferior.

Si está trabajando en los requisitos comerciales, desea menos aspectos técnicos que cuando trabaja en los requisitos de la aplicación. La razón es bastante simple: cuanto más alto sea su nivel de requisitos, más lejos estará de la implementación y menos importarán estas cosas.

En la práctica rara vez he visto este tipo de distinción; sueles hablar de "los requisitos". Y la cantidad de detalles de diseño que desea incluir en sus requisitos depende de una serie de factores, por ejemplo:

1. ¿Qué tipo de sistema está construyendo? Cuando crea un sistema operativo, no puede crear los requisitos sin muchos detalles técnicos.
2. Cultura de la empresa. Una empresa de tecnología verá la definición de lo que es un requisito de manera diferente a una empresa minorista.
3. El equipo del proyecto. Los desarrolladores ven los requisitos de manera diferente a los analistas de negocios y, según la composición de su equipo, habrá diferentes resultados.

Especialmente en los requisitos de nivel inferior, los detalles técnicos no siempre son algo malo. Por ejemplo:

• Si un requisito dice que la página web diseñada debe usar un diseño web receptivo, probablemente esté bien. Aunque este es un término técnico, describe muy bien lo que se desea como salida.
• Por otro lado, los detalles puramente técnicos como la elección del lenguaje de programación no pertenecen a los requisitos.

Estar en desacuerdo sobre qué es un requisito y qué es un detalle de implementación es bastante común. Aunque tuve la experiencia opuesta: los gerentes de producto a menudo intentan limitar la definición de "qué es un requisito" para descargar el trabajo detallado al equipo de desarrollo (seamos realistas: los requisitos son difíciles).

La mejor respuesta que puedo darle es: Aborde su problema abiertamente con el equipo. Si usted es el único que ve asuntos como este u otros están de acuerdo con usted, tiene un punto válido. Debe encontrar algunas pautas sobre lo que es un requisito (también puede escribirlas como referencia), para que todos estén en la misma página. Si tu equipo funciona bien, no necesitarás moderación, ya que podrán trabajar juntos. Dado que hay un área gris, encontrará una solución con la que probablemente todos puedan vivir. Si tiene alguna fricción en su equipo, debe nombrar a un moderador que todos acepten como neutral. O mejor aún: trate de resolver su fricción, ya que eso también beneficiará al proyecto en otros aspectos.

También debe asegurarse de incluir en su discusión a los miembros de su equipo que utilizarán la especificación de requisitos (desarrolladores, probadores, etc.). Tendrán que trabajar con la especificación, por lo que su punto de vista es importante. Lo que también sería beneficioso es revisar el documento de requisitos que incluye (pero no solo) a estas partes interesadas. La revisión sirve como correctivo en caso de que los requisitos se equivoquen demasiado en la implementación técnica.

Una vez que haya definido claramente qué es un requisito, debería poder redactar un documento de requisitos con el que todos estén satisfechos. Una revisión corregirá cualquier problema que quede.

Depende de quién esté en la habitación.

Idealmente, debe tener un conjunto de requisitos que desarrolle que sean declaraciones completas sobre la funcionalidad sin referencia a la implementación técnica, las herramientas utilizadas, etc. Se supone que los requisitos son como un modelo de un arquitecto que se puede implementar de manera diferente (usando materiales y herramientas) por diferentes constructores. En realidad, las cosas no son tan cortas y secas.

Puede haber casos en los que los requisitos y el diseño se integren entre sí. De hecho, esa probabilidad inevitable es la razón por la que tratamos de hacer pruebas iterativas, creación de prototipos y hacer cosas divertidas como estructuras alámbricas en las que se puede hacer clic para que los clientes jueguen. Es MUY común que el cliente no se dé cuenta completamente de lo que REALMENTE necesita hasta que tenga algo parecido a un software real para interactuar. El diseño, por naturaleza, delineará lo que SE PUEDE hacer (dentro de límites de tiempo/costo razonables) usando la pila de tecnología y las herramientas elegidas. El diseño, por lo tanto, lleva a un lógico "Esto podría hacerse fácilmente con lo que tenemos, ¿quieren esto?" Tipos de conversaciones. Esa retroalimentación circular entre los requisitos, el diseño y el cliente realmente continúa durante toda la vida útil del producto. Ese'

Soy analista de negocios y he tenido sesiones de elicitación de requisitos en las que le pedí a mi Team Lead Tech que se sentara con nosotros debido a su experiencia con la funcionalidad existente de la aplicación, y sabía que sería muy valioso para el cliente mientras trabajaban. qué, exactamente, estaban pidiendo.

En general, cuando se reúnen algunos ingenieros expertos en una sala, se hablará un poco sobre los detalles de implementación. Eso casi siempre es algo bueno, y siempre presto mucha atención a ese tipo de discusión arquitectónica porque me ayuda a dividir la funcionalidad en segmentos lógicos que pueden construirse potencialmente en un sprint de desarrollo. Personalmente, creo que el conocimiento de la arquitectura siempre es una ventaja para un analista de negocios. Lo que desea hacer (en mi opinión) es mantener las etapas iniciales de elicitación enfocadas en el cliente, no en los desarrolladores de software. ¿Qué hace el cliente ahora? ¿Qué creen que quieren hacer? ¿Qué es lo que realmente necesitan hacer? Las primeras etapas consisten en comprender sus procesos comerciales, que son el FUNDAMENTO MISMO de la entrega de VALOR, no solo de la entrega de código. Claramente,

En algún momento, habrá superado un umbral en el que se HAN formalizado los requisitos pero no está completo, los ingenieros SE HAN sentado y comenzado a trabajar en ellos y usted (como equipo) tiene una buena idea de cómo abordará el proyecto. . Es posible que aún tenga sesiones de requisitos, pero a medida que avanza la fase de diseño, lógicamente superará la recopilación de requisitos. Esto no es necesariamente algo malo, pero debe mantener un documento de requisitos limpio ("documento" en términos generales: depende totalmente de cómo esté organizado) que le permita mantener la trazabilidad de los requisitos. Si necesita sacar a los ingenieros de la sala un par de veces para obtener eso, adelante.

Tener un documento de requisitos claro es importante para las pruebas, lo cual es fundamental para las prácticas modernas de desarrollo de aplicaciones empresariales. Esto debe quedar claro en cuanto a los detalles de implementación, pero sin duda puede utilizar la retroalimentación obtenida a partir de la comprensión de lo que se puede hacer con un conjunto determinado de herramientas.

En otras palabras, no está totalmente claro que hablar de implementación esté necesariamente fuera de lugar en una sesión de requisitos, pero la mejor práctica es siempre escribir requisitos de manera que sean "neutrales a la implementación". Mi regla general es no depender demasiado del procedimiento formal si estamos colaborando bien con el cliente y se está logrando mucho, siempre y cuando SÍ tengamos una buena comprensión de hacia dónde se supone que debemos ir.

Para evitar especificar en exceso y anotar las necesidades reales del cliente, puede emplear la siguiente estrategia:

iniciar/convertir cada requisito con "el sistema deberá tener la capacidad de..."

Esta estrategia impide que el cliente entre en el ámbito del diseño sin darse cuenta. (He leído este enfoque en un libro sobre ingeniería de sistemas, citaré la referencia si puedo encontrarla).

Sin embargo; Creo que el cliente puede dictar (bastante) algunas soluciones de diseño si o cuando:

1) el cliente necesita definir un caso de uso (por ejemplo: el usuario ingresa datos usando una pantalla táctil con sus dedos desnudos)

2) hay alguna interfaz para algún sistema existente

3) el diseño está parcialmente definido y el cliente quiere asegurarse de que se mantenga como está

4) el cliente quiere reutilizar algún hardware/software existente como parte de la solución.

He visto varios contratos, algunos que especifican demasiado y otros que definen ampliamente, y la conclusión es que mientras las partes estén contentas, las especificaciones son suficientes. Aunque técnicamente hablando, muchos están lejos de ser ideales.

Por último, el mejor argumento del equipo de diseño en contra de especificar demasiado es: puede olvidar algunos temas ("integridad") y puede resultar en un sistema que no funciona (requisitos en conflicto), lo que puede causar la iteración de un contrato/programa/costo.

Hay tres niveles de requisitos:

1. Requisitos comerciales (por qué necesitamos un sistema).
2. Requisitos del usuario para el software (lo que los usuarios deben poder hacer para habilitar los requisitos comerciales).
3. Requisitos funcionales/no funcionales del software (lo que los desarrolladores deben implementar para habilitar los requisitos del usuario).

Sólo el primer nivel se relaciona con un proyecto empresarial. El segundo y el tercer nivel se relacionan con proyectos de TI y contienen claramente la frase "al software". Por lo tanto, los requisitos comerciales deben definir un problema comercial y las posibles formas de resolverlo, como la compra de licencias de algún producto existente o desarrollar software por sí mismo o comprar una empresa propietaria de ese hermoso software, etc.

Los requisitos comerciales generalmente se definen en un documento de visión y alcance (que contiene oportunidades comerciales, objetivos comerciales, métricas de éxito comercial, riesgos comerciales, limitaciones, alcance, etc.). Otros nombres de este documento: caso de negocio, acta de constitución del proyecto, oportunidad de mercado, etc.

El diseño de software comienza desde los requisitos del usuario hasta el software porque los usuarios comienzan imaginando lo que quieren poder hacer. Por supuesto, sus diseñadores/arquitectos tienen que revisar los requisitos constantemente. Es un ejemplo de integración continua de cualquier información en un proyecto: nadie debería sorprenderse por los resultados de los predecesores.