Das Kanban-Board eignet sich perfekt für Feature-Karten, reicht jedoch nicht für Unteraufgabenkarten aus. Wie verwaltet man Unteraufgaben (die einzelnen Arbeitern zugewiesen sind) auf einem Kanban-Board?

Wir sind ein kleines Team, das Webapps für mehrere Kunden parallel entwickelt.

Wir haben Scrum nicht mit vollem Funktionsumfang durchgeführt, aber wir haben „Sprints“ und Boards pro Projekt mit den folgenden Spalten:

  • Machen
  • Im Gange
  • Im Rückblick
  • Erledigt

Ein solches Board ist perfekt für Teilaufgaben . Ein Feature in der Entwicklung ist eine Aufgabe , die die Arbeit mehrerer Mitarbeiter erfordert: Designer, Backend-Entwickler und Frontend-Entwickler. Jedem Mitarbeiter wird also eine persönliche Teilaufgabe zugewiesen , und er verschiebt die Teilaufgabe auf der ganzen Linie, wenn er Fortschritte macht.

Eine solche Tafel macht es einfach, die Arbeitsbelastung jedes Arbeiters zu verfolgen. Aber dieser Ansatz leidet unter vielen Problemen, die Kanban zu lösen versucht: Aufgaben im Push-Stil, Mikromanagement, viele unvollendete laufende Arbeiten, die sich häufen, nutzlose Schätzungen usw.

In einem Versuch, Kanban anzunehmen, hatten wir ein Meeting, in dem wir über die Idee diskutierten, auf die Verwendung eines einzelnen Kanban-Boards umzusteigen. Wir haben uns folgende Spalten ausgedacht:

  • Bereit für Konzept

    Konzept in Arbeit

  • Bereit für Design

    Entwurf in Bearbeitung

  • Bereit für die Entwicklung

    Entwicklung läuft

  • Bereit zur Überprüfung

    Überprüfung läuft

  • Bereitstellen

    Auf dem Dev- Server

    Auf dem Staging -Server

    Auf Produktionsserver _

Nach einiger Diskussion sind wir zu dem Schluss gekommen, dass dieses Board perfekt für die Verwaltung von Client-zentrierten Aufgaben geeignet ist , dh jede Karte muss ein Feature darstellen. An jeder Karte arbeiten mehrere Arbeiter.

Aber dieses Board ist ziemlich kläglich für die Verwaltung von Unteraufgaben . Das ist weil:

  • Der Lebenszyklus der Funktionsentwicklung ist nicht linear, dh die Entwicklung von Frontend und Backend kann parallel oder in beliebiger Reihenfolge erfolgen. Wir möchten, dass das Board sichtbar macht, was genau gerade los ist, oder wen man anpingen muss, um seine Bewertungen zu erhalten und die Zusammenführung freizugeben.
  • PR-Überprüfungen erfordern möglicherweise 👀 von mehreren Personen. Natürlich möchte ich an der Tafel sehen, welche PRs gerade meine Aufmerksamkeit erfordern.
  • Die Bereitstellung kann für Backend und Frontend getrennt erfolgen, zumindest auf dem Dev-Server.
  • Wir haben Pro-PR-Vorschaubereitstellungen, die eine QA-Prüfung anstehender PRs ermöglichen. developFront-End- und Back-End-PRs werden jedoch in der Vorschau gegen Zweige voneinander bereitgestellt . Wenn für ein Feature sowohl Frontend- als auch Backend-Änderungen erforderlich sind, kann es nur dann einer QS unterzogen werden, wenn mindestens ein PR bereits zusammengeführt wurde (dann spiegelt die Vorschaubereitstellung des anderen PR das Ergebnis wider) oder wenn beide PRs zusammengeführt sind (dann der Dev-Server wird das Ergebnis widerspiegeln).

Aus der Sicht eines Kunden scheinen all diese Details "Implementierungsdetails" der Spalte "Development in Progress" zu sein. Wenn wir diese Details aus dem Kanban-Board weglassen, wird das Board vollkommen konsistent und effizient bei der Verwaltung von Feature-Cards auf allgemeiner Ebene, dh ohne ins Detail zu gehen.

Das Problem ist, dass wir das Detail wollen! Wir werden das Kanban-Board innerhalb des Teams verwenden und erwägen nicht, das Board unseren Kunden zugänglich zu machen, zumindest bis jetzt. Daher möchten wir, dass diese "Implementierungsdetails der laufenden Entwicklung" auf dem Board sichtbar sind . Wir wollen die Teilaufgabenkarten sehen! Aber gleichzeitig wollen wir alle Hauptprinzipien von Kanban übernehmen : Sichtbarkeit, Zuweisungen im Pull-Stil, kein Mikromanagement, WIP-Limits, Fokus auf horizontale Swimlane-Geschwindigkeit auf Kosten der Nicht-Vollbeschäftigung usw.

Wie machen wir es also? Zwei Boards parallel verwenden? Erstellen Sie ein 2D-Kanban-Board? Ein Board in ein anderes einbetten? Alle Hoffnung aufgeben?


Hausaufgaben:

Sie sagen : „Dieser Ansatz leidet unter vielen Problemen, die Kanban zu lösen versucht: Aufgaben im Push-Stil, Mikromanagement, viele unvollendete Arbeiten, die sich häufen, nutzlose Schätzungen usw.“ Dies sind Verhaltensweisen, die sich auf den Arbeitsfluss und die Produktivität auswirken. Sie schlagen einen neuen Arbeitsablauf und neue Boards vor und organisieren Dinge neu, aber tun Sie etwas gegen diese Verhaltensweisen? Eine andere Sache: Sie machen einen vollständigen Austausch, wie es scheint. Haben Sie zuerst kleinere, inkrementelle Änderungen ausprobiert, um die Probleme zu lösen, die Sie mit Ihrem aktuellen Ansatz haben, bevor Sie einen Big-Bang-Ersatz vornehmen?
@Bogdan, "Sie machen anscheinend einen vollständigen Ersatz" - nein, wir ziehen es nur in Betracht. „Haben Sie zuerst kleinere, inkrementelle Änderungen versucht“ – nein. Das erste, was auf unserer Wunschliste steht, ist die Zusammenführung von Pro-Projekt-Boards zu einem einzigen unternehmensweiten Board. Diese Änderung allein ist störend genug, um als All-in-Zug betrachtet zu werden. Es nur für einige Projekte zu tun, bringt keinen Nutzen, es ist alles oder nichts. Im Vergleich dazu erscheinen andere Änderungen geringfügig, und ich sehe keinen Grund, an alten Praktiken festzuhalten.
Es scheint ein grundlegendes Problem zu sein, dass ein Kanban-Board dazu dient, einen Workflow zu visualisieren. Es scheint, als hätten Sie mehrere Workflows. Wenn Sie Kanban-Boards verwenden, benötigen Sie Boards für jeden Workflow. Sie brauchen jedoch nicht unbedingt Kanban-Boards für alles – es gibt alternative Visualisierungen, je nachdem, welche Tools Ihnen zur Verfügung stehen.

Antworten (1)

Nehmen Sie als kleines Team ein Projekt nach dem anderen an

Sie sagten, Sie wollten unter anderem das Kanban-Prinzip „WIP-Limits“ übernehmen. Der Grund, warum Kanban WIP-Limits empfiehlt, ist, dem Team zu helfen, sich zu konzentrieren und Kontextwechsel zu minimieren. Stattdessen fliegst du sehr weit in die entgegengesetzte Richtung:

Zwei Boards parallel verwenden? Erstellen Sie ein 2D-Kanban-Board? Ein Board in ein anderes einbetten?

Angenommen, Sie finden ein Tool, das eine dieser Funktionen unterstützt, wird dies für Ihr kleines Team ein Alptraum für den Kontextwechsel, denn Sie sind:

Erstellen von Webapps für mehrere Clients parallel

Meine Empfehlung ist, dass Sie in erster Linie die „WIP-Limits“ auf die Anzahl der gleichzeitig laufenden Projekte anwenden sollten. Eine der wichtigsten Voraussetzungen dafür ist, Ihr Entwicklerteam funktionsübergreifender zu schulen. Es kann in der Praxis nicht möglich sein, nur jeweils ein Projekt zu bearbeiten. Aber es lohnt sich, in diese Richtung zu arbeiten.

Wenn ein Mitglied des Entwicklungsteams abgeschlossen hat, woran es gerade arbeitet, lautet meine Richtlinie für es, zuerst zu prüfen, ob es einem anderen Teammitglied helfen kann, seine bereits laufende Arbeit abzuschließen. Nur wenn das gar nicht möglich ist, sollten sie neue Arbeiten auf den Status „In Bearbeitung“ bringen.

Ebenso sollten Sie das Entwicklerteam bitten, zu sehen, was es tun kann, um das bereits laufende Projekt abzuschließen, anstatt weitere Projekte in den Pool „In Bearbeitung“ zu bringen. Jedes neue Projekt, das Sie diesem Pool hinzufügen, erhöht die Produktivitätssteigerung bei der Kontextumschaltung exponentiell.