Scrum - Kurzanleitung

Agile ist zu einem der wichtigsten Schlagworte in der Softwareentwicklungsbranche geworden. Aber was genau ist agile Entwicklung? Einfach ausgedrückt ist agile Entwicklung eine andere Art, Softwareentwicklungsteams und -projekte auszuführen.

Um zu verstehen, was neu ist, lassen Sie uns die traditionellen Methoden zusammenfassen. Bei der herkömmlichen Softwareentwicklung werden die Produktanforderungen festgelegt, bevor mit der Entwicklung fortgefahren wird.

Wasserfall-Modell

Das am häufigsten verwendete Softwareentwicklungsmodell mit dieser Eigenschaft ist das Wasserfallmodell, wie in der folgenden Abbildung dargestellt. In den meisten Fällen werden jedoch neue Funktionen hinzugefügt, und auch frühere Anforderungen können sich ändern. Das Wasserfallmodell ist nicht so strukturiert, dass es solchen kontinuierlichen Änderungen der Anforderungen Rechnung trägt. Darüber hinaus hat der Benutzer keine Klarheit über die Funktionalität des Produkts, bis das Produkt vollständig verfügbar ist.

Iteratives inkrementelles Modell

Im iterativen inkrementellen Modell beginnt die Entwicklung mit einer begrenzten Anzahl finalisierter und priorisierter Anforderungen. Das Ergebnis ist ein Arbeitsschritt des Produkts. Eine Reihe von Aktivitäten, die von Anforderungen bis zur Codeentwicklung reichen, werden als Iteration bezeichnet. Basierend auf der Funktionalität des Inkrements und einigen oder allen neuen, geänderten, ausstehenden Anforderungen wird die nächste Menge von Anforderungen an die nachfolgende Iteration übergeben. Das Ergebnis der nachfolgenden Iteration ist ein verbessertes Arbeitsinkrement des Produkts. Dies wird wiederholt, bis das Produkt die erforderlichen Funktionen erfüllt.

Der Benutzer ist normalerweise nicht an der Entwicklungsarbeit beteiligt und kann Kommunikationslücken verursachen, die zu falschen Funktionen führen. Das Engagement ist positiv für das Entwicklungsteam, stellt jedoch hohe Anforderungen an die Zeit des Teams und kann zu Verzögerungen führen. Darüber hinaus können informelle Anforderungsänderungen während einer Iteration zu Verwirrung führen und auch zu Scope Creeps führen. Mit dieser Prämisse entstand die agile Entwicklung.

Agile Entwicklung

Die agile Entwicklung basiert auf einer iterativen inkrementellen Entwicklung, bei der sich Anforderungen und Lösungen durch Teamzusammenarbeit entwickeln. Es empfiehlt einen iterativen Ansatz mit Zeitrahmen und fördert eine schnelle und flexible Reaktion auf Änderungen. Es ist ein theoretischer Rahmen und legt keine bestimmte Praxis fest, der ein Entwicklungsteam folgen sollte. Scrum ist ein spezifisches agiles Prozess-Framework, das die zu befolgenden Praktiken definiert.

Zu den frühen Implementierungen agiler Methoden gehören Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development (1997) und Dynamic Systems Development Method (DSDM) (1995). Diese werden nun gemeinsam als bezeichnetagile methodologies, nachdem das Agile Manifest im Jahr 2001 veröffentlicht wurde.

Agiles Manifest

Das Agile Manifest wurde 2001 von einem Team von Softwareentwicklern veröffentlicht. Es unterstreicht die Bedeutung, die dem Entwicklungsteam beigemessen werden muss, um den sich ändernden Anforderungen und der Kundenbeteiligung gerecht zu werden.

Das Agile Manifest lautet wie folgt:

„Wir entdecken bessere Möglichkeiten für die Entwicklung von Software, indem wir dies tun und anderen dabei helfen. Durch diese Arbeit haben wir Wert geschaffen:

Individuen und Interaktionen über Prozesse und Werkzeuge
Arbeitssoftware über umfassende Dokumentation
Kundenzusammenarbeit über Vertragsverhandlungen
Antworten auf Umstellung nach einem Plan

Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr. "

… Manifest für agile Softwareentwicklung, Autoren: Beck, Kent, et al. (2001)

Definition von agilen Manifestelementen

Die Manifestelemente auf der linken Seite können wie folgt beschrieben werden:

Manifest Item	Beschreibung
Individuen und Interaktionen	Wichtigkeit muss gegeben werden für: Selbstorganisation und Selbstmotivation der Teammitglieder Kontinuierliche Interaktion für die Arbeit, Klarstellungen, Informationen unter den Teammitgliedern
Arbeitssoftware	Die Lieferung von Arbeitssoftware in kurzen Intervallen trägt dazu bei, das Vertrauen und die Sicherheit der Kunden im Team zu gewinnen.
Kundenzusammenarbeit	Die ständige Einbeziehung des Kunden in das Entwicklungsteam stellt die Kommunikation der erforderlichen Änderungen sicher.
Auf Veränderungen reagieren	Konzentrieren Sie sich auf eine schnelle Reaktion auf die vorgeschlagenen Änderungen, die durch Iterationen von kurzer Dauer ermöglicht wird.

Das Schlüsselelement des Agilen Manifests ist, dass wir den Menschen und ihrer Fähigkeit zur Zusammenarbeit vertrauen müssen. Aus diesem Grund nutzen die entwickelten spezifischen agilen Methoden die Fähigkeiten der Teammitglieder, indem sie Teamarbeit und Zusammenarbeit während des gesamten Lebenszyklus des Projekts hervorheben.

Schlüsselprinzipien von Agile

Das Agile Manifest basiert auf folgenden Prinzipien:

Prinzip	Beschreibung
Zufriedenheit und Lieferung	Kundenzufriedenheit durch frühzeitige und kontinuierlich arbeitende Software.
Veränderung begrüßen	Begrüßen Sie sich ändernde Anforderungen auch in späteren Entwicklungsstadien.
Häufig liefern	Stellen Sie häufig funktionierende Software bereit (wöchentlich statt monatlich).
Kommunikation ist der Schlüssel	Stellen Sie sicher, dass Entwickler täglich eng mit Geschäftsleuten verbunden sind.
Umwelt und Vertrauen	Bauen Sie Projekte um motivierte Personen auf. Geben Sie ihnen die notwendige Unterstützung und vertrauen Sie ihnen.
Kommunikation von Angesicht zu Angesicht	Ermutigen Sie zu persönlichen Gesprächen, um eine effiziente und effektive Kommunikation sicherzustellen.
Software als Maß für den Fortschritt	Arbeitssoftware ist das Hauptmaß für den Fortschritt.
Nachhaltige Entwicklung	Förderung einer nachhaltigen Entwicklung mit der Fähigkeit, während der gesamten Entwicklung ein konstantes Tempo beizubehalten.
Liebe zum Detail	Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design.
Die Kraft von weniger	Einfachheit ist wichtig.
Selbstorganisierende Teams	Regelmäßige Aufmerksamkeit des Teams, um unter sich ändernden Umständen effektiv zu werden.

Agile Methoden

Dynamische Systementwicklungsmethode (DSDM)

Es ist ein agiles Framework für Softwareprojekte. Es wurde verwendet, um die traditionellen Ansätze zu verfeinern. Die neueste Version von DSDM heißt DSDM Atern. Der Name Atern ist eine Abkürzung für Arctic Tern - ein Seevogel, der große Entfernungen zurücklegen kann und viele Merkmale der Methode darstellt, die natürliche Arbeitsweisen wie Priorisierung und Zusammenarbeit sind.

Gedränge

Es ist das beliebteste agile Framework, das sich insbesondere auf die Verwaltung von Aufgaben in einer teambasierten Entwicklungsumgebung konzentriert. Scrum verwendet ein iteratives und inkrementelles Entwicklungsmodell mit einer kürzeren Iterationsdauer. Scrum ist relativ einfach zu implementieren und konzentriert sich auf schnelle und häufige Lieferungen.

Extreme Programmierung (XP)

Es ist eine Art agile Softwareentwicklung. Es befürwortet häufige Releases in kurzen Entwicklungszyklen, um die Produktivität zu verbessern und Checkpoints einzuführen, an denen neue Kundenanforderungen übernommen werden können. Die Methodik hat ihren Namen von der Idee, dass die nützlichen Elemente traditioneller Softwareentwicklungspraktiken auf ein extremes Niveau gebracht werden. (Extreme Programming ist eine Softwareentwicklungsdisziplin, die Menschen dazu organisiert, qualitativ hochwertigere Software produktiver zu produzieren.) XP adressiert die Analyse-, Entwicklungs- und Testphasen mit neuartigen Ansätzen, die einen wesentlichen Unterschied zur Qualität des Endprodukts bewirken.

Testgetriebene Entwicklung (TDD)

Es ist ein Softwareentwicklungsprozess, der auf der Wiederholung eines sehr kurzen Entwicklungszyklus beruht: Zuerst schreibt der Entwickler einen automatisierten Testfall, der eine gewünschte Verbesserung oder eine neue Funktion definiert, dann erzeugt er die geringste Menge an Code, um diesen Test zu bestehen, und Endlich bringt der neue Code akzeptable Standards.

Lehnen

Es ist eine Produktionspraxis, die den Ressourcenverbrauch für ein anderes Ziel als die Wertschöpfung für den Endkunden als verschwenderisch und damit als Ziel für die Beseitigung betrachtet. Aus der Sicht des Kunden, der ein Produkt oder eine Dienstleistung konsumiert, wird der Begriff Wert als jede Handlung oder jeder Prozess definiert, für die ein Kunde bereit wäre zu zahlen. Lean konzentriert sich darauf, mit weniger Arbeit Wert zu erhalten.

Kanban

Es ist ein System zur Verbesserung und Aufrechterhaltung eines hohen Produktionsniveaus. Kanban ist eine Methode, mit der Just-In-Time (JIT), die Strategie der Unternehmen zur Kontrolle der Bestandskosten, erreicht wird. Kanban wurde zu einem wirksamen Instrument zur Unterstützung des Betriebs eines gesamten Produktionssystems und erwies sich als hervorragende Möglichkeit, Verbesserungen zu fördern.

Fazit

In den letzten 10 Jahren gab es immer mehr Erfolgsgeschichten, in denen Unternehmen den Erfolg und die Leistung ihrer IT-Entwicklungsteams und -Projekte mit agilen Praktiken dramatisch verbessert haben. Dies hat dazu geführt, dass Agilität in einer Vielzahl von Branchen, einschließlich Medien und Technologie, großen Unternehmen und sogar der Regierung, weit verbreitet ist.

Mit Agile Framework können Teams von folgenden Vorteilen profitieren:

Schnellere Lieferzeit / Vermarktung
Unsicherheit und Risiko reduzieren
Steigern Sie den Return on Investment (ROI), indem Sie sich auf den Kundennutzen konzentrieren

Unter diesen verschiedenen agilen Methoden hat sich Scrum in den letzten 20 Jahren weltweit als äußerst erfolgreich erwiesen.

Scrum ist ein Framework für die Entwicklung und Erhaltung komplexer Produkte. Ken Schwaber und Jeff Sutherland entwickelten Scrum. Zusammen stehen sie hinter den Scrum-Regeln.

Scrum-Definition

Scrum ist ein Rahmen, in dem Menschen komplexe Anpassungsprobleme angehen und gleichzeitig produktiv und kreativ Produkte mit dem höchstmöglichen Wert liefern können.

Scrum ist ein Prozess-Framework, mit dem seit Anfang der 90er Jahre komplexe Produktentwicklungen verwaltet werden. Scrum ist kein Prozess oder eine Technik zum Bauen von Produkten. Vielmehr handelt es sich um einen Rahmen, in dem Sie verschiedene Prozesse und Techniken anwenden können. Scrum macht die relative Wirksamkeit Ihrer Produktmanagement- und Entwicklungspraktiken deutlich, damit Sie sich verbessern können.

Das Scrum-Framework besteht aus Scrum-Teams und den zugehörigen Rollen, Ereignissen, Artefakten und Regeln. Jede Komponente innerhalb des Frameworks dient einem bestimmten Zweck und ist für den Erfolg und die Verwendung von Scrum von entscheidender Bedeutung.

Die Regeln von Scrum binden die Ereignisse, Rollen und Artefakte zusammen und regeln die Beziehungen und die Interaktion zwischen ihnen. Die Regeln von Scrum werden in diesem Tutorial beschrieben.

Note- In der gesamten Branche gibt es falsche Vorstellungen, dass Scrum keine Dokumentation bedeutet, das Scrum-Team nur aus Entwicklern besteht und so weiter. Es ist nicht ganz so; Wir werden dies in späteren Abschnitten erläutern.

Scrum Process Framework

In Scrum werden die vorgeschriebenen Ereignisse verwendet, um Regelmäßigkeit zu erzeugen. Alle Ereignisse sind Ereignisse mit Zeitrahmen, sodass jedes Ereignis eine maximale Dauer hat. Die Ereignisse werden in den folgenden Kapiteln ausführlicher beschrieben.

Sprint

Das Herzstück von Scrum ist ein Sprint, eine Zeitspanne von zwei Wochen oder einem Monat, in der ein potenziell freisetzbares Produktinkrement erstellt wird. Ein neuer Sprint startet unmittelbar nach Abschluss des vorherigen Sprints. Sprints bestehen aus der Sprint-Planung, täglichen Scrums, der Entwicklungsarbeit, dem Sprint-Review und der Sprint-Retrospektive.

Bei der Sprint-Planung werden die im Sprint auszuführenden Arbeiten vom Scrum-Team gemeinsam geplant.
Das Daily Scrum Meeting ist eine 15-minütige Veranstaltung mit Zeitrahmen für das Scrum-Team, um die Aktivitäten zu synchronisieren und einen Plan für diesen Tag zu erstellen.
Am Ende des Sprints wird eine Sprint-Überprüfung durchgeführt, um das Inkrement zu überprüfen und bei Bedarf Änderungen am Product Backlog vorzunehmen.
Die Sprint-Retrospektive findet nach der Sprint-Überprüfung und vor der nächsten Sprint-Planung statt. In diesem Meeting soll sich das Scrum-Team selbst inspizieren und einen Plan für Verbesserungen erstellen, die während des nachfolgenden Sprints durchgeführt werden sollen.

Fazit

Scrum ist ein Prozessframework, das bestimmte Regeln, Ereignisse und Rollen definiert, um die Regelmäßigkeit zu gewährleisten. Es kann jedoch je nach Bedarf an jede Organisation angepasst werden, sofern die grundlegenden Scrum-Regeln nicht verletzt werden.

Das Scrum-Team besteht aus drei Rollen, nämlich einem ScrumMaster, einem Product Owner und dem Team.

ScrumMaster

Der ScrumMaster (manchmal als Scrum Master geschrieben, obwohl der offizielle Begriff nach "Scrum" kein Leerzeichen hat) ist der Bewahrer des Scrum-Prozesses. Er / sie ist verantwortlich für-

Damit der Prozess reibungslos verläuft
Beseitigung von Hindernissen, die sich auf die Produktivität auswirken
Organisation und Durchführung der kritischen Besprechungen

Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produkts und die Arbeit des Teams zu maximieren. Wie dies gemacht wird, kann zwischen Organisationen, Scrum-Teams und Einzelpersonen sehr unterschiedlich sein.

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Das Product Backlog Management umfasst:

Product Backlog-Elemente klar ausdrücken.
Bestellen der Product Backlog-Artikel, um Ziele und Aufgaben am besten zu erreichen.
Optimierung des Werts der Arbeit, die das Team leistet.
Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Team weiter arbeiten wird.
Stellen Sie sicher, dass das Team die Elemente im Product Backlog auf dem erforderlichen Niveau versteht.

Der Product Owner kann die oben genannten Arbeiten ausführen oder vom Team ausführen lassen. Der Product Owner bleibt jedoch für diese Aufgaben verantwortlich.

Der Product Owner ist eine Person, kein Ausschuss. Der Product Owner kann die Wünsche eines Ausschusses im Product Backlog vertreten, aber diejenigen, die die Priorität eines Product Backlog-Elements ändern möchten, müssen sich an den Product Owner wenden.

Damit der Product Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product Owners sind im Inhalt und in der Reihenfolge des Product Backlogs sichtbar. Niemand darf dem Team sagen, dass es nach anderen Anforderungen arbeiten soll, und das Team darf nicht nach den Aussagen anderer handeln. Dies wird durch ScrumMaster sichergestellt.

Die Mannschaft

Das Team ist selbstorganisierend und funktionsübergreifend. Das bedeutet, dass das Team aus Analysten, Designern, Entwicklern, Testern usw. besteht, die für das Projekt angemessen und relevant sind.

Einige Leute in der Branche bezeichnen dieses Team als Entwicklungsteam. Eine solche Referenz führt jedoch zu Kontroversen darüber, dass das Team nur Entwickler und keine anderen Rollen haben kann. Es ist ein offensichtliches Verständnis, dass es nur ein Missverständnis ist. Um ein Softwareprodukt zu entwickeln, benötigen wir alle Rollen, und das ist die Essenz von Scrum - das Team wird zusammenarbeiten. Funktionsübergreifende Teams verfügen über alle Kompetenzen, die für die Ausführung der Arbeit erforderlich sind, ohne von anderen abhängig zu sein, die nicht Teil des Teams sind. Auf diese Weise können Zeit und Mühe gespart werden. Das Teammodell in Scrum wurde entwickelt, um Flexibilität, Kreativität und Produktivität zu optimieren.

Die optimale Teamgröße ist klein genug, um flink zu bleiben, und groß genug, um wichtige Arbeiten innerhalb eines Sprints auszuführen. Die Teamgröße sollte nach Möglichkeit im Bereich von fünf bis neun Personen liegen. Weniger als fünf Teammitglieder verringern die Interaktion und führen zu geringeren Produktivitätsgewinnen. Mehr als neun Mitglieder zu haben, erfordert zu viel Koordination.

Das Scrum-Team arbeitet täglich eng zusammen, um einen reibungslosen Informationsfluss und eine schnelle Lösung von Problemen zu gewährleisten. Das Scrum-Team liefert das Produkt iterativ und inkrementell und maximiert so die Möglichkeiten für Feedback. Inkrementelle Lieferungen eines vollständigen Produkts stellen sicher, dass immer eine potenziell nützliche Version des Arbeitsprodukts verfügbar ist.

ScrumMaster ist eine geschulte verantwortliche Person, die Dienstleistungen wie unten beschrieben erbringt -

ScrumMaster Services für den Product Owner

Der ScrumMaster dient dem Product Owner auf verschiedene Weise, einschließlich -

Suche nach Techniken für ein effektives Product Backlog-Management.
Helfen Sie dem Scrum-Team, die Notwendigkeit klarer und präziser Product Backlog-Elemente zu verstehen.
Produktplanung in einem empirischen Umfeld verstehen.
Sicherstellen, dass der Product Owner weiß, wie das Product Backlog angeordnet wird, um den Wert zu maximieren.
Beweglichkeit verstehen und üben.
Erleichterung von Scrum-Ereignissen nach Bedarf.

ScrumMaster Services für das Scrum-Team

Der ScrumMaster dient dem Scrum-Team auf verschiedene Weise, darunter:

Coaching des Scrum-Teams in Selbstorganisation und funktionsübergreifend.
Unterstützung des Scrum-Teams bei der Entwicklung hochwertiger Produkte.
Hindernisse für den Fortschritt des Scrum-Teams beseitigen.
Erleichterung von Scrum-Ereignissen nach Bedarf oder Bedarf.
Coaching des Scrum-Teams in organisatorischen Umgebungen, in denen Scrum noch nicht vollständig übernommen und verstanden ist.

ScrumMaster Services für die Organisation

Der ScrumMaster dient der Organisation auf verschiedene Weise, einschließlich:

Führung und Coaching der Organisation bei der Einführung von Scrum.
Planung von Scrum-Implementierungen innerhalb der Organisation.
Unterstützung von Mitarbeitern und Stakeholdern beim Verständnis und der Umsetzung von Scrum und der empirischen Produktentwicklung.
Verursachen von Änderungen, die die Produktivität des Scrum-Teams erhöhen.
Arbeiten Sie mit anderen ScrumMastern zusammen, um die Effektivität der Anwendung von Scrum in der Organisation zu erhöhen.

Fazit

Das Scrum Process Framework kann mithilfe einer Abfolge von Ereignissen und den entsprechenden Artefakten angezeigt werden. Die Scrum-Ereignisse sind Ereignisse mit Zeitrahmen. Das bedeutet, dass in einem Projekt jedes Scrum-Ereignis eine vordefinierte maximale Dauer hat. Diese Veranstaltungen ermöglichen allen am Projekt Beteiligten Transparenz über den Projektfortschritt. Die lebenswichtigen Ereignisse von Scrum sind:

Der Sprint
Sprintplanung
Tägliche Scrum-Meetings
Der Sprint Review
Die Sprint-Retrospektive

Der Sprint

Während eines Sprints wird ein funktionierendes Produkt Increment entwickelt. Sie dauert normalerweise zwei Wochen oder einen Monat und bleibt für alle Sprints im Projekt konstant. Wir können keine unterschiedlichen Dauern für die verschiedenen Sprints in einem Projekt haben. Ein neuer Sprint startet unmittelbar nach Abschluss des vorherigen Sprints.

Das Sprint-Ziel ist ein Ziel für den Sprint. Es gibt dem Team eine Anleitung, warum es das Inkrement erstellt. Es wird während des Sprint Planning-Meetings erstellt. Der Umfang des Sprints wird zwischen dem Product Owner und dem Team geklärt und neu ausgehandelt, sobald mehr über die Anforderungen erfahren wird. Somit ist jedem Sprint eine Definition dessen zugeordnet, was gebaut werden soll, ein Entwurf und der flexible Plan, der den Bau des Sprints, die Entwicklungsarbeit und das daraus resultierende Produktinkrement leiten wird.

Ein Sprint sollte abgesagt werden, wenn das Sprint-Ziel veraltet ist. Dies kann auftreten, wenn die Organisation die Richtung ändert oder wenn sich die Markt- oder Technologiebedingungen ändern. Ein Sprint kann nur vom Produktbesitzer abgesagt werden, andere haben jedoch Einfluss darauf.

Aufgrund der kurzen Dauer von Sprints ist eine Absage während eines Sprints selten sinnvoll. Da die Sprint-Stornierungen Ressourcen verbrauchen, um sich in einem anderen Sprint neu zu organisieren, sind sie sehr selten.

Wenn ein Sprint abgebrochen wird und ein Teil der während des Sprints produzierten Arbeit möglicherweise freigegeben werden kann, akzeptiert der Product Owner dies normalerweise. Alle unvollständigen Sprint-Backlog-Elemente werden wieder in das Product Backlog aufgenommen.

Sprintplanung

Die im Sprint auszuführenden Arbeiten werden im Sprint Planning Meeting geplant. Das Sprint Planning Meeting dauert maximal vier Stunden für zwei Wochen Sprints und acht Stunden für einen Monat Sprints. Es liegt in der Verantwortung des Scrum Masters, sicherzustellen, dass das Meeting stattfindet und dass alle erforderlichen Teilnehmer anwesend sind und den Zweck des geplanten Meetings verstehen. Der Scrum Master moderiert das Meeting, um den Fortbestand der Diskussion und den Abschluss rechtzeitig zu überwachen.

Sprint Planning konzentriert sich auf die folgenden zwei Fragen:

Was muss und kann im Sprint Increment geliefert werden?
Wie wird die für die Ausführung von Sprint erforderliche Arbeit geleistet?

Die Beiträge zu diesem Treffen sind -

Das Product Backlog
Das neueste Produkt Increment
Projizierte Kapazität des Teams während des Sprints
Vergangene Leistung des Teams

Das Scrum-Team erläutert die Funktionen, die während des Sprints entwickelt werden können. Der Product Owner bietet Erläuterungen zu den Product Backlog-Elementen. Das Team wählt die Elemente aus dem Product Backlog für den Sprint aus, da sie am besten beurteilen können, was sie im Sprint erreichen können. Das Team besteht aus Analysten, Designern, Entwicklern und Testern. Die Arbeit wird kollaborativ ausgeführt, wodurch Nacharbeiten minimiert werden.

Das Scrum-Team legt dann das Sprint-Ziel fest. Das Sprint-Ziel ist ein Ziel, das dem Team eine Anleitung gibt, warum es das Produktinkrement erstellt. Das Team entscheidet dann, wie die ausgewählte Funktionalität während des Sprints in ein funktionierendes Produktinkrement eingebaut wird. Die für diesen Sprint ausgewählten Product Backlog-Elemente sowie der Plan für deren Bereitstellung werden als Sprint Backlog bezeichnet.

Die Arbeit während eines Sprints wird während der Sprintplanung geschätzt und kann von unterschiedlicher Größe und / oder Aufwand sein. Am Ende des Sprint Planning-Meetings ist die Arbeit in Aufgaben von einer Dauer von einem Tag oder weniger unterteilt. Dies dient dazu, die Arbeitszuweisung zu vereinfachen und den Abschluss zu verfolgen. Wenn das Team feststellt, dass es zu viel oder zu wenig Arbeit hat, kann es die ausgewählten Product Backlog-Elemente mit dem Product Owner neu aushandeln.

Das Team kann auch andere (nicht Teil des Scrum-Teams) zur Teilnahme an der Sprint-Planungssitzung einladen, um technische oder domänenbezogene Ratschläge oder Hilfe bei der Schätzung zu erhalten.

Tägliche Scrum-Meetings

Das Daily Scrum Meeting ist ein 15-minütiges Meeting für das Team, das täglich durchgeführt wird, um die Arbeit seit dem letzten Daily Scrum Meeting schnell zu verstehen und einen Plan für die nächsten 24 Stunden zu erstellen. Dieses Meeting wird auch als Daily Stand Up Meeting bezeichnet.

Das Daily Scrum Meeting findet jeden Tag zur gleichen Zeit und am gleichen Ort statt, um die Komplexität zu verringern.

Während des Meetings erklärt jedes Teammitglied -

Was hat er gestern getan, um dem Team zu helfen, das Sprint-Ziel zu erreichen?
Was wird er heute tun, um dem Team zu helfen, das Sprint-Ziel zu erreichen?
Sieht er irgendwelche Hindernisse, die ihn oder das Team daran hindern, das Sprint-Ziel zu erreichen?

Daily Scrum wird fälschlicherweise als Statusverfolgungsereignis angesehen, obwohl es sich tatsächlich um ein Planungsereignis handelt.

Der Input für das Meeting sollte sein, wie das Team das Sprint-Ziel erreicht, und der Output sollte ein neuer oder überarbeiteter Plan sein, der die Bemühungen des Teams zur Erreichung des Sprint-Ziels optimiert.

Obwohl der Scrum Master das tägliche Scrum Meeting koordiniert und sicherstellt, dass die Ziele des Meetings erreicht werden, liegt das Meeting in der Verantwortung des Teams.

Bei Bedarf kann sich das Team unmittelbar nach dem Daily Scrum Meeting treffen, um detaillierte Diskussionen zu führen oder den Rest der Sprint-Arbeit neu zu planen.

Im Folgenden sind die Vorteile von Daily Scrum Meetings aufgeführt:

Verbessern Sie die Kommunikation innerhalb des Teams.
Identifizieren Sie gegebenenfalls Hindernisse, um eine frühzeitige Beseitigung derselben zu ermöglichen und die Auswirkungen auf den Sprint zu minimieren.
Markieren und fördern Sie schnelle Entscheidungen.
Verbessern Sie den Wissensstand des Teams.

Sprint Review

Am Ende jedes Sprints findet eine Sprint-Überprüfung statt. Während der Sprint-Überprüfung wird eine Präsentation des Inkrements überprüft, das freigegeben wird. In diesem Meeting arbeiten das Scrum-Team und die Stakeholder zusammen, um zu verstehen, was im Sprint getan wurde. Auf dieser Grundlage und bei Änderungen am Product Backlog während des Sprints gelangen die Teilnehmer zu den nächsten erforderlichen Schritten, mit denen der Wert optimiert werden kann. Ziel von Sprint Review ist es daher, gemeinsam Feedback zu erhalten und Fortschritte zu erzielen.

Die Sprint-Überprüfung wird normalerweise zwei Stunden lang für zweiwöchige Sprints und vier Stunden lang für einmonatige Sprints durchgeführt.

Der Scrum Master stellt sicher, dass -

Das Treffen findet statt.
Die Teilnehmer verstehen den Zweck.
Das Treffen konzentriert sich auf die erforderliche Tagesordnung und wird innerhalb der erforderlichen Dauer abgeschlossen.

Die Sprint-Überprüfung umfasst die folgenden Aspekte:

Zu den Teilnehmern zählen das Scrum-Team und wichtige Stakeholder, wie vom Product Owner eingeladen.
Der Product Owner erklärt, welche Product Backlog-Elemente während des Sprints abgeschlossen wurden und welche nicht.
Das Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden.
Das Team demonstriert die abgeschlossene Arbeit und beantwortet gegebenenfalls Fragen zum Inkrement.
Die gesamte Gruppe bespricht dann, was als nächstes zu tun ist. Somit liefert die Sprint-Überprüfung wertvolle Informationen zur Sprint-Planung des nachfolgenden Sprints.
Das Scrum-Team überprüft dann den Zeitplan, das Budget, die potenziellen Funktionen und den Marktplatz für die nächste erwartete Veröffentlichung des Produktinkrements.
Das Ergebnis der Sprint-Überprüfung ist ein aktualisiertes Product Backlog, das die wahrscheinlichen Product Backlog-Elemente für den nächsten Sprint definiert.

Sprint Retrospektive

Die Sprint-Retrospektive findet nach der Sprint-Überprüfung und vor der nächsten Sprint-Planung statt. Dies ist normalerweise eine einstündige Besprechung für Sprints mit einer Dauer von zwei Wochen und eine dreistündige Besprechung für Sprints mit einer Dauer von einem Monat.

Der Zweck der Sprint-Retrospektive ist -

Kombinieren Sie die Erkenntnisse aus dem letzten Sprint in Bezug auf Personen, Beziehungen, Prozesse und Werkzeuge.
Identifizieren Sie die wichtigsten Punkte, die gut gelaufen sind, und mögliche Verbesserungen.
Erstellung eines Plans zur Implementierung von Verbesserungen zur Steigerung der Produktqualität.

Die Sprint-Retrospektive bietet dem Scrum-Team die Möglichkeit, das Scrum-Prozess-Framework zu überprüfen und zu verbessern, um das nächste Sprint-Ergebnis effektiver zu gestalten.

Reference

Scrum-Artefakte bieten wichtige Informationen, die das Scrum-Team und die Stakeholder kennen müssen, um das in der Entwicklung befindliche Produkt, die durchgeführten Aktivitäten und die im Projekt geplanten Aktivitäten zu verstehen. Die folgenden Artefakte sind in Scrum Process Framework definiert:

Produktrückstand
Sprint Backlog
Burn-Down-Diagramm
Increment

Dies sind die minimal erforderlichen Artefakte in einem Scrum-Projekt, und Projektartefakte sind nicht auf diese beschränkt.

Produktrückstand

Das Product Backlog ist eine geordnete Liste von Funktionen, die als Teil des Endprodukts benötigt werden, und es ist die einzige Quelle für Anforderungen, die an Änderungen am Produkt vorgenommen werden müssen.

Das Product Backlog listet alle Features, Funktionen, Anforderungen, Verbesserungen und Korrekturen auf, die die Änderungen darstellen, die in zukünftigen Versionen am Produkt vorgenommen werden müssen. Product Backlog-Elemente haben die Attribute Beschreibung, Bestellung, Schätzung und Wert. Diese Elemente werden normalerweise als User Stories bezeichnet. Der Product Owner ist für das Product Backlog verantwortlich, einschließlich dessen Inhalt, Verfügbarkeit und Bestellung.

Ein Product Backlog ist ein sich entwickelndes Artefakt. Die früheste Version enthält möglicherweise nur die ursprünglich bekannten und am besten verstandenen Anforderungen. Das Product Backlog wird entwickelt, während das Produkt und die Umgebung, in der es verwendet wird, Fortschritte machen. Das Product Backlog ändert sich ständig, um das zu berücksichtigen, was erforderlich ist, um es effektiv zu machen. Solange ein Produkt existiert, existiert auch sein Product Backlog.

Wenn das zu erstellende Produkt verwendet wird und an Wert gewinnt, wird das Product Backlog zu einer größeren und umfassenderen Liste. Änderungen der Geschäftsanforderungen, Marktbedingungen oder Technologien führen zu Änderungen im Product Backlog und machen es zu einem Live-Artefakt.

Bei der Verfeinerung des Product Backlogs werden den Product Backlog-Elementen Details, Schätzungen und Prioritätsreihenfolgen hinzugefügt. Dies ist ein fortlaufender Prozess, der vom Product Owner und dem Team durchgeführt wird. Das Scrum-Team entscheidet, wie und wann eine Verfeinerung vorgenommen werden soll.

Product Backlog-Elemente können jederzeit vom Product Owner oder nach Ermessen des Product Owner aktualisiert werden.

Übergeordnete Product Backlog-Elemente sind normalerweise klarer und detaillierter als untergeordnete. Genauere Schätzungen werden aufgrund der größeren Klarheit und Detailgenauigkeit vorgenommen. Je niedriger die Reihenfolge, desto geringer ist das Detail.

Product Backlog-Elemente, die wahrscheinlich die Kandidatenanforderungen für den bevorstehenden Sprint sind, werden verfeinert, damit diese Elemente während des Sprints entwickelt werden können. Product Backlog-Elemente, die vom Team innerhalb eines Sprints entwickelt werden können, gelten als zur Auswahl in einem Sprint-Planungsmeeting bereit.

Sprint Backlog

Das Sprint-Backlog besteht aus den für den Sprint ausgewählten Product Backlog-Elementen sowie einem Plan für die Bereitstellung des Produktinkrements und die Verwirklichung des Sprint-Ziels.

Das Sprint-Backlog ist eine Prognose des Teams darüber, welche Funktionen im nächsten Inkrement verfügbar sein werden und welche Arbeiten erforderlich sind, um diese Funktionen als funktionierendes Produktinkrement bereitzustellen.

Das Sprint Backlog ist ein Plan mit genügend Details, die verstanden werden können, aber das Team, um es im Daily Scrum zu verfolgen. Das Team ändert das Sprint-Backlog während des Sprints und das Sprint-Backlog entsteht während des Sprints. Diese Entstehung tritt auf, wenn das Team den Plan durcharbeitet und mehr über die Arbeit erfährt, die zur Erreichung des Sprint-Ziels erforderlich ist.

Wenn neue Arbeiten erforderlich sind, fügt das Team sie dem Sprint-Backlog hinzu. Sobald die Arbeit ausgeführt oder abgeschlossen ist, wird die geschätzte verbleibende Arbeit aktualisiert. Wenn Elemente des Plans als unnötig erachtet werden, werden sie entfernt. Nur das Team kann sein Sprint-Backlog während eines Sprints ändern. Das Sprint-Backlog ist ein gut sichtbares Echtzeitbild der Arbeit, die das Team während des Sprints ausführen möchte, und es gehört ausschließlich dem Team.

Zuwachs

Das Inkrement ist die Summe aller während eines Sprints abgeschlossenen Product Backlog-Elemente, kombiniert mit den Inkrementen aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement ein funktionierendes Produkt sein, was bedeutet, dass es sich in einem brauchbaren Zustand befinden muss. Es muss in einwandfreiem Zustand sein, unabhängig davon, ob der Product Owner beschließt, es tatsächlich freizugeben.

Das Scrum-Team muss einen Konsens darüber haben, was als Inkrement angesehen wird. Dies ist je nach Scrum-Team sehr unterschiedlich. Die Teammitglieder müssen jedoch ein gemeinsames Verständnis dafür haben, was es bedeutet, dass die Arbeit abgeschlossen ist. Dies wird verwendet, um zu beurteilen, wann die Arbeiten am Produktinkrement abgeschlossen sind.

Das gleiche Verständnis hilft dem Team zu wissen, wie viele Product Backlog-Elemente es während einer Sprint-Planung auswählen kann. Der Zweck jedes Sprints besteht darin, Inkremente potenziell freisetzbarer Funktionen bereitzustellen.

Teams liefern bei jedem Sprint eine Steigerung der Produktfunktionalität. Dieses Inkrement kann verwendet werden, sodass ein Product Owner es sofort freigeben kann. Wenn das Verständnis eines Inkrements Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Scrum-Teams es mindestens befolgen. Wenn es sich nicht um eine Konvention der Entwicklungsorganisation handelt, muss das Scrum-Team eine für das Produkt geeignete Definition von Inkrement definieren.

Jedes Inkrement ist additiv zu allen vorherigen Inkrementen und wird gründlich getestet, um sicherzustellen, dass alle Inkremente zusammenarbeiten.

Mit zunehmender Reife der Scrum-Teams wird erwartet, dass ihre Definitionen von Inkrementen um strengere Kriterien für eine höhere Qualität erweitert werden. Jedes Produkt sollte eine Definition von Inkrement haben, die ein Standard für alle daran durchgeführten Arbeiten ist.

Sprint Burn-Down-Diagramm

Zu jedem Zeitpunkt in einem Sprint kann die im Sprint-Backlog verbleibende Gesamtarbeit summiert werden. Das Team verfolgt diese verbleibende Gesamtarbeit für jedes tägliche Scrum, um die Wahrscheinlichkeit des Erreichens des Sprint-Ziels zu prognostizieren. Durch die Verfolgung der verbleibenden Arbeit während des Sprints kann das Team den Fortschritt verwalten.

Das Sprint Burn-Down-Diagramm ist eine Methode zur Ermittlung der vom Scrum-Team aufgewendeten Arbeit. Dies hat sich als nützliche Technik zur Überwachung des Sprint-Fortschritts auf dem Weg zum Sprint-Ziel erwiesen.

Der Product Owner verfolgt diese Gesamtarbeit, die mindestens bei jeder Sprint-Überprüfung verbleibt. Der Product Owner vergleicht diesen Betrag mit der bei früheren Sprint-Überprüfungen verbleibenden Arbeit, um den Fortschritt bei der Fertigstellung der geplanten Arbeit zum gewünschten Zeitpunkt für das Ziel zu bewerten. Diese Informationen werden an alle Beteiligten weitergegeben.

Fazit

Scrums Rollen, Ereignisse, Artefakte und Regeln sind unvermeidlich. Wenn nur einige Teile von Scrum implementiert sind, ist das Ergebnis nicht Scrum. Scrum muss vollständig implementiert werden und funktioniert gut, wenn es mit anderen Techniken, Methoden und Praktiken in Einklang gebracht wird.

Reference

Wie Sie verstanden haben, werden die User Stories häufig zur Beschreibung der Produktmerkmale verwendet und sind Teil der Scrum-Artefakte. Product Backlog und Sprint Backlog.

Benutzergeschichten

In der Softwareentwicklung spielen die Produktmerkmale eine entscheidende Rolle. Es sind die Funktionen, die der Benutzer letztendlich gerne im Endprodukt verwendet. Sie werden in der allgemeinen Terminologie als Anforderungen bezeichnet. Der Erfolg eines Softwareentwicklungsprojekts besteht darin, die Benutzeranforderungen genau und angemessen zu verstehen und sie dann im Endprodukt zu implementieren. Daher müssen Anforderungen oder Produktmerkmale dem Entwicklungsprojektteam gründlich bekannt sein.

Im Jahr 1999 entwickelte Kent Beck einen Begriff User Stories für die Produktmerkmale. Er beschrieb, dass eine User Story aus Anwendersicht darüber erzählt wird, was er oder sie haben möchte, anstatt was das System für ihn tun kann. Daher wurde die Ansicht von Produkt zu Benutzer vollständig geändert und User Stories wurden de facto zum Standard für Anforderungen in allen agilen Frameworks.

In Scrum-Projekten ist das Product Backlog eine Liste von User Stories. Diese User Stories werden priorisiert und im Sprint-Planungsmeeting in das Sprint-Backlog aufgenommen.

Die Schätzung basiert auch auf User Stories und die Größe des Produkts wird in User Story Points geschätzt.

Die User Story-Struktur

Die User Story-Struktur lautet wie folgt:

Als <Typ User> ,

Ich möchte <eine Aufgabe ausführen> ,

Damit <ich ein Ziel / Nutzen / Wert erreichen kann> .

Lassen Sie uns einen Blick darauf werfen, wie eine User Story für das Szenario eines Bankkunden gestaltet ist, der Bargeld am Geldautomaten abhebt.

User Story: Bargeldbezug des Kunden

Als ein Customer,

ich will withdraw cash from an ATM,

Damit I don't have to wait in line at the Bank

Akzeptanzkriterien für User Storys

Für jede User Story ist außerdem ein Akzeptanzkriterium definiert, sodass die Richtigkeit der Implementierung der User Story durch Bestehen des auf dem Akzeptanzkriterium basierenden Abnahmetests bestätigt wird.

Im Folgenden finden Sie das Beispielakzeptanzkriterium für das Beispiel der Barabhebung von User Story-Kunden.

Acceptance Criterion 1:

Given dass das Konto kreditwürdig ist

Und die Karte ist gültig
Und der Spender enthält Bargeld,

When Der Kunde fordert das Geld an

Then Stellen Sie sicher, dass das Konto belastet wird

Und stellen Sie sicher, dass Bargeld ausgegeben wird
Und stellen Sie sicher, dass die Karte zurückgegeben wird.

Acceptance Criterion 2:

Given dass das Konto überzogen ist

Und die Karte ist gültig

When Der Kunde fordert das Geld an

Then Stellen Sie sicher, dass die Ablehnungsmeldung angezeigt wird

Und stellen Sie sicher, dass kein Bargeld ausgegeben wird
Und stellen Sie sicher, dass die Karte zurückgegeben wird.

User Stories schreiben

Der Product Owner ist verantwortlich für das Product Backlog und damit für die User Stories. Dies bedeutet jedoch nicht, dass nur der Product Owner die User Stories schreibt. Jeder im Scrum-Team kann die User Stories schreiben und die Aktivität kann über das Projekt verteilt werden, wenn die Anforderungen verfeinert und neue Funktionen hinzugefügt werden.

Nichtfunktionale Anforderungen in User Stories

Es ist möglich, die nicht funktionalen Anforderungen auch in die User Stories einzubeziehen. In dem angegebenen ATM-Beispiel ist der ATM, der dem Benutzer rund um die Uhr und 365 Tage zur Verfügung steht, eine nicht funktionale Anforderung, die durch einen Anwendungsfall beschrieben werden kann.

Verwalten von User Stories

User Stories werden im Product Backlog verwaltet. Die User Stories sind nach Priorität geordnet. Die User Storys mit der höchsten Priorität werden auf eine detaillierte Ebene verfeinert, während die User Storys mit der niedrigsten Priorität auf einer geringeren Detailebene gehalten werden. Für jeden Sprint werden die am meisten priorisierten und damit detaillierteren User Stories in das Sprint-Backlog aufgenommen. Wenn eine User Story zum Product Backlog hinzugefügt werden soll, wird zuerst ihre Priorität festgelegt und entsprechend ihrer Position gemäß der Priorität platziert. Die User Stories können jederzeit neu priorisiert werden. Bei Bedarf können auch User Storys entfernt werden.

Vorteile mit User Stories

Der Hauptvorteil von User Story liegt in der benutzerzentrierten Definition selbst. Dies liegt daran, dass letztendlich der Benutzer das Produkt in den relevanten Benutzerszenarien verwendet. Es verbindet die Endbenutzer mit den Teammitgliedern.
Die Syntax der User Story selbst stellt sicher, dass das Ziel oder der Nutzen oder Wert, den der Benutzer erreichen möchte, erfasst wird.
Da die Akzeptanzkriterien Teil der User Story selbst sind, ist dies ein zusätzlicher Vorteil für das Scrum-Team.
Es ist möglich, während der Ausführung des Projekts Änderungen an einer User Story vorzunehmen. Wenn der Umfang der User Story groß wird, muss sie in kleinere User Storys aufgeteilt werden. Die Bedingungen im Akzeptanzkriterium können ebenfalls geändert werden.
Wenn den Benutzern am Ende jedes Sprints funktionierende Produktinkremente zugestellt werden, kann das Scrum-Team in einem Sprint-Review-Meeting Feedback von den Benutzern erhalten. Dies ermöglicht die kontinuierliche Einbeziehung von Feedback in das Produkt.

Fazit

Die User Stories von Scrum bringen die Benutzer näher an das Scrum-Team heran und verhindern Überraschungen in letzter Minute.

Die Sprint-Verfolgung erfolgt normalerweise mithilfe des Burn-Down-Diagramms. Das Burn-Down-Diagramm zeigt den verbleibenden Aufwand in Stunden am Tag. Betrachten wir zum Beispiel einen 2-wöchigen Sprint -

Sprint Duration: 2 Wochen

No. of Days per Week: 5

No. of Hrs. per Day: 6

No. of Resources: 6

Daher beträgt die verbleibende Gesamtleistung zu Beginn des Sprints 2 * 5 * 6 * 6 = 360 Stunden.

In einem idealen Szenario werden daher 36 Stunden Arbeit in der verbleibenden Arbeit reduziert, und das Abbranddiagramm sieht wie folgt aus:

Wenn die Sprintarbeit wie geplant täglich ausgeführt wird, ist der Scrum-Fortschritt fast auf den idealen Balken ausgerichtet.

Wenn sich die Sprintarbeit verzögert und der Zeitaufwand nicht eingehalten wird, sieht das Burn-Down-Diagramm wie folgt aus:

Da das Burn-Down-Diagramm jedoch täglich erstellt wird und der Schlupf frühzeitig bekannt ist, können Korrekturmaßnahmen ergriffen werden, um die Sprint-Zeitlinie einzuhalten. Angenommen, das Team streckt sich, um die Zeitachse einzuhalten. Das Burn-Down-Diagramm sieht wie folgt aus:

Somit kann zu jedem Zeitpunkt in einem Sprint die gesamte im Sprint verbleibende Arbeit visualisiert und die Möglichkeit, die Sprint-Zeitachse einzuhalten, verbessert werden.

Fazit

Burn-Down-Diagramme helfen dem Scrum-Team, den Fortschritt und die Maßnahmen zu verfolgen, die zur Erreichung des Sprintziels ergriffen werden müssen.

In Scrum-Projekten wird die Schätzung vom gesamten Team während des Sprint-Planungsmeetings durchgeführt. Das Ziel der Schätzung wäre es, die User Stories für den Sprint nach Priorität und nach der Fähigkeit des Teams zu berücksichtigen, während des Zeitrahmens des Sprints zu liefern.

Der Product Owner stellt sicher, dass die priorisierten User Stories klar sind, einer Schätzung unterzogen werden können und an den Anfang des Product Backlogs gebracht werden.

Da das Scrum-Team insgesamt für die Lieferung des Produktinkrements verantwortlich ist, wird sorgfältig darauf geachtet, die User Stories für den Sprint basierend auf der Größe des Produktinkrements und dem dafür erforderlichen Aufwand auszuwählen.

Die Größe des Produktinkrements wird anhand von User Story-Punkten geschätzt. Sobald die Größe bestimmt ist, wird der Aufwand anhand der vergangenen Daten geschätzt, dh anhand des Aufwands pro User Story Point, der als Produktivität bezeichnet wird.

Scrum-Schätztechniken

Die Scrum-Schätzung von User Stories bezieht sich auf den Schwierigkeitsgrad für jede der User Stories. Zur Beurteilung des Schwierigkeitsgrades wird eine bestimmte Skala verwendet.

Es gibt verschiedene Arten von Skalen, die in der Scrum-Schätzung verwendet werden. Es folgen einige Beispiele -

Numerische Größe (1 bis 10)
T-Shirt Größen (XS, S, M, L, XL XXL, XXXL)
Fibonacci-Sequenz (1, 2, 3, 5, 8, 13, 21, 34 usw.)
Hunderassen (Chihuahua, ………, Deutsche Dogge)

Die Schätztechnik wird normalerweise so gewählt, dass das gesamte Scrum-Team mit den Werten der Skala vertraut und vertraut ist. Die am häufigsten verwendete und beliebteste Technik ist Planning Poker, die auf der Fibonacci-Sequenz basiert.

Planung der Pokertechnik

Bei der Planning Poker Estimation-Technik werden Schätzungen für die User Stories durch das Spielen von Planning Poker abgeleitet. Das gesamte Scrum-Team ist involviert und führt zu schnellen, aber zuverlässigen Schätzungen.

Planning Poker wird mit einem Kartenspiel gespielt. Da die Fibonacci-Sequenz verwendet wird, haben die Karten Zahlen - 1, 2, 3, 5, 8, 13, 21, 34 usw. Diese Zahlen repräsentieren die Story Points. Jeder Schätzer hat ein Kartenspiel. Die Zahlen auf den Karten sollten groß genug sein, um für alle Teammitglieder sichtbar zu sein, wenn eines der Teammitglieder eine Karte hochhält.

Eines der Teammitglieder wird als Moderator ausgewählt. Der Moderator liest die Beschreibung der User Story, für die eine Schätzung vorgenommen wird. Wenn die Schätzer Fragen haben, beantwortet der Product Owner diese.

Jeder Schätzer wählt privat eine Karte aus, die seine Schätzung darstellt. Karten werden erst angezeigt, wenn alle Schätzer eine Auswahl getroffen haben. Zu diesem Zeitpunkt werden alle Karten gleichzeitig umgedreht und hochgehalten, sodass alle Teammitglieder jede Schätzung sehen können.

In der ersten Runde ist es sehr wahrscheinlich, dass die Schätzungen variieren. Die hohen und niedrigen Schätzer erklären den Grund für ihre Schätzungen. Es ist darauf zu achten, dass alle Diskussionen nur zum Verständnis gedacht sind und nichts persönlich zu nehmen ist. Der Moderator muss dies sicherstellen.

Das Team kann die Geschichte und ihre Schätzungen noch einige Minuten diskutieren.

Der Moderator kann sich Notizen zu der Diskussion machen, die hilfreich sein wird, wenn die spezifische Geschichte entwickelt wird. Nach der Diskussion schätzt jeder Schätzer neu, indem er erneut eine Karte auswählt. Die Karten werden wieder privat gehalten, bis alle geschätzt haben, und zu welchem Zeitpunkt sie gleichzeitig umgedreht werden.

Wiederholen Sie den Vorgang, bis die Schätzungen zu einer einzelnen Schätzung konvergieren, die für die Story verwendet werden kann. Die Anzahl der Schätzungsrunden kann von einer User Story zur anderen variieren.

Vorteile der Planung der Pokerschätzung

Planning Poker kombiniert drei Schätzmethoden:

Expert Opinion: Bei einem auf Expertenmeinungen basierenden Schätzungsansatz wird ein Experte gefragt, wie lange etwas dauern wird oder wie groß es sein wird. Der Experte gibt eine Schätzung ab, die sich auf seine Erfahrung, seine Intuition oder sein Bauchgefühl stützt.

Die Schätzung von Expertenmeinungen nimmt normalerweise nicht viel Zeit in Anspruch und ist im Vergleich zu einigen Analysemethoden genauer.

Analogy: Die Analogie-Schätzung verwendet den Vergleich von User Stories. Die User Story unter Schätzung wird mit ähnlichen User Stories verglichen, die zuvor implementiert wurden. Dies führt zu genauen Ergebnissen, da die Schätzung auf nachgewiesenen Daten basiert.

Disaggregation: Die Disaggregationsschätzung erfolgt durch Aufteilen einer User Story in kleinere, einfacher zu schätzende User Stories. Die User Stories, die in einen Sprint aufgenommen werden sollen, sind normalerweise im Bereich von zwei bis fünf Tagen zu entwickeln. Daher müssen die User Stories, die möglicherweise länger dauern, in kleinere Anwendungsfälle aufgeteilt werden. Dieser Ansatz stellt auch sicher, dass es viele Geschichten gibt, die vergleichbar sind.

Fazit

Planning Poker ist ein unterhaltsamer und dennoch produktiver Ansatz zur Schätzung. Da die Sitzung offen ist, bevor die endgültige Schätzung vorliegt, kann das Team leicht zu einem Konsens gelangen und einen umfassenden Überblick über die Umsetzung der vorliegenden User Story erhalten.

Scrum Tools erleichtern die Planung und Nachverfolgung von Scrum-Projekten. Sie bieten einen zentralen Ort für die Verwaltung des Produkt-Backlogs, des Sprint-Backlogs, die Planung und Verfolgung von Sprints, die Anzeige von Burndown-Diagrammen, die Durchführung täglicher Scrum-Meetings und die Durchführung von Scrum-Retrospektiven.

Es gibt viele verschiedene Arten von Scrum Tools. Einige sind kostenlos (Open Source), andere kostenpflichtig und für andere erhalten Sie eine destillierte Version des Tools. Um jedoch alle Funktionen und Skalierbarkeit zu erhalten, müssen Sie eine Vollversion kaufen.

Verfügbare Scrum Tools

Im Folgenden finden Sie eine Liste einiger Scrum Tools, die ab dem Tag auf dem Markt erhältlich sind. Die Open Source Tools sind mit einem Sternchen gekennzeichnet.

Axosoft	Airgile	Agiles Cockpit	Jira (GreenHopper)	Mischen
Scrumwise	Agilo für Scrum	Bananen-Scrum	Kunagi	OnTime Now
Version Eins	AgileWrap	Daily-Scrum	Intervalle	Pango Scrum
Acunote	Agiles Tracking-Tool *	Digaboard *	iMeta Agilität	Pivotal Tracker
Agile Agenda	Agile Aufgabe	EasyBacklog	Ice Scrum *	pmScrum
Agile Bank	Agile Suppe	Erklären Sie PMT	Hansoft	Prj Planer
Agiler Kumpel	Agiler Manager	Agile Express *	GravityDev	Projektkarten
Agile Fant *	Agiles Protokoll	Fire Scrum *	Drehpunkt *	Quantenflüstern
Quick Scrum	Rückblick *	Scrum'd	Scrum Factory *	Scrumpy
Rally Dev	Scrinch *	Scrum Dashboard *	Scrum Edge	Scrum Pad
Redmine Backlogs	Scrum 2 Go	Scrum Desk	Scrum Do.	Tweet Scrum
Scrumrf	Scrum Time *	Scrumwise	Wählen Sie Solution Factory	Angehen*
Urban Turtle	ScrumTool	Scrum Works	Zeitkasten	Tangy Orange Scrum

Fazit

Agil im Allgemeinen, Scrum im Besonderen bedeutet nicht, dass keine Dokumentation vorhanden ist. Die Scrum-Artefakte sind definiert, die Scrum-Planung und das Tracking sind gut etabliert.

Scrum Tools erleichtern das Erfassen und Verfolgen von Informationen zu den Scrum-Projekten. Die Auswahl des Tools hängt von den Funktionen ab, die von der Organisation benötigt werden, zusätzlich zu den Anforderungen für jedes andere Tool.

Scrum unterstützt die kontinuierliche Zusammenarbeit zwischen Kunden, Teammitgliedern und relevanten Stakeholdern. Sein zeitlich begrenzter Ansatz und das kontinuierliche Feedback des Produktbesitzers stellen sicher, dass das Produkt jederzeit mit wesentlichen Funktionen ausgestattet ist. Darüber hinaus bietet Scrum den verschiedenen Rollen im Projekt unterschiedliche Vorteile.

Vorteile für den Kunden

Die Sprints sind von kürzerer Dauer und bei jeder Sprintplanung werden priorisierte User Stories berücksichtigt. Es stellt sicher, dass bei jeder Sprintauslieferung die vom Kunden sofort geforderten Funktionen sofort berücksichtigt werden. Wenn ein Kunde eine Änderungsanforderung stellt, wird diese im aktuellen Sprint absorbiert oder im nächsten Sprint berücksichtigt. So reagiert das Entwicklungsteam sehr schnell auf die Anforderungen des Kunden.

Vorteile für die Organisation

Die Organisation kann sich auf den Aufwand konzentrieren, der für die Entwicklung der priorisierten User Stories erforderlich ist, und so den Aufwand und die Nacharbeit reduzieren. Aufgrund der spezifischen Vorteile von Scrum für den Kunden sind eine höhere Effizienz des Entwicklungsteams, Kundenzufriedenheit und damit Kundenbindung und Kundenreferenzen möglich. Es erhöht das Marktpotential der Organisation.

Vorteile für Produktmanager

Der Produktmanager spielt im Projekt die Rolle des Product Owners. Der Produktbesitzer ist dafür verantwortlich, die Kundenzufriedenheit sicherzustellen. Da Scrum schnelle Reaktionen, Priorisierung der Arbeit und Übernahme von Änderungen ermöglicht, kann der Produktmanager problemlos sicherstellen, dass die Arbeit auf die Kundenbedürfnisse ausgerichtet ist, was wiederum die Kundenzufriedenheit gewährleistet.

Vorteile für Projektmanager

Der Projektmanager spielt im Projekt die Rolle des Scrum Masters. Der kollaborative Charakter von Scrum ermöglicht eine einfache und konkrete Planung und Nachverfolgung. Durch die Verwendung von Burndown-Diagrammen, um die verbleibende Arbeit zu verstehen, und die täglichen Scrum-Meetings wird der Projektmanager jederzeit über den Status des Projekts informiert. Dieses Bewusstsein ist wichtig, um das Projekt zu überwachen und Probleme schnell zu erkennen und anzugehen.

Vorteile für das Entwicklungsteam

Aufgrund der zeitlichen Abfolge der Sprints und der Lieferung von Arbeitsprodukten am Ende jedes Sprints ist das Entwicklungsteam begeistert, dass ihre Arbeit sofort verwendet wird. Die eingebaute Teamzusammenarbeit macht dem Team Spaß an der Arbeit, die sie leisten. Da die User Stories für jeden Sprint auf Kundenprioritäten basieren, versteht das Team auch, dass ihre Arbeit geschätzt wird.

Scrum-Zertifizierungen werden von der Scrum Alliance angeboten. Folgende Zertifizierungen werden angeboten -

Zertifizierter ScrumMaster (CSM)
Zertifizierter Scrum Product Owner (CSPO)
Certified Scrum Practitioner (CSP)
Zertifizierter Scrum Coach (CSC)
Zertifizierter Scrum Trainer (CST)

Zertifizierter ScrumMaster (CSM)

Certified Scrum Master ist die Grundzertifizierung, um Mitglied der Scrum Alliance zu werden, die Rolle des Scrum Masters zu spielen und sich für andere Zertifizierungen zu qualifizieren. Die Zertifizierung erfordert die Teilnahme am CSM-Kurs. Danach erhält der Kandidat eine E-Mail mit den Details der Scrum-Mitgliedschaft und der CSM-Online-Prüfung. Nach der Prüfung erhält der Kandidat die Certified ScrumMaster (CSM) -Zertifizierung.

Zertifizierter Scrum Product Owner (CSPO)

Certified Scrum Product Owner ist die Grundzertifizierung, um Mitglied der Scrum Alliance zu werden, die Rolle des Product Owner zu spielen und für andere Zertifizierungen berechtigt zu sein.

Certified Scrum Practitioner (CSP)

Certified Scrum Practitioner ist die Zertifizierung für erfahrene ScrumMasters und Product Owners. Der Kandidat sollte mindestens ein Jahr lang ScrumMaster oder Product Owner sein. Der Kandidat muss eine Bewerbung einreichen, die eine detaillierte Beschreibung dessen enthält, was er in der angegebenen Rolle getan hat.

Es ist möglich, dass ein Kandidat die CSP-Zertifizierung unmittelbar nach der CSM-Zertifizierung oder der CSPO-Zertifizierung erwirbt, sofern der Kandidat die Rolle des ScrumMasters oder des Product Owners für die erforderliche Dauer aktiv ausübt.

Zertifizierter Scrum Coach (CSC)

Certified Scrum Coach ist die Zertifizierung für diejenigen, die sich auf Coaching konzentrieren. Die Zertifizierung setzt voraus, dass der Kandidat Scrum-Teams durch die Einführung und Beherrschung von Scrum in den letzten 5 Jahren mindestens 1500 Stunden lang trainiert hat.

Zertifizierter Scrum Trainer (CST)

Certified Scrum Trainer ist die Zertifizierung für diejenigen, die CSM- oder CSPO-Klassen unterrichten möchten. Bewerber müssen entweder einen CSM oder einen CSPO haben und sollten vor der Bewerbung mindestens ein Jahr lang CSP sein.

Im Folgenden finden Sie einige häufig gestellte Fragen zu Scrum -

Question: What is the difference between Scrum and Agile Development?

Answer : Agile Development ist eine Softwaremethode, während Scrum eines der Prozess-Frameworks ist, die Agile folgen.

Question: Are Sprints and Iterations the same?

Answer: Sowohl Scrints of Scrum als auch Iterations of Iterative Incremental liefern funktionierende Produktinkremente. Diese unterscheiden sich jedoch darin:

Die Lebenszyklen von Sprint und Iteration sind unterschiedlich.
Sprints sind zeitlich begrenzt, Iterationen hingegen nicht.
Die Dauer von Sprints ist viel geringer als die Dauer von Iterationen.

Question: Is Scrum Master a job title or a role that someone with an existing job title fills?

Answer: Scrum Master ist eine Rolle, die jemand mit einer Berufsbezeichnung ausfüllt. Normalerweise spielt die Person, die die Rolle des Projektmanagers spielt, auch die Rolle des ScrumMasters.

Question: Can Product Owner and ScrumMaster’s roles be played by the same person?

Answer: Nein, da der Besitz unterschiedlich ist. Der Product Owner kümmert sich um das Product Backlog, die Priorisierung von User Stories und die Validierung des Arbeitsproduktinkrements mit den dem Sprint zugewiesenen User Stories.

Question: Is it that Scrum Projects need not have any Documentation?

Answer : Nein. Scrum-Projekte erfordern wie alle anderen Projekte Dokumentation wie User Stories, Design, Testfälle usw.

Fazit

Agile und Scrum sind nicht dasselbe. Scrum ist eines der Prozess-Frameworks zur Anpassung von Agile. Scrum wird Teams mit erfahrenen Teammitgliedern empfohlen, da das Framework auch eine hervorragende Zusammenarbeit und Selbstorganisation erfordert. Wenn die Scrum-Regeln nicht strikt befolgt werden, kann ein Projekt zum Scheitern führen. Daher ist es notwendig, die Scrum-Konzepte im gesamten Team richtig zu verstehen. Da die Sprints von kurzer Dauer sind und eine Zeitbox haben, bleibt keine Zeit, um die Scrum-Besonderheiten im Job zu lernen, selbst wenn ein Scrum-Master das Projekt kontinuierlich überwacht.