agile methodology beginner s guide agile method
Ein vollständiger Leitfaden zur agilen Methodik: (20+ detaillierte Tutorials zur agilen Scrum-Methodik)
Dies ist der Leitfaden für Softwareentwickler und Tester, um das sehr berühmte zu verstehen und daran zu arbeiten Agile SCRUM-Methodik für Softwareentwicklung und -tests . Lernen Sie die grundlegenden, aber wichtigen Terminologien des Agile Scrum-Prozesses sowie ein reales Beispiel für den gesamten Prozess kennen.
Wir haben alle Agile Tutorials in dieser Reihe für Ihre Bequemlichkeit aufgelistet. Ich hoffe, sie werden Ihnen immens helfen.
Behandelten Themen: Was ist agil, was ist Scrum, agile Methodik in der Softwareentwicklung und beim Testen, agiles Testen, agiler Scrum-Prozess, Scrum-Methodik mit Scrum Team und Scrum Master.
Was du lernen wirst:
- Liste der Lernprogramme für agile Methoden
- Einführung in die agile Entwicklung
- Agile Methodik
- Scrum-Methodik
Liste der Lernprogramme für agile Methoden
Tutorial Nr. 1: Agile Scrum-Methoden (Dieses Tutorial)
Tutorial # 2: Agiles Manifest
Tutorial # 3: Scrum Team & ihre Rollen und Verantwortlichkeiten
Tutorial # 4: Scrum-Artefakte
Tutorial Nr. 5: Scrum-Ereignisse
Tutorial # 6: Fehlerprüfung in Scrum
Tutorial Nr. 7: Autarke Scrum-Teams
Tutorial Nr. 8: Drei-Amigo-Prinzip
Tutorial Nr. 9: SAFe - Skaliertes agiles Framework
Tutorial Nr. 10: Agiles Scrum-Quiz
MEHR Empfohlene Agile Scrum-Tutorials:
Tutorial Nr. 11: Top Agile Estimation Techniques
Tutorial Nr. 12: Agiles Wasserfall-Hybridmodell
Tutorial Nr. 13: Kanban gegen Scrum gegen Agile
Tutorial Nr. 14: JIRA Agile Tutorial
Tutorial Nr. 15: Agile retrospektive Meetings
Tutorial Nr. 16: Rolle von Business Analysten in SCRUM
Tutorial Nr. 17: QA-Rolle in Scrum
Tools und Interviewfragen:
Tutorial Nr. 18: Agile Testwerkzeuge
Tutorial Nr. 19: Beste agile Projektmanagement-Tools
Tutorial Nr. 20: Top Agile Interview Fragen
Tutorial Nr. 21: Top Scrum Interview Fragen
Beginnen wir mit dem ersten Tutorial der Reihe - Agile Scrum Introduction.
Einführung in die agile Entwicklung
Agil in der Softwareentwicklung:
Agile ist eines der weltweit am häufigsten verwendeten und anerkannten Softwareentwicklungs-Frameworks.
Die meisten Organisationen haben es in der einen oder anderen Form übernommen, aber es ist noch ein langer Weg bis zur Reife ihrer Adoptionsprogramme. Das einzige Ziel dieser Reihe von Tutorials ist es, Technologie- und Nicht-Technologie-Profis in die agile Welt einzubeziehen.
Wir werden Sie Schritt für Schritt durch die agile Reise führen, bis Sie die Philosophie hinter der Verwendung von Agile, ihre Vorteile und deren Anwendung verstanden haben. Diese Reihe soll den Lesern die Möglichkeit geben, agiles und Scrum-Lernen in ihre Arbeit einzubeziehen.
In diesem speziellen Tutorial erfahren Sie, warum Agile benötigt wurde und wie es erstellt wurde. Das Grundlegende dabei ist, Ihnen das Konzept der agilen Einführung in der Softwareentwicklungsbranche näher zu bringen.
Geschichte von Agile
Agile wurde geboren, als an einem schönen Tag 17 Personen mit unterschiedlichen Entwicklungsmethoden zusammenkamen, um ein Brainstorming durchzuführen, wenn es eine mögliche alternative Lösung zur Softwareentwicklung gab, die zu einer schnelleren Entwicklungszeit führen und weniger dokumentationsintensiv sein könnte.
Zu dieser Zeit dauerte die Softwareentwicklung so lange, bis das Projekt fertig war und das Geschäft sich weiterentwickelt hatte und sich die Anforderungen geändert hatten. Somit konnte ein Projekt die Geschäftsanforderungen nicht erfüllen, selbst wenn es seine definierten Ziele erreichen konnte.
So kamen diese Verfechter verschiedener Software-Engineering-Techniken zusammen und das Endergebnis ihres Treffens war das sogenannte „agile Manifest“, das wir im nächsten Tutorial dieser Reihe ausführlich diskutieren werden.
Aber die Agilität, die an diesem Tag geboren wurde, ist nicht das, was wir heute in Organisationen sehen. Die von diesen Experten vereinbarte Methodik wurde als „leicht“ und schnell beschrieben. Der Hauptgewinn dieses Meetings war jedoch der Gedanke, dass eine schnellere Lieferung eines Produkts und ständiges Feedback der Schlüssel zum Erfolg bei der Softwareentwicklung sind.
Die vorhandenen Wasserfalltechniken waren zu umständlich und enthielten keine Rückmeldungen, bis das Endprodukt zur Auslieferung bereit war. Dies bedeutete, dass es keinen Spielraum für Kurskorrekturen gab und der Kunde den Fortschritt nicht sehen konnte, bis das gesamte Produkt fertig war. Und das wollten diese Experten vermeiden.
Sie wollten eine Lösung, die Raum für ständiges Feedback bietet, um die Kosten für Nacharbeiten zu einem späteren Zeitpunkt zu vermeiden.
Agile Herausforderungen
Die zu diesem Zeitpunkt vorhandenen Wasserfalltechniken waren zu umständlich und enthielten keine Rückmeldung, bis das Endprodukt zur Auslieferung bereit war. Es wurde als Wasserfall-Entwicklungsmodell bezeichnet, da die Teams zunächst einen Schritt vollständig abgeschlossen hatten und erst danach mit dem nächsten Schritt fortfuhren.
Dies bedeutete, dass es keinen Spielraum für Kurskorrekturen gab und der Kunde den Fortschritt nicht sehen konnte, bis das gesamte Produkt fertig war. Und das wollten diese Experten vermeiden. Sie wollten eine Lösung, die Raum für ständiges Feedback bietet, um die Kosten für Nacharbeiten zu einem späteren Zeitpunkt zu vermeiden.
Und deshalb geht es bei Agilität auch um adaptive und kontinuierliche Verbesserung, ebenso wie um konstantes Feedback und schnelle Lieferung.
Was sind agile Versprechen?
Bei Agile geht es nicht nur darum, die festgelegten Praktiken bei der Entwicklung von Software anzuwenden. Dies führt auch zu einer Änderung der Denkweise des Teams, die es dazu bringt, bessere Software zu entwickeln, zusammenzuarbeiten und schließlich einen zufriedenen Kunden zu gewinnen.
Agile Werte und Prinzipien ermöglichen es dem Team, seinen Fokus zu verlagern und seinen Denkprozess zur Entwicklung besserer Software zu ändern.
Was genau ist Agile?
Agilität ist kein Regelwerk. Agile ist keine Reihe von Richtlinien. Agilität ist nicht einmal eine Methode. Agile ist vielmehr eine Reihe von Prinzipien, die Flexibilität, Anpassungsfähigkeit, Kommunikation und Arbeitssoftware gegenüber Plänen und Prozessen fördern. Es wird sehr prägnant in dem so genannten agilen Manifest festgehalten.
Dank der agilen Softwareentwicklung kann das Team bei der Entwicklung komplexer Projekte effizienter und effektiver zusammenarbeiten. Es besteht aus Übungen, die iterative und inkrementelle Techniken anwenden, die leicht übernommen werden können und hervorragende Ergebnisse zeigen.
Um Agile in die Tat umzusetzen, haben wir verschiedene agile Methoden und Methoden. Diese Methoden und Methoden erfüllen alle Anforderungen einer Softwareentwicklungsbranche, von Software-Design und -Architektur über Entwicklung und Test bis hin zu Projektmanagement und Lieferungen.
Darüber hinaus eröffnen agile Methoden und Methoden als integraler Bestandteil jeder Lieferung Möglichkeiten zur Prozessverbesserung.
Agile ist ein Softwareentwicklungsansatz, bei dem ein autarkes und funktionsübergreifendes Team an kontinuierlichen Lieferungen durch Iterationen arbeitet und sich während des gesamten Prozesses weiterentwickelt, indem Feedback von den Endbenutzern eingeholt wird.
Wie übe ich Agilität?
Es gibt verschiedene agile Methoden, die in verschiedenen diversifizierten Branchen praktiziert werden.
Die beliebtesten Methoden unter allen sind jedoch:
- Gedränge
- Kanban
- Extremes Programmieren
Alle diese Methoden konzentrieren sich auf die Entwicklung schlanker Software und helfen dabei, bessere Software effektiv und effizient zu erstellen.
Das ist alles mit Agile Introduction. Der Teil ist so strukturiert, dass Sie die Grundwerte und Prinzipien verstehen, die für ein Team gelten sollen, um in einem agilen Modus und einer agilen Denkweise zu arbeiten.
Agil Methodik
Einführung in agile Modelle:
VR-Headset, das mit Xbox One funktioniert
Wie wir alle wissen, ist Agile eine Softwareentwicklungsmethode.
Wir haben auch etwas über die Werte und Prinzipien gelernt, die von den Gründern von Agile im Agile Manifest erwähnt wurden. In unseren ersten Gesprächen haben wir auch die Unterschiede zwischen agilen und traditionellen Wasserfallmodellen umgangen.
In diesem Tutorial lernen wir die Vor- und Nachteile der agilen Methodik kennen.
Wir werden sehen, was Scrum ist? und wie unterscheidet es sich von agil. Dann werden wir die verschiedenen agilen Methoden verstehen, die von verschiedenen Organisationen verwendet werden, und wie wir agile Methoden mit ihnen implementieren können.
Sie werden auch den Unterschied und die Vor- und Nachteile dieser Methoden erkennen können.
Vorteile der agilen Methodik
Nachfolgend sind die verschiedenen Vorteile der agilen Methodik aufgeführt:
- Die Kunden erhalten am Ende jeder Iteration / jedes Sprints kontinuierlich einen Überblick über den Projektfortschritt.
- Jeder Sprint bietet dem Kunden eine funktionierende Software, die seine Erwartungen gemäß der von ihm bereitgestellten Definition erfüllt.
- Die Entwicklungsteams reagieren sehr gut auf die sich ändernden Anforderungen und können Änderungen auch in fortgeschrittenen Entwicklungsstadien berücksichtigen.
- Es gibt eine ständige wechselseitige Kommunikation, die die Kunden einbezieht, sodass alle Beteiligten - geschäftliche und technische - klare Sicht auf den Projektfortschritt haben.
- Das Design des Produkts ist effizient und erfüllt die Geschäftsanforderungen.
Nachteile der agilen Methodik
Obwohl die agile Methodik mehrere Vorteile bietet, sind damit auch bestimmte Nachteile verbunden.
Sie sind:
# 1) Eine umfassende Dokumentation wird nicht bevorzugt, was dazu führen kann, dass agile Teams dies falsch interpretieren, da für agile keine Dokumentation erforderlich ist. So geht die Genauigkeit der Dokumentation verloren. Dies sollte vermieden werden, indem Sie sich ständig fragen, ob dies ausreichend ist, um fortzufahren oder nicht.
#zwei) Manchmal sind die Anforderungen zu Beginn der Projekte nicht klar. Die Teams könnten fortfahren und feststellen, dass die Vision der Kunden neu ausgerichtet wurde. In solchen Situationen müssen die Teams viele Änderungen vornehmen, und es ist schwierig, auch das Endergebnis zu beurteilen.
Arten agiler Methoden
In der Praxis gibt es weltweit mehrere agile Methoden. Wir werden mehr über vier der beliebtesten erfahren.
# 1) Scrum
Scrum kann leicht als das beliebteste agile Framework angesehen werden. Der Begriff 'Scrum' wird von den meisten Praktikern synonym mit 'agil' angesehen. Das ist aber ein Missverständnis. Scrum ist nur eines der Frameworks, mit denen Sie Agile implementieren können.
Das Wort Scrum stammt aus dem Sport-Rugby. Wo sich die Spieler in einer verriegelten Position zusammenkauern und gegen die Gegner drücken. Jeder Spieler hat eine definierte Rolle in seiner Position und kann je nach Bedarf sowohl offensiv als auch defensiv spielen.
In ähnlicher Weise glaubt das Scrum in der IT an befähigte selbstverwaltete Entwicklungsteams mit drei spezifischen und klar definierten Rollen. Diese Rollen umfassen - Product Owner (PO), Scrum Master (SM) und das Entwicklungsteam bestehend aus Programmierern und Testern . Sie arbeiten in iterativen Zeiträumen zusammen, die als Sprints bezeichnet werden.
Der erste Schritt ist die Erstellung des Product Backlogs durch die Bestellung. Es handelt sich um eine Aufgabenliste, die vom Scrum-Team ausgeführt werden muss. Anschließend wählt das Scrum-Team die Elemente mit der höchsten Priorität aus und versucht, sie innerhalb des als Sprint bezeichneten Zeitfelds zu beenden.
Eine einfachere Möglichkeit, sich an all dies zu erinnern, besteht darin, sich das 3-3-5-Framework zu merken. Dies bedeutet, dass ein Scrum-Projekt 3 Rollen, 3 Artefakte und 5 Ereignisse hat.
Diese sind - -
Rollen: PO, Scrum Master und Entwicklungsteam.
Artefakte: Product Backlog, Sprint BacklogundProduktinkrement.
Veranstaltungen: Sprint, Sprintplanung, Daily Scrum, Sprint Review und Sprint Retrospektive.
Wir werden in unseren nachfolgenden Tutorials mehr darüber erfahren.
# 2) Kanban
Kanban ist ein japanischer Begriff, der eine Karte bedeutet. Diese Karten enthalten Details zu den Arbeiten, die an der Software ausgeführt werden müssen. Der Zweck ist die Visualisierung. Jedes Teammitglied ist sich der Arbeit bewusst, die mit diesen visuellen Hilfsmitteln geleistet werden muss.
Teams verwenden diese Kanban-Karten für die kontinuierliche Lieferung. Genau wie Scrum unterstützt Kanban die Teams bei der effektiven Arbeit und fördert selbstverwaltete und kollaborative Teams.
Aber es gibt auch Unterschiede zwischen diesen beiden - wie während eines Scrum-Sprints sind die Elemente, an denen ein Team arbeitet, behoben und wir können dem Sprint keine Elemente hinzufügen, während wir in Kanban Elemente hinzufügen können, wenn Kapazität verfügbar ist. Dies ist besonders nützlich, wenn sich die Anforderungen häufig ändern.
In ähnlicher Weise besteht ein weiterer Unterschied darin, dass das Scrum zwar die Rollen eines PO-, Scrum-Master- und Entwicklungsteams definiert hat, in Kanban jedoch keine solchen vordefinierten Rollen vorhanden sind.
Ein weiterer Unterschied besteht darin, dass Kanban zwar eine Priorisierung der Produktrückstände vorschlägt, Kanban jedoch keine solchen Anforderungen hat und dies völlig optional ist. Daher erfordert Kanban weniger Organisation und vermeidet nicht wertschöpfende Aktivitäten und ist für Prozesse geeignet, die eine Reaktion auf Änderungen erfordern.
# 3) Lean
Lean ist eine Philosophie, die sich auf die Abfallreduzierung konzentriert. Wie macht es das?
In Lean unterteilen Sie einen Prozess in wertschöpfende Aktivitäten, nicht wertschöpfende Aktivitäten und wesentliche nicht wertschöpfende Aktivitäten. Jede Aktivität, die als nicht wertschöpfende Aktivität eingestuft werden kann, ist eine Verschwendung, und wir sollten versuchen, diese Verschwendung im Prozess zu beseitigen, um sie schlanker zu machen.
Ein schlankerer Prozess bedeutet eine schnellere Lieferung und weniger Aufwand für Aufgaben, die nicht zur Erreichung der Teamziele beitragen. Dies hilft, jeden Schritt im Softwareentwicklungszyklus zu optimieren. Aus diesem Grund wurden die Lean-Prinzipien von Lean Manufacturing in die Softwareentwicklung übernommen.
Lean-Software-Entwicklung kann in jedem IT-Projekt verwendet werden, indem die folgenden sieben Lean-Prinzipien angewendet werden:
Diese sind ziemlich selbsterklärend, wie ihre Namen vermuten lassen. Die Beseitigung von Verschwendung ist das erste und wichtigste Lean-Prinzip, und wir haben gesehen, wie das geht. Wir klassifizieren Aktivitäten lediglich als wertschöpfend und nicht wertschöpfend.
Eine nicht wertschöpfende Aktivität kann ein beliebiger Teil des Codes sein, der ihn möglicherweise weniger robust macht, den Aufwand erhöht und viel Zeit in Anspruch nimmt, ohne einen vertretbaren Geschäftswert hinzuzufügen. Es kann sich auch um vage User Stories oder schlechte Tests oder das Hinzufügen von Funktionen handeln, die im Gesamtbild nicht erforderlich sind.
Das zweite Prinzip, das das Lernen verstärkt, ist wieder leicht zu verstehen, da ein Team verschiedene Fähigkeiten benötigt, um Produkte in einer sich schnell ändernden Umgebung zu liefern, wobei neue Technologien in kurzer Zeit auftauchen.
Verspätete Entscheidungen zu treffen kann sich lohnen, wenn die Nacharbeit reduziert wird, z. B. wenn Änderungen erwartet werden, und diese dann besser verzögern, damit das Team die Arbeit nicht wiederholen muss, wenn sich die geschäftlichen Anforderungen ändern.
Aber hier gibt es immer einen Kompromiss, da die Teams dies mit dem vierten Prinzip der schnelleren Lieferung in Einklang bringen müssen. Verzögerungen bei Entscheidungen sollten sich nicht auf die Gesamtleistung auswirken und dürfen das Arbeitstempo nicht verringern. Ein Auge sollte immer auf das Gesamtbild gerichtet sein.
Befähigte Teams sind heutzutage ebenfalls weit verbreitet, und dies ist etwas, was sogar agil nahe legt. Befähigte Teams sind verantwortungsbewusster und können Entscheidungen schneller treffen. Das Gefühl der Eigenverantwortung in einem befähigten Team führt zu besseren Ergebnissen. Um ein Team zu stärken, sollte es ihnen gestattet sein, sich selbst zu organisieren und selbst Entscheidungen zu treffen.
Wir sehen also, dass Lean und Agile viel mit einem großen Unterschied gemeinsam haben - während Lean-Teams helfen können, ein Produkt zu verfeinern, sind Agile-Teams diejenigen, die das Produkt tatsächlich entwickeln.
# 4) Extreme Programmierung (XP)
Extreme Programmierung ist eine weitere beliebte agile Technik. Laut extremeprogramming.org wurde das erste XP-Projekt am 6. März 1996 gestartet. Sie erwähnen auch, dass XP die Entwicklung von Softwareprojekten auf fünf verschiedene Arten beeinflusst - Kommunikation, Einfachheit, Feedback, Respekt und Mut. Diese werden als XP-Werte bezeichnet.
Von diesen beginnt alles mit der Kommunikation. XP-Teams arbeiten regelmäßig mit Geschäftsteams und anderen Programmierern zusammen und beginnen vom ersten Tag an mit der Erstellung von Code. Der Fokus liegt hier auf der Kommunikation von Angesicht zu Angesicht so weit wie möglich mit Hilfe der anderen visuellen Hilfsmittel.
Extreme Programmierer erstellen auch einen einfachen Code und erhalten vom ersten Tag an Feedback dazu. Der Fokus liegt darauf, nicht über Bord zu gehen oder Anforderungen vorherzusagen, die nicht geteilt wurden. Dies hält das Design einfach und produziert nur das Mindestprodukt, das den Anforderungen entspricht.
Feedback hilft dem Team, die Arbeitsqualität zu verbessern und zu verbessern. Dies hilft ihnen, Respekt füreinander aufzubauen, wenn sie voneinander lernen und lernen, ihre Ansichten zu teilen.
Dies gibt ihnen auch den Mut, da sie wissen, dass sie die besten Ideen aller gesammelt und ein gutes Produkt mit dem Feedback anderer produziert haben. Daher haben sie auch keine Angst davor, Änderungen aufzunehmen oder weiteres Feedback zu ihrer Arbeit zu erhalten.
Dies ist besonders nützlich in Projekten, in denen sich die Anforderungen häufig ändern werden. Ständiges Feedback hilft den Teams, diese Änderungen mutig zu berücksichtigen.
So haben wir die verschiedenen agilen Methoden wie Scrum, XP, Kanban und Lean mit ihren jeweiligen Vor- und Nachteilen gesehen.
Jetzt können wir leicht zwischen ihnen unterscheiden und auch die subtileren Unterschiede zwischen ihnen erkennen. Wir haben auch die Grundlagen jeder dieser Methoden gelernt und gesehen, wie wir sie bei Bedarf in unseren Projekten anwenden können.
Lassen Sie uns im nächsten Teil alles über Scrum verstehen.
Scrum-Methodik
SCRUM ist ein Prozess in agiler Methodik, der eine Kombination aus dem iterativen Modell und dem inkrementellen Modell darstellt.
Eines der größten Nachteile des Traditionellen Wasserfall-Modell war das - bis die erste Phase abgeschlossen ist, wechselt die Anwendung nicht in die andere Phase. Und wenn es in der späteren Phase des Zyklus einige Änderungen gibt, wird es zufällig sehr schwierig, diese Änderungen zu implementieren, da die früheren Phasen erneut überprüft und die Änderungen wiederholt werden müssen.
Einige der Hauptmerkmale von SCRUM sind:
- Selbstorganisiertes und fokussiertes Team.
- Keine großen Anforderungsdokumente, sondern sehr präzise und auf den Punkt gebrachte Geschichten.
- Die funktionsübergreifenden Teams arbeiten als eine Einheit zusammen.
- Enge Kommunikation mit dem Benutzervertreter, um die Funktionen zu verstehen.
- Hat eine bestimmte Zeitspanne von maximal einem Monat.
- Anstatt das ganze „Ding“ gleichzeitig zu machen, macht Scrum in einem bestimmten Intervall ein bisschen von allem.
- Ressourcenfähigkeit und -verfügbarkeit werden berücksichtigt, bevor etwas festgelegt wird.
Um diese Methodik gut zu verstehen, ist es wichtig, die wichtigsten Terminologien in SCRUM zu verstehen.
Lesen Sie auch => Bereitstellung hochwertiger Softwarefunktionen in kurzer Zeit mithilfe des Agile Scrum-Prozesses
Wichtige SCRUM-Terminologien
1) Scrum Team
Das Scrum-Team besteht aus 7 Teams mit + oder - zwei Mitgliedern. Diese Mitglieder sind eine Mischung aus Kompetenzen und setzen sich aus Entwicklern, Testern, Datenbankmitarbeitern, Supportmitarbeitern usw. sowie dem Product Owner und einem Scrum Master zusammen.
Alle diese Mitglieder arbeiten in enger Zusammenarbeit für ein rekursives und bestimmtes Intervall zusammen, um die genannten Funktionen zu entwickeln und zu implementieren. Die Sitzordnung des SCRUM-Teams spielt eine sehr wichtige Rolle in ihrer Interaktion. Sie sitzen nie in Kabinen oder Kabinen, sondern an einem riesigen Tisch.
2) Sprint
Sprint ist ein vordefiniertes Intervall oder ein vordefinierter Zeitrahmen, in dem die Arbeit abgeschlossen und für die Überprüfung oder die Bereitstellung in der Produktion vorbereitet werden muss. Diese Zeitbox liegt normalerweise zwischen 2 Wochen und 1 Monat.
Was ist Beta-Test und wie wird es verwendet?
Wenn wir in unserem täglichen Leben sagen, dass wir den 1-monatigen Sprint-Zyklus befolgen, bedeutet dies einfach, dass wir einen Monat lang an den Aufgaben arbeiten und sie bis Ende dieses Monats für die Überprüfung bereit machen.
3) Product Owner
Der Product Owner ist der Hauptbeteiligte oder der Hauptbenutzer der zu entwickelnden Anwendung. Der Product Owner ist die Person, die die Kundenseite vertritt. Er / sie hat die letzte Autorität und sollte immer für das Team verfügbar sein.
Er / sie sollte erreichbar sein, wenn jemand Zweifel hat, die geklärt werden müssen. Für den Product Owner ist es wichtig zu verstehen und keine neuen Anforderungen in der Mitte des Sprints oder wenn der Sprint bereits gestartet ist, zuzuweisen.
4) Scrum Master
Scrum Master ist der Moderator des Scrum-Teams. Er / sie stellt sicher, dass das Scrum-Team produktiv und fortschrittlich ist. Im Falle von Hindernissen verfolgt der Scrum Master diese und löst sie für das Team. SCRUM Master ist der Vermittler zwischen der PO und dem Team.
Er / sie hält die PO über den Fortschritt des Sprints auf dem Laufenden. Wenn es irgendwelche Hindernisse oder Bedenken für das Team gibt, bespricht dies mit der PO und lässt sie lösen. Wie beim Daily Standup des Teams findet jeden Tag ein Standup des SCRUM-Masters mit der PO statt.
Empfohlene Lektüre => Wie kann man in einer agilen Testwelt ein guter Team-Mentor, Coach und echter Team-Verteidiger sein?
5) Business Analyst (BA)
Ein Business Analyst spielt in SCRUM eine sehr wichtige Rolle. Diese Person ist dafür verantwortlich, dass die Anforderung in den Anforderungsdokumenten (auf deren Grundlage die User Stories erstellt werden) finalisiert und entworfen wird.
Wenn es Unklarheiten in den User Stories / Akzeptanzkriterien gibt, ist er derjenige, der vom technischen Team (SCRUM) angesprochen wird, und er nimmt sie dann zur Bestellung auf oder löst sie nach Möglichkeit selbst auf. Bei Großprojekten kann es mehr als 1 BA geben, bei Kleinprojekten kann der SCRUM-Master auch als BA fungieren.
Es ist immer eine gute Praxis, einen BA zu haben, wenn der Projektkick beginnt.
6) User Story
User Stories sind nichts anderes als die Anforderungen oder Funktionen, die implementiert werden müssen.
Im Scrum haben wir nicht diese riesigen Anforderungsdokumente, sondern die Anforderungen werden in einem einzigen Absatz definiert, der normalerweise das folgende Format hat:
Als ein
Ich möchte
Erreichen
Zum Beispiel ::
Als Administrator möchte ich eine Passwortsperre haben, falls der Benutzer dreimal hintereinander ein falsches Passwort eingibt, um den nicht autorisierten Zugriff einzuschränken.
Es gibt einige Merkmale von User Stories, die eingehalten werden sollten. Die User Stories sollten kurz, realistisch, schätzbar, vollständig, verhandelbar und überprüfbar sein. Eine User Story wird während des Sprints niemals geändert.
Es liegt in der Verantwortung des SCRUM-Masters und des BA (falls zutreffend), sicherzustellen, dass die Bestellung die User Stories mit einem korrekten Satz der Akzeptanzkriterien korrekt verfasst hat. “ Wenn Änderungen vorgenommen werden sollen, die sich auf die Sprintfreigabe auswirken, werden solche Storys aus dem Sprint herausgezogen oder gemäß den verfügbaren Stunden durchgeführt.
Jede User Story hat ein Akzeptanzkriterium, das vom Team genau definiert und verstanden werden sollte.
Annahmekriterien beschreiben die User Story, die die unterstützenden Dokumente bereitstellt. Es hilft, die User Story weiter zu verfeinern. Jeder aus dem Team kann die Akzeptanzkriterien aufschreiben. Das Testteam stützt seine Testfälle / -bedingungen auf diese Akzeptanzkriterien.
7) Epen
Epen sind zweideutige User Stories oder wir können sagen, dass dies die User Stories sind, die nicht definiert sind und für zukünftige Sprints aufbewahrt werden.
Versuchen Sie einfach, es mit dem Leben in Verbindung zu bringen. Stellen Sie sich vor, Sie machen Urlaub. Wenn Sie nächste Woche losfahren, haben Sie alles im Griff, wie Hotelbuchungen, Besichtigungen, Reiseschecks usw. Aber was ist mit Ihrem Urlaubsplan für das nächste Jahr? Sie haben nur eine vage Vorstellung davon, dass Sie zum XYZ-Ort gehen könnten, aber Sie haben keinen detaillierten Plan.
Ein Epos ist genau wie Ihr Urlaubsplan für das nächste Jahr, in dem Sie nur wissen, dass Sie vielleicht gehen möchten, aber wo, wann, mit wem, all diese Details Sie zu diesem Zeitpunkt keine Ahnung haben.
In ähnlicher Weise gibt es Funktionen, die in Zukunft implementiert werden müssen und deren Details noch nicht bekannt sind. Meistens beginnt ein Feature mit einem Epos und wird dann in Geschichten zerlegt, die implementiert werden könnten.
8) Product Backlog
Das Product Backlog ist eine Art Bucket oder Quelle, in der alle User Stories aufbewahrt werden. Dies wird vom Product Owner gepflegt. Das Product Backlog kann als Wunschliste des Product Owners betrachtet werden, der es gemäß den Geschäftsanforderungen priorisiert.
Während des Planungsmeetings (siehe nächster Abschnitt) wird eine User Story aus dem Product Backlog entnommen, dann führt das Team das Brainstorming durch, versteht es und verfeinert es und entscheidet gemeinsam mit dem Product Owner, welche User Storys erstellt werden sollen.
9) Sprint Backlog
Basierend auf der Priorität werden User Stories einzeln aus dem Product Backlog entnommen. Das Brainstorming des Scrum-Teams bestimmt die Machbarkeit und entscheidet über die Geschichten, die an einem bestimmten Sprint arbeiten sollen. Die Sammelliste aller User Stories, die das Scrum-Team an einem bestimmten Sprint bearbeitet, wird als Sprint-Backlog bezeichnet.
10) Story Points
Story Points sind ein quantitativer Hinweis auf die Komplexität einer User Story. Basierend auf dem Story-Punkt werden die Schätzung und der Aufwand für eine Story bestimmt.
Ein Story Point ist relativ und nicht absolut. Um sicherzustellen, dass unsere Schätzungen und Bemühungen korrekt sind, ist es wichtig zu überprüfen, ob die User Stories nicht groß sind. Je präziser und kleiner die User Story ist, desto genauer ist die Schätzung.
Jede User Story ist einem Story Point zugeordnet, der auf der Fibonacci-Serie basiert (1, 2, 3, 5, 8, 13 & 21). Höher ist die Zahl, der Komplex ist die Geschichte.
Um genau zu sein
- Wenn Sie 1/2/3 Story Point angeben, bedeutet dies, dass die Story klein und von geringer Komplexität ist.
- Wenn Sie Punkte als 5/8 geben, ist es ein mittlerer Komplex und
- 13 und 21 sind sehr komplex.
Hier besteht Komplexität sowohl aus Entwicklungs- als auch aus Testaufwand.
Um einen Story-Punkt zu bestimmen, findet innerhalb des Scrum-Teams ein Brainstorming statt, und das Team entscheidet gemeinsam über einen Story-Punkt.
Es kann vorkommen, dass das Entwicklungsteam einer bestimmten Story einen Story-Punkt von 3 gibt, da es sich bei ihnen möglicherweise um 3 Zeilen Codeänderung handelt. Das Testteam gibt jedoch 8 Story-Punkte an, da sie der Ansicht sind, dass diese Codeänderung größere Module betrifft Der Testaufwand wäre größer. Welchen Story-Punkt Sie auch geben, Sie müssen ihn rechtfertigen.
In dieser Situation findet also ein Brainstorming statt und das Team stimmt gemeinsam einem Story-Punkt zu.
Wenn Sie sich für einen Story-Punkt entscheiden, sollten Sie die folgenden Faktoren berücksichtigen:
- Die Abhängigkeit der Geschichte von anderen Anwendungen / Modulen.
- Die Fähigkeiten der Ressource.
- Die Komplexität der Geschichte.
- Historisches Lernen.
- Akzeptanzkriterien der User Story.
Wenn Ihnen eine bestimmte Geschichte nicht bekannt ist, passen Sie sie nicht an.
Immer wenn eine Geschichte = oder> 8 Punkte ist, wird sie in 2 oder mehr Geschichten unterteilt.
11) Diagramm abbrennen
Das Burndown-Diagramm ist ein Diagramm, das den geschätzten tatsächlichen Aufwand der Scrum-Aufgaben v / s zeigt.
Es handelt sich um einen Verfolgungsmechanismus, mit dem für einen bestimmten Sprint die täglichen Aufgaben verfolgt werden, um zu überprüfen, ob die Storys in Richtung der Fertigstellung der festgeschriebenen Story-Punkte voranschreiten oder nicht.
Beispiel : Um dies zu verstehen, überprüfen Sie die folgende Abbildung:
Ich habe angenommen:
- 2 Wochen Sprint (10 Tage)
- 2 Ressourcen arbeiten tatsächlich am Sprint.
'Geschichte' -> Diese Spalte zeigt die User Stories, die für den Sprint erstellt wurden.
'Aufgabe' -> Diese Spalte zeigt die Liste der Aufgabe, die der User Story zugeordnet ist.
'Anstrengung' -> Diese Spalte zeigt den Aufwand. Diese Maßnahme ist nun der Gesamtaufwand für die Erledigung der Aufgabe. Es zeigt nicht den Aufwand, den eine bestimmte Person unternimmt.
'Tag 1 - Tag 10' -> Diese Spalte (n) zeigt die verbleibenden Stunden, um die Geschichte zu vervollständigen. Bitte beachten Sie, dass die Stunde NICHT die Stunde ist, die bereits erledigt ist, ABER die Stunden, die noch übrig sind.
'Geschätzter Aufwand' -> Ist die Summe des Aufwands. Für den „Start“ ist es einfach die Summe der gesamten Einzelaufgabe: SUMME (C5: C15)
Die Gesamtzahl der Anstrengungen, die an einem Tag erledigt werden müssen, beträgt 70/10 = 7. Am Ende von Tag 1 sollte sich der Aufwand auf 70 - 7 = 63 reduzieren. In ähnlicher Weise wird er für alle berechnet Tage bis Tag 10, an dem der geschätzte Aufwand 0 sein sollte (Zeile 16)
'Tatsächliche Anstrengung übrig' -> Wie der Name schon sagt, bleibt tatsächlich die Mühe, die Geschichte zu vervollständigen. Es kann auch vorkommen, dass der tatsächliche Aufwand zunimmt oder abnimmt als der geschätzte.
Sie können die integrierten Funktionen und das Diagramm in Excel verwenden, um dieses Burndown-Diagramm zu erstellen.
Burn Down Chart Schritte wären:
- Geben Sie alle Geschichten ein (Spalte A5 - A15).
- Geben Sie alle Aufgaben ein (Spalte B5 - B15).
- Geben Sie die Tage ein (Tag 1 - Tag 10).
- Geben Sie die Startbemühungen ein (Summieren Sie die Aufgaben C5 - C15).
- Wenden Sie die Formel an, um die „geschätzten Anstrengungen“ für jeden Tag (Tag 1 bis Tag 10) zu berechnen. Geben Sie die Formel bei D15 (C16- $ C $ 16/10) ein und ziehen Sie sie für alle Tage.
- Geben Sie für jeden Tag die tatsächlichen Anstrengungen ein. Geben Sie bei D17 (SUMME (D5: D15)) die Formel ein, um die tatsächlich verbleibenden Anstrengungen zusammenzufassen, und ziehen Sie sie für alle anderen Tage.
- Wählen Sie es aus und erstellen Sie das Diagramm wie folgt:
12) Geschwindigkeit
Die Gesamtzahl der Story Points, die ein Scrum-Team in einem Sprint archiviert, wird als Velocity bezeichnet. Das Scrum-Team wird anhand seiner Geschwindigkeit beurteilt oder referenziert. Allerdings sollte bedacht werden, dass das Ziel hier NICHT darin besteht, die maximalen Story-Punkte zu erreichen, sondern eine Qualität zu erzielen, die dem Komfortniveau des Scrum-Teams entspricht.
Zum Beispiel : Für einen bestimmten Sprint: Die Gesamtzahl der User Stories beträgt 8 mit den unten gezeigten Story Points.
Hier ist die Geschwindigkeit also die Summe der Story-Punkte = 30
Definition von Fertig:
Ein Sprint wird als Fertig markiert, wenn alle Storys abgeschlossen sind, alle Entwickler-, Forschungs- und QS-Aufgaben als 'Abgeschlossen' markiert sind, alle Fehler behoben sind, ansonsten diejenigen, die später ausgeführt werden können (wie nicht vollständig verwandt oder weniger wichtig). werden herausgezogen und in den Rückstand aufgenommen, die Codeüberprüfung und der Komponententest sind abgeschlossen, die geschätzten Stunden haben die tatsächlichen Stunden der Aufgaben erreicht und vor allem wurde der PO und den Stakeholdern eine erfolgreiche Demo gegeben.
Aktivitäten in der SCRUM-Methodik
# 1) Planungsbesprechung
Ein Planungstreffen ist der Ausgangspunkt von Sprint. Es ist das Meeting, bei dem sich das gesamte Scrum-Team versammelt. Der SCRUM-Master wählt eine User Story basierend auf der Priorität aus dem Produkt-Backlog und den darauf basierenden Brainstormings des Teams aus.
Basierend auf der Diskussion entscheidet das Scrum-Team über die Komplexität der Geschichte und bewertet sie gemäß der Fibonacci-Serie. Das Team identifiziert die Aufgaben zusammen mit den Anstrengungen (in Stunden), die unternommen werden würden, um die Implementierung der User Story abzuschließen.
Oft geht dem Planungsmeeting ein „Pre-Planning-Meeting“ voraus. Es ist wie bei den Hausaufgaben, die das Scrum-Team macht, bevor es zum formellen Planungstreffen sitzt. Das Team versucht, die Abhängigkeiten oder andere Faktoren aufzuschreiben, die es in der Planungsbesprechung diskutieren möchte.
# 2) Ausführung von Sprint-Aufgaben
Wie der Name schon sagt, handelt es sich hierbei um die tatsächliche Arbeit des Scrum-Teams, um seine Aufgabe zu erfüllen und die User Story in den Status 'Fertig' zu versetzen.
# 3) Tägliches Aufstehen
Während des Sprintzyklus trifft sich das Scrum-Team jeden Tag nicht länger als 15 Minuten (dies könnte ein Stand-up-Anruf sein, der zu Beginn des Tages empfohlen wird) und gibt 3 Punkte an:
- Was hat das Teammitglied gestern gemacht?
- Was hatte das Teammitglied heute vor?
- Irgendwelche Hindernisse (Straßensperren)?
Es ist der Scrum-Meister, der dieses Treffen leitet. Falls ein Teammitglied auf irgendwelche Schwierigkeiten stößt, folgt der Scrum Master, um die Lösung zu finden. In Stand-Ups wird das Board ebenfalls überprüft und zeigt an sich den Fortschritt des Teams.
# 4) Besprechung überprüfen
Am Ende jedes Sprintzyklus trifft sich das SCRUM-Team erneut und demonstriert dem Produktbesitzer die implementierten User Stories. Der Product Owner kann die Storys gemäß seinen Akzeptanzkriterien überprüfen. Es liegt erneut in der Verantwortung des Scrum-Masters, dieses Treffen zu leiten.
Auch im SCRUM-Tool wird der Sprint geschlossen und die Aufgaben als erledigt markiert.
# 5) Rückblickendes Treffen
Das retrospektive Meeting findet nach dem Review-Meeting statt.
Das SCRUM-Team trifft, diskutiert und dokumentiert die folgenden Punkte:
- Was ist während des Sprints gut gelaufen (Best Practices)?
- Was ist im Sprint nicht gut gelaufen?
- Gewonnene Erkenntnisse
- Aktionselemente.
Das Scrum-Team sollte weiterhin die Best Practices befolgen, die „nicht Best Practices“ ignorieren und die Lehren aus den nachfolgenden Sprints umsetzen. Das retrospektive Treffen hilft, die kontinuierliche Verbesserung des SCRUM-Prozesses umzusetzen.
Wie läuft der Prozess ab? Ein Beispiel!
Nachdem ich über die technischen Jargons von SCRUM gelesen habe. Lassen Sie mich versuchen, den gesamten Prozess anhand eines Beispiels zu demonstrieren.
Beispiel:
Schritt 1 : Wir haben ein SCRUM-Team von 9 Personen, bestehend aus 1 Produktbesitzer, 1 Scrum-Master, 2 Testern, 4 Entwicklern und 1 DBA.
Schritt 2 : Der Sprint folgt einem 4-wöchigen Zyklus. Wir haben also einen einmonatigen Sprint vom 5. bis 4. Junithdes Julis.
Schritt 3 : Der Product Owner verfügt über die priorisierte Liste der User Stories im Product Backlog.
Schritt 4: Das Team beschließt, sich am 4. zu treffenthJuni für das Treffen „Vorplanung“.
- Der Product Owner nimmt 1 Story aus dem Product Backlog, beschreibt sie und überlässt sie dem Team, um ein Brainstorming durchzuführen.
- Das gesamte Team diskutiert und kommuniziert direkt mit dem Product Owner, um die User Story klar zu verstehen.
- In ähnlicher Weise werden verschiedene andere User Stories aufgenommen. Wenn möglich, kann das Team auch die Geschichten einschätzen.
Nach all den Diskussionen kehren einzelne Teammitglieder zu ihren Arbeitsplätzen zurück und
- Identifizieren Sie ihre individuellen Aufgaben für jede Geschichte.
- Berechnen Sie die genaue Anzahl der Stunden, an denen sie arbeiten werden. Lassen Sie uns überprüfen, wie das Mitglied diese Stunden abschließt.
Gesamtzahl der Arbeitsstunden = 9
Minus 1 Stunde für eine Pause, minus 1 Stunde für Besprechungen, minus 1 Stunde für E-Mails, Diskussionen, Fehlerbehebung usw.
Die tatsächliche Arbeitszeit beträgt also 6.
Gesamtzahl der Arbeitstage während des Sprints = 21 Tage.
Gesamtzahl der verfügbaren Stunden = 21 * 6 = 126.
Das Mitglied hat 2 Tage Urlaub = 12 Stunden (Dies ist für jedes Mitglied unterschiedlich, einige nehmen möglicherweise Urlaub und andere nicht.)
Anzahl der tatsächlichen Stunden = 126 - 12 = 114 Stunden.
Dies bedeutet, dass das Mitglied für diesen Sprint tatsächlich 114 Stunden verfügbar ist. So wird er seine individuelle Sprintaufgabe so aufteilen, dass insgesamt 114 Stunden erreicht sind.
Schritt 5 : Am 5thIm Juni trifft sich das gesamte Scrum-Team zum „Planungstreffen“.
- Das endgültige Urteil der User Story aus dem Product Backlog wird getroffen und die Story in das Sprint Backlog verschoben.
- Für jede Geschichte erklärt jedes Teammitglied seine identifizierten Aufgaben. Bei Bedarf können sie eine Diskussion über diese Aufgaben führen, ihre Größe ändern oder ihre Größe ändern (denken Sie an die Fibonacci-Serie !!).
- Der Scrum-Master oder das Team geben ihre individuellen Aufgaben zusammen mit den Stunden für jede Story in einem Tool ein.
- Nachdem alle Geschichten fertig sind, notiert der Scrum-Master die anfängliche Geschwindigkeit und startet den Sprint offiziell.
Schritt 6 : Sobald der Sprint gestartet wurde, beginnt jedes Teammitglied basierend auf den zugewiesenen Aufgaben mit der Arbeit an diesen Aufgaben.
Schritt 7 : Das Team trifft sich täglich für 15 Minuten und bespricht 3 Dinge:
- Was haben sie gestern gemacht?
- Was planen sie heute zu tun?
- Irgendwelche Hindernisse (Straßensperren)?
Schritt 8 : Der Scrum Master verfolgt den Fortschritt täglich mit Hilfe von „Burn Down Chart“.
Schritt 9 : Im Falle von Hindernissen folgt der Scrum-Master, um diese zu beheben.
Schritt # 10 : Am 4thIm Juli trifft sich das Team erneut zum Review-Meeting. Ein Mitglied demonstriert dem Product Owner die implementierte User Story.
Schritt 11 : Am 5thIm Juli trifft sich das Team erneut zur Retrospektive, wo sie diskutieren
- Was ging gut?
- Was ist nicht gut gelaufen?
- Aktionselemente.
Schritt # 12 : Am 6thIm Juli trifft sich das Team erneut zum Vorplanungstreffen für den nächsten Sprint und der Zyklus geht weiter.
SCRUM-Aktivitätstools
Es gibt verschiedene Tools, die in großem Umfang zum Verfolgen von Scrum-Aktivitäten verwendet werden können.
Einige von ihnen umfassen:
Im kommenden Tutorial werden wir das Agile Manifest beleuchten, ein Begriff, der effektive Agile Teams antreibt.
Über die Autoren: Diese Serie wurde von folgenden STH-Teammitgliedern verfasst: Shruti Shrivastava - Ein professioneller Scrum-Master mit 9 Jahren Erfahrung in BFSI-, E-Commerce- und B2B-Domänen. Shruti ist Experte für Automatisierungstests und führt Scrum-Teams.Anshul Kumar Srivastava - Ein ergebnisorientierter Produktmanagement-Experte und agiler Praktiker mit 7 Jahren Erfahrung in den Bereichen BFSI und Telekommunikation.
Literatur-Empfehlungen
- Agile Scrum Online Quiz: Testen Sie Ihr Wissen über Agile Scrum
- Kanban vs Scrum vs Agile: Ein detaillierter Vergleich, um Unterschiede zu finden
- So liefern Sie mithilfe des Agile Scrum-Prozesses in kurzer Zeit hochwertige Softwarefunktionen
- Agiles Manifest: Agile Werte und Prinzipien verstehen
- SAFe Agile Tutorial: Was ist Scaled Agile Framework?
- 30+ Top Scrum Interview Fragen und Antworten (2021 LIST)
- Agile Vs Waterfall: Welches ist die beste Methode für Ihr Projekt?
- Top 31 Agile Interview Fragen und Antworten