Estamos dando nuestros primeros pasos en el mundo del desarrollo Agile, y aunque tenemos un largo camino por recorrer, estoy teniendo dificultades para incorporar a nuestro diseñador gráfico en el proceso de desarrollo.
El PO anterior creía en un Product definition => designer => Developersflujo. El diseñador trabajó con el gerente de producto para crear una presentación de imágenes exactas de la aplicación y enviarla a los desarrolladores para su implementación. Esto generó un gran desperdicio ya que cualquier cambio requería que el diseñador actualizara muchas diapositivas. Además, dado que hizo todas las imágenes para toda la aplicación de antemano, cuando el desarrollo de la aplicación progresó, hubo cambios en el diseño que nuevamente lo hicieron cambiar muchas diapositivas. Otro tema problemático fue que las imágenes no explican el comportamiento esperado: ¿qué sucede cuando hay un error? ¿Usando qué animación debería aparecer una ventana emergente? esto causó muchos errores relacionados con el comportamiento esperado.
Para eliminar este desperdicio, le pedí al diseñador que creara un conjunto de imágenes para cada historia, cuando la mayor parte de la imagen es un boceto de la aplicación y solo las partes relacionadas con la característica actual son imágenes reales. Además, le pedí al gerente de producto que escriba los criterios de aceptación que definen el comportamiento esperado (que incluye cualquier comportamiento o mensajes de error específicos).
Esto fue solo un tiro en la oscuridad, y no estoy seguro de que sea el camino a seguir. Agradecería a cualquiera que pueda compartir su opinión sobre el proceso descrito aquí, si hay algo que debería hacer de manera diferente.
El proceso que describe es bastante bueno y se adapta bastante bien a las prácticas de diseño visual Agile-scrum.
Este es el proceso de diseño visual que me ha funcionado bien en varios proyectos Agile-Scrum:
Comience con wireframes aproximados 1-2 semanas antes de entrar en una iteración. Haga que su diseñador trabaje con el PO para crear los wireframes. Intente que los wireframes se centren en la funcionalidad que SOLO se cubrirá en la historia. Si necesita agregar otros elementos a su wireframe para el contexto, asegúrese de que quede absolutamente claro qué parte de la funcionalidad cubren los wireframes y qué es adicional. Revise los esquemas ~ 1 semana antes de que comience la iteración con un líder técnico o un desarrollador para obtener comentarios. Negocie los cambios de la historia/cambios de esquema con el PO después de recibir comentarios técnicos. Al inicio de la iteración, adjunte los esquemas finales y/o los diseños visuales a la historia de usuario correspondiente. La historia de usuario debe hacer referencia al diseño visual. La historia de usuario aún debe proporcionar descripciones en los criterios de aceptación de cómo interactúan los elementos de la interfaz de usuario durante la demostración/aceptación, compare los wireframes/diseño visual con el producto real. Discuta cualquier discrepancia y ajuste el diseño o cree un defecto si es necesario para asegurarse de que ambos permanezcan sincronizados.
Algunas herramientas de wireframing son interactivas y en realidad pueden mostrar elementos de la interfaz de usuario; ventanas emergentes, modales, navegación entre páginas, etc. para ayudar a brindar aún más profundidad a los componentes de diseño visual de la historia.
Si hay un diseño visual o un cambio de estructura alámbrica durante la iteración, asegúrese de que los activos visuales se actualicen para que coincidan con la historia. He visto a tantos diseñadores trabajar con imágenes obsoletas que se siguen reutilizando en las historias. Esto crea mucha confusión para los desarrolladores.
Finalmente, intente integrar a su diseñador en el equipo. Muchos diseñadores pueden actuar también como un recurso de control de calidad observando el producto de trabajo local o de nivel de control de calidad y asegurándose de que cumpla con los criterios de diseño antes de enviarlo al PO para su revisión.
El wireframing puede ser increíblemente simple; He visto grandes wireframes salir de una pizarra. No hace falta que sea siempre bonito. Además, a menudo puede evitar el diseño visual detallado en cada historia si su proyecto reutiliza elementos de diseño. Tenga esto en cuenta cuando busque áreas para exprimir la eficiencia.
Estás en el camino correcto.
El mejor lugar para el diseño gráfico es una Definición de Ready for a User Story. El equipo percibe que la historia está lista para comenzar a desarrollarse cuando:
Una pregunta que debe hacerse es si todas las historias deben diseñarse finalmente cuando salen. De lo contrario, podría ayudar hacer solo el diseño de interacción/usabilidad por adelantado y dejar el diseño visual para más adelante. Puede que esto no sea lo ideal, ya que arrastra una historia a lo largo de varios sprints, pero podría ahorrarse la revisión inicial de las diapositivas de alta calidad.
Una de las mayores ventajas que puede brindar Agile (y todos los demás enfoques similares) es que una o dos funciones (PO y diseñadores) nunca deben tomar decisiones clave por su cuenta, o esas decisiones estarán sujetas a reelaboración innecesaria y procesos posteriores. cambio: esa es una de las principales razones por las que Agile puede brindarle un mejor producto más rápido :)
Agile fomenta que todas las funciones clave trabajen como un solo equipo.
Ashok Ramachandran
Kuf
Todd A. Jacobs
david arno