Agile Methodology

Características de la historia del usuario en la metodología de scrum ágil – Yodiz Project Management Blog


 Características de la historia de usuario en la metodología de scrum ágil

La historia de usuario es una descripción de objetivo, que ayuda a una persona a lograr una función. Para que pueda utilizar esa característica cuando usa la aplicación de software.

La historia del usuario es una parte del proceso de desarrollo Agile. Cada proceso tiene algunas características que lo hacen claro y conciso. La historia del usuario es un primer proceso es el proceso de desarrollo Agile. Una buena historia de usuario puede transmitir una buena comprensión al programador sobre los requisitos.
La historia del usuario es una descripción de las características valiosas del usuario, la buena historia del usuario debe incluir los roles, funciones y valor comercial de tres elementos.

Como ( Rol)
Quiero (Qué)
De modo que (Por qué, Beneficio)

Las historias de usuario son la técnica ágil más popular. Ayuda a capturar la funcionalidad del producto. Las historias de usuario facilitan el trabajo. La definición de una historia de usuario efectiva puede ser difícil. Estos consejos dados le ayudarán a crear historias de usuario efectivas.

Microsoft Press define Criterios de aceptación como:

"Condiciones que un producto de software debe cumplir para ser aceptado por un usuario, cliente u otro interesado".

Google define Criterios de aceptación como:

"Estándares o requisitos preestablecidos que un producto o proyecto debe cumplir".

Características de la historia del usuario

Aquí hay una lista breve pero informativa de las características de la historia del usuario.

  • A una buena historia de usuario debe ser lo suficientemente completa como para proporcionarle algún valor a un usuario.
  • La buena historia del usuario debe estar centrada en el usuario, normalmente la gente escribe la historia del usuario demasiado centrada en los componentes o aspectos del sistema.
  • Al escribir una historia de usuario, concéntrese en lo que el usuario está haciendo o en la historia.
  • El objetivo es que, cuando finalice la historia del usuario, la historia del usuario tenga algún valor para los usuarios.
  • Agrupe las historias de usuarios que ofrecen una función en el mismo dominio, o es bueno agrupar una determinada característica o caso de uso en una sola o múltiples Épicas.
  • Una buena historia de usuario está escrita en una o tres líneas.
  • Algunas historias de usuarios tienen archivos adjuntos para elaborar la historia del usuario más claramente.
  • La buena historia del usuario está bien definida, bien detallado y completo.
  • Una buena historia de usuario es útil para capturar una funcionalidad específica.
  • La participación del equipo de desarrollo en la historia del usuario es importante.
  • Una buena historia de usuario es simple y conciso.
  • La buena historia de usuario siempre debe estar en voz activa. No use términos ambiguos y confusos.
  • La buena historia de usuario solo se enfoca en la parte importante y deja de lado el resto.
  • Comience con una épica, cuando escriba una historia de usuario sobre un nuevo producto y característica, ya que permite capturar el contenido idea sobre el producto con menos detalles.
  • User Stories se usa para comunicar información, así que sea visible y accesible.
  • Las buenas historias de usuario se complementan con otras técnicas como mapas de historias, bocetos, maquetas, guiones gráficos y diagramas de flujo de trabajo, etc. .
  • Trate de evitar las dependencias entre las historias, las dependencias entre las historias tendrán prioridad y problemas de planificación.
  • La historia debe ser negociable. La historia del usuario debe cambiarse o eliminarse sin impacto para todo lo demás.
  • La mejor historia de usuario valiosa es aquella escrita por el usuario o el cliente. Dé valor a cada historia de usuario que escribe por usuario del cliente.
  • Los desarrolladores deben ser capaces de predecir (al menos una aproximación aproximada). Predicen la escala de tiempo de las historias y para lograr la codificación deseada.
  • La historia de la escala depende del tamaño del equipo, del grupo de desarrollo de capacidades y de la realización técnica.
  • Una buena historia de usuario es una historia que es fácil comprobable. No podemos desarrollar, lo que no podemos probar. Una historia de usuario no comprobable es: "el software debe ser fácil y agradable de usar".

Hay dos métodos de ayuda para escribir historias de usuario:

  • Invest (Esta técnica es útil para la historia del usuario)
  • Inteligente (SMART es para las tareas de una historia de usuario)

Cuenta de usuario de Bill Wake Características:

Para construir una buena historia de usuario, nos enfocamos en seis características. Una buena historia debe tener características. Bill Wake describió seis características de una buena historia de usuario. Titulamos su fórmula como "Invertir".

Invertir

  • I) Independiente
  • N) Negociable
  • V) Valioso
  • E) Estimable
  • S) Pequeño
  • T) Testable

Independiente

Debemos tratar de evitar la interdependencia entre la historia. Cuando la historia prioriza, planifica hacer o cuándo usar la historia, la historia de la interdependencia entre la carga de trabajo estimada causará más dificultades. Por lo general, podemos reducir la dependencia de dos maneras:

  • Historia interdependiente combinada en grandes historias separadas
  • Con una forma diferente de dividir la historia

Negociable

La libreta de historias es una breve descripción de la función, los detalles de la discusión darán lugar a clientes y equipos de desarrollo. La historia es un recordatorio del papel de los creadores de tarjetas y los clientes para entablar un diálogo sobre la demanda, no es una necesidad específica de habilidades. Una historia de usuario es un cassette con demasiados detalles, que limita de manera efectiva la comunicación del usuario.

Valioso

Las historias de usuario deben reflejar claramente los valores del usuario o clientes, el mejor enfoque es permitirles a los clientes escribir la historia . Una vez que un cliente se da cuenta de que esta historia de usuario no está en contrato y puede negociarse, estará feliz de escribir la historia.

Estimable:

El equipo de desarrollo necesita estimar una historia de usuario para determinar las prioridades, la programación de la carga de trabajo . Pero dejar que los desarrolladores sean difíciles de estimar Problemas de la historia de:

  • Falta de conocimiento del desarrollador
  • Los desarrolladores carecen de conocimiento técnico

La historia también. . . .

Pequeño

Una buena historia sobre la cantidad de trabajo que debe ser lo más pequeña posible, preferiblemente no más de 10 personas sobre la carga de trabajo / día, al menos asegúrese de que en una iteración o Sprint se pueda completar. Historias de usuarios: esquema más grande de acuerdo en riesgo, estimación de esfuerzo y otros aspectos serán.

Testable

La historia debe ser comprobable. Aprobado con éxito la prueba los desarrolladores pueden demostrar que implementa correctamente la historia. Si un usuario no puede probar la historia, entonces no sabrá cuándo se puede hacer. Un ejemplo de historias de usuario sin prueba: el usuario debe encontrar el software muy fácil de usar.

Relacionado: Historias de usuarios ágiles y acumulación de productos arreglados

Inteligente:

SMART no es para historias de usuarios pero para las tareas de una historia de usuario.

  • S) Específico
  • M) Medible
  • A) Alcanzable [19659013] R) Relevante
  • T) Time-Boxed

Específico

Una tarea debe ser lo suficientemente específica para que todos puedan entenderla. Ayuda a evitar que otras tareas se superpongan y también ayuda a las personas a comprender si las tareas se suman o no a la historia completa.

Medible

La clave de la medida es "¿podemos marcarlo como hecho?" Equipo necesita acordar lo que eso significa, pero también debe incluir:

  • "lo que se pretende"
  • "se incluyen pruebas"
  • "el código se ha refabricado".

Alcanzable

El propietario de la tarea debe ser capaz de lograr la tarea. En la metodología XP, los equipos tienen una regla, en la que cualquiera puede pedir ayuda cuando lo necesiten; esto ciertamente incluye asegurar que los propietarios de las tareas estén a la altura del trabajo.

Relevante

Cada tarea debe ser relevante y contribuir a la historia. Las historias de los usuarios se dividen en tareas para beneficio de los desarrolladores, pero el cliente debería poder esperar que cada tarea se justifique y explique.

Time-Boxed

Una tarea debe limitarse a una duración específica. No es necesario que sea una estimación formal en horas o días, pero debe haber una expectativa para que las personas sepan cuándo deben buscar ayuda. Si una tarea es más difícil que las expectativas, entonces el equipo necesita dividir la tarea, cambiar jugadores o hacer algo para ayudar a que la tarea (y la historia) se hagan.

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Powered by themekiller.com