¿Cuál es la diferencia entre historias de usuarios y características?

25

Jugando con icescrum , me di cuenta de que no entiendo la diferencia entre las historias de usuario y las características del usuario.

¿Alguien puede explicar la diferencia?

agile scrum features BЈовић
fuente

Respuestas:

23

Una característica es un elemento distintivo de funcionalidad que puede proporcionar capacidades a la empresa.

Una historia es un pequeño aspecto de una característica que puede utilizar para obtener comentarios de sus partes interesadas y averiguar si está haciendo algo mal.

Por ejemplo, una característica podría ser "permitir a los usuarios comentar artículos". Las historias asociadas con esa característica podrían ser:

  • guardar comentarios
  • filtrar comentarios por palabras groseras
  • limitar comentarios a 400 caracteres y retroalimentar a los usuarios
  • agregue captchas para evitar que los bots envíen spam al sitio
  • permitir a los usuarios iniciar sesión a través de la identificación de Google

etc.

En cada etapa podemos obtener retroalimentación sobre si la dirección que estamos tomando es útil.

Algunos equipos no se molestan en dividir las características en historias. Está bien.

Lunivore
fuente
13
¿No son esas historias asociadas realmente tareas de historias de usuario? Yo diría que lo son. Una historia de usuario sería: Como usuario, me gustaría comentar artículos para que nosotros, como usuarios, podamos mejorar el contenido del artículo o expresar inquietudes. Esta historia de usuario se desglosaría en tareas que usted describió ...
Robert Koritnik
44
Considero que una tarea es algo que debe hacerse para obtener retroalimentación, pero sobre la cual no puede obtener retroalimentación solo, por ejemplo, crear una tabla de base de datos. Cualquiera de estas historias, excepto la primera, podría eliminarse y dejar valor en el envío. Las tareas generalmente se cortan horizontalmente en mi mundo. Pero, si tiene diferentes definiciones, está bien. La granularidad no es una cosa completamente discreta, cada objetivo es un objetivo secundario de otro, y creo que debes hacer lo que sea pragmático para ti. Este desglose me parece útil, al igual que muchos de mis equipos.
Lunivore
16

Características == Historias de usuarios.

La palabrería está dictada por la metodología ágil dada que se emplea.

Las diferentes metodologías usan diferentes terminologías para referirse a las características. Depende del equipo decidir qué metodología o terminología usar. Extreme Programming (XP) usa los términos Historias de usuario o Historias para representar características; Scrum usa la cartera de productos para describir una lista de características; El desarrollo basado en funciones utiliza la función; y DSDM usa Requisito. Del mismo modo, hay varias versiones livianas del Proceso Unificado, o Agile UP, que usan Requisito y / o Caso de Uso para definir la funcionalidad de entrega incremental. En última instancia, el objetivo es el mismo: entregar valor comercial regularmente en pequeños incrementos, y más temprano que tarde.

Aaron McIver
fuente
+1, esto lo explica bien. No necesariamente diría la característica == historia del usuario, excepto cuando habla sobre el valor comercial o el valor del cliente. En otros casos, el término respectivo podría no tener un significado.
murrekatt
2
No creo que se pueda decir que son iguales, incluso si son términos relacionados. ¿Qué pasa con las características que abarcan varias historias de usuarios?
sleske
@sleske Una historia de usuario en un enfoque de Scrum puro debe ser un valor agregado para el usuario y, por lo tanto, una característica. Si vamos a catalogar las características como Epics generales, está bien, pero el resultado final son las historias de los usuarios que ofrecen valor.
Aaron McIver
1
@AaronMcIver: Sí, eso es cierto. Sin embargo, a veces la cantidad mínima de funcionalidad que es realmente útil para el usuario (= función) es demasiado para una historia de usuario (o incluso para una iteración). En ese caso, debe desglosar la función en varias historias.
sleske
Por cierto, preguntas y respuestas relacionadas: stackoverflow.com/questions/1714557/…
sleske
7

Una historia de usuario es una declaración informal en el idioma del cliente que captura la intención de algo que el cliente desea lograr. Puede pensar en una historia de usuario como una declaración informal de requisitos.

Una característica de software es una característica distintiva del software que contribuye al diseño general y la funcionalidad del software.

Un par de consideraciones clave:

  • Una historia puede describir una característica , pero una característica nunca describe una historia .
  • Una historia podría no describir directamente una característica .
  • Una historia puede implicar la inclusión de una serie de características .
  • Una característica , ya sea individualmente o como miembro de una colección de características , puede capturar la intención de una historia .

Con todo esto en mente, tiendo a pensar en las historias como descripciones. Requisitos básicamente informales que me dicen lo que quiere el cliente. Características, por otro lado, tiendo a pensar más en una especificación que me dice cómo debe funcionar un sistema para cumplir con los requisitos de los clientes.

S.Robins
fuente
3

Los dos términos están estrechamente relacionados, pero hay algunas diferencias.

Primero, provienen de diferentes dominios. El término "característica" es un término bastante general para alguna parte de la funcionalidad de un software, mientras que la "historia de usuario" fue inventada y en realidad solo se usa en el contexto del desarrollo ágil de software.

En la práctica, muy a menudo coinciden, ya que una historia de usuario consiste en implementar una determinada característica.

Sin embargo, en algunas situaciones pueden ser diferentes:

  • A menudo, una característica es demasiado trabajo para una sola historia de usuario. Las historias de usuarios no deben ser demasiado grandes (generalmente no más de unos pocos días, máximo 1-2 semanas de trabajo). Obviamente, muchas características son mucho más grandes. En ese caso, se implementará una función en muchas historias de usuarios. Algunas personas usan "epopeyas" para agrupar historias de usuarios, en ese caso se podría decir que la función es épica.
  • Los requisitos no funcionales (rendimiento, seguridad, compatibilidad, etc.) también se pueden manejar como historias de usuario (aunque esto no se acepta universalmente). En ese caso, el resultado de la historia del usuario normalmente no se llamaría una función (a menos que llame a "nuestra aplicación raramente se cuelga" una función).
sleske
fuente