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:
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:
develop
Front-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 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.
Bogdan
Andrej Michailow - Lolmaus
Thomas Owens