Auswahl der Projektmethode

Transkript

1 LMU Ludwig- Maximilians- Universität München Lehr- und Forschungseinheit für Programmierung und Softwaretechnik Juristisches IT-Projektmanagement (Frank Sarre), WS 2014 / 2015 Auswahl der Projektmethode Projektmethoden Einflussgrößen Schwierigkeiten in der Praxis Fazit Martin Plötz Martin Plötz Wintersemester Wintersemester / 2011 / 2015 Folie 1

2 Projektmethoden Allgemein Auch: Vorgehensmodelle Definition von Aufgaben und Verantwortlichkeiten Regelung des konkreten Projektablaufs Vorgehensmodelle sind für den Erfolg eines Softwareerstellungsprojektes zwingend notwendig, da ohne eine Koordinierung der Aktivitäten aller Beteiligten ein Projektüberblick nicht mehr gewährleistet und ein Scheitern des Projektes vorprogrammiert ist [1] Wintersemester 2009 / 2010 Folie 2

3 Projektmethoden Allgemein Modelle gibt es seit den 1950er Jahren Mittlerweile gibt es eine Vielzahl an Modellen Unterscheidung in herkömmliche und agile Methoden Durch die höhere Anzahl an Methoden wird die Chance erhöht, eine passende Methode zu finden aber: Die Auswahl wird dadurch auch deutlich komplexer Wintersemester 2009 / 2010 Folie 3

4 Projektmethoden Herkömmliche Projektmethoden Begriff seit dem Bestehen agiler Methoden Stellvertretend: Wasserfallmodell In Deutschland besonders wichtig: V-Modell XT Wintersemester 2009 / 2010 Folie 4

5 Projektmethoden Wasserfallmodell 1956 erstmals vorgestellt (ursprünglich nur 5 Phasen) [2] Lineares und sequentielles Modell Phasen bauen kaskadierend aufeinander auf Wintersemester 2009 / 2010 Folie 5

6 Projektmethoden V-Modell XT [3] Wintersemester 2009 / 2010 Folie 6

7 Projektmethoden V-Modell XT Militärischer Ursprung Ende der 1980er Jahre Prozesstransparenz und Qualitätssicherung um Vordergrund Klare Definition von Verantwortlichkeiten Basiert auf dem Wasserfallmodell Zwei Revisionen 1997 und 2005 Vorgeschriebener Entwicklungsstandard für IT-Systeme des Bundes für die Planung und Durchführung von IT Projekten [4] Wintersemester 2009 / 2010 Folie 7

8 Projektmethoden Agile Methoden Versuch, die Probleme herkömmlicher Methoden zu minimieren Flexibilität (agil) als Schwerpunkt Erste Ansätze zu Beginn der 1990er Jahre Durchbruch um die Jahrtausendwende (Extreme Programming, 1999) Steigende Popularität Deutliche Überlegenheit bei Projekterfolgen in Studien bestätigt: 64% agile vs. 42% herkömmliche Projekte erfolgreich [5] Meist verbreitetste Methode: Scrum Wintersemester 2009 / 2010 Folie 8

9 Projektmethoden Agiles Manifest Manifest für Agile Softwareentwicklung (2001) 17 Erstunterzeichner, mittlerweile tausende Personen Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. [6] Wintersemester 2009 / 2010 Folie 9

10 Projektmethoden Scrum [7] Wintersemester 2009 / 2010 Folie 10

11 Projektmethoden Scrum Veröffentlicht 2002 Ursprünglich zur Softwareentwicklung, wird mittlerweile auch im allgemeinen Projektmanagement verwendet Eigentlich ein Framework und kein Modell Rein iteratives, inkrementelles Vorgehen Drei Rollen, drei Artefakte und fünf Aktivitäten Stakeholder und früh funktionierende Software im Mittelpunkt Wintersemester 2009 / 2010 Folie 11

12 Projektmethoden Unterschiede / Vergleich Hauptunterschied agiler Methoden: Inkrementell iterativ statt sequentiell linear, dadurch deutlich flexibler V-Modell XT in Deutschland häufig verwendet, mittlerweile auch mit agilen Ansätzen in den Unterprozessen Scrum sehr beliebt da leicht ausprobierbar und sehr anpassungsfähig Kein Modell beschränkt sich auf typische Projektarten, Auswahl einer Projektmethode also nur vom Projekt abhängig Entscheidung komplex und vielschichtig, Risiken und Nutzen kaum vorhersehbar Wintersemester 2009 / 2010 Folie 12

13 Einflussgrößen Einflussgrößen eines Projekts Spezifikation vor Vertragsabschluss Änderungen im Projektverlauf Mitwirkung des Auftraggebers Projektgröße und Zerlegbarkeit des Projekts Kritikalität des Systems Projektdurchführungsgeschwindigkeit Risikoverteilung zwischen den Projektpartnern Entscheidungskompetenzen Vergütung Rechtliche Aspekte (Deutschland) Wintersemester 2009 / 2010 Folie 13

14 Einflussgrößen Spezifikation vor Vertragsabschluss Grad der Spezifikation entscheidend Eventuell Projektunterteilung in Planungsphase und Realisierungsphase Von beiden Parteien durchführbar Oft bewusst an Auftragnehmer vergeben wg. Fachkompetenz Wenn Spezifikation ausreichend fertig und unverändert, sind agile Konzepte unnötig Wintersemester 2009 / 2010 Folie 14

15 Einflussgrößen Änderungen im Projektverlauf In der IT-Branche keine Seltenheit Moving-Target-Effekt Je größer und länger das Projekt, desto wahrscheinlicher dass sich Anforderungen und Ziele verändern Bei herkömmlichen Methoden sind späte Änderungen nicht möglich Agile Methoden sind quasi auf Änderungen ausgelegt Wintersemester 2009 / 2010 Folie 15

16 Einflussgrößen Mitwirkung des Auftraggebers Verteilung von Rollen und Verantwortlichkeiten unterscheiden sich in den Vorgehensmodellen sehr Bei herkömmlichen Methoden leicht strikte Trennung möglich Agile Methoden fordern explizit erhebliche Beteiligung Deutlich höherer Kommunikationsaufwand Entsprechendes eigenes Know-How erforderlich Deutlich mehr Ressourcen müssen ans Projekt gebunden werden Wintersemester 2009 / 2010 Folie 16

17 Einflussgrößen Projektgröße Spielt generell keine große Rolle für die Wahl der Projektmethode Agile Methoden sollten mit kleinen und weniger wichtigen Projekten eingeführt werden, insbesondere bei bestehender Struktur Agile Methoden machen Vorschläge bzgl. der maximalen Teamgröße und empfehlen dann eine Aufteilung in mehrere Teams Daher wichtiger: Zerlegbarkeit Wintersemester 2009 / 2010 Folie 17

18 Einflussgrößen Zerlegbarkeit des Projekts Bei größeren Projekten wichtig, um agil erfolgreich arbeiten zu können, sonst keine inkrementelle Spezifikation möglich Schwierig, wenn Ergebnisse nicht vor der Fertigstellung prüfbar (z.b. embedded systems oder Militär) Fachliche Anforderungen sollten parallel bearbeitbar sein Je höher die Kritikalität, desto schwieriger zerlegbar Wintersemester 2009 / 2010 Folie 18

19 Einflussgrößen Kritikalität des Systems Je kritischer ein Projekt, desto wichtiger ist die Spezifikation Am kritischsten: Abhängigkeit von menschlichem Leben Testen unter Live-Bedingungen oft nicht möglich Entsprechende Branchenstandards (eher sequentiell) Aufsteigende Risikobewertung bei Crystal: Gefährdung der Kundenzufriedenheit Finanzieller Verlust Imageschäden Verlust von Menschenleben Wintersemester 2009 / 2010 Folie 19

20 Einflussgrößen Projektdurchführungsgeschwindigkeit Hängt mehr von Mitwirkungsleistungen und Anforderungen ab als vom Vorgehensmodell Bei Spezifikation vom Auftraggeber können herkömmliche Methoden genauso schnell sein Dokumentation in agilen Projekten weniger wichtig, Grad der Dokumentation wird aber vom Auftraggeber bestimmt Risiko, unnötige Anforderungen (doch nicht mehr benötigt) zu implementieren wird bei agilen Methoden minimiert Bewusster Verzicht auf Qualität zugunsten der Geschwindigkeit mit agilen Methoden leicht möglich Wintersemester 2009 / 2010 Folie 20

21 Einflussgrößen Risikoverteilung zwischen den Projektpartnern Agile Methoden erfordern viel Vertrauen, da Aufwand und Gesamtdauer schwer abgeschätzt werden können Ständige Beteiligung ermöglicht bessere Kontrolle, führt aber in der Schuldfrage bei gescheiterten Projekten zu schlechteren Situationen Risiko durch agile Methoden stärker auf Auftraggeber verlagert, muss bewusst eingegangen werden Agile Methoden am besten mit bereits bekannten Partnern Herkömmliche Methoden lassen Zuständigkeit und Verantwortlichkeit leicht trennen, Erfolgsrisiko kann vollständig auf den Auftragnehmer übertragen werden Wintersemester 2009 / 2010 Folie 21

22 Einflussgrößen Entscheidungskompetenzen Vertrauen auch entscheidend Agiles Manifest fordert: Teammitglieder müssen Entscheidungsbefugnisse haben (technisch, organisatorisch) Management muss Mitarbeiter bevollmächtigen Auftraggeber muss deshalb mehr Entscheidungen dem Auftragnehmer überlassen Je mehr Entscheidungen von den Mitarbeitern getroffen werden können, desto eher kommen agile Methoden in Frage Achtung: Auftraggeber muss evtl. mit entscheiden Wintersemester 2009 / 2010 Folie 22

23 Einflussgrößen Vergütung Unterteilung in Phasen (herkömmlich) ermöglicht einfache Vergütung nach Festpreis (unterteilt oder gesamt) Finanzielles Risiko beim Auftragnehmer, wenn Spezifikation vorhanden und Aufwand abschätzbar Bei Spezifikation im laufenden Projekt -> höheres Risiko (Auftraggeber) Lösungsansätze für agile Methoden: Aufwandsbasierte Modelle mit Vergütungsobergrenze Projektbudget das sukzessive aufgebraucht wird Wintersemester 2009 / 2010 Folie 23

24 Einflussgrößen Rechtliche Aspekte (Deutschland) Zuordnung von Vorgehensmodellen auf Vertragstypen schwierig Herkömmliche Methoden meist Werkvertragsrecht Verstrickung des Auftraggebers bei agilen Methoden erschwert eine Zuordnung Nicht erfolgte Leistungsbeschreibung bei Vertragsabschluss (agil) untypisch für Werkverträge Umfassender Rahmenvertrag empfehlenswert [8] Bisher kaum Rechtsprechung über agile Projekte Agile Projekte ermöglichen effektivere juristische Möglichkeiten, falls z.b. einzelne Iterationen als einzelne Werkverträge bestehen Wintersemester 2009 / 2010 Folie 24

25 Schwierigkeiten in der Praxis Zuordnung in deutsches Vertragsrecht Fähigkeiten und Kenntnisse von Auftraggeber und Auftragnehmer Anpassungsmöglichkeiten bei bestehenden Modellen Standard-Methoden von Auftragnehmern Fehlende Kenntnis beim Auftraggeber Rechtlich vermutlich günstiger für Auftragnehmer Müssen bei komplexen Projekten auch angepasst werden Fehlende Kenntnis beim Auftragnehmer, falls die Projektmethode vom Auftraggeber vorgegeben wird Wintersemester 2009 / 2010 Folie 25

26 Fazit Wahl der Projektmethode zu komplex um sie zu automatisieren, trotzdem von entscheidender Bedeutung Alle Einflussgrößen müssen detailliert betrachtet werden Projektmethoden müssen vertraglich festgehalten werden Persönliche Faktoren und Qualifikationen der Mitarbeiter sind bei allen Projektmethoden entscheidend Schwierigkeiten bei der praktischen Umsetzung agiler Methoden in deutschem Recht Schwierigkeiten bei der Vergütung bei agilen Methoden Wintersemester 2009 / 2010 Folie 26

27 Referenzen [1] Schwartmann, R. (2014). Praxishandbuch Medien-, IT-und Urheberrecht (S. 907f.), Hüthig Jehle Rehm. [2] ( ) [3] a/v-modell.svg/2000px-v-modell.svg.png ( ) [4] ( ) [5] Development- Survey.pdf ( ) [6] ( ) [7] d/scrum_process-de.svg/1280px-scrum_process-de.svg.png ( ) [8] Söbbing, T. (2014). Agile Projekte in der IT-rechtlichen Praxis. Der IT- Rechtsberater. Köln, Verlag Dr. Otto Schmidt: Wintersemester 2009 / 2010 Folie 27