{"id":37577,"date":"2015-04-13T12:04:00","date_gmt":"2021-02-10T11:00:11","guid":{"rendered":"https:\/\/www.globallogic.com\/latam\/insights\/blogs\/escribiendo-user-stories-en-agile\/"},"modified":"2025-01-30T11:21:47","modified_gmt":"2025-01-30T11:21:47","slug":"escribiendo-user-stories-en-agile","status":"publish","type":"insightsection","link":"https:\/\/www.globallogic.com\/latam\/insights\/blogs\/escribiendo-user-stories-en-agile\/","title":{"rendered":"Escribiendo User Stories en Agile"},"content":{"rendered":"<div class=\"classic_editor_content\">Las metodolog\u00edas \u00e1giles proponen iteraciones cortas para desarrollar software de manera incremental. En cada iteraci\u00f3n los requerimientos a desarrollar se expresan mediante user stories. Una user story se expresa mediante una oraci\u00f3n simple, siguiendo un formato cl\u00e1sico y busca mostrar las necesidades del usuario para con el uso del sistema de manera directa y precisa. Dicho formato es el siguiente: \u201cC\u00f3mo quiero para \u201d. Cada user story es acompa\u00f1ada de criterios de aceptaci\u00f3n, los cuales detallan qu\u00e9 condiciones debe cumplir el c\u00f3digo que implementa la user story. Los criterios de aceptaci\u00f3n ser\u00e1n utilizados tanto por los desarrolladores como por los testers para validar la conformidad de la aplicaci\u00f3n con los requerimientos funcionales.<\/p>\n<p>Escribir buenas user stories no es trivial. Es un ejercicio que requiere tiempo y experiencia. En particular, existen un tipo de user-stories que requieren especial atenci\u00f3n: son aquellas denominadas \u201ct\u00e9cnicas\u201d o de investigaci\u00f3n. Sobre las mismas surgen voces a favor y en contra. A continuaci\u00f3n se detallan consejos para redactar buenas user-stories, y se da un panorama sobre las user-stories de investigaci\u00f3n.<\/p>\n<p><strong>El arte de redactar<\/strong><\/p>\n<p>En la referencia [1] se detallan los cinco errores m\u00e1s comunes a la hora de redactar User Stories. En primer lugar se menciona el problema de describir user-stories muy generales, del estilo \u201cComo usuario quiero manejar distintas cotizaciones para poder seleccionar la m\u00e1s conveniente\u201d. Si bien a primera vista cumple el patr\u00f3n esperado de una user-story, el rol de la misma no est\u00e1 bien especificado. \u00bfQui\u00e9n es el usuario observando las cotizaciones? Es distinta la funcionalidad detr\u00e1s si es el administrador del sitio, o un usuario visualizando datos.<\/p>\n<p>Es fundamental por lo tanto especificar lo m\u00e1s detalladamente posible el usuario detr\u00e1s de cada user-story. De manera similar para una user-story que comienza con \u201cComo Product Owner\u2026.\u201d o \u201cComo desarrollador\u201d. Una buena user-story refleja la visi\u00f3n desde el punto de vista del usuario del producto final, y no desde el l\u00edder o integrante del equipo de desarrollo.<\/p>\n<p>Otro error com\u00fan es ignorar la parte de para qu\u00e9 quiero la funcionalidad de la user-story. Parece trivial, pero poder justificar la funcionalidad pedida es un ejercicio \u00fatil para mejorar el proceso de identificar requerimientos. Si no es posible formular de manera simple para qu\u00e9 se quiere una determinada funcionalidad del producto, es probable que no sea necesaria implementarla. Finalmente, se destaca la necesidad de especificar criterios de aceptaci\u00f3n. Una manera de verlos es como casos de prueba para el c\u00f3digo que implementa la user-story, y por su papel debe prestarse atenci\u00f3n en su formulaci\u00f3n. Por ejemplo, para una user story que describe la funcionalidad de buscar un determinado producto en un cat\u00e1logo, un criterio de aceptaci\u00f3n podr\u00eda describir el escenario donde no se encuentre el producto al realizar la b\u00fasqueda y especificar en este caso que se espera que aparezca en pantalla un texto del estilo \u201cActualmente no se posee el producto en stock. Vuelva a consultar pronto!\u201d<\/p>\n<p><strong>User-stories t\u00e9cnicas o de investigaci\u00f3n<\/strong><\/p>\n<p>En repetidas ocasiones surge la necesidad de contemplar user-stories un tanto particulares, donde no se refleja la necesidad de un usuario final, sino del equipo de desarrollo. Si el equipo necesita emplear avanzadas t\u00e9cnicas de encriptaci\u00f3n de datos para desarrollar un producto seguro, \u00bfes una buena pr\u00e1ctica \u00e1gil agregar una user-story \u201cinterna\u201d del equipo donde se refleje la necesidad de estudiar t\u00e9cnicas de encriptaci\u00f3n? En este sentido hay voces a favor y en contra.<\/p>\n<p>En las referencias [2,3] se manifiestan en contra de su utilizaci\u00f3n. Los argumentos son que en realidad son requerimientos que se alejan de la noci\u00f3n de user-stories, lo cual produce un product backlog entremezclado y confuso. Proponen en cambio incluir los requerimientos t\u00e9cnicos como tareas dentro de user-stories, introduci\u00e9ndolos de manera gradual y fiel a los conceptos \u00e1giles.<\/p>\n<p>Las voces a favor (ver [4,5]) argumentan que en determinadas ocasiones es provechoso tener expl\u00edcitamente historias que reflejen la necesidad de investigar una tecnolog\u00eda, realizar un prototipo, etc. En especial, cuando son actividades cr\u00edticas para el producto. Por ejemplo, si el equipo est\u00e1 desarrollando un proyecto de e-commerce es cr\u00edtico que el equipo sea experto en cuestiones de seguridad. En caso de no contar con la suficiente experiencia, es posible emplear user-stories t\u00e9cnicas o de investigaci\u00f3n que reflejen la inversi\u00f3n en tiempo y esfuerzo del equipo en investigar t\u00e9cnicas y herramientas de seguridad y encriptaci\u00f3n. Muchas veces estas stories se conocen como user stories de tipo \u201cspike\u201d.<\/p>\n<p><strong>Conclusiones<\/strong><br \/>\nComo siempre, mucho depende de la experiencia y del equipo llevando adelante el proyecto. Para redactar buenas user stories, el mejor consejo es seguir fielmente el patr\u00f3n propuesto:\u201cC\u00f3mo quiero para \u201d. El mismo es un proceso que tiende a mejorar a medida que se adquiere m\u00e1s experiencia. Sobre las user stories t\u00e9cnicas, son buenas en la medida que se justifique su utilidad, y tenga un output concreto. Por ejemplo, el algoritmo de encriptaci\u00f3n que mejor se adapta al proyecto es un buen entregable de una user story t\u00e9cnica.<\/p>\n<p><strong>Referencias:<\/strong><\/p>\n<p>[1] https:\/\/www.scrumalliance.org\/community\/articles\/2011\/august\/5-common-mistakes-we-make-writing-user-stories<br \/>\n[2] http:\/\/xprogramming.com\/articles\/technical-stories-we-dont-need-em\/<br \/>\n[3] http:\/\/www.industriallogic.com\/blog\/as-a-developer-is-not-a-user-story\/<br \/>\n[4] http:\/\/programmers.stackexchange.com\/questions\/140065\/is-it-proper-to-have-investigation-task-in-sprint<br \/>\n[5] http:\/\/agileatlas.org\/articles\/item\/spikes-in-scrum-the-exception-not-the-rule<\/p><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Las metodolog\u00edas \u00e1giles proponen iteraciones cortas para desarrollar software de manera incremental<\/p>\n","protected":false},"author":12,"featured_media":25693,"parent":0,"menu_order":0,"template":"","insight":[41],"insight-subcats":[63],"insight-industry":[779],"insight-services":[],"insight-partners":[],"class_list":["post-37577","insightsection","type-insightsection","status-publish","has-post-thumbnail","hentry","insight-blogs","insight-subcats-agile","insight-industry-cross-industry"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insightsection\/37577","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insightsection"}],"about":[{"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/types\/insightsection"}],"author":[{"embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/users\/12"}],"version-history":[{"count":1,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insightsection\/37577\/revisions"}],"predecessor-version":[{"id":100930,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insightsection\/37577\/revisions\/100930"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/media\/25693"}],"wp:attachment":[{"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/media?parent=37577"}],"wp:term":[{"taxonomy":"insight","embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insight?post=37577"},{"taxonomy":"insight-subcats","embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insight-subcats?post=37577"},{"taxonomy":"insight-industry","embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insight-industry?post=37577"},{"taxonomy":"insight-services","embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insight-services?post=37577"},{"taxonomy":"insight-partners","embeddable":true,"href":"https:\/\/www.globallogic.com\/latam\/wp-json\/wp\/v2\/insight-partners?post=37577"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}