Agile Vs Waterfall: Welches ist die beste Methode für Ihr Projekt?

agile vs waterfall which is best methodology

beste Arbeitszeittabellen-App für mehrere Mitarbeiter

Erfahren Sie alles über agile und Wasserfallmethoden, verschiedene Arten von SDLC-Modellen und die Unterschiede zwischen Wasserfall- und agilen Entwicklungsmodellen sowie Tests:

Lesen Sie diesen informativen Artikel, um anhand der Vor- und Nachteile der einzelnen Modelle zu entscheiden, welches Modell für Ihr Projekt am besten geeignet ist.

Das Wasserfallmodell und das agile Modell sind die Arten des Software Development Life Cycle (SDLC). Dies ist der Prozess, mit dem die Softwareindustrie die Software entwirft, entwickelt und testet.

Durch Befolgen des SDLC können wir Kundenerwartungen erfüllen, das Projekt innerhalb eines bestimmten Zeitrahmens abschließen und die Kosten schätzen.

Was du lernen wirst:

• Wasserfall und agile Modell-Workflows
  • Was ist der Lebenszyklus der Softwareentwicklung?
  • Arten des Softwareentwicklungs-Lebenszyklus
    • # 1) Wasserfallmodell
    • # 2) Agiles Modell
    • # 3) Spiralmodell
    • # 4) Prototypmodell
    • # 5) V- und V-Modell
• Wasserfall-Modell
• Agiler Workflow
  • In Agile verwendete Schlüsselterminologien
  • Schlüsselfaktoren für die Einführung einer agilen Methodik
  • Arten agiler Methoden
• Unterschied zwischen agilen und Wasserfallmodellen
• Unterschiede zwischen Agile Testing und Waterfall Testing
• Fazit
  • Literatur-Empfehlungen

Wasserfall und agile Modell-Workflows

Im einfachen Englisch bedeutet Agil „in der Lage, sich schnell und einfach zu bewegen“, und daher ist es das, was es bedeutet, wenn es um die Agile Entwicklungsmethode .

Agile ist eine Methode des Projektmanagements, die durch Aufteilung der Aufgaben in kürzere Arbeitssegmente mit häufigen Überprüfungen und Anpassungen von Plänen dargestellt wird.

In ähnlicher Weise bezeichnet das Wort Wasserfall einen vertikalen Wasserfluss oder den Wasserfluss durch eine Reihe steiler Tropfen. Das Wasserfallmodell ist ein lineares sequentielles Modell, bei dem der Fortschritt in den Phasen der Erfassung, Analyse, Konstruktion, Entwicklung, Prüfung, Bereitstellung und Wartung von Anforderungen hauptsächlich in eine Richtung nach unten fließt.

Die gleiche Darstellung gilt für das Konzept des Projektmanagements, wenn es um die Wasserfall-Modell . Es ist eine Methode des Projektmanagements, die durch serielle Phasen und einen festen Arbeitsplan dargestellt wird.

(Bild Quelle ))

Bevor wir uns mit dem Waterfall-Workflow und dem Agile-Workflow befassen, werfen wir einen Blick auf die Definition des Software Development Life Cycle und ihre Anforderungen.

Was ist der Lebenszyklus der Softwareentwicklung?

Es ist ein schrittweises Verfahren, die Software systematisch zu entwickeln. Dazu wählen wir aus verschiedenen Arten von Softwareentwicklungs-Lebenszyklen in verschiedenen Unternehmen aus. Basierend auf der Anforderung wird ein geeigneter Lebenszyklus ausgewählt.

Das Wasserfallmodell ist einer der SDLC-Typen und ein alter Prozess zur Entwicklung von Software. Das agile Modell ist das neueste und fortschrittlichste. Agile wird aus anderen Lebenszyklen der Softwareentwicklung abgeleitet.

Andere SDLC umfassen das Spiralmodell, das V- und das V-Modell, das Prototypmodell. Basierend auf der Notwendigkeit und Kompatibilität der Geschäftsanforderungen werden wir das beste Modell für die Entwicklung der Softwareanwendung auswählen.

(Bild Quelle ))

Warum ist ein Lebenszyklus für die Softwareentwicklung erforderlich?

SDLC ist erforderlich, um das Projekt strukturiert zu verwalten. Es bietet ein gewisses Maß an Kontrolle und definiert die Rollen und Verantwortlichkeiten der Teammitglieder. Es gibt den Umfang und die Frist für jede Phase in SDLC an.

Es ist eine Art Benutzerhandbuch für die Teammitglieder, alle Schritte zur Entwicklung und Lieferung des Qualitätsprodukts zu befolgen. Es hilft dem Teammanagement, die Ziele und Anforderungen zu definieren und zu bewerten. Es hilft auch bei der Planung und Schätzung der Aufgaben. Es stellt die Kommunikationslinie zwischen dem Kunden und dem Entwicklungsteam her und erstellt die Rollen und Verantwortlichkeiten für jeden von ihnen.

Arten des Softwareentwicklungs-Lebenszyklus

Lassen Sie uns eine kurze Einführung in die im Softwareentwicklungsprozess verwendeten SDLC-Typen geben.

# 1) Wasserfallmodell

Wie bereits erwähnt, ist das Wasserfallmodell der erste eingeführte Lebenszyklus der Softwareentwicklung. Dies ist die sequentielle Methode zur Entwicklung von Software. Nur sehr wenige Unternehmen verfolgen diesen Ansatz. Wenn das Projekt sehr einfach ist und keine weiteren Anforderungsänderungen vorliegen, werden wir diesen Ansatz verfolgen.

In diesem Tutorial werden wir mehr über das Wasserfallmodell diskutieren.

# 2) Agiles Modell

Ein agiler Workflow ist ein fortschrittlicher Ansatz für den Softwareentwicklungsprozess, der in den meisten Unternehmen verwendet wird. Agile ist definiert als der sprintbasierte Lebenszyklus der Softwareentwicklung.

In den nächsten Abschnitten können wir mehr über den agilen Workflow diskutieren.

# 3) Spiralmodell

Auf diese Weise können Sie die Software erstellen und testen, indem Sie die Anforderung in inkrementeller Reihenfolge aufteilen und hinzufügen. Dieses Modell hilft bei Projekten, bei denen sich die Anforderungen ständig ändern. Dieses Spiralmodell ist die Kombination des iterativen Entwicklungsprozesses und des sequentiellen linearen Entwicklungsprozesses.

Dieser Ansatz ermöglicht uns inkrementelle Releases des Produkts. Hier muss nicht auf den Abschluss aller Module der Software bis zur Veröffentlichung gewartet werden.

Das lineare sequentielle Modell bedeutet, dass es sich um einen systematischen sequentiellen Ansatz der Softwareentwicklung handelt, der auf Systemebene beginnt und sich durch Analyse, Design, Codierung, Test und Support entwickelt.

Das iterative Modell bedeutet, dass es sich um eine bestimmte Implementierung eines Softwareentwicklungslebenszyklus handelt, die sich auf eine anfängliche, vereinfachte Implementierung konzentriert, die dann zunehmend komplexer wird und eine umfassendere Funktion festgelegt wird, bis das endgültige System vollständig ist.

# 4) Prototypmodell

Dieses Modell umfasst den Prozess des Erstellens und Testens der Software in der Weise, dass wir zuerst das Dummy-Modell entwickeln und, wenn es machbar ist und alle Geschäftsanforderungen erfüllt, das eigentliche Arbeitsmodell implementieren.

Hier haben wir zuerst den Prototyp gebaut und getestet und dann das eigentliche Modell mit den genauen Systemspezifikationen gebaut. Software-Prototyping ist die Aktivität zum Erstellen von Prototypen von Softwareanwendungen.

# 5) V- und V-Modell

Es ist das Verifizierungs- und Validierungsmodell. Während der Entwicklung der Software haben wir hier alles in jeder Phase des SDLC überprüft und validiert. Das V-Modell wird als Erweiterung des Wasserfallmodells betrachtet.

Alle SDLC-Typen haben also ihre Merkmale und Eigenschaften. Basierend auf den Projektanforderungen, Anforderungen, Durchführbarkeit und Zeitdauer können wir den jeweiligen Softwareentwicklungslebenszyklus für die Entwicklung der Softwareanwendung auswählen.

Jetzt werden wir die Lebenszyklen der Softwareentwicklung von Waterfall und Agile im Detail diskutieren.

Wasserfall-Modell

Im Wasserfallmodell sollte jede Phase abgeschlossen sein, bevor eine weitere Phase gestartet wird. Wir können nicht mehrere Phasen gleichzeitig betreiben. Dies wurde 1970 von Winston Royce eingeführt. Das Wasserfallmodell ist in verschiedene Phasen unterteilt.

(Bild Quelle ))

Das Wasserfallmodell umfasst die folgenden Phasen:

1. Anforderungserfassung
2. Machbarkeitsstudie
3. Design
4. Codierung
5. Testen
6. Instandhaltung

# 1) Anforderungsanalyse

Hier erhält der Business Analyst die Anforderungsspezifikation. Die Anforderung wird im CRS-Format (Customer Requirement Specification) vorliegen. CRS erklärt, wie der Geschäftsablauf verlaufen soll und wie die Anwendung gemäß den angegebenen Anforderungen funktionieren soll. Die Geschäftsanalysten werden CRS in SRS (Software Requirement Specification) umwandeln.

Anschließend bespricht der Business Analyst die Anforderungsspezifikationen mit dem Entwicklungs- und Testteam im Detail und versteht die Anforderung aus Sicht der Entwicklung und des Testens. In dieser Phase werden Anforderungen diskutiert und analysiert, um die Anwendungssoftware basierend auf den tatsächlichen Anforderungen zu erstellen.

Hier sollte alles im Dokument mit den Softwareanforderungsspezifikationen dokumentiert werden. Im Wasserfallmodell ist das Ergebnis / Ergebnis / die Ausgabe jeder Phase die Eingabequelle für die nächsten Phasen.

In einer serviceorientierten Branche kann ein Business Analyst die Anforderung stellen.
In einem produktbasierten Unternehmen bringt der Produktanalyst die Anforderung.

# 2) Machbarkeitsstudie

Das Management-Team wird die Machbarkeitsstudie durchführen. Das bedeutet, dass das Team Parameter analysiert, z. B. ob diese Anforderung / Anwendung in unserer Umgebung entwickelt werden kann oder nicht, ob die verfügbare Ressource ausreicht oder nicht, die Kosten und viele andere Faktoren machbar sind oder nicht und ob wir prüfen können, ob wir sie abdecken können alle Geschäftsabläufe oder nicht.

In diesem Meeting / dieser Analyse werden Projektmanager, Business Analyst, Finanzmanager, HR und Projektleiter Teil der Diskussion sein.

# 3) Systemdesign

Hier bereitet der Projektarchitekt das Systemdesign vor. Er legt die Hardware, die Systemanforderungen und das Design der Anwendungsarchitektur fest. Das Systemdesign besteht aus 2 Teilen: High-Level-Design und Low-Level-Design. Im High-Level-Design entwerfen wir die verschiedenen Blöcke der Anwendung. Im Low-Level-Design schreiben wir den Pseudocode.

# 4) Codierung

Hier beginnen Entwickler mit der genauen Codierung jeder Funktion und Benutzeroberfläche der Anwendung, indem sie unterschiedliche Methoden und unterschiedliche Logiken verwenden. Sie können jede Programmiersprache wie Java, Python oder eine andere Sprache verwenden, um die Anwendung zu erstellen.

Sobald die Codierung für jede Funktionalität des jeweiligen Moduls der Anwendung abgeschlossen ist, führt der Entwickler den Komponententest durch. Wenn der Code einwandfrei funktioniert, stellt der Entwickler den Code in der Testumgebung bereit und gibt den Build zum Testen an den Tester weiter.

# 5) Testen

Ab hier beginnt die Testaktivität. Bis zu dieser Phase werden wir im Wasserfallmodell keine Aufgabe haben. In dieser Phase führen wir alle Arten von Tests durch. Diese Testtypen umfassen Rauchtests, Funktionstests, Integrationstests, Systemtests, Abnahmetests, Regressionstests, Ad-hoc-Tests, Erkundungstests und browserübergreifende Tests.

Wir werden mit dem Testen der Anwendung beginnen, sobald wir den Build erhalten haben. Zunächst beginnen wir mit der Rauchprüfung. Wenn keine Blockerprobleme festgestellt werden, fahren wir mit den detaillierten Tests fort.

Beim Funktionstest beginnen wir mit dem Testen jeder Komponente der Anwendung. Hier überprüfen wir die verschiedenen Komponenten wie Textfelder, Schaltflächen, Links, Optionsfelder, Upload-Schaltflächen, Dropdowns und Navigationslinks.

Als nächstes werden wir die Benutzeroberfläche, das Erscheinungsbild und die positiven und negativen Eingabetests überprüfen.

Dann beginnen wir mit dem Integrationstest. Hier überprüfen wir die Datenintegration. Wir werden überprüfen, ob dieselben Daten auf verschiedenen Seiten wiedergegeben werden oder nicht, und die Navigation per E-Mail-Link zu den jeweiligen Seiten überprüfen. Wir werden die Datenintegration mit Anwendungen von Drittanbietern überprüfen und die Datenbankänderungen in der Anwendung überprüfen.

Als nächstes werden wir Systemtests durchführen. Wir werden die gesamte Anwendung als eine Einheit prüfen. Wir werden die Funktionalität, die Integration der Seiten, Feldvalidierungen, Fehlermeldungen, Bestätigungsmeldungen und vieles mehr überprüfen.

Während des Testens der Anwendung werden die Probleme im Bug-Tracking-Tool protokolliert. Wir werden dem Fehler basierend auf den Problemen Priorität einräumen. Nach dem Erstellen des Fehlers weisen wir ihn dem jeweiligen Entwickler zu, um das Problem zu beheben. Wir werden die Fehler überprüfen, sobald die Entwickler sie den Testern zugewiesen haben, nachdem sie behoben wurden. Wenn es gut funktioniert, schließt der Tester den Fehler, andernfalls weisen die Tester dem Entwickler zurück, um das Problem zu beheben. So läuft der Bug-Lebenszyklus ab.

Dann fahren wir mit der Abnahmeprüfung fort. Hier testen wir die Anwendung in verschiedenen Umgebungen wie Staging und UAT (User Acceptance Testing). Dies ist die wichtigste Phase, um die Anwendung gründlich zu testen, bevor wir den Code in die Produktionsumgebung verschieben.

Sobald der Abnahmetest fehlerfrei durchgeführt wurde, plant der Client, den Code auf dem Produktionsserver bereitzustellen und die Freigabe zu planen.

# 6) Wartung

Sobald wir den Anwendungscode auf dem Produktionsserver bereitgestellt haben, sollten wir den Support / die Wartung für die Clientanwendung bereitstellen. In dieser Wartungsphase werden die Produktionsprobleme in Echtzeit beobachtet und behoben, die Speicherprobleme überprüft, die Anwendung verbessert und die neuen Anforderungsänderungen entwickelt.

In welchen Fällen können wir uns für das Wasserfallmodell entscheiden?

• Wenn keine Änderungen erforderlich sind.
• Wenn das Projekt klein und einfach ist.
• Wenn es keine Komplexität in der Technologie gibt.
• Wenn mehr Ressourcen verfügbar sind.

Wasserfall-Vorteile:

• Vorwärts rückwärts Planung und Implementierung sind einfach .
• Das Wasserfallmodell ist einfach zu bedienen und leicht zu verstehen. Es erfordert keine spezielle Schulung für Projektmanager oder Mitarbeiter. Es hat eine einfache Lernkurve .
• Es ist starr in der Natur einfach zu verwalten der Wasserfallzyklus. Jede Phase hat feste Ergebnisse und einen Überprüfungsprozess.
• Weniger Komplexität da sich die Phasen nicht überlappen. Phasen werden nacheinander verfolgt. Es verwendet eine klare Struktur im Vergleich zu den anderen Softwareentwicklungsmethoden. Das Projekt durchläuft feste aufeinanderfolgende Schritte, beginnend mit der Anforderungserfassung, und landet schließlich bei der Wartung.
• Aufgrund der schrittweisen Entwicklung, Disziplin wird durchgesetzt und Zeitskalen können leicht eingehalten werden.
• Funktioniert gut für kleine Projekte wo wir feste und kristallklare Anforderungen haben.
• Prozesse und Ergebnisse sind gut dokumentiert .
• Das Ordnen von Aufgaben ist einfach.
• Es ist einfach den Fortschritt zu messen als Start- und Endpunkt jeder Phase sind vorgegeben.
• Es gibt fast keine Änderung der Anforderungen während des Projekts, daher die Aufgaben bleiben stabil für die Entwickler. Auch ist es für jeden einfach neuer Entwickler, um schnell zu lernen und die Arbeit beginnen.
• Es gibt Keine finanziellen Überraschungen . Sobald die Anforderungen festgelegt sind, können die endgültigen Kosten vor Beginn der Entwicklung berechnet werden.
• Bietet für eine sequentielles Finanzierungsmodell .
• Es ist detailliertes Design macht das endgültige erwartete Ergebnis allen klar.
• Die in der Anforderungserfassungsphase dokumentierte funktionale Anforderungsspezifikation bietet den Testern genügend Details, um Testszenarien und Testfälle zu entwerfen. Daher die Testprozess wird einfach im Wasserfallmodell.

Wasserfall Nachteile:

• Da alle Anforderungen vor Beginn der Entwicklung klar bekannt sein müssen, ist es verzögert das Projekt .
• Erfordert umfangreiche Forschung in die Benutzerbedürfnisse.
• In der Anfangsphase des Projekts ist es für einen Kunden eine Herausforderung, seine Anforderungen in Form von Funktionsspezifikationen klar zu definieren und zu konzipieren. Daher besteht für sie eine hohe Wahrscheinlichkeit, dass sie ihre Meinung ändern, nachdem sie das Endprodukt gesehen haben. Diese Änderung kann auch aufgrund eines Geschäftsplans oder eines Markteinflusses auftreten. Geringe Flexibilität in diesem Modell macht es Es ist schwierig, solche Änderungen zu berücksichtigen , insbesondere wenn das Produkt weitgehend überarbeitet werden muss.
• Kein Arbeitsmodell wird produziert bis zum später Phase während des Wasserfalllebenszyklus.
• Langsame Lieferzeiten . Der Kunde kann das Produkt erst sehen, wenn es vollständig fertiggestellt ist.
• Der Kunde hat keine Möglichkeit, sich vorab mit dem System vertraut zu machen. Das Wasserfallmodell ist eher ein interner Prozess und hält den Endbenutzer ausgeschlossen .
• Das Kunde wird nicht informiert gut über die Gesundheit des Projekts.
• Fristen können versäumt werden wenn strikte Verwaltung und regelmäßige Überwachung nicht eingehalten werden.
• Es gibt kein Raum für Änderungen auch wenn es während der Entwicklung sichtbar ist, da das Produkt nicht den Marktanforderungen entspricht.
• Verzögert das Testen bis nach Fertigstellung. Außerdem sind große Überarbeitungen zu diesem Zeitpunkt sehr kostspielig.
• Hohes Risiko und Unsicherheit sind am Wasserfallmodell beteiligt, da zu viel Raum für Probleme bleibt, um unbemerkt zu bleiben, bis das Projekt kurz vor dem Abschluss steht.
• Kein geeignetes Modell für lange, komplexe und laufende Projekte.
• Es ist schwierig zu Messen Sie den Fortschritt innerhalb jeder Phase.
• Die Tester werden in den vielen Phasen des Projekts untätig bleiben.

Agiler Workflow

Jetzt sehen wir den Entwicklungszyklus der agilen Softwareentwicklung. Agil ist der Prozess, bei dem Arbeiten schnell und einfach und genauer ausgeführt werden.

Dieses Modell bezieht sich auf eine Methode des Projektmanagements, die speziell für die Softwareentwicklung verwendet wird. Es zeichnet sich durch die Aufteilung der Aufgaben in kurze Arbeitsphasen sowie die häufige Neubewertung und Anpassung von Plänen aus. Jedes Teammitglied sollte die Idee der grundlegenden Geschäftsabläufe haben.

(Bild Quelle ))

In Agile arbeiten Entwickler und Tester parallel an der Entwicklung und dem Testen der Anwendungssoftware. Die Entwicklung erfolgt im iterativen Modus. Jede Iteration User Storys erfordert die Analyse, das Design, die Codierung und das Testen.

Wir testen die Anforderung detailliert, um zu überprüfen, ob die Anforderung fehlerfrei und implementierbar ist oder nicht. Wechseln Sie nach dem Ende jeder Iteration zur nächsten Iteration, und wir folgen demselben Prozess für die neuen / anderen Anforderungen.

Somit wird dieser Prozess des Entwickelns und Testens des Softwareblocks in kurzer Zeit mit größerer Genauigkeit und Flexibilität durchgeführt. Weitere Branchen folgen und übernehmen diesen Prozess.

Zunächst fügt der Product Owner alle Anforderungen zum Product Backlog hinzu. Das Product Backlog enthält alle User Stories. Angenommen, 100 bis 150 User Stories beziehen sich auf das gesamte Projekt. Fügen Sie nun die bestimmten User Stories zum Sprint-Backlog hinzu, das implementiert werden muss. Dann werden alle Entwickler, QA, BA, an den Sprint-Elementen arbeiten. So funktioniert Agile Flow.

In Agile verwendete Schlüsselterminologien

Was ist der Sprint-Rückstand?

Was ist ein Testfall beim Testen von Software anhand eines Beispiels?

Dies ist die Liste der User Stories, die wir in der aktuellen Iteration oder im Sprint implementieren müssen.

Zum Beispiel, Das Sprint-Backlog enthält 20 bis 30 User Stories. Dann sind dies die User Stories, die wir im aktuellen Sprint implementieren müssen.

(Bild Quelle ))

Was ist ein Sprint?

Sprint ist die kleine Dauer, in der wir die ausgewählten User Stories innerhalb einer bestimmten Dauer implementieren müssen. Die Sprintdauer beträgt ca. 2 bis 3 Wochen. Ihre Dauer variiert von Unternehmen zu Unternehmen.

In dieser Sprintdauer muss das Team die Anforderungen analysieren, die Anforderungen entwerfen, Codierungen durchführen, Tests durchführen, das Problem beheben, erneut testen, Regressionstests durchführen, Demos durchführen und viele weitere Aktivitäten durchführen.

Tägliches Standup Scrum Meeting

Business Analyst, Entwickler, Tester und der Projektmanager sind Teil der täglichen Stand-up-Scrum-Meetings. Es wird täglich gemacht. Es sollte nicht länger als 15 bis 30 Minuten dauern.

Hier teilen sich alle Teammitglieder den täglichen Arbeitsstatus. Die wichtigsten Dinge, die wir hier diskutieren, sind: Was sind die Dinge, die gestern abgeschlossen wurden, Plan für die heutige Arbeit und alle Herausforderungen oder Abhängigkeiten, mit denen sie im Projekt konfrontiert sind.

Wenn ein Teammitglied während des Projekts auf Herausforderungen oder Hindernisse stößt, wird die betroffene Person daran arbeiten, um dies zu erreichen.

Burndown-Diagramm

Es ist eine bildliche grafische Darstellung von Zeit und Arbeit. Die x-Achse repräsentiert die verbleibende Arbeit, die y-Achse repräsentiert die verbleibende Sprintzeit. Das Team muss die Arbeitsaufgaben bezüglich der im jeweiligen Sprint verfügbaren Zeit erstellen. Das Team verbrennt die Arbeitsstunden täglich basierend auf der Arbeit, die sie geleistet und erledigt haben.

(Bild Quelle ))

Kanban-Diagramm

Es ist ein Projektmanagement-Diagramm / Tool. Damit können wir die Aufgaben des gesamten Projekts verwalten. Wir können den Projektfortschrittsstatus und den Arbeitsstatus einzelner Personen überprüfen. Es zeigt die bildliche digitale Darstellung von Fortschrittselementen, ausstehenden Elementen und fertigen Elementen.

(Bild Quelle ))

Virtual-Reality-Brille für Xbox 360

Planung der Pokeraktivität

Es ist ein Spiel zwischen den Mitgliedern des Sprintteams, um die User Stories zu schätzen. Hier wird das gesamte Team die Pokeraktivität spielen. Jedes Teammitglied gibt die Schätzung basierend auf dem User Story-Punkt. Basierend auf den Stimmen der Mehrheitsschätzung entscheidet das Team über das Zeitfenster und teilt es zu.

Zum Beispiel Ein User Story-Teammitglied gibt eine Schätzung wie 3, 5, 8, 3, 1, 3. Dann wählt das Team 3 als Schätzung. Poker Aktivitätskarte enthält 0, 1, 3, 5, 8, 13, 20, 100, Pause, Zweifel? Karten. Basierend auf diesem Team schlagen die Mitglieder eine Schätzkarte vor. Auf diese Weise werden wir alle User Stories schätzen, die sich auf den jeweiligen Sprint beziehen.

(Bild Quelle ))

• 0 Pokernummer steht für: Keine Aufgabe in diesem Artikel / dieser User Story
• 1, 3 Zahlen stehen für: Die Aufgabe ist weniger
• 5, 8 Zahlen stehen für: Aufgaben auf mittlerer Ebene
• 13, 20 Zahl steht für: große Aufgaben
• 100 Zahl steht für: sehr große Aufgaben
• Unendlichkeit repräsentiert: Die Aufgabe ist riesig und muss in mehrere Aufgaben und User Stories aufgeteilt werden
• Pause steht für: brauche eine Pause
• ? Repräsentiert: Zweifel

Scrum Master

Er ist die Person, die dem Team hilft, den agilen Prozess zu verfolgen und die Projektanforderungen zu erfüllen. Er wird das Meeting bei Bedarf durchführen und dabei helfen, die Bedürfnisse des Projekts zu besprechen.

Scrum Master fungiert als Brücke zu allen Teammitgliedern, um die Herausforderungen und Abhängigkeiten zu lösen, die im Projekt auftreten. Er wird den Projektfortschritt für jeden Sprint verfolgen.

Er ist an der Standup-Besprechung, der Rückschau, der Inspektion, der Überprüfung und der Demo beteiligt. Er ist derjenige, der die täglichen Stand-up-Meetings durchführt und das Update der Teammitglieder übernimmt.

Product Owner

Er ist die Person, die das Produkt / Projekt aus geschäftlicher Sicht steuert und überwacht. Er beobachtet weiterhin, ob das Produkt gemäß den Geschäftsanforderungen entwickelt wurde oder nicht. Er ist derjenige, der die User Stories priorisiert und die Anforderungen vom Produkt-Backlog in das Sprint-Backlog verschoben hat. Er wird die Projektfristen schätzen.

Er betrachtet das Produkt immer aus der Sicht des Benutzers. Der Product Owner verfügt über umfassende Kenntnisse darüber, wie die Anwendung funktionieren soll.

Benutzer Geschichte

Es ist ein Anforderungsblock. Es enthält eine Reihe von Anwendungsfällen / Anforderungen, die sich auf dasselbe Modul beziehen. Hier definieren wir, wie jede Komponente einer Anwendung funktionieren soll und wie die Benutzeroberfläche aussehen soll. Der Umfang jeder Komponente wird in der User Story definiert.

Aufgaben

Die Teammitglieder erstellen die Aufgabe für die ihnen zugewiesene User Story. Sie müssen die Aufgabe basierend auf den verschiedenen Aufgaben wie Entwicklungsaufgabe, Testaufgabe und User Story-Analyseaufgabe erstellen. Die Dauer der Aufgabe sollte von den User Story-Punkten abhängen.

Als Tester erstellen wir die Aufgaben für die Analyse von User Storys, die Vorbereitung von Testfällen, die Ausführung, Regressionstests und vieles mehr.

Backlog-Pflege

In diesem Teil werden Rückstandselemente verwaltet. Die Aktivitäten, die wir hier ausführen, sind das Priorisieren der Backlog-Elemente, das Aufteilen in kleinere Elemente, das Erstellen der Aufgabe und das Aktualisieren der Akzeptanzkriterien.

Wiederholung

Iteration ist die Entwicklung und Erprobung einiger Module / Teile der Softwareanwendung. Jede Iteration besteht aus der Analyse des Produkts, dem Design des Produkts, der Entwicklung des Produkts, dem Testen des Produkts und der Demo des Produkts.

Schlüsselfaktoren für die Einführung einer agilen Methodik

• Überwachung: Überprüfen Sie die Arbeit und das Produkt regelmäßig und planen Sie die Aktivitäten entsprechend. Der Produktentwicklungsprozess und die Produktqualität werden also gut sein.
• Willkommene Änderungen: Änderungen sind sehr einfach zu handhaben. Dies hat keine großen Auswirkungen auf das Produkt, da Module der Software separat entwickelt und später integriert werden. Es wird also keine Nacharbeit geben, wenn sich die Anforderung in Zukunft ändert.
• Zeitrahmen: Wir erhalten den Zeitrahmen für jede Einheit der Anwendung. Die Schätzung ist also genau auf die Projektzeitschätzungen zugeschnitten.
• Kundenzufriedenheit: Die Kundenzufriedenheit ist höher, da wir während des gesamten Projekts mit dem Kunden und den Aktionären interagieren und auf jeder Ebene der Produktentwicklung eine Demo geben. Auf diese Weise erhalten wir regelmäßig Kunden- / Kundenfeedback über die Geschäftsabläufe und den Arbeitsfortschritt. Somit werden Arbeit und Entwicklung der Anwendung entsprechend durchgeführt.

Arten agiler Methoden

• Agile Scrum-Methodik
• Lean Software-Entwicklung
• Kanban
• Extreme Programmierung (XP)
• Kristall
• Entwicklungsmethode für dynamische Systeme (DSDM)
• Feature Driven Development (FDD)

Agile Profis:

• Einer der größten Vorteile des agilen Modells ist seine große Anpassungsfähigkeit . Anpassungsfähigkeit bedeutet „auf Veränderungen reagieren“. Agile ist sehr flexibel im Umgang mit Änderungen der Kundenbedürfnisse und -prioritäten.
• Ermöglicht Den gesamten Produktbestand ständig verfeinern und neu priorisieren ohne die aktuelle Iteration zu beeinflussen, in der sich das Team auf die Bereitstellung des MVP konzentriert. Die Änderungen können für die nächste Iteration geplant werden, sodass die Änderungen nur innerhalb weniger Wochen vorgenommen werden können.
• Agile Methodik bietet ein hohes Maß an Stakeholder-Engagement . Der Kunde und das Projektteam treffen sich vor, während und nach jedem Sprint. Da der Kunde während des gesamten Projekts ständig involviert ist, hat das Team mehr Möglichkeiten, die Vision des Kunden klar zu verstehen.
• Die funktionierende Software wird früh und häufig geliefert. Dies erhöht die Vertrauen der Stakeholder im Team und ermutigt das Team dazu Bleib sehr engagiert zum Projekt.
• Dieses Modell gibt Transparenz . Sowohl die Stakeholder als auch das Team wissen genau, was passiert. Der Kunde kann die laufenden Arbeiten sehen.
• Feste Sprints von ein bis vier Wochen sind möglich frühzeitige und vorhersehbare Lieferung . Neue Funktionen werden schnell und häufig zeitgesteuert veröffentlicht.
• Agil ist kundenorientierte . Es bietet nicht nur die Funktionalität, sondern konzentriert sich auch auf die Bereitstellung der Funktion, die für den Benutzer von Wert ist. Jede User Story hat ein geschäftsorientiertes Akzeptanzkriterium.
• Wertvoll Kundenbewertung gewonnen wird früh im Projekt und Änderungen am Produkt können nach Bedarf vorgenommen werden.
• Der Fokus liegt auf dem Geschäftswert . Es liefert zunächst das, was für den Kunden am wichtigsten ist.
• Verbessert die Qualität der Ergebnisse . Im Gegensatz zu Wasserfällen werden Tests in einem agilen Projekt kontinuierlich und häufig durchgeführt, was wiederum dazu beiträgt, die Probleme frühzeitig zu erkennen und zu beheben.
• Agil unterstützt den TDD-Ansatz (Test Driven Development) Dies bietet genügend Zeit, um Komponententests für die Funktionen zu erstellen, die über MVP veröffentlicht werden.
• Auch durch Produzieren häufige Builds Auch eine Fehlausrichtung mit den Kundenanforderungen kann frühzeitig erkannt und behoben werden.
• Wie wir bekommen sofortiges Benutzerfeedback Nach jeder MVP-Veröffentlichung wird die Risiko eines Projektversagens ist gering, wenn Sie agil arbeiten.
• Agil fördert die Teamarbeit . Es gibt eine großartige Zusammenarbeit, Interaktion, Harmonie und Begeisterung unter den agilen Teammitgliedern.
• Die Kosten- und Zeitplanschätzungen für jeden Sprint werden dem Kunden vor dem Start des Sprints mitgeteilt. Dies verbessert die Entscheidungsfindung da der Benutzer die Kosten jeder Funktion verstehen und entsprechend priorisieren kann.
• In einem agilen Projekt ist Platz für ständige Verbesserung . Lehren aus den vergangenen Sprints können in den kommenden Sprints angewendet werden.
• Es konzentriert sich auf die jeweilige Aufgabe in jeder Phase des Projekts.

Agile Nachteile:

• Es wird oft gesehen, dass agile Teams eine haben Tendenz, die Dokumentation zu vernachlässigen . Dies liegt daran, dass sich das Agile-Manifest mehr auf funktionierende Software als auf die umfassende Dokumentation konzentriert. Die Teams sollten jedoch das richtige Gleichgewicht zwischen Code und Dokumentation aufrechterhalten.
• Da es ein hohes Maß an Kundenbeteiligung erfordert, kann es manchmal problematisch für Kunden die nicht viel Zeit und Interesse haben, um an dem Projekt teilzunehmen.
• Es funktioniert nicht gut, wenn dem Team Engagement und Engagement fehlen. Wasserfall erfordert Engagement, Agile erfordert Engagement.
• Wenn die anfängliche Architektur und das Design schwach sind, dann häufiges Refactoring ist nötig.
• Im Vergleich zum Wasserfall ist Agile schwer zu üben . Die Teammitglieder müssen mit agilen Konzepten vertraut sein. Es erfordert viel Disziplin und Engagement, um Agile zu üben.
• Aufgrund der Neupriorisierung ist dies der Fall weniger vorhersehbar als was am Ende des Sprints geliefert wird.
• Aufgrund der zeitgesteuerten Zustellung und der häufigen Neupriorisierung besteht die Möglichkeit, dass einige Funktionen nicht in der zugewiesenen Zeitachse ausgeliefert werden. Dies kann dazu führen zusätzliche Sprints und zusätzliche Kosten . Dies kann auch zu dem Problem führen nebulöse Zeitlinien .
• Mangel an Struktur im Vergleich zum Wasserfall, es erfordert selbstdisziplinierte, hochqualifizierte und fachübergreifende Teams . Ohne dies kann das Projekt wirklich eine Herausforderung sein.
• Verfügbarkeit ist weniger eine Blaupause des endgültigen Ergebnisses .
• Manchmal die Externe Stakeholder können dem agilen Ansatz nicht widerstehen . In solchen Fällen sind Schulungen und Schulungen zu Agile für ein breites Publikum erforderlich.
• Alle Teammitglieder müssen an der Verwaltung des Projekts beteiligt sein.
• Die Dokumentation ist weniger detailliert.

Unterschied zwischen agilen und Wasserfallmodellen

Die Unterschiede zwischen den Lebenszyklen von Waterfall und Agile Software Development sind unten aufgeführt.

Wasserfall	Agil
Der Prozess wird als ein einziges Projekt behandelt, das weiter in verschiedene Phasen unterteilt ist.	Der Prozess ist in mehrere Projekte unterteilt und jedes Projekt hat eine Iteration verschiedener Phasen.
Die Wasserfallmethode ist ein Modell, bei dem jede Phase des Produktlebenszyklus in einer Sequenz abläuft. Der Fortschritt des Projekts verläuft schrittweise abwärts durch diese Phasen, die einem Wasserfall ähneln.	Die agile Methodik ist ein Modell, das einem iterativen Ansatz folgt.
Dieses Modell glaubt an eine einmalige massive Gesamtlieferung. Das Produkt wird am Ende des SDLC geliefert.	Dieses Modell glaubt an mehrere kleine Lieferblöcke in definierten Zeitintervallen. Am Ende jedes Sprints wird ein MVP (Minimum Viable Product) geliefert.
Es ist ein traditioneller und altmodischer Ansatz.	Es ist ein neuer und moderner Ansatz.
Ein einziger Zyklus und eine einzige Version.	Wiederholte Anzahl von Iterationen und mehreren Releases.
Es unterteilt den Softwareentwicklungslebenszyklus in verschiedene Phasen.	Es unterteilt den Lebenszyklus der Softwareentwicklung in Sprints.
Strukturiertes und starres Modell. Es ist schwierig, die Beschreibung, Spezifikation und das Design des Projekts zu ändern.	Dieses Modell ist bekannt für seine Flexibilität. Wir können jederzeit Änderungen in jeder Projektphase vornehmen.
Langfristige Planungsskala.	Kurzfristige Planungsskala.
Zwischen dem Kunden und dem Entwickler besteht eine große Distanz.	Zwischen dem Kunden und dem Entwickler besteht eine kurze Distanz.
Lange Zeit zwischen Spezifikation und Implementierung. Der Business Analyst sammelt und bereitet den Bedarf vor Projektbeginn vor.	Kurze Zeit zwischen Spezifikation und Implementierung. Der Product Owner bereitet die Anforderungen und Aktualisierungen für das Team in jedem Sprint vor.
Es dauert lange, Probleme zu entdecken.	Probleme werden schnell erkannt.
Hohes Projektplanrisiko.	Geringes Projektplanrisiko.
Weniger die Fähigkeit, schnell auf Änderungen zu reagieren.	Hohe Fähigkeit, schnell auf Änderungen zu reagieren.
Die Testphase erfolgt erst nach Abschluss der Entwicklungsphase.	Die Tests werden in der Regel parallel zur Entwicklung durchgeführt, um die Qualität kontinuierlich sicherzustellen.
Der Kunde ist nur in der Anforderungserfassungsphase involviert und danach erfolgt keine Beteiligung des Kunden. Er kommt erst zum Zeitpunkt der Lieferung des Produkts ins Bild.	Der Kunde ist während des gesamten Projekts involviert und wird von Zeit zu Zeit vom Kunden zurückgemeldet, um die Kundenzufriedenheit sicherzustellen.
Geeignet für Projekte mit klar definierten Anforderungen und solche, die keine Änderungen erwarten.	Geeignet für Projekte, die sich weiterentwickeln müssen, und solche, bei denen sich die Anforderungen ändern.
Streng sequentieller Prozess.	Ein äußerst kollaborativer Softwareentwicklungsprozess führt zu besseren Teamanstrengungen und einer schnellen Problemlösung.
Zeigt eine Projektmentalität.	Führt eine Produkt-Denkweise ein und ist somit kundenorientierter. Anforderungen und Änderungen sind Teil des Prozesses
Formell und hierarchisch. Der Projektmanager ist der Entscheider.	Es ist informell. Das gesamte Team ist für die Entscheidungsfindung verantwortlich.
Dieses Modell geht davon aus, dass sich die Anforderungen während des gesamten Projekts nicht ändern werden.	Dieses Modell basiert auf Anpassung und umfasst Änderungen.
Sie müssen manuelle Dokumente erstellen, um den Status der Arbeit und den Projektfortschritt der Person zu überprüfen.	Befolgen Sie das Kanban-Diagramm und das Burn-Down-Diagramm, um den Projektfortschritt und den Arbeitsstatus der Person zu überprüfen.

Wir hatten genug Diskussion über die Unterschiede zwischen den Agile & Waterfall-Methoden und die Vorteile und Herausforderungen der einzelnen Methoden. Lassen Sie uns nun die Unterschiede zwischen agilen Tests und Wasserfalltests untersuchen.

Unterschiede zwischen Agile Testing und Waterfall Testing

Aus der Sicht des Softwaretests ist es wichtig, dass wir eine gute Vorstellung davon haben, wie sich agiles Testen von Wasserfalltests unterscheidet.

Fazit

In diesem Artikel haben wir die genauen Unterschiede zwischen dem modernen agilen Ansatz und der traditionellen Waterfall-Methode zur Softwareentwicklung und zum Testen anhand einer Vergleichstabelle kennengelernt, in der die Vor- und Nachteile der einzelnen Modelle aufgeführt sind.

Unter Berücksichtigung aller in diesem Artikel aufgeführten Faktoren können wir das richtige Lebenszyklusmodell für die Softwareentwicklung auswählen, um die Softwareanwendung zu entwickeln. Es besteht kein Zweifel daran, dass agile Methoden dem Wasserfallmodell vorgezogen werden. 90% der Unternehmen bevorzugen und folgen dem agilen Workflow, um die Softwareanwendung zu entwickeln.

Agile Methodik eignet sich für alle Arten von Projekten. Nur sehr wenige Unternehmen folgen der Wasserfallmethode. Diese Methode eignet sich nur, wenn die Anwendung klein und einfach ist und sich die Anforderungen nicht ändern.

In einigen Fällen entscheiden wir uns je nach Bedarf auch für andere Ansätze namens Spiral, V und V sowie Prototyp.

Ich hoffe, diese Informationen helfen Ihnen bei der Entscheidung, welches Modell für Ihr Projekt am besten geeignet ist. Sie können auch für die gehen Hybridmodell, das die Nachteile jeder Methode beseitigt - hier diskutiert.

Literatur-Empfehlungen

• Fallstudie: Beseitigung von Fehlern bei Wasserfällen und agilen Entwicklungsprozessen mithilfe eines Hybridmodells
• Was ist das SDLC-Wasserfallmodell?
• Überprüfung des Zephyr Enterprise Test Management-Tools - Verwenden von Wasserfallmodell-Assets in Agile Tool
• VersionOne-Lernprogramm: All-in-One-Handbuch für agiles Projektmanagement
• Jira Portfolio Tutorial: Agiles Projektportfolio-Management-Plug-In für JIRA (Überprüfung)
• TOP 10 der besten agilen Projektmanagement-Tools im Jahr 2021
• Agile Schätztechniken: Eine echte Schätzung in einem agilen Projekt
• 4 Schritte zur Entwicklung der Denkweise für agile Tests für einen erfolgreichen Übergang zu agilen Prozessen