Bevor ich anfange, muss ich mich vorbeugend entschuldigen:

Es ist sehr wahrscheinlich, dass einige der in diesem Beitrag verwendeten Begriffe / Vokabeln einfach falsch sind. Es besteht auch eine gute Chance, dass ich einige der Schlüsselaspekte völlig falsch interpretiert habe. Ich bin neu in diesem Bereich, also sei nicht zu kritisch, sondern begrüße konstruktives Feedback;)

Hintergrund

Wir stellen derzeit eine Entwicklungsabteilung mit 200 Mitarbeitern von Multi-Methodik auf "Agile" um. Das Warum, Warum, Für und Wider davon geht weit über den Rahmen dieser Frage hinaus.

Diese Entwicklungsabteilung besteht aus einem Architecture Service-Team, das aus 10 Personen besteht, die offiziell als "Solution Architects" bekannt sind. In Wirklichkeit decken sie mehr als nur die Lösung ab. Hierbei handelt es sich um technische Mitarbeiter, die alle technischen Architekturaspekte eines Projekts abdecken (z. B. Hardware, Software, Sicherheit, Governance usw.). Sie bieten auch Ad-hoc-Funktionen für das Entwicklungsteam (Codeüberprüfungen, Standardrichtlinien usw.) und das gesamte Geschäft (technische Eingaben in Ausschreibungen, technische Vorschau der Kundenanforderungen vor Vertragsabschluss).

Im Rahmen dieses Übergangs wurde ich beauftragt, ein Kanban-Board zu erstellen, um einen Überblick über die Arbeitsaktivitäten zu erhalten, für die das Architecture Service-Team verantwortlich ist. Es gibt unzählige Beispieltafeln für Entwicklungs- / Codierungsteams, aber keine, die ich für die Architektur finden kann. Also habe ich aus verschiedenen Quellen "etwas" geschaffen, ich würde mich wirklich über echtes Feedback dazu freuen.

Es ist auch erwähnenswert, dass dies dem Team als Ausgangspunkt / laufende Arbeit präsentiert wird. Es ist ihr Board und ich möchte, dass sie es besitzen. Alles, was ich tue, ist eine Grundlage zu schaffen, auf der die Jungs aufbauen können (und sich bei Bedarf ändern können).

Bisher habe ich so etwas

Die Hauptplatine

Auf der Hauptplatine halten wir alle aktiven / Backlog-Projekte ab - alle aktiven Arbeiten werden auf dieser Platine stattfinden. Dies wird im täglichen Architektur-Scrum kurz besprochen und am Ende jeder Woche eingehender besprochen.

           ------------------------------------------------------------------------
           | Evaluation            | Implementation       | Ad- Hoc               |
           | Todo  | Doing  | Done | Todo  | Doing | Done | Todo  | Doing  | Done |
    -------------------------------------------------------------------------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    --------       -----------------       ----------------       -----------------
    Person |       |        |      |       |       |      |       |        |      |
    -------------------------------------------------------------------------------

Die Spaltenbeschreibungen / -zwecke sind:

Bewertung : Projekte, bei denen die Person eine erste technische Analyse durchführt, dh mit einem Product Owner technische Optionen durchläuft, um die Größe des Projekts zu bestimmen. Ein Evaluierungsprojekt kann beispielsweise der Architekt sein, der eine neue Technologie evaluiert oder mit einem Kunden zusammenarbeitet, um eine einvernehmlich festgelegte technische Lösung zu erstellen.

Implementierung : Projekte, die sich aktiv in der Entwicklung befinden (Codierung, Test usw.) und die Person in einer SA-Funktion für das breitere Projektteam handelt. Als Beispiel könnte dies die Entwicklung von Codierungsaspekten der oben erwähnten "einvernehmlichen technischen Lösung" sein, ebenso könnte es auch die architektonische Überwachung der Implementierung einiger neuer Hardware sein.

Ad-hoc : All die seltsamen und wunderbaren Dinge, die auftauchen und nicht in die beiden anderen Spalten eingefügt werden können. Als Beispiel in einer seltsamen rekursiven Welt gibt es in der Ad-hoc-Spalte eine Karte für mich, um ein KanBan-Board zu erstellen :).

Person : Ziemlich selbsterklärend, die Person, die die Karten in dieser Reihe "besitzt". Um die Dinge ein bisschen lustiger zu machen, enthält dies tatsächlich einen Avatar dieser Person.

Todo : Ist effektiv unser Rückstand, werden die Karten hier vorrangig von oben nach unten sortiert. Wenn Platz in einer Person, die eine Zelle macht, verfügbar wird, nehmen wir von oben nach unten.

Tun : Ziemlich selbsterklärend

Fertig : Elemente, die seit der letzten Überprüfung der Vollpension abgeschlossen wurden (Freitagnachmittag jede Woche)

WIP-Grenzwerte

Anstatt das zu tun, was wir jetzt tun (dh Arbeit zu geben, bis jemand quietscht), möchte ich, dass die Hauptplatine mit objektiven / evidenzbasierten WIP-Grenzwerten arbeitet. Die Absicht ist, jede der Karten mit folgenden Größen zu versehen:

• XS (extra klein): 3 Punkte
• S (klein): 5 Punkte
• M (mittel): 8 Punkte
• L (groß): 13 Punkte
• XL (extra groß): 21 Punkte

Die Größe ist aus Sicht der Architekten sehr stark, zum Beispiel ein Projekt, das 1 Jahr Codierung für 10 Personen erfordert, aber nur minimale architektonische Eingaben, wäre XS oder S. Ein Projekt, das massive architektonische Eingaben, aber minimale Codierungen aufweist, könnte jedoch XL sein.

Im Laufe der Zeit sollten wir in der Lage sein, das WIP-Limit für jede Person zu ermitteln. Wir wissen also, dass Jonny Smith mit einer Geschwindigkeit von 42 Punkten arbeiten und daher Projekte bis zu dieser Ebene zuweisen kann.

Da wir dies vorher noch nicht getan haben, ist es meine Absicht, das anfängliche Limit hoch zu setzen. Die Idee ist, dass wir (als Team), wenn eine Person quietscht, dies objektiv betrachten und feststellen können, ob es wirklich zu viel ist oder ob es an unseren Prozessen liegt usw. sind zu lästig und sollten rationalisiert werden.

• HINWEIS : Von allem hier sind diese WIP-Berechnungen das Bit, das sich am wenigsten richtig "anfühlt" *

Das Trichterbrett

Um alle zufälligen Dinge im Auge zu behalten, die durch das Team fliegen, haben wir auch ein Trichterbrett. Dies ist ein relativ einfaches Board, das so aussieht:

    ------------------------------------------------------------------------
    | Evaluation            | Implementation       | Ad- Hoc               |
    ------------------------------------------------------------------------
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    |                       |                      |                       |
    ------------------------------------------------------------------------

Da das Team auf ein "Projekt" aufmerksam gemacht wird, dieses jedoch noch nicht offiziell genehmigt ist (dh in die Todo-Spalten auf der Hauptplatine eingefügt werden kann), wird es auf die Trichtertafel übertragen. Elemente hier sind keiner Person zugeordnet. Die Idee ist, dass wir die zufälligen Dinge, die durchkommen, verfolgen und sicherstellen können, dass sie nicht vergessen werden. Wenn die Person ein Evaluierungsprojekt abschließt, wechselt diese von der Evaluierung der Hauptplatine zur Implementierungs-Trichtertafel (es sei denn, es wird sofort ein Implementierungsprojekt).

Ein Mitglied des Teams wird gelegentlich beauftragt, alles auf dem Trichterbrett zu verfolgen, dh einen kurzen Anruf beim Produktbesitzer zu tätigen und zu fragen, ob dies noch relevant ist (dies wäre ein Ad-hoc-Projekt auf dem Hauptbrett).

Das Erfolgsgremium

Dies ist nur ein einfaches Board, um zu verfolgen, was wir in den letzten X Monaten getan haben. Es enthält die Karten, die durch den Trichter und / oder die Hauptplatinen gegangen sind

    ------------------------------------------------------------------------
    | Successes                                                            |
    ------------------------------------------------------------------------
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    |                                                                      |
    ------------------------------------------------------------------------

Die Idee ist, dass wir gelegentlich um dieses Board herumkommen und uns gegenseitig auf den Rücken klopfen können :)

Board Cards

Die Karten auf den Brettern enthalten die folgenden Informationen:

    ------------------------------------------------------------------------
    | SIZE (XS,S,M,L,XL)          | OWNING TEAM MEMBER             |  RAG  | 
    ------------------------------------------------------------------------
    |                                                                      |
    |                         PROJECT TITLE                                |
    |                                                                      |
    ------------------------------------------------------------------------
    |                                  |                                   |
    |        DEPENDENTS                |          DEPENDENCIES             |
    |                                  |                                   |
    ------------------------------------------------------------------------
    |                                                                      |
    |                         MISC INFORMATION                             |
    |                                                                      |
    ------------------------------------------------------------------------
    |                WIDER PROJECT TEAM (AS APPLICABLE)                    |
    | Other Architects, Project Manager, Principal Developer, Business     |
    | Analyst, Scrum Master                                                |
    ------------------------------------------------------------------------

Da Sie feststellen werden, dass die Granularität der Karte auf einem ziemlich hohen "Projekt" -Niveau liegt, habe ich nicht vor, ein Entwickler-Style-Board zu erstellen, das in Aufgaben unterteilt ist (Gedanken zu diesem Willkommen). Erwähnenswert ist auch, dass je nachdem, wo sich die Karte befindet, nicht alle Abschnitte anwendbar sind. Ich plane auch die Farbcodierung der Karten, als ersten Stich habe ich:

Gelb: Alles, was vom Kunden vertraglich vereinbart wurde. Rosa: Alles, was intern ist (dh nicht dem Endbenutzer zugewandt ist). Grün: Alles, was ein Unternehmensgruppenprojekt ist

Die Karten werden eher magnetisch als post-it sein. Ich hoffe, einige zu finden, die wie Mini-Whiteboards aussehen, da dies das Leben erleichtert, wenn sich die Dinge ändern

Andere Sachen

• Wenn es nicht auf einer Karte auf einem Brett ist, existiert es für das Team nicht
• Die Boards selbst sind Whiteboards mit Rädern, wir können sie überall hin mitnehmen
• Wir könnten in Zukunft in Betracht ziehen, ein virtuelles Whiteboard zu verwenden (physische Whiteboards lassen sich leichter ändern, wenn wir entscheiden, dass die X-Spalte am besten links von Y und nicht rechts ist).

Fragen

1. Was denkst du, nachdem du meinen Neuling Kanban War and Peace gelesen hast? (Bitte schont mich :))

Beeindruckend! Es dauerte einige Zeit, um vollständig zu verdauen und zu verstehen. Herzlichen Glückwunsch zu Ihrer Entscheidung, Kanban für Ihre Agile-Initiative zu übernehmen. Wirklich schöne Analyse und Modellierung bisher. Vielen Dank, dass Sie es hier teilen und uns erlauben, zu dieser Initiative beizutragen und dazu beizutragen!

Ich habe einige Gedanken und Vorschläge - hoffe diese helfen!

A. Erstens, um eine allgemeine „Systemansicht“ zu erhalten, habe ich die drei von Ihnen gezeigten Tafeln NUR zur Verfolgung der Arbeit der Architekten zusammengestellt, nicht für den Rest der Arbeit der Entwicklungsabteilung. Ist das richtig?

B. In Anbetracht der Art und Weise, wie Sie es beschrieben haben, scheint es, dass jede der Trichterkartenspalten im Wesentlichen die Spalte „Bereit“ für die entsprechenden Abschnitte der Hauptplatine ist.

1. Ist es notwendig, die separate Trichterkarte zu haben? Wäre es nicht einfacher, eine einzige Karte zu haben - wo Sie für jeden Abschnitt der Hauptplatine Spalten mit "Trichter" oder "Bereit" haben?

2. In ähnlicher Weise kann das Erfolgsboard als große Spalte rechts vom Main Board angesehen werden, in der sich alle erfolgreich abgeschlossenen Arbeiten für einen bestimmten Zeitraum ansammeln.

3. Abhängig von der Anzahl der Projekte im Trichter und in Bearbeitung (in einer der Phasen) zu einem beliebigen Zeitpunkt wäre es einfacher, diese alle in einem einzigen Board zu verwalten, das das folgende Design aufweist:

Natürlich ist es sehr wahrscheinlich, dass Sie dies bereits bewertet haben und entschieden haben, dass es zu groß ist, um es in einem einzigen Board zu verwalten! (Sie könnten in Betracht ziehen, die To-Do-Spuren in jedem Abschnitt zu löschen, da die Trichterspur möglicherweise denselben Zweck erfüllt?)

C. In Bezug auf das Mainboard-Design hängt es wirklich davon ab, was Ihre allgemeinen Ziele für die Implementierung von Kanban sind. Einige Fragen zum Boarddesign:

1. Möchten Sie die Vorlauf- / Zykluszeiten für Einzelpersonen (was im aktuellen Design einfach zu tun wäre) oder für verschiedene Arten von Projekten (die möglicherweise schwieriger sind (aber angesichts Ihrer Farbcodierung nicht zu viel) verbessern? Wenn ja In letzterem Fall möchten Sie die Fahrspuren möglicherweise nicht nach Personen, sondern nach Projekttyp definieren (ähnlich wie bei der Serviceklasse).

2. Ist es jemals möglich, dass zwei Architekten an einem einzigen Projekt arbeiten? Wenn ja, würde es schwierig sein, Spuren von Personen zu haben, wenn Sie nicht zwei Karten für dasselbe Projekt gegen jede Person hätten?

3. Ist es möglich, dass verschiedene Projekttypen einen unterschiedlichen Workflow haben? Könnte ein Kundenprojekt beispielsweise eine genauere Prüfung (Validierung oder Prüfung oder Überprüfung) erfordern als die anderen? In diesem Fall können Sie mit Kanban unterschiedliche Workflows für unterschiedliche Arbeitstypen verwenden, was bei diesem Entwurf nicht möglich wäre.

   Wenn einer der oben genannten Punkte 1-3 in Ihrer Situation sinnvoll ist, würde ich vorschlagen, dass Sie Fahrspuren in Betracht ziehen sollten, die nicht auf Personen, sondern auf einem anderen Aspekt basieren. Nach dem, worüber Sie gesprochen haben, scheint es eine Option zu sein, dies nach Projekttyp zu tun - aber ich bin sicher, dass auch andere Kriterien möglich sind.

4. Ein weiterer Vorschlag, nur für eine intuitivere Visualisierung - da die Leute den Fluss von links nach rechts (oder in einigen Teilen der Welt von rechts nach links) als Richtung des Flusses zuordnen, denken Sie, dass der Ad-hoc-Bereich dazu gehört Das Recht der Implementierungsspalten könnte verwirrend sein. Meine eigene Präferenz wäre es, Ad-hoc-Projekte mit einer eigenen separaten Schwimmbahn zu haben.

   Das Main Board könnte also wie folgt aussehen:

   

5. In all dem könnten Sie einige „Avatar-Aufkleber“ haben, um zu zeigen, welche Architekten an jedem Projekt gearbeitet haben, die Sie auf die Projektkarten kleben könnten. Bei Bedarf kann eine Legende auf einer Seite der Tafel erklären, welcher Avatar welcher Architekt war.

6. Zum Schluss noch eine größere Frage: Sie haben anfangs festgestellt, dass diese Boards Projekte verfolgen sollten, für die die Architekten verantwortlich waren. Ich nehme an, diese Projekte sind Teil von (größeren) Projekten, die von der gesamten Entwicklungsabteilung durchgeführt werden. Wie wollen Sie Abhängigkeiten zwischen diesen (größeren) Projekten und der Arbeit der Architekten aufzeigen?

D. In Bezug auf die WIP-Grenzwerte, basierend auf dem, was ich bei einigen unserer Kunden gesehen habe, ist es anfangs nicht zu viel zu schwitzen! Im Laufe der Zeit ist es jedoch wichtig, WIP-Grenzwerte festzulegen - und diese bei Bedarf zu ändern, anstatt keine WIP-Grenzwerte festzulegen. Wenn Sie bereits Daten darüber haben, wie viele Projekte jeder Architekt oder das gesamte Architektenteam in den letzten Monaten bearbeitet hat, können Sie damit bereits einige anfängliche WIP-Grenzwerte definieren.

Wenn Sie in Zukunft in Betracht ziehen, auf ein virtuelles Kanban-Board zu gehen, sind einige davon möglicherweise einfacher zu verwalten, zu ändern und zu spielen - wie z.

• Menschen zeigen, die an Karten arbeiten
• Einrichten und Anzeigen von Kartenabhängigkeiten innerhalb und zwischen Karten
• Filtern des Boards nach Personen, Projekttyp oder anderen Attributen
• Änderungen an Board- und Kartendesigns usw. vornehmen

Ich hoffe, das hilft - zumindest, wenn Sie einige Ideen einbringen, die Sie berücksichtigen sollten.

Beste,

Mahesh

Interessante Lektüre und meistens sinnvoll.

Die einzige unmittelbare Sache, die ich kommentieren möchte, ist, dass ein Kanban-Board einen Arbeitsfluss von links nach rechts darstellen soll. Da ich mir vorstelle, dass Ihre Arbeit nicht von der Implementierung zu Ad-hoc fließt, funktioniert dies auf Ihrem Board nicht wirklich.

Eine bessere (imo) Option wäre, die horizontalen Fahrspuren als Evaluierung, Implementierung und Ad-hoc zu verwenden und dann die Karten selbst die Namen der Personen auf ihnen zu enthalten. Dies hat den Vorteil, dass mehr als eine Person an einer Aktivität arbeiten kann (obwohl Sie dies möglicherweise nicht benötigen).

Darüber hinaus haben Sie, wie auf dem anderen Poster angegeben, externe Abhängigkeiten nicht berücksichtigt. Es könnte sich lohnen, eine Spalte "Blockiert" zu haben, um Arbeiten anzuzeigen, die auf jemanden oder etwas außerhalb des Teams warten.

Hoffe das ist nützlich