{"id":31715,"date":"2020-05-28T12:52:21","date_gmt":"2020-05-28T10:52:21","guid":{"rendered":"https:\/\/xitaso.com\/?p=31715"},"modified":"2021-09-21T13:51:07","modified_gmt":"2021-09-21T11:51:07","slug":"enfoque-de-las-historias-de-usuario","status":"publish","type":"post","link":"https:\/\/xitaso.com\/es\/enfoque-de-las-historias-de-usuario\/","title":{"rendered":"Nuestro enfoque de las historias de usuario"},"content":{"rendered":"

[vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text]En la situaci\u00f3n actual, estamos poniendo a prueba las herramientas con las que trabajamos a diario y evaluando su idoneidad para el uso diario en la oficina dom\u00e9stica. Uno de los elementos fundamentales en Scrum son las historias de usuario. A continuaci\u00f3n, mostraremos lo que hace que una historia de usuario sea una buena historia de usuario para nosotros en XITASO, as\u00ed como lo que resulta particularmente importante en la situaci\u00f3n actual.<\/strong><\/p>\n

\u00bfQu\u00e9 son las historias de usuario y c\u00f3mo se estructuran?<\/h2>\n

Lo que en ingl\u00e9s se denomina \u00abuser stories\u00bb son lo que nosotros llamamos historias de usuario. El propietario del producto describe los requisitos desde el punto de vista del usuario en una historia de usuario. Es decir, explica qu\u00e9 buscan los usuarios en el software, o los clientes en un producto, para alcanzar sus objetivos empresariales.[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_empty_space height=\u00bb20″][vc_single_image image=\u00bb15082″ img_size=\u00bbfull\u00bb qode_css_animation=\u00bb\u00bb][vc_empty_space height=\u00bb20″][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text]Las historias de usuario constan de unas pocas frases f\u00e1cilmente comprensibles. Son cortas, pero concisas, espec\u00edficas y detalladas desde el punto de vista del cliente. Las historias de usuario no solo transmiten las expectativas de los futuros sistemas inform\u00e1ticos, sino tambi\u00e9n los requisitos de los productos entregados que hacen realidad los proyectos \u00e1giles. Las historias de usuario se mueven en el espacio de los requisitos sin cambiar al espacio de la soluci\u00f3n. No proporcionan soluciones t\u00e9cnicas que obliguen a los desarrolladores a aplicarlas de forma estricta y, por lo tanto, son diferentes de una especificaci\u00f3n. 1<\/a><\/sup> 2<\/a><\/sup><\/p>\n

Una historia de usuario debe ser sencilla y f\u00e1cil de entender.<\/p>\n

\u00abComo [usuario], me gustar\u00eda a\u00f1adir la [funci\u00f3n] a [valor]\u00bb.<\/p>\n

Es decir, una historia de usuario responde a las preguntas QUI\u00c9N <\/strong>quiere QU\u00c9<\/strong> y POR QU\u00c9<\/strong>:[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text][Usuario] \u2013 \u00bfQui\u00e9n?<\/strong>
\nEl marcador de posici\u00f3n [Usuario] se rellena con roles o personas. Una persona es un representante t\u00edpico de un grupo destinatario. El rol del usuario tambi\u00e9n puede definirse en funci\u00f3n del contexto de cada momento. As\u00ed, por ejemplo, es posible asignar el mismo rol a diferentes personas y describir la relaci\u00f3n existente con el producto.[\/vc_column_text][vc_column_text][Valor] \u2013 \u00bfPor qu\u00e9?<\/strong>
\nEl marcador de posici\u00f3n [Valor] responde a la pregunta de POR QU\u00c9. Aunque la estructura de la frase le tiente a omitir esta cl\u00e1usula subordinada, una historia de usuario no est\u00e1 completa sin este a\u00f1adido.[\/vc_column_text][vc_column_text][Funci\u00f3n] \u2013 \u00bfQu\u00e9?<\/strong>
\nEl marcador de posici\u00f3n [Funci\u00f3n] se rellena con la expectativa, los objetivos y los deseos del [usuario]. La funci\u00f3n responde as\u00ed a la pregunta de QU\u00c9 necesita y espera el cliente. Si el producto ya se encuentra disponible en el mercado, muchas de las funciones deseadas vendr\u00e1n sin duda directamente del usuario. En las primeras fases de un proyecto, se pueden formular suposiciones sobre qu\u00e9 [funci\u00f3n] espera el [usuario] bas\u00e1ndose en la experiencia del cliente o del propietario del producto y del equipo.[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text]Esto significa que, hasta que no se indica el [valor], no se explica por qu\u00e9 el logro de la [funci\u00f3n] es importante en absoluto para el [usuario] y qu\u00e9 valor a\u00f1adido crea el cumplimiento de la historia de usuario. Como muy tarde en este punto, la historia de usuario ofrece una reflexi\u00f3n veraz sobre el grado en el que ha logrado satisfacer los requisitos de los clientes. Incluir los requisitos es f\u00e1cil (por ejemplo, porque el cliente pide a gritos una funci\u00f3n). Pero entender por qu\u00e9 es importante para \u00e9l es lo que da al equipo el contexto necesario. 3<\/a><\/sup>[\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_empty_space][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text]<\/p>\n

As\u00ed escribimos las historias de usuario en XITASO<\/strong><\/h2>\n

Como resultan f\u00e1ciles de comprender y se centran en el usuario, las historias de usuario son una t\u00e9cnica popular y ampliamente utilizada para describir las entradas en la pila de producto de un equipo de Scrum. En consecuencia, en XITASO tambi\u00e9n utilizamos historias de usuario en todos nuestros equipos de Scrum. Sin embargo, la forma en la que estas se crean, el modo en el que se estructuran y la manera en la que se ejecuta la \u00absoluci\u00f3n ideal\u00bb esbozada difieren en el d\u00eda a d\u00eda de los diferentes equipos individuales y tambi\u00e9n dentro de un mismo equipo en funci\u00f3n del caso de que se trate.<\/p>\n

As\u00ed pues, apart\u00e1ndonos del enfoque cl\u00e1sico, preferimos poner un \u00e9nfasis especial en el \u00abporqu\u00e9\u00bb del requisito en la historia de usuario, explicando primero ese \u00abporqu\u00e9\u00bb en la estructura de dicha historia. Como el equipo debe desarrollar una soluci\u00f3n para satisfacer las necesidades del cliente, es crucial conocer exactamente los motivos o el problema de dicho cliente para poder ofrecer soluciones alternativas que sean m\u00e1s eficaces, o incluso m\u00e1s baratas, si es que esto \u00faltimo es tambi\u00e9n necesario. Adem\u00e1s, al anteponer el \u00abporqu\u00e9\u00bb a la historia del usuario, desde el comienzo de dicha historia, uno se pone en el lugar del cliente y, por tanto, tambi\u00e9n ve las cosas con la perspectiva del usuario.<\/p>\n

En XITASO, no solo trabajamos en nuevos productos de software, sino tambi\u00e9n en la mejora de los productos existentes. En este caso, las historias de usuario suelen referirse a funciones ya disponibles. Por ejemplo, una historia de usuario para una tienda en l\u00ednea existente podr\u00eda ser as\u00ed: \u00abPara poder procesar el pago de mi pedido de forma r\u00e1pida y c\u00f3moda, como cliente me gustar\u00eda vincular los datos de mi tarjeta de cr\u00e9dito con mi cuenta\u00bb. Esta formulaci\u00f3n responde a las preguntas de qui\u00e9n quiere qu\u00e9 y por qu\u00e9. No obstante, queda abierto cu\u00e1l es el procedimiento actual. \u00bfA\u00fan no es posible que el cliente pague con tarjeta de cr\u00e9dito o ya es posible, pero el cliente tiene que volver a introducir los datos de la tarjeta de cr\u00e9dito cada vez que realiza un pedido? Dependiendo de la situaci\u00f3n de partida, las expectativas y la urgencia de los cambios tambi\u00e9n son distintas para el cliente en cuesti\u00f3n. As\u00ed, para lograr un mejor entendimiento com\u00fan de lo que se debe conseguir con esta historia de usuario, nos ha resultado \u00fatil ampliar dichas historias con una cl\u00e1usula subordinada del tipo \u00abpuesto que, en la actualidad\u00bb, que describe el procedimiento actual que debe mejorarse: \u00abPara poder procesar el pago de mi pedido de forma r\u00e1pida y c\u00f3moda, como cliente me gustar\u00eda vincular los datos de mi tarjeta de cr\u00e9dito con mi cuenta, puesto que, en la actualidad, tengo que volver a introducir los datos de mi tarjeta de cr\u00e9dito cada vez que hago una compra\u00bb.<\/p>\n

Tambi\u00e9n tratamos de forma intensa la cuesti\u00f3n de si los criterios de aceptaci\u00f3n deben (pre)formularse al crear la historia de usuario y en qu\u00e9 medida debe hacerse esto. Est\u00e1 claro que los criterios de aceptaci\u00f3n deben definirse en un di\u00e1logo entre el desarrollador y el propietario del producto. \u00bfPero se formulan realmente los criterios de aceptaci\u00f3n de todas las historias pendientes durante el refinamiento de la pila? \u00bfO puede resultar \u00fatil que el propietario del producto defina ciertos criterios de aceptaci\u00f3n al crear la historia, que luego puedan debatirse y cambiarse durante el refinamiento de la pila? Por un lado, nuestra experiencia ha demostrado que puede resultar ventajoso formular los criterios de aceptaci\u00f3n por adelantado para comunicar los cambios deseados a un equipo m\u00e1s amplio, pues esto proporciona un marco para el debate y la definici\u00f3n de los criterios y ahorra tiempo durante el refinamiento de la pila. Sin embargo, un argumento en contra de este enfoque es que los criterios de aceptaci\u00f3n formulados por escrito ya prescriben una l\u00ednea de pensamiento y, por lo tanto, pueden llegar a impedir la introducci\u00f3n soluciones creativas. As\u00ed que es cuesti\u00f3n de ponderar en cada caso el tiempo que se ahorra con lo que supone la b\u00fasqueda de soluciones creativas. Un compromiso podr\u00eda ser que el propietario del producto ya haya pensado en los criterios de aceptaci\u00f3n por adelantado, pero que a\u00fan no los haya fijado en la historia de usuario. De este modo, puede cotejar sus notas durante las reuniones o las charlas y a\u00f1adir sus criterios de aceptaci\u00f3n si es necesario.<\/p>\n

Dependiendo de la estructura de roles que exista entre el cliente\/contratante y el equipo del propietario del producto, la creaci\u00f3n de la visi\u00f3n del producto y, en consecuencia, la parte creativa en la elaboraci\u00f3n de las historias de usuario se deja completamente en manos del propietario del producto. En el caso de un fuerte visionario en el lado del cliente o del contratante, el propietario del producto asume m\u00e1s bien el papel de un ingeniero de requisitos, que moldea los requisitos de una forma que se ajuste al desarrollo \u00e1gil de software y represente la visi\u00f3n del cliente y su visi\u00f3n del producto ante su equipo de desarrollo. En este \u00faltimo caso, el propietario del producto suele carecer en la pr\u00e1ctica de la capacidad de decisi\u00f3n para responder a todas las consultas o incluso para aceptar propuestas de soluci\u00f3n alternativas por parte de su equipo en casos concretos. As\u00ed pues, es aconsejable crear las historias de usuario en una fase temprana y presentarlas en la reuni\u00f3n del equipo, pues as\u00ed hay tiempo suficiente antes de iniciar la puesta en marcha para aclarar cualquier cuesti\u00f3n necesaria con el cliente o el contratante.<\/p>\n

<\/h3>\n

\u00bfQu\u00e9 requisitos especiales surgen para las historias de usuario cuando se trabaja a distancia?<\/strong><\/h3>\n

En la actualidad, la crisis provocada por la pandemia de COVID-19 tambi\u00e9n ha dado lugar a nuevas situaciones y a desaf\u00edos especiales en nuestro trabajo diario. Desde este punto de vista, tambi\u00e9n hemos de comprobar si la historia de usuario sigue siendo adecuada o debe adaptarse en un equipo en el que los miembros trabajan ahora a distancia entre s\u00ed. Y, para conseguirlo, damos un paso atr\u00e1s y nos preguntamos de nuevo qu\u00e9 prop\u00f3sito debe cumplir la historia de usuario. La historia de usuario debe transmitir al equipo de desarrollo los requisitos de un sistema, desde la perspectiva del usuario y utilizando solo unas cuantas frases. Por supuesto, la historia de usuario tambi\u00e9n cumple estas condiciones en los casos en los que se trabaja a distancia, pues el propietario del producto utiliza la historia de usuario al principio de la planificaci\u00f3n y al principio del refinamiento para explicar el problema al equipo. Adem\u00e1s, las historias de usuario se consultan durante el proceso de desarrollo en curso para recordar las relaciones entre las tareas individuales, o bien al finalizar la puesta en marcha, para volver a comprobar si los requisitos se han cumplido en todos los aspectos desde el punto de vista del usuario. En este punto en particular, es preferible que la historia de usuario se haya descrito con cierto detalle, puesto que, trabajando a distancia, no es posible preguntar a la persona que tenemos al lado o al propietario del producto que est\u00e1 sentado junto a nosotros si se ha entendido todo correctamente.<\/p>\n

Por supuesto, la comprensi\u00f3n correcta y completa de la historia de usuario tambi\u00e9n se necesita en las planificaciones y los refinamientos que se llevan a cabo peri\u00f3dicamente. Asimismo, adem\u00e1s de prestar m\u00e1s atenci\u00f3n a los detalles, existen otros consejos que pueden ayudar a conseguir resultados \u00f3ptimos en estas reuniones, incluso trabajando a distancia. Esto significa que el propietario del producto debe estar m\u00e1s pendiente de las expresiones faciales de su p\u00fablico. Por ejemplo, un ce\u00f1o fruncido o una mirada errante suelen ser indicios de que el oyente est\u00e1 absorto en sus pensamientos o se ha desconectado del hilo del discurso. Planteando preguntas espec\u00edficas, el propietario del producto puede comprobar si hay cuestiones que a\u00fan no se han entendido, as\u00ed como registrar las respuestas por escrito en la historia de usuario.<\/p>\n

De la experiencia que hemos adquirido en los equipos que trabajan a distancia y, sobre todo, de las \u00faltimas semanas, hemos extra\u00eddo m\u00e1s indicaciones y consejos, que hemos reunido en nuestro podcast de v\u00eddeo, en los art\u00edculos del blog y en la serie de seminarios web denominada \u00abAgile Wednesday\u00bb<\/a>. Nos gustar\u00eda haber despertado su inter\u00e9s y estaremos encantados de que vuelva a visitarnos. [\/vc_column_text][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_empty_space][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_column_text]<\/p>\n

Estos son algunos consejos para realizar buenas historias de usuario<\/strong><\/h2>\n

[\/vc_column_text][vc_empty_space][\/vc_column][\/vc_row][vc_row css_animation=\u00bb\u00bb row_type=\u00bbrow\u00bb use_row_as_full_screen_section=\u00bbno\u00bb type=\u00bbfull_width\u00bb angled_section=\u00bbno\u00bb text_align=\u00bbleft\u00bb background_image_as_pattern=\u00bbwithout_pattern\u00bb][vc_column][vc_accordion active_tab=\u00bb0″ collapsible=\u00bbyes\u00bb style=\u00bbaccordion\u00bb][vc_accordion_tab title=\u00bbCard, Conversation und Confirmation\u00bb][vc_column_text]Ron Jeffries menciona tres aspectos decisivos que deben tenerse en cuenta a la hora de crear historias de usuario. Son los t\u00e9rminos ingleses \u00abcard\u00bb, \u00abconversation\u00bb y \u00abconfirmation\u00bb, que significan tarjeta, conversaci\u00f3n y confirmaci\u00f3n.<\/p>\n

Card
\n<\/strong>Lo habitual es que las historias se escriban en tarjetas, por lo que los propietarios del producto deben ser breves para no utilizar m\u00e1s espacio del que permite la tarjeta.<\/p>\n

Conversation
\n<\/strong>Los requisitos no deben \u00ablanzarse sin m\u00e1s\u00bb al equipo de desarrollo. El propietario del producto y los desarrolladores deben hablar entre s\u00ed sobre las tarjetas para afianzar la comprensi\u00f3n y el entendimiento de todas las partes implicadas, pues que los escollos y los problemas se encuentran precisamente en los detalles. As\u00ed, solo si se entabla una conversaci\u00f3n es posible demostrar si los desarrolladores tienen realmente claro lo que deben construir. Para este prop\u00f3sito, los desarrolladores y el propietario del producto deben mantener un di\u00e1logo en el que definan juntos los criterios de aceptaci\u00f3n en cada caso. Y, una vez que se dispone de la formulaci\u00f3n para una historia de usuario, los desarrolladores suelen plantearle al propietario del producto las preguntas cuyas respuestas llevar\u00e1n a los criterios de aceptaci\u00f3n.<\/p>\n

Confirmation
\n<\/strong>Una historia de usuario no finaliza hasta que se cumplen los criterios de aceptaci\u00f3n, que describen lo que se espera de la historia para informar de ella como \u00abterminada\u00bb. Los criterios de aceptaci\u00f3n son flexibles y se adaptan seg\u00fan sea necesario hasta que el equipo comienza a llevar a cabo la historia de usuario. El maestro de Scrum (Scrum Master) y el equipo de desarrollo constatan en los debates y las conversaciones si existe un entendimiento com\u00fan, lo que sirve para evitar malentendidos que luego costar\u00eda mucho tiempo arreglar. 1<\/a><\/sup>[\/vc_column_text][\/vc_accordion_tab][vc_accordion_tab title=\u00bbINVEST-Prinzip\u00bb][vc_column_text]En un caso ideal, la historia de usuario terminada debe escribirse seg\u00fan el principio INVEST<\/strong>:<\/p>\n