¿Dónde se debe incorporar el diseño en un proceso ágil?

Hemos luchado con esto también. Esto resume un poco nuestro viaje, ¡eso no quiere decir que las mismas cosas se aplicarán a ti!

El trabajo de diseño se realiza en sprint.

Esto solía estar bien cuando hacíamos sprints largos (4 semanas) y había tiempo para un intercambio entre el diseñador, UX y Marketing sobre cuál debería ser el diseño final. Sin embargo, incluso en sprints largos, si estuviéramos haciendo un diseño muy diferente al que existe actualmente (es decir, rediseño de marca), las partes interesadas querrían más tiempo para pensar que el que hubo en el sprint. Creo que este enfoque puede funcionar si la duración de su sprint es razonablemente larga, está trabajando con estrictas pautas de marca y su PO puede aprobar los diseños por sí mismo sin tener que acudir a otras partes interesadas.

A medida que nuestras iteraciones se acortaron y nos quemamos con más historias bloqueadas en espera de la aprobación del diseño, intentamos:

Diseño como historias separadas

Esto nos permitió entregar el trabajo antes, lo que nos permitió planificar mejor cuándo necesitábamos comenzar el trabajo de diseño para asegurarnos de que se cerrara a tiempo para trabajar en la historia. Esto ha funcionado bien, pero causa algunos problemas con la velocidad y la estimación (vea la respuesta de Lunivore) y nunca me interesó tener historias dependientes en la cartera de pedidos (el diseño no tiene valor sin el desarrollo, el desarrollo no se puede hacer sin el diseño).

Ahora estamos haciendo:

El diseño es parte de nuestra definición de ready

Tenemos una columna lista para el sprint en nuestro tablero: las historias solo pueden pasar de la cartera de pedidos a estar listas si tienen el tamaño adecuado, tienen criterios de aceptación y tienen diseños completos y aprobados. Esto aún nos brinda visibilidad de las próximas historias para las que necesitamos diseños sin tener 'diseño para la página xyz' por separado en la cartera de pedidos y el trabajo de diseño se realiza fuera del sprint, por lo que no afecta la estimación o la planificación.

Dicho esto, todavía tenemos algunas historias que aparecen en las que terminamos haciendo desarrollo de wireframes para colocar las cosas en el lugar correcto y terminamos haciendo el CSS una semana o dos más tarde cuando tenemos los diseños reales.

Hay tres razones para la estimación:

• Para calcular cuánto puede aguantar el equipo en cada sprint
• Para calcular cuánto tiempo llevará completar un lanzamiento, dado el equipo disponible
• Permitir que el equipo alcance un entendimiento común sobre el alcance del trabajo.

No se trata realmente del tamaño del trabajo, sino más bien de cuánto puede caber a través de su tubería de desarrollo.

Por esta razón, tiendo a alentar a los equipos a que se preocupen por el esfuerzo de desarrollo, en lugar de incluir también el análisis, el diseño de la interfaz de usuario, las pruebas, etc. El desarrollo normalmente constituye la parte más restringida de la canalización. Hay muchas cosas que los desarrolladores pueden hacer para ayudar a los analistas y evaluadores, si se sobrecargan de trabajo, pero a menos que un miembro del equipo pueda codificar, no hay mucho que puedan hacer para ayudar a los desarrolladores, por lo que me concentro únicamente en los puntos de desarrollo. Centrarse solo en los puntos de desarrollo es suficiente para obtener estas tres cosas.

Con respecto a trabajar en colaboración en lugar de tener dependencias, por lo general animo a los analistas y diseñadores a trabajar un sprint por delante de los desarrolladores, asegurándome de que se haga lo suficiente para que los desarrolladores tengan una idea del alcance del trabajo que están haciendo. asumir en la reunión de planificación y estimarlo con la mayor confianza posible.

He encontrado útil hacer que los diseñadores piensen en lo que podría ser fácil de cambiar más tarde (texto, colores, ubicación, etc.) y centrarse en dibujar una estructura alámbrica que los desarrolladores pueden usar para obtener los controles correctos en una página o pantalla. . Luego pueden trabajar en colaboración, en la última parte del sprint, para corregir los detalles finos. He encontrado que este también es un enfoque útil con análisis y detalles como validación, mensajes de error o con arquitectura y el contenido real de mensajes HTML/XML, palabras clave RESTful, etc. Mantener las cosas fáciles de cambiar más tarde hace que el análisis previo al sprint sea muy mucho más liviano y puede ayudar a los equipos a colaborar de manera más efectiva, independientemente de su rol.

Esto es algo con lo que mi equipo también lucha.

Y esto me llevó a hacerle una pregunta diferente a mi equipo.

"Si no sabe cuál es el diseño, ¿cómo puede elaborar la historia y aceptarla en la iteración"?

Como puede adivinar, esta pregunta fue recibida con miradas en blanco y un silencio atónito. Simplemente lo hacemos fue la respuesta final.

En última instancia, creo que la mejor manera de manejar esta pregunta es tener estándares de diseño y codificación claros y definidos a los que el equipo se adhiera con un fervor casi religioso. A medida que la historia se revisa en el backlog a través de una reunión de preparación semanal, se actualiza y se acuerda un diseño aproximado basado en los estándares aceptados por los equipos.

Si se sigue este proceso, sus reuniones de planificación de Sprint/iteración serán mucho más fluidas. Esto también debería aumentar su velocidad y reducir la cantidad de historias que no lograron ser aceptadas porque no pudieron completarse debido al trabajo encontrado.

Si está hablando de gráficos e interfaz de usuario, siempre me ha parecido útil dividir este esfuerzo en dos o más historias, la primera historia ofrece la funcionalidad sin ninguna de las campanas o silbatos, esto le da al equipo de diseño algo para iterar y venir. con un diseño final en una siguiente iteración.

Idealmente, todos los elementos de diseño se extraen en archivos de recursos para que puedan actualizarse sin tener que volver a implementar la página.

jeff

Cuando se trabaja con software, creo que el diseño bien hecho siempre está sucediendo. Miro las historias como centradas en el negocio/usuario, no centradas en el desarrollo. Una historia como "Obtener estados de la base de datos". se centra en el desarrollo y dará lugar a muchos problemas. Una historia como "Mostrar el estado del pedido". está más centrado en el negocio/usuario. Si elige dividir esa historia en tareas (algo que en realidad no recomiendo), entonces la dividiría para que cada tarea incorpore todas las capas de su arquitectura.

Cuando su equipo se acostumbre a hacer esto, encontrará las consideraciones de diseño temprano y si su equipo tiene una buena comunicación (una gran clave en mi libro), las decisiones de diseño se discutirán en el momento adecuado, ya que la discusión se llevará a cabo de forma dinámica y no planificada.

Espero que esto ayude.

Si está tratando de estimar la interfaz de usuario y la arquitectura generales al comienzo del proyecto, considere si se basará en proyectos anteriores o no.

Si no, usaría historias de usuario separadas y les asignaría una alta prioridad y tal vez un riesgo. Me preguntaría por qué los diseños de arquitectura o interfaz de usuario anteriores ya no son adecuados. Esto le ayudará a escribir historias que tengan sentido para el cliente.

Si decide que la interfaz de usuario o la arquitectura serán similares a los proyectos anteriores, probablemente no se requiera una historia separada.

Creo que una buena definición de HECHO es útil en este caso. Mi equipo sabrá que si marcan una historia de usuario como TERMINADA, debe analizarse más, diseñarse, implementarse, refactorizarse, probarse, revisarse por pares e integrarse en la compilación: la historia es potencialmente entregable. El diseño del aviso está ahí. Sus estimaciones reflejan esto.

También es útil si su equipo desarrolla software que tiene una capa de presentación desacoplada (lo que significa que la interfaz de usuario está codificada por separado de la lógica). Esta técnica reducirá la dependencia entre la mayoría de las historias. Tal vez pregúntele a su equipo si este es el caso.

Desafortunadamente, como la mayoría de las cosas en Scrum, no hay una manera correcta o incorrecta. Debe considerar muchos factores y decidir qué funciona para usted.

Tenemos un "preproyecto" antes de que comience el proyecto real. En este proyecto se finalizan los US's, se crean los casos de usos inteligentes y se realizan los wireframes.

De esta manera tenemos un punto de partida para cuando empecemos el proyecto "real". El diseñador puede trabajar en la conversión de wf en diseños, la interfaz puede hacer lo mismo y los desarrolladores de .Net y SQL pueden hacer ese trabajo. Todo el equipo en un solo equipo SCRUM.

Ofc todavía hay margen de cambio y mejora en el proyecto "real"