En Pivotal Labs (compañía) utilizamos algunas técnicas para manejar las dependencias de diseño en nuestra cartera de productos.
- diseño de necesidades y etiquetas de activos de necesidades : utilizamos etiquetas en Historias para indicar que una Historia necesita diseño o activos. need-design se usa para mostrar que una característica, bueno, necesita diseño: por ejemplo, los desarrolladores podríamos no tener simulacros que nos digan cómo diseñar una historia. necesidades-activos indica que nos falta algo para completar una historia, como iconos o esquinas redondeadas.
- Tarea “Mocks and Wireframes”: Esta es una innovación reciente: cree una Tarea en el Icebox titulada “Mocks and Wireframes” y adjunte todos esos elementos a esa Tarea, dándonos una ubicación central y bien conocida para encontrarlos. Esto es mejor que enviar simulacros por correo electrónico o adjuntarlos a historias individuales que podrían estar terminadas, eliminadas o renombradas.
- Tarea de “Activos”: al igual que la Tarea de Mocks y Wireframes anterior, solo adjunte sus activos aquí. Esto funciona mejor cuando no tiene una gran cantidad de activos, o cuando su equipo está iterando sobre un activo en particular, tratando de hacerlo bien: elimine el antiguo de la Tarea de activos y cargue el nuevo.
Estoy de acuerdo con Drew McManus en que el esfuerzo de diseño (es decir, Historias de diseño con valores de puntos que fluyen a través de la tubería de inicio => terminado => entregado => aceptar / rechazar ) es muy raro y nunca he estado en un proyecto donde las tareas de un diseñador fueron tratados como cualquier otra historia priorizada. Podría publicar una pregunta de seguimiento para discutir si las Historias de diseño y desarrollo deberían coexistir en el mismo proyecto.
