WikiDer > Scrum (Softwareentwicklungsmethode)

Scrum (softwareontwikkelmethode)

Gedränge ist ein Framework zur flexiblen Herstellung von (Software-)Produkten. Multidisziplinär arbeiten Mannschaften die in kurzen Sprints funktionierende (Software-)Produkte mit einer festen Länge von 1 bis 4 Wochen liefern. Gedränge ist ein Begriff, der aus dem Rugby-Sport. In einem Gedränge versucht ein Team gemeinsam ein Ziel zu erreichen und das Spiel zu gewinnen. Zusammenarbeit ist sehr wichtig und man muss schnell auf sich ändernde Umstände reagieren können.

Scrum kommt häufig bei Produkten zum Einsatz, von denen der Kunde oder Anwender noch nicht weiß, was er will und bei denen Menschen lernen, die Anforderungen und Wünsche besser zu beschreiben und in brauchbare Produkte umzuwandeln. Oft wissen die Leute erst, was sie wollen, wenn sie das erste Produkt haben, das Prototyp, und dann werden die Anforderungen noch angepasst. Scrum hat die Flexibilität, auf sich ändernde Anforderungen und Wünsche einzugehen. Scrum fällt unter die Agile Software Entwicklung.

Geschichte

Scrum wurde in einer Studie von Ikujiro Nonaka und Hirotaka Takeuchi eingeführt, die Anfang 1986 in der Harvard Business Review wurde veröffentlicht. Diese Forschung beschreibt, dass Projekte mit kleinen (multidisziplinären) Teams in der Vergangenheit die besten Ergebnisse erbracht haben. Als Ergebnis dieser Forschung entwickelte Jeff Sutherland 1993 den Scrum-Prozess, während Ken Schwaber seinen eigenen Ansatz auf sein Unternehmen anwendete. Gemeinsam entwickelten sie dies weiter und 1995 formalisierte Ken Schwaber Scrum als Softwareentwicklungsmethode. Scrum wurde in den USA entwickelt und wird oft in teilweise englischsprachigen Projekten verwendet, daher die englische Terminologie.

Scrum-Methode

Ziele

  • In kurzen Sprints schnell funktionierende Produkte liefern, damit schnell klar wird, ob es den Menschen gut geht. Dies begrenzt die Risiken von Langzeitprojekten, bei denen Anwender oder Kunden das Ergebnis manchmal erst nach einem Jahr sehen und ausprobieren können.
  • Schnelle Klarheit über den Fortschritt.
  • Kurze Wege, schnelle Kommunikation, Teamwork.
  • Stärkere Einbindung der Teammitglieder, Konzentration auf einen klaren Teil des Projekts

Theorie

Scrum basiert auf der Theorie der empirischen Prozesssteuerung oder dem Empirismus.Der Empirismus geht davon aus, dass Wissen aus Erfahrungen und Entscheidungen auf der Grundlage von Wissen entsteht. Scrum verwendet einen iterativen, inkrementellen Ansatz, um die Vorhersehbarkeit zu optimieren und Risiken zu managen.
Drei Säulen bilden die Grundlage jeder empirischen Prozesssteuerungsimplementierung:
Transparenz, Kontrolle und Anpassung

Annahmen

Scrum hat die folgenden Prinzipien:

  • Engagement: Die Mitglieder müssen sich voll und ganz dafür einsetzen; es ist kein teilzeitjob.
  • Fokus: man muss zu konzentrieren was in den Sprints zu tun ist.
  • Offenheit: Menschen müssen sich gegenseitig gut über Fortschritte und mögliche Probleme informieren. (Transparenz)
  • Respekt: ​​Menschen mit einem anderen Hintergrund und Fachwissen sollten respektiert werden.
  • Mut: Man muss den Mut haben, Dinge zu benennen, Fragen zu stellen und neue Lösungen zu finden.

Methode

Scrum arbeitet mit multidisziplinären Teams, die vorzugsweise in einem Raum arbeiten, damit Diskussionen problemlos geführt werden können. Das Team wird geführt von a Scrum-Master, die eine unterstützende Rolle spielt. Das Product Owner oder Product Owner, ist der Kunde oder Auftraggeber oder dessen Vertreter. Er oder sie spezifiziert die gewünschten Ergebnisse, in der Regel in Form von benutzergeschichten. Diese User Stories werden in einer Liste geführt, die Produktrückstand oder Arbeitsvorrat. Der Product Owner sortiert die Arbeitswarteschlange nach Priorität. Die wichtigsten User Stories stehen ganz oben.

Arbeiten in Sprints oder Iterationen. Diese dauern in der Regel etwa eine Woche bis zu einem Monat, wobei eine Dauer von zwei Wochen am häufigsten ist. Sprints sind Zeitboxen. Mit anderen Worten: Es wird im Voraus festgelegt, wie lange ein Sprint dauert und wann er endet. Zu Beginn eines Sprints werden die User Stories für diesen Sprint ermittelt und im Sprint-Backlog.

Sprints führen zu möglichst greifbaren Ergebnissen. zw. Softwareentwicklung kann sich auf verwendbaren Code beziehen, einschließlich Integration, Test und Dokumentation, und ist vorzugsweise auf den Kunden oder Endbenutzer anwendbar.

Am Ende eines Sprints, a Sprint-Review Platz und zeigt das Ergebnis dem Product Owner. Außerdem findet eine Evaluation innerhalb des Teams statt.

Rollen

Scrum hat die folgenden drei Hauptrollen.[1] Diese sind:

Product Owner
Der Product Owner ist der Auftraggeber oder Kunde. Er/sie hat das größte Interesse an dem entstehenden (Software-)Produkt. Er/sie sorgt dafür, dass die Rechnung bezahlt wird. Sie verwaltet auch das Product Backlog und legt fest, was in welcher Reihenfolge zu tun ist. Grundsätzlich beginnen wir mit dem Wichtigsten, mit dem wir den größten Nutzen erzielen, das ganz oben im Product Backlog steht.
Entwicklungsteam / Expertenteam
Das Entwicklungsteam ist multidisziplinär und für die Auslieferung des (Software-)Produkts am Ende jedes Sprints verantwortlich. Das Team besteht in der Regel aus 3 bis 9 Personen. Das Team organisiert sich selbst. Sie übernehmen die Analyse, das Design, die Entwicklung, das Testen und die Dokumentation und sorgen dafür, dass am Ende des Sprints ein fertiges Produkt steht, das im Prinzip in Serie gehen kann.
Scrum-Master
Der Scrum Master führt und unterstützt das Team, indem er sicherstellt, dass der richtige Scrum-Prozess befolgt wird. Er bietet auch jede Ausbildung an. Der Scrum Master organisiert alle Meetings. Er richtet auch die Einrichtungen wie einen Arbeitsplatz, Hard- und Software ein. Der Scrum Master sorgt dafür, dass das Team nicht von Dritten belästigt wird, die zusätzliche Anforderungen stellen oder beispielsweise vorübergehend Personen aus dem Team benötigen. Der Scrum Master ist nicht ein Projektmanager. Er kümmert sich beispielsweise nicht um Personalangelegenheiten wie Auswahl, Beurteilung und Entlohnung der Personen. Dies fördert Offenheit und Kooperation.

Scrum-Rituale

tägliches Gedränge

Das Daily Scrum oder Stand-Up: Alle stehen!

Jeden Tag gibt es das "Daily Scrum" oder "Stand-up". Für dieses Treffen gelten folgende Regeln:

  • Alle Mitglieder des Entwicklungsteams haben sich auf das Meeting vorbereitet.
  • Das Meeting beginnt pünktlich, auch wenn nicht alle anwesend sind.
  • Das Treffen findet jeden Tag genau zur gleichen Zeit und am gleichen Ort statt, in der Regel um 9:00 Uhr im Projektraum.
  • Die Sitzung dauert maximal 15 Minuten, kürzer ist auch zulässig.
  • Das Meeting wird im Stehen abgehalten: „stand-up“, so dass es bereits einfach auf 15 Minuten begrenzt ist. Ähnlich wie bei einem Treffen zwischen Sportlern zu Beginn beispielsweise eines Rugby-Spiels.
  • Besucher sind willkommen, aber normalerweise sprechen nur die Mitglieder des Entwicklungsteams.
  • Normalerweise findet eine Runde statt, in der jedes Teammitglied drei Fragen beantwortet:
    • Was hast du getan?
    • Was werden Sie tun?
    • Sehen Sie auch Probleme und Herausforderungen (Hindernisse), brauchen Sie Hilfe, gibt es Dinge, die für andere Teammitglieder wichtig sind?
  • Die Beantwortung dieser drei Fragen sollte kurz und prägnant sein. Wesentliche Informationen müssen dann außerhalb der Sitzung besprochen werden.

Das Meeting kann maximal 15 Minuten dauern, so dass größere Themen außerhalb des Meetings besprochen werden. Das Meeting ist gerade lang genug, um im Stehen eine Tasse Kaffee zu trinken.

Backlog-Verfeinerung

Die User Stories, die sich im Backlog befinden, müssen erstellt und weiter ausgearbeitet werden. Deshalb ist es wichtig, vom Product Owner und durch ihn vom Rest der Organisation klar zu verstehen, was genau er will.

Dinge, die zunächst vage sind, wie „Entwicklung einer Benutzeroberfläche“ oder „Management-Reporting“, können auch in kleinere, überschaubarere Teile zerlegt werden, wie etwa „Benutzeroberflächen für verschiedene Benutzergruppen“, „Jahresabschluss“ und "Handelserklärungen".

Dies ermöglicht es, über die beste Lösung nachzudenken, so dass auch abgeschätzt werden kann, wie viel Zeit dafür benötigt wird. Dadurch ist es auch möglich, Akzeptanzkriterien festzulegen, damit Akzeptanztests kann gemacht werden. Eventuell müssen sogar zusätzliche Untersuchungen in Form von sogenannten „Spikes“ durchgeführt werden. Innerhalb der Wasserfallmethode wäre das die Analysephase heißen. Bei Scrum finden diese Meetings während des gesamten Projekts fast wöchentlich statt.

Dieser Prozess ist nicht der Haupt-Scrum-Prozess, wurde aber im Laufe der Zeit hinzugefügt, um sicherzustellen, dass die Dinge im Backlog von ausreichender Qualität (klar genug) sind, um in den bevorstehenden Sprint aufgenommen zu werden.[2]

Scrum oder Scrums

Bei mehreren Scrum-Teams ist auch eine Abstimmung zwischen diesen Teams notwendig. Dies betrifft die Punkte, mit denen sich Menschen auseinandersetzen müssen, Schnittstellen etc. Diese Beratungen finden in der Regel unmittelbar nach dem Daily Scrum statt.

  • Jedes Team entsendet einen Vertreter.

Die Agenda ist ungefähr dieselbe wie beim Daily Scrum, nämlich:

  • Was hast du seit dem letzten Treffen gemacht?
  • Was wirst du jetzt machen?
  • Läuft alles gut oder haben Sie Probleme oder Verzögerungen?
  • Gibt es Dinge, die uns wichtig sind, die uns stören könnten?
  • Wenn Vereinbarungen nicht eingehalten wurden, reagiert das Team darauf.

Sprintplanung

Zu Beginn des Sprints findet ein Sprint Planning Meeting statt. Grundsätzlich fließen die wichtigsten und wichtigsten User Stories des Product Backlogs in den Sprint ein. Es ist entscheidend, dass das Entwicklungsteam die einzubindenden User Stories auswählt, denn die Teammitglieder sind diejenigen, die sich der Durchführung der zugrunde liegenden Aufgaben verschrieben haben. Deshalb legt das Team auch fest, wie viel Arbeit in den jeweiligen Sprint einfließen kann und das Team ist auch für die Schätzung des Arbeitsaufwands pro User Story verantwortlich. Für diese Schätzung Poker planen eine weit verbreitete Methode.Das Entwicklungsteam muss auch bestätigen, dass alles klar ist. Die Aufgaben werden dann innerhalb des Entwicklungsteams weiter verteilt.

Sprint-Review

Der „Sprint Review“ zeigt das fertige Produkt. Gegebenenfalls wird auch angezeigt, was beim Abschluss dieses Sprints nicht erfolgreich war. Das Sprint Review dauert maximal 4 Stunden. Das gesamte Sprint-Team ist anwesend sowie alle weiteren Interessenten. Ein Drink danach ist eine gute Angewohnheit.

Auswertung (rückblickend)

Die Evaluation soll lernen, was richtig und was schief gelaufen ist, mit dem Ziel, als Team noch besser zu werden. Alle Teammitglieder sind ebenfalls anwesend. Die Beratung dauert maximal 3 Stunden pro Monat und wird vom Scrum Master geleitet. Sie machen eine Runde und jeder sagt, was richtig und was schief gelaufen ist. Man kann auch sagen, was am meisten aufgefallen ist oder was am schwierigsten war usw. Es ist nicht die Absicht, den Leuten eine Verzögerung vorzuwerfen. Daraus soll für zukünftige Sprints gelernt werden.

Eine der wichtigsten Bedingungen einer Retrospektive ist auch eine der größten Herausforderungen für den Moderator: Ein lösungsorientiertes Klima zu schaffen, in dem sich die Teilnehmer frei äußern können und ein gesundes gegenseitiges Verständnis aufgebaut wird.[3]

Ressourcen (Artefakte)

Produktrückstand

Das Produktrückstand ist ein Überblick über die Dinge, die noch zu tun sind. In anderen Softwareentwicklungsmethoden wird dies als Anforderungen, Anforderungen und Wünsche bezeichnet. Es besteht aus allem, was im Sprint wichtig ist, wie Features, Fehler aus früheren Releases, nicht-funktionale Anforderungen wie Navigation, Farbe, "Look and Feel", Geschwindigkeitsanforderungen usw. Der Product Owner ist der Eigentümer dieser Liste und bestimmt die Reihenfolge. Grundsätzlich stehen die wichtigsten ganz oben, aber auch eine andere Reihenfolge ist möglich. Dabei spielen Dinge wie Risiko, Wert für die Organisation, Bedarfstermin, gesetzliche Vorgaben etc. eine Rolle, die auf der Liste stehen in der Regel in Form einer User Story. Darin steht, WAS WARUM und für WEN gemacht werden muss. Jeder kann Dinge hinzufügen, aber der Product Owner ist und bleibt verantwortlich. Darüber hinaus sind grobe Schätzungen des Werts für die Organisation und Entwicklungskosten enthalten. Um die Entwicklungszeit abzuschätzen, kann innerhalb von Scrum das sogenannte "Planning Poker" verwendet werden.

Sprint-Backlog

Ein Scrum-Taskboard.

Das Sprint-Backlog zeigt, was während dieses Sprints getan wird. Das Sprint Backlog setzt sich aus den Top Items des Product Backlogs zusammen. Das Entwicklungsteam bestimmt, was es tun kann, basierend auf seiner Geschwindigkeit in den vorherigen Sprints.

Normalerweise werden die Items im Sprint Backlog auf geschrieben post-its. Es gibt dann drei Spalten, "to do", "in progress", "done". Manchmal mit einer vierten Spalte "Testen". So ist jedem klar, wie die Situation ist.

Das Entwicklerteam entscheidet, wer was macht, oder eigentlich wählen die Mitglieder selbst aus, was sie (können und wollen) von der Todo-Liste abholen. Das fördert, dass sich das Team damit verbunden fühlt, sich dafür engagiert, dass es zu ihrem Produkt wird.

Nach dem Start können dem Sprint keine weiteren Items hinzugefügt werden, außer vom Entwicklerteam selbst. Nach Abschluss des Sprints wird das Product Backlog noch einmal untersucht und Prioritäten und damit die Reihenfolge können sich ändern.

Akzeptanzkriterien (Definition of done)

Die "Definition of done" gibt an, was vereinbart wurde, wie ein Produkt geliefert werden soll. Anforderungen an Dokumentation (in Englisch), Testing (getestet von Benutzern und der Managementabteilung, mit welchen Geräten und Webbrowsern), Standort (auf der Akzeptanzumgebung) usw.

Verbesserung (Inkrement)

Die "Verbesserung" (Inkrement) ist eine Auflistung aller Verbesserungen und Änderungen, die am Produkt vorgenommen wurden. Diese Liste wird in jedem Sprint am Ende des Sprints aktualisiert. Es enthält nur Elemente, die der "Definition of done" entsprechen. Diese Übersicht muss in einer für den Kunden oder Product Owner verwendbaren Form vorliegen. Die Liste kann benötigt werden, um weitere Investitionen in das Projekt zu verteidigen und Außenstehenden, Kunden, Händlern und der Regierung klar zu machen, was bisher erreicht wurde. Ob diese Liste verwendet und veröffentlicht wird, obliegt dem Product Owner. Nach englischer Terminologie wird dies auch als PSI oder Potentiell lieferbares Produkt bezeichnet.

Abbrennen

Dies ist ein Beispiel für ein "Burn-Down-Chart" eines abgeschlossenen Sprints. Sie können sehen, was getan wurde und was noch zu tun ist.

Das Brenndiagramm des Sprints hängt meist im Projektraum an der Wand. So ist jedem sofort klar, wie viel noch zu tun ist. Da es täglich aktualisiert wird, ist sofort klar, wie es läuft. Es gibt auch andere Arten von "Burn-Down-Charts", zum Beispiel die Burn-Down-Chart veröffentlichen Angabe, wie viel bis zum nächsten Release des Produkts noch zu erledigen ist (vorausgesetzt ein "Release" wird in mehreren Sprints realisiert). Da ist auch ein Burn-Down-Chart für alternative Release,[4] dies tut im Prinzip das Gleiche, weist aber zusätzlich auf die Veränderungen durch die mehr/weniger Arbeit durch die fortschreitende Erkenntnis hin.

Konzepte

Die folgenden Begriffe werden in Scrum verwendet:[5] und/oder sind nützlich, um das Ganze zu verstehen.

Scrum-Team (Scrum-Team)
Product Owner, Scrum Master und Entwicklungsteam
Product Owner (ProductOwner)
Der Verantwortliche für das Product Backlog, das die Prioritäten der Stakeholder hervorhebt, damit die Arbeit des Entwicklungsteams einen Wert für die Organisation hat.
Scrum-Master
Die Person, die für den Scrum-Prozess verantwortlich ist, die dafür sorgt, dass alles reibungslos abläuft und der Nutzen von Scrum maximiert wird.
Entwicklungsteam
Eine Gruppe von Spezialisten, die für die Entwicklungsarbeit und die Realisierung eines fertigen Produkts (Erweiterung) verantwortlich ist.
Sprint-Burn-Down-Chart
Eine Grafik, die den täglichen Sprintfortschritt zeigt.
Burn-Down-Chart freigeben
Ein Diagramm, das zeigt, was aus dem Product Backlog gemacht wurde und was noch zu tun ist.
Produktrückstand (Produktrückstand)
Eine Liste mit den Anforderungen und Wünschen an das Produkt auf hohem Niveau.
Sprint-Backlog (Sprint-Backlog)
Eine Liste der während des Sprints auszuführenden Aufgaben, einschließlich eines Plans für die Bereitstellung des Produktinkrements.
Sprint
Ein Zeitraum von 1 bis 4 Wochen, in dem einige Artikel aus dem Product Backlog abgeholt werden. Dies ist eine Zeitbox.
Spitze
Ein kurzer Zeitraum, in dem eine Untersuchung in einer Zeitbox durchgeführt wird. Zum Beispiel, um einen Prototypen zu bauen oder zu testen, ob etwas möglich ist.
Leichte Kugel (Tracerkugel)
Ein Leuchtspurgeschoss ist ein Spike, mit dem man versucht, die Möglichkeiten der gewählten Projektarchitektur, Technologie und beste Übung. Das Ergebnis ist eine Software. Es mag die Entwicklung eines kleinen Teils sein, aber es ist keine Wegwerf-Software. Es kann im weiteren Prozess verwendet werden. Es ist ein „Proof of Concept“ und auch ein „Prototyp“, der Einblicke in die neue Architektur, Technologie und Arbeitsweise gewinnen soll. Der Name kommt von der Armee, wo die Leute Leuchtspurmunition der Spur der Kugeln zu folgen und gegebenenfalls die Richtung zu korrigieren.
Aufgaben
Zu Beginn des Sprints werden die Stories aus dem Product Backlog in Aufgaben zerlegt. Eine Aufgabe hat einen Zeitplan in Stunden. Nach der Theorie darf eine Aufgabe maximal 12 Stunden dauern, aber es wird in der Regel vereinbart, dass Aufgaben maximal einen Tag (8 Stunden) dauern.
Definition of Done (DoD)
Die Check-Off-Kriterien, die etwas erfüllen muss, um fertig zu sein. Diese Kriterien werden vom Entwicklungsteam gemeinsam festgelegt. In vielen Fällen ist zum Beispiel Voraussetzung, dass alle Regressionstests wurden erfolgreich geschlossen.
Geschwindigkeit
Die Geschwindigkeit des Teams, was das Team in einem Sprint leisten kann. Die Geschwindigkeit kann basierend auf der in früheren Sprints erreichten Geschwindigkeit, gemessen in Story Points, mithilfe eines Burn-Down-Charts berechnet werden. Dies ist eine Richtlinie für das Team und die Umgebung, um richtig einzuschätzen, wie viel getan werden kann und was zu erwarten ist.
Behinderung
(Hindernis) Alles, was einem effizienten Prozess im Wege steht.[6]
Sashimi
Ein Bericht, der anzeigt, dass etwas "erledigt" ist.
Abnormale Beendigung
(Abtreibung). Bei Bedarf kann der Product Owner einen Sprint vorzeitig beenden.[7] Der Product Owner kann dies mit Input vom Team, Scrum Master oder Management tun. So kann es beispielsweise sein, dass das Management den Sprint stoppen möchte, weil äußere Umstände das Ziel des Sprints nicht mehr sinnvoll machen. Wenn ein Sprint auf diese Weise gestoppt wird, ist der nächste Schritt, in einem Meeting zu erklären, warum dies notwendig war, und es gibt auch ein neues „Sprint-Planungsmeeting“, um den nächsten Sprint zu planen.
ScrumBut
Ein ScrumBut ist eine Ausnahme zur „echten“ Scrum-Methode, bei der das Team Scrum an die eigenen Bedürfnisse angepasst hat.[8][9]
Paar-Programmierung
Arbeiten zu zweit an einem Programm oder Problem. Dabei handelt es sich um eine intensive Zusammenarbeit, bei der Menschen voneinander lernen und gemeinsam versuchen, etwas zu lösen, das einem Menschen aufgrund fehlender Kenntnisse oder Fähigkeiten zu schwer fällt. Sie können das Know-how des anderen nutzen.
Refactoring
Überarbeitung, Entwicklung oder Programmierung eines bestimmten Teils, um es besser (wartungsfähig) zu machen.
Story-Punkt
Werden bei der Planung verwendet, um die Größe eines Jobs (Story) anzugeben. Durch die Vergabe von 1 oder 2 Punkten für einen bekannten kurzen Job können große Jobs beispielsweise auf dreimal so lang oder zehnmal so lang geschätzt werden.
Zeitboxen
Eine Methode, bei der sich Menschen eine vereinbarte Zeit (Time-Box) nehmen, um etwas zu tun. Es kann also nichts schiefgehen. Es ist beispielsweise möglich, vor dem Testen zu vereinbaren, sich drei Tage Zeit zu nehmen, um nach Fehlern zu suchen. Oder Sie vereinbaren zwei Schulungstage pro Benutzer. Besprechungen können eine Start- und eine Endzeit haben.
Triangulation
Eine Planungsmethode, bei der man sich aus verschiedenen Blickwinkeln gute Schätzungen erhofft. Vor allem, indem wir miteinander darüber reden, warum die Leute denken, dass etwas eine gewisse Zeit in Anspruch nehmen wird.

Andere agile Methoden

Externe Links