Wenn Sie ein Softwareprojekt leiten, werden Sie sich wahrscheinlich mit der Frage auseinandersetzen müssen, welche Entwicklungsmethodik die richtige ist. Manche bevorzugen den traditionellen Wasserfallansatz, während andere auf agile Methoden setzen. In der Realität bewegen sich viele Projekte irgendwo dazwischen – mit einer Methodik, die weder extrem agil noch extrem starr ist.
Im Vergleich zum Wasserfallmodell wirken diese „Mittelweg“-Methoden flexibel, da sie Änderungen von Iteration zu Iteration ermöglichen. Im Vergleich zu agilen Methoden erscheinen sie jedoch starr und deutlich weniger kollaborativ.
Bei der Wahl der passenden Entwicklungsmethodik für Ihr Projekt sollten Sie überlegen, wie flexibel sie sein sollte und welche Aspekte verschiedener Ansätze sich am besten kombinieren lassen. Berücksichtigen Sie die Projektgröße, die Zusammensetzung Ihres Teams, die Unternehmenskultur und Ihre Ziele. Stellen Sie anschließend die Methodik passend zu Ihren spezifischen Anforderungen zusammen. Selbst wenn Ihr Unternehmen einen bestimmten Ansatz bevorzugt, gibt es oft Möglichkeiten, diesen zu verbessern und an Ihr Projekt anzupassen.
Um Ihnen die Entscheidung zu erleichtern, welcher Ansatz für Ihre Situation am besten geeignet ist, berücksichtigen Sie bitte die folgenden Aspekte. Die Fragen helfen Ihnen dabei, den erforderlichen Flexibilitätsgrad Ihrer Methodik auf einer Skala von sehr flexibel (agil) bis sehr starr (Wasserfallmodell) einzuschätzen.
Siehe auch: Agile vs. Wasserfall: Ein strategischer Leitfaden für Projektmanager (mit detaillierter Vergleichstabelle)
1. Wie klar sind die Ziele und Anforderungen des Projekts?
Bei manchen Projekten wissen die Kunden genau, was sie erreichen wollen und welche Erfolgskriterien gelten. Bei anderen Projekten ist es oft schwierig, die Projektziele oder Anforderungen präzise zu definieren. Sind die Anforderungen schwer zu fassen oder ändern sie sich voraussichtlich stark, ist ein relativ experimenteller und flexibler Ansatz erforderlich. Dieser ermöglicht es, Ideen schnell zu präsentieren und Prototypen zu erstellen sowie sich ändernde Anforderungen zu integrieren.
2. Wie klar und präzise ist die Lösung definiert?
Es kann vorkommen, dass das gewünschte Projektergebnis klar definiert ist, die Lösung zur Erreichung dieses Ergebnisses jedoch unklar bleibt. Steht das Team vor schwierigen und riskanten Entscheidungen hinsichtlich Technologie, Design und Implementierung, muss Ihre Softwareentwicklungsmethodik flexibel genug sein, um dies zu berücksichtigen und verschiedene Phasen von Prototyping, Entwicklung und Rollout iterativ zu durchlaufen.
3. Wie einfach oder schwierig ist es, die Endnutzer zu erreichen?
Sind die Nutzer, Fachexperten und Produktverantwortlichen voraussichtlich kurzfristig für Feedback und Tests der Ergebnisse verfügbar, oder erwarten Sie Schwierigkeiten bei der Kontaktaufnahme? Wäre es einfacher, sie für einen vorab geplanten Testzyklus einzubinden, in dem viele Ergebnisse gleichzeitig getestet werden können? Je eingeschränkter die Verfügbarkeit Ihrer Nutzer ist, desto strenger sollte Ihre Methodik sein.
4. Wie groß ist das Projekt?
Handelt es sich bei Ihrem Projekt um ein größeres Projekt oder um ein vergleichsweise kleines und schlankes? Je größer das Projekt, desto schwieriger kann es sein, kurzfristig viele Änderungen umzusetzen und das Team neu auszurichten. Kleine, eng verbundene Teams, die eng mit dem Kunden und den Endnutzern zusammenarbeiten, sind flexibler und besser darauf vorbereitet, Änderungen schnell zu implementieren.
5. Wie dezentralisiert ist das Projektteam?
Haben Sie mehrere Projektteams an verschiedenen Standorten oder ist Ihr Team eher homogen und arbeitet an einem Ort? Bei geografisch verteilten Teams kann es schwierig sein, neue Aufgaben schnell zu koordinieren und sich an veränderte Prioritäten anzupassen. Teams, die zusammen arbeiten und sich sogar einen Raum teilen, sind deutlich besser für die Arbeit in einem agilen Umfeld mit wechselnden Prioritäten gerüstet.
6. Welche Erfahrungen haben das Team und die Stakeholder mit diesen Methoden gemacht?
Sind Ihr Team und Ihre Stakeholder bereits an eine bestimmte Arbeitsweise gewöhnt? Falls ja, bedenken Sie, dass die Umstellung von Arbeitsabläufen Zeit braucht. Bei zeitkritischen Projekten sollten Sie zu viele drastische Änderungen an der bestehenden Vorgehensweise vermeiden, da dies den Zeitplan und den Erfolg Ihres Projekts gefährden könnte.
7. Was sind die Erfolgskriterien des Projekts?
Was ist Ihrem Auftraggeber und Kunden wichtiger? Ein relativ fester Kostenvoranschlag und Zeitplan, an den sich alle halten müssen, oder die Gewissheit, dass die Endergebnisse einen Mehrwert bieten und den Bedürfnissen und Erwartungen der Nutzer entsprechen? Ist Ihr Kunde bereit, einen flexibleren und qualitätsorientierten Ansatz zu verfolgen, selbst wenn dies zu Lasten fixer Kosten und Zeitpläne geht?
8. Welchen Mehrwert würde eine inkrementelle, funktionsorientierte Entwicklung bieten?
Eignet sich das Projekt für eine schrittweise Umsetzung und würde dies den Stakeholdern einen echten Mehrwert bieten? Müssen die Produkte und Funktionen sofort bereitgestellt werden, um greifbare Vorteile zu erzielen, oder wäre eine schrittweise Bereitstellung von Vorteil?
Nachdruck mit freundlicher Genehmigung von Susanne Madsen.
Autorin:
Susanne Madsen
Susanne Madsen ist eine international anerkannte Coachin, Trainerin und Beraterin für Projektmanagement. Sie ist die Autorin von „The Project Management Coaching Workbook“ und „The Power of Project Leadership“. Susanne ist überzeugt, dass erfolgreiches Projektmanagement ebenso sehr von der Führung von Mitarbeitern abhängt wie von der Steuerung von Aufgaben, Ereignissen und Prozessen. Sie ist eine überzeugte Anhängerin und Praktikerin der GTD-Methode (Get Things Done) und unterstützt Menschen mit Begeisterung bei der Formulierung und Erreichung ihrer Ziele. Weitere Informationen zu Susanne finden Sie unter http://www.susannemadsen.com/
Kommentare
0 Antworten