# data[].attributes.body
https://jviezca.blogspot.com/2011/09/tarjetas-crc.html

# data[].attributes.attachment_link.readable_text
Son una metodología para el diseño de programas orientados a objetos.

CRC son las iniciales de clase, responsabilidad y colaboración.

Resumen las responsabilidades de una clase antes de pasar a realizar el diagrama.

Sirven para simular escenarios.

Las tarjetas CRC representan objetos; la clase a la que pertenece el objeto se puede escribir arriba, las responsabilidades u objetivos que debe llevar a cabo el objeto se pueden escribir a la izquierda, y la derecha las clases que se relacionan con dicho objeto.

Tarjetas CRC de mi Proyecto

# data[].attributes.attachment_link.description
Son una metodología para el diseño de programas orientados a objetos. CRC son las iniciales de clase, responsabilidad y colaboración. Resumen las responsabilidades de una clase antes de pasar a realizar el diagrama. Sirven para simular escenarios.

# data[].attributes.body
Las tarjetas CRC representan objetos; la clase a la que pertenece el objeto se puede escribir arriba, las responsabilidades u objetivos que debe llevar a cabo el objeto se pueden escribir a la izquierda, y la derecha las clases que se relacionan con dicho objeto.

# data[].attributes.body
Son una metodología para el diseño de programas orientados a objetos.

CRC son las iniciales de clase, responsabilidad y colaboración.

Resumen las responsabilidades de una clase antes de pasar a realizar el diagrama.

Sirven para simular escenarios.

# data[].attributes.body
En la parte superior, el nombre de la clase.

Debajo, en la parte izquierda, las responsabilidades de dicha clase. Son sus objetivos, a alto nivel.

A la derecha de las responsabilidades, los colaboradores, que son otras clases que ayudan a conseguir cumplir a esta con sus responsabilidades.

# data[].attributes.body
Desde mi perspectiva, para la realización de estas tarjetas, puedes utilizar lo que es la aplicación de EXCEL, y una en-linea llamada: "Visual Online paradigm"
Son totalmente gratuitas, y utilizarlas para la creacion de las CRC

# data[].attributes.body
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema.

# data[].attributes.body
https://scrum.mx/informate/historias-de-usuario

# data[].attributes.attachment_link.readable_text
¿Qué es una historia de usuario?

Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema. Por lo general, siguen una plantilla simple:

Las historias de los usuario a menudo se escriben en fichas o notas adhesivas, se almacenan en una caja y se organizan en paredes o mesas para facilitar la planificación y el debate. Como tal, cambian fuertemente el enfoque de escribir sobre las características a discutir. De hecho, estas discusiones son más importantes que cualquier texto que se escriba.

# data[].attributes.attachment_link.title
Historias de Usuario, Escritura, Definición, Contexto y Ejemplos - SCRUM MÉXICO

# data[].attributes.attachment_link.description
Las historias de usuario son descripciones cortas y simples de una característica contada desde la perspectiva de la persona que desea la nueva capacidad, generalmente un usuario o cliente del sistema.

# data[].attributes.body
Como <Usuario>

Quiero <algún objetivo>

Para que <motivo>

# data[].attributes.headline
Ejemplos extras: "Como escribir historias usuario"

# data[].attributes.subject
Ejemplos extras: "Como escribir historias usuario"

# data[].attributes.body
Piensa en lo siguiente cuando escribas historias de usuario:

Definición de “Listo”: la historia suele estar “lista” cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.

Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.

Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.

Pasos ordenados: escribe una historia para cada paso en un proceso más grande.

Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.

Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.

# data[].attributes.body
Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want…) o desde la organización (As the organisation I want to…) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación.

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario.

# data[].attributes.headline
Partes que conforma historias de usuario

# data[].attributes.subject
Partes que conforma historias de usuario

# data[].attributes.body
https://jeronimopalacios.com/product-delivery/los-elementos-una-buena-historia-de-usuario/#:~:text=Los%20elementos%20fundamentales%20de%20una,de%20la%20historia%20de%20usuario.

# data[].attributes.attachment_link.readable_text
La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación. Contrariamente a lo que mucha gente cree, el Product Backlog en Scrum está poblado por muchos tipos de requerimiento y solamente uno de ellos son las historias de usuario.

Es más acerca de la conversación que de la historia de usuario en sí misma. La conversación es lo que da las razones inherentes en la historia de usuario a lo que hay que hacer en el producto. La historia de usuario es únicamente un recordatorio de esa conversación.

Las 3 C's de la historia de usuario

Los elementos fundamentales de una historia de usuario son la Tarjeta (Card), la Conversación (Conversation) y Confirmación (Confirmation). Estos tres elementos son más importantes que cualquier detalle que pongamos en la historia de usuario en sí misma, y componen los elementos fundamentales de la historia de usuario. Sin ellos, la historia de usuario no está completa.

Tarjeta (Card): La tarjeta refleja los elementos más importantes de la historia de usuario. Expresa el valor que se quiere conseguir desde el punto de vista del usuario. Expresar un historia de usuario desde el punto de vista del desarrollador (As a developer I want...) o desde la organización (As the organisation I want to...) es una mala práctica que refleja la incapacidad de pensar en el valor para el usuario final.

Conversación (Conversation): Después de escribir la historia de usuario en la tarjeta, es necesario tener una conversación al respecto de su contenido. Hay que saber responder a cuestiones sobre el valor y sobre el resultado esperado de la implementación. Esta conversación puede suceder en cualquier momento; es habitual que se produzca durante el refinamiento del Backlog o el Sprint Planning.

Confirmación (Confirmation): La confirmación es un acuerdo que refleja que todas las personas implicadas, Product Owner y Development Team, entienden cuales son los elementos, valor y resultado esperado de la historia de usuario. Muchos equipos cometen el error de no tener esta confirmación, lo cual lleva a fricciones y problemas durante el Sprint Planning.

Modelo de historia de usuario

Una historia de usuario generalmente sigue un patrón definido
As a... Persona para la que se cubre una necesidad
I want... lo que queremos que ocurra, por ejemplo una características o una funcionalidad
So that... el valor que obtiene la persona de la implementación de la característica o funcionalidad.
En la primera parte de la historia de usuario, es muy útil hacer referencia a usuarios de nuestro producto, usuarios que estén descritos y estudiados usando el modelo de User Personas, que toman una serie de rasgos de múltiples usuarios y construyen una persona ficticia que haga uso de la aplicación.

En la segunda parte de la historia de usuario, se explica lo que desde el punto de vista de la persona debería de suceder, sin entrar en descripciones técnicas. Una buena historia de usuario no tiene en cuenta lo que el sistema puede hacer, sino lo que el usuario quiere obtener.

Una historia de usuario está totalmente centrada en el usuario, y no en el producto o la organización.En la tercera parte, se expresa el valor que la persona quiere obtener, lo cual ayuda a entender y refinar, o incluso cambiar la forma en la que usuario obtiene el valor esperado.

Como se puede comprobar, las historias de usuario están totalmente alineadas con la expectativa del usuario, sin tener en cuenta capacidades o restricciones de nuestro producto. Una buena historia de usuario es aquella que está construida sobre datos reales, obtenidos de los propios usuarios.

Vanesa Tejada tiene una gran presentación sobre como escribir historias de usuario

Criterios de Aceptación

Los criterios de aceptación son los detalles de una historia de usuario, y ayudan a completar el patrón de valor expresado por la misma. Los criterios de aceptación incluyen los detalles que ayudan a visualizar la película completa y mejoran el entendimiento que el Product Owner, los Stakeholders y el Development Team tienen sobre lo que se va a realizar.

Los criterios de aceptación cumplen dos funciones: Clarificar el contexto en el que ocurre la historia de usuario y facilitar saber cuando están realmente terminadas.Los criterios de aceptación también son el medio por el cual el Development Team es capaz de saber cuando un ítem del Product Backlog está terminado, y ser capaces de testar los elementos de la historia de usuario en conjunto.

Unos buenos criterios de aceptación son claros, concisos, expresan una sola cualidad del ítem del Product Backlog y en la mayoría de ocasiones son redundantes, explicando desde múltiples puntos de vista cual es la imagen finalizada de la historia de usuario.

Además, pueden contener requerimientos no funcionales, si estos no están recogidos en la Definition of Done del equipo, como velocidad de la aplicación, concurrencia o elementos de seguridad que deben ser implantados para considerar la historia de usuario terminada.

Specification by example

Otro elemento que puede resultar de ayuda en una historia de usuario es expresar los resultados deseados mediante un ejemplo, que ayude a entender al Development Team cual es el resultado deseado al implementar una historia de usuario.

No solamente es válido para Algoritmos, sino que también puede ser muy útil en el caso de implementación de diseños en un producto ya existente. Herramientas como InVision ayudan a los especialistas en UX/UI a diseñar flujos en una aplicación que posteriormente pueden ser implementados como especificaciones en el producto final, siendo uno de los criterios de aceptación que la UI del producto sea cómo la del diseño inicial.

También puedes leer más sobre Specification by Example en el blog de Martin Fowler.

# data[].attributes.attachment_link.title
Los elementos de una buena historia de usuario

# data[].attributes.attachment_link.description
La historia de usuario no es el santo grial que muchos creen, sino un contenedor que sirve como recordatorio de una conversación entre el Product Owner y el Development TeamUna historia de usuario es una promesa para mantener una conversación.

# data[].attributes.headline
Ejemplos de utilización de historias de usuario

# data[].attributes.subject
Ejemplos de utilización de historias de usuario

# data[].attributes.body
Esta es una de las más sencilla de utilización.
Se podría considerar aplicaciones como: Jira software.
Pero para tener una idea de utilización, podrías hacerlo mediante aplicaciones como correos electrónicos, un bloc de notas, y nomás sería representarlas en jira software

# data[].attributes.body
https://www.atlassian.com/es/agile/project-management/user-stories

# data[].attributes.attachment_link.readable_text
Resumen: una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente.

Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software. Pero no lo son.

Un componente clave del desarrollo de software ágil es poner a las personas en primer lugar, y las historias de usuarios ponen a los usuarios finales reales en el centro de la conversación. Las historias utilizan un lenguaje no técnico para ofrecer contexto al equipo de desarrollo y sus esfuerzos. Después de leer una historia de usuario, el equipo sabe por qué está compilando lo que está compilando y qué valor crea.

Las historias de usuario son uno de los componentes centrales de un programa ágil. Ayudan a proporcionar un marco centrado en el usuario para el trabajo diario, lo que impulsa la colaboración y la creatividad y mejora el producto en general.

¿Qué son las historias de usuario ágiles?

Una historia de usuario es la unidad de trabajo más pequeña en un marco ágil. Es un objetivo final, no una función, expresado desde la perspectiva del usuario del software.

Una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final o cliente.

El propósito de una historia de usuario es articular cómo un elemento de trabajo entregará un valor particular al cliente. Ten en cuenta que los "clientes" no tienen por qué ser usuarios finales externos en el sentido tradicional, también pueden ser clientes internos o colegas dentro de tu organización que dependen de tu equipo.

Las historias de usuario son unas pocas frases en lenguaje sencillo que describen el resultado deseado. No entran en detalles, ya que los requisitos se añaden más tarde, una vez acordados por el equipo.

Las historias encajan perfectamente en marcos ágiles como scrum y kanban. En el scrum, las historias de los usuarios se añaden a los sprints y se "queman" a lo largo del sprint. Los equipos de kanban introducen las historias de usuario en su backlog y las ejecutan siguiendo su flujo de trabajo. Es este trabajo sobre las historias de usuario lo que ayuda a los equipos de scrum a mejorar en la estimación y planificación del sprint, lo que conduce a un pronóstico más preciso y a una mayor agilidad. Gracias a las historias, los equipos de kanban aprenden a gestionar el trabajo en curso (WIP) y pueden perfeccionar aún más sus flujos de trabajo.

Las historias de usuario son también los componentes básicos de los marcos ágiles más grandes, como los epics y las iniciativas. Los epics son grandes elementos de trabajo divididos en un conjunto de historias, y varios epics constituyen una iniciativa. Estas estructuras más grandes garantizan que el trabajo diario del equipo de desarrollo contribuya a los objetivos de la organización incorporados en los epics y las iniciativas.
Más información sobre epics e iniciativas
¿Por qué crear historias de usuario?

Para los equipos de desarrollo nuevos en la metodología ágil, las historias de usuario a veces parecen un paso más. ¿Por qué no dividir el gran proyecto ( el epic) en una serie de pasos y seguir adelante? Pero las historias dan al equipo un contexto importante y asocian las tareas con el valor que estas aportan.

Las historias de usuario tienen varios beneficios clave:

Las historias centran la atención en el usuario. Una lista de tareas pendientes mantiene al equipo centrado en tareas que deben completarse, pero un conjunto de historias lo mantiene centrado en solucionar problemas para usuarios reales.

Las historias permiten la colaboración. Con el objetivo definido, el equipo puede colaborar para decidir cómo ofrecer un mejor servicio al usuario y cumplir con dicho objetivo.

Las historias impulsan soluciones creativas. Las historias fomentan que el equipo piense de forma crítica y creativa sobre cómo lograr mejor un objetivo.

Las historias motivan. Con cada historia el equipo de desarrollo disfruta de un pequeño reto y una pequeña victoria, lo que aumenta la motivación.

Trabajar con historias de usuario

Una vez que se ha escrito una historia, es hora de integrarla en tu flujo de trabajo. Por lo general, una historia la escribe el propietario del producto, el gestor del producto o el gestor del programa, y la envía para su revisión.

Durante una reunión de planificación de sprint o iteración, el equipo decide qué historias afrontará en ese sprint. Los equipos discuten los requisitos y la funcionalidad que requiere cada historia de usuario. Esta es una oportunidad para ponerse técnico y creativo en la implementación de la historia por parte del equipo. Una vez acordados, estos requisitos se añaden a la historia.

Otro paso común en esta reunión es calificar las historias en función de su complejidad o tiempo hasta su finalización. Los equipos usan las tallas de las camisetas, la secuencia de Fibonacci o el Planning Poker para hacer las estimaciones adecuadas. Una historia debe ser de un tamaño que pueda completarse en un sprint; por lo tanto, cuando el equipo establezca las especificaciones de cada historia, se deben asegurar de dividir las historias que superen ese horizonte de finalización.

Cómo escribir historias de usuario

Piensa en lo siguiente cuando escribas historias de usuario:

Definición de "Listo": la historia suele estar "lista" cuando el usuario puede completar la tarea descrita, pero debes asegurarte de definir lo que representa completarla.

Describe tareas o subtareas: decide qué pasos específicos deben completarse y quién es responsable de cada uno de ellos.

Perfiles de usuario: ¿para quién? Si hay varios usuarios finales, considera crear varias historias.

Pasos ordenados: escribe una historia para cada paso en un proceso más grande.

Escucha el feedback: habla con los usuarios y capta sus problemas o necesidades en lo que dicen. No es necesario tener que estar adivinando las historias cuando puedes obtenerlas de tus clientes.

Tiempo: el tiempo es un tema delicado. Muchos equipos de desarrollo evitan hablar sobre el tiempo, y en su lugar confían en sus marcos de trabajo de estimación. Dado que las historias deberían completarse en un sprint, aquellas que puedan necesitar semanas o meses deberían dividirse en historias más pequeñas o considerarse un epic independiente.

Una vez que las historias de usuario estén definidas de forma clara, debes asegurarte de que todo el equipo pueda verlas.

Plantilla y ejemplos de historias de usuario

Las historias de usuario suelen expresarse con una frase simple con la siguiente estructura:
"Como [perfil], [quiero] [para]."
Desglosemos esta estructura:

"Como [perfil]": ¿para quién desarrollamos esto? No solo buscamos un puesto, buscamos el perfil de la persona. Max. Nuestro equipo debería comprender quién es Max. Con suerte hemos entrevistado a muchos Max. Comprendemos cómo trabaja esa persona, cómo piensa y cómo se siente. Sentimos empatía por Max.

"Quiere": aquí describimos su intención, no las funciones que usan. ¿Qué es lo que están intentando lograr realmente? Esta descripción debería realizarse con independencia de las implementaciones; si describes algún elemento de la IU y no el objetivo del usuario, estás cometiendo un error.

"Para": ¿cómo encaja su deseo inmediato de hacer algo en la perspectiva general? ¿Cuál es el beneficio general que intentan lograr? ¿Cuál es el gran problema que debe resolverse?

Por ejemplo, las historias de usuario pueden tener este aspecto:

Como Max, quiero invitar a mis amigos, para que podamos disfrutar de este servicio juntos.

Como Sascha, quiero organizar mi trabajo, para poder sentir que tengo un mayor control.

Como gestor, quiero poder comprender el progreso de mis compañeros, para poder informar sobre nuestros éxitos y fallos.

Esta estructura no es obligatoria, pero resulta de ayuda para establecer una definición de "hecho". Cuando ese perfil puede alcanzar su valor deseado, la historia está completa. Recomendamos a nuestros equipos definir su propia estructura, y que no se desvíen de ella.

Introducción a las historias de usuario ágiles

Las historias de los usuarios describen el por qué y el qué que hay detrás del trabajo diario de los miembros del equipo de desarrollo; a menudo las historias de usuario se expresan de la siguiente manera: perfil + necesidad + propósito. Entender su papel como fuente de verdad para lo que el equipo está entregando, pero también el por qué, es clave para un proceso sin problemas.

Empieza por evaluar el siguiente gran proyecto o el más apremiante (por ejemplo, un epic). Divídelo en historias de usuario más pequeñas y trabaja con el equipo de desarrollo para mejorarlo. Una vez que tus historias están fuera, donde todo el equipo puede verlas, ya tienes todo listo para empezar a trabajar.

# data[].attributes.attachment_link.title
Historias de usuario | Ejemplos y plantilla | Atlassian

# data[].attributes.attachment_link.description
Resumen: una historia de usuario es una explicación general e informal de una función de software escrita desde la perspectiva del usuario final. Su propósito es articular cómo proporcionará una función de software valor al cliente. Es tentador pensar que las historias de usuario son, en pocas palabras, requisitos del sistema de software.