Was würden Sie für eine gute Farbcodierung für ein Storyboard empfehlen?Scrum-Board/Task-Board und Farbcodierung
Ist das ein gutes Muster aus Ihrer Erfahrung?
http://maxheapsize.com/static/ScrumBoardCheatSheet.pdf
Was ist die Standard-Farbcodierung?
Ich empfehle weiß für normale Backlog-Elemente, d. H. Diejenigen mit Geschäftswert und rot für Bugfixes. Dies macht Fehler deutlich und hilft dem Team, sich zu verbessern.
Beginnen Sie einfach - so einfach wie Sie es wagen - und erlauben Sie Innovationen, wie sie vom Scrum-Team während Sprint-Retrospektiven vorgeschlagen wurden. Nur eine Innovation zu einer Zeit; versuche es lange genug, um zu sehen, wie gut es wirklich funktioniert; Lass sie fallen, wenn sie nicht wirklich notwendig sind.
Es sieht nach meinem Geschmack überladen. Als ich Scrum vor einigen Jahren lernte, waren die einzigen Farbcodes weiß und rot. Die roten Geschichten waren Integrationsgeschichten. Wenn Sie zu viele von denen im Produktstau dicht beieinander haben - Sie sind in Schwierigkeiten. Jedenfalls gab ich im ersten Sprint mit Low-Tech-Board auf, weil ich Remote-Teammitglieder hatte, also benutzten wir ein elektronisches Format - Excel, TWiki, VersionOne, Rally.
Machen Sie nichts Besonderes. Nutze den gesunden Menschenverstand. Ich habe keine Farbcodes verwendet, weil ich denke, dass sie nicht viel helfen - sie machen es sogar anderen Beteiligten schwerer, das Taskboard zu verstehen. Dies führt zu weniger Transparenz. Ansonsten stimme ich Morendil zu.
Ich habe das Spektrum gesehen, wenn es um Kartenfarben und Pannen geht. Einige Teams verwenden eine Kartenfarbe, da eine Aufgabe eine Aufgabe ist, unabhängig von der Arbeit. Andere Teams haben Farben für jede Art von Aufgabe, die ich irgendwie mochte, da sie einen schönen Blick auf die Art der Arbeit gab, die man ohne jede Karte lesen konnte.
Geschichte Karten: blau Technische Schulden: grün Bugs: gelb Analyse: rot QA (nicht Geschichte QA, sondern Aufgaben, die QA außerhalb der normalen QA tat): weiß
Dies trug dazu bei, wenn wir eine hatten großes Team mit einer Anzahl von Nicht-Entwicklern, die am Tisch sitzen.
Ich stimme dem mehr Farben zu, die Sie verwenden, desto mehr Sie sind blind. Ich ziehe es vor, Mängel, Geschichten und Epen zu markieren. Im Sprint Backlog gibt es nur zwei Farben - Orange für Defekte und Gelb für Stories. ScrumDesk zum Beispiel erlaubt es, einer Karte in der Story-Vorlage Farbe zuzuweisen, was hilfreich ist, um den Backlog korrekt zu färben.
Die Farben sind sehr brauchbar, wenn Backlog mehr Produkte beschreibt (Programm Backlog). In diesem Fall könnten Farben Epen entsprechend Produkt hervorheben.
Für Backlog Items verwende ich große Post-its (4x4): User Stories (Blau/Grün), Defekte (Rot), Ausnahmen (Gelb), Investigational (Lila).
Für Aufgaben verwenden wir normale Post-its (3x3): Dev-Aufgaben (Gelb: Weil sie am einfachsten zu kommen sind, und die meisten der Brett wird Dev-Aufgaben sein), QA (grün), Design (blau) , Bugs (Pink), ScrumMaster/Impediments (Orange).
Wir starten den Sprint mit blassen/pastellfarbenen Post-its, und alles, was nach der Sprint-Planung hinzugefügt wird, wird auf Neon der gleichen Farbe ausgeführt. So blasses Gelb gegen Neongelb und so weiter. Auf diese Weise können wir sehen, was hinzugefügt wurde, um wirklich hervorzuheben, ob wir nicht einen guten Zusammenbruch hatten oder ob es Unmengen von Unbekannten gab, die den Sprint begannen.
Hoffe, das hilft.
Diese Frage ist off-topic, weil sie nicht in den Bereich der Fragen für diese Website passt, wie in [Welche Themen kann ich hier fragen?] (// stackoverflow.com/help/on-topic) Bitte Siehe auch: [Welche Art von Fragen sollte ich vermeiden?] (// stackoverflow.com/help/dont-ask) Sie können möglicherweise Hilfe zu [einer anderen Stack Exchange-Site] erhalten (// stackexchange.com/sites# Name). – Makyen