“Los miembros de un equipo de Scrum están acostumbrados a ver dos nuevos roles en sus proyectos: el ScrumMaster y el Product Owner. Pero los cambios a un equipo de proyecto Scrum van mucho más allá de la introducción de dos nuevos roles. Por ejemplo, la naturaleza auto-organizada de un equipo Scrum elimina el rol del líder técnico, los individuos deben ver más allá de sus especialidades y ayudar al equipo de cualquier forma posible; el énfasis se traslada de la simple escritura de requerimientos a la conversación sobre los mismos, y los equipos deberán producir algo tangible para el final de cada Sprint. Porque estos cambios alteran los roles y relaciones dentro del equipo y la organización, muchos contribuyen a los desafíos que estas organizaciones enfrentan cuando adoptan Scrum.”

Esta es una serie de traducciones al español del artículo publicado el 12 de Enero en InfoQ con un extracto del libro “Succeeding with Agile: Software Development Using Scrum” de Mike Cohn. Hoy publico la sección de “Diseñadores de Experiencia de Usuario" como parte de la serie "Roles ágiles".

Diseñadores de Experiencia de Usuario Ágiles

Los diseñadores de experiencia de usuario (User Experience Designers) a menudo tienen una preocupación legítima con la adopción de Scrum. A pesar de que están acostumbrados a trabajar de forma iterativa, prefieren ejecutar sus iteraciones antes que el resto del proyecto. En un proyecto Scrum, sin embargo, no queremos hacer todo el trabajo UED antes de comenzar las actividades de desarrollo. This article is a Spanish direct translation of the “Programmers” section from the InfoQ Article named “Book Excerpt: Succeeding with Agile: Software Development Using Scrum“, which is about Mike Cohn’s book “Succeeding with Agile: Software Development Using Scrum“.

You can access the Spanish version of this article following this link.

Since the original article is written in English, I see no need to translate it. Please visit the original article here: http://www.infoq.com/articles/cohn-chapter8Mis descripciones favoritas de cómo funcionan los diseñadores ágiles han surgido de Autodesk en Toronto. Lynn Miller y Desiree Sy han escrito sobre el enfoque que han utilizado para integrar el diseño en un proceso ágil. He trabajado en docenas de proyectos en los que los equipos y diseñadores adoptaron su consejo.


Según Miller y Sy, debería haber dos vías paralelas de trabajo en el proyecto: una para el desarrollo y una para el diseño de interacción. La figura 8.2 muestra estas dos vías y la interacción entre ellas. La idea esencial aquí es que el trabajo UED siempre precede a la labor de desarrollo en por lo menos un sprint. A los UEDs se les da una ventaja inicial en el proyecto a través de una combinación de un sprint cero inicial y un enfoque en el sprint uno en funcionalidades con pocas o ninguna implicancias de interfaz de usuario.


El enfoque que se muestra aquí puede trabajar bien, pero trae consigo el riesgo de que UEDs se ven a sí mismos como un equipo independiente. Lynn Miller esbozó la primera versión de este diagrama y está de acuerdo en que no debe ser interpretado como que hay equipos separados.


Siempre que he enseñado este concepto en insistí en que los diseñadores no debe pensar en sí mismos como un equipo independiente y que la comunicación estrecha y frecuente es esencial para el concepto funcione. Siempre ha habido un fallo en el diagrama que parece sugerir la separación del equipo cuando esa nunca fue mi intención.


El diseño de experiencia de usuarios y el desarrollo puede ocurrir en pistas paralelas. (Adaptado por cortesía de Lynn Miller.)

Es esencial que los UEDs se ven a sí mismos como parte del equipo. La idea de equipos interdisciplinarios es fundamental en Scrum, el equipo debe incluir a todos los necesarios para llegar de la idea a la implementación. ¿Qué impediría a un equipo de testing la preparación de su propia versión de la figura 8.2 que muestre las pistas paralelas de la programación y sprints de testing?

Si yo encontrara a un UED en el pasillo de su empresa y preguntara, "¿Qué haces tú?" Podría obtener una respuesta como esta: "Soy un diseñador de experiencia de usuario. Yo trabajo de un sprint delante de los desarrolladores. Mi trabajo es asegurarme de que cuando empiezan un sprint les pueda dar un diseño de lo que van a desarrollar en ese sprint“. Esta respuesta se corresponde con la figura 8.2, pero no es una respuesta que me gusta. En lugar de eso prefiere escuchar "Soy un diseñador de experiencia de usuario. Estoy en el equipo de desarrollo, y mi trabajo principal es asegurarnos de terminar lo que nos comprometemos a trabajar para cada sprint. Pero eso no ocupa todo mi tiempo, entonces empleo una buena cantidad del mismo mirando hacia adelante en lo que vamos a construir en un sprint o dos. Luego reúno datos, maqueto diseños, y hago todo lo que está a mi alcance para que cuando empecemos una característica en un sprint futuro, seamos capaces de terminarlo en ese mismo sprint. "

Ambas citas ficticias describir exactamente el mismo trabajo. En ambos casos, los UEDs están trabajando con el equipo durante el sprint para resolver los problemas de ese sprint, pero también miran hacia adelante. Sin embargo, las dos respuestas reflejan diferentes modos de pensar sobre el trabajo. En primer lugar, quiero que los UEDs se sientan parte del equipo y que su principal prioridad sea la entrega de la funcionalidad a la que se han comprometido para el sprint actual. Más allá de eso, su trabajo es mirar hacia adelante de la misma manera que todo el mundo espera de un Product Owner, que mire hacia adelante lo que está haciendo la competencia, lo que los usuarios querrán a continuación, etc.

Yo no soy el único en pensar que una mentalidad ágil es fundamental para que los UEDs hagan la transición a Scrum. Un muy respetado experto en usabilidad -Jakob Nielsen- está de acuerdo:

Para los profesionales de experiencia de usuario que apoyan a los equipos ágil, el principal cambio es de mentalidad. Teniendo buen conocimiento general sobre la experiencia de usuario le ayudará a comprender cómo cambiar el diseño tradicional y métodos de evaluación para cumplir con el nuevo enfoque de su equipo Agile. En última instancia, sin embargo, ambos deben creer en sí mismos y comprender los conceptos del desarrollo ágil si quieren tener éxito. Si están preparados para cambiar sus prácticas y asumir la responsabilidad, hay grandes oportunidades para mejorar su eficacia y su impacto en los equipos en los que trabajan.


Dime lo que piensas. Por favor, deja un comentario más adelante (y luego dale click a ese botón de 'Me gusta'!)

Seguir leyendo


Comentarios

comments powered by Disqus