Scrum-board / Task Board et code de couleur [fermé]

Question

Que recommanderiez-vous en ce qui concerne un bon code couleur pour une utilisation sur un scénarimage?

S'agit-il d'un bon modèle d'après votre expérience?
http://maxheapsize.com/static/ScrumBoardCheatSheet.pdf
Quel est le code couleur le plus standard?

Answer 1

Je suggère le blanc pour les éléments de backlog normaux, c'est-à-dire ceux qui ont une valeur commerciale, et le rouge pour les corrections de bugs. Cela fait ressortir les erreurs et aide l’équipe à s’améliorer.

Commencez simplement - aussi simple que vous le voulez - et permettez les innovations suggérées par l’équipe Scrum lors des rétrospectives de sprint. Une seule innovation à la fois; essayez-le assez longtemps pour voir à quel point cela fonctionne vraiment; déposez-les s'ils ne sont pas vraiment nécessaires.

Answer 2

Ne faites rien de fantaisie. Utiliser le bon sens. Je n'ai pas utilisé de codes de couleur, car je ne pense pas qu'ils aident beaucoup - ils rendent même plus difficile la compréhension du tableau de bord par les autres parties prenantes. Cela conduit à moins de transparence. Sinon, je suis d'accord avec Morendil.

Answer 3

Pour les articles en retard, j'utilise des post-its volumineux (4x4): User Stories (bleu / vert), défauts (rouge), exceptions (jaune), expérimentaux (violet).

Pour les tâches que nous utilisons, nous utilisons des post-its de taille normale (3x3): Tâches de développement (Jaune: elles sont les plus faciles à trouver et la plupart du tableau sont des tâches de développement), QA (vert), Conception (bleu), Bugs (Rose), ScrumMaster / Impediments (Orange).

Nous commençons le sprint avec des post-its pâles / pastels, et tout ce qui est ajouté par le passé est planifié au néon de la même couleur. Donc jaune pâle vs jaune fluo, et ainsi de suite. De cette façon, nous pouvons voir ce qui a été ajouté pour vraiment souligner si nous n’avons pas fait une bonne ventilation ou si des tonnes d’inconnues ont démarré le sprint.

J'espère que cela vous aidera.

Answer 4

J'ai vu le spectre des couleurs et des pannes de cartes. Certaines équipes utilisent une couleur de carte car une tâche est une tâche quel que soit le travail impliqué. D'autres équipes ont des couleurs pour chaque type de tâche, ce qui m'a un peu plu car cela donnait une bonne vue du type de travail restant sans avoir à lire chaque carte.

Cartes d'histoire: bleu Dette technique: verte Bugs: jaune Analyse: rouge QA (pas de QA histoire, mais des tâches que le QA a effectuées en dehors du QA normal): blanc

Cela a aidé lorsqu'une grande équipe composée d'un certain nombre de non-développeurs était assise autour de la table.

Answer 5

Je suis d'accord pour dire que plus vous utilisez de couleurs, plus vous êtes aveugle . Je préfère mettre en valeur les défauts, les histoires et les épopées. Dans le carnet de commandes de sprint, il n'y a que deux couleurs: orange pour les défauts et jaune pour les histoires. ScrumDesk permet par exemple d'attribuer une couleur à une carte dans un modèle de scénario, ce qui est utile pour conserver le carnet de commandes en couleur correctement.

Les couleurs sont très utilisables si le backlog décrit plus de produits (backlog du programme). Dans ce cas, les couleurs peuvent mettre en valeur les épopées selon le produit.

Answer 6

Il semble surchargé à mon goût. Lorsque j'ai appris Scrum il y a plusieurs années, les seuls codes de couleur étaient le blanc et le rouge. Les histoires rouges étaient des histoires d'intégration. Si vous avez trop de personnes dans le carnet de produit proches les unes des autres, vous avez des problèmes. En tout cas, j’ai abandonné l’utilisation du tableau low-tech dès le premier sprint, car j’avais des membres distants de l’équipe. Nous avons donc utilisé un format électronique: Excel, TWiki, VersionOne, Rally.