Wie funktioniert Scrum, wenn Sie mehrere Projekte haben? [geschlossen]


91

Ich bin ziemlich gut in den Vorteilen und Prozessen von Scrum gelesen. Ich bekomme die Ideen zum Backlog, zu Burndown-Diagrammen, Iterationen, unter Verwendung 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 einer bestimmten Zeit und das gesamte Team arbeitet daran. Wenn diese Iteration abgeschlossen ist, fahren Sie mit einer neuen Iteration mit dem nächsten Projekt fort. Oder gibt es eine "agile" Möglichkeit, mehrere Projekte mit eigenen Iterationen mit nur einem Team gleichzeitig zu verwalten?


9
Ich wünschte ich wüsste es, ich bin an 3+ Projekten und muss 3+ SCRUMS pro Tag machen. : cry:
Chad Grant

Diese Frage ist nicht zum Thema gehörend, da sie nicht in den Geltungsbereich dieser Website fällt, wie unter Welche Themen kann ich hier fragen? Siehe auch: Welche Arten von Fragen sollte ich vermeiden? Möglicherweise können Sie auf einer anderen Stack Exchange-Site nachfragen , z. B. Projektmanagement oder Software-Engineering . Lesen Sie unbedingt die Themenseite in der Hilfe für jede Site, auf der Sie eine Frage stellen möchten.
Makyen

3
@Makyen Eine Sache, die hier berücksichtigt werden muss, ist, dass diese Frage erfolgreich 8,5 Jahre alt ist und lange bevor die meisten Sub-Stack-Börsen existierten. Während das Thema jetzt am besten von so etwas wie dem Project Management Stack Exchange bedient werden kann, war zu der Zeit eine Frage zu den Praktiken von Scrum für Entwickler und ihre Methoden unglaublich relevant, wie die Arbeit am besten erledigt werden kann.
Tim Knight

Ich stimme zu, es war zum Zeitpunkt der Anfrage vernünftig. An der Frage als Frage ist nichts auszusetzen. Es ist derzeit einfach nicht zum Thema für SO. Was für SO zum Thema gehört, hat sich im Laufe der Zeit geändert. Während diese Frage für Programmierer von Interesse ist, geht es nicht in erster Linie um Programmierung. Es geht um den Scrum-Prozess, eine Methode zum Verwalten von Projekten, nicht zum spezifischen Programmieren. Es geht darum, "mehrere Projekte zu verwalten ... mit nur einem Team ...", was eine Vielzahl von Projekttypen sein kann. Daher ist es angebracht, es zu schließen. Ich würde nicht dafür stimmen, es zu löschen, da es hier nützliche Informationen gibt.
Makyen

2
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es um organisatorische Praktiken geht, nicht um Programmierung.
Kristján

Antworten:


61

Scrum schreibt wirklich nicht vor, dass Sie an einem in sich geschlossenen Produkt arbeiten müssen. Es wird lediglich angegeben, dass eine Reihe von Aufgaben erledigt werden müssen (das Produkt-Backlog), dass in der nächsten Iteration eine bestimmte Entwicklungszeit verfügbar ist (aus der Projektgeschwindigkeit herausgearbeitet) und dass vom Kunden ausgewählte Elemente vorhanden sind / business hat aus diesem Pool von Problemen / Aufgaben, die in der nächsten Iteration (dem Sprint-Backlog) ausgeführt werden, die höchste Priorität.

Es gibt keinen Grund, warum das Produkt-Backlog und das Sprint-Backlog aus einem Projekt stammen müssen - selbst in einem einzelnen Projekt gibt es diskrete Arbeitseinheiten, die wie separate Projekte aussehen - die Benutzeroberfläche, die Geschäftsschicht, das Datenbankschema usw. Insbesondere die Entwicklung von Unternehmenssoftware sieht so aus, dass Sie über eine Reihe von Codebasen verfügen, die alle weiterentwickelt werden müssen. Der Scrum-Prozess - Besprechungen, Fragen, Burn-Down-Diagramme usw. - funktioniert unabhängig davon, ob es sich um ein Projekt oder mehrere handelt.

In der Praxis ist es jedoch oft gut, wenn jede Iteration ein Hauptthema hat - "Do the Reporting Module" oder "Interface mit der API des XYZ-Systems" -, sodass viele der Probleme aus einem Projekt oder Bereich und aus dem Bereich stammen Am Ende der Iteration können Sie auf eine große Anzahl von Arbeiten zeigen und ein Häkchen dagegen setzen.


4
+1: Scrums Essenz ist das tägliche Stand-up-Meeting zur Koordinierung der Aktivitäten. Funktioniert für einzelne oder mehrere Projekte.
S.Lott

4
Ich bin mit S.Lott nicht einverstanden, ich denke, die Essenz ist der Sprint und das Stand-up-Meeting ist ein Werkzeug, um den Sprint zu verwalten. Ich würde 6 Sprints oder 1 pro Projekt laufen.
Kenny

@Kenny: Wenn es nicht unbedingt notwendig ist, würden Sie auf ein tägliches Aufstehen für jedes einzelne Projekt verzichten? Wenn ja, was tun Sie, um den Sprint jedes Projekts auf Kurs zu halten?
S.Lott

1
@ S.Lott, das Treffen ist für Probleme, wenn sie auftreten. Ich hätte einen für das ganze Team. Es tut nicht weh, auf dem Laufenden zu bleiben, und andere / neue Sichtweisen können oft wertvoll sein.
Kenny

Was ist mit 3 Projekten, 3 Teammitgliedern, die jeweils eine eigene Codebasis für verschiedene Produktbesitzer entwickeln? In diesem Fall gibt es 3 Teams?
jolySoft

25

Ich denke, die Antwort hängt davon ab, " wer die Backlog-Elemente priorisieren wird " (dh zu 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 einen einzigen Rückstand für alle Elemente für alle Projekte haben - oder einen Rückstand pro Projekt - 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 seine Verantwortung hat, werden Sie wahrscheinlich auf einige Probleme stoßen, bei denen jeder Verantwortliche - mehr oder weniger bewusst - versucht, seine Projekte zu bevorzugen. Meiner Meinung nach benötigen Sie nur einen Product Owner, der befugt ist, die Prioritäten durch Schiedsverfahren festzulegen.

Eine Regel, die in einem solchen Kontext befolgt werden muss, ist, den Sprint-Inhalt während des Sprints niemals zu ändern . 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.


16

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

Eine andere Sache, die Sie beachten sollten, ist, dass das parallele Ausführen von Projekten Ihren Zeitplan beeinträchtigt. Bedenken Sie Folgendes: Nehmen wir der Einfachheit halber an, wir haben 5 Projekte mit demselben Team und beginnen am selben Datum. Jedes Projekt benötigt 3 einmonatige Anstrengungen. Im besten Fall, wenn es parallel läuft, werden Sie alle auf einmal fertigstellen und es dauert 15 Monate. Ihre Geschwindigkeit wird cremig, weil Sie nur 1/5 eines Monats Anstrengung in einen einzigen Sprint bringen können. Sie werden auch 5 Demo-Meetings gleichzeitig durchführen. Im besten Fall liefern Sie Ihre 5 Projekte in 15 Monaten und Ihre Konkurrenz wird behaupten, dass sie in 3 die gleiche Arbeit leisten könnten. 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 können Sie einige Aufgaben nicht in einem einzigen Sprint ausführen. Wenn Sie die Anzahl der Projekte von 5 auf 5 ändern müssen, muss Ihr Team die Schätzgewohnheiten anpassen, was die Effizienz des Teams beeinträchtigt. 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 eingerichtet werden muss, bevor mit der Arbeit begonnen werden kann.

Wenn Sie dieselben 5 Projekte seriell ausführen würden, würden Sie das fünfte Projekt in denselben 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 während des aktiven Zeitraums schnelle Verbesserungen festgestellt hat. Sie können dieses Projekt ein Jahr früher abschließen und in Ihren Lebenslauf aufnehmen. Ihre Sprintgeschwindigkeit wird sich in diesem Zeitraum stabilisieren, und Sie werden möglicherweise feststellen, dass sie nach ein oder zwei Projekten ihren Schritt vollzieht und in einem bestimmten Sprint mehr erreichen kann.

Ich denke, dass das serielle Ausführen von Projekten eine der größten Hürden ist, die eine Organisation versucht, Scrum-Gesichter einzuführen. Es ist eine große kulturelle Veränderung, die mit der Dekonstruktion der Projektmanagerrolle verbunden ist, aber die Vorteile für den Scrum-Prozess sind enorm.

Denken Sie daran, dass JEDER kein vollwertiges Teammitglied sein muss. Sie können Ihren Kunden im Wartezimmer einbeziehen und sich auf den Entwicklungsprozess vorbereiten. Ich halte meine Business Analysten, Netzwerkarchitekten und Grafikdesigner als Domain-Experten und verbinde sie nur bei Bedarf mit einem Team. Lassen Sie sie mit Sprint 0 laufen. Sie wären überrascht, wie engagiert die Arbeit an Look & Feel und Workflow ist. Es ist auch gut, Ihren Kunden darauf vorzubereiten, dass zu Beginn der Entwicklung die Beteiligung tatsächlich steigen kann und es wichtig ist, dass er verfügbar ist. Lassen Sie sie den Zeitplan wissen, damit sie genügend Zeit haben, sich frühzeitig mit Dingen wie Urlaub und Ferien zu befassen.


Dies funktioniert nur, wenn Sie Teammitglieder neu zuweisen können. Wenn sie nirgendwo hingehen können, können Sie sie nicht untätig lassen.
BlueChippy

8

Ich war genau in dieser Situation.

Wenn Sie einen Produktbesitzer in den Projekten haben, ist Phillipe absolut korrekt. Ein Sprint mit einem Team sollte gut funktionieren.

Wenn Sie mehr als einen Product Owner haben, muss die Unternehmensseite im Idealfall einen einzigen "Priorizer" auswählen, der für die Planung der Arbeiten verantwortlich ist. Dies ist definitiv die beste Lösung.

Wenn das Unternehmen (wie es wahrscheinlich der Fall ist) nicht ändern möchte, wie es Prioritäten setzen möchte (das wäre viel zu bequem), können Sie das Team aufteilen und zwei Sprints gleichzeitig ausführen. Mit einem Team von sechs 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 Teams einer einzelnen Person zu haben, erscheint mir etwas sinnlos, da Sie dann kein Team mehr haben, sondern nur noch 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 einem Großteil derselben Codebasis arbeiten. Dies kann jedoch ein Argument für die Zusammenlegung dieser Teams sein der Sprint.


5

Es gibt eine andere Meinung, über die ich in letzter Zeit gelesen habe, nämlich dass in einer agilen Umgebung das Konzept des Projekts kontraproduktiv sein und beseitigt werden könnte. Nach dieser Denkweise sollte sich die Organisation stattdessen auf Releases konzentrieren. Dies liegt daran, dass Projekte künstliche Arbeitsboxen sind, die bis zu ihrem Abschluss keinen Wert produzieren. Sie stehen im Widerspruch zu Agiles Ziel, häufig einen versandfähigen Wert zu liefern. Ein Release entspricht eher Agile, da es auf die Bereitstellung von Wert ausgerichtet ist und weil sein Umfang je nachdem, was Teams vor dem nächsten Release liefern können, reduziert oder erweitert werden kann .

Es gibt einen potenziellen Mittelweg, in dem das, was früher in Ihrem Unternehmen als Projekt bezeichnet wurde, jetzt als gemeinsames agiles Thema oder Feature neu verpackt wird . Der Vorteil dieses Ansatzes besteht darin, dass das Thema oder die Funktion jetzt in Wertelementen implementiert werden kann, wie es der Product Owner für richtig hält.

Es gibt immer noch die Frage, ob ein Team an mehreren Produkten arbeitet , und dies ist eine Frage aufgrund berechtigter Bedenken hinsichtlich des Domänenwissens und möglicher technischer Fähigkeiten. Aber Produkte mit Agile gebaut, sogar mehr Produkte von einem einzigen Team aufgebaut, häufen sie ständig Veröffentlichung -able Wert. Im Gegensatz dazu sind Projekte nichts wert, bis sie abgeschlossen sind (und viele nicht).

Etwas zum Nachdenken...


1
Wir sind uns einig, dass wir den "Software-Bestand" minimieren sollten, bei dem es sich um einen akkumulierten Geschäftswert handelt, der noch nicht in Betrieb genommen wurde.
AndyM

4

Ich denke, Anopres hatte Recht: Der beste Weg ist, mehrere Projekte gleichzeitig mit Scrum zu vermeiden. Tun Sie alles, um zu überzeugen, dass es nicht effizient ist, zu viel parallel zu laufen.

Nehmen wir 5 Projekte alle ca. 3 Monate für ein Team mit 5 Personen an.

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

  • Eine Liefergeschwindigkeit von 1/5 pro Projekt ergibt eine Lieferzeit von 15 Monaten für alle Projekte
  • Jede einzelne Person ist Experte, aber nur in einem eigenen Projekt
  • Kein Teamgeist

Ansatz 2: 1 Sprint pro Projekt, Projektwechsel

  • Jeder 6. Sprint arbeitet am Projekt
  • Zu lange Zeit zwischen den Projektarbeiten - kein regulärer inkrementeller Wert für das Projekt (für Product Backlog ja), leicht zu vergessen, Aufwand zur Wiederherstellung des Kontexts erforderlich,
  • Erstes Projekt nach ca. 12-13 Monaten (unter der Annahme eines 2-wöchigen Sprints)

Ansatz 3: 5 Projekte im Einzelsprint

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

Ansatz 4: empfohlen - Serialisierte Arbeit

  • Das Team arbeitet an einem Projekt nach dem anderen
  • Erstes Projekt gestartet und nach 3 Monaten geliefert
  • Das zweite Projekt begann nach dem 3. Monat und wurde nach dem 6. Monat geliefert
  • ...
  • Das fünfte Projekt begann nach dem 12. Monat und wurde nach dem 15. Monat geliefert
  • Das Team konzentrierte sich stark auf das Projekt, die intensive Forschung und die Zusammenarbeit mit dem Kunden
  • Das gesamte Team verfügt über allgemein gute Kenntnisse über alle Projekte
  • Keine Zeitverschwendung beim Kontextwechsel
  • Gute Teamzusammenarbeit erforderlich (Konflikte können die Lieferung verlangsamen).

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

Und was ist mit der Rückstandspflege? Wenn das Team gleichzeitig an einem einzelnen Projekt arbeitet, ist das einfach - jeder wird beitreten. Wenn es mehrere Projekte gibt, müssen wir möglicherweise einzelne Personen an separate Pflegesitzungen delegieren (es ist nicht das gesamte Team beteiligt).

Es ist wichtig, die Kunden davon zu überzeugen, dass der Start des zweiten Projekts nach 3 Monaten immer noch zu einer schnelleren Lieferung (nach dem 6. Monat) führt, als wenn wir es sofort mit allen anderen starten. Es ist eine Illusion, die Manager sehen - wir starten 5 Projekte gleichzeitig, 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 zu integrieren und nach Scrum-Regeln zu arbeiten. Manchmal mag es gut sein, zwei Projekte zu haben, um alle Leute zu beschäftigen, aber je mehr Projekte wir hinzufügen, desto weniger effizient ist Scrum. Vielleicht ist Kanban eine Alternative, nur um den Fortschritt und die Teamarbeit zu sehen (nicht so stark wie im Scrum-Team)?

Grüße, Adam


3

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

Denken Sie in einem Rückstand mit 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 klar zu machen.

Unterschiedliche Produktbesitzer haben und aufgrund der Tatsache, dass diese Produktbesitzer sich nicht darauf einigen werden, wie viel Zeit sie für jedes Projekt geben sollen. "Jemand" muss die Entscheidung über die Verwaltung der Interprojektprioritäten auf sich nehmen. Hinweis: Entwickler sollten dies 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, in Einklang bringt. Produktbesitzer A hat für einen Monat Arbeit bezahlt, aber Produktbesitzer B aktualisiert ständig sein Projekt (und bezahlt Sie auch gut). Es gibt einige Möglichkeiten, wie Sie Ihr Team so ausbalancieren können, dass A einen Monat Zeit hat (Entwicklerzeit), 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 gegebene Zeit einigen. Sie leben nicht isoliert, sondern im selben Boot wie Sie (Projektmanager "S"). Sie werden es Ihnen leichter machen, einige Aufgaben zu verschieben, aber gleichzeitig sollten Sie ihre Bedürfnisse niemals vergessen.

Nun, ich versuche immer noch herauszufinden, wie ich das am besten machen kann. Aber das ist es, was wir gerade vorantreiben. Ich hoffe, es hilft.


3

Teammitglieder können ihre Zeit zwischen Scrum-Projekten aufteilen, aber es ist viel produktiver, wenn die Teammitglieder voll engagiert sind. 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 deren Bemühungen eng koordinieren.


0

Ich würde vorschlagen, einen Sprint für jedes Projekt durchzuführen und 1 tägliches Standup-Meeting abzuhalten, um alle aktiven Quellen / Projekte zu bearbeiten.


Kenny also jeweils einen Sprint für jedes Projekt? Oder redest du davon, mehrere Sprints gleichzeitig zu laufen und das Team zu teilen, wie es andere vorschlagen?
Tim Knight

Hey Tim, ich habe mir vorgestellt , dass Sie Ihre Teamstruktur nicht ändern, indem Sie Teams in Sprints aufteilen, sondern für jedes Projekt separate Sprints / Backlogs / etc ... ausführen. Lassen Sie bei jedem Aufstehen jede Person kommentieren, worüber sie sich Sorgen macht. Für mich wäre es schön, über alle / alles auf dem Laufenden zu bleiben oder sich dessen bewusst zu sein.
Kenny

0

Ich möchte dazu beitragen. So mache ich das:

  • Pro Team gibt es einen Product Owner und einen Product Backlog. Der Product Owner muss nicht eine einzelne Person sein, aber diese "Entität" des Product Owners ist für den Product Backlog verantwortlich.
  • Das Product Backlog enthält die User Stories jedes Projekts (alle Projekte hier). Jede User Story hat einen Aufwand / Story Points (Teamverantwortung) und einen Geschäftswert (Product Owner Responsibility).
  • Wir haben ein "Product Backlog Grooming", das jeden Sprint erfüllt. Vor diesem Treffen 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 sollte uns nicht interessieren) und einige neue Storys hinzugefügt. In diesem Treffen 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 Produkt-Backlog, ordnen die Storys nach ROI (dies ist der geschäftliche Wert / Aufwand) und planen Storys, bis die Zeit abgelaufen ist.

Und das ist es. Ich kann sagen, dass das ziemlich gut funktioniert. Wir verwenden dazu ein paar Google-Tabellen (das Product Backlog und das Sprint Backlog, beide mit Diagrammen und anderen 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 dupliziert und redmine habe. Aber ich finde kein Online-Tool, um dies vollständig online zu tun. Ich vermisse einen Product Backlog in Redmine (keine andere semantische Arbeit für mich), ein einzelnes Board in Jira, mehr Geschichten in Taiga usw.


Wie konzentrieren Sie sich auf jedes Produkt in einem Rückstand? Tags, Namenskonvention usw.? Ich habe einen ähnlichen Ansatz implementiert, aber versucht, alles in TFS zu behalten, und noch keine gute Lösung gefunden, um sowohl Rückstands- als auch Produktansichten der Features / Stories zu ermöglichen.
BlueChippy
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.