Scrum-board / Task Board y codificación de colores [cerrado]

Question

¿Qué recomendaría en cuanto a una buena codificación de colores para usar en un Storyboard?

¿Es este un buen patrón de tu experiencia?
http://maxheapsize.com/static/ScrumBoardCheatSheet.pdf
¿Cuál es el código de color más estándar?

Answer 1

Sugiero blanco para los elementos normales de la cartera de pedidos, es decir, aquellos con valor comercial, y rojo para las correcciones de errores. Esto hace que los errores se destaquen y ayuda al equipo a mejorar.

Comience de manera simple, tan simple como se atreva a hacerlo, y permita innovaciones como lo sugiere el equipo de Scrum durante las retrospectivas de sprint. Sólo una innovación a la vez; Pruébelo durante el tiempo suficiente para ver qué tan bien funciona; Déjalos caer si no son realmente necesarios.

Answer 2

No hagas nada lujoso. Usa el sentido común. No he usado códigos de colores, porque no creo que ayuden mucho, incluso hacen que sea más difícil para otras partes interesadas entender el panel de tareas. Esto conduce a una menor transparencia. De lo contrario estoy de acuerdo con Morendil.

Answer 3

Para los artículos de Backlog que utilizo post-it grande (4x4): Historias de usuario (Azul / Verde), Defectos (Rojo), Excepciones (Amarillo), Investigacional (Púrpura).

Para las tareas, usamos post-its de tamaño regular (3x3): Dev Tasks (Amarillo: Porque son las más fáciles de conseguir, y la mayoría del tablero serán Dev Tasks), QA (Verde), Diseño (Azul), Errores (Rosa), ScrumMaster / Impediments (Naranja).

Comenzamos el sprint con post-its pálido / pastel, y todo lo que se agrega después de la planificación del sprint se realiza en neón del mismo color. Tan amarillo pálido vs. amarillo neón, y así sucesivamente. De esa manera podemos ver lo que se ha agregado para resaltar realmente si no hicimos una buena avería o si había toneladas de incógnitas al inicio del sprint.

Espero que esto ayude.

Answer 4

He visto el espectro cuando se trata de colores de tarjeta y desgloses. Algunos equipos usan una tarjeta de color porque una tarea es una tarea es una tarea independientemente del trabajo involucrado. Otros equipos tienen colores para cada tipo de tarea, lo cual me gustó porque me dio una buena vista del tipo de trabajo que quedaba sin tener que leer cada tarjeta.

Cartas de cuentos: azul Deuda técnica: verde Errores: amarillo Análisis: rojo Control de calidad (no control de calidad de la historia, pero tareas que control de calidad hizo fuera del control de calidad normal): blanco

Esto nos ayudó cuando teníamos un gran equipo con varios no desarrolladores sentados alrededor de la mesa.

Answer 5

Estoy de acuerdo con que más colores uses, más ciego estés . Prefiero resaltar defectos, historias y epopeyas. En el backlog de sprint solo hay dos colores: naranja para defectos y amarillo para historias. ScrumDesk , por ejemplo, permite asignar color a una tarjeta en la plantilla de la historia, lo que es útil para mantener el trabajo de reserva correctamente.

Los colores son muy utilizables si el backlog describe más productos (backlog del programa). En este caso los colores pueden resaltar epopeyas según el producto.

Answer 6

Parece sobrecargado a mi gusto. Cuando aprendí Scrum hace varios años, los únicos códigos de color eran el blanco y el rojo. Las historias rojas eran historias de integración. Si obtiene demasiados de esos en la cartera de productos cerca uno del otro, está en problemas. De todos modos, dejé de usar el tablero de baja tecnología en un primer sprint, porque tenía miembros remotos del equipo, así que usamos algún formato electrónico: Excel, TWiki, VersionOne, Rally.