¿Alguno de ustedes diseñadores está usando Pivotal Tracker? ¿Cuál es su proceso para integrar el desarrollo y el diseño en Tracker?

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.

He visto esto hecho, pero debe tener cuidado de cómo lo integra en su proceso general. Por lo general, recomiendo que NO incluya tareas de diseño en el mismo proyecto Pivotal Tracker que usa para seguir su desarrollo. La mayoría de los equipos necesitan mantener su diseño en una línea de tiempo ligeramente diferente a su desarrollo, y colocarlos en el mismo proyecto de Rastreador puede causar confusión sobre las prioridades.

Si desea realizar un seguimiento del esfuerzo de diseño en Tracker (que es una buena idea), solo asegúrese de incluirlo en un proyecto separado.

Lo he estado usando por más de un año. Mi sugerencia: ponga todo, desde ideas hasta el trabajo a realizar y el trabajo que se está realizando actualmente. Luego asigne las tareas y tenga una reunión física para que todos estén en la misma página. Realmente no debería requerir mucho esfuerzo.

Puede * agregar * errores, pero realmente veo errores en PT como desviaciones del requisito en lugar de errores reales como sabemos en el software (use su integración BugZilla para eso).

Solo desearía que tuvieran la integración de Yammer para comentarios.

Por cierto, asegúrese de obtener la aceptación de todos los miembros del equipo. No funciona de otra manera. O bien, obtenga una pista para asegurarse de que se use si no tiene creyentes (algunos tardan un tiempo en adaptarse).