Kanban / Scrum Boards [geschlossen]

StackOverflow https://stackoverflow.com/questions/1807100

Frage

Ich bin neugierig, was andere Leute benutzen für physische Kanban / Scrum-Boards in ihren Unternehmen. Ich schätze, dass wegen sensibler Geschäftsinformationen Sie nicht in der Lage sein kann, ein Foto der Platte zu liefern. I "m auf der Suche, um herauszufinden, Wie sieht Ihr Board sieht aus wie und , wie Sie User Storys und Aufgaben organisieren, wie sie durch eine typische Sprint / Iteration bewegen?

typischerweise in einem Ort, die ich gearbeitet habe, dass das Board organisieren, wie mit jedem folgt 

User Story   | Todo                   | In Progress  | Ready for QA     | Done   |
UC-001       | Domain Object, Service | DAO(Bob)     |                  |        |
UC-002       | Payment UI Screen      |              | Payment Srv (Don)|        |
UC-003       |                        |              | UC-003           |        |
             |                        |              |                  | UC-004 |
             |                        |              |                  | UC-005 |

Um es zusammenzufassen:

  • Eine Aufgabe für UC-001 ist im Gang durch ein Mitglied des Teams (Bob). Eine Liste der Aufgaben für andere Menschen in der Todo Spalte holen warten, aber das von einem anderen Mitglied des Teams aufgenommen, die mit Bob koordinieren kann die Arbeit zu erledigen.
  • Für UC-002 den Zahlungsdienst Aufgabe wurde abgeschlossen und ein automatisiertes Testgeschirr wurde für QA abgeschlossen so dass sie ohne eine Benutzeroberfläche, den Dienst zu testen. Wenn der Test ein Fehler nicht angehoben und bewegte mit der Payment Service Aufgabe zurück in die QA-Phase entlang
  • Alle Aufgaben für UC-003 wurden für QA Bereit abgeschlossen und bewegt werden.
  • Alle Aufgaben für Uc-004 und UC-005 abgeschlossen waren, so wurde die User Story Erledigt bewegt.

Das funktioniert als greifbare weiße Tafel, die Menschen der Interaktion mit jedem der Aufgaben / User Stories (dargestellt als Post-Itanmerkungen) beinhaltet. Eine elektronische Version wird vor dem Sprint / Iteration erstellt und wird erst am Ende der Sprint / Iteration aktualisiert, um die aktuelle Situation entspricht. Kommentare und Kritik sind willkommen:)

War es hilfreich?

Lösung

Wir verwenden etwas von der berühmten Scrum und XP von dem Trenches < a /> von Henrik Kniberg, wobei die Säulen in Abhängigkeit von dem Kontext angepasst (oft: TODO, auf dem Gehen, getestet werden, DONE):

alt text http://blog.realcoderscoding.com/ wp-content / uploads / 2008/09 / hk.png

Product Backlog Artikel (PBI) werden als "physische Karten" (A5-Format) für den Sprint Planning Meeting gedruckt (zumindest die wichtigsten). Nachdem das Team PBIs für die nächste Iteration ausgewählt hat, sind Elemente in Aufgaben / Aktivitäten abbauen (auf Haftnotizen). Nach dem Treffen geht alles auf dem Scrum Vorstand und ich schlage vor, Band oder Reißzwecke oder Magneten zu verwenden. PBIs werden von Wichtigkeit geordnet, was am wichtigsten an der Spitze des Vorstandes, weniger wichtig an der Unterseite. Das Team sollte zunächst auf dem wichtigsten Punkt arbeiten, bis es erledigt wird. Erstens Aktivität nach dem Umzug von links nach rechts. Dann springt die PBI zu Erledigt. Unerwartete Aufgaben werden an eine „ungeplanten Artikel“ Zone hinzugefügt (sie berücksichtigt in der Burndown Chart zu nehmen). Zukunft PBIs bleibt sichtbar in einer „Next“ Zone (wenn alle Elemente während der Iteration abgeschlossen sind, wählen wir einen neuen von dort). Ganz einfach.

Diese Praktiken erlauben Gerüche visuell zu erkennen, zum Beispiel:

  • stucked Aufgaben (das heißt Aufgaben, die nicht bewegt werden), die ein potenzielles Hindernis zeigen
  • Team Dinge in der falschen Reihenfolge zu tun und nicht auf dem oberste Priorität Elemente konzentrieren, wie auf der Probe:)
  • zu viel Arbeit im Gange ist, nichts getan
  • ungeplante Elemente, die einen Sprint
    • töten

Arbeiten groß.

Wenn Sie mehr "KANBAN-orientierte" Sachen suchen, haben vielleicht einen Blick auf Kanban vs Scrum , Eines Tages im Kanban Land und Kanban und Scrum - ein praktischer Leitfaden von der gleicher Henrik Kniberg. Great stuff zu.

Und für weitere Bilder, gibt Google Bildern einen Versuch mit gedränge + Board kanban , scrumban , gedränge + kanban .

Andere Tipps

Hier ist unser Kanbantafel, die wir verwenden unter Target . Wir arbeiten nicht auf Aufgaben Ebene, nur auf User Stories und Bugs Ebene. Manchmal schaffen wir Aufgaben, aber sie sind nicht explizit auf der Platine verfolgt.

Wir schätzen nicht User Stories und Bugs, sondern versuchen, Geschichten in kleineren aufteilen (mit unterschiedlichem Erfolg). Spalten sind selbsterklärend. Wir akkumulieren Elemente in Getestet Spalte, erstellen Sie einen Zweig, Rauch testen und neue Build veröffentlichen. Normalerweise geben wir neue Build alle zwei Wochen.

Auch das Board zeigt Entwickler und Tester Last und Klassen von Diensten über eine Farbcodierung.

Target Kanban Board

UPD. Jetzt haben wir mehrere kleine Teams und eine Einplatinen verwenden Fortschritt der gesamten Teams zu verfolgen in http: //www.targetprocess. com / 3

eingeben Bild Beschreibung hier

alt text

Scrum / Extreme Programming Storyboard.

http://www.flickr.com/photos/dafydd_ll_rees/4138686549/

Arbeit erscheint auf dem zweiten von links colum, und schreitet auf der ganzen Linie durch verschiedene Stadien der Vollständigkeit.

Spaltennamen: Nicht gestartet, gerade begonnen, auf halbem Weg, fast fertig, bereit für Showcase (bestanden QA)

Die erste Reihe speziell für Bugfixing reserviert ist -. Wie eine feste, Priorität für das Clearing von Bugs

Die Simpsons Zeichen repräsentieren jedes Mitglied des Teams. Sie sind bewegt um so können wir sehen, wer arbeitet an was.

Ich schlage vor, Sie auf Eylean Board einen Blick zu nehmen. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort es können alle Ihre Bedürfnisse wegen intuitive Benutzeroberfläche, Statistiken, Armaturenbrett passen. Auch paßt es jeden Prozess und das Wichtigste ist es sehr einfach zu bedienen. Dieses Board ermöglicht es Ihnen, mehrere Projekte auf einem Board mit Reihen darzustellen. Alle Zeilen können zu einer Zeit sichtbar sein oder können Sie ausgewählte aus der scope.Another Lösung entfernen Aufgabe Gruppierung und Filterung von Kategorien sein -. Dann werden alle Aufgaben auf einer Platine und Zeile dargestellt werden, aber auf verschiedenen Kategorien angebracht

die Organisation der Arbeit in progress Board In der Praxis wird für das Team am besten links, je nach Ihren persönlichen Umständen und Umgebung zu bestimmen. (Agile == Selbstmanagement.)

Das heißt, hier ist das, was wir haben in meinem früheren Team, Teil eines 300+ Entwickler Anstrengungen, die relativ neu auf Agile und Scum war:

Wir hatten zwei Boards - eine mit Karteikarten für die bevorstehenden Geschichten so könnten wir sagen, was oben kommen würde, und eine mit der Arbeit des aktuellen Sprint. Unsere Spalten auf dem aktuellen Sprint Bord waren einfach 

Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")

und eine Kiste in der Ecke für Blocked.

Ein Post-it Note repräsentiert jede Geschichte.

Entwickler hatten jeweils einen kleinen Magneten, die sie an dem Standup jeden Morgen verwendet, um anzuzeigen, wer auf was funktioniert. Unser Team war ziemlich groß (~ 12 an einem Punkt), so das hat mir sehr geholfen, herauszufinden, wer mit wem gepaart wurde.

Wir haben nicht mit einer elektronischen Version (kein Punkt) stören, obwohl unser Product Owner hatte ein ScrumWorks System, das er auf dem Laufenden zu halten, benötigt. Wir hielten so weit weg von dem, wie wir konnten!

Ich bin ziemlich scharf auf Mager / Kanban und wir haben für eine Weile, zunächst durch einen maßgeschneiderten Workflow in JIRA auf unserem Prozess wurden laufen, aber das ist nicht genau das reibungs der Admin Komplexität in der Enterprise-Version gegeben. Wir haben jetzt unsere Verwendung eines Whiteboard erweitert und haben beschlossen, unseren Prozess mit dem Whiteboard für eine Weile, bevor erneut kodifiziert es in JIRA iterieren. Hier ist ein Beispiel für unser Layout:

  • Wir sind 6 Entwickler
  • Wenn eine Geschichte in dev ist, dann ist es auf einem Schreibtisch des dev. Ebenso mit überprüft werden, wobei QA'd usw. Das bedeutet, jede Karte auf dem Board steht und umsetzbare Element und stellt auch eine anständig genaue Momentaufnahme des Iteration Fortschritts. Die Regel ist, dass nur in Ausnahmefällen tun Sie mehr als eine Karte auf Ihrem Schreibtisch haben.
  • Wir haben vereinbart, nicht mehr als zwei Karten „pile-up“ in der Überprüfung ausstehend Spalt. Dadurch bleibt ein gewisses Maß an "Flow". 

Backlog   | Awaiting Dev   | Awaiting Review   | Awaiting Design  | Awaiting Deployment | Awaiting QA | Done |
Story11   |    Story2      |    Story9         |     Story 6      |   Story1            |    Story9   |
Story3    |    Story7      |                   |                  |                     |    Story12  |
Story8    |    Story10     |                   |                  |                     |             |
          |                |                   |                  |                     |             |
          |                |                   |                  |                     |             |

Das ist ziemlich nah an Abbilden des Wertstroms mit Ausnahme der Bereitstellung Teil erwartet, die ist ein Hack, das Problem in das QA kann kein Element QA bis wir bereitgestellt haben es auf ihrem Server zu beheben -. wir 3/4 mal während einer 2-wöchigen Iteration bereitstellen

Eine Sache, ich habe von Abbildung des Wertstroms bemerkt auf einem „ Informationen Heizkörper “ist, dass es auf magische Weise die Menschen nicht konzentrieren sich auf die tatsächlichen Mehrwert-Arbeit, die getan werden muss, und das scheint das Tempo der Geschäftswertentwicklung und Schwung halten.

Ich hoffe, das hilft!

Wir sind mit ein paar verschiedenen Pappstrukturen über ein paar verschiedene Projekte experimentieren, die wir laufen. Ein Projekt hat die grundlegendste Struktur, die wir verwenden können: 

| (Sprint) Backlog | In Progress | Done |

So viel wie möglich, versuchen wir, eine einzelne Post-it müssen repräsentieren sowohl die Dev und QS-Aktivitäten für eine Geschichte.

Die obige Struktur schien für die Entwickler an dem Projekt ok zu arbeiten, aber die QA-Mitglieder zu kämpfen haben zu wissen, wann eine Geschichte die Entwicklungsarbeit hatte so vollständig, dass sie ihre Tests für diese Geschichte ausführen können. Wir fanden sie die Geschichten die „andere Seite“ bewegen von dem In Progress Abschnitt, um anzuzeigen, dass die Dev Arbeit war getan, und dass QA diese Geschichte abholen kann. Dies wurde sehr schnell sehr unhandlich wie die In Progress Abschnitt gefüllt ist.

Dies führte zu der zweiten Iteration der Plattenstruktur für ein anderes Projekt, das ist: 

| (Sprint) Backlog | In Progress | Ready for Test | Done |

Der neu hinzugefügte Abschnitt Bereit Test wurde im Wesentlichen ein formaler Abschnitt der Platte, das zuvor die „andere Seite“ des In Progress Abschnitt war. Auf der Oberfläche davon, sollte dies für die QS-Mitgliedern haben sich die Dinge klarer, aber dies verursacht noch einige Verwirrung wie Menschen unterschiedlicher Interpretationen hatte, was Ready for Test gemeint (Ich werde Sie nicht langweilen mit den verschiedene Interpretationen hier).

Das hat dann führte auf die neueste Iteration der Board-Struktur wir an einem anderen Projekt verwenden: 

| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
Dieser

ist sicherlich ein ziemlich weit Weg von den einfachen Backlog In Progress und Fertig Abschnitte der ersten Iteration, aber dies scheint seine gut für das Team arbeiten. Sie haben eine klare Vorstellung davon, was es bedeutet, eine Geschichte durch verschiedene Abschnitte der Platte zu bewegen und für jede eine Geschichte, gibt es ein klares Bild davon, wo im Lebenszyklus, die besondere Geschichte. Wir haben erst seit Beginn des aktuellen Sprints diese Struktur wurden mit (wir sind 9 Tage in einen 10-tägigen Sprint), so dass wir diese Struktur im Detail in unserer Retrospektive morgen zu entdecken. Nicht perfekt Ich bin sicher, aber wenn es weiterhin für das Team arbeiten, die es testet, werden wir versuchen, es zu rollen über andere Teams in unserer Organisation.

Unser Whiteboard gliedert sich in diesen Spalten:

Story, nicht gestartet, Anf / Das / Dev *, Peer Review, QA, Fertig

Die höchste Priorität Geschichten gehen von oben nach unten. Jede Geschichte kann mehrere Aufgaben haben, so dass wir einen großen Post-It für die Geschichte und kleinere für die Aufgaben verwenden. Aufgaben bewegen sich von links nach rechts. Jeden Tag stellen wir sicher, überprüfen wir die höchste Priorität Geschichten arbeiten.

Wir verwenden einen klebrigen weißen Reiter auf jeder Aufgabe, wo die Person daran zu arbeiten, ihre Initialen setzt. Wenn sie fertig sind und es entlang einer neuen weißen Registerkarte bewegen, über die alte gelegt zu zeigen, es verfügbar ist, um jemand zu holen. Wenn alle Aufgaben erledigt sind, wird die Geschichte auch auf die Fertig-Säule bewegt und an der Standup wird alles getan, was Arbeit ausgezählt und das Brett bewegt, um Platz an der Unterseite für mehr Geschichten zu machen.

Wir haben auch für die Geschichten und Aufgaben farbige Registerkarten Blockaden, um anzuzeigen, für den Fortschritt (blau eine Blockade von einem anderen Team angibt, rot anfordernden Scrum Master Hilfe). Wir sprechen über die Straßensperren an jedem Stand-up.

Wir können sehen, wenn es zu viele Aufgaben in einer bestimmten Spalte und verschieben Betonung mehr zu tun zu bekommen. Wir haben bewusst die Überprüfung Spalte zu betonen, dass die Arbeit von jemand anderem als der Person überprüft brauchte es zu tun, bevor es zu QA bekam.

* Anforderungen / Design / Entwicklung

Ours sieht ziemlich ähnlich. Jeder Entwickler hat eine Spalte und wir haben Zeilen für 'Fertig', 'In Testing', 'Work in Progress', 'Backlog'.

Und wir verwenden tatsächliche Post-it-Stil stellt fest, dass wir körperlich bewegen, wie es durch jede Phase geht.

Persönlich finde ich das System zu fehlen ...

  • Die manuelle Verschieben Post-its bekommt ein Schmerz nach einer Weile zu sein. Unser QS-Team verwaltet meist das Ticket moving -. Und es ist ein ständiges Bemühen sie mit TFS synched zu halten
  • Die Post-its kann eigentlich nur so viele Male bewegt werden, bevor sie nicht mehr klebrig sind. Wenn ein Ticket von der Prüfung gesendet Rück und platziert in ‚In Bearbeitung‘ und dann zog zurück nach Tests, etc, etc ... es braucht nicht viel für sie auf dem Boden zu landen.
  • Manchmal ist die schiere Menge der Noten überwältigend. Hinweise werden müssen gestapelt auch nur entfernt sichtbar zu sein - wir schichten diese so, dass wir jede Notizen eindeutige Kennung sehen (so gut wie wir können) ... aber dann haben Sie einen Stapel von 10 Noten bekommen und Sie brauchen, um die 5. aus dem Stapel und Sie tragen schnell auf die Abnahme der Klebrigkeit, die mit den Noten auf dem Boden enden werden.
  • Wenn die Karten auf dem Boden, um herauszufinden, es ist am Ende noch ziemlich ärgerlich, wo sie gehen sollten. War das Entwickler A das Ticket? Oder B? Und war es in Testing? Oder war es getan? Kommen wir zurück in TFS gehen, sehen die Tickets und dann die Post-its entsprechend bewegen.

Ich persönlich glaube nicht, Post-it-Notizen hier das geeignete Instrument sind. Es gibt eine Handvoll von digitalen Werkzeugen, die diese Art der Sache völlig störungsfrei zu machen. Wir verwenden Team Foundation Server - und ich habe ein paar wirklich groß, robust, frei, und auch Open-Source-Tools gesehen, die mit dem Team Foundation Server-Schnittstelle werden und all das für Sie in Echtzeit verwalten

.

http: / /www.telerik.com/community/labs/tfs-work-item-manager-and-tfs-project-dashboard.aspx

Unsere Platten sind in der Regel Überstunden entwickeln, wie wir als Team Fortschritte. Ich neige dazu, physische Karte Boards zu bevorzugen, wenn Sie einen gemeinsam genützten haben ein Team, wie es besser Gesicht fördert die Kommunikation im Allgemeinen aus meiner Erfahrung zu stellen. Offensichtlich gibt es mehr Aufwand, aber es lohnt sich das Team zusammen arbeiten zu erhalten. Ein weiterer Vorteil, den ich mit physischen Boards gesehen haben ist, dass es mit der Wirtschaft Engagement hilft. Remote-Akteure können nicht einfach anmelden und sehen Fortschritte im aktuellen Sprint und die Dinge nehmen Zusammenhang aus, wie manchmal Karten nicht die ganze Geschichte erzählen. Sie haben ein Gespräch haben und kommen zu dem Brett, das von Vorteil sein kann, wie die Dinge können erklärt bekommen, und es bedeutet auch, dass sie gefördert werden können, um mit Hindernissen zu lösen. Dies ist jedoch nicht ausschließlich auf physikalische Platten, aber es hilft.

Wie unsere Boards erwähnt Überstunden mit den Teams entwickeln muss. Oft wir mit Lehrbuch gedränge beginnen, aber eine kontinuierliche Verbesserung fördern und in der Regel mit einer scrumban Lösung enden. Diese Veränderungen spiegeln sich durch die neue Workflow durch die Bretter zu visualisieren. Ich schrieb vor kurzem einen Beitrag auf unserer letzten Änderung, wenn Ihr daran interessiert, einen Blick auf unsere Sanduhr gedränge / Kanbantafel

ich glaube, das Team sollte bei der Herstellung der Bretter engagieren, wie es das Team des Workflow verstehen hilft und nicht den Silos wird. Auch wenn das Team hat eine Hand bei der Herstellung der Platte hat sie ihre eigenen Prozesse besser Polizei, die mit Selbstorganisation hilft, da es ein Produkt ist sie gehabt hat eingegeben.

Wir gingen mit folgenden Board-Struktur in unserem Unternehmen. 

Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working

Die Spuren sind an bestimmte Mitglieder zugeordnet. Jedes Mitglied hat verschiedenen Job in unserem Büro, so dass die Aufgaben variieren. Wir fügen, was wir unseren Backlog arbeiten müssen, dann ist es in nächsten Sprint nur dann, wenn sie die Frist zu erreichen. Blockierte grüne Aufgaben sind für den Daueraufgaben eingesetzt, die täglich bearbeitet werden müssen. Rote Karten zeigen Wichtigkeit der Aufgabe und müssen so schnell wie möglich abgeschlossen werden. Unser Board ermöglicht es uns, frei zusammenarbeiten, und fügen Sie Aufgaben zu jedem anderen Swimlanes wenn wir etwas brauchen, von anderen Abteilung durchgeführt werden.

Wir verwenden KanbanTool (Kanbantool.com) unseren Workflow zu visualisieren und Projekte zu verwalten. Es ist wirklich intuitiv und einfach zu bedienen. Unsere Kommunikation im Team hat sich enorm verbessert.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top