web-dev-qa-db-de.com

Wie funktioniert Scrum, wenn Sie mehrere Projekte haben?

Ich bin ziemlich gut über die Vorteile und Prozesse von Scrum informiert. Ich erhalte die Ideen im Backlog, in Burndown-Diagrammen, in Iterationen, mithilfe von User Stories und anderen verschiedenen Konzepten des Scrum-Frameworks.

Vor diesem Hintergrund ... arbeite ich für eine Webentwicklungsfirma, die mehrere Projekte gleichzeitig verwaltet, mit sechs Teammitgliedern, die das "Produktionsteam" bilden.

Wie funktioniert Scrum mit mehreren Projekten? Planen Sie immer noch eine Iteration für ein einzelnes Projekt in einem bestimmten Zeitraum und das gesamte Team arbeitet daran. Fahren Sie dann mit einer neuen Iteration mit dem nächsten Projekt fort, wenn diese Iteration abgeschlossen ist? Oder gibt es eine "agile" Möglichkeit, mehrere Projekte mit eigenen Iterationen mit nur einem Team gleichzeitig zu verwalten?

87
Tim Knight

Scrum schreibt wirklich nicht vor, dass Sie an einem in sich abgeschlossenen Produkt arbeiten müssen. Es wird lediglich angegeben, dass einige Dinge erledigt werden müssen (das Produkt-Backlog), dass in der nächsten Iteration eine bestimmte Zeit für die Entwicklung zur Verfügung steht (berechnet aus der Projektgeschwindigkeit) und dass vom Kunden ausgewählte Elemente vorhanden sind/business hat aus diesem Pool von Problemen/Aufgaben, die in der nächsten Iteration erledigt werden (dem Sprint-Backlog), die höchste Priorität.

Es gibt keinen Grund, warum das Produkt- und das Sprint-Backlog aus einem Projekt stammen müssen - selbst in einem einzelnen Projekt gibt es separate Arbeitseinheiten, die wie separate Projekte aussehen - die Benutzeroberfläche, die Business-Schicht, das Datenbankschema usw. Insbesondere bei der Entwicklung von Unternehmenssoftware gibt es eine Reihe von Codebasen, die alle weiterentwickelt werden müssen. Der Scrum-Prozess - Besprechungen, Fragen, Burndown-Diagramm usw. - funktioniert unabhängig davon, ob es sich um ein oder mehrere Projekte handelt.

In der Praxis ist es jedoch häufig sinnvoll, für jede Iteration ein Hauptthema festzulegen - "Berichterstellungsmodul ausführen" oder "Schnittstelle zur API des XYZ-Systems" -, damit viele Probleme aus einem Projekt oder Bereich und auf der einen Seite auftreten Am Ende der Iteration können Sie auf eine große Menge von Arbeiten verweisen und ein Häkchen dagegen setzen.

59
Chris Latta

Ich denke, die Antwort hängt von "wer wird die Backlog-Elemente priorisieren" ab (d. H. Entscheiden, was zuerst getan werden muss). Wenn es sich um eine einzelne Person handelt, ist diese Person der Product Owner für Ihre Projekte. Sie können über einen einzelnen Rückstand verfügen, der alle Elemente für alle Projekte oder einen Rückstand pro Projekt enthält, und Sie wählen die Rückstandselemente aus allen Projekten aus, wenn Sie planen ein Sprint. In diesem Fall funktioniert Scrum einwandfrei.

Wenn jedes Projekt seinen Verantwortlichen hat, werden Sie wahrscheinlich auf einige Probleme stoßen, bei denen jeder Verantwortliche - mehr oder weniger bewusst - versucht, sein (e) Projekt (e) zu favorisieren. IMHO, Sie müssen nur einen Product Owner haben, der befugt ist, die Prioritäten durch Schiedsverfahren zu regeln.

Eine Regel, die in einem solchen Kontext befolgt werden muss, ist: Ändere niemals den Sprint-Inhalt während des Sprints. Bei Bedarf können Sie die Iteration auf zwei oder drei Wochen verkürzen, um das Risiko zu verringern, dass Sie dem aktuellen Sprint ein dringendes Element hinzufügen müssen.

25
philant

Ich muss nicht zustimmen. Ich denke, es ist der Schlüssel zu diesem Prozess, wenn sich ein Team während eines Sprints auf ein einzelnes Projekt konzentriert. Wenn Sie Spezialisten haben, die nicht zum gesamten Entwicklungsprozess beitragen können (Autoren von Inhalten, Grafiker, Geschäftsprozessanalysten usw.), würde ich sie aus dem Team entfernen, wenn sie nicht mehr beitragen können. Oder noch besser, lassen Sie sie auf einige verschiedene Aufgaben vorbereiten, damit sie zum Beispiel zum Testen beitragen können.

Eine andere Sache, die Sie im Hinterkopf behalten sollten, ist, dass das parallele Ausführen von Projekten Ihren Zeitplan zerstört. Bedenken Sie Folgendes: Nehmen wir der Einfachheit halber an, wir haben 5 Projekte mit demselben Team und beginnen am selben Datum. Für jedes Projekt sind 3 Monate Aufwand erforderlich. Im besten Fall werden alle Projekte gleichzeitig ausgeführt, und es dauert 15 Monate. Ihre Geschwindigkeit wird gestaucht, weil Sie nur 1/5 eines Monats Anstrengung in einen einzelnen Sprint passen können. Sie werden auch 5 Demo-Meetings gleichzeitig durchführen. Im besten Fall liefern Sie also Ihre 5 Projekte in 15 Monaten aus, und Ihre Konkurrenz behauptet, sie könnten in 3 dieselbe Arbeit leisten. Ihre Teams, die die Reife schätzen, werden darunter leiden, weil sie nur 20% ihrer verfügbaren Arbeitskräfte berücksichtigen können. Möglicherweise stellen Sie fest, dass Sie einige Aufgaben in einem einzelnen Sprint nicht ausführen können. Wenn Sie die Anzahl der Projekte, an denen gearbeitet wird, von 5 ändern müssen, muss Ihr Team die Schätzgewohnheiten anpassen, wodurch die Effizienz des Teams beeinträchtigt wird. Darüber hinaus fällt es Ihrem Team schwer, sich selbst zu organisieren, wenn für eine einfache Neuzuweisung von Aufgaben möglicherweise eine neue Entwicklungsumgebung hochgefahren werden muss, bevor mit der Arbeit begonnen werden kann.

Wenn Sie die gleichen 5 Projekte nacheinander ausführen würden, würden Sie das 5. Projekt in den gleichen 15 Monaten liefern, aber Sie hätten Ihren Kunden darüber informiert, dass Ihr Team so gefragt ist, dass Sie einen Rückstand von 12 Monaten haben und diesen nutzen können diese Zeit, um Ihre Projektziele zu verfeinern. Oder wenn Sie einen konstanten Rückstand haben, wissen Sie, dass es Zeit ist, ein anderes Team einzustellen. Ihr bestes Projekt ist jedoch in 3 Monaten mit einem Kunden abgeschlossen, der in der aktiven Zeit schnelle Verbesserungen erfahren hat. Sie können das Projekt ein Jahr früher abschließen und es in Ihren Lebenslauf aufnehmen. Ihre Sprint-Geschwindigkeit wird sich über diesen Zeitraum stabilisieren und Sie werden feststellen, dass Sie nach ein oder zwei Projekten einen großen Schritt nach vorne machen und in einem bestimmten Sprint mehr erreichen können.

Ich denke, die serielle Ausführung von Projekten ist eine der größten Hürden für Unternehmen, die versuchen, Scrum Faces einzuführen. Es ist ein großer kultureller Wandel, der mit der Dekonstruktion der Projektleiterrolle verbunden ist, aber der Nutzen für den Scrum-Prozess ist enorm.

Denken Sie daran, dass JEDER kein vollwertiges Teammitglied sein muss. Sie können Ihren Kunden in den Wartesaal einbeziehen und sich auf den Entwicklungsprozess vorbereiten. Ich behalte meine Business Analysten, Netzwerkarchitekten und Grafikdesigner als Domain-Experten und ordne sie nur bei Bedarf einem Team zu. Lassen Sie sie mit Sprint 0 rennen. Sie werden überrascht sein, wie engagiert die Arbeit an Look & Feel und Workflow ist. Es ist auch gut, Ihre Kunden darauf vorzubereiten, dass wenn die Entwicklung ernsthaft beginnt, der Grad ihrer Teilnahme tatsächlich steigen kann und dass es wichtig ist, dass sie verfügbar sind. Teilen Sie ihnen den Zeitplan mit, damit sie genügend Zeit haben, sich frühzeitig mit Urlaub und Ferien zu befassen.

15
anopres

Ich war in genau dieser Situation.

Wenn Sie projektübergreifend einen Product Owner haben, ist Phillipe absolut richtig. Ein Sprint mit einem Team sollte gut funktionieren.

Wenn Sie mehr als einen Produktbesitzer haben, muss die Geschäftsseite im Idealfall einen einzigen "Priorisierer" auswählen, der die Verantwortung für die Planung der Arbeit trägt. Dies ist definitiv die beste Lösung.

Wenn das Unternehmen (wie es wahrscheinlich der Fall ist) nicht ändern möchte, wie Prioritäten gesetzt werden sollen (das wäre viel zu praktisch), können Sie das Team aufteilen und zwei Sprints gleichzeitig ausführen. Bei einem Sechserteam würde ich es jedoch nicht in mehr als drei Teams aufteilen (ich würde es überhaupt nicht aufteilen wollen, aber ich denke, 2-3 Teams wären praktikabel). Eine weitere Aufteilung, wie Kenny vorschlägt, und das Vorhandensein von Teams aus einer Person erscheint mir etwas sinnlos, da Sie dann kein Team mehr haben, sondern nur einzelne Programmierer.

Wenn Sie das Team aufteilen, habe ich nicht viel Wert darauf gelegt, die Stand-Ups zusammenzuführen, es sei denn, Sie haben separate Sprints, die an sehr viel derselben Codebasis arbeiten, aber dann könnte dies ein Argument sein, um diese Teams zum Zweck der Zusammenführung zusammenzuführen der Sprint.

8
DanSingerman

Es gibt eine andere Meinung, über die ich in letzter Zeit gelesen habe, nämlich dass in einer agilen Umgebung das Konzept von Projekt kontraproduktiv sein könnte und beseitigt werden könnte. Nach dieser Denkrichtung sollte sich die Organisation stattdessen auf Releases konzentrieren. Dies liegt daran, dass Projekte künstliche Schachteln von Arbeit sind, die erst dann einen Wert erzeugen, wenn sie abgeschlossen sind. Sie stehen im Widerspruch zu Agiles Ziel, häufig versandfähigen Wert zu liefern. Ein Release steht eher im Einklang mit Agile, da es darauf ausgerichtet ist, Mehrwert zu liefern, und weil sein Umfang auf der Grundlage dessen, was Teams vor dem Release liefern können, reduziert oder erweitert werden kann nächstes Release .

Es gibt einen potenziellen Mittelweg, in dem das, was früher in Ihrem Unternehmen als Projekt bezeichnet wurde, jetzt als gemeinsames agiles Thema umgepackt wird oder Feature. Der Vorteil dieses Ansatzes ist, dass das Theme oder Feature nun sein kann in Wertstücken umgesetzt, wie es der Product Owner für richtig hält.

Es ist immer noch die Frage eines Teams, das an mehreren Produkten arbeitet, und es ist eine Frage, weil berechtigte Bedenken hinsichtlich des Domänenwissens und möglicher technischer Fähigkeiten bestehen. Aber Produkte , die mit Agile erstellt wurden, auch mehrere Produkte , die von einem einzigen Team erstellt wurden , akkumulieren ständig Release - fähigen Wert. Im Gegensatz dazu sind Projekte nichts wert, bis sie abgeschlossen sind (und viele nicht).

Etwas zum Nachdenken...

5
Bob Lieberman

Ich denke, Anopres hatte Recht: Der beste Weg ist, mehrere Projekte gleichzeitig mit Scrum zu vermeiden. Tun Sie alles, um sich zu vergewissern, dass zu viel Parallelbetrieb nicht effizient ist.

Nehmen wir für ein Team mit 5 Personen jeweils 5 Projekte von ca. 3 Monaten an.

Ansatz 1: Jede Person arbeitet an einem einzelnen Projekt im Team

  • 1/5 Liefergeschwindigkeit pro Projekt ergibt für alle Projekte eine Lieferzeit von 15 Monaten
  • Jeder Einzelne ist Experte, aber nur in seinem eigenen Projekt
  • Kein Teamgeist

Ansatz 2: 1 Sprint pro Projekt, Projektwechsel

  • Jeder 6. Sprint arbeitet am Projekt
  • Zu lange Zeit zwischen den Projektarbeiten - kein regelmäßiger inkrementeller Wert für das Projekt (für den Produktbestand ja), leicht zu vergessen, Aufwand für die Wiederherstellung des Kontexts erforderlich,
  • Erstes Projekt nach ca. 12-13 Monaten geliefert (vorausgesetzt 2 Wochen Sprint)

Ansatz 3: 5 Projekte im Einzelsprint

  • Erfordert eine zu detaillierte Aufgabenteilung, um in den Sprint zu passen
  • Sehr wenig inkrementeller Build pro Projekt
  • Lieferung des ersten Projektes nach ca. 12-15 Monaten

Ansatz 4: empfohlen - Serialisierte Arbeit

  • Team arbeitet an einem Projekt nach dem anderen
  • Erstes Projekt gestartet und nach 3 Monaten ausgeliefert
  • Das zweite Projekt begann nach dem 3. Monat und wurde nach dem 6. Monat fertiggestellt
  • ...
  • Das fünfte Projekt wurde nach dem 12. Monat gestartet und nach dem 15. Monat fertiggestellt
  • Team sehr fokussiert auf Projekt, intensive Recherche und Zusammenarbeit mit Kunden
  • Das gesamte Team hat allgemein gute Kenntnisse über alle Projekte
  • Keine Zeitverschwendung beim Kontextwechsel
  • Gute Teamzusammenarbeit erfordern (Konflikte können die Bereitstellung verlangsamen).

Wie Sie sehen, ist Lösung 4 im Allgemeinen besser, da Projekte viel schneller geliefert werden, das Team zusammenarbeitet und effizient arbeitet. Andere Ansätze beinhalten Zeitverschwendung durch Kontextwechsel, keine vollständige Teamzusammenarbeit, sehr lange Gesamtlieferzeiten aller Projekte usw.

Und wie steht es mit dem Backlog-Grooming? Wenn ein Team auf einmal an einem Projekt arbeitet, ist das einfach - jeder wird mitmachen. Wenn es mehrere Projekte gibt, müssen wir möglicherweise einzelne Personen an separate Pflegesitzungen delegieren (nicht das gesamte Team ist beteiligt).

Es ist wichtig, die Kunden davon zu überzeugen, dass der Start des zweiten Projekts nach 3 Monaten zu einer schnelleren Lieferung (nach 6 Monaten) führt, als wenn wir es sofort mit allen anderen beginnen. Es ist eine Illusion, die Manager sehen - wir starten 5 Projekte auf einmal, wir arbeiten hart und liefern nach und nach. Am Ende ist dies jedoch nicht effizient.

Aus diesem Grund glaube ich nicht, dass Scrum für mehrere Projekte gleichzeitig effizient ist. Es ist sehr schwierig, es in ein Framework einzubinden und nach Scrum-Regeln zu arbeiten. Manchmal mag es gut sein, 2 Projekte zu haben, um alle Leute zu beschäftigen, aber je mehr Projekte wir hinzufügen, desto weniger effizient wird das Gedränge sein. Vielleicht ist Kanban eine Alternative, um nur den Fortschritt und die Teamarbeit zu sehen (nicht so stark wie im Scrum-Team)?

Grüße, Adam

4
Adam Krawczyk

Wie @Chris sagte, enthält ein normales Projekt Unterprojekte. Sie haben jedoch nur einen Rückstand.

Denken Sie an einen Rückstand bei all Ihren Projekten. Erstes Problem: Weisen Sie Aufgaben oder Projekten Prioritäten zu? Ich bevorzuge einen Rückstand pro Projekt. Zumindest, um die Prioritäten des Produktbesitzers zu klären.

Unterschiedliche Produktverantwortliche haben und aufgrund der Tatsache, dass sich diese Produktverantwortlichen nicht darauf einigen werden, wie viel Zeit sie jedem Projekt widmen sollen. "Jemand" wird die Entscheidung über die Verwaltung der Interprojektprioritäten auf sich nehmen müssen. Hinweis: Entwickler sollten das nicht tun.

Hier kommt unser Projekt "S" -Manager, der die Ressourcen, die Produktbesitzer benötigen, und die Zeit, die Mitglieder des Teams zur Verfügung stellen können, ausbalanciert. Product Owner A hat einen Monat Arbeit bezahlt, aber Product Owner B aktualisiert sein Projekt immer (und bezahlt Sie auch gut). So können Sie Ihr Team so ausbalancieren, dass A einen Monat (Entwicklerzeit) hat und B nicht daran hindert, Ihre Taschen zu füllen.

Bei interner Software (ein Unternehmen, tausend Projekte). Die verschiedenen Produktbesitzer sollten sich auf die ihnen zur Verfügung stehende Zeit einigen. Sie leben nicht isoliert, sondern im selben Boot wie Sie (Projektleiter "S"). Sie werden es Ihnen leichter machen, einige Aufgaben zu verschieben, aber gleichzeitig sollten Sie niemals ihre Bedürfnisse vergessen.

Nun, ich versuche immer noch herauszufinden, wie ich das am besten machen kann. Aber das ist es, worauf wir gerade drängen. Ich hoffe, es hilft.

3
graffic

Teammitglieder können ihre Zeit zwischen Scrum-Projekten aufteilen, aber es ist viel produktiver, wenn sich die Teammitglieder voll und ganz engagieren. Teammitglieder können auch von einem Sprint zum nächsten wechseln, was jedoch auch die Produktivität des Teams verringert. Projekte mit größeren Teams sind als mehrere Scrums organisiert, die sich jeweils auf einen anderen Aspekt der Produktentwicklung konzentrieren und ihre Bemühungen eng koordinieren.

Ich würde vorschlagen, einen Sprint für jedes Projekt durchzuführen und ein tägliches Stand-up-Meeting abzuhalten, um alle aktiven Quellen/Projekte abzuwickeln.

0
kenny

Ich würde gerne dazu beitragen. So mache ich es:

  • Es gibt einen Product Owner und einen Product Backlog pro Team. Der Product Owner muss nicht eine einzige Person sein, aber diese Product Owner- "Entität" ist für den Product Backlog verantwortlich.
  • Das Product Backlog enthält die User Stories aller Projekte (alle Projekte hier). Jede User Story hat einen Aufwand/Story-Punkte (Teamverantwortung) und einen Geschäftswert (Produktverantwortung).
  • Wir haben einen "Product Backlog Grooming", der jeden Sprint erfüllt. Vor dieser Besprechung hat der Product Owner die Geschäftswerte der Storys aktualisiert (falls sie aus irgendeinem geschäftlichen Grund geändert werden müssen - das ist uns egal -) und einige neue Storys hinzugefügt. In diesem Meeting werden die neuen Geschichten erklärt und die Bemühungen ebenfalls aktualisiert. Dieses Treffen dauert ungefähr eine Stunde (außer beim ersten Mal ungefähr 4 Stunden).
  • Wenn wir einen neuen Sprint planen, öffnen wir das Product Backlog, ordnen die Storys nach ROI (dies ist geschäftlicher Wert/Aufwand) und planen Storys, bis die Zeit abgelaufen ist.

Und das ist es. Ich kann sagen, das funktioniert ganz gut. Dazu verwenden wir ein paar Google - Tabellen (das Product - Backlog und das Sprint - Backlog, beide mit Diagrammen und Dingen) und Redmine (mit einer bestimmten Semantik) für eine Online - Organisation jeden Tag: Zeit, Aufgabenfortschritt usw

Das Problem bei diesem Ansatz ist, dass ich die Aufgaben in der Sprint-Backlog-Tabelle und in Redmine dupliziert habe. Aber ich finde kein Online-Tool, um dies vollständig online zu tun. Ich vermisse einen Product Backlog in Redmine (keine anderen semantischen Arbeiten für mich), ein einzelnes Board in Jira, mehr Geschichten in der Taiga usw.

0
hosseio