Pregunta

Las historias de usuario se escriben tradicionalmente como la expresión "Como [Tipo de usuario] Quiero [función] para que [algún beneficio]". En los libros y recursos en línea [Tipo de usuario] normalmente se corresponde con un papel de un ser humano. Sin embargo, al describir las funciones de partes internas del sistema, a menudo es más fácil de poner algún servicio sin vigilancia en lugar de un usuario, por ejemplo, "Como ServiceX Quiero algunos datos que se actualizan regularmente para que pueda hacer XYZ utilizando la información más reciente".

Tal forma hace que sea sencillo para escribir fácil de entender las pruebas de aceptación para las partes relacionadas del sistema. ¿Pero esto es conceptualmente correcto? no deben historias de usuario se basan en características dando negocio valor, y dado que los sistemas y servicios que no están interesados ??en la obtención de los valores empresariales, que no debe ser actores de las historias de usuario?

¿Fue útil?

Solución

Sistemas sin duda está interesado en la obtención de valor para el negocio. Un actor puede ser un agente automatizado escrito por un tercero, y que incorpora que la intención de terceros. De hecho, esto se está convirtiendo en una forma dominante de interacción como los servicios web se convierten en una característica más popular de los principales sitios web, lo que permite la interacción entre los sitios complejos en nombre de los usuarios, sino que implica solamente las máquinas.

Otros consejos

No veo por qué un actor debe tener que ser un ser humano -. Su ejemplo es un perfectamente buena razón para que no sea

La cosa con la metodología como esto no es hacer que colgó sobre pegue a las minucias de la práctica definida. Incluso si las personas que originalmente habían subido con el concepto de "historias de usuario" pensamiento de que sólo deben aplicarse a los seres humanos, no hay ninguna ley en su lugar lo que obligó a adhieren rígidamente a sus conceptos.

El punto de historias de usuario, ágiles, scrum, y todas las otras metodologías es ayudar a los con el proceso de desarrollo, no a ser el proceso de desarrollo. Una metodología sólo es valiosa, siempre y cuando se hace mejor el proceso, de manera que de cómo se deben utilizar. Usted debe sentirse libre de adaptar la metodología que se adapte a sus circunstancias únicas. No deje que la metodología sea más importante que el desarrollo de código real.

Aquí está el secreto. No son historias de usuario, pero son escenarios de usuario.

La usuario es lo que hace la interacción -. La máquina, o una persona

La los grupos de interés es la persona o corporación obtener el beneficio de la interacción (que nunca es una máquina; no en esta etapa en el desarrollo de la IA de todos modos). Por lo general hay varias partes interesadas con las necesidades de cualquier proyecto en competencia. El principal interesado puede ser rastreado mediante el trabajo que ha de pagar por el proyecto y por qué.

El usuario es rara vez el actor principal. Por lo general, una parte interesada desea que un usuario haga algo para que ellos, la parte interesada, pueden obtener el beneficio.

Por ejemplo, Twitter inversores quieren los usuarios disfrutar de Twitter para que puedan mantener todas sus opciones para ganar dinero en el futuro. Los jefes quieren que sus secretarias para utilizar procesadores de texto para que puedan recibir cartas mecanografiadas más rápido y cambiar de opinión en el último minuto. Stackoverflow quiere grandes puestos que se upvoted para que puedan obtener sus ingresos por publicidad.

He aquí una entrada de blog que escribí en el sujetos, incluyendo una plantilla que puede utilizar para separar las preocupaciones de los usuarios y los grupos de interés. Lo dejo como ejercicio para que se imaginen que se beneficie cuando usted, el usuario del puesto, lo lee.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top