Hallo zusammen,

ich bin kurz vor mein Projektbeginn, und habe noch einige bedenken zum Vorgehensmodell.

Mein Projekt ist eine Neuentwicklung einer bereits existierenden, aber veralteten Anwendung. Die Anwendung muss testgetrieben entwickelt werden. Aufgrund der Tatsache, das bereits eine alte Anwendung existiert und die Anforderungen/Funktionalität an der neuen Anwendung sehr klar sind, wollte ich gern das sequentielle Wasserfallmodell nehmen, da Agile Vorgehensmodelle wie Scrum und XP in meinem Betrieb nicht genutzt werden.

Phasen Analyse, Entwurf, Implementierung, Abnahme, Dokumentationen erstellen

Ich würde jedoch gerne in der Entwurfsphase für die Erstellung der Mockups, den Fachbereich direkt um Feedback bitten. Das wäre aber eher eine agile Vorgehensweise? Da die Anwendung testgetrieben entwickelt wird, erstelle ich in der Entwurfsphase auch kein Klassendiagramm, sondern erst in der Implementierungsphase (kleinere Klassendiagramme für den verbesserten Überblick). Testgetriebene Entwicklung ist aber eher auch ein agiles Vorgehen.

Könnte man das sequentielle Wasserfallmodell nutzen und in der Phase Entwurf und Implementierung ein agileres Vorgehen nutzen?

Vielleicht hab ich auch einfach ein Denkfehler irgendwo, freue mich über Ratschläge.

 

 

 

Bearbeitet 1. April 20169 j von March

Wenn du die wichtigsten Phasen deines Projekts eigentlich agil entwickelst, warum nennst du es dann Wasserfall? Welchen Vorteil hast du davon? Welche Unternehmensvorgaben sprechen dafür? Bzw. was hat dein Unternehmen gegen ein agiles Vorgehen?

Ich würde den letzten Schritt gehen und das gesamte Projekt agil entwickeln. Du nutzt offensichtlich die Vorteile der agilen Herangehensweise, aber wagst nicht den letzten Schritt. Mit diesem Mischmasch wirst du dir in der Prüfung eher Probleme einhandeln, als wenn du einfach klar Stellung beziehst.

Aber auch wenn du letztlich doch deine Mischung anwendest: Natürlich kannst du auch nur einzelne Phasen deines Projektes agil entwickeln. Das sehe ich sogar recht häufig in den Projekten. Wenn du das sauber begründest (z.B. Qualitätsgewinn, bessere Erfüllung der Anforderungen, Zeitersparnis), ist das kein Problem.