¿Cuál es la diferencia entre una Historia de usuario y una Función en la terminología Ágil? [cerrado]

Según 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 cliente.

Un función es usualmente referido como tema o épica. Los temas y epopeyas se utilizan para agrupar historias de usuarios en conjuntos de características más grandes, que tienen sentido por sí solos.

De un más punto de vista semántico: 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, tal vez perdí el significado real de" característica " en esa cita ("característica" obviamente se refiere a la funcionalidad) Aparte de esto, todavía creo que se pueden usar estas palabras (característica e historia de usuario) como sinónimos en muchos contextos ("Estoy trabajando en esta historia "vs." Estoy trabajando en esta característica"), ya que, como Pascal dijo, una historia de usuario es una forma de capturar una característica. Lo que significa que hay una relación 1:1 entre esos dos. Y, como se puede ver en mi comentario sobre la semántica, así es como realmente lo entiendo.

Para nada..

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

Entonces, si sigues la recomendación de agile para mantener las historias cortas, caerás en el "mejor" escenario que es que la historia del usuario sea una subconjunto de la característica.

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

Las características son lo que está haciendo un sistema. Las historias de usuario son solo una forma, entre otras, de capturar características.

Acabo de encontrar este tema cuando estaba buscando diferentes ideas sobre "usar múltiples roles para requisitos similares".

Creo que una característica como contenedor para historias relacionadas ayuda a priorizar los requisitos porque los interesados generalmente cuentan sus necesidades como historias dependientes. En un proyecto reciente, el cliente me dijo lo siguiente

Un miembro puede enviar mensajes al administrador El administrador puede enviar mensajes a todos los miembros Los miembros pueden enviar mensajes a cada uno los demás

Cuando veo estos requisitos, sé que deberíamos implementar un sistema que permita a las personas enviar un mensaje y deberíamos agregar comprobaciones para permitir a quién hacer qué.

Y también sé que estos requisitos pueden tener algunos otros requisitos implícitos, como leer los mensajes que llegaron, organizarlos, configurarlos como spam, etc.

Así que trato de reformular estos requisitos como

Como miembro o administrador, puedo enviar mensajes a otras personas. Como miembro o admin, puedo leer los mensajes que me enviaron.

Y como criterio de aceptación, indico en detalle quién puede enviar a quién.

Entonces llamo a todas estas cosas como función de "Mensajería privada", de modo que, en algún momento después, si el cliente decide que es un costo adicional, puede decir "Simplemente elimine la cosa de mensajería privada" y puedo eliminarlas todas del backlog.