Vorgehensmodelle: Unterschied zwischen den Versionen

Aus FI-Wiki
 
(8 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 54: Zeile 54:
Projekte, bei denen ein bekanntes Technologie-Stack und Tools zum Einsatz kommen.
Projekte, bei denen ein bekanntes Technologie-Stack und Tools zum Einsatz kommen.


== SCRUM ==
== Scrum ==
'''Scrum''' ist ein leichtgewichtiges Rahmenwerk zur Entwicklung komplexer Produkte. 
Die Arbeit erfolgt in Sprints mit fester Länge von höchstens einem Monat.


Scrum ist eine der beliebtesten agilen Entwicklungsmethoden.
=== Verantwortlichkeiten ===
{| class="wikitable" style="width:100%; text-align:center;"
! Verantwortung !! Aufgabe
|-
| Product Owner || maximiert den Produktwert und verantwortet das Product Backlog
|-
| Scrum Master || unterstützt Scrum, beseitigt Hindernisse und fördert die Zusammenarbeit
|-
| Developers || erstellen in jedem Sprint ein nutzbares Increment
|}


Die Projektlaufzeit wird in kurze Iterationen (Sprints) aufgeteilt.
Gemeinsam bilden sie das Scrum Team. Scrum definiert innerhalb des Teams keine weiteren Hierarchien oder Unterteams.


Jede Iteration (Sprint) beginnt mit sorgfältiger Planung.
=== Ereignisse ===
* Sprint – Rahmen für alle weiteren Ereignisse
* Sprint Planning – Sprint-Ziel und geplante Arbeit festlegen
* Daily Scrum – tägliche Planung der Developers
* Sprint Review – Ergebnis mit Stakeholdern prüfen und weitere Anpassungen beraten
* Sprint Retrospective – Zusammenarbeit und Arbeitsweise verbessern


Der Sprint endet mit einer Sprint-Retrospektive, bei der der vorherige Sprint analysiert und bewertet wird.
=== Artefakte und Commitments ===
{| class="wikitable" style="width:100%; text-align:center;"
! Artefakt !! Commitment
|-
| Product Backlog || Product Goal
|-
| Sprint Backlog || Sprint Goal
|-
| Increment || Definition of Done
|}


Der nächste Sprint baut auf den Ergebnissen des vorherigen Sprints auf (z. B. Kundenfeedback, neue Anforderungen).
=== Änderungen im Sprint ===
Das Sprint-Ziel darf nicht gefährdet werden. Qualität darf nicht sinken. Der Umfang kann geklärt und mit dem Product Owner neu verhandelt werden; das Sprint Backlog wird während des Sprints angepasst.


Eine Iteration dauert üblicherweise 2 bis 4 Wochen.
=== Empirie ===
Scrum beruht auf:


Nachdem die Aktivitäten für den Sprint festgelegt sind, können keine Änderungen vorgenommen werden.
* Transparenz
* Überprüfung
* Anpassung


BILD
=== Kurzmerksatz ===
 
'''Scrum organisiert komplexe Produktentwicklung in kurzen Sprints mit klaren Verantwortlichkeiten, Ereignissen, Artefakten und regelmäßiger Anpassung.'''
=== Anwendungsbereiche: ===
 
Praktisch alle Startup-Initiativen, bei denen ein frühzeitiges Feedback der Endbenutzer erforderlich ist.
 
Die meisten mittelgroßen Projekte im Rahmen der individuellen Softwareentwicklung, bei denen detaillierte Softwareanforderungen auf Geschäftsanforderungen basieren.
 
Große Projekte, die einfach in kleinere Teile zerlegt und schrittweise umgesetzt werden können.

Aktuelle Version vom 7. September 2026, 07:30 Uhr

Aufgrund stetig zunehmender Komplexität der Software gewinnt das Thema Vorgehensmodelle in der Softwareentwicklung zunehmend an Bedeutung. Zu Beginn der Zeit der Softwareentwicklung wurden Programme hauptsächlich nach dem "Code and Fix" Prinzip erstellt.

Ziele: Projekt planbar machen und somit die Software-Qualität gewährleisten

Klassische Vorgehensmodelle (z. B. Wasserfallmodell, V-Modell)

Ablauf: Linear und sequenziell – Phasen wie Anforderungsanalyse, Planung, Umsetzung, Test und Wartung folgen strikt aufeinander.

Merkmale:

  • Feste Abläufe und Meilensteine
  • Frühzeitige, vollständige Planung
  • Änderungen sind später schwierig
  • Klare Dokumentation und Rollenverteilung

Geeignet für: Projekte mit klaren, stabilen Anforderungen

Agile Vorgehensmodelle (z. B. Scrum, Kanban)

Ablauf: Iterativ und inkrementell – das Projekt wird in kurzen Zyklen (Sprints) entwickelt.

Merkmale:

  • Flexibel, anpassbar an Veränderungen
  • Enge Zusammenarbeit im Team und mit dem Kunden
  • Laufende Lieferung von funktionsfähigen Teilprodukten
  • Kaum oder wenig Bürokratie, Fokus auf funktionierende Ergebnisse

Geeignet für: Dynamische Projekte mit sich ändernden Anforderungen

Wasserfallmodell

Bei diesem sequentiellen Vorgehensmodell ist der Entwicklungsprozess in aufeinanderfolgenden Phasen organisiert:

  • Analyse,
  • Entwurf,
  • Implementierung,
  • Test,
  • Installation, Wartung.

Dabei wird jede einzelne Phase stark dokumentiert.

Sobald die vorhergehende Stufe beendet wird, beginnt die nächste, die auf konkreten Ergebnissen der vorherigen Phase basiert.

Deshalb gibt es keine Möglichkeit, beispielsweise, Softwareanforderungen während der Entwicklungsphase neu zu bewerten.

Es ist auch unmöglich, die fertige Software zu sehen und zu testen, bis die letzte Entwicklungsstufe vollständig abgeschlossen ist, was zu hohen Projektrisiken und unvorhersehbaren Ergebnissen führt.

Deshalb werden Fehler nur am Ende des Projektes in der Testphase gefunden.

Deren umgehende Behebung erfordert einen größeren Aufwand und führt zu steigenden Gesamtkosten.

BILD

Anwendungsbereiche

Einfache kleine oder mittelgroße Softwareprojekte mit klar definierten und unveränderlichen Anforderungen (Entwicklung einer Website für kleine Unternehmen).

Projekte, bei denen ein bekanntes Technologie-Stack und Tools zum Einsatz kommen.

Scrum

Scrum ist ein leichtgewichtiges Rahmenwerk zur Entwicklung komplexer Produkte. Die Arbeit erfolgt in Sprints mit fester Länge von höchstens einem Monat.

Verantwortlichkeiten

Verantwortung Aufgabe
Product Owner maximiert den Produktwert und verantwortet das Product Backlog
Scrum Master unterstützt Scrum, beseitigt Hindernisse und fördert die Zusammenarbeit
Developers erstellen in jedem Sprint ein nutzbares Increment

Gemeinsam bilden sie das Scrum Team. Scrum definiert innerhalb des Teams keine weiteren Hierarchien oder Unterteams.

Ereignisse

  • Sprint – Rahmen für alle weiteren Ereignisse
  • Sprint Planning – Sprint-Ziel und geplante Arbeit festlegen
  • Daily Scrum – tägliche Planung der Developers
  • Sprint Review – Ergebnis mit Stakeholdern prüfen und weitere Anpassungen beraten
  • Sprint Retrospective – Zusammenarbeit und Arbeitsweise verbessern

Artefakte und Commitments

Artefakt Commitment
Product Backlog Product Goal
Sprint Backlog Sprint Goal
Increment Definition of Done

Änderungen im Sprint

Das Sprint-Ziel darf nicht gefährdet werden. Qualität darf nicht sinken. Der Umfang kann geklärt und mit dem Product Owner neu verhandelt werden; das Sprint Backlog wird während des Sprints angepasst.

Empirie

Scrum beruht auf:

  • Transparenz
  • Überprüfung
  • Anpassung

Kurzmerksatz

Scrum organisiert komplexe Produktentwicklung in kurzen Sprints mit klaren Verantwortlichkeiten, Ereignissen, Artefakten und regelmäßiger Anpassung.