Unterbringung von Back-End- und Front-End-Aufgaben in Kanban

Stehen vor einem Kanban-Board-Workflow-Problem und glauben, dass wir noch keine Lösung gefunden haben.

Wir erstellen eine App, die von einer Middleware-Schicht unterstützt wird, die JSON-Inhalte bereitstellt. Nichts Neues daran.

Das Problem, das wir haben, ist die Aufrechterhaltung eines soliden Arbeitsablaufs.

Im Moment haben wir die folgenden (relevanten) Spalten: Ready 4 Dev | In Entwicklung | Bereit 4 Test | Im Test

Wir haben AUCH horizontale Swimlanes für iOS | Android | Server , der jede dieser Spalten durchschneidet.

Wir haben AUCH farbcodierte Tickets (rot = Fehler, lila = Server usw.).

Idealerweise hätten wir in einer sequentiellen Welt Spalten für f/e und b/e, aber natürlich kann parallel an Komponenten gearbeitet werden.

Mehrere Ideen, die wir hatten:

  1. Verwenden Sie EIN Ticket/eine Karte/eine Geschichte, die sich in einer Flugspur befindet, während die zusammengesetzten Aufgaben darüber fließen. Es ist erst abgeschlossen, wenn alle Aufgaben abgeschlossen sind

  2. Ein STORE ist in ZWEI (oder vielleicht mehr) Tickets (im Grunde Aufgaben) unterteilt, aber wir entfernen die horizontalen Komponenten (b/e und f/e) Swimlanes

BEISPIEL:

Feature: AGB (als Teil eines MVP)

Ticket 1: HTML-Dokumente formatieren und gestalten Ticket 2: HTML-Dokumente auf den Server hochladen und Adressen angeben Ticket 3: WebKit-Aufrufe in HTML-Dateien implementieren Ticket 4: Middleware-Dienst zur Kommunikation zwischen Client und DB (um aufzuzeichnen, wann und welche Version der AGB vereinbart wurde bei Anmeldung)

Zum Beispiel...

Es schweben also viele verwandte Tickets darüber, an denen jeweils unterschiedliche Personen oder Teams arbeiten müssen, um ein etwas triviales Feature fertigzustellen.

Anregungen?

Antworten (2)

Zu Visualisierungszwecken können Sie oben eine neue Bahn namens "Features" erstellen, in die Sie Ihre High-Level-Karten legen. Wenn Sie mit den darunter liegenden Karten fertig sind, verschieben Sie sie auf erledigt.

Eine Feature- Lane funktioniert gut, und sie funktioniert sogar noch besser, wenn Sie eine visuelle Verbindung zu ihren Unteraufgaben haben (ein einfaches Nummerierungsschema funktioniert).

Sie haben keine wirklichen Details zu dem tatsächlichen Problem angegeben, mit dem Sie konfrontiert sind. Ist es so etwas wie Android- oder iOS-Karten, die sich aufbauen, weil sie nach dem JSON-Bit gemacht werden müssen? Oder umgekehrt?

Wenn mein Verdacht richtig ist, haben Sie nur eine Karte für das Feature und eine Entwickler-JSON-Spalte links (oder rechts) von DEV Mobile. Sowas in der Art.

Ich denke, es ist tatsächlich besser, die Reihenfolge hier nicht zu erzwingen, aber ich bin mir nicht sicher, mit welchen Problemen Sie konfrontiert sind, wenn Sie es parallel tun.

Punkt 1 klingt verwirrend, da sowohl Geschichten als auch Aufgaben auf demselben Board verfolgt werden. Ich habe es benutzt gesehen, aber ich denke, es ist zu kompliziert.

Vielleicht könnten Sie zwei Boards haben. Eine Geschichte auf höherer Ebene und kleinere mit Aufgaben für die Teams.

Punkt 2 könnte etwas sein, aber ich müsste noch einmal mehr über das Problem wissen. Ich würde jedoch wirklich versuchen, Story-Karten anstelle von Aufgabenkarten auf dem Kanban-Board zu verwenden.

Bitte geben Sie weitere Details zu dem Problem an. Vielleicht können wir Ihnen besser helfen.

Ich habe einige Änderungen an meinem Original vorgenommen und ein Beispiel hinzugefügt.
Ich würde sagen, bleiben Sie einfach bei einer Karte pro Feature und einer Spalte für die Stufe im Workflow, und wer daran arbeitet, arbeitet je nach Spalte daran. Ich bin mir immer noch nicht sicher, ob ich mir das Problem vorstellen kann. Wir haben regelmäßig eine ähnliche Situation und der einfache Ansatz funktioniert für uns. Entschuldigung, ich denke, das ist nicht so hilfreich. Das einzige, was ich mir vorstelle, ist, dass Ihr Board mit aufgabenbasierten Karten zu kompliziert ist, und ich würde vorschlagen, es zu vereinfachen und funktionsbasierte Karten zu verwenden.
Ich habe die gleichen Fragen gestellt wie Kurt, als ich die ursprüngliche Frage gelesen habe. :) Es hört sich so an, als ob Sie mit zu vielen Details auf dem Board zu kämpfen haben – gibt es echte Vorteile, jede Aufgabe separat zu verfolgen, im Vergleich zu Bahnen pro Phase oder Mitarbeitern, die „off-board“ koordinieren und die Karte gemeinsam durch die Phasen bewegen?
Wie können Sie parallel an Dingen arbeiten? Sicherlich hängt die Arbeit am Front-End davon ab, dass das Back-End abgeschlossen ist?
Die Tatsache, dass wir parallel arbeiten KÖNNEN, ist Teil des Problems. Also atm, wir erstellen ZWEI Tickets für die gleiche Geschichte/dasselbe Feature. Zum Beispiel „Benutzer kann xxxx anrufen“ – EIN Ticket, um die Anrufschaltfläche zu implementieren, und ein ANDERES, um die Nummer vom Server in JSON bereitzustellen. Beides kann parallel passieren (obwohl beide an einem Punkt voneinander abhängig sind.
Heh ahsga, tatsächlich machen viele Leute zuerst das Frontend und entwickeln dann das Backend, um die Bedürfnisse des Frontends zu erfüllen. Oder wie Paul erwähnt, sie können natürlich parallel durchgeführt werden.
Hallo Paul, werde die Schwimmbahnen los und benutze ein Ticket für das Feature. Das Haupt-Kanban-Board sollte Funktionen und keine Aufgaben verfolgen (muss nicht, aber ich denke, diese Vereinfachung sollte Ihr Problem lösen). Ein kleiner Trick, den Sie tun können, wenn Sie mehr Details angeben möchten, besteht darin, 2 oder 3 kleine Kontrollkästchen auf die Karten zu schreiben, eines für das Backend und eines für jedes Frontend. Sie können eine Zeile wie einen Schrägstrich \ einfügen, um anzuzeigen, dass die Arbeit begonnen hat, und wenn sie fertig ist, können Sie das \ in ein X verwandeln. Für noch mehr Details kann jedes Team ein einfaches „to do, does, done“-Board haben Tracking-Aufgaben.
Hallo Kurt, danke für die Antwort! Gute Idee! WRT Ihren letzten Punkt; schlagen Sie "to do | does | done"-Spalten für F/E und B/E vor? Wir haben darüber nachgedacht, aber das verhindert, dass Teams parallel arbeiten, richtig? Genauso wie Ihre Vorstellung von einem Ticket. Es scheint einfach unvermeidlich ... Zwei oder mehr parallele Teams zu ermöglichen, parallel an demselben Feature zu arbeiten, bedeutet ein unordentliches Board und einen unordentlichen Ablauf und oft eine unklare Aufsicht ... Nein?
Nein, mein letzter Vorschlag war für völlig andere Boards, die eher Aufgaben als Funktionen verfolgen. Ich stellte mir vor, Sie haben getrennte Teams für sein und jedes fe-Team. Wenn Sie Teams haben, die sowohl be als auch fe sind, dann hätte ich separate Aufgabenkarten für jede kleine fe- und be-Aufgabe. Diese Boards hätten wirklich nur 3 Spalten. Natürlich können Teams parallel arbeiten. Auch selbstständig. Sie teilen sich das Kanban-Board, das Funktionen verfolgt, und in einigen Fällen wahrscheinlich sogar eine Karte. Aber sie haben ihre eigenen Todo-Boards zur Aufgabenverfolgung.
Sehr interessante Sachen Leute :) Ich würde davon abraten, zuerst Frontend-Arbeiten zu machen, nur weil die Entwickler den Code zweimal berühren müssten, einmal, um die Frontend-Arbeit zu erledigen, und noch einmal, sobald das Backend bereit ist, ihn zu verknüpfen, wäre es nicht möglich Haben Sie einen Arbeitsablauf, bei dem das Backend zuerst geliefert wird und dann die Frontend-Leute ihre Arbeit erledigen?
Unterbringung von Back-End- und Front-End-Aufgaben in Kanban
AntwortenHierDatenschutz-Bestimmungen1y, 0v