historias de usuario para los requisitos funcionales [cerrada]

Question

Como somos una pequeña empresa, tanto trabajo como un director de proyecto y desarrollador. Las especificaciones que creo para los clientes contienen una serie de elementos que se utilizan para describir y definir el proyecto, incluyendo las historias de usuario, junto con cualesquiera otros elementos que siento necesita ser incluido para definir el proyecto (por ejemplo, wireframes, userflows, mapas de sitio, etc.) al cliente.

Si una especificación funcional “se describe cómo funcionará un producto enteramente desde la perspectiva del usuario. No importa cómo se implementa la cosa. Se habla de características. “. Entonces, ¿alguien ve ningún problema con el uso de historias de los usuarios para definir una especificación funcional para un sitio web? ¿Hay alguien que realmente hacen las especificaciones funcionales de esta manera?

Realmente estoy tratando de mejorar mi juego un poco, y se pregunta si esto se acercaría trabajaría para los clientes más grandes que tal vez tienen ideas más estrictas sobre lo que es una especificación funcional debe contener, por lo que puede ser necesario un enfoque formal. Sin duda en el momento en que nuestros clientes responden bien a nuestro método de producción de documentación.

Estoy interesado en escuchar lo que la gente que hace la gestión de proyectos profesionalmente piensan acerca de esto.

Answer 1

Estoy en desacuerdo con lo que un par de otras personas han dicho.

En primer lugar el bit Estoy de acuerdo con - historias son una gran manera de plantear requisitos funcionales. Para mi dinero son una de las mejores maneras de requisitos realidad se comunican de una manera realmente los usuarios finales tendrán. Yo he visto demasiadas especificaciones que se firman fuera sin haber sido leído.

Lo único que diría es posible que desee agregar a ellos no es funcional requisitos - que cubren el rendimiento, la seguridad, los volúmenes de datos, auditoría, archivo y así sucesivamente. Mientras que pueden ser cubiertos en las historias, a veces son mejores cubierto de una manera que cruza todas las historias.

En cuanto a si es conveniente para las grandes empresas aquí es donde no estoy de acuerdo. En mi experiencia (y que he hecho proyectos de Shell, American Express, un par de bancos multinacionales y otros) a menudo son más formales que las empresas más pequeñas para que estén bien con historias. La realidad es que un usuario en una empresa grande no es mejor equipado (o interesados) en diagramas de clases y de secuencia de lectura de lo que son en otro lugar.

El tamaño y la complejidad del proyecto pueden requerir requisitos más detallados pero es el tamaño del proyecto, no el tamaño de la empresa que importa cuando se está determinando cómo documento de requisitos.

Para mí la mejor documentación de los requisitos es la documentación que se adapta a su audiencia, y para mí las historias de usuario ha puesto el dedo en la cabeza la mayor parte del tiempo - son lo suficientemente corto y suficiente como para que cuando firman apagado que quieren decir algo claro debido a que han leído y entendido (a diferencia de la señal fuera de una especificación de 100 páginas que invariablemente significa que en realidad no lo han leído), pero lo suficientemente bueno para los desarrolladores trabajar a partir también.

Answer 2

Sí, puede utilizar las historias de usuario para su requiere funcional. Lo hago todo el tiempo, y han sido durante años. En mi opinión, funciona muy bien, y mejor que otros sistemas que he utilizado.

Que este trabajo enfoque para los clientes más grandes? Para hacer una burda generalización, no. Ellos van a tener algún sistema que utilizan para definir los requisitos, y que probablemente no sus historias de usuario. Si viene con historias de usuario, no va a haber una desconexión con las prácticas actuales, que tendrá que trabajar a través.

He tenido éxito usando las historias de usuario con las organizaciones más grandes, pero se necesitará un esfuerzo concertado, que ambas partes necesitan ser comprometido.

Answer 3

Lo que usted describe son los escenarios de casos de uso que definen las características, esto es lo que se requiere desde una perspectiva de usabilidad y es exactamente lo que el cliente va a entender y aceptar. maquetas de pantalla y diagramas de flujo sin duda nos ayudará tanto al cliente como a los desarrolladores.

Una especificación de implementación puede entonces ser necesaria para instruir a los desarrolladores sobre lo que debe ser incluido en la construcción real, la profundidad de esto será determinado por su capacidad de desarrolladores que incluyen el conocimiento de la Casa de la configuración / marco y metodologías / convenciones y puede incluir detalles sobre qué impactos varias partes de la aplicación.

También trabajamos en equipos pequeños (a veces uno o dos desarrolladores) y creemos que el anterior es todo lo que se requiere en este caso.

Las empresas más grandes con equipos mucho más grandes pueden utilizar software de modelado, diagramas UML y otras especificaciones más detalladas. En el caso en el que el desarrollador principal, que todavía debe pasar el tiempo el diseño de su aplicación, pero si nadie se va a revisar los diseños e insistir en todos los trámites, el tiempo es mejor gastar la implementación del software.