Deutsche Gesellschaft für Recht und Informatik e.V. - DGRI ......RAin Elke Bischof FAin für...

1RAin Elke Bischof FAin für IT-Recht - SSW

DGRI Fachausschuss-Sitzung VertragsrechtRechtlichen Anforderungen an Verträge über die agile

Ausgestaltung von Softwareerstellungsprojekten

Rechtsanwältin Elke Bischof, Fachanwältin für IT‐Recht ‐ SSW

München, 15. April 2016


Agenda

1

4 Beispiele

Ausgangslage

2

3 Agiles Vorgehen bei der öffentlichen Hand

Notwendige vertragliche Regelungen

15.04.2016

Vertragsgestaltung: AGB versus Individualverträge

- Ziel der Vertragsgestaltung: Rechtssicherheit und gute Handhabbarkeit in der Praxis

- Maßstab für AGB: Inhaltskontrolle nach §§ 305 ff. BGB

Vermeidung „unangemessener Benachteiligung“ i.S.d. § 307 Abs. 1, Abs. 2 BGB

Maßstab: Wesentliche Grundgedanken der jeweiligen gesetzlichen Regelungen müssen beachtet werden, § 307 Abs. 2 Nr. 1 BGB

Einschlägige bzw. empfehlenswerte Vertragstypologie bei agilen Projektmethoden jedoch umstritten bzw. von unterschiedlichen Interessenlagen der Vertragspartner geprägt:

Werkvertrag?, Dienstvertrag?, ARGE?

15.04.2016 3RAin Elke Bischof FAin für IT-Recht - SSW

„Leitlinien“ für die Vertragsgestaltung- Welcher Vertragstyp als Leitlinie der Vertrags-/AGB-Gestaltung?

- Auftraggebersicht: Werkvertragliche Gestaltung und Festpreis

- Argument: Messbare Leistung und klare Preisgestaltung; aber:

- Kein Leistungsbeschreibung vorhanden was ist der werkvertragliche Erfolg? = Risiko AN

- Stete Änderungen sind Prinzip und nicht Ausnahme: Festpreis nicht kalkulierbar = Risiko AN

- Auftragnehmersicht: Dienstvertragliche Gestaltung, Vergütung nach Aufwand

- Argument: (ua.) agiles Vorgehen fordert wenig vertragliche Regulierung

- Leistung und Verfügung sind offen = Risiko für AG

- ARGE = §§ 705 ff BGB: in aller Regel weder von AG noch AN gewollt

- Lösung?15.04.2016 4RAin Elke Bischof FAin für IT-Recht - SSW

Werkvertrag / § 651 BGB:

Software als bewegliche Sache ? zwei Alternativen:

1. Alternative: § 651 BGB findet keine Anwendung, wenn nicht die Erstellung der Sache im Vordergrund steht, sondern ein über die Erstellung hinausgehender Erfolg. Bei Konstruktion einer neuen Maschine wäre dies etwa die geistige Planungsleistung. Bei Software wäre der im Vordergrund stehende Erfolg die „Problemlösung“. Zumindest bei der Herstellung von Individualsoftware käme dann nicht § 651 BGB, sondern reines Werkvertragsrecht zum Zuge.

2. Alternative: § 651 BGB ist bei Software nicht anwendbar, wenn Software keine bewegliche Sache ist. Was gilt dann? Reines Werkvertragsrecht? Aber: § 643a Abs. 1 Nr. 1 BGB (2 Jahre Verjährung ab Abnahme) nicht anwendbar, sondern § 634 Abs. 1 Nr. 3 BGB (3 Jahre ab Jahresende und Kenntnis)!

BGH v. 23.07.2009 - VII ZR 151/08, CR 2009, 637 - Silo-Anlage BGH v. 9.2.2010 - X ZR 82/07 – Tiefladesattelaufleger OLG München v. 23.12.2009, CR 2010, 156, 157


Werkvertrag / § 651 BGB

Gerade unter Berücksichtigung der vorstehend genannten Siloanlagen-Entscheidung des BGH lässt sich eine werkvertragliche Einordung bei agilem Vorgehen wohl gut begründen, denn:

•Relevanz des Planungsanteils am Gesamtprojekt: Schwerpunkt des jeweiligen Vertrags

•Planungsleistungen (wie Erstellung von Anforderungsprofilen, Anwendung besonderer Programmiertechniken, Projektsteuerung uä.) sind bei agilen Projektmethoden integraler Bestandteil des gesamten Entwicklungsprozesses:

• Anforderungen können sich laufend ändern, damit auch die Entwicklung Planung als zentrale Herausforderung und Schwerpunkt


Werkvertrag: Erfolgsverantwortung?

Wesentliche Voraussetzung für eine werkvertragliche Gestaltung:

- „geschuldeter Erfolg“ = Zielsetzung des Projekts = funktionsfähiges IT-System, funktionale Beschreibungen (all dies gibt es auch bei den agilen Vorgehensmodellen): ausreichend für einen werkvertraglich geschuldeten Erfolg; zudem wie vorstehend dargestellt Planungsleistungen!

- Den werkvertraglichen Erfolg kann aber nur derjenige schulden, der auch die Projektverantwortung und –steuerung innehat.

Je mehr der Auftraggeber in die Verantwortung einbezogen wird bzw. sichselbst in verantwortlichen Rollen sieht bzw. solche verantwortlichenRollen übernimmt (v.a. Product Owner bei Scrum), desto weniger kann derAuftragnehmer einen werkvertraglichen Erfolg schulden Dienstvertrag!

7RAin Elke Bischof FAin für IT-Recht - SSW15.04.2016


Agenda

1

4 Beispiele

Ausgangslage

2



15.04.2016

Was muss bei Werkvertrag geregelt werden?

Wesentliche Regelungsbereiche bei werkvertraglicher Einordnung:

• Vertragsgegenstand: Bezeichnung / Beschreibung der Software(zumindest nach Kernfunktionalitäten, Designanforderungen und dem mitder SW vom AG verfolgten Zweck);

• Zusammenarbeit: Festschreiben des Verfahrens agiler SW-Erstellung nebst anzuwendender Methoden, zu beachtender Werte oder Prinzipien, insbes. im Umgang der Beteiligen miteinander; Lenkungsausschuss, (De-) Eskalation

• Projektplan/Verantwortlichkeiten• Art und Umfang der Dokumentation, insb. bei ausdrücklichem Verzicht

auf eine solche (AGB-rechtlich allerdings bedenklich; Individualvereinbarung!)

• Mitwirkungspflichten des AG (Art, Dauer, Häufigkeit und Umfang Projektplan)


Was muss bei Werkvertrag geregelt werden?

Wesentliche Regelungsbereiche bei werkvertraglicher Einordnung:

•CR-Verfahren; Risikoverteilung bei nicht realisierbaren Funktionalitäten / Designanforderungen, Haftung des AN und Ausstiegsmöglichkeiten des AG•Freigabe/Abnahme (Maßstab, Teil- und Gesamtabnahmen (?), Testszenarien/-kriterien)•Vergütung, Verfahren für etwaige Erhöhungen •Laufzeit, Kündigung, Folgen•Sach-/Rechtsmängelhaftung; Schadensersatz


Dienstvertragliche Einordnung?

• Risikoverteilung zu Lasten des AG

• Projektverantwortung (und damit Risiko für Fertigstellung der Software) beim AG: AG ist für die gewählte Ausführungsart und Projekterfolg selbst verantwortlich

• In der Praxis wohl sinnvoll nur möglich, wenn der AG selbst über die entsprechende IT-Expertise verfügt und diese Verantwortung auch wirklich übernehmen kann und will.


Dienstvertragliche Einordnung?

Was ist zu regeln?

- Kein klassisches Gewährleistungsrecht, sondern Haftung aus §§ 280 ff. BGB

- Zumindest kurzfristige Lösungsrechte des Auftraggebers vorzusehen, wenn „es nicht (mehr) läuft“: Kurze Kündigungsfristen, Vergütung der erbrachten Leistungen (ohne Abzüge) für Auftragnehmer

- Incentivierung eines „Projekterfolgs“ durch variablen, erhöhten Vergütungsanteil (birgt aber ggf. Risiko der werkvertraglichen Einordnung und AGB-Kontrolle nach Werkvertrag statt Dienstvertrag wegen der erfolgsorientierten Vergütung)


Der typengemischte Vertrag

Im Hinblick auf „agile Softwareentwicklung“, bei der der gemeinsamenPlanung sowie der gemeinsamen Ausführung in parallelenLeistungssträngen sowie auch gemeinsamer Kontrolle eine besondereBedeutung zukommen, wird man ggf. einen gemischten Vertrag aufgrunddieser parallelisierten Leistungsstränge annehmen können.

(1)PLANUNG/ Ausführung in Pairs/ Kontrolle gemeinsam

(2)PLANUNG….

(3)PLANUNG …....

Dann stellt sich die bei gemischten Verträgen stets aber wieder die zuberücksichtigende Frage:

Überwiegt Werk- oder Dienstvertrag?


Vertragsgestaltung: notwendige Regelungen

Vereinbarung grundsätzlicher Regelungen für insb. folgende Bereiche empfehlenswert:

• Verfahrensgegenstand:

• Die Frage nach dem „was soll erreicht werden“, „was ist das Vertragsziel“, sollte ungeachtet der iterativen Vorgehensweise möglichst genau beantwortet werden.

• Der Vertragsgegenstand ist im Laufe des Projektes ggfls. an geänderte Vereinbarungen der Parteien anzupassen.

• Verfahrensgrundsätze: Änderungen bzgl. Zeit/Scope/Budget sind typisch und gewollt.

• Verfahren der und zur Zusammenarbeit

• Einsatz von Personal (inkl. Verantwortlichkeiten, Gewährleistung von Kontinuität und Verlässlichkeit; sollte für beide Vertragspartner gelten)




Die Vorgehensweise im Projekt wird nicht nur durch das vereinbarte Vorgehensmodell bestimmt.

Gegenstand der Projektsteuerung sind u.a.

regelmäßige Inspektionspunkte für den Auftraggeber am Start und am Ende von Iterationen, Fertigungsstufen usw.,

Bewertung von Inspektionspunkten, d.h. Bestimmung der Folgen, die sich aus Terminüberschreitungen ergeben, insbesondere wenn hierdurch das Erreichen eines nach dem Kalender bestimmten Vertragserfolges gefährdet ist,

die Bestimmung des Eskalationspfads,

klare und umsetzbare Regelungen über Aufgaben, Kompetenzen und Verantwortungen.




Aufgaben (Mitwirkung?) des Auftraggebers:

die dauernde Interaktion mit dem Auftragnehmer hinsichtlich fachlicher Vorgaben und Abstimmung über das weitere Vorgehen, aktive Beteiligung an Zwischentests und Maßnahmen zur

Qualitätssicherung, Bewertung, Freigabe oder Abnahme von Zwischenresultaten, Information des Auftragnehmers über Änderungen von Normen oder

technischen Gegebenheiten in seiner Sphäre, die Grundlage für die Leistung sind, das Vertragsmanagement.

In Abhängigkeit von Art und Umfang der Mitwirkungsleistungen können diese ggfls. nicht mehr als Nebenpflichten eingestuft werden.




Aufgaben des Auftragnehmers:

die verantwortliche Projektsteuerung,

die Erbringung der vereinbarten Leistungen unter Anwendung vereinbarter Methoden und Techniken agiler Softwareentwicklung zu den vereinbarten Terminen in der vereinbarten Qualität,

die Dokumentation der Leistungen dergestalt, dass auch bei einem eventuellen Scheitern des Projektes ein Dritter, dem hierfür die erforderlichen Rechte eingeräumt werden, die Leistung abschließen kann,

die Information des Auftraggebers über im Projektverlauf auftretende Probleme und / oder Schwachstellen in dessen Vorgaben, verbunden mit Lösungsvorschlägen.




Vorbereitung und Durchführung von Tests mit verbindliche Regelungen u.a. hinsichtlich der Zuständigkeiten und der Verantwortungen für

die Erstellung von Testfällen, Teststrategien, Testabläufen unter Einsatz von Tools, die maschinell ausführbare, automatisierte Tests ermöglich,

die gegenseitige Verwendung von Skripten, die von derartigen Tools erstellt werden,

die Reaktion auf Mängel, die im Testverlauf auftreten,

Art, Form, Zeitpunkte und Bedeutung von Testabläufen in Abhängigkeit vom Bestimmungszweck.




• Regelmäßigkeit sowie Transparenz von Informationsaustausch, Zwischenberichten (und ggf. Teilabnahmen)

• Vergütungsmodell, z.B. Splittung wie folgt:

– periodische Vergütung zur Deckung eines bestimmten Minimums an Aufwand auf Seiten des Auftragnehmers für eine bestimmte Zeit (etwa unterstellt eine 4-Tage-Arbeitswoche für x Mitarbeiter für vier oder acht Wochen als Iterations-Phase und anschließend drei Tage Workshop oder Planungs-Meeting o. ä.).

– weiterer, zusätzlicher Teil-Betrag bzw. weitere zusätzliche Zahlung für die Erreichung derjeweiligen Iterations-Planziele

– weiterer Betrag (oder auch eine Berechnungsmethode), der nur dann zu zahlen ist und fälligwird, wenn eine Abnahme/Gesamt-/Endabnahme erfolgreich stattgefunden hat.




• Sach- und Rechtsmängelhaftung (bei Ziel Werkvertrag)

AN übernimmt Sach- und Rechtsmängelhaftung sowohl für das gesamte Werk als auch für Zwischenergebnisse, die vom Auftraggeber bereits vorher produktiv genutzt werden, wenn und soweit der Auftraggeber hierfür die Abnahme erklärt hat.

Werden teilabnahmefähige Leistungen vereinbart, die produktiv genutzt werden können, so sind hinsichtlich der Abnahme des gesamten Werkes besondere Vereinbarungen erforderlich über den Abschlusstest vor der Abnahme des gesamten Werkes und hinsichtlich der Sach- und Rechtsmängelhaftung für diese Teilabnahmen.

Werden Zwischenresultate abgenommen, ohne dass diese anschließend produktiv genutzt werden können, bedarf es ebenfalls einer Vereinbarung über Art und Umfang sowie die Behandlung von Mängeln für die der Abnahme vorausgehenden Tests und den Abschlusstest vor der Abnahme des Werkes.


Ggf. erwägenswerte Gestaltungsmodell

• Rahmenvertrag + Einzelverträge:

• ermöglicht flexible vertragstypologische Bewertung in den jeweiligen Einzelverträgen: werk- und dienstvertragliche Einzelverträge

• Rahmenvertrag neutral gestaltet mit den jeweils übergeordneten Regelungen, v.a. Regelungen zur Zusammenarbeit.

• Generelle Kritik: Praxisfern und ungeeignet für agile Methoden;

• Kritik im Zusammenhang mit Scrum: Weder Sprint Backlog noch Product Backlog sind als Lasten-/Pflichtenhefts (mangels abschließend beschreibbarem Teilerfolgs) geeignet, damit fehlt die Grundlage für „Mini-Werkverträge“ pro Sprint.

• Grundsätzlich: modulare Vorgehensweise bei vorheriger Verständigung auf einen Aktivitäten- und Fristenplan, der als Orientierung dient.



Agenda

1

4 Beispiele

Ausgangslage

2



15.04.2016

Agiles Vorgehen bei Projekten der öffentlichen Hand?


EVB-IT

4/2016

Systemlieferung

DienstleistungPflege

Standard-SW (2.0)

Instandhaltung

SW-ÜberlassungTyp A (2.0)

SW-Überlassung

Typ B

System

(2.0)

Kauf (2.0)

SW-Überlassung Typ A: zeitlich unbefristet

SW-Überlassung Typ B: zeitlich befristet

Erstellung

Service


SW-Überlassung Typ A: zeitlich unbefristet

SW-Überlassung Typ B: zeitlich befristet

15.04.2016 RAin Elke Bischof FAin für IT-Recht - SSW 24



EVB-IT Erstellung – Vertragswerk

EVB-IT Erstellung(AGB)

EVB-IT Erstellung(AGB)

Muster 3: Änderungsverfahren

Muster 3: Änderungsverfahren

EVB-IT Erstellungsvertrag

EVB-IT Erstellungsvertrag

Muster 4: Nutzungsrechtsmatrix

Muster 4: Nutzungsrechtsmatrix

Muster 1:Störungsmelde-

formular

Muster 1:Störungsmelde-

formular

Muster 2: Leistungsnachweis

Muster 2: Leistungsnachweis

INDIVIDUELLE ERGÄNZUNGEN!

INDIVIDUELLE ERGÄNZUNGEN!

Agiles Vorgehen bei Projekten der öffentlichen Hand?Ergänzende Vereinbarungen zur agilen Vorgehensweise

1. Grundsätze, z.B.

• Maximale Kostentransparenz für die Parteien• Maximale Preissicherheit für den Auftraggeber• Permanente kommerzielle und technische Kontrolle des

Vertragsfortschritts durch beide Parteien• Klare Prinzipien, nach denen das Projekt durchgeführt wird, und eine klare

Projektversion als Darstellung des Projektziels• Partnerschaftliche Zusammenarbeit der Projektteams• Maximale Flexibilität bei der Realisierung des Projekts



2. Definitionen, z.B.– User Story

– Projektversion

– Sprints

– Gutfall

– Schlechtfall

3. Mitwirkungsleistungen des Auftraggebers aufgrund des agilen Vorgehens

Besondere Bedeutung bei agilem Vorgehen!

4. Vorgehen | Mechanismus | Zeiträume

Festlegung der Umsetzung der Anforderungen an die zu erstellende Software im Sinne eines agilen Vorgehensmodells in definiertem Zeiträumen.

Regelung zum Exchange-for-free15.04.2016 28RAin Elke Bischof FAin für IT-Recht - SSW


5. Transparenz Dokumentation des Projekts (z.B./mind. im/als Pflichtenheft) und des Source

Codes zur jederzeitigen Nachvollziehbarkeit seitens des öAG

Reporting

etc.

6. Abnahme

7. Teilabnahmen

8. Kommunikation | Eskalation



9. Gewährleistung | Verjährung (auch i.V.m. (Teil-) Abnahmen)

10. Festpreis | Teilzahlungen | Zahlungsweise

Inkl. Vergütung nebst Regelungen über ggf. erforderliche Erhöhung bei bestimmten Änderungsanforderungen, die über den Vertragszweck hinausgehen oder nach Ablauf der vereinbarten Fristen geltend gemacht werden.

Z.B. geknüpft an abgenommene Sprints mit X realisierten User Stories – i.H.v. z.B. 80% der Gesamtvergütung hierfür.



Vergütungsmodelle:I.) Festpreisvertrag mit ErfolgsverantwortungFestpreis, aufgeteilt auf einzelne SW-Module bzw. –Funktionalitäten

hinterlegt mit Aufwandsschätzungen

daraus abgeleitete Preiseinheiten

CR-Verfahren für Leistungsänderungen.

Ggf. bei Überschreitung reduzierte Stundensätze (z.B. – 50%), außer für geänderte Anforderungen

II.) Dienstleistung nach Aufwand ohne ErfolgsverantwortungArbeiten/Abrechnung nach Aufwand gem. Stundensätzen

„enges“ Controlling durch öAG

Reduzierte Stundensätze für Korrekturarbeiten



Vergütungsmodelle:III.) Dienstleistung mit monetärer Obergrenze (ähnlich EVB-IT

Dienstleistung) und Erfolgsverantwortung

Abrechnung nach Aufwand, aber

zulasten des AN gedeckelt durch Obergrenze (Maximalpreis)

ODER bei Überschreitung reduzierte Stundensätze (z.B. – 50%), außer für geänderte Anforderungen

UND ggf. Effizienzbonus

Bsp.: 50% der Differenz zwischen finalem Maximalpreis und tatsächlichem Preis als Zahlung an AN



Vergütungsmodelle: zu Festpreisvereinbarung:Nach Opelt/Gloger/Pfarl/Mittermayr „Der agile Festpreis“, Hanser - Verlag

I. Beschreibung der Komplexität durch Klassen

– Klassifizierung von User Stories, z.B. in „komplex“, „mittel“ und „einfach“ sowie nach Umfang.

– Daran anknüpfend Einordnung auch späterer Änderungen.

II. Beschreibung der Komplexität durch Punkte

– Auf Basis von Komplexitätspunkten für User Stories (Storypoints).

– 1 Storypoint wird mit einem €-Betrag hinterlegt.

– Spätere neue User Stories werden entsprechend „bewertet“.


Fazit

Agilität braucht Freiraum.

Vertragspartner brauchen Rechtssicherheit, Planbarkeit und klare juristische Vereinbarungen.

Schaffung einer soliden, belastbaren rechtlichen Basis und eines verlässlichen, positiven Klimas der Zusammenarbeit.

Dies unter einen Hut zu bekommen, ist die juristische Herausforderung, die sich bei vielen modernen Projektmethoden stellt.

AGB erscheinen meist nicht als der passende Weg.

Individualvertragliche Gestaltung vorzuziehen, wobei ein Kompromiss zwischen den widerstreitenden Interessen der Vertragspartner zu finden sein wird.

hohe Anforderungen an Transparenz und Ausgewogenheit, denn:

Flexibilität bei gleichzeitiger Minimierung von Dokumentationspflichten ist Kernmerkmal bei vielen modernen Projektmethoden und könnte zu Unübersichtlichkeit führen >> hierfür sollten die Vertragsparteien sensibilisiert sein und potentielle Konfliktpunkte möglichst im Vorfeld entschärfen.



SSW Schneider Schiffer WeihermüllerRechtsanwälte Steuerberater Wirtschaftsprüfer

Beethovenstraße 6 80336 München Tel. 089/54349‐100 Fax 089/54349‐111

Mail: elke.bischof@ssw‐muc.de Homepage: www.ssw‐muc.de

15.04.2016

Deutsche Gesellschaft für Recht und Informatik e.V. - DGRI ......RAin Elke Bischof FAin für...

Documents

Transcript of Deutsche Gesellschaft für Recht und Informatik e.V. - DGRI ......RAin Elke Bischof FAin für...