¿Cómo escribir historias de usuario para nuestro proceso de desarrollo de UI?

En primer lugar, permítanme disculparme si cometo algunos errores de escritura ya que el inglés no es mi idioma nativo.

Actualmente trabajo en una empresa de UX como desarrollador front-end y tengo algunos problemas para entender el desarrollo ágil correctamente. Permítanme darles un poco de contexto sobre nuestro entorno de trabajo antes de hacer mi pregunta.

Mi empresa actual se centró principalmente en la consultoría de UX, creando la arquitectura de la información, diseñando las aplicaciones y creando las vistas de una manera muy antigua (creando páginas estáticas con mucho CSS contextual y jQuery, en lugar de crear sistemas modulares que te permitan crear tales páginas). Luego, las "vistas" se le darían al cliente y una empresa de terceros integraría ese código con el back-end del cliente. Actualmente lo que tengo como desarrollador es un diseño de las diferentes vistas (páginas completas) y sus diferentes estados y tengo que codificarlos.

Últimamente tienen algunos clientes que querían que sus proyectos/IU ​​se crearan con Angular, por lo que me contrataron para modernizar su flujo de trabajo, ya que tengo experiencia en la creación de aplicaciones Angularjs con una filosofía más basada en componentes. El problema es que nunca he trabajado en un entorno ágil/scrum y estamos pensando en implementarlo, así que lucho con algunos conceptos.

¿Qué podría ser una historia de usuario en mi caso? Quiero decir, estoy separado del proceso de diseño del producto. Lo que tengo son algunos archivos .psd que deben transformarse en una aplicación web, por lo que no estoy seguro de cómo debo definir las historias de usuario para el equipo de desarrollo. Crear un componente podría ser una tarea, pero no puedo asignar historias de usuario a un proceso aislado de codificación de una interfaz de usuario.

Una vez más, recién estoy comenzando con el desarrollo ágil y estoy seguro de que se pueden detectar muchos defectos en mi proceso de pensamiento, así que espero que puedan entender lo que estoy tratando de decir.

Gracias de antemano.

Respuestas (2)

Haces una pregunta bastante amplia, así que discúlpame si mi respuesta es demasiado amplia. Parece que está comenzando con los .psd y luego su equipo de desarrollo actuará como un equipo ágil desde allí hasta la entrega. Puede que esto no sea lo ideal, pero lo dejaré para el final.

Dada su circunstancia, primero quiero aclarar que, si bien Agile promueve la medición del progreso en el trabajo del software de extremo a extremo, esto puede ser confuso para su grupo. Parece que su punto a punto está todo en HTML, CSS y jQuery/Angular. Si luego se lo pasa a otra empresa para que haga servicios web o algo así, no trataría de incorporar eso en su idea de Listo. Su punto a punto significa que la funcionalidad de la página y el JS funcionan correctamente y puede probarlo.

En cuanto a la construcción de historias, la clave es centrarse en la entrega de valor, no en la creación de artefactos. Por ejemplo, la creación de artefactos diría:

Como usuario, me gustaría una página de inicio de sesión para poder iniciar sesión.

y tendría criterios de aceptación como:

Puedo iniciar sesión. Tengo un enlace de contraseña olvidada...

Centrándose en la capacidad sería:

Como usuario registrado que olvidó su contraseña, me gustaría poder proporcionar mi correo electrónico y recibir un recordatorio de mi contraseña.

La idea es que, en lugar de que su trabajo se centre en recrear el .psd, intente crear funcionalidad utilizando el .psd como su guía de cómo debería verse. Por cierto, habrá recreado el .psd para cuando haya terminado, así que no se preocupe por perder algo allí.

Cómo podría ser mejor: puede encontrar algunos inconvenientes con sus diseñadores que aún trabajan con el enfoque de simular un psd y entregarlo. Probablemente ya sepa que Photoshop y los navegadores renderizan los gráficos de manera diferente y que se puede perder una cantidad increíble de tiempo tratando de igualarlos. Además, si una parte de la funcionalidad fluye a través de muchas pantallas, es posible que los diseñadores hayan completado solo la mitad de las pantallas que necesita para entregar la funcionalidad.

He visto equipos que realmente luchan con esta dinámica antes y tienen mucho más éxito al pasar a un sistema donde hay una hoja de estilo estándar para componentes web y usan prototipos rápidos para el diseño.

Gran respuesta Daniel, es muy esclarecedor. Descubriste correctamente nuestra forma de trabajar. Pensar en mi definición de hecho fue útil. Sobre la última parte, ¿tiene alguna buena lectura/guía sobre ese flujo de trabajo específico que profundice en el problema? Lo agradecería mucho. Muchas gracias, tu conocimiento es muy útil.
No tengo ninguna lectura para ir, pero eché un vistazo. Siento que este hace un buen trabajo al describirlo: romanpichler.com/blog/agile-user-interface-design Y este habla un poco más sobre dividir el trabajo: blogs.balsamiq.com/ux/2013/02/ 06/… El segundo especialmente es un poco demasiado prescriptivo en lo que estás construyendo para mi gusto. Creo que se está enfocando demasiado en construir exactamente una cosa en lugar de resolver una necesidad del usuario, pero siempre que tenga eso en cuenta, creo que es un buen artículo.
Además de "Cómo podría ser mejor", también recomendaría (si aún no lo está haciendo) que su equipo sea multifuncional; haga que el diseñador visual, el arquitecto de información/UX, los desarrolladores front-end como usted se sienten todos juntos y compartan la comprensión y los objetivos en torno a las necesidades, planes, resultados, procesos, etc. de los usuarios. Aunque puede que no haya mucha superposición en los conjuntos de habilidades, trabajar de cerca y en colaboración en todas las etapas (eso significa que usted está involucrado en los primeros conceptos hasta la entrega) es un tiempo bien empleado.
Como desarrollador frontend, estoy teniendo esta misma lucha. Las maquetas deben estar impulsadas por las historias de los usuarios, pero a menudo experimento el enfoque opuesto. Echaré un vistazo a los artículos anteriores y veré si ayudan.

Me doy cuenta de que esta es una pregunta anterior, pero creo que sigue siendo relevante dada mi lucha por encontrar una respuesta a su pregunta. Esto es lo que se me ocurrió para algunas mejores prácticas para escribir tickets/tareas de interfaz:

  1. Las maquetas (que a menudo impulsan las tareas de interfaz) deben realizarse después de escribir las historias de los usuarios (quién, qué, dónde, por qué). Estas historias deben explicar el valor para el usuario, que es un contexto importante para las tareas de interfaz.
  2. Las tareas/tickets de front-end deben ser parte de las historias de los usuarios y estar impulsadas por las historias de los usuarios, pero una tarea o ticket de front-end individual no necesita tener una historia de usuario.
  3. Las tareas de interfaz pueden describirse mejor con descripciones funcionales y criterios de aceptación en lugar de historias de usuarios.

Recursos: https://balsamiq.com/learn/resources/articles/userstories/ https://builttoadapt.io/this-is-what-my-user-stories-look-like-50c7b127bb26 https://en.wikipedia .org/wiki/Feature-driven_development

Espero que ayude.