Herkömmliche Softwareentwicklungsmodelle vs. Agile Methoden

Transkript

1 vs. Agile Methoden University.de Medien und Kommunikationsinformatik

2 Agenda Einführung Vorgehensmodelle Herkömmlich agil Resümee

3 Klassische Probleme Nachgereichte Anforderungen Mangelhaftes Risikomanagement Projektstart Definierter Termin, definierte Kosten Ausfälle im Entwicklerteam Verspäteter Termin, überschrittenes Budget Quelle: eigene Grafik

4 Klassische Probleme Nur 35% der Softwareprojekte sind erfolgreich 19% werden abgebrochen 46% sind zu spät oder über Budget Qualität Zeit Kosten Quelle: eigene Grafik

5 Klassische Probleme Formalisierung soll Entwicklung effizienter und qualitativ besser machen Zeit und Kosten sollen besser einschätzbar werden Lösungsansatz: ein Vorgehensmodell

6 Vorgehensmodelle Wasserfallmodell (1960er) inkrementell + iterativ V-Modell (1986) V-Modell 97 Spiralmodell (1988) Probleme auf andere Weise angehen V-Modell XT (2005) Unified Process (1999) Agile Methoden (1990er) Quelle: eigene Grafik

7 Herkömmliche (Unified Process) Quelle: [RUP06]

8 Herkömmliche (Unified Process) Dokumentengetriebenes Vorgehensmodell Best Practices für jeden Teilschritt Meilensteine Vertraglich gut fassbar, da Spezifikation vor Umsetzung

9 Herkömmliche (Unified Process) Hohe Formalisierung Modell RUP Rollen > 30 Artefakte > 75 Quelle: [RUP06]

10 Herkömmliche Kritikpunkte: Analyse Paralyse Hohe Formalisierung hemmt Kreativität Zu statische Planorientierung hemmt Kreativität Aufgrund der Komplexität teuer in der Einführung

11 Agile We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Quelle: [AgMa08]

12 Agile (extreme Programming) Kurze Releasezyklen Inkrementell und iterativ Kontinuierliche Rückmeldung in beide Richtungen geringere Formalisierung Quelle: eigene Grafik, [Pap09]

13 Agile (extreme Programming) Kritikpunkte: Nur für Projektteams <= 10 Entwickler geeignet Qualitätsverlust durch geringere Formalisierung Effizienzeinbußen durch geringere Formalisierung Aufgrund geringer Dokumentation geht Wissen verloren Risiko änderungsfreundliche Architektur Vertraglich schwer fassbar

14 Agile (extreme Programming) Rechtliche Problematik bei Vertragsverhandlungen: Ein XP Kunde erwirbt keinen Plan, sondern ein lauffähiges Produkt ungewissen Umfangs zu einem definierten Termin. [CsHaSt01]

15 Herkömmlich agil Herkömmliche Vorgehensmodelle Agile Methoden Phasen, Dokumentation Kurze Releasezyklen, Flexibilität, direkte Kommunikation Herkömmlich agil: OpenUP Quelle: eigene Grafik

16 Open Unified Process (OpenUP) Quelle: [OUP09]

17 OpenUP Spezifikation vor Umsetzung, aber Änderungen erlaubt Kurze Releasezyklen inkl. ausführbare Software Direkte Kommunikation basierend auf einer angemessenen Anzahl Dokumente Selbstorganisiertes Team

18 OpenUP Geringere Formalisierung Modell RUP (large) RUP (small) OpenUP XP Rollen > Artefakte Quelle: [RUP06], [OUP09]

19 Resümee WF UP OpenUP Agil Antrieb planorientiert planorientiert planorientiert und flexibel flexibel Formalisierung hoch hoch niedrig niedrig Vorgehen sequentiell iterativ iterativ iterativ Team 10 beliebig 10 beliebig < = 10 < = 10 Analyse und Spezifikation Gesamtspezifikation vor Umsetzung Großteil der Spezifikation vor Umsetzung Spezifikation und Umsetzung inkrementell Spezifikation und Umsetzung inkrementell Quelle: eigene Grafik

20 Resümee Reine Agilität ist nicht immer einsetzbar, jeweilige Vorgehensweise ist stark projektabhängig Herkömmliche Methoden oftmals zu bürokratisch, vor allem für kleinere Entwicklerteams Mischformen sind eine risikoärmere Alternative zu streng agilen Vorgehensweisen

21 Quellen [AlCo09] [AgMa09] [ChEb08] [CsHaSt01] [JaBoRu99] Alistair Cockburn, Crystal methodologies, er, Stand: Kent et al: The Agile Manifesto, Stand: Christof Ebert: Systematisches Requirements Engineering und Management, dpunkt Verlag, 2008 C. Csallner et al.: Fachstudie zum Einsatz von XP bei sd&m, Universität Stuttgart, 2001 Jacob et al: The Unified Software Development Process, Addison Wesley, 1999

22 Quellen [OUP09] [Pap09] [RUP06] [SCRU09] [Stand07] Eclipse Foundation: Open Unified Process, Stand: Papierstapel: Internetseite des Deutschen Bundestags, p/index.html IBM, Rational Unified Process, Version 7.0.1, 2006 Eclipse Foundation: SCRUM, Stand: Standish Group, Chaos Reports: Stand:

23 Quellen [VMXT09] [XP09] Der Beauftragte der Bundesregierung für Informationstechnik, modell xt.de Eclipse Foundation: extreme Programming, Stand:

24 Fragen? Vielen Dank für die Aufmerksamkeit!