Cómo escribir tu historia de usuario

1. Introducción: Hola ahí. Mi nombre es Adam. Soy Gerente de Producto y me gustaría hablarte sobre cómo escribir tu historia de usuario perfecta. Sí, así es. Tu estilo, tu personalidad, tu pasión y compromiso, tu equipo, tus partes interesadas, tu producto y tu historia de usuario. Porque no existe tal cosa como una plantilla universal que lo haga todo perfecto y que se aplique en todos los ámbitos. Si crees que has logrado la perfección al escribir tus historias de usuario, podrías tener una sorpresa cuando cambiarás de equipo por proyectos. Con todas y cada una de las interacciones con todas y cada una de las nuevas características, tu enfoque cambiará ligeramente y eso está bien. Tú eres el que necesita ajustarse para que la historia correcta, alcance el aspecto deseado en términos de claridad y granularidad y atractivo. Entonces el nivel de comprensión de todos. La misma historia de usuario que estás escribiendo necesita hablar el lenguaje del equipo de desarrollo que son técnicamente conocedores, pero también debe hablar el idioma de los dueños de negocios que pueden o no tener antecedentes técnicos. Mi definición de una historia de usuario perfecta tiene su fundamento en la siguiente declaración. Si te llevas a un extraño para modelar la calle y mostrarles la historia del usuario que has escrito. No deberían ser capaces de entenderlo. Debería ser bastante fácil para cualquiera envolver la cabeza alrededor del requisito, el contexto, y la funcionalidad que nacerá como resultado de la implementación de esta historia de usuario en particular. Entonces de lo que vamos a estar hablando de sus pautas, punteros, consejos y trucos, y todo lo que necesitas saber para que puedas escribir tu historia de usuario perfecta independientemente del equipo, el proyecto, o la industria para ese asunto. 2. Cómo escribir tu historia de usuario perfecta: Hola ahí. Mi nombre es Adam. Soy Gerente de Producto y me gustaría hablarte sobre cómo escribir tu historia de usuario perfecta. Sí, así es. Tu estilo, tu personalidad, tu pasión y compromiso, tu equipo, tus partes interesadas, tu producto y tu historia de usuario. Porque no existe tal cosa como una plantilla universal que lo haga todo perfecto y que se aplique en todos los ámbitos. Si crees que has logrado la perfección al escribir tus historias de usuario, entonces podrías tener una sorpresa cuando cambiarás de equipo por proyectos. Con todas y cada una de las interacciones con todas y cada una de las nuevas características, tu enfoque cambiará ligeramente y eso está bien. Tú eres el que necesita ajustarse para que la historia correcta, alcance el aspecto deseado en términos de claridad y granularidad y atractivo. Entonces el nivel de comprensión de todos. La misma historia de usuario que estás escribiendo necesita hablar el lenguaje del equipo de desarrollo que son técnicamente conocedores, pero también debe hablar el idioma de los dueños de negocios que pueden o no tener antecedentes técnicos. Mi definición de una historia de usuario perfecta tiene su fundamento en la siguiente declaración. Si sacas a un extraño del modelo de la calle y muéstrales la historia del usuario que has escrito. No deberían ser capaces de entenderlo. Debería ser bastante fácil para cualquiera envolver la cabeza alrededor del requisito, el contexto, y la funcionalidad que nacerá como resultado de la implementación de esta historia de usuario en particular. Entonces de lo que vamos a estar hablando de sus pautas, punteros, consejos y trucos, y todo lo que necesitas saber para que puedas escribir tu historia de usuario perfecta independientemente de la equipo, el proyecto, o la industria para ese asunto. Pero primero lo primero, ¿qué es una historia de usuario? Una historia de usuario es una representación clara de un requisito, ilustrando la perspectiva del usuario y articulando cómo una funcionalidad particular entregará un valor específico a los clientes. Está escrito como una historia usando un formato específico, pero en inglés sencillo. Y en tal lenguaje que cualquier humano puede leer y entender fácilmente sin contextos previos ni información adicional. ¿ Qué tan granular es de hecho una historia de usuario? Bueno, tienes a nivel de proyecto a gran nivel, nivel de características, y luego tienes historias de usuarios. Por lo que son básicamente la única expresión más granular de requerimiento. No obstante, por tan granular como sea, la historia del usuario aún necesita definir una pieza de funcionalidad totalmente comprobable y entregable. No importa cuán pequeño sea. ¿ Por qué utilizamos historias de usuarios? Las usamos para traducir las necesidades empresariales en funcionalidades enfocadas al usuario. Los usamos para crear un entendimiento común de lo que queremos construir para que terminemos construyendo lo correcto y cómo se construirá. Para que terminemos construyéndolo ¿verdad? usamos para tener una única fuente de verdad y una forma más estandarizada de estructurar y comunicarse con el equipo, pero también fuera del equipo con nuestros interesados internos o externos. Y por último pero no menos importante, las usamos para establecer expectativas y crear hábitos. ¿ Cuáles son los beneficios de mejores historias de usuarios? Entrega más rápida de mayor satisfacción del cliente, mejor curva de aprendizaje, decisiones más rápida, menos desperdicio. Entonces construye lo correcto y construirlo de la manera correcta. O de lo contrario surgirán preguntas y no el bueno y el tipo malo. Eso pronto se traducirá en incertidumbre, falta de confianza, cuestionando y empujando hacia atrás todas las cosas desagradables que dañarán mal tu relación con el equipo de desarrollo. no hablar de los retrasos, las últimas horas de los viernes por la noche al final del sprint, la multitud de bichos que inevitablemente se arrastrarán en el producto que se supone que estás nutriendo. Y por último pero no menos importante, apenas resolviendo la necesidad y Cargar para conocer la satisfacción del cliente. Invierte en buenas historias usuario porque las historias de usuario necesitan ser independientes para que puedan trabajarse sin ningún tipo de dependencias negociables, porque una historia de usuario no es un contrato para una característica. Valioso, lo que significa que debe entregar valor para los clientes, estimable a un nivel razonable de aproximación, pequeño tamaño, de tal manera que encaja en una iteración, luego comprobable para que se pueden probar las condiciones de éxito. Hablemos un poco sobre la anatomía de una historia de usuario. Puedes tener diferentes tipos de historias de usuarios. Puedes tener historias de usuarios regulares. Puedes tener historias técnicas de usuario. Puedes tener picos, que son básicamente. Historias de usuarios de investigación y así sucesivamente. Ahora, ¿qué hace una buena historia de usuario? Bueno, para empezar, una historia de usuario tiene un título. El título debe ser conciso, claro e intuitivo. Piensa en titulares de periódicos. Eso es lo que el título es de tu historia de usuario. Entonces lo mejor es proporcionar un poco de contexto en cuanto a por qué es que queremos implementar esta pieza de funcionalidad? Qué valor aporta a nuestros clientes, y cuál es la necesidad, son almas. El razonamiento detrás de esto es que el equipo de desarrollo no puede trabajar de manera aislada. No solo se sientan en una burbuja esperando que alguien les dé de comer historias de usuarios. Sin que comprendan el contexto pleno y las implicaciones. Cuanto mejor capten el contexto de los requisitos, más capaces habrá de llegar a una mejor solución técnica con una valiosa retroalimentación para el negocio y así sucesivamente. Entonces, ¿cómo expresamos ese contexto? Bueno, como parte de la anatomía de una historia de usuario, comienzas con una famosa como, yo quiero. Entonces esa fórmula. Déjame darte un ejemplo. Si el título de la historia de mi usuario es el usuario puede realizar una búsqueda en el sitio web, entonces la expresión del contexto, sería, por ejemplo, como usuario del sitio web, quiero poder realizar un buscar en el sitio web para que pueda encontrar el artículo que estoy buscando. Entonces tienes la sección de criterios de aceptación. Aquí es donde se anotan los requisitos reales porque el contexto no es el requisito. Se trata de una descripción espejo de alto nivel del razonamiento detrás del requisito. Mira que escribirás en esta sección, el equipo de desarrollo se convertirá en realidad. Los desarrolladores escribirán el código. Los probadores probarán la funcionalidad después. Y el propietario del producto o los analistas de negocios realizarán las pruebas de aceptación del usuario de la UAT basadas en esos requisitos específicos. Entonces, ¿cómo deberían verse los criterios de aceptación? Bueno, idealmente, lo estructurarías en escenarios. Por ejemplo, escenario número uno, escenario número dos, etcétera. Cada uno de ellos con un título y composición específicos. Y es aquí donde usamos la otra parte famosa del cuerpo de una historia de usuario, la dada cuando entonces secuencia. El dado es el requisito previo. Describe lo que ya necesitas tener en su lugar. cuando llegues a este paso. El cuándo es el gatillo. Muestra lo que tiene que pasar. Con el fin de determinar un comportamiento específico. Entonces es el comportamiento esperado. Se ilustra lo que debe suceder como resultado de un disparador específico. Siguiendo nuestro ejemplo anterior, con el cliente que necesita poder realizar una búsqueda en la página web. Nuestro primer escenario y los criterios de aceptación sonarían así. Escenario número uno, el título sería Buscar opción está disponible para el usuario. Entonces tenemos el dado cuando entonces secuencia. Así que vamos a ver. Dado que el usuario tiene acceso al sitio web, cuando se muestra la página del producto del sitio web, entonces el módulo de búsqueda está disponible en la esquina superior derecha de la pantalla. Entonces, ¿qué hemos hecho aquí? En primer lugar, hemos descrito el prerrequisito dado que el usuario ya tiene acceso al sitio web. ¿ Por qué? Porque si el usuario no accede al sitio web, entonces no hay funcionalidad de la que hablar. Después especificamos el gatillo cuando la página del producto del sitio web es esta placa. ¿ Por qué? Porque el equipo de desarrollo necesita saber cuándo esta pieza de funcionalidad recién implementada debe estar disponible para los usuarios. ¿ Queremos la funcionalidad de búsqueda en todas las páginas del sitio web? No. Solo queremos que esté disponible cuando accedamos a la página de productos. Entonces, ¿cuándo es el gatillo? ¿ Recuerdas eso? Sólo después pedimos el comportamiento esperado. Entonces el módulo de búsqueda está disponible en la esquina superior derecha de la pantalla. ¿ Por qué? Porque tenemos que ilustrar lo que debe pasar. Si accedo al sitio web y aterrizo en la página de productos. El comportamiento esperado en nuestro caso es que ahora puedo ver el cuadro de búsqueda. ¿ De acuerdo? Para que podamos ver el cuadro de búsqueda en esa página. Pero, ¿cómo hacemos que funcione? Bueno, eso es bastante fácil. Podemos escribir otro escenario como parte de los criterios de aceptación. Por lo que ahora tendremos Escenario número dos con un siguiente título. El usuario puede buscar un producto específico por nombre, siguiendo la fórmula dada cuando entonces mágica. Esto es lo que tenemos. Recuerda. En este punto sólo podemos ver el cuadro de búsqueda. Aún no hace nada. Entonces aquí va. Dado que el usuario ha enviado criterios de búsqueda específicos utilizando el cuadro de entrada de búsqueda. Cuando el usuario hace clic en la búsqueda CTA llamada a la acción. Entonces el filtrado se realiza de acuerdo con los criterios especificados. Y se muestra la lista de resultados de búsqueda que contiene todos los productos que coinciden con los criterios de búsqueda. Una nota importante aquí, puede tener múltiples requisitos previos dados son las condiciones previas. Y puedes expresarlos mediante el uso de end. Por ejemplo, dado que el usuario ha enviado criterios de búsqueda específicos utilizando el cuadro de entrada de búsqueda y el cuadro de entrada de búsqueda contiene caracteres válidos. También puedes tener comportamientos múltiples de lo esperado, como por ejemplo, en nuestro ejemplo anterior. Entonces el filtrado se realiza acuerdo con los criterios especificados. Y se muestra la lista de resultados de búsqueda que contiene todos los productos coinciden con los criterios de búsqueda. Pero solo puede haber uno cuando el disparador debe ser una expresión singular, un solo evento. También, en cuanto a escenarios, hay que tener cuidado en especificar todos los casos posibles. Escenarios de casos felices, casos de falla, y los escenarios de caso de borde. Y denotado para hacer eso correctamente, necesitamos caminar una milla en los zapatos del cliente y siempre cuestionar cada acción y cada decisión. Esa es la única manera en que podemos maximizar nuestras posibilidades descubrir todos los casos de uso posibles. Entonces ahí vas. Hay que tener en cuenta muchas cosas al escribir historias de usuarios. Y es un proceso que no se debe dar por sentado. Escribir historias de usuario adecuadas. Una vez que el equipo de desarrollo pueda entender e implementar fácilmente los que sean claros, concisos, y con la cantidad y la información de calidad adecuadas es todo un proceso que puede hacer que su la vida más fácil o puede causar pesadillas y muchos problemas. Un par de consejos y trucos para que consideres. Empieza a lo grande y descúbrelos según sea necesario. Usos historias están destinadas a ser refinadas. No te enfoques en hacerlo todo a la vez. Piensa en los flujos de usuario, luego crea un rebanadas verticales para apoyarlos. Significado, usa Story Mapping, ¿verdad? Y revisarlos como equipo. Porque esto crea un entendimiento compartido. Este no es un solo hombre. Muéstralo como un esfuerzo colaborativo. Centrarse en subyacente a la necesidad del cliente, no en los percibe y el estado. No sudas el formato. Hay muchas formas válidas de escribir una historia de usuario. Basta con averiguar qué funciona mejor para el equipo y luego ser consistente. Las historias de usuarios son las estructuras que inician y capturan la conversación torno a la función basada en valores centrada en sus usuarios. Y recuerda, no eres tu usuario. Por último pero no menos importante, invierte en tus historias. Y lo más importante, pregúntale al quién, el qué y el por qué. Usa toda esta información como tu Northstar. A pesar de que lo más probable es que no seas capaz de crear unos usos perfectos para alcanzar y cada vez. Pero la práctica hace perfecta. Así que mantengan al día el buen trabajo. Reconoció la importancia de escribir historias de usuario adecuadas y hacer que su vida más fácil en su trabajo sea más agradable.