Scrum (Softwareentwicklung)

Gedränge oder GEDRÄNGE, ist ein Rahmen für das Projektmanagement,^[1] mit einer anfänglichen Betonung auf Software-Entwicklung, obwohl es in anderen Bereichen wie Forschung, Vertrieb, Marketing und verwendet wurde fortgeschrittene Technologien.^[2] Es ist für Teams von zehn oder weniger Mitgliedern konzipiert, die ihre Arbeit unterbrechen Tore das kann innerhalb von Zeitbox-Iterationen abgeschlossen werden, genannt Sprints, nicht länger als einen Monat und am häufigsten zwei Wochen. Das Scrum -Team bewertet den Fortschritt in zeitlich tägliche Besprechungen von 15 Minuten oder weniger, Daily Scrums (eine Form von Stand-up-Meeting). Am Ende des Sprint hält das Team zwei weitere Treffen ab: die Sprint -Bewertung, die die geleisteten Arbeiten demonstriert Stakeholder Feedback ausführen, und Sprint Retrospektive Dies ermöglicht es dem Team, nachzudenken und zu verbessern.

Name

Der Begriff Gedränge wird ausgeliehen von Rugby, wo es eine Bildung von Spielern ist. Der Begriff Gedränge wurde von den Autoren der Zeitung ausgewählt, weil es die Teamarbeit betont.^[4]Der Begriff der Softwareentwicklung Gedränge wurde erstmals in einer Arbeit von 1986 mit dem Titel "The New Product Development Game" von verwendet Hirotaka Takeuchi und Ikujiro Nonaka.^[5][6] Das Papier wurde in der Januar -Ausgabe von 1986 veröffentlicht Harvard Business Review.

Gedränge wird gelegentlich in All-Capitals wie geschrieben, wie GEDRÄNGE.^[7] Während das Wort selbst keiner ist Akronym, sein aktiviertes Styling stammt wahrscheinlich aus einem frühen Papier von Ken Schwaber^[8] das kapitalisierte GEDRÄNGE in seinem Titel.^[9][10]

Während Warenzeichen auf dem Begriff Gedränge selbst durfte verfallen, es wird jetzt als als als er angesehen Generisches Markenzeichen Im Besitz der breiteren Gemeinschaft und nicht einer Person.^[11]

Schlüsselideen

Scrum ist ein leichtes Gewicht, iterativ und inkrementell Rahmen für die Entwicklung, Bereitstellung und Aufrechterhaltung komplexer Produkte.^[12][13] Das Framework stellt die Annahmen des traditionellen, sequentiellen Ansatzes zur Produktentwicklung heraus und ermöglicht es den Teams, sich selbst zu organisieren, indem sie die physische Förderung ermutigen Co-Lokation Oder eine enge Online-Zusammenarbeit aller Teammitglieder sowie die tägliche persönliche Kommunikation zwischen allen Teammitgliedern und Disziplinen.

Ein wichtiges Prinzip von Scrum ist die doppelte Anerkennung, dass Kunden den Umfang dessen ändern werden, was gewünscht wird (oft genannt Anforderungen Volatilität^[14]) und dass es unvorhersehbare Herausforderungen geben wird - für die ein prädiktiver oder geplanter Ansatz nicht geeignet ist. Diese Veränderungen stammen aus einer Vielzahl von Quellen, aber laut Scrum ist es irrelevant zu verstehen, warum es irrelevant ist, und Veränderungen sollten einfach akzeptiert, angenommen und auf Vorteile analysiert werden.

Geschichte

Hirotaka Takeuchi und Ikujiro Nonaka stellten den Begriff vor Gedränge im Zusammenhang mit Produktentwicklung in ihrem 1986 Harvard Business Review Artikel "The New Product Development Game".^[15] Takeuchi und Nonaka stritten sich später in Das Wissen erstellt Unternehmen^[16] Dass es eine Form der "organisatorischen Wissensschöpfung, [...] besonders gut darin ist, kontinuierlich, inkrementell und spiralisch innovativ zu sein".

Die Autoren beschrieben einen neuen Ansatz für die Entwicklung kommerzieller Produkte, der die Geschwindigkeit und Flexibilität erhöhen würde, basierend auf Fallstudien von Herstellungsunternehmen im Automobil, Fotokopierer und Drucker Branchen.^[15] Sie nannten das das ganzheitlich oder Rugby Ansatz, da der gesamte Prozess von einem durchgeführt wird funktionsübergreifende Team In mehreren überlappenden Phasen, in denen das Team "versucht, die Distanz als Einheit zu gehen und den Ball hin und her zu übergeben".^[15] (Im Rugby Fußball, a Gedränge wird verwendet, um das Spiel neu zu starten, da die Stürmer jedes Teams mit dem Kopf nach unten zusammenarbeiten und versuchen, den Ball in Besitz zu nehmen.^[17]))

Das Scrum -Framework basierte auf der Forschung von Schwaber mit Babatunde Ogunnaike an der Dupont Research Station und der University of Delaware.^[9] Ogunnaike riet, dass Versuche, komplexe Produkte wie Software zu entwickeln, die nicht auf dem Empirismus basierten, zu höheren Risiken und Versagensraten bei der Änderung der Anfangsbedingungen und Annahmen verurteilt seien. Der Empirismus unter Verwendung häufiger Inspektion und Anpassung mit Flexibilität und Transparenz ist der am besten geeignete Ansatz.

Anfang der neunziger Jahre,, Ken Schwaber benutzte das, was in seinem Unternehmen, Advanced Development Methods, zu Scrum werden würde; während Jeff Sutherland, John Scumniotales und Jeff McKenna entwickelten einen ähnlichen Ansatz bei der Easel Corporation, wobei er mit dem einzelnen Wort darauf hinweist Gedränge.^[18]

Sutherland und Schwaber arbeiteten zusammen, um ihre Ideen in einen einzigen Framework zu integrieren, Scrum. Sie testeten Scrum und verbesserten es kontinuierlich, was zu ihrem 1995er Papier führte.^[19] Beiträge zur Manifest für agile Softwareentwicklung in 2001,^[20] und die weltweite Verbreitung und Verwendung von Scrum seit 2002.

Im Jahr 1995 präsentierten Sutherland und Schwaber gemeinsam ein Papier, in dem das Scrum -Framework im Workshop für Geschäftsobjekte gestaltet und implementiert wird Objektorientierte Programmierung, Systeme, Sprachen & Anwendungen '95 (Oopsla '95) in Austin, Texas.^[19] In den folgenden Jahren haben Schwaber und Sutherland zusammengearbeitet, um dieses Material - mit ihrer Erfahrung und der Entwicklung einer guten Praxis - zu kombinieren, um das zu entwickeln, was als Scrum bekannt wurde.^[3]

Im Jahr 2001 arbeitete Schwaber mit Mike Beedle Um die Methode im Buch zu beschreiben, Agile Softwareentwicklung mit Scrum.^[21] Der Ansatz von Scrum zur Planung und Verwaltung der Produktentwicklung beinhaltet das Bringen Entscheidung fällen Autorität für die Betriebsebene und Gewissheiten.^[9]

Im Jahr 2002 gründete Schwaber mit anderen die Scrum Alliance^[22] und richten Sie die ein Zertifiziertes Scrum Akkreditierungsreihe. Schwaber verließ die Scrum Alliance Ende 2009 und gründete Scrum.org^[23] was die Parallele überwacht Professionelles Scrum Akkreditierungsreihe.^[24]

Seit 2009 ein öffentliches Dokument namens namens Der Scrum Guide^[3] wurde von Schwaber und Sutherland veröffentlicht und aktualisiert. Es wurde sechs Mal überarbeitet, wobei die aktuelle Version November 2020 ist.

Scrum -Team

Die grundlegende Einheit von Scrum ist ein kleines Team von Menschen, das aus einem Produktbesitzer, einem Scrum -Master und Entwicklern besteht. Das Team ist selbstverwaltet, funktionsübergreifend und konzentriert sich jeweils auf ein Ziel: das Produktziel.

Produktbesitzer

Der Produktbesitzer, der das Produkt vertritt Stakeholder und die Stimme des Kunden (oder kann die Wünsche von a darstellen Komitee^[25]), ist verantwortlich für die Erbringung guter Geschäftsergebnisse.^[26] Daher ist der Produktbesitzer für die verantwortlich Produktrückstand und um den Wert zu maximieren, den das Team liefert.^[25] Der Produktbesitzer definiert das Produkt in Bezug auf kundenorientierte Ergebnisse (typisch - aber nicht beschränkt auf - benutzergeschichten), fügt sie dem Produktrücken hinzu und priorisiert sie basierend auf Bedeutung und Abhängigkeiten.^[27] Ein Scrum -Team sollte nur einen Produktbesitzer haben (obwohl ein Produktbesitzer mehr als ein Team unterstützen könnte)^[28] und es wird stark davon abgehalten, diese Rolle mit der Rolle des Scrum -Meisters zu kombinieren. Der Produktbesitzer sollte sich auf die Geschäftsseite der Produktentwicklung konzentrieren und die meiste Zeit mit den Stakeholdern und dem Team verbringen. Der Produktbesitzer bestimmt nicht, wie das Team eine technische Lösung erreicht, sondern nach Konsens unter den Teammitgliedern.^[29][30][31] Diese Rolle ist entscheidend und erfordert ein tiefes Verständnis für beide Seiten: das Geschäft und die Ingenieure (Entwickler) im Scrum -Team. Daher sollte ein guter Produkteigentümer in der Lage sein, zu kommunizieren, was das Geschäft braucht, warum er es braucht (da es möglicherweise bessere Möglichkeiten gibt, dies zu erreichen), und die Botschaft allen Beteiligten, einschließlich der Entwickler, die die technische Sprache verwenden, nach Bedarf zu vermitteln. Der Produktbesitzer verwendet die empirischen Tools von Scrum, um hochkomplexe Arbeiten zu verwalten, gleichzeitig das Risiko zu kontrollieren und Wert zu erreichen.

Kommunikation ist eine zentrale Verantwortung des Produktbesitzers. Die Fähigkeit, Prioritäten zu vermitteln und sich in Teammitglieder und Stakeholder einfühlen, ist von entscheidender Bedeutung, um die Produktentwicklung in die richtige Richtung zu steuern. Die Rolle des Produktbesitzers überbrückt die Kommunikationslücke zwischen dem Team und seinen Stakeholdern und dient als Stellvertreter für die Stakeholder des Teams und als Teamvertreter der Gesamt -Stakeholder -Community.^[32][33]

Als Gesicht des Teams zu den Stakeholdern sind die folgenden Kommunikationsaufgaben des Produktbesitzers für die Stakeholder:^[34]

• Veröffentlichungen definieren und ankündigen.
• Kommunizieren Sie die Lieferung und den Produktstatus.
• Fortschritte während der Governance -Sitzungen teilen.
• Signifikante Ridas teilen (Risiken, Hindernisse, Abhängigkeitenund Annahmen) mit Stakeholdern.
• Prioritäten, Umfang, Finanzierung und Zeitplan verhandeln.
• Stellen Sie sicher, dass der Produktrückstand sichtbar, transparent und klar ist.

Die Fähigkeit zu beziehen ist ein wichtiges Attribut für einen Produktbesitzer - die Fähigkeit, sich selbst in die Schuhe eines anderen zu stecken. Ein Produktbesitzer unterhält sich mit verschiedenen Stakeholdern mit einer Vielzahl von Hintergründen, Jobrollen und Zielen - und sollte in der Lage sein, diese unterschiedlichen Standpunkte zu schätzen. Um effektiv zu sein, ist es für einen Produktbesitzer ratsam, das Detailgrad des Publikums zu kennen. Die Entwickler benötigen gründliche Feedback und Spezifikationen, damit sie ein Produkt für die Erwartung aufbauen können, während ein Executive Sponsor möglicherweise nur Zusammenfassungen des Fortschritts benötigt. Die Bereitstellung von mehr Informationen als notwendig kann das Interesse der Stakeholder und die Verschwendung von Zeit verlieren. Ein direktes Kommunikationsmittel wird von erfahrenen Produktbesitzern bevorzugt.^[28]

Die Fähigkeit eines Produktbesitzers, effektiv zu kommunizieren, wird auch durch Fachkräfte in Techniken, die die Bedürfnisse der Stakeholder identifizieren, Prioritäten zwischen den Interessen der Stakeholder aushandeln und mit den Entwicklern zusammenarbeiten, um eine effektive Umsetzung der Anforderungen zu gewährleisten.

Entwickler

Die Entwickler führen alle Arbeiten durch, die erforderlich sind, um Wertschöpfung in jedem Sprint zu erstellen.^[27]

Der Begriff Entwickler^[3] Bezieht sich auf alle, die eine Rolle bei der Entwicklung und Unterstützung des Systems oder des Produkts spielen, und können unter anderem Forscher, Architekten, Designer, Datenspezialisten, Statistiker, Analysten, Ingenieure, Programmierer und Tester umfassen.^[35] Aufgrund der Verwirrung, die auftreten kann, wenn einige Menschen den Begriff „Entwickler“ nicht für sie gilt, werden sie oft genauso bezeichnet Teammitglieder.

Das Team organisiert sich selbst. Während keine Arbeit zum Team außer dem Produktbesitzer kommen sollte und der Scrum -Master das Team vor Ablenkungen schützt, wird das Team ermutigt, direkt mit Kunden und/oder Stakeholdern zu interagieren, um maximales Verständnis und Unmittelbarkeit des Feedbacks zu erhalten.^[27]

Scrum Master

Scrum wird von einem Scrum -Master erleichtert, der dafür verantwortlich ist, Hindernisse für die Fähigkeit des Teams zu beseitigen, die Produktziele und -zustellungen zu liefern.^[36] Der Scrum Master ist nicht traditionell Teamleiter oder Projektmanager aber als Barriere zwischen dem Team und allen ablenkenden Einflüssen. Der Scrum -Master stellt sicher, dass das Scrum -Framework das Team in Scrum -Theorie und -konzepten trainiert und häufig die wichtigsten Sitzungen erleichtert, und ermutigt das Team, zu wachsen und sich zu verbessern. Die Rolle wurde auch als Teamvermittler bezeichnet oder Dienerführer diese doppelten Perspektiven zu verstärken.

Zu den Kernaufgaben eines Scrum -Meisters gehören (aber nicht beschränkt):^[37]

• Helfen Sie dem Produktbesitzer, das Produkt -Rückstand auf eine Weise aufrechtzuerhalten, die sicherstellt
• Helfen Sie dem Team, die Definition von Fertig für das Produkt zu bestimmen, mit Eingaben von wichtigen Stakeholdern
• Coaching des Teams innerhalb der Scrum-Prinzipien, um qualitativ hochwertige Funktionen für sein Produkt zu liefern^[38]
• Bildung wichtiger Stakeholder und dem Rest der Organisation über Scrum- (und möglicherweise agile) Prinzipien
• Helfen Sie dem Scrum -Team, Hindernisse für den Fortschritt zu vermeiden oder zu entfernen, sei
• Förderung der Selbstorganisation und Kreuzfunktionalität innerhalb des Teams
• Erleichterung von Teamveranstaltungen, um einen regelmäßigen Fortschritt zu gewährleisten

Der Scrum Master hilft Menschen und Organisationen, empirisches und schlankes Denken zu übernehmen und die Hoffnungen auf Sicherheit und Vorhersehbarkeit zurückzulassen.

Eine der Möglichkeiten, wie sich die Rolle der Scrum -Master von einem Projektmanager unterscheidet, besteht darin, dass letztere möglicherweise haben kann Mitarbeiterführung Verantwortlichkeiten und der Scrum Master nicht. Ein Scrum-Master bietet eine begrenzte Ausrichtung, da das Team voraussichtlich gestärkt und selbstorganisiert werden soll.^[39] Scrum erkennt die Rolle des Projektmanagers nicht offiziell als traditionell an Steuerung und Kontrolle Tendenzen würden Schwierigkeiten verursachen.^[40]

Arbeitsablauf

Sprint

Ein Sprint (auch bekannt als Wiederholung oder Zeitkasten) ist die grundlegende Entwicklungseinheit in Scrum. Der Sprint ist ein Zeitschachtel Anstrengung; Das heißt, die Länge wird für jeden Sprint im Voraus vereinbart und fixiert und liegt normalerweise zwischen einer Woche und einem Monat, wobei zwei Wochen am häufigsten sind.^[9]

Jeder Sprint beginnt mit einem Sprintplanung Ereignis, bei dem ein Sprint -Ziel definiert ist. Prioritäten für den bevorstehenden Sprint werden aus dem Rückstand ausgewählt. Jeder Sprint endet mit zwei Veranstaltungen:

• a Sprint Review (Fortschritte, die den Stakeholdern gezeigt werden, um ihr Feedback zu erlangen)
• a Sprint Retrospektive (Identifizieren Sie Lektionen und Verbesserungen für die nächsten Sprints).^[18]

Scrum betont die wertvolle, umsetzbare Leistung am Ende des Sprint, der gerade fertiggestellt wurde. Bei Software umfasst dies wahrscheinlich, dass Produkte vollständig integriert, getestet und dokumentiert und potenziell freigesetzt werden.^[40]

Sprintplanung

Zu Beginn eines Sprint veranstaltet das Scrum -Team eine Sprint -Planungsereignis an:

• Stimmen Sie auf das Sprint -Ziel zu, eine kurze Beschreibung dessen, was sie prognostizieren möchten, basierend auf den Prioritäten, die der Produktbesitzer festgelegt hat
• Wählen Sie Produkt -Rückstandselemente aus, die zu diesem Ziel beitragen
• Bilden Sie einen Sprint -Rückstand, indem Sie sich gegenseitig diskutieren und zustimmen, welche Elemente während dieses Sprint durchgeführt werden sollen

Die maximale Sprintplanungsdauer beträgt acht Stunden für einen vierwöchigen Sprint.^[3] Da die detaillierten Arbeiten ausgearbeitet werden, können einige Produkt -Backlog -Elemente aufgeteilt oder an den Produktrücken zurückgegeben werden, wenn das Team der Ansicht ist, dass sie diese Arbeit in einem einzigen Sprint nicht erledigen können.

Täglich Scrum

Jeden Tag während eines Sprint halten die Entwickler ein tägliches Scrum (manchmal durchgeführt aufstehen) mit spezifischen Richtlinien:^[41][9]

Alle Entwickler sind vorbereitet. Das tägliche Scrum:

• konzentriert sich darauf, den Fortschritt in Richtung des Sprint -Ziels zu inspizieren
• sollte jeden Tag gleichzeitig und Ort passieren
• ist begrenzt (Zeitschachtel) bis fünfzehn Minuten
• wird durchgeführt, aber das Team entscheidet
• Kann andere umfassen, obwohl nur Entwickler sprechen sollten.
• kann vom Scrum Master erleichtert werden
• kann Hindernisse für den Fortschritt identifizieren (z. B. Stolperstein, Risiko, Problem, verzögerte Abhängigkeit, Annahme als unbegründet).^[42]
• enthält keine Diskussionen
• ist kein Mittel zur Aktualisierung von Fortschrittsdiagrammen

Während des täglichen Scrum sollten keine detaillierten Diskussionen stattfinden. Sobald einzelne Mitglieder in Details diskutieren können, die häufig als "Breakout -Sitzung" oder "After Party" bezeichnet werden.^[43] Die identifizierten Probleme oder Fehler sollten gemeinsam außerhalb des täglichen Scrum diskutiert werden, um auf eine Lösung hinzuarbeiten.

Wenn das Team den Wert in diesem Fall nicht sieht, liegt es in der Verantwortung des Scrum -Meisters, herauszufinden, warum^[44] und das Team und die Stakeholder über Scrum -Prinzipien aufklären,^[38] Oder ermutigen Sie das Team, seine eigene Methode zu entwerfen, um das Team vollständig über den Sprint -Fortschritt auf dem Laufenden zu halten.

Sprint Review

Am Ende eines Sprint, des Teams, durchgeführt:

• präsentiert die abgeschlossenen Arbeiten den Stakeholdern (a.k.a. die Demo)
• Arbeitet mit Stakeholdern zu Themen wie:
  • Einladende Feedback zum abgeschlossenen Produktinkrement
  • Erörterung der Auswirkungen unvollständiger Arbeiten (geplant oder auf andere Weise)
  • Erhalt von Vorschlägen für bevorstehende Arbeiten (Anleitung, woran man als nächstes arbeiten soll)

Produktbesitzer sollten diese Veranstaltung als wertvolle Gelegenheit sehen, den Produkt Rückstand mit den Stakeholdern zu überprüfen und zu verfeinern.

Richtlinien für Sprint -Bewertungen:

• Unvollständige Arbeiten sollten nicht nachgewiesen werden; Obwohl Stakeholder mit Produktschritten vorgestellt werden, werden sie erhalten, können aber auch beantragen, bei Bedarf Arbeiten in Arbeit zu sehen. Das Team sollte jedoch nur bereit sein, zu zeigen, was getan wurde.
• Die empfohlene Dauer beträgt zwei Stunden für einen zweiwöchigen Sprint (proportional für andere Sprint-Dauer).^[3]

Sprint Retrospektive

Bei der Sprint -Retrospektive das Team:

• reflektiert die vergangenen Sprint (n)
• Überprüfen Sie, wie der letzte Sprint verlief (Einzelpersonen, Interaktionen, Prozesse, Werkzeuge, Definition von Fertig))
• identifiziert und stimmt zu Kontinuierliche Prozessverbesserung Aktionen

Richtlinien für Sprint -Retrospektiven:

• Drei vorgeschlagene Bereiche, die in Sprint -Retrospektiven berücksichtigt werden müssen, sind:
  • Was ist während des Sprint gut gelaufen?
  • Was ist nicht gut gelaufen?
  • Was könnten wir den nächsten Sprint anders machen?
• Die Dauer beträgt maximal drei Stunden für einen vierwöchigen Sprint, der für andere Sprint-Dauer (z. B. anderthalb Stunden für einen zweiwöchigen Sprint) proportional ist.

Der Scrum -Meister kann diese Veranstaltung erleichtern, können aber auch als Teil des Teams anwesend sein.

Raffinesse

Obwohl ursprünglich nicht eine Kernpraxis, Rückstand Raffinesse (früher genannt Körperpflege) wurde dem Scrum Guide hinzugefügt und zur Verwaltung der Qualität von Produkt -Rücksteinelementen in einen Sprint übernommen. Es ist der fortlaufende Prozess der Überprüfung und Änderung/Aktualisierung/Neubestellung von Produkt-Rückstandsartikeln im Lichte neuer Informationen.

Gründe für die Änderung des Rückstands und der Elemente innerhalb können enthalten:

• Größere Gegenstände können in mehrere kleinere untergebracht werden
• Akzeptanzkriterien können geklärt werden
• Abhängigkeiten können identifiziert und untersucht werden
• Ein Artikel erfordert möglicherweise eine weitere Entdeckung und Analyse
• Prioritäten können sich geändert haben; Die erwarteten Renditen werden nun unterschiedlich sein

Die Verfeinerung bedeutet, dass Elemente angemessen vorbereitet und so bestellt werden, dass sie für Entwickler für die Sprintplanung klar und ausführbar sind.

Der Rückstand kann auch enthalten Technische Schulden (Auch als Entwurfsschuld oder Code -Schulden bezeichnet). Dies ist ein Konzept in der Softwareentwicklung, das die impliziten Kosten für zusätzliche Nacharbeit widerspiegelt, die durch die Auswahl einer einfachen Lösung jetzt verursacht werden, anstatt einen besseren Ansatz zu verwenden, der länger dauern würde.

Es wird empfohlen, bis zu 10 Prozent der Sprintkapazität eines Teams zu investieren^[3] Bei Backlog -Verfeinerung. Ausgereiftere Teams werden dies nicht als ein geplantes definiertes Ereignis ansehen, sondern als eine Ad-hoc-Aktivität, die Teil des natürlichen Workflows ist und das Produktrückstand bei Bedarf verfeinert und anpasst.

Stornieren eines Sprint

Der Produktbesitzer kann bei Bedarf einen Sprint stornieren.^[3] und kann dies mit Eingaben anderer (Entwickler, Scrum Master oder Management) tun. Zum Beispiel können jüngste externe Umstände den Wert des Sprint -Ziels negieren, sodass es sinnlos ist, fortzufahren.

Wenn ein Sprint abnormal beendet wird, besteht der nächste Schritt darin, eine neue Sprintplanung durchzuführen, bei der der Grund für die Kündigung überprüft wird.

Artefakte

Artefakte beziehen sich auf die Dokumentation, die zur Verwaltung von Arbeiten im Projekt verwendet wird.

Produktrückstand

Der Produkt -Rückstand ist eine Aufschlüsselung der Arbeit, die zu erledigen ist, und enthält eine geordnete Liste von Produktanforderungen dass das Team für a unterhält Produkt. Gemeinsame Formate für Backlog -Elemente enthalten benutzergeschichten und Anwendungsfälle.^[40] Diese Anforderungen definieren Merkmale, Fehlerbehebung, Nicht-funktionale Anforderungenusw. - Was auch immer ein tragfähiges Produkt liefert. Der Produkteigentümer priorisiert die PBIs (PBIs) für Produkt Rückstand (PBIs), basierend auf Überlegungen wie Risiko, Geschäftswert, Abhängigkeiten, Größe und Datum erforderlich.

Der Produkt -Rückstand ist "was benötigt wird, bestellt von wann es benötigt wird" und ist für alle sichtbar, kann jedoch nur mit Zustimmung des Produktbesitzers geändert werden, der für die Verwaltung und Wartung der Produkt -Rückmeldungen verantwortlich ist.

Der Produkt -Rückstand enthält die Bewertung des Geschäftswertes durch den Produktbesitzer und kann die Bewertung des Aufwands oder der Komplexität des Teams oft, aber nicht immer, enthalten Story -Punkte Verwendung der Runden Fibonacci -Skala. Diese Schätzungen helfen dem Produktbesitzer, die Zeitleiste zu beurteilen und die Bestellung von Produktrückstlog -Elementen zu beeinflussen. Beispielsweise kann der Produktbesitzer für zwei Funktionen mit dem gleichen Geschäftswert frühere Arbeiten mit niedrigeren Entwicklungsaufwand planen (weil die Return on Investment ist höher) oder derjenige mit höherer Entwicklungsanstrengungen (weil es komplexer oder riskanter ist und dieses Risiko früher zurückziehen möchte).^[45]

Der Produktrückstand und der geschäftliche Wert jedes Produkt -Rückstandsartikels liegen in der Verantwortung des Produktbesitzers. Die Bemühungen, jeden Artikel zu liefern, kann in Story -Punkten oder Zeit geschätzt werden. Durch die Schätzung der Story -Punkte reduziert das Team die Abhängigkeit einzelner Entwickler. Dies ist insbesondere für dynamische Teams nützlich, in denen Entwickler nach der Abgabe von Sprint häufig anderen Arbeiten zugewiesen werden. Wenn beispielsweise eine Benutzergeschichte als 5 in Anstrengung geschätzt wird (unter Verwendung von Fibonacci -Sequenz), bleibt sie 5, unabhängig davon, wie viele Entwickler daran arbeiten

Story-Punkte definieren die Bemühungen in einer Zeitbox, sodass sie sich nicht mit der Zeit ändern. Zum Beispiel kann eine Person in einer Stunde laufen, laufen oder klettern, aber die Aufwand ist eindeutig anders. Der Gap -Fortschreiten zwischen den Begriffen in der Fibonacci -Sequenz ermutigt das Team, sorgfältig berücksichtigte Schätzungen zu liefern. Schätzungen von 1, 2 oder 3 implizieren ähnliche Anstrengungen (1 ist trivial). Wenn das Team jedoch 8 oder 13 (oder höher) schätzt, kann die Auswirkungen sowohl auf die Lieferung als auch auf das Budget erheblich sein. Der Wert der Verwendung von Story -Punkten besteht darin, dass das Team sie wiederverwenden kann, indem sie ähnliche Arbeiten aus früheren Sprints vergleichen, aber es sollte anerkannt werden, dass Schätzungen im Verhältnis zu diesem Team sind. Beispielsweise könnte eine Schätzung von 5 für ein Team eine 2 für ein anderes sein, das aus erfahreneren Entwicklern mit höherer Fähigkeit besteht.

Jedes Team sollte einen Produktbesitzer haben, obwohl ein Produktbesitzer in vielen Fällen mit mehr als einem Team zusammenarbeiten könnte.^[28] Der Produktbesitzer ist dafür verantwortlich, den Wert des Produkts zu maximieren. Der Produktbesitzer sammelt Eingaben und nimmt Feedback von und wird von vielen Menschen eingesetzt, hat aber letztendlich die endgültige Entscheidung darüber, was aufgebaut wird.

Der Produktrückstand:

• Erfasst Anfragen zum Ändern eines Produkts - einschließlich neuer Funktionen, Ersetzen alter Funktionen, Entfernen von Funktionen und Behebung von Problemen
• Stellt sicher, dass die Entwickler Arbeit haben, die den geschäftlichen Nutzen des Produkts maximiert

In der Regel arbeitet das gesamte Team zusammen, um den Produktrückstand zu verfeinern, der sich als neue Informationsflächen über das Produkt und seine Kunden entwickelt, und so können später Sprints neue Arbeiten ansprechen.

Management

Ein Produkt -Rückstand in seiner einfachsten Form ist lediglich eine Liste von Elementen, an denen sie arbeiten können. Gut etablierte Regeln darüber, wie Arbeit hinzugefügt, entfernt und geordnet wird, hilft dem gesamten Team, bessere Entscheidungen darüber zu treffen, wie das Produkt geändert werden kann.^[46]

Der Produktbesitzer priorisiert Produkt -Rückstandsartikel, die darauf basieren, dass sie bald benötigt werden. Entwickler, die vom Sprintziel beeinflusst werden, wählen Gegenstände für den kommenden Sprint und verschieben diese Gegenstände vom Produkt -Rückstand auf den Sprint -Rückstand, der die Liste der Elemente ist, die sie erstellen werden. Konzeptionell wird das Sprintziel von hochpriorischen Elementen oben auf der Liste beeinflusst, aber es ist nicht ungewöhnlich, dass Entwickler einige Elemente mit niedrigerer Priorität einnehmen, wenn im Sprint noch Zeit ist, um mehr Arbeiten unterzubringen.

Elemente mit hoher Priorität (oben im Rückstand) sollten auf Details unterteilt werden, die für die Entwickler geeignet sind, um daran zu arbeiten. Je weiter im Rückstand, desto weniger detaillierte Elemente werden es sein. Wie Schwaber und Beedle es "desto niedriger die Priorität haben, desto weniger Details, bis Sie den Rückstandsartikel kaum erkennen können".^[9]

Da das Team den Rückstand durcharbeitet, muss angenommen werden, dass Veränderungen außerhalb seiner Umgebung stattfinden - das Team kann sich über neue Marktchancen, die die Aussagen von Wettbewerbern nutzen, und das Feedback von Kunden kennenlernen, die die Art und Weise, wie das Produkt gemeint war, verändern kann arbeiten. All diese neuen Ideen lösen das Team dazu, den Rückstand anzupassen, um neues Wissen einzubeziehen. Dies ist Teil der grundlegenden Denkweise eines agilen Teams. Die Welt verändert sich, der Rückstand ist nie fertig.^[47]

Sprint Rückstand

Der Sprint -Rückstand ist die Teilmenge der Artikel aus dem Produkt -Rückstand, das Entwickler im kommenden Sprint ansprechen soll.^[48] Entwickler werden diesen Rückstand füllen, bis sie das Gefühl haben, über genügend Arbeit zu verfügen, um den Sprint zu füllen, und die Kapazität für den nächsten Sprint nutzen, um diese als Richtlinie zu nutzen, wie viel „Anstrengungen“ sie abschließen können.

Arbeiten am Sprint -Rückstand werden den Entwicklern nie zugewiesen (oder gedrückt). Die Teammitglieder ziehen die Arbeit nach Bedarf gemäß der Priorität der Rückstände und ihren eigenen Fähigkeiten und Kapazitäten. Dies fördert die Selbstorganisation der Entwickler.

Der Sprint -Rückstand ist Eigentum der Entwickler, und alle enthaltenen Schätzungen werden von den Entwicklern bereitgestellt. Obwohl einige Teams nicht Teil von Scrum sind, verwenden sie ein begleitendes Board, um den Arbeitszustand im aktuellen Sprint zu visualisieren: Todo, Tun, fertig.

Zuwachs

Das Zuwachs ist die potenziell freisetzbare Ausgabe des Sprint, der dem Sprintziel erreicht. Es wird aus allen fertigen Sprint -Rückstände gegründet, die in die Arbeit aller früheren Sprints integriert sind. Das Inkrement muss gemäß dem Scrum -Team abgeschlossen sein Definition von fertig (Dod), voll funktionsfähig und in einem verwendbaren Zustand, unabhängig davon, ob der Produktbesitzer es tatsächlich bereitstellt und verwendet.

Erweiterungen

Die folgenden Artefakte und Techniken können verwendet werden, um Menschen zu helfen, Scrum zu verwenden.^[3]

Burndown -Diagramm

Ein Burndown -Diagramm wird häufig in Scrum (aber nicht Teil von Scrum) verwendet. Es ist ein öffentlich angezeigter Diagramm, das die verbleibenden Arbeiten zeigt.^[49] Täglich aktualisiert, bietet es schnelle Visualisierungen als Referenz. Die horizontale Achse des Burndown -Diagramms zeigt die verbleibenden Tage, während die vertikale Achse die Menge der verbleibenden Arbeiten pro Tag zeigt.

Während der Sprintplanung wird das ideale Burndown -Diagramm aufgetragen. Während des Sprint aktualisieren die Entwickler das Diagramm mit den verbleibenden Arbeiten, damit das Diagramm von Tag zu Tag aktualisiert wird und einen Vergleich zwischen tatsächlicher und vorhergesagtem Vergleich zeigt.

Es sollte nicht mit einem verwechselt werden Verdienst -Value -Diagramm.

Burn-up-Diagramm freigeben

Das Veröffentlichungs-Burn-up-Diagramm ist eine Möglichkeit für das Team, Sichtbarkeit zu bieten und den Fortschritt zu einer Veröffentlichung zu verfolgen. Am Ende jedes Sprint aktualisiert, zeigt es Fortschritte bei der Bereitstellung eines prognostizierten Bereichs. Die horizontale Achse der Verbrennungsdiagramme der Freisetzung zeigt die Sprints in einer Version, während die vertikale Achse die Menge an Arbeiten zeigt, die am Ende jedes Sprint ausgeführt werden (in der Regel die kumulativen Arbeitspunkte der Arbeiten abgeschlossen). Der Fortschritt wird als eine Linie dargestellt, die auf eine horizontale Linie wächst, die den prognostizierten Bereich darstellt. Oft mit einer Prognose angezeigt, die auf dem bisherigen Fortschritt basiert, zeigt an, wie viel Umfang durch ein bestimmtes Veröffentlichungsdatum abgeschlossen sein könnte oder wie viele Sprints es dauern wird, um den angegebenen Umfang zu vervollständigen.

Das Veröffentlichungsdiagramm erleichtert es leicht zu erkennen, wie viel Arbeit abgeschlossen wurde, wie viel Arbeit hinzugefügt oder entfernt wurde (wenn sich die horizontale Umfangslinie bewegt) und wie viel Arbeit zu erledigen ist.

Definition von Ready (DOR)

Die Startkriterien, um festzustellen, ob die Spezifikationen und Eingaben sind klar genug eingestellt, um das Arbeitselement zu starten.

Definition von Fertig (DOD)

Das Abbruchkriterium So ermitteln Regressionstests erfolgreich sein. Die Definition von Fertig kann von einem Team zum anderen variieren, muss jedoch innerhalb eines Teams konsistent sein.^[50]

Geschwindigkeit

Die Gesamtleistung eines Teams für einen einzigen Sprint, der durch Bewertung der im letzten Sprint abgeschlossenen Arbeiten abgeleitet wird. Die Sammlung historischer Geschwindigkeitsdaten ist eine Richtlinie, um das Team beim Verständnis seiner Kapazität zu unterstützen, d. H. Wie viel Arbeit sie bequem erreichen können.

Diese Metrik hat Kontroversen in der Scrum -Community angezogen:

• Story -Punkte konsumiert ist nicht gleich Wert geliefert: Das Team kann die Arbeit erledigen und den Stakeholdern lieferbare Vorteile ignorieren
• Einführung von Ablenkungspraktiken: Schätzung im Vergleich zu Tatsache, Varianzuntersuchung und Richtlinien der Wiedereinschätzung beginnen sich zu entstehen
• Das Management sieht die Geschwindigkeit als Leistungsmetrik an, um sie zu erhöhen, was bedeutet:
  • Qualitätsleiden - das Team beginnt, Ecken zu "abschneiden", um die zusätzliche Arbeitsbelastung einzuschließen
  • Moral leidet - das Team kann nicht in angenehmem nachhaltigem Tempo arbeiten, und ein erhöhter Druck führt zu Burn -out
  • Schätzung leidet - Entwickler werden Schätzungen aufbauen, um in Puffer aufzubauen und "die Metriken zu spielen", wodurch die gleichen Anstrengungen auf einer anderen Skala messen
  • Werts leidet - Der Endeffekt ist eine Einmischung, die die Unzufriedenheit der Stakeholder infolge des Wechsels von der Abgabe von Unternehmenswerts zu Unzufriedenheit verursacht

Während das Verständnis der Lieferkapazität eines Teams Wert aufweist, sollte die Geschwindigkeit als Indikator für das Team und kein Zifferblatt angesehen werden, das angepasst werden kann.

Spitze

Eine Zeitbox-Zeit, die verwendet wird, um ein Konzept zu erforschen oder einen einfachen Prototyp zu erstellen. Spikes können entweder zwischen Sprints oder für größere Teams geplant werden, die als eines von vielen Sprint -Lieferzielen angenommen werden kann. Spikes werden häufig vor der Lieferung großer oder komplexer Produkt -Rückstandsgegenstände eingeführt, um das Budget zu sichern, Wissen zu erweitern oder einen Beweis für das Konzept zu erstellen. Die Dauer und Ziele eines Spike werden vom Team vor dem Start vereinbart. Im Gegensatz zu Sprint -Verpflichtungen können Spikes greifbare, versendbare und wertvolle Funktionen liefern oder nicht. Zum Beispiel könnte das Ziel einer Spitze darin bestehen, erfolgreich eine Entscheidung über eine Vorgehensweise zu treffen. Die Spitze ist vorbei, wenn die Zeit abgelaufen ist, nicht unbedingt, wenn das Ziel geliefert wurde.^[51]

Tracer -Kugel

Eine Tracer -Kugel, die auch als Drohnenspike bezeichnet wird, ist ein Spike mit der aktuellen Architektur, der aktuellen Technologie -Set, aktueller Best Practices, die zu Produktionsqualitätscode führen. Es mag nur eine sehr enge Implementierung der Funktionalität sein, aber kein Wegwerfcode. Es ist von Produktionsqualität und der Rest der Iterationen kann auf diesem Code aufbauen. Der Name hat militärische Ursprünge als Munition Das macht den Weg der Kugel sichtbar und ermöglicht Korrekturen. Oft sind diese Implementierungen ein "Schnellschuss" durch alle Schichten einer Anwendung, z. B. das Verbinden eines Eingangsfelds eines einzelnen Formulars mit dem Back-End, um die Schichten wie erwartet zu beweisen.^[52]

Einschränkungen

Die Vorteile von Scrum sind möglicherweise schwieriger zu erzielen mit:^[53][54]

• Teams, deren Mitglieder geografisch verteilt oder Teilzeit sind: In Scrum sollten Entwickler eine enge und anhaltende Interaktion haben, die die meiste Zeit idealerweise im selben Raum zusammenarbeiten. Während die jüngsten Verbesserungen der Technologie die Auswirkungen dieser Barrieren verringert haben (z. B. in der Lage sind, an einem digitalen Whiteboard zusammenzuarbeiten), behauptet das agile Manifest, dass die beste Kommunikation von Angesicht zu Angesicht ist.^[55]
• Teams, deren Mitglieder sehr spezielle Fähigkeiten haben: In Scrum sollten Entwickler haben T-förmige Fähigkeitenund erlauben ihnen, an Aufgaben außerhalb ihrer Spezialisierung zu arbeiten. Dies kann durch gute Scrum -Führung gefördert werden. Während Teammitglieder mit sehr spezifischen Fähigkeiten einen guten Beitrag leisten können, sollten sie dazu ermutigt werden, mehr über andere Disziplinen zu erfahren und mit ihnen zusammenzuarbeiten.
• Produkte mit vielen externen Abhängigkeiten: In Scrum ist die Aufteilung der Produktentwicklung in kurze Sprints eine sorgfältige Planung erforderlich. externe Abhängigkeiten, wie z. User Acceptance Testing oder die Koordination mit anderen Teams kann zu Verzögerungen und dem Versagen einzelner Sprints führen.
• Produkte, die sind reifen oder Erbe oder mit reguliertem Qualitätskontrolle: In Scrum sollten Produktschritte in einem einzigen Sprint vollständig entwickelt und getestet werden. Produkte, die große Mengen von benötigen Regressionstests oder Sicherheitstests (z. B. Medizinprodukte oder Fahrzeugkontrolle) für jede Freisetzung sind weniger für kurze Sprints als länger geeignet als für länger Wasserfall Veröffentlichungen.

Werkzeuge verfügbar

Wie andere agile Ansätze kann eine effektive Einführung von Scrum durch eine breite Palette von verfügbaren Werkzeugen unterstützt werden (aber nicht abhängig von).

Viele Unternehmen verwenden universelle Tools wie Tabellenkalkulationen, um einen Sprint -Rückstand zu erstellen und zu pflegen. Es gibt auch Open-Source- und proprietäre Softwarepakete, die Scrum-Terminologie für die Produktentwicklung verwenden oder mehrere Produktentwicklungsansätze einschließlich Scrum unterstützen.

Andere Organisationen implementieren Scrum ohne Softwaretools und pflegen ihre Artefakte in hartkopischen Formularen wie Papier, Whiteboards und Haftnotizen.^[56]

Scrum -Werte

Scrum ist ein feedbackgetriebenes empirischer Ansatz, der wie alle empirischen Prozesskontrolle durch die drei Säulen von Transparenz, Inspektion und Anpassung untermauert wird. Alle Arbeiten innerhalb des Scrum -Frameworks sollten für diejenigen sichtbar sein, die für das Ergebnis verantwortlich sind: Der Prozess, der Workflow, den Fortschritt usw. Um diese Dinge sichtbar zu machen, müssen Scrum -Teams häufig das entwickelte Produkt und wie gut das Team ist Arbeiten. Bei häufiger Inspektion kann das Team erkennen, wenn seine Arbeit außerhalb von akzeptablen Grenzen abweicht und sein Prozess oder das in der Entwicklung befindliche Produkt anpassen.^[27]

Diese drei Säulen erfordern Vertrauen und Offenheit im Team, was die folgenden fünf Werte von Scrum ermöglichen:^[3]

1. Engagement: Teammitglieder verpflichten sich individuell, ihre Teamziele zu erreichen, und alle jeder Sprint.
2. Mut: Teammitglieder wissen, dass sie den Mut haben, gemeinsam Konflikte und Herausforderungen zu bewältigen, damit sie das Richtige tun können.
3. Fokus: Teammitglieder konzentrieren sich ausschließlich auf ihre Teamziele und den Sprint -Rückstand. Es sollte keine andere Arbeit als durch ihren Rückstand erledigt werden.
4. Offenheit: Teammitglieder und ihre Stakeholder sind sich einig, transparent in Bezug auf ihre Arbeit und alle Herausforderungen, denen sie gegenüberstehen.
5. Respekt: ​​Teammitglieder respektieren sich gegenseitig, um technisch fähig zu sein und mit guter Absicht zu arbeiten.

Anpassungen

Scrum wird in einer Vielzahl von Kontexten verwendet, um viele verschiedene Ziele zu erreichen. Um diese unterschiedlichen Enden zu erreichen, wird Scrum häufig zugeschnitten oder angepasst.^[57] Ein gemeinsamer Ansatz zur Anpassung von Scrum ist die Hybridisierung von Scrum mit anderen Softwareentwicklungsmethoden, da Scrum das Ganze nicht abdeckt Produktentwicklungslebenszyklus; Daher finden Unternehmen die Notwendigkeit, zusätzliche Prozesse hinzuzufügen, um eine umfassendere Implementierung zu erstellen. Zu Beginn der Produktentwicklung fügen Organisationen beispielsweise die Prozessanleitungen zum Geschäftsfall, die Anforderungen und Priorisierung, das anfängliche Design auf hoher Ebene sowie die Budget- und Zeitplanprognose hinzu.^[58]

Verschiedene Autoren und Gemeinschaften von Menschen, die Scrum verwenden, haben auch detailliertere Techniken vorgeschlagen, um Scrum an bestimmte Probleme oder Organisationen anzuwenden oder an sie anzupassen. Viele bezeichnen diese methodischen Techniken als „Muster“ - durch Analogie mit Designmuster in Architektur und Software.^[59][60]

Schrott

Scrumban ist ein Software -Produktionsmodell, das auf Scrum und basierend basiert Kanban. Scrumban eignet sich besonders für Produktwartung mit häufigen und unerwarteten Arbeitsteilen wie z. Produktionsfehler oder Programmierfehler. In solchen Fällen können die zeitlich begrenzten Sprints des Scrum-Frameworks als von geringerem Nutzen angesehen werden, obwohl die täglichen Ereignisse und andere Praktiken von Scrum weiterhin angewendet werden können, abhängig vom Team und der jeweiligen Situation. Die Visualisierung der Arbeitsphasen und Einschränkungen für gleichzeitige unvollendete Arbeit und Mängel sind aus dem Kanban -Modell bekannt. Mit diesen Methoden des Teams des Teams Arbeitsablauf wird auf eine Weise gerichtet, die für jeden Arbeitselement oder Programmierfehler eine minimale Abschlusszeit ermöglicht, und stellt andererseits sicher, dass jedes Teammitglied ständig angewendet wird.^[61]

Um jede Arbeitsphase zu veranschaulichen, verwenden Teams, die im selben Raum arbeiten, häufig Post-It-Notizen oder ein großes Whiteboard.^[62] Im Fall von dezentralen Teams, Software zur Stufe-Ilustration wie z. B. Assembla, Jira oder Agilo kann verwendet werden.

Der Hauptunterschied zwischen Scrum und Kanban besteht darin, dass in Scrum die Arbeit in Sprints unterteilt ist, die eine feste Zeit dauern, während in Kanban der Arbeitsfluss kontinuierlich ist. Dies ist in Arbeitstabellen sichtbar, die nach jedem Sprint in Scrum geleert werden, während in Kanban alle Aufgaben auf demselben Tisch gekennzeichnet sind. Scrum konzentriert sich auf Teams mit vielfältigem Know-how, während Kanban spezielle, funktionale Teams ermöglicht.^[61]

Scrum von Scrums

Das Scrum of Scrums ist eine Technik, um Scrum in Maßstab zu bedienen, für mehrere Teams, die an demselben Produkt arbeiten, sodass sie Fortschritte in ihren gegenseitigen Abhängigkeiten besprechen und sich darauf konzentrieren können, wie die Liefersoftware koordiniert werden soll.^[63] insbesondere in Bereichen der Überlappung und Integration. Abhängig von der Trittfrequenz (Timing) des Scrum of Scrums endet das relevante tägliche Scrum für jedes Scrum -Team, indem es ein Mitglied als Botschafter für die Teilnahme am Scrum of Scrums mit Botschaftern anderer Teams bezeichnet. Abhängig vom Kontext können die Botschafter technische Mitwirkende oder den Scrum -Master jedes Teams sein.^[63]

Anstatt einfach ein Fortschritts -Update, sollte sich das Scrum von Scrums darauf konzentrieren, wie Teams gemeinsame Risiken, Hindernisse, Abhängigkeiten und Annahmen (RIDAs), die identifiziert wurden, zusammenarbeiten, abmildern oder akzeptieren. Das Scrum von Scrums verfolgt diese Ridas über einen eigenen Rückstand, wie z. B. ein Risikobrett (manchmal bekannt als Board Nach den Initialen von gelöst, besessen, akzeptiert und gemildert),^[64] Dies führt typischerweise zu einer größeren Koordination und Zusammenarbeit zwischen Teams.^[63]

Dies sollte einem täglichen Scrum ähnlich sein, wobei jeder Botschafter die folgenden vier Fragen beantwortet:^[65]

• Welche Risiken, Hindernisse, Abhängigkeiten oder Annahmen haben Ihr Team seit dem letzten Treffen gelöst?
• Welche Risiken, Hindernisse, Abhängigkeiten oder Annahmen werden Ihr Team entschlossen, bevor wir uns wieder treffen?
• Gibt es neue Risiken, Hindernisse, Abhängigkeiten oder Annahmen, die Ihr Team verlangsamen oder sich im Weg stellen?
• Sind Sie kurz davor, ein neues Risiko, eine Hindernis, eine Abhängigkeit oder eine Annahme vorzustellen, die in den Weg eines anderen Teams kommt?

Wie Jeff Sutherland kommentiert,^[63]

Da ich ursprünglich das Scrum von Scrums definiert habe (Ken Schwaber war bei IDX mit mir), kann ich definitiv sagen, dass das Scrum von Scrums kein "Metakrum" ist. Das Scrum von Scrums, wie ich es verwendet habe, ist dafür verantwortlich, die Arbeitssoftware aller Teams zur Definition von Fertig am Ende des Sprint oder für Veröffentlichungen während des Sprint zu liefern. Der Patientkeeper wurde viermal pro Sprint an die Produktion geliefert. Ancestry.com liefert 220 Mal pro zweiwöchiger Sprint. HubSpot liefert Live-Software 100-300 Mal am Tag. Das Scrum of Scrums Master wird für die Arbeit dieser Arbeit zur Rechenschaft gezogen. Das Scrum of Scrums ist also ein operativer Liefermechanismus.

Großer Scrum

Large-Scale Scrum (weniger) ist ein Produktentwicklungsrahmen, das Scrum mit Skalierungsregeln und Richtlinien erweitert, ohne die ursprünglichen Scrum-Zwecke zu verlieren.

Der Rahmen hat zwei Ebenen: Die erste weniger Ebene ist für bis zu acht Teams ausgelegt. Die zweite Ebene, bekannt als "weniger groß", führt mit bis zu Hunderten von Entwicklern zusätzliche Skalierungselemente für die Entwicklung ein. "Scaling Scrum beginnt mit dem Verständnis und der Möglichkeit, Standard-Real-One-Team-Scrum einzuschlagen. Große Scrum erfordert die Untersuchung des Zwecks von Single-Team-Scrum-Elementen und der Ermittlung des Erreichens des gleichen Zwecks, während Sie innerhalb der Einschränkungen des Standard-Scrum bleiben Regeln."^[66]

Bas Vodde und Craig Larman entwickelte den weniger Rahmen aus ihren Erfahrungen mit der groß angelegten Produktentwicklung, insbesondere in den Telekommunikations- und Finanzindustrien. Es entwickelte sich, indem es Scrum nahm und viele verschiedene Experimente ausprobierte, um herauszufinden, was funktioniert. Im Jahr 2013 wurden die Experimente in die weniger Rahmenregeln verfestigt.^[67] Die Absicht weniger ist es, die Komplexität der Organisation zu "des Unternehmens" der Organisation, unnötige komplexe organisatorische Lösungen aufzulösen und sie auf einfachere Weise zu lösen. Weniger Rollen, weniger Management, weniger organisatorische Strukturen.^[68]

Kritik

Es wurde berichtet, dass Scrum -Ereignisse verletzt sind Produktivität und Zeitverschwendung, die besser für tatsächliche produktive Aufgaben aufgewendet werden könnte,^[69][70] normalerweise verursacht durch ein Missverständnis des Zwecks und des Ziels des Ereignisses,^[71] So wird es eher als überwiegend gründliche Besprechung als als kurze Zeitbox-Diskussion durchgeführt. Scrum -Praktiken, wenn sie nicht korrekt im Geiste des Agiles Manifesteine Tendenz haben, eine Form von zu werden Mikromanagement^[72] und führen Sie die gleiche Funktionsstörung wieder ein, die die Praktiken entfernen wollten. Scrum setzt auch davon aus unberechenbar.^[73] Scrum lässt absichtlich präkriptive Praktiken aus^[74] Freiheit der empirischen Analyse und Experimente fördern. Scrum wird eher als eine Form von und eher als alternativer Ansatz für die Verwaltung von Projekten wahrgenommen. Ein anfänglicher Einstieg in Scrum führt nicht sofort zu qualitativ hochwertigen Ergebnissen. Ungeduld raubt Scrum der Chance, sich einzubetten und zu wachsen. Häufige dysfunktionale Ansätze^[75] Zu Scrum wurde jetzt als Antipatterns, einschließlich Dark Scrum, erkannt^[76] und schreien^[77]

Siehe auch

• Agile Tests
• Disziplinierte agile Lieferung
• Hochleistungsteams
• Lean Softwareentwicklung
• Projektmanagement
• Einheitlicher Prozess

Verweise

Weitere Lektüre

Externe Links

• Scrum Library der Agile Alliance
• Eine Scrum -Prozessbeschreibung durch das ECLIPSE Process Framework (EPF) -Projekt