Scrum: Ein praktischer Leitfaden

In der aktuellen IT-Branche ist das Konzept von Agile sehr beliebt geworden. Alle reden. Fast alle IT-Unternehmen haben ein gewisses Maß an Agilität angenommen.

Scrum Process Canvas – Visuelles Paradigma

Es gibt auch viele Methoden unter dem Dach der agilen Entwicklung, darunter Extreme Programming (XP), Scrum, Crystal Methods, Adaptive Software Development (ASD), Feature Driven Development (FDD), Dynamic System Development (DSDM) und Lightweight. RUP, Test Driven Development (TDD) und mehr. Unter den vielen agilen Entwicklungsmethoden ist die Implementierung von Scrum beliebter.

Umbrella der agilen Methoden

Agil oder Wasserfall? Siehe die Abbildungen

Der jüngste Bericht der Standish Group behandelte Projekte, die sie zwischen 2013 und 2017 untersucht hat. Für diesen Zeitraum ist die Gesamtverteilung von Erfolg, Herausforderung und Misserfolg unten für agile und Wasserfall-Projekte dargestellt, wobei agile Projekte etwa doppelt so wahrscheinlich erfolgreich sind. und 1/3 weniger Ausfallwahrscheinlichkeit.

(Quelle: vitalitychicago.com –  Vergleich der Wasserfall- und agilen Projekterfolgsraten )

Wasserfall vs. Agile, was ist besser?

Dieser Artikel teilt hauptsächlich das Verständnis von Scrum, den Implementierungsprozess von Scrum und die Änderungen, die die Implementierung von Scrum mit sich bringt, und erklärt, was ein laufendes Scrum ist.

Was ist Scrum?

Scrum ist ein Framework zur Entwicklung und Pflege komplexer Produkte und ist ein inkrementeller, iterativer Entwicklungsprozess. In diesem Rahmen besteht der gesamte Entwicklungsprozess aus mehreren kurzen Iterationszyklen, einem kurzen Iterationszyklus, der als Sprint bezeichnet wird, und jeder Sprint dauert 2 bis 4 Wochen.

Verwenden Sie in Scrum das Produkt-Backlog, um die Anforderungen des Produkts zu verwalten. Das Product Backlog wird nach der Priorität der Implementierung sortiert, wobei der kommerzielle Wert das Hauptprinzip der Sortierung ist. Im Sprint wählte das Scrum-Team die Anforderungen mit der höchsten Priorität aus dem Produkt-Backlog für die Entwicklung aus. Die ausgewählten Anforderungen werden beim Sprint-Planungsmeeting besprochen, analysiert und geschätzt, um eine Aufgabenliste namens Sprint-Backlog zu erhalten. Wenn das Scrum-Team alle Aufgaben in der Sprint-Backlog-Liste erledigt hat, endet der Sprint und fährt mit dem nächsten Sprint-Iterationszyklus fort.

Warum Scrum in einigen Unternehmen scheiterte

Scrum hat einen großen Wert. Allerdings ist es in manchen Unternehmen schwierig, Scrum zu implementieren. Einige Leute sagen, dass Scrum keine substanzielle Wirkung in ihrer Organisation hat. Warum haben sie ein solches Ergebnis? Die Hauptgründe könnten sein:

  • Agil ist schneller  — Dem Projektteam fehlt das richtige Verständnis von Agilität. Es denkt einfach, dass Agilität schnell ist, das heißt, den Fortschritt einholt, und es kann frei von jeglichen Systembeschränkungen sein.
  • Agile ist schneller, oder wir müssen Überstunden machen  – ich habe gehört, dass einige Unternehmen eine neue Funktion entwickeln müssen. Aufgrund der Einführung von Scrum muss das Projektteam Überstunden machen, und die Entwicklungsaufgaben von 2 Wochen oder mehr werden innerhalb einer Woche freigegeben. Die Implementierung von Scrum bedeutet, dass das Projektteam Überstunden macht, was zu einer „Angst“ in der Agilität des Projektteams führt;
  • Product Backlog wird nicht gut gepflegt  – PO kann nicht für die Arbeit qualifiziert werden, kann keine effektiven User Stories aufteilen oder die Story-Aufteilung des Benutzers ist unangemessen, kann keine inkrementelle Generierungsentwicklung realisieren;
  • Problem  der Teambildung – Scrum hat eine hohe Nachfrage nach selbstorganisierenden Teams, aber viele Teammitglieder haben das Gefühl, dass sie den Standards der Selbstorganisation nicht gewachsen sind;
  • Mangel an agiler Kultur  – Scrum befürwortet die Transparenz der Arbeit, den Abschluss des Projekts in Echtzeit und die Aufgabenerkennung jeder Person. Das Sprint Board und das Projekt-Burndown-Diagramm sind frei zugänglich, und viele Menschen fühlen sich damit nicht wohl;
  • Inspektion und Anpassung nicht vorhanden  – Im Iterationsprozess kann das Problem nicht rechtzeitig entdeckt werden oder das Problem wird gefunden und das Problem kann nicht effektiv gelöst werden, was das Projektteam frustriert. und viele mehr.

Wenn das Scrum-Wissen nur noch steckt:

„Morgens habe ich eine Idee, nachmittags wird sie umgesetzt und abends ist sie online.“

Es ist unangemessen. Meiner Meinung nach ist Scrum definitiv wertvoll. Zu den Hauptfunktionen von Scrum gehören:

  • Scrum kann sicherstellen, dass die Entwicklung von Produktrückständen, die für Kunden von hohem Wert sind, priorisiert wird und die Bedürfnisse der Benutzer besser erfüllt werden.
  • Verglichen mit der Entwicklungsmethode im Wasserfallprozess kann das Team durch die Implementierung von Scrum die Entwicklungseffizienz verdoppeln und die Rolle des Teams maximieren;
  • Scrum kann Entwicklungszyklen verkürzen und die Effizienz der Projektabwicklung steigern.

Die Implementierung von Scrum bedeutet jedoch nicht, dass es keinen Regeln und Projektbeschränkungen unterliegt. Was ist also die richtige Haltung, um Scrum zu implementieren?

Schritte zur Implementierung von Scrum

1. Weisen Sie eine Bestellung zu

PO ist der Produkteigentümer, was eine Rolle ist, und PO ist der alleinige Eigentümer der Aufgabenliste des Verwaltungsprodukts. Natürlich existiert der PO in manchen Unternehmen bereits als Organisation – beispielsweise hat unser Unternehmen den PO als Organisation bei der Umsetzung von Scrum implementiert.

Als Eigentümer muss es ein großes Bild haben; die Brancheninformationen und -richtungen tief verstehen; in der Lage sein, die Richtung des Produkts zu erfassen, die Verantwortung für die kurz- und mittel- und langfristige Planung und das Management des Produkts zu übernehmen; in der Lage sein, Benutzerforschung und Produktfunktionsplanung gemäß den strategischen Anforderungen des Unternehmens durchzuführen, die sich ständig ändernden Anforderungen zu verfolgen und Produkte kontinuierlich zu erneuern.

Wenn Sie PO als Organisation in einem Softwareentwicklungsprojekt verwenden, kann das PO-Team außerdem Mitglieder wie Produktmanager und Endbenutzer umfassen.

2. Bilden Sie ein Entwicklungsteam

Das Team ist der Implementierer des Produkts und verantwortlich für die Bereitstellung potenzieller lieferbarer Inkremente und „abgeschlossener“ Produktinkremente am Ende jedes Sprints.

Das Team besteht hauptsächlich aus Entwicklungs- und Testpersonal, und das Team muss in der Lage sein, die Produktvision des PO umzusetzen.

Die Größe des Teams sollte zwischen 5 und 9 Personen betragen.

Das Scrum-Team sollte auch funktionsübergreifend sein, und Mitglieder mit der „Full Stack“-Fähigkeit sind vorzuziehen, auch wenn  es in den meisten Unternehmen schwierig sein kann, sie zu implementieren.

3. Wählen Sie Scrum-Master aus

Der Scrum Master ist für den Scrum-Prozess verantwortlich und dient dem PO- und Entwicklungsteam. Der Scrum Master muss einen Sinn für Rituale haben und kann das iterative Planmeeting, das tägliche Stehmeeting, das Funktionsdemonstrationsmeeting und das Retrospektive-Review-Meeting effektiv und effizient organisieren; Der Scrum Master muss ein hohes Maß an Ausführung haben und glaubwürdig bleiben, um dem Team zu helfen. Konzentrieren Sie sich auf Lieferziele und Qualitätsziele, um sicherzustellen, dass Teams qualitativ hochwertige Produkte effizient liefern; Teams dazu bringen, effiziente Prozesse aufzubauen, Teams zu agilen Werten, Prinzipien und agilen Praktiken zu führen; für die Schulung anderer Teammitglieder verantwortlich sein, um sicherzustellen, dass Scrum korrekt verwendet wird; Kommunikation, Problemmanagement, Konfliktlösung helfen dem Team, alle Hindernisse zu beseitigen.

4. Pflegen Sie das Produkt-Backlog

Das Product Backlog ist eine Sammlung aller Backlog-Einträge und basiert auf der Unternehmensstrategie und Produktvision. PO sortiert alle Artikel im Product Backlog gemäß der Prioritätsreihenfolge nach Geschäftswerten und bildet eine priorisierte Artikelliste. Das  Product Backlog kann als „Roadmap“ der Produktentwicklung dienen. Um den Produktkontext zu verstehen, sind die Product Backlog Items die beste Referenz.

Jeden Tag werden wir mit neuen Anforderungen von neuen Wettbewerbern konfrontiert, was bedeutet, dass PO sein Produktdesign kontinuierlich optimieren und die Prioritäten des Produkt-Backlogs anpassen muss, um mit den neuen Änderungen fertig zu werden.

In diesem Prozess sollte sich der PO mit allen Beteiligten und Teams beraten, um sicherzustellen, dass Produktrückstände die wahren Ansprüche des Benutzers widerspiegeln.

5. Agile Schätzung mit Story Point

Eine relativ agile Schätzung wird typischerweise beim Sprint Planning oder Touch Up während eines Sprints durchgeführt und das Product Backlog wird vom Team zusammen mit den Verantwortlichen für die eigentliche Entwicklungs- und Testarbeit bewertet.

Um das Sprint Planning in der Praxis effizienter durchführen zu können, nehmen PO und Scrum Master vor dem Sprint Planning Meeting eine grobe Abschätzung vor. Sie müssen diese Art von Fragen stellen, wie zum Beispiel:

  • Sehen Sie, ob der Sprintplan durchführbar ist?
  • Liegen genügend Informationen vor, um diese Angelegenheiten abzuschließen?
  • Ist die Aufteilung des Product-Backlog-Items sinnvoll?

Wenn das Entwicklungsteam eine Schätzung durchführt, wird empfohlen, die traditionelle Methode (d. h. wie viele Stunden der Aufgabe zugewiesen werden) aufzugeben und einen agilen Schätzansatz zu verwenden, indem der Story Point – die Fibonacci-Zahl (1, 2, 3, 5) – verwendet wird , 8, 13, 21…) Formular zur Bewertung des Aufwands für die Umsetzung eines Items.

Zum Zeitpunkt der Schätzung muss das Team zunächst ein Backlog-Element identifizieren, das möglicherweise in Form einer User Story als Referenz für die Schätzung vorliegt. Darüber hinaus ist es wichtig zu beachten, dass,  wenn der Single Story Point der Bewertung größer als 21 ist, die User Story erneut aufgeteilt werden muss und der Single User Story Point nicht mehr als 8 ist der ideale Zustand.

Agile Schätzmethode

6. Sprint-Planungsmeeting

Dies ist das erste echte Scrum-Meeting. Team, Scrum Master und PO setzen sich zusammen, um den Inhalt des Sprints zu planen. Als Softwareentwicklungsprojekt, das in die User Story des Planungssprints eintritt, sollte die User Story aufgeteilt und das visuelle Design abgeschlossen sein.

Der Sprintzyklus ist in der Regel festgelegt, meist auf 2 bis 4 Wochen. Das Team beginnt mit der User Story mit der höchsten Priorität in der Produkt-To-do-Liste, um zu sehen, wie viel in einem Sprint erledigt werden kann.

Wenn das Team bereits mehrere Sprints durchgeführt hat, anhand von:

  • Die „Story Points“, die in den vorherigen Iterationen abgeschlossen wurden,
  • Das Team kann die ungefähren Story Points für diese Iteration schätzen.
  • „Story Points“ entspricht der Geschwindigkeit des Teams.

Scrum Master und Team sollten danach streben, diese Zahl in jeder Sprint-Iteration zu erhöhen.

Alle Teammitglieder sollten einen Konsens über das Ziel eines Sprints bilden, d. h. was in einer Sprint-Iteration erreicht werden muss. Beim Sprint-Planungsmeeting muss PO dem Team die Prioritätsreihenfolge der User-Story-Implementierung mitteilen. Das Team verspricht, wie viele Geschichten es in der nächsten Sprint-Iteration abschließen kann. Während des Sprints kann niemand den Inhalt des Sprints einseitig ohne Genehmigung ändern.

7. Tägliches Stand-up-Meeting

Daily Stand-up ist die Quelle der Vitalität für Scrum. Zu den Teilnehmern gehören in der Regel PO, Scrum Master und Team. Das Team kommuniziert intern an einem festen Ort und zu einer festen Tageszeit. Die  Zeit ist normalerweise morgens, die Dauer beträgt nicht mehr als 15 Minuten und steht. Der Scrum Master stellt den Teammitgliedern  folgende Fragen:

  • Was hast du gestern gemacht?
  • Welche Arbeit hast du heute vor?
  • Was sind Hindernisse und Hindernisse?

Die Bedeutung davon besteht darin, das gesamte Team über den Fortschritt jeder Aufgabe während dieses Sprintzyklus klar zu informieren und darüber, ob alle Aufgaben rechtzeitig abgeschlossen werden können.

Die Aufgaben des Teams werden nicht von oben nach unten vergeben, sondern eigeninitiativ und freiwillig entschieden. Wenn die vorherige Aufgabe nicht abgeschlossen ist, können Sie sich nicht für die nächste Aufgabe bewerben, und Sie können keine zwei Aufgaben beanspruchen, die nicht am selben Tag erledigt werden können.

Der Scrum Master ist dafür verantwortlich, die Hindernisse zu beseitigen, denen sich die Teammitglieder gegenübersehen.

8. Verfolgen Sie den Projektfortschritt mit dem Scrum Task Board

In Scrum muss die Arbeit transparent sein, und die gängigste Praxis ist die Implementierung eines Scrum Task Boards.

Einige Teams sind gut darin, Tools von Drittanbietern zu verwenden, um elektronische Scrum-Boards wie Visual Paradigm oder Jira zu verwenden; Einige Teams verwenden gerne große physische Offline-Whiteboards.

Unabhängig davon, ob Sie ein elektronisches Scrum-Board oder ein physisches Whiteboard verwenden, enthalten die Kanban-Spalten normalerweise drei Teile: die To-Do-Liste, die laufenden Elemente und die abgeschlossenen Elemente. Während der Fortschritt der Iteration fortschreitet, wird das Team die Angelegenheit jeden Tag umgehend in der entsprechenden Scrum-Kanban-Spalte aktualisieren.

Scrum Task Board – Visuelles Paradigma

9. Fortschrittsverfolgung mit Burnout-Diagrammen

Ein weiteres Tool, um die Arbeit transparent zu machen, ist das Burn-Out-Chart. In der folgenden Abbildung stellt eine Achse die Arbeitsbelastung und die andere die Zeit dar. Jeden Tag erfasst der Scrum Master die noch zu erledigenden Punkte und trägt sie dann in das Burnout-Diagramm ein. Idealerweise ist der Graph eine Abwärtskurve, die auf Null ausbrennt, wenn der Rest der Arbeit abgeschlossen ist.

用燃尽图跟踪进度

10. Produktdemonstration

Scrum Review und Retrospektive Meeting – Visuelles Paradigma

Der Demonstrationsabschnitt des Scrum-Leitfadens wird als Sprint Review Meeting bezeichnet, das besagt, dass er die Arbeit des Entwicklungsteams demonstrieren und Fragen zum Produktinkrement beantworten sollte. Das Meeting findet normalerweise vor der Veröffentlichung dieser Iteration statt. Die wichtigste Arbeit dieses Treffens besteht darin, die Implementierungsszenarien von User Stories zu verifizieren, indem Bewertungen mit jedem abgeschlossenen Element akzeptiert werden, um die Definition of Done zu erfüllen.

An diesem Meeting kann jeder teilnehmen, nicht nur PO, Scrum Master und Team, sondern auch Stakeholder, Unternehmen und Manager und sogar Kunden.

Dies ist ein offenes Meeting, an dem jeder teilnehmen kann, nicht nur PO, Scrum Master und Team, sondern auch Stakeholder, Unternehmen und Manager und sogar Kunden.

Teams sollten nur die Items zeigen, die der Definition of Done entsprechen, also die Ergebnisse, die ohne weitere Arbeit geliefert werden können. Dieses Ergebnis ist vielleicht kein vollständiges Produkt, aber es ist zumindest eine vollständige und nutzbare Funktion für den Endbenutzer.

11. Sprint-Retrospektive

Das Sprint Retrospektive Meeting findet in der Regel am zweiten Tag nach dem Ende dieses Sprints statt.

Das Sprint-Retrospektive-Meeting sollte die folgenden Fragen sorgfältig prüfen:

  • Was passiert ist, wurde verbessert;
  • Warum ist das passiert?
  • Warum haben wir es damals ignoriert;
  • Wie können wir die Arbeit beschleunigen.

Um diesen Sprint-Retrospektive-Prozess als Team effektiv zu gestalten, muss das Team einander vertrauen. Wir müssen uns an die Diskussion und Argumente zu Projekt- und technischen Fragen erinnern:

  • Es gibt kein absolutes Richtig, Falsch und Sorgen,
  • Fördern Sie technische Kollisionen;
  • Darf keine Diskussionen über persönliche Angriffe beinhalten;
  • Widerstehen Sie Menschen mit farbigen Brillen, um Menschen zu sehen,
  • Führen Sie alle zu einer vernünftigen Diskussion;
  • Nehmen Sie mutig die Herausforderungen anderer an,
  • Akzeptieren Sie ihre eigenen Unvollkommenheiten.
  • Verantwortung für die eigenen Prozesse und Ergebnisse,
  • Brainstorming und Suche nach Lösungen für Probleme. Das ist entscheidend.

Schließlich identifiziert das Team eine der lohnenswertesten Verbesserungen und legt sie als oberste Priorität für den nächsten Sprint fest. Sie müssen konkret und umsetzbar definieren, was „erfolgreich“ ist, damit Sie beim nächsten Sprint-Review-Meeting schnell feststellen können, ob die Verbesserungen vorgenommen wurden.

Nachdem der letzte Sprint beendet ist, beginnen Sie mit der Eingabe der neuen Sprint-Iteration.

Zusammenfassung

Scrum  ist eine Kombination aus 3355. Die Kernkonzepte des Scrum-Frameworks können einfach als 3.3.5.5 wie folgt auswendig gelernt werden:

3 Rollen

3 Artefakte

5 Veranstaltungen

5 Werte

  • Offen
  • Respekt
  • Mut
  • Fokus
  • Engagement

Die Ziele von 3355 stehen hinter den drei Scrum-Säulen

  • Transparent
  • Inspektion
  • Anpassung

Die Definition of „Done“ (DoD) wird durch die Erfüllung der 3 Säulen durch 5 Events des  Scrum Teams erreicht .

Scrum 3355-Framework

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht.