In unserem Unternehmen stehen wir auch vor ähnlichen Problemen und ich würde dem obigen Beitrag zustimmen, dass Kanban eine gute Wahl ist. Das Kanban-Board bietet dem Team die nötige Sichtbarkeit und Klarheit, außerdem führen wir Meetings für einen schnellen Überblick durch. Während der Planungsphase nehmen wir teil - wenn die Planung für das erste Projekt ist, laden wir nur die Mitglieder ein, die verwandt sind. Auf diese Weise sparen wir Zeit. Kanban eignet sich auch hervorragend für Multitasking-Einschränkungen, hier kommen die Grenzen für Spalten. Es ist sehr wichtig, in Umgebungen mit mehreren Projekten Grenzen zu setzen, damit sich die Mitarbeiter auf einzelne Aufgaben konzentrieren können, bis sie erledigt sind.

Ich denke, das ist durchaus möglich, da Sie sich auf eine und die wichtigste Regel einigen müssen. Wenn Sie ein Sprint-Backlog planen, schließen Sie es und es gibt keinen Platz für neue „unerwartete“ Arbeitsaufgaben. Da Sie gezwungen sind, bei jedem der laufenden Projekte Wert zu liefern, scheitern Sie in jedem anderen Fall nicht an einem Projekt, sondern an allen. Außerdem ist es wichtig, dass das gesamte Team mit diesen Projekten verbunden ist, denn wenn eine Person nur an Projekt A arbeitet und die anderen Teammitglieder an Projekt B arbeiten, verschwenden Sie Zeit, anstatt zu sparen.

Aber alles in allem wird Scrum funktionieren, wenn Sie die Richtlinien anwenden, nehmen Sie zum Beispiel ein großes System, das aus verschiedenen Modulen besteht, aber sie sind ein großes Projekt, so wie Sie - Ihre Projekte sind wie Module, aber weniger verwandt :)

Eine Frage, vielleicht wäre Scrumban oder sogar ein einfacher Kanban-Ansatz für eine schnelle Projektabwicklung geeignet? IMHO ist Kanban lockerer und für kleine Teams geeigneter als Scrum, da es ziemlich wenige Übungen erfordert.

Ich hoffe, es gibt nicht zu viele Redundanzen zu anderen Antworten, aber ich wollte auf einige Details zu Tools eingehen, die Sie in agilen Teams mit mehreren Projekten verwenden können.

Was wir tun (ungefähr 6 Entwickler, an 2 größeren und bis zu 4 kleineren Projekten gleichzeitig) ist auch die Kombination von Tools aus verschiedenen Technologien.

1. Wir schreiben Spezifikationen auf Basis von User Stories, die wir gemeinsam mit unseren Kunden entwickeln oder zumindest am Ende Korrektur lesen lassen.
2. Am Ende der Iterationen (oder wenn Sie flexibler arbeiten, wann immer etwas fertig ist) lassen wir den Kunden die auf der Grundlage dieser Spezifikationen geleistete Arbeit abnehmen.
3. Wo es möglich ist, arbeiten wir in Iterationen, das ist kein generelles Problem, nur weil es mehrere Projekte gleichzeitig gibt.
4. Retrospektive, Sprint-Planung usw. können je nach Projekt- / Iterationsgröße und anderen Umständen (z. B. wie gut der Kunde spezifiziert) mehr oder weniger umfassend sein.
5. Wir führen täglich ein Stand-up-Meeting mit allen Entwicklern und der QA durch.
6. Für das Stehmeeting verwenden wir ein Board im Kanban-Stil, auf dem wir projektübergreifend farbcodierte Karten haben. Es hat eine Weile und etwas Disziplin gedauert, bis alle verstanden haben, dass es in Ordnung ist, sich Berichte aus anderen Projekten anzuhören, aber am Ende hat es sehr geholfen, dass sich Menschen motiviert haben, sich gegenseitig mit Erfahrungen projektübergreifend zu helfen.
7. Wir verwenden meistens Schätzungen im Story-Point-Stil, um ein Gefühl für die Geschwindigkeit für jedes Projekt / Projektteam zu bekommen.

Wie andere Antworten bereits vorgeschlagen haben, glaube ich, dass ein Board im Kanban-Stil das wichtigste Werkzeug in Ihrem Fall sein könnte. Sie werden sehen, ob sich Aufgaben beispielsweise beim Design oder Testen häufen, wenn Aufgaben hängen bleiben, und Sie können Aufgaben auf transparente Weise auch projektübergreifend priorisieren.

Erledigen Sie Ihre Projekte sequentiell, eines nach dem anderen. Zeitraum.

Und wie verhindert man, dass andere Projekte/Kunden nicht einen Monat warten...

Denken Sie darüber nach: Angenommen, Sie haben drei Projekte zu erledigen, und jedes dauert vier Wochen (wobei das gesamte Team daran arbeitet). Gehen Sie weiter davon aus, dass Sie keine Zeit verlieren würden, wenn Sie zwischen ihnen wechseln.

Wenn Sie diese perfekt parallel machen, haben Sie bis zum allerletzten Tag der Zwölf-Wochen-Periode kein abgeschlossenes Projekt. Das heißt, alle Ihre Kunden warten fast drei Monate.

Wenn Sie in einwöchigen Sprints zwischen Projekten wechseln, beenden Sie ein Projekt nach zehn Wochen, eines nach elf Wochen und eines nach zwölf Wochen. Herzlichen Glückwunsch, jetzt muss nur noch einer Ihrer Kunden drei Monate warten – aber die anderen bekommen ihre Sachen erst ein bis zwei Wochen vorher.

Wenn Sie die Projekte nacheinander durchführen, hat ein Kunde sein Projekt am Ende von vier Wochen. Eine zweite wird nach acht Wochen ihre haben. Und ein dritter wird seine am Ende von zwölf Wochen haben – was passieren wird, egal wie Sie es planen, es sei denn, Sie haben zufällig eine TARDIS.

In Wirklichkeit beeinträchtigt das Wechseln zwischen Projekten Ihre Produktivität, sodass Ihre tatsächliche Erfahrung mit Parallelität oder Abwechslung schlechter sein wird, als wenn Sie sie einfach nacheinander ausführen würden.

Sie haben ein kleines Team. Teilen Sie das Team nicht auf, weil Sie glauben, Sie könnten mehr Arbeit erledigen. Du kannst nicht.

Ja, es kann getan werden. Es ist schwer!

Es gibt viele Dinge, die ich empfehlen kann, aber etwas, das Ihre Arbeitsweise wirklich verändern wird, ist Ihr Kommentar: „Können wir wirklich etwas in 2 Wochen liefern?“. Ja. Automatisieren Sie absolut alles. Streben Sie danach, mehrere Bereitstellungen pro Tag durchführen zu können. Kleinere Änderungen. Weniger Codezeilen. Kleinere Risiken. Kleinere Prüfungen. Weniger Fehler.

Wenn Sie mit dieser Geschwindigkeit liefern können, ändert sich Ihr Gespräch mit Ihren Projekten von: "Wie viele Wochen brauchen wir, um alles zu erledigen?" zu "Was möchten Sie morgen früh haben?"

Sie können mit der Verwaltung mehrerer Projekte beginnen, da sich Ihre Konversation von „Können Sie bis Juli warten?“ ändert. zu "Wir können Ihre wichtigste Funktion nächste Woche zum Laufen bringen, ist das in Ordnung?"

Ich denke, Sie müssen einen Schritt zurücktreten und sich keine Gedanken über SCRUM und Sprints machen.

Sie haben ein kleines Team und mehrere Kunden mit mehreren Projekten, die sie erledigen möchten.

Konzentrieren Sie sich auf einen Kunden oder ein Projekt

Für jeden Kunden und jedes Projekt ist es eine gute Idee, eine grobe Schätzung des Ertragswerts vorzunehmen. Wenn möglich, versuchen Sie, wie andere hier gesagt haben, die Anzahl der Kunden oder Projekte auf den Kunden/Projekt mit dem höchsten Wert zu reduzieren.

Es ist eine schlechte Geschäftslage, aber wenn Sie klein sind und gerade erst anfangen, müssen die Dinge einfach so sein, bis Sie genug Geld gespart haben, um zusätzliche Entwickler und Designer einzustellen. (Deshalb versuchen Agenturen immer, Produkte in ferner Zukunft zu entwickeln, um nicht nur von bestimmten Kunden und der Kunden-/Projektpipeline abhängig zu sein).

Fügen Sie Zeitschätzungen einen Puffer hinzu

Wenn Sie jedes Projekt planen, fügen Sie für jede Phase einen Puffer hinzu, der die stattfindenden Kontextwechsel berücksichtigt. Der Kontextwechsel kann in Form von Wartung oder Funktionen (abhängig von Ihren vertraglichen Verpflichtungen) erfolgen.

Konzentrieren Sie sich auf einen Tech-Stack oder eine Technologie

Versuchen Sie, die Projekte zu konsolidieren, sodass sie dieselbe Codebasis oder dieselben Frameworks, Bibliotheken oder Tools verwenden. Dies wird Kontextwechsel reduzieren und ermöglicht es vielen Webentwicklungsagenturen, Projekte schnell und erfolgreich abzuschließen.

Ich habe zum Beispiel an einem Ort gearbeitet, der Python/Django/PostgreSQL für alle Projekte verwendet hat. Wenn ein Kunde eine andere Technologie verwenden wollte, würde dies den Preis des Projekts erhöhen (um Schulungen oder die Einstellung neuer Entwickler zu berücksichtigen). Die meisten Kunden waren damit zufrieden, die Wahl der Technologie der Agentur zu überlassen.

Bei einem anderen Unternehmen haben wir nur Drupal und Wordpress verwendet, wodurch wir Kunden gewinnen konnten, die eine CMS-Website auf Unternehmensebene oder eine Website für kleine Unternehmen wollten. Die Tools gaben uns die Flexibilität, auf kleinen oder großen Websites zu arbeiten.

SCRUM und Projektmanagement und Sprints

Ihr großes Problem bei mehreren Projekten wird der Kontextwechsel sein. Ein Entwickler und Designer muss seinen Workflow umstellen. Bei größeren Aufgaben müssen Sie einen Tag hinzufügen, bevor die „echte“ Arbeit erledigt wird, bei den größten Aufgaben müssen Sie möglicherweise 2-3 Tage hinzufügen, damit das Teammitglied wieder auf Kurs kommt. Für kleine Aufgaben können Sie vielleicht einen halben Tag oder ein paar Stunden für den Kontextwechsel einplanen.

Sie müssen Erwartungen festlegen, wann Client-Updates/Meetings stattfinden können und wann Sie auf Notfälle und Anfragen von Kunden reagieren können. Auf diese Weise können Sie Zeitabschnitte gruppieren, um Kontextwechsel zu reduzieren.

• 1 Kunde, 1 Projekt: Idealerweise konzentriert sich Ihr Team auf die Erledigung eines Projekts, es gibt keinen Kontextwechsel
• 1 Kunde, 2 Projekte: fast ideal, Ihr Team kann Updates liefern und sich auf die Bedürfnisse von 1 Kunden konzentrieren
• 2 Kunden, 2 Projekte: Wenn Ihr Team irgendwann in Schwierigkeiten mit Timing und Zeitplänen gerät, muss es sich auf einen Kunden konzentrieren und dann den Fokus auf einen anderen richten. Sie werden auf Abhängigkeiten von Entwicklern über Designer bis hin zu Kunden stoßen, welche Tage gut für Besprechungen sind und wann bestimmte Aufgaben erledigt werden müssen. Vielleicht möchten Sie Aushilfskräfte einstellen. Eine gute Idee ist es, 1 Kunde/Projekt für die erste Wochenhälfte und den anderen Kunden/Projekt für die andere Wochenhälfte einzuplanen oder zwischen den Wochen zu wechseln (1 Projekt pro Woche).
• 2+ Kunden, 2+ Projekte: Sie müssen mehr Leute einstellen und sie in Teams aufteilen, die sich auf höchstens 1-2 Projekte oder Kunden konzentrieren.

Ich praktiziere Scrum jetzt seit ein paar Jahren. Ich bin hierher gekommen, weil ich jetzt mit einem kleinen Team (4 Entwickler, 1 QA) arbeite, das für ein Portfolio von Unternehmensprojekten, Neuentwicklungen, Verbesserungen und Support verantwortlich ist. Ich denke, die offensichtliche Antwort kommt von George P.; Arbeiten Sie an einem Projekt nach dem anderen, bringen Sie es zum Abschluss und fahren Sie mit dem nächsten fort. Sie werden die Projekte tatsächlich schneller und besser erledigen. Der Durchsatz vom Engagement bis zur Fertigstellung für jeden Kunden wird kürzer sein. Ich habe versucht, parallele Projekte mit Scrum auszuführen, und der Overhead der Scrum-Rituale und die Ablenkung durch das Wechseln von Projekten ist verschwenderisch. Versuch es. Wenn Sie einmal gut darin sind, werden Sie Ihre Kunden mit Ihrer Geschwindigkeit verblüffen.