Supongo que una característica podría ser algo así como "autorización de tarjeta de crédito", mientras que una historia de usuario puede ser "autorizar tarjeta de crédito para PayPal".¿Cuál es la diferencia entre una historia de usuario y una característica en terminología ágil?
Entonces, ¿la historia de un usuario es un subconjunto de una característica?
Sí, algo así como un subconjunto. Este artículo es una buena lectura:
Features vs Stories
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 es un importante diferencia. Básicamente, una característica es un grupo de historias que están relacionadas y entregan un paquete de funcionalidad que los usuarios finales esperarían en general. Por ejemplo, el cambio de tamaño de tabla en línea es una característica (nota: esta es la capacidad de arrastrar para cambiar el tamaño de tablas, filas y columnas - pruébelo en Word). En la primera pasada , probablemente tenga una sola historia para cambiar el tamaño en línea de las tablas , pero sería demasiado grande para estimar . Por lo tanto, puede dividirlo en tres pisos, cambiar el tamaño de las columnas, cambiar el tamaño de las filas y cambiar el tamaño de la tabla.
Eche un vistazo a la publicación 'Diego's' en esta página, una perspectiva refrescante. –
Gracias ... Ese es un buen enlace que ha publicado también. Cada vez que leo la experiencia de alguien que está repensando lo que hace, me hace pensar en el tema de otra manera. Esa es una de las razones por las que creo que este sitio es increíble. Siempre aprendes –
Sentimientos exactos aquí :) –
No, en absoluto ..
Una historia de usuario representa una pequeña parte de valor del negocio. Así que 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 usuarios generalmente las escriben los interesados, que tienden a no saber exactamente lo que quieren ... :))
Por lo tanto, si sigues la recomendación de ágil para mantener las historias cortas, estarás en el "mejor" escenario, ya que la historia del usuario es un subconjunto de la función.
Sin embargo, si su parte interesada escribe largas historias, cada historia tendrá 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)
Según Kent Beck and Martin Fowler historias y características son sinónimos:
una historia de usuario es un trozo de funcionalidad (algunas personas usan la palabra característica) que tiene un valor de para el cliente.
Lo que se llama a una funciónque normalmente se conoce como tema o épica. Los temas y las epopeyas se usan para agrupar historias de usuarios en conjuntos de características más grandes, que tienen sentido por sí mismos.
Desde un punto de vista más semántico: la característica es una parte del sistema que está intentando construir, la historia del usuario es una forma 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 usar estas palabras (característica e historia del usuario) como sinónimos en muchos contextos ("Estoy trabajando en esta historia" vs. "Estoy trabajando en esta característica"), ya que, como dijo Pascal, la historia de un 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.
"Lo que llamas una característica se conoce generalmente como tema o épica", me gusta esta analogía. :) –
He borrado mi comentario por accidente, así que lo estoy volviendo por motivos de claridad: ¿está seguro de que algunas personas usan la palabra función no se aplica a la funcionalidad? –
Por cierto, realmente me gusta el apéndice incluso si tengo otro punto de vista (personalmente, veo la relación como * user story => función * sin equivalencia estricta). –
Las características son lo que hace un sistema. Las historias de usuario son solo una forma entre otras de capturar características.
Mi punto, Pascal;) –
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 de historias relacionadas ayuda a priorizar los requisitos porque las partes interesadas normalmente cuentan sus necesidades como historias dependientes. En un reciente proyecto, el cliente me dijo de la siguiente manera
un miembro puede enviar mensajes al admin admin puede enviar mensajes a todos los miembros Los miembros pueden enviar mensajes entre sí
cuando veo estos requisitos, i Sé que deberíamos implementar un sistema para permitir que las personas envíen un mensaje y deberíamos agregar controles para permitir a quién hacer qué.
y también sé que estos requisitos pueden tener algunos otros requisitos implícitos tales como la lectura de los mensajes que vienen, la organización de ellos, puede estar fijándose como spam, etc
así que trato de reformular estos requisitos como
Como miembro o administrador, puedo enviar mensajes a otras personas. Como miembro o administrador, puedo leer mensajes que me fueron enviados.
Y como los criterios de aceptación, declaro en detalle quién puede enviar a quién.
Luego llamo a todas estas cosas como la función de "Mensajería privada", de modo que, en algún momento más adelante, si el cliente decide que es un costo adicional, puede decir "Simplemente deje de enviar mensajes privados" y yo puedo eliminar todos ellos de la acumulación.
Una tienda de usuario ágil debe ser centrada en la persona. Por ejemplo: "Como propietario de una cuenta, puedo autorizar mi tarjeta de crédito para Paypal". Después de eso, querrás obtener criterios de éxito detallados. – Jay
Existen modelos de UML para explicar las relaciones de Historias, atrasos, etc. en http://scalingsoftwareagility.files.wordpress.com/2007/03/a-lean-and-scalable-requirements-information-model-for-agile- enterprises-pdf.pdf – Fuhrmanator