¿Cuál es la diferencia entre una Historia de Usuario y una Característica en Agile terminología?[cerrado]

Question

Supongo que una característica podría ser algo así como "autorización de tarjeta de crédito", mientras que una historia de usuario se puede "autorizar la tarjeta de crédito de paypal".

Así, es una historia de usuario de un subconjunto de una función?

Answer 1

Sí, algo así como un subconjunto. Este artículo es una buena lectura:
Características vs Historias

Extracto:

  

Me di cuenta hoy que yo no había hecho   explícita la diferencia en mi mente   entre las características y las historias y que es   una diferencia importante. Esencialmente,   una característica es un grupo de historias que   están relacionados y entregar un paquete de   funcionalidad que los usuarios finales se   generalmente esperar para obtener a la vez.   Por ejemplo, la tabla en línea es el cambio de tamaño   una característica (nota: esto es la capacidad   para arrastrar a cambiar el tamaño de tablas, filas y   columnas - probarlo en Word). En el   primera pasada, lo que probablemente tiene una   de una sola planta para cambiar el tamaño de la línea   mesas, pero sería demasiado grande para   estimar. Así se descomponen en   tres historias, cambiar el tamaño de las columnas, cambiar el tamaño   filas y cambiar el tamaño de la propia tabla.

Answer 2

De acuerdo con Kent Beck y Martin Fowler historias y características son sinónimos:

  

Una historia de usuario es un trozo de   funcionalidad (algunas personas utilizan el   palabra característica ) que es de valor para   el cliente.

Lo que se llama a un característica que normalmente se conoce como tema o épica . Temas y epopeyas se utilizan para casos de usuario grupo de grandes conjuntos de características, que tienen sentido por sí mismos.

Desde un punto de vista más semántica: característica es una parte del sistema que está tratando de construir, historia de usuario es una manera de describir esa parte.

---

Corrección:

Como Pascal ha señalado - que tal vez se perdió el verdadero significado de la "característica" en esa cita ( "característica" obviamente se refiere a la funcionalidad) Aparte de esto, sigo pensando que uno puede utilizar estas palabras (función y historia de usuario) como sinónimos en muchos contextos ( "estoy trabajando en esta historia" frente a "estoy trabajando en esta función"), ya que, como dijo Pascal, una historia de usuario es una manera de capturar una característica. Que significa que hay una relación 1: 1 entre los dos. Y, como se puede ver en mi observación acerca de la semántica, esta es la forma en que realmente lo entiendo.

Answer 3

No, en absoluto ..

Una historia de usuario representa una pequeña parte de valor del negocio. Por lo tanto, es muy difícil decir cuando una historia de usuario es un subconjunto de una función o una característica es un subconjunto de una historia de usuario (también tenga en cuenta que las historias de usuario se escriben normalmente por las partes interesadas, que tienden a no saber exactamente lo que quieren ... :))

Por lo tanto, si se sigue la recomendación del ágiles para mantener las historias cortas que se caería en el "mejor" escenario que es la historia de usuario es un subconjunto de la función.

Sin embargo, si su partes interesadas escribir historias largas, cada historia tendría un par de características (si hay una buena comunicación entre el equipo y las partes interesadas que esto no sucederá ya que el equipo va a romper las historias en otras más pequeñas)

Answer 4

Las características son lo que un sistema está haciendo. historias de usuario son sólo una manera de capturar entre otras características.

Answer 5

Me encontré con este tema cuando yo estaba buscando ideas diferentes sobre el "uso de múltiples funciones para los requisitos similares".

Yo creo que una característica como un contenedor de historias relacionadas con el ayuda en la priorización de los requisitos, ya que las partes interesadas suelen decir a sus necesidades como dependiente de historias.En un proyecto reciente, el cliente me dijo de la siguiente manera

Un miembro puede enviar mensajes a los admin El administrador puede enviar mensajes a todos los miembros de la Los miembros pueden enviar mensajes el uno al otro

Cuando veo estos requisitos, sé que, se debe implementar un sistema para permitir a la gente a enviar un mensaje y le debe agregar controles para permitir quién hará qué.

Y también sé que estos requisitos puede tener algunos otros implícito requisitos, tales como la lectura de los mensajes que han llegado, la organización de ellos , se puede establecer como spam y etc.

Así que tratan de reformular estos requisitos como

Como un miembro o administrador, puedo enviar mensajes a otras personas.Como un miembro o administrador, puedo leer los mensajes que me fueron enviados.

Y como los criterios de aceptación, he estado en el detalle que se puede enviar a la oms.

Luego me llama a estas cosas como "mensajes Privados" característica, por lo que, en algún momento posterior, si el cliente decide que es un coste adicional, se puede decir que "Sólo la caída de la mensajería privada de la cosa" y me puede quitar todos ellos de la cartera.