Scrum (Softwareentwicklung) - Scrum (software development)

Software-Entwicklung
Hauptaktivitäten
Paradigmen und Modelle
Methoden und Rahmenbedingungen
Unterstützende Disziplinen
Praktiken Methoden Ausübungen
Werkzeuge
Standards und Wissensdatenbanken
Glossare
Umrisse

Scrum ist ein Framework für die Entwicklung, Bereitstellung und Aufrechterhaltung von Produkten in einer komplexen Umgebung mit einem anfänglichen Schwerpunkt auf der Softwareentwicklung , obwohl es in anderen Bereichen wie Forschung, Vertrieb, Marketing und fortschrittliche Technologien verwendet wird. Es ist für Teams mit zehn oder weniger Mitgliedern konzipiert, die ihre Arbeit in Ziele aufteilen, die in zeitlich begrenzten Iterationen, sogenannten Sprints , nicht länger als einen Monat und meistens zwei Wochen dauern können. Das Scrum-Team bewertet den Fortschritt in zeitlich begrenzten täglichen Meetings von 15 Minuten oder weniger, die als Daily Scrums bezeichnet werden. Am Ende des Sprints hält das Team zwei weitere Meetings ab: das Sprint-Review, das den Stakeholdern die geleistete Arbeit demonstriert, um Feedback zu erhalten, und die Sprint-Retrospektive, die es dem Team ermöglicht, zu reflektieren und sich zu verbessern.

Name

Der Softwareentwicklungsbegriff Scrum wurde erstmals 1986 in einem Artikel mit dem Titel "The New New Product Development Game" von Hirotaka Takeuchi und Ikujiro Nonaka verwendet . Das Papier wurde in der Januar 1986 Ausgabe der Harvard Business Review veröffentlicht . Der Begriff ist dem Rugby entlehnt , wo ein Gedränge eine Formation von Spielern ist. Der Begriff Scrum wurde von den Autoren des Papers gewählt, weil er Teamwork betont.

Scrum wird gelegentlich in Großbuchstaben geschrieben als SCRUM . Während das Wort selbst kein Akronym ist , stammt sein großgeschriebenes Styling wahrscheinlich von einem frühen Papier von Ken Schwaber , das SCRUM in seinem Titel großgeschrieben hat .

Während das Markenzeichen des Begriffs Scrum selbst verfallen ist, wird es als Eigentum der breiteren Gemeinschaft und nicht als Einzelperson angesehen.

Viele der in Scrum verwendeten Begriffe werden typischerweise in Großbuchstaben geschrieben (zB Scrum Master , Daily Scrum ). Um jedoch einen enzyklopädischen Ton beizubehalten, verwendet dieser Artikel für diese Begriffe die normale Groß-/Kleinschreibung (zB Scrum Master , Daily Scrum ) – es sei denn, es handelt sich um anerkannte Zeichen ( zB Certified Scrum Master und Professional Scrum Master ).

Schlüsselideen

Scrum ist ein leichtgewichtiges, iteratives und inkrementelles Framework für die Entwicklung, Bereitstellung und Aufrechterhaltung komplexer Produkte. Das Framework stellt Annahmen des traditionellen, sequenziellen Ansatzes bei der Produktentwicklung in Frage und ermöglicht es Teams, sich selbst zu organisieren, indem es die physische Co-Location oder enge Online-Zusammenarbeit aller Teammitglieder sowie die tägliche persönliche Kommunikation zwischen allen Teammitgliedern fördert und Disziplinen beteiligt.

Ein Schlüsselprinzip von Scrum ist die doppelte Erkenntnis, dass Kunden den Umfang des Gewünschten ändern (oft als Anforderungsvolatilität bezeichnet ) und dass es unvorhersehbare Herausforderungen geben wird – für die ein vorausschauender oder geplanter Ansatz nicht geeignet ist. Diese Veränderungen kommen aus einer Vielzahl von Quellen, aber es ist irrelevant zu verstehen, warum: Veränderungen sollten einfach akzeptiert, angenommen und auf ihren Nutzen hin analysiert werden.

Daher verfolgt Scrum einen evidenzbasierten empirischen Ansatz – akzeptiert, dass das Problem nicht vollständig verstanden oder im Voraus definiert werden kann, und konzentriert sich stattdessen darauf, die Fähigkeit des Teams zu maximieren, schnell zu liefern, auf aufkommende Anforderungen zu reagieren und sich an sich entwickelnde . anzupassen Technologien und Veränderungen der Marktbedingungen.

Geschichte

Hirotaka Takeuchi und Ikujiro Nonaka führten den Begriff Scrum im Zusammenhang mit der Produktentwicklung 1986 in ihrem Harvard Business Review- Artikel „The New New Product Development Game“ ein. Takeuchi und Nonaka argumentierten später in The Knowledge Creating Company, dass es sich um eine Form der "organisatorischen Wissenserzeugung handelt, die [...] besonders gut darin ist, Innovationen kontinuierlich, inkrementell und spiralförmig hervorzubringen".

Die Autoren beschrieben einen neuen Ansatz für kommerzielle Produktentwicklung , die Geschwindigkeit und Flexibilität von Unternehmen des Verarbeitenden Gewerbes in der Automobil-, Kopierer und Drucker auf Basis von Fallstudien erhöhen würde Industrien . Sie nannten dies den ganzheitlichen oder Rugby- Ansatz, da der gesamte Prozess von einem funktionsübergreifenden Team über mehrere sich überschneidende Phasen hinweg durchgeführt wird, in denen das Team "versucht, die Distanz als Einheit zu überwinden, indem es den Ball hin und her spielt". (Im Rugby-Fußball wird ein Gedränge verwendet, um das Spiel wieder aufzunehmen, da die Stürmer jeder Mannschaft mit gesenktem Kopf ineinandergreifen und versuchen, in Ballbesitz zu kommen.)

Das Scrum-Framework basierte auf Forschungen von Schwaber mit Babatunde Ogunnaike von der DuPont Research Station und der University of Delaware. Ogunnaike weist darauf hin, dass Versuche, komplexe Produkte wie Software zu entwickeln, die nicht auf Empirie basieren, zu höheren Risiken und Fehlerquoten verdammt sind, wenn sich die Ausgangsbedingungen und Annahmen ändern. Empirismus, durch häufige Überprüfung und Anpassung, mit Flexibilität und Transparenz, ist der am besten geeignete Ansatz.

In den frühen 1990er Jahren verwendete Ken Schwaber in seinem Unternehmen das spätere Scrum, Advanced Development Methods; während Jeff Sutherland , John Scumniotales und Jeff McKenna einen ähnlichen Ansatz bei der Easel Corporation entwickelten und sich auf ihn mit dem einzigen Wort Scrum bezogen.

Sutherland und Schwaber arbeiteten zusammen, um ihre Ideen in ein einziges Framework, Scrum, zu integrieren. Sie testeten Scrum und verbesserten es kontinuierlich, was zu ihrem Papier von 1995, Beiträgen zum Agile Manifest im Jahr 2001 und der weltweiten Verbreitung und Verwendung von Scrum seit 2002 führte.

1995 präsentierten Sutherland und Schwaber beim Business Object Design and Implementation Workshop im Rahmen von Object-Oriented Programming, Systems, Languages ​​& Applications '95 (OOPSLA '95) in Austin, Texas, gemeinsam ein Papier, in dem das Scrum-Framework beschrieben wurde . In den folgenden Jahren arbeiteten Schwaber und Sutherland zusammen, um dieses Material – mit ihren Erfahrungen und sich entwickelnden bewährten Verfahren – zu kombinieren, um das zu entwickeln, was als Scrum bekannt wurde.

2001 arbeitete Schwaber mit Mike Beedle zusammen , um die Methode in dem Buch Agile Software Development with Scrum zu beschreiben . Scrums Ansatz zur Planung und Steuerung der Produktentwicklung beinhaltet die Entscheidungsbefugnis auf der Ebene der Betriebseigenschaften und Gewissheiten.

2002 gründete Schwaber mit anderen die Scrum Alliance und richtete die Certified Scrum Akkreditierungsreihe ein. Schwaber verließ die Scrum Alliance Ende 2009 und gründete Scrum.org, das die parallele Akkreditierungsreihe Professional Scrum betreut .

Seit 2009 wird ein öffentliches Dokument namens The Scrum Guide von Schwaber und Sutherland veröffentlicht und aktualisiert. Es wurde 6-mal überarbeitet, die aktuelle Version ist November 2020.

Scrum-Team

Die grundlegende Einheit von Scrum ist ein kleines Team, bestehend aus einem Product Owner, einem Scrum Master und Entwicklern. Das Team ist selbstverwaltet, funktionsübergreifend und konzentriert sich auf ein Ziel nach dem anderen: das Produktziel.

Product Owner

Der Product Owner, der die Stakeholder des Produkts und die Stimme des Kunden (oder die Wünsche eines Ausschusses) vertritt, ist dafür verantwortlich, gute Geschäftsergebnisse zu erzielen. Daher ist der Product Owner verantwortlich für das Product Backlog und für die Maximierung des Wertes, den das Team liefert. Der Product Owner definiert das Produkt in Bezug auf kundenzentrierte Ergebnisse (normalerweise – aber nicht beschränkt auf – User Stories ), fügt sie dem Product Backlog hinzu und priorisiert sie basierend auf Wichtigkeit und Abhängigkeiten. Ein Scrum-Team sollte nur einen Product Owner haben (obwohl ein Product Owner mehr als ein Team unterstützen könnte) und es wird dringend davon abgeraten, diese Rolle mit der Rolle des Scrum Masters zu kombinieren. Der Product Owner sollte sich auf die geschäftliche Seite der Produktentwicklung konzentrieren und die meiste Zeit damit verbringen, mit Stakeholdern und dem Team in Kontakt zu treten. Der Product Owner schreibt nicht vor, wie das Team zu einer technischen Lösung gelangt, sondern sucht den Konsens unter den Teammitgliedern. Diese Rolle ist entscheidend und erfordert ein tiefes Verständnis beider Seiten: des Business und der Ingenieure (Entwickler) im Scrum-Team. Daher sollte ein guter Product Owner in der Lage sein, zu kommunizieren, was das Unternehmen braucht, zu fragen, warum sie es brauchen (weil es möglicherweise bessere Möglichkeiten gibt, dies zu erreichen) und die Botschaft bei Bedarf an alle Beteiligten, einschließlich der Entwickler, in technischer Sprache zu übermitteln. Der Product Owner verwendet die empirischen Tools von Scrum, um hochkomplexe Aufgaben zu bewältigen und gleichzeitig Risiken zu kontrollieren und Werte zu erzielen.

Kommunikation ist eine Kernaufgabe des Product Owners. Die Fähigkeit, Prioritäten zu vermitteln und sich in Teammitglieder und Stakeholder einfühlen zu können, ist entscheidend, um die Produktentwicklung in die richtige Richtung zu lenken. Die Rolle des Product Owners überbrückt die Kommunikationslücke zwischen dem Team und seinen Stakeholdern und dient als Stellvertreter der Stakeholder für das Team und als Teamvertreter für die gesamte Stakeholder-Community.

Als Gesicht des Teams gegenüber den Stakeholdern sind die folgenden Kommunikationsaufgaben des Product Owners gegenüber den Stakeholdern:

  • Releases definieren und ankündigen.
  • Liefer- und Produktstatus kommunizieren.
  • Teilen Sie den Fortschritt während der Governance-Meetings.
  • Teilen Sie wichtige RIDAs (Risiken, Hindernisse, Abhängigkeiten und Annahmen) mit Stakeholdern.
  • Verhandeln Sie Prioritäten, Umfang, Finanzierung und Zeitplan.
  • Stellen Sie sicher, dass das Product Backlog sichtbar, transparent und klar ist.

Empathie ist eine Schlüsseleigenschaft für einen Product Owner – die Fähigkeit, sich in die Lage eines anderen zu versetzen. Ein Product Owner unterhält sich mit unterschiedlichen Stakeholdern mit unterschiedlichen Hintergründen, Jobrollen und Zielen – und sollte diese unterschiedlichen Sichtweisen schätzen können. Um effektiv zu sein, ist es für einen Product Owner ratsam, den Detaillierungsgrad zu kennen, den das Publikum benötigt. Die Entwickler benötigen gründliches Feedback und Spezifikationen, damit sie ein Produkt gemäß den Erwartungen entwickeln können, während ein Executive Sponsor möglicherweise nur Zusammenfassungen des Fortschritts benötigt. Die Bereitstellung von mehr Informationen als nötig kann das Interesse der Stakeholder verlieren und Zeit verschwenden. Ein direktes Kommunikationsmittel wird von erfahrenen Product Ownern bevorzugt.

Die Fähigkeit eines Product Owners, effektiv zu kommunizieren, wird auch dadurch verbessert, dass er mit Techniken vertraut ist, die die Bedürfnisse von Stakeholdern identifizieren, Prioritäten zwischen den Stakeholder-Interessen aushandeln und mit Entwicklern zusammenarbeiten, um eine effektive Umsetzung der Anforderungen zu gewährleisten.

Entwickler

Die Entwickler führen in jedem Sprint alle erforderlichen Arbeiten durch, um Wertinkremente aufzubauen.

Der Begriff Entwickler bezieht sich auf jeden, der eine Rolle bei der Entwicklung und dem Support des Systems oder Produkts spielt, und kann unter anderem Forscher, Architekten, Designer, Datenspezialisten, Statistiker, Analysten, Ingenieure, Programmierer und Tester umfassen. Aufgrund der Verwirrung, die entstehen kann, wenn manche Leute der Meinung sind, dass der Begriff „Entwickler“ nicht auf sie zutrifft, werden sie oft nur als Teammitglieder bezeichnet .

Das Team organisiert sich selbst. Während dem Team keine Arbeit außer durch den Product Owner zufließen sollte und vom Scrum Master erwartet wird, das Team vor Ablenkungen zu schützen, wird das Team ermutigt, direkt mit Kunden und/oder Stakeholdern zu interagieren, um maximales Verständnis und Unmittelbarkeit des Feedbacks zu erlangen.

Scrum-Master

Scrum wird von einem Scrum-Master unterstützt, der dafür verantwortlich ist, Hindernisse für die Fähigkeit des Teams zu beseitigen, die Produktziele und Ergebnisse zu erreichen. Der Scrum Master ist kein klassischer Teamleiter oder Projektmanager, sondern fungiert als Barriere zwischen dem Team und allen ablenkenden Einflüssen. Der Scrum Master stellt sicher, dass dem Scrum-Framework gefolgt wird, indem er das Team in Scrum-Theorie und -Konzepten coacht, häufig wichtige Sitzungen moderiert und das Team ermutigt, zu wachsen und sich zu verbessern. Die Rolle wurde auch als Teammoderator oder Servant-Leader bezeichnet , um diese doppelten Perspektiven zu stärken.

Zu den Kernaufgaben eines Scrum Masters gehören (sind aber nicht beschränkt auf):

  • Unterstützung des Product Owners bei der Pflege des Product Backlogs auf eine Weise, die sicherstellt, dass die erforderliche Arbeit gut verstanden wird, damit das Team kontinuierlich Fortschritte machen kann
  • Unterstützung des Teams bei der Bestimmung der Definition von Done für das Produkt mit Input von wichtigen Stakeholdern
  • Coaching des Teams innerhalb der Scrum-Prinzipien, um qualitativ hochwertige Funktionen für sein Produkt bereitzustellen
  • Schulung der wichtigsten Stakeholder und des Rests der Organisation zu Scrum- (und möglicherweise agilen) Prinzipien
  • Unterstützung des Scrum-Teams bei der Vermeidung oder Beseitigung von Hindernissen für seinen Fortschritt, sei es innerhalb oder außerhalb des Teams
  • Förderung der Selbstorganisation und Cross-Funktionalität im Team
  • Moderation von Teamevents, um regelmäßige Fortschritte zu gewährleisten

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

Eine der Möglichkeiten , die Scrum Master Rolle unterscheidet sich von einem Projektmanager ist , dass letztere haben die Menschen Management Verantwortlichkeiten und die Scrum Master nicht. Ein Scrum Master bietet eine begrenzte Menge an Richtung, da von dem Team erwartet wird, dass es befähigt und selbstorganisiert ist. Scrum erkennt die Rolle des Projektmanagers nicht offiziell an, da traditionelle Befehls- und Kontrolltendenzen Schwierigkeiten bereiten würden.

Arbeitsablauf

Sprint

Scrum-Framework
Nicht zu verwechseln mit Hackathon § Code Sprints .
Der Scrum-Prozess

Ein Sprint (auch Iteration oder Timebox genannt ) ist die Grundeinheit der Entwicklung in Scrum. Der Sprint ist eine zeitlich begrenzte Anstrengung; das heißt, die Länge wird für jeden Sprint im Voraus vereinbart und festgelegt und beträgt normalerweise zwischen einer Woche und einem Monat, wobei zwei Wochen am häufigsten sind.

Jeder Sprint beginnt mit einem Sprint-Planungs- Event, in dem ein Sprint-Ziel erarbeitet wird und ein Sprint-Backlog entsteht, das die geplante Arbeit für den kommenden Sprint enthält. Jeder Sprint endet mit zwei Events:

  • ein Sprint-Review (Fortschritt, der den Stakeholdern gezeigt wird, um ihr Feedback zu erhalten)
  • eine Sprint-Retrospektive (Ermittlung von Lektionen und Verbesserungen für die nächsten Sprints).

Scrum betont wertvollen, nützlichen Output am Ende des Sprints, der wirklich erledigt ist. Im Falle von Software beinhaltet dies wahrscheinlich, dass die Produkte vollständig integriert, getestet und dokumentiert und potenziell releasefähig sind.

Sprintplanung

Zu Beginn eines Sprints veranstaltet das Scrum-Team eine Sprint-Planungsveranstaltung, um:

  • Vereinbaren Sie das Sprint-Ziel, eine kurze Beschreibung dessen, was sie bis zum Sprint-Ende prognostizieren, basierend auf den vom Product Owner festgelegten Prioritäten
  • Wählen Sie Product Backlog Items aus, die zu diesem Ziel beitragen
  • Bilden Sie ein Sprint-Backlog, indem Sie gemeinsam besprechen und vereinbaren, welche Aufgaben während dieses Sprints erledigt werden sollen

Die maximale Dauer der Sprintplanung beträgt acht Stunden für einen vierwöchigen Sprint. Während die Detailarbeit ausgearbeitet wird, können einige Product-Backlog-Elemente aufgeteilt oder in das Product-Backlog zurückgeführt werden, wenn das Team der Meinung ist, dass es diese Arbeit nicht in einem einzigen Sprint abschließen kann.

Tägliches Gedränge

Ein tägliches Gedränge im Computerraum. Dieser zentrale Standort hilft dem Team, pünktlich zu starten.

Jeden Tag während eines Sprints führen die Entwickler ein Daily Scrum (manchmal im Stehen durchgeführt ) mit spezifischen Richtlinien durch:

Alle Entwickler sind vorbereitet. Das tägliche Gedränge:

  • konzentriert sich auf die Überprüfung des Fortschritts in Richtung des Sprintziels
  • sollte jeden Tag zur gleichen Zeit und an jedem Ort passieren
  • ist begrenzt ( timeboxed ) auf fünfzehn Minuten
  • wird durchgeführt, aber das Team entscheidet
  • kann andere einschließen, obwohl nur Entwickler sprechen sollten.
  • kann durch den Scrum Master unterstützt werden
  • kann Hindernisse für den Fortschritt erkennen (z. B. Stolperstein, Risiko, Problem, verzögerte Abhängigkeit, Annahme als unbegründet)
  • bietet keine Diskussionen
  • ist kein Mittel zum Aktualisieren von Fortschrittsdiagrammen

Während des Daily Scrums sollten keine detaillierten Diskussionen stattfinden. Danach können die einzelnen Mitglieder Themen ausführlich besprechen, die oft als „Breakout Session“ oder „After Party“ bezeichnet werden. Identifizierte Blocker sollten außerhalb des Daily Scrum gemeinsam diskutiert werden, um auf eine Lösung hinzuarbeiten.

Wenn das Team den Wert dieses Ereignisses nicht erkennt, liegt es in der Verantwortung des Scrum-Masters zu bestimmen, warum und das Team und die Stakeholder über die Scrum-Prinzipien aufzuklären oder das Team zu ermutigen, eine eigene Methode zu entwickeln, um das Team vollständig über Sprint zu informieren Fortschritt.

Sprint-Review

Am Ende eines Sprints durchgeführt, hat das Team:

  • präsentiert die fertige Arbeit den Stakeholdern (auch bekannt als Demo )
  • arbeitet mit Stakeholdern zu Themen wie:
    • Einladen von Feedback zum abgeschlossenen Produktinkrement
    • Diskussion der Auswirkungen unvollständiger Arbeit (geplant oder anderweitig)
    • Erhalt von Vorschlägen für anstehende Arbeiten (Anleitung, woran als nächstes gearbeitet werden soll)

Product Owner sollten diese Veranstaltung als wertvolle Gelegenheit sehen, das Product Backlog mit Stakeholdern zu überprüfen und zu verfeinern.

Richtlinien für Sprint-Reviews:

  • Unvollständige Arbeiten sollten nicht nachgewiesen werden; Obwohl Interessenvertretern die Produktinkremente präsentiert werden sollten, die sie erhalten werden, können sie bei Bedarf auch anfordern, dass die laufenden Arbeiten eingesehen werden. Das Team sollte jedoch nur darauf vorbereitet sein, zu zeigen, was getan wurde.
  • Die empfohlene Dauer beträgt zwei Stunden für einen zweiwöchigen Sprint (anteilig für andere Sprint-Dauern).

Sprint-Retrospektive

Bei der Sprint-Retrospektive hat das Team:

Richtlinien für Sprint-Retrospektiven:

  • Drei empfohlene Bereiche, die bei Sprint-Retrospektiven berücksichtigt werden sollten, sind:
    • Was ist während des Sprints gut gelaufen?
    • Was ist nicht gut gelaufen?
    • Was könnten wir beim nächsten Sprint anders machen?
  • Die empfohlene Dauer beträgt eineinhalb Stunden für einen zweiwöchigen Sprint (anteilig für andere Sprintdauer(n)).

Der Scrum Master kann dieses Ereignis unterstützen, aber seine Anwesenheit wird nicht als obligatorisch angesehen.

Backlog-Verfeinerung

Obwohl es ursprünglich keine Scrum-Kernpraxis war, wurde die Backlog- Verfeinerung (früher als Grooming bezeichnet ) dem Scrum-Leitfaden hinzugefügt und als eine Möglichkeit zur Verwaltung der Qualität von Product-Backlog-Elementen, die in einen Sprint eingehen, übernommen. Es ist der laufende Prozess der Überprüfung und Ergänzung/Aktualisierung/Nachbestellung von Product Backlog Items im Lichte neuer Informationen.

Gründe für die Änderung des Backlogs und der darin enthaltenen Elemente können sein:

  • Größere Gegenstände können in mehrere kleinere aufgeteilt werden
  • Akzeptanzkriterien können geklärt werden
  • Abhängigkeiten können identifiziert und untersucht werden
  • Ein Gegenstand erfordert möglicherweise weitere Entdeckung und Analyse
  • Prioritäten können sich geändert haben; erwartete Renditen werden nun abweichen

Verfeinerung bedeutet, dass Items entsprechend aufbereitet und so angeordnet werden, dass sie für Entwickler für die Sprintplanung übersichtlich und ausführbar sind.

Der Rückstand kann auch technische Schulden (auch bekannt als Konstruktionsschulden oder Codeschulden) enthalten. Dies ist ein Konzept in der Softwareentwicklung, das die impliziten Kosten zusätzlicher Nacharbeit widerspiegelt, die dadurch verursacht werden, dass jetzt eine einfache Lösung gewählt wird, anstatt einen besseren Ansatz zu verwenden, der länger dauern würde.

Es wird empfohlen, bis zu 10 Prozent der Sprintkapazität eines Teams in die Verfeinerung des Backlogs zu investieren. Reifere Teams werden dies nicht als geplantes, definiertes Ereignis betrachten, sondern als Ad-hoc-Aktivität, die Teil des natürlichen Workflows ist und bei Bedarf das Produkt-Backlog verfeinert und anpasst.

Sprint abbrechen

Der Product Owner kann bei Bedarf einen Sprint abbrechen, und zwar mit Input von anderen (Entwickler, Scrum Master oder Management). Zum Beispiel können jüngste äußere Umstände den Wert des Sprintziels zunichte machen, so dass 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 Beendigung überprüft wird.

Artefakte

Produktrückstand

Das Product Backlog ist eine Aufschlüsselung der zu erledigenden Arbeit und enthält eine geordnete Liste von Produktanforderungen , die das Team für ein Produkt pflegt . Zu den gängigen Formaten für Backlog-Elemente gehören User Stories und Anwendungsfälle . Diese Anforderungen definieren Funktionen , Fehlerbehebungen , nicht funktionale Anforderungen usw. – was immer ein praktikables Produkt liefert. Der Product Owner priorisiert Product Backlog Items (PBIs) basierend auf Überlegungen wie Risiko, Geschäftswert, Abhängigkeiten, Größe und benötigtem Datum.

Das Product Backlog ist "was benötigt wird, geordnet nach wann es benötigt wird" und ist für jeden einsehbar, darf aber nur mit Zustimmung des Product Owners geändert werden, der für die Verwaltung und Pflege der Product Backlog Items verantwortlich ist.

Das Product Backlog enthält die Einschätzung des Geschäftswerts durch den Product Owner und kann die Einschätzung des Teams zu Aufwand oder Komplexität beinhalten, die oft, aber nicht immer, in Story Points unter Verwendung der gerundeten Fibonacci-Skala angegeben wird . Diese Schätzungen helfen dem Product Owner, den Zeitplan einzuschätzen und können die Bestellung von Product Backlog Items beeinflussen; Beispielsweise kann der Product Owner für zwei Features mit demselben Geschäftswert eine frühere Bereitstellung der Arbeit mit dem geringeren Entwicklungsaufwand (da der Return on Investment höher ist) oder die mit höherem Entwicklungsaufwand (da komplexer oder riskanter ist) planen , und sie möchten dieses Risiko früher abstellen).

Das Product Backlog und der Geschäftswert jedes Product Backlog Items liegen in der Verantwortung des Product Owners. Der Aufwand für die Lieferung jedes Artikels kann in Story Points oder Zeit geschätzt werden. Durch das Schätzen von Story Points reduziert das Team die Abhängigkeit einzelner Entwickler; Dies ist insbesondere für dynamische Teams nützlich, in denen Entwickler nach der Sprint-Bereitstellung häufig anderen Aufgaben zugewiesen werden. Wenn zum Beispiel eine User Story als Aufwand von 5 geschätzt wird (unter Verwendung der Fibonacci-Folge), bleibt sie 5, unabhängig davon, wie viele Entwickler daran arbeiten

Story Points definieren den Aufwand in einer Timebox, sodass sie sich mit der Zeit nicht ändern. Zum Beispiel kann eine Person in einer Stunde gehen, laufen oder klettern, aber der Aufwand ist eindeutig anders. Die Lückenprogression zwischen den Termen in der Fibonacci-Folge ermutigt das Team, sorgfältig überlegte Schätzungen abzugeben. Schätzungen von 1, 2 oder 3 implizieren ähnliche Bemühungen (1 ist trivial), aber wenn das Team eine 8 oder 13 (oder höher) schätzt, können die Auswirkungen sowohl auf die Leistung als auch auf das Budget erheblich sein. Der Wert der Verwendung von Story Points besteht darin, dass das Team sie wiederverwenden kann, indem es ähnliche Arbeit aus früheren Sprints vergleicht, aber es sollte anerkannt werden, dass die Schätzungen relativ 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öheren Fähigkeiten besteht.

Jedes Team sollte einen Product Owner haben, obwohl ein Product Owner in vielen Fällen mit mehr als einem Team zusammenarbeiten könnte. Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren. Der Product Owner sammelt Input und Feedback von vielen Leuten und wird von vielen Leuten genutzt, aber letztendlich hat er die endgültige Entscheidung darüber, was gebaut wird.

Das Produkt-Backlog:

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

Normalerweise arbeitet das gesamte Team zusammen, um das Product Backlog zu verfeinern, das sich entwickelt, wenn neue Informationen über das Produkt und seine Kunden auftauchen, und so können spätere Sprints neue Aufgaben angehen.

Verwaltung

Ein Product Backlog ist in seiner einfachsten Form lediglich eine Liste von Elementen, an denen gearbeitet werden muss. Gut etablierte Regeln für das Hinzufügen, Entfernen und Ordnen von Arbeit helfen dem gesamten Team, bessere Entscheidungen darüber zu treffen, wie das Produkt geändert werden soll.

Der Product Owner priorisiert Product Backlog Items basierend darauf, welche am ehesten benötigt werden. Entwickler, die vom Sprint-Ziel beeinflusst werden, wählen Elemente für den kommenden Sprint aus und verschieben diese Elemente aus dem Produkt-Backlog in das Sprint-Backlog, das ist die Liste der Elemente, die sie erstellen werden. Konzeptionell wird das Sprintziel von Elementen mit hoher Priorität an der Spitze der Liste beeinflusst, aber es ist nicht ungewöhnlich, dass Entwickler einige Elemente mit niedrigerer Priorität verwenden, wenn innerhalb des Sprints noch Zeit bleibt, um mehr Arbeit aufzunehmen.

Elemente mit hoher Priorität (am Anfang des Backlogs) sollten in weitere Details unterteilt werden, die für die Entwickler geeignet sind, an denen sie arbeiten können. Je weiter unten im Backlog, desto weniger detailliert werden die Elemente sein. Wie Schwaber und Beedle es ausdrücken: "Je niedriger die Priorität, desto weniger Details, bis Sie das Backlog-Item kaum erkennen können."

Während das Team den Rückstand abarbeitet, muss davon ausgegangen werden, dass Veränderungen außerhalb seiner Umgebung stattfinden – das Team kann sich über neue Marktchancen, auftretende Wettbewerbsbedrohungen und Feedback von Kunden informieren, die die Art und Weise, wie das Produkt gedacht war, verändern können arbeiten. All diese neuen Ideen veranlassen das Team dazu, den Rückstand anzupassen, um neues Wissen zu integrieren. Dies ist Teil der grundlegenden Denkweise eines agilen Teams. Die Welt verändert sich, der Rückstand ist nie fertig.

Sprint-Backlog

Das Sprint-Backlog ist die Teilmenge der Elemente aus dem Produkt-Backlog, die Entwickler im kommenden Sprint bearbeiten sollen. Entwickler werden diesen Rückstand auffüllen, bis sie der Meinung sind, dass sie genug Arbeit haben, um den Sprint zu füllen, und verwenden die Leistung der Vergangenheit, um die Kapazität für den nächsten Sprint zu bewerten, und verwenden dies als Richtlinie dafür, wie viel „Aufwand“ sie bewältigen können.

Die Arbeit am Sprint-Backlog wird niemals Entwicklern zugewiesen (oder gepusht); Teammitglieder ziehen Arbeit nach Bedarf entsprechend der Priorität des Rückstands und ihren eigenen Fähigkeiten und Kapazitäten. Dies fördert die Selbstorganisation der Entwickler.

Das Sprint-Backlog ist Eigentum der Entwickler und alle enthaltenen Schätzungen werden von den Entwicklern bereitgestellt. Obwohl nicht Teil von Scrum, verwenden einige Teams ein begleitendes Board, um den Arbeitsstand im aktuellen Sprint zu visualisieren: ToDo, Doing, Done.

Zuwachs

Das Inkrement ist die potenziell freisetzbare Ausgabe des Sprints, die das Sprintziel erfüllt. Es wird aus allen abgeschlossenen Sprint-Backlog-Items gebildet, integriert mit der Arbeit aller vorherigen Sprints. Das Inkrement muss gemäß der Definition of done (DoD) des Scrum-Teams vollständig, voll funktionsfähig und in einem brauchbaren Zustand sein, unabhängig davon, ob sich der Product Owner für die tatsächliche Bereitstellung und Nutzung entscheidet.

Erweiterungen

Die folgenden Artefakte und Techniken können verwendet werden, um Benutzern bei der Verwendung von Scrum zu helfen.

Burndown-Chart

Ein Beispiel für ein Burndown-Diagramm für einen abgeschlossenen Sprint, das die verbleibende Anstrengung am Ende jedes Tages anzeigt.
Hauptartikel: Burn-Down-Chart

Ein Burndown-Diagramm wird oft in Scrum verwendet (aber nicht Teil von Scrum). Es ist ein öffentlich angezeigtes Diagramm, das die verbleibende Arbeit zeigt. Es wird täglich aktualisiert und bietet schnelle Visualisierungen als Referenz. Die horizontale Achse des Burndown-Diagramms zeigt die verbleibenden Tage, während die vertikale Achse die verbleibende Arbeit pro Tag zeigt.

Während der Sprintplanung wird das ideale Burndown-Chart erstellt. Während des Sprints aktualisieren die Entwickler das Diagramm dann mit der verbleibenden Arbeit, sodass das Diagramm Tag für Tag aktualisiert wird und einen Vergleich zwischen Ist und Vorhersage zeigt.

Es sollte nicht mit einem Ertragswertdiagramm verwechselt werden .

Burn-up-Chart freigeben

Ein Beispiel für ein Burn-up-Diagramm für ein Release, das den Umfang jedes Sprints zeigt (MVP = Minimum Viable Product)

Das Burn-up-Diagramm der Veröffentlichung ist eine Möglichkeit für das Team, Transparenz zu schaffen und den Fortschritt in Richtung einer Veröffentlichung zu verfolgen. Es wird am Ende jedes Sprints aktualisiert und zeigt den Fortschritt bei der Bereitstellung eines Prognoseumfangs an. Die horizontale Achse des Release-Burn-up-Diagramms zeigt die Sprints in einem Release, während die vertikale Achse den am Ende jedes Sprints abgeschlossenen Arbeitsaufwand zeigt (in der Regel die kumulierten Story Points der abgeschlossenen Arbeit). Der Fortschritt wird als Linie dargestellt, die bis zu einer horizontalen Linie wächst, die den Prognoseumfang darstellt. wird oft mit einer Prognose angezeigt, die auf dem bisherigen Fortschritt basiert und angibt, wie viel Umfang bis zu einem bestimmten Veröffentlichungsdatum abgeschlossen sein könnte oder wie viele Sprints erforderlich sind, um den angegebenen Umfang abzuschließen.

Das Release-Burn-Up-Diagramm macht es einfach zu sehen, wie viel Arbeit abgeschlossen wurde, wie viel Arbeit hinzugefügt oder entfernt wurde (wenn sich die horizontale Ziellinie verschiebt) und wie viel Arbeit noch zu erledigen ist.

Definition von ready (DoR)

Die Startkriterien, um zu bestimmen, ob die Spezifikationen und Eingaben ausreichend gesetzt sind, um das Workitem zu starten.

Definition of done (DoD)

Die Exit-Kriterien , um zu bestimmen, ob die Arbeit an einem Sprint-Backlog-Element abgeschlossen ist, zum Beispiel: Das DoD erfordert, dass alle Regressionstests erfolgreich sind. Die Definition von Done kann von einem Team zum anderen variieren, muss jedoch innerhalb eines Teams konsistent sein.

Geschwindigkeit

Der Gesamtkapazitätsaufwand eines Teams für einen einzelnen Sprint, abgeleitet aus der Bewertung der im letzten Sprint abgeschlossenen Arbeit. Die Sammlung historischer Geschwindigkeitsdaten ist eine Richtlinie, die dem Team hilft, seine Kapazität zu verstehen, dh wie viel Arbeit es bequem erledigen kann.

Diese Metrik hat in der Scrum-Community Kontroversen ausgelöst:

  • Verbrauchte Story Points entsprechen nicht dem gelieferten Wert : Das Team sieht möglicherweise die geleistete Arbeit und ignoriert die für die Stakeholder zu erbringenden Vorteile
  • Einführung von ablenkenden Praktiken: Schätzung vs. Ist, Varianzuntersuchung und Politik der Neuschätzungen beginnen sich zu entwickeln
  • Das Management sieht Geschwindigkeit als Leistungskennzahl und versucht, diese zu erhöhen, was bedeutet:
    • die Qualität leidet - das Team beginnt, "Ecken zu kürzen", um die zusätzliche Arbeitsbelastung einzubeziehen
    • die Moral leidet - das Team kann nicht in einem angenehmen, nachhaltigen Tempo arbeiten und erhöhter Druck verursacht Burn-out
    • Schätzung leidet - Entwickler werden Schätzungen aufblähen, um Puffer einzubauen und die Metriken zu "spielen", indem sie den gleichen Aufwand auf einer anderen Skala messen
    • der Wert leidet – der Endeffekt ist eine Störung, die die Unzufriedenheit der Interessengruppen verursacht, weil der Fokus von der Bereitstellung des Geschäftswerts abweicht

Es ist zwar von Wert, die Leistungsfähigkeit eines Teams zu verstehen, die Geschwindigkeit sollte jedoch als Indikator für das Team und nicht als Wählscheibe betrachtet werden, die angepasst werden kann.

Spitze

Ein zeitlich begrenzter Zeitraum, der verwendet wird, um ein Konzept zu erforschen oder einen einfachen Prototyp zu erstellen. Spikes können entweder zwischen Sprints geplant werden oder bei größeren Teams als eines von vielen Sprint Delivery-Zielen akzeptiert werden. Spikes werden oft vor der Auslieferung großer oder komplexer Product Backlog Items eingeführt, um Budgets zu sichern, Wissen zu erweitern oder einen Proof of Concept zu erstellen. Dauer und Ziel(e) eines Spikes werden vom Team vor dem Start vereinbart. Im Gegensatz zu Sprint-Verpflichtungen können Spikes greifbare, auslieferbare, wertvolle Funktionen liefern oder auch nicht. Das Ziel eines Spikes kann beispielsweise darin bestehen, erfolgreich eine Entscheidung über eine Vorgehensweise zu treffen. Der Spike ist vorbei, wenn die Zeit abgelaufen ist, nicht unbedingt, wenn das Objektiv geliefert wurde.

Leuchtspurkugel

Ein Tracer-Geschoss, auch Drohnen-Spike genannt, ist ein Spike mit der aktuellen Architektur, dem aktuellen Technologiesatz und den aktuellen Best Practices, die zu einem Code in Produktionsqualität führen. Es kann nur eine sehr enge Implementierung der Funktionalität sein, aber kein Wegwerfcode. Es hat Produktionsqualität und die restlichen Iterationen können auf diesem Code aufbauen. Der Name hat militärischen Ursprung als Munition , die den Lauf der Kugel sichtbar macht und Korrekturen ermöglicht. Oftmals sind diese Implementierungen ein „Schnellschuss“ durch alle Ebenen einer Anwendung, z.

Einschränkungen

Die Vorteile von Scrum können schwieriger zu erreichen sein, wenn:

  • Teams, deren Mitglieder geografisch verteilt sind oder Teilzeit arbeiten : In Scrum sollten Entwickler eine enge und kontinuierliche Interaktion haben und idealerweise die meiste Zeit im selben Raum zusammenarbeiten. Während die jüngsten technologischen Verbesserungen die Auswirkungen dieser Hindernisse verringert haben (z. B. die Möglichkeit, an einem digitalen Whiteboard zusammenzuarbeiten), behauptet das Agile-Manifest, dass die beste Kommunikation von Angesicht zu Angesicht stattfindet.
  • Teams, deren Mitglieder sehr spezialisierte Fähigkeiten haben : In Scrum sollten Entwickler T-förmige Fähigkeiten haben , die es ihnen ermöglichen, an Aufgaben außerhalb ihrer Spezialisierung zu arbeiten. Dies kann durch eine gute Scrum-Führung gefördert werden. Während Teammitglieder mit sehr spezifischen Fähigkeiten einen guten Beitrag leisten können und tun, sollten sie ermutigt werden, mehr über andere Disziplinen zu lernen und mit ihnen zusammenzuarbeiten.
  • Produkte mit vielen externen Abhängigkeiten : In Scrum erfordert die Aufteilung der Produktentwicklung in kurze Sprints eine sorgfältige Planung; externe Abhängigkeiten, wie User Acceptance Testing oder Abstimmung mit anderen Teams, können zu Verzögerungen und dem Scheitern einzelner Sprints führen.
  • Produkte, die reife oder Vermächtnis oder mit geregelter Qualitätskontrolle : In Scrum, vollständig in einem einzigen Sprint - Schritt Produkt entwickelt und getestet werden sollten; Produkte, die für jedes Release große Mengen an Regressionstests oder Sicherheitstests erfordern (z. B. medizinische Geräte oder Fahrzeugkontrolle), sind weniger für kurze Sprints geeignet als für längere Wasserfall- Releases.

Werkzeuge verfügbar

Hauptartikel: Vergleich von Scrum-Software

Wie bei anderen agilen Ansätzen kann die effektive Einführung von Scrum durch eine breite Palette verfügbarer Tools unterstützt werden (jedoch nicht davon abhängig).

Viele Unternehmen verwenden universelle Tools wie Tabellenkalkulationen, um ein Sprint-Backlog aufzubauen 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 Papierform wie Papier, Whiteboards und Haftnotizen.

Scrum-Werte

Scrum ist ein feedbackgetriebener empirischer Ansatz, der wie jede empirische Prozesssteuerung auf den drei Säulen Transparenz, Inspektion und Anpassung basiert. Alle Arbeiten innerhalb des Scrum-Frameworks sollten für die für das Ergebnis verantwortlichen Personen sichtbar sein: der Prozess, der Workflow, der Fortschritt usw. Um diese Dinge sichtbar zu machen, müssen Scrum-Teams häufig das zu entwickelnde Produkt und die Leistungsfähigkeit des Teams überprüfen Arbeiten. Durch häufige Inspektionen kann das Team erkennen, wenn seine Arbeit von akzeptablen Grenzen abweicht und seinen Prozess oder das in Entwicklung befindliche Produkt anpassen.

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

  1. Engagement: Teammitglieder verpflichten sich individuell, ihre Teamziele in jedem Sprint zu erreichen .
  2. Mut: Teammitglieder wissen, dass sie den Mut haben, Konflikte und Herausforderungen gemeinsam zu meistern, damit sie das Richtige tun können.
  3. Fokus: Teammitglieder konzentrieren sich ausschließlich auf ihre Teamziele und das Sprint-Backlog; es sollte keine andere Arbeit als durch ihren Rückstand geleistet werden.
  4. Offenheit: Die Teammitglieder und ihre Stakeholder verpflichten sich, ihre Arbeit und alle Herausforderungen, denen sie sich gegenübersehen, transparent zu machen.
  5. Respekt: ​​Die Teammitglieder respektieren sich gegenseitig, um technisch fähig zu sein und mit gutem Willen zu arbeiten.

Anpassungen

Die Hybridisierung von Scrum mit anderen Softwareentwicklungsmethoden ist üblich, da Scrum nicht den gesamten Produktentwicklungslebenszyklus abdeckt ; Daher müssen Unternehmen zusätzliche Prozesse hinzufügen, um eine umfassendere Implementierung zu erzielen. Zum Beispiel fügen Unternehmen zu Beginn der Produktentwicklung in der Regel Prozessleitlinien zum Geschäftsszenario, zur Erfassung und Priorisierung von Anforderungen, zum ersten High-Level-Design sowie zur Budget- und Terminprognose hinzu.

Verschiedene Autoren und Gemeinschaften von Menschen, die Scrum verwenden, haben auch detailliertere Techniken vorgeschlagen, wie Scrum an bestimmte Probleme oder Organisationen angewendet oder angepasst werden kann. Viele bezeichnen diese methodischen Techniken als „Muster“ – in Analogie zu Entwurfsmustern in Architektur und Software.

Scrumban

Hauptartikel: Scrumban

Scrumban ist ein Software-Produktionsmodell basierend auf Scrum und Kanban . Scrumban eignet sich besonders für die Produktpflege mit häufigen und unerwarteten Arbeitsaufgaben, wie beispielsweise Produktionsfehlern oder Programmierfehlern. In solchen Fällen können die zeitlich begrenzten Sprints des Scrum-Frameworks als weniger nützlich empfunden werden, obwohl die täglichen Ereignisse und anderen Praktiken von Scrum je nach Team und Situation weiterhin angewendet werden können. Die Visualisierung der Arbeitsschritte und Einschränkungen bei gleichzeitiger Unfertigkeit und Mängel sind aus dem Kanban-Modell bekannt. Mit diesen Methoden wird der Arbeitsablauf des Teams so gelenkt , dass für jedes Arbeitselement oder jeden Programmierfehler eine minimale Bearbeitungszeit möglich ist und andererseits sichergestellt wird, dass jedes Teammitglied ständig beschäftigt ist.

Um jeden Arbeitsschritt zu veranschaulichen, verwenden Teams, die im selben Raum arbeiten, häufig Haftnotizen oder ein großes Whiteboard. Bei dezentralen Teams kann Bühnen-Illustrationssoftware wie Assembla , Jira oder Agilo verwendet werden.

Der Hauptunterschied zwischen Scrum und Kanban besteht darin, dass die Arbeit in Scrum in Sprints unterteilt ist, die eine festgelegte Zeit dauern, während der Arbeitsfluss in Kanban kontinuierlich ist. Dies ist in Arbeitsphasentabellen sichtbar, die in Scrum nach jedem Sprint geleert werden, während in Kanban alle Aufgaben auf derselben Tabelle markiert sind. Scrum konzentriert sich auf Teams mit vielseitigem Know-how, während Kanban spezialisierte, funktionale Teams ermöglicht.

Scrum von Scrums

Scrum of Scrums ist eine Technik, um Scrum in großem Maßstab für mehrere Teams zu betreiben, die an demselben Produkt arbeiten, und es ihnen ermöglicht, den Fortschritt ihrer gegenseitigen Abhängigkeiten zu diskutieren und sich auf die Koordinierung der Bereitstellung von Software zu konzentrieren, insbesondere auf Bereiche mit Überschneidungen und Integration. Je nach Kadenz (Timing) des Scrum of Scrums endet das jeweilige Daily Scrum für jedes Scrum-Team mit der Benennung eines Mitglieds als Botschafter zur Teilnahme am Scrum of Scrums mit Botschaftern anderer Teams. Je nach Kontext können die Botschafter technische Mitarbeiter oder der Scrum Master jedes Teams sein.

Anstatt nur ein Fortschrittsupdate zu machen, sollte sich das Scrum of Scrums darauf konzentrieren, wie Teams kollektiv arbeiten, um identifizierte Risiken, Hindernisse, Abhängigkeiten und Annahmen (RIDAs) zu lösen, zu mindern oder zu akzeptieren. Das Gedränge von Scrums verfolgt diese Ridas über einen Rückstand der eigenen, wie ein Risikokarte (manchmal als bekannt ROAM Brett nach den Initialen der aufgelösten, besessen, akzeptiert und gemildert), die in der Regel führt zu einem stärkeren Koordinierung und Zusammenarbeit zwischen den Teams .

Dies sollte ähnlich wie bei einem Daily Scrum ablaufen, bei dem jeder Botschafter die folgenden vier Fragen beantwortet:

  • Welche Risiken, Hindernisse, Abhängigkeiten oder Annahmen hat Ihr Team seit unserem letzten Treffen gelöst?
  • Welche Risiken, Hindernisse, Abhängigkeiten oder Annahmen wird Ihr Team lösen, bevor wir uns wiedersehen?
  • Gibt es neue Risiken, Hindernisse, Abhängigkeiten oder Annahmen, die Ihr Team verlangsamen oder ihnen im Weg stehen?
  • Sind Sie dabei, ein neues Risiko, Hindernis, Abhängigkeit oder Annahme einzuführen, die einem anderen Team in die Quere kommt?

Wie Jeff Sutherland kommentierte,

Da ich Scrum of Scrums ursprünglich definiert habe (Ken Schwaber arbeitete bei IDX mit mir), kann ich definitiv sagen, dass Scrum of Scrums kein „Meta-Scrum“ ist. Das Scrum of Scrums, wie ich es verwendet habe, ist dafür verantwortlich, die funktionierende Software aller Teams nach der Definition of Done am Ende des Sprints oder für Releases während des Sprints zu liefern. PatientKeeper lieferte viermal pro Sprint an die Produktion. Ancestry.com liefert 220 Mal pro zweiwöchigem Sprint an die Produktion. Hubspot liefert 100-300 Mal am Tag Live-Software. Der Scrum of Scrums Master ist dafür verantwortlich, dass dies funktioniert. Scrum of Scrums ist also ein operativer Bereitstellungsmechanismus.

Scrum im großen Maßstab

Large-scale Scrum (LeSS) ist ein Produktentwicklungs-Framework, das Scrum um Skalierungsregeln und -richtlinien erweitert, ohne den ursprünglichen Zweck von Scrum zu verlieren.

Es gibt zwei Ebenen des Frameworks: Die erste LeSS-Ebene ist für bis zu acht Teams ausgelegt; Die zweite Ebene, bekannt als 'LeSS Huge', führt zusätzliche Skalierungselemente für die Entwicklung mit bis zu Hunderten von Entwicklern ein. „Die Skalierung von Scrum beginnt mit dem Verständnis und der Fähigkeit, standardmäßiges echtes Ein-Team-Scrum zu übernehmen. Großes Scrum erfordert, den Zweck von Scrum-Elementen für einzelne Teams zu untersuchen und herauszufinden, wie man denselben Zweck erreicht, während man die Einschränkungen des Standard-Scrums einhält Regeln."

Bas Vodde und Craig Larman haben das LeSS-Framework aus ihren Erfahrungen mit groß angelegter Produktentwicklung, insbesondere in der Telekommunikations- und Finanzbranche, entwickelt. Es hat sich entwickelt, indem man Scrum genommen und viele verschiedene Experimente ausprobiert hat, um herauszufinden, was funktioniert. 2013 wurden die Experimente in den LeSS-Rahmenregeln verfestigt. Die Absicht von LeSS besteht darin, die Komplexität der Organisation zu „entskalieren“, unnötige komplexe organisatorische Lösungen aufzulösen und sie auf einfachere Weise zu lösen. Weniger Rollen, weniger Management, weniger Organisationsstrukturen.

Kritikpunkte

Scrum ist oft unter Beschuss geraten, hauptsächlich durch diejenigen, die Konzepte schlecht anwenden, aber die gleichen Ergebnisse erwarten, oder die kulturellen Veränderungen, die Scrum erfordert, missverstehen:

  • Es wurde berichtet, dass Scrum-Ereignisse die Produktivität beeinträchtigen und Zeit verschwenden, die besser für tatsächliche produktive Aufgaben verwendet werden könnte, normalerweise verursacht durch ein Missverständnis des Zwecks und Ziels des Ereignisses .
  • Scrum-Praktiken neigen , wenn sie nicht im Geiste des agilen Manifests korrekt befolgt werden , dazu, zu einer Form des Mikromanagements zu werden und dieselbe Dysfunktion wieder einzuführen, die die Praktiken beseitigen wollten.
  • Scrum geht auch davon aus, dass der Aufwand für die Erledigung von Arbeiten genau abgeschätzt werden kann, obwohl dies häufig recht unvorhersehbar sein kann .
  • Scrum verzichtet bewusst auf präskriptive Praktiken, um die Freiheit empirischer Analysen und Experimente zu fördern.
  • Scrum wird eher als eine Form des Managements von Projekten und nicht als ein alternativer Ansatz wahrgenommen.
  • Ein erster Vorstoß in Scrum führt nicht sofort zu qualitativ hochwertigen Ergebnissen; Ungeduld beraubt Scrum der Chance, sich einzubetten und zu wachsen.

Gängige dysfunktionale Ansätze für Scrum wurden inzwischen als Antimuster erkannt, darunter Dark Scrum und Scream

Siehe auch

Verweise

Weiterlesen

Externe Links