Kanban - /Scrum-Boards

Ich bin neugierig, was andere Leute verwenden, die für physische Kanban - /Scrum-boards in Ihrem Unternehmen. Ich Schätze, dass wegen der empfindlichen geschäftlichen Informationen, die Sie möglicherweise nicht in der Lage, ein Foto von der platine. I"m Blick auf um herauszufinden,was deine platine aussieht wieund wie organisieren Sie user stories und Aufgabenwie Sie bewegen sich durch eine typische sprint/iteration?

In der Regel arbeitete ich in einem Orte, organisieren der Vorstand wie folgt mit jedem

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 |

So zusammenfassen:

Eine Aufgabe für UC-001 ist im Gange, die von einem Mitglied des Teams (Bob). Eine Liste von Aufgaben für andere Menschen zu Holen, warten in der Todo-Spalte, aber dies kann abgeholt werden, von einem anderen Mitglied des Teams, der co-ordinate mit Bob um die Arbeit zu erledigen.
Für UC-002 der payment-service-Aufgabe abgeschlossen wurde und eine automatisierte Testumgebung abgeschlossen war, QS-erlaubt Ihnen, den Dienst zu testen ohne UI. Wenn der test fehlschlägt, wird ein Fehler ausgelöst, und zog zusammen mit dem Payment-Service-Aufgabe zurück in die QA-phase
Alle Aufgaben, die für UC-003 wurde abgeschlossen und zog Sie sich Bereit für die QS.
Alle Aufgaben, die für Uc-004 und UC-005 wurden abgeschlossen, damit die user story verschoben wurde, Fertig.

Diese funktioniert wie eine greifbare weiße Tafel, die beinhaltet Menschen, die Interaktion mit jedem der die tasks/user stories (dargestellt als post-it-Zetteln). Eine elektronische version erstellt wird, bevor der sprint/iteration und wird nur aktualisiert, am Ende des Sprints/der iteration entsprechend der aktuellen situation. Kommentare und Kritik sind willkommen : )

InformationsquelleAutor der Frage Jon | 2009-11-27

15

Verwenden wir etwas inspiriert durch den berühmten Scrum and XP from the Trenches von Henrik Kniberg, der Spalten angepasst, je nach Kontext (oft: TODO, AUF, um GEPRÜFT ZU WERDEN, GETAN):

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

Product Backlog Items (PBIs) gedruckt, als "physische Karten" (A5-format) für das Sprint Planning Meeting (zumindest die wichtigsten). Nachdem das team hat abgeholt PBIs für die nächste iteration werden die Elemente Gliedern sich in Aufgaben/Tätigkeiten (sticky notes). Nach dem treffen, das geht alles auf dem Scrum-Board und ich schlage vor, verwenden Sie Klebeband oder Heftzwecken oder Magnete. PBIs sind bestellt von Bedeutung, am wichtigsten an der Oberseite des Vorstands, die weniger wichtigen unten. Das team sollte auf die wichtigsten Artikel zuerst, bis es getan wird. Erste, Aktivität post-its zu bewegen, von Links nach rechts. Dann die PBI-Sprünge Gemacht. Unerwartete Aufgaben Hinzugefügt werden, um eine "Ungeplante Elemente" - zone (Sie berücksichtigt in der burndown-chart). Zukunft PBIs bleiben sichtbar in einem "Weiter" - zone (wenn alle Positionen abgeschlossen werden, während der iteration, suchen wir uns ein neues von dort). Ziemlich einfach.

Diese Praktiken erlauben zu erkennen, Gerüche visuell, zum Beispiel:
- stucked Aufgaben (D. H. Aufgaben, die sich nicht bewegen) zeigen, dass eine mögliche Behinderung
- team, die Dinge in der falschen Reihenfolge und nicht die Fokussierung auf top-priority-Sendungen, wie auf deinem Beispiel 🙂
- zu viel in Arbeit, nichts getan
- ungeplante Elemente, die töten eine sprint
Funktioniert Super.

Wenn Sie sind auf der Suche nach mehr "kanban-orientierten" Zeug, vielleicht einen Blick auf Kanban vs Scrum Ein Tag in Kanban-Land und Kanban-und Scrum - ein praktischer Leitfaden aus der gleichen Henrik Kniberg. Tolle Sachen auch.

Und, für mehr Bilder Google Bilder einen Versuch mit scrum+board kanban scrumban scrum+kanban.

InformationsquelleAutor der Antwort Pascal Thivent
8

Hier ist unser Kanban-Board, wir verwenden bei TargetProcess. Wir arbeiten nicht auf der Aufgaben-Ebene, nur auf User Stories und Bugs Ebene. Manchmal schaffen wir Aufgaben, aber Sie werden nicht verfolgt explizit auf dem board.

Wir nicht schätzen, User Stories und Bugs, aber versuchen, teilen Geschichten in kleinere (mit gemischtem Erfolg). Spalten sind selbsterklärend. Wir sammeln Gegenstände in Getestet Spalte, dann erstellen Sie einen Zweig , Rauch zu testen und neue zu bauen. In der Regel veröffentlichen wir neue bauen alle zwei Wochen.

Auch das board zeigt, Entwickler und Tester Last und Klassen der Dienste über eine Farbcodierung.

UPD. Jetzt haben wir mehrere kleine teams und die Verwendung einer einzigen Karte, um die Fortschritte aller teams in http://www.targetprocess.com/3

InformationsquelleAutor der Antwort Michael Dubakov
6

Scrum /Extreme programming storyboard.

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

Arbeit wird auf der zweiten von Links colum, und schreitet über das board durch die verschiedenen Stadien der Vollständigkeit.

Spalte-Namen: Nicht Gestartet wurde, Gerade Gestartet, auf halbem Weg, Fast Fertig, Fertig für die Vitrine (weitergeleitet von QA -)

Die erste Zeile ist speziell reserviert für Fehler beheben - wie eine Feste, Priorität für das clearing von bugs.

Den Simpsons-Charaktere darstellen, die jedem Mitglied des Teams. Sie sind bewegt, damit wir sehen können, wer gerade auf was.

InformationsquelleAutor der Antwort daf
4

Ich schlage vor, Sie nehmen einen Blick auf Eylean board. http://www.eylean.com/?utm_source=geffort&utm_medium=content&utm_campaign=geffort
es passen alle Ihre Bedürfnisse, weil der intuitive Schnittstelle, Statistik-dashboard. Auch er passt in jeden Prozess und das wichtigste es ist sehr einfach zu bedienen. Dieses board ermöglicht es Ihnen, vertreten mehrere Projekte auf einem Brett mit Reihen. Alle Zeilen sichtbar in einer Zeit, oder entfernen Sie ausgewählte Bücher aus dem Bereich.Eine andere Lösung kann sein, die Aufgabe, Gruppierung und Filterung nach Kategorien - dann werden alle Aufgaben dargestellt werden kann, auf einem board, und die Zeile, aber an verschiedenen Kategorien.

InformationsquelleAutor der Antwort userG
2

In der Praxis die organisation des work-in-progress board ist am besten Links für das team um zu bestimmen, je nach Ihren Umständen und der Umwelt. (Agil == Selbstverwaltung.)

Dieser sagte, hier ist was wir getan haben, in meinem vorherigen team, Teil eines 300+ Entwickler Mühe, die relativ neu, Agil und Abschaum:

Hatten wir zwei boards, eins mit index-Karten für die kommenden Geschichten, so könnten wir sagen, was auf mich zukommt, und eine mit den aktuellen sprint gearbeitet. Die Spalten auf den aktuellen sprint Bord waren einfach
```
Not Started
Under Development
Dev Done 
In QA
Complete ("Done Done")
```
und eine box in der Ecke für Blocked.

Einen post-it-Zettel dargestellt, jede Geschichte.

Entwickler jeder hatte einen kleinen Magneten, die Sie verwendet, auf der Stand-up-Paddle jeden morgen, um zu bestätigen, die mit der Arbeit war auf, was. Unser team war Recht groß (~ 12 an einem Punkt), so das wirklich geholfen, herauszufinden, wer das war, gepaart mit wem.

Wir nicht die Mühe mit einer elektronischen version (ohne Punkt), obwohl unsere Product Owner haben ein Scrumworks system, das er benötigt, um zu halten up-to-date. Wir hielten uns so weit entfernt, wie wir nur konnten!

InformationsquelleAutor der Antwort Jeremy McGee
2

Ich bin ziemlich scharf auf der Lean/Kanban und wir überarbeiten unser Prozess für eine Weile, zunächst über einen individuell angepassten workflow in JIRA, aber das ist nicht genau das, glatten angesichts der admin Komplexität in der enterprise-version. Wir haben jetzt erweitert die Nutzung von Whiteboards und sich entschieden haben, Durchlaufen unsere Prozess mit dem whiteboard für eine Weile, bevor re-codieren in JIRA. Hier ist ein Beispiel unseres Layouts:
- Wir sind 6 Entwickler
- Wenn sich eine Geschichte in dev, es ist in einem dev ' s Schreibtisch. Ebenfalls mit geprüft, QS würde, etc. Dies bedeutet, dass jede Karte auf dem board steht und umsetzbare Sache, und bietet auch ein ziemlich exaktes Bild der iteration die Fortschritte. Die Regel ist, dass nur in außergewöhnlichen Umständen haben Sie mehr als eine Karte auf Ihren Schreibtisch.
- Wir haben vereinbart, nicht mehr als zwei Karten "pile-up" in der Erwartung Abgeben Spalte. Diese sorgt für einen gewissen "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 der value stream mapping außer für das warten auf die Bereitstellung Teil, das ist ein hack, um das problem zu beheben, wo QA-Team kann keine QA-ein Element, bis wir bereitgestellt haben es auf Ihre server - wir bereitstellen 3/4 mal während einer 2-Wochen-iteration.

Eine Sache, die ich bemerkt haben, die Zuweisung der value-stream auf ein "information radiator" ist, dass es nicht magisch konzentrieren sich die Menschen auf den tatsächlichen Mehrwert der Arbeit, die getan werden muss, und das scheint, das Tempo der business-Wert-Entwicklung und halten Sie in Schwung.

Hoffe, das hilft!

InformationsquelleAutor der Antwort Mark Gibaud
2

Wir Experimentieren mit ein paar unterschiedlichen board-Strukturen über ein paar verschiedene Projekte, die wir ausführen. Ein Projekt hat die grundlegende Struktur, die wir verwenden können:
```
| (Sprint) Backlog | In Progress | Done |
```
So viel wie möglich, werden wir versuchen, eine single post-it zu vertreten sowohl der Dev-und QA-Aktivitäten für eine Geschichte.

Den oben beschriebenen Struktur hat, schien zu funktionieren ok für die Entwickler auf das Projekt, aber der QS-Mitglieder haben gekämpft, um zu wissen, Wann eine Geschichte hatte, die Arbeit bei der Entwicklung abgeschlossen, so dass Sie ausführen können Ihre tests für die Geschichte. Wir fanden uns bewegen die Geschichten der "anderen Seite" der In Progress Abschnitt an, dass die Dev Arbeit getan war und dass QA abholen konnte, die Geschichte. Dies wurde sehr schnell zu Recht unüberschaubar wie die In Progress Abschnitt gefüllt.

Dies führte zu der zweiten iteration der board-Struktur für ein anderes Projekt:
```
| (Sprint) Backlog | In Progress | Ready for Test | Done |
```
Den neu hinzugefügten Abschnitt Bereit für den Test im wesentlichen zum einen formalen Abschnitt, der Vorstand, der vorher die "andere Seite" der In Progress Abschnitt. Auf der Oberfläche der es, sollte dies die Dinge klarer für den QA-Mitglieder, aber dies immer noch für Verwirrung, als die Menschen haben unterschiedliche Interpretationen dessen, was Bereit für den Test gemeint (ich werde Sie nicht langweilen mit den verschiedenen Interpretationen hier).

Dies hat dann dazu geführt, dass die neueste iteration der board-Struktur verwenden wir auf ein anderes Projekt:
```
| (Sprint) Backlog | Dev in Progress | Dev Done | QA in Progress | Done |
```
Dies ist sicherlich ganz weit Weg von der einfachen RückstandIn Progress und Getan Abschnitte der ersten iteration, aber dies scheint zu funktionieren gut für das team. Sie haben ein klares Verständnis von dem, was es bedeutet, sich zu bewegen, eine Geschichte durch verschiedene Bereiche der Karte und für jeden eine Geschichte, es gibt ein klares Bild, wo Sie sich im Lebenszyklus, insbesondere Geschichte ist. Wir habe nur mit dieser Struktur seit dem start der aktuellen sprint (wir sind 9 Tage in ein 10-Tages-sprint), also werden wir die Erkundung dieser Struktur im detail in unserer Retrospektive morgen. Nicht perfekt, ich bin mir sicher, aber wenn es weiterhin Arbeit für das team, ist ein Pilotprojekt, wir werden versuchen, Sie Rollen über die anderen teams in unserer organisation.

InformationsquelleAutor der Antwort
2

Unser whiteboard ist unterteilt in diese Spalten:

Geschichte, Nicht Gestartet, Req/Des/Dev*, Peer-Review, QA, Getan

Höchste Priorität Geschichten gehen von oben nach unten.
Jede Geschichte kann mehrere Aufgaben, so verwenden wir einen großen postit für die Geschichte und die kleinere für die Aufgaben. Die Aufgaben bewegen sich von Links nach rechts. Jeden Tag prüfen wir, ob wir arbeiten, die höchste Priorität Geschichten.

Verwenden wir eine klebrige weiße Registerkarte auf jeder Aufgabe, bei der die person, die auf Sie legt Ihren Initialen. Wenn Sie fertig sind und für sich einen neuen weißen Reiter platziert wird, über die alte zu zeigen, es ist für jedermann verfügbar zu Holen. Wenn alle Aufgaben fertig sind, die Geschichte bewegt sich auf die Done-Spalte und auch im standup, alle Arbeit Getan ist ausgezählt und nach oben bewegt, wird der Vorstand um Platz auf dem Boden für weitere Geschichten.

Wir haben auch farbige tabs für die Geschichten und Aufgaben zu zeigen Blockaden an den Fortschritt (blau, der angibt, um eine Verstopfung aus einem anderen team, rot ersuchenden scrum master Unterstützung). Wir sprechen über die Straßensperren an jedem standup.

Können wir sehen, wenn es zu viele Aufgaben in einer bestimmten Spalte und verlagern den Schwerpunkt um mehr zu Getan. Wir haben uns bewusst Hinzugefügt, die review-Spalte zu betonen, dass die Arbeit, die gebraucht wird überprüft, indem eine andere Person als die person, es zu tun, bevor etwas an die QA.

*Anforderungen/Design/Entwicklung

InformationsquelleAutor der Antwort Sam
0

Uns sieht relativ ähnlich. Jeder Entwickler hat eine Spalte, und wir haben die Zeilen für 'Fertig', 'In Prüfung', 'in Arbeit', 'Rückstand'.

Nutzen wir aktuelle post-it-Stil, stellt fest, dass wir uns körperlich bewegen, wie es geht durch jede phase.

Persönlich finde ich das system zu fehlen...
- Manuelle verschieben von post-its wird zu einem Schmerz nach einer Weile. Unser QA-team meist verwaltet das ticket verschieben - und es ist ein ständiges bemühen, Sie zu halten synchronisiert mit TFS.
- Die post-its können wirklich nur verschoben werden, so viele Male, bevor Sie nicht mehr klebrig. Wenn ein ticket geschickt-zurück von den Tests und in "In Progress" und ging dann wieder zu den Tests, etc, etc...es braucht nicht viel, für die es am Ende auf den Boden.
- Manchmal die schiere Menge der Notizen ist überwältigend. Noten müssen gestapelt werden, um sogar aus der Ferne sichtbar - wir Schicht Sie, so dass wir sehen können, jede Note unique identifier (so gut wir können)...aber dann hast du einen Stapel von 10 Hinweise und müssen Sie Holen Sie sich die 5 aus dem Stapel, und Sie werden schnell einen Beitrag zu dem Rückgang der Klebrigkeit, der wird am Ende mit den Noten auf dem Boden.
- Wenn die Karten am Ende nicht auf dem Boden, es ist einigermaßen ärgerlich, um herauszufinden, wo Sie gehen sollten. War, dass Entwickler Ein ticket? Oder B? Und war es in der Prüfung? Oder war es fertig? Gehen wir zurück in TFS, suchen Sie die tickets und dann verschieben der post-its entsprechend.
Persönlich, ich glaube nicht, dass der post-it-notes sind das entsprechende Werkzeug hier. Es gibt eine Handvoll von digitalen tools, die diese Art von Sache, die völlig problemlos ist. Wir nutzen Team foundation server und ich habe gesehen, ein paar wirklich große, robuste, kostenlos und sogar open-source-tools, die Schnittstelle mit Team foundation server und verwalten Sie alle für Sie in Echtzeit.

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

InformationsquelleAutor der Antwort Rob P.
0

Unsere boards neigen dazu zu entwickeln, überstunden wie wir Fortschritte als team. Ich Neige zu bevorzugen, physische Karte-boards, wenn Sie eine colocated team, wie es fördert eine bessere face to face Kommunikation in der Regel aus meiner Erfahrung. Offensichtlich ist es mehr Aufwand, aber es lohnt sich, um das team zusammen zu arbeiten. Ein weiterer Vorteil den ich gesehen haben mit physischen boards ist, dass es hilft mit business engagement. Remote-Akteure können sich nicht einfach anmelden und sehen den Fortschritt im aktuellen sprint und nehmen die Dinge aus dem Zusammenhang, wie manchmal die Karten nicht die ganze Geschichte erzählen. Sie haben ein Gespräch und kommen zu dem board, was von Vorteil sein kann, wie die Dinge können erklärt und es bedeutet auch, dass Sie ermutigt werden, Hilfe beheben mit Behinderungen. Dies ist jedoch nicht ausschließlich auf physische boards, aber es hilft.

Wie erwähnt, unsere boards zu entwickeln die überstunden mit den teams benötigt. Oft beginnen wir mit dem lehrbuch scrum, sondern ermutigen, kontinuierliche Verbesserungen und in der Regel mit einer scrumban Lösung. Diese änderungen werden durch die Visualisierung der neuen workflow durch die Bretter. Ich schrieb vor kurzem einen Beitrag über unsere neueste ändern, wenn Ihr Interesse haben Sie einen Blick auf unsere Sanduhr-scrum /Kanban-board

Ich denke, die Teams sollten involviert bei der Herstellung der Platten, da es hilft, das team zu verstehen, das workflow-und nicht im silo. Auch wenn das team hatte eine hand in der Herstellung der platine, die Polizei Ihre eigenen Prozesse besser was hilft bei der Selbstorganisation, wie es ist ein Produkt, das Sie hatte Eingang zu.

InformationsquelleAutor der Antwort user2231614
0

Gingen wir mit folgenden board-Struktur in unserem Unternehmen.
```
Backlog | Next sprint |      Current sprint         | Done
                         Buffer    |     Working
```
Bahnen zugeordnet sind, bestimmte Elemente. Jedes Mitglied hat den anderen job in unserem Büro, so dass die Aufgaben variieren. Wir fügen hinzu, was wir haben, zu arbeiten, unseren Auftragsbestand, bewegen Sie ihn dann in den Nächsten Sprint, wenn es nähert sich der Termin. Gesperrt grünen Aufgaben verwendet werden, für kontinuierliche Aufgaben, die bearbeitet werden, täglich. Rote Karten zeigen, wie wichtig diese Aufgabe und werden so bald wie möglich fertig.
Unser board ermöglicht uns die Zusammenarbeit frei und fügen Sie die Aufgaben zu jedem anderen swimlanes, wenn wir etwas benötigen, werden durch verschiedene Abteilung.

Verwenden wir KanbanTool (Kanbantool.com) zur Visualisierung unserer Arbeitsabläufe und Projekte zu verwalten. Es ist wirklich intuitiv und einfach zu bedienen. Unsere Kommunikation im team hat sich enorm verbessert.

InformationsquelleAutor der Antwort Szymon Majdak

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.