[vc_row][vc_column][vc_custom_heading text=“Auf den Vertrag kommt es an“ font_container=“tag:h2|font_size:38|text_align:left|color:%23e30613″ use_theme_fonts=“yes“ css=“.vc_custom_1576053475725{margin-top: -25px !important;}“][vc_custom_heading text=“Haftung bei agiler Softwareentwicklung“ font_container=“tag:h2|font_size:22|text_align:left|color:%23f07d00″ use_theme_fonts=“yes“ css=“.vc_custom_1576053499807{padding-bottom: 10px !important;}“][vc_column_text]Anne Allar, Benjamin Raue, Universität Trier[/vc_column_text][vc_custom_heading text=“Kurz und bündig:“ font_container=“tag:h3|font_size:17|text_align:left|color:%23ffffff“ use_theme_fonts=“yes“ css=“.vc_custom_1519747666609{padding-left: 15px !important;background-color: #f07d00 !important;}“][vc_column_text css=“.vc_custom_1576053977234{border-top-width: 1px !important;border-right-width: 1px !important;border-bottom-width: 1px !important;border-left-width: 1px !important;padding-top: 10px !important;padding-right: 10px !important;padding-bottom: 10px !important;padding-left: 10px !important;background-color: #eaeaea !important;border-left-color: #aaaaaa !important;border-left-style: solid !important;border-right-color: #aaaaaa !important;border-right-style: solid !important;border-top-color: #aaaaaa !important;border-top-style: solid !important;border-bottom-color: #aaaaaa !important;border-bottom-style: solid !important;border-radius: 1px !important;}“]Agile Softwareentwicklung zeichnet sich durch einen flexiblen Entwicklungsprozess aus. Der komplexe Erstellungsvorgang wird in mehrere kleine Abschnitte unterteilt. Entstehende Fehler sollen im Verlaufe der weiteren Entwicklung behoben werden. Doch wie ist bei einer solchen flexiblen Entwicklung die Haftung geregelt? Das Kernproblem liegt in der vertraglichen Einordnung. Bei einem Dienstvertrag muss der Softwareentwickler nur tätig werden, beim Werkvertrag erfolgreich, sonst muss er nachbessern oder bekommt weniger Geld.[/vc_column_text][/vc_column][/vc_row][vc_row css=“.vc_custom_1519752670572{margin-top: -10px !important;}“][vc_column][vc_column_text]Software wird heute flexibel und agil entwickelt – und nicht mehr durch das Abarbeiten handbuchartiger Vorgaben. Dieses neue Vorgehen ist geprägt durch den schnellen technischen Wandel. Wenn es zu Streit zwischen den Beteiligten kommt, stellt sich aber die Frage: Lassen sich die auftretenden Haftungsprobleme noch mit unserem Bürgerlichen Gesetzbuch aus dem Jahre 1896 lösen? Das BGB kennt keinen Softwareentwicklungsvertrag, geschweige denn einen agilen. Es kommt daher entscheidend darauf an, was Auftraggeber und Softwareentwickler vereinbart haben. [/vc_column_text][ult_dualbutton btn_hover_style=“Style 2″ btn_border_style=“solid“ btn_color_border=“#ffffff“ btn_border_size=“2″ btn_alignment=“left“ dual_resp=“off“ button1_text=“Einzelheft kaufen“ icon_link=“url:https%3A%2F%2Fwww.aws-institut.de%2Fim-io%2Fproduct%2Fqualitaet-4-0%2F|title:Qualit%C3%A4t%204.0||“ btn1_background_color=“#f07d00″ btn1_bghovercolor=“#e30613″ icon=“Defaults-book“ icon_size=“22″ icon_color=“#ffffff“ icon_hover_color=“#f07d00″ button2_text=“Jetzt abonnieren“ btn_icon_link=“url:https%3A%2F%2Fwww.aws-institut.de%2Fim-io%2Fabo%2F|title:Abo||“ btn2_background_color=“#f07d00″ btn2_bghovercolor=“#e30613″ btn_icon=“Defaults-chevron-right“ btn_icon_size=“22″ btn_icon_color=“#ffffff“ btn_iconhover_color=“#f07d00″ divider_text=“oder“ divider_text_color=“#f07d00″ divider_bg_color=“#ffffff“ btn1_text_color=“#ffffff“ btn1_text_hovercolor=“#ffffff“ btn2_text_color=“#ffffff“ btn2_text_hovercolor=“#ffffff“ title_font_size=“desktop:20px;“ btn_border_radius=“3″ title_line_ht=“desktop:22px;“ btn_width=“280″][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]Die Entwicklung einer Software ist komplex, langwierig und kompliziert. Früher war der Prozess oft langsam und schwerfällig. Bevor die eigentliche Entwicklung gestartet werden konnte, wurde zunächst ein Pflichtenheft entworfen. In diesem wurde (im Idealfall) minutiös festgehalten, welche Leistung der Softwareentwickler konkret bis wann erbringen musste, um das Projektziel (also eine lauffähige Softwarelösung) zu erreichen. Schon dieser erste vorläufige Schritt zog sich meistens über Wochen und Monate, manchmal über Jahre. Sehr viel Kraft und Ressourcen wurden in diese erste Projektphase gesteckt. Konnte endlich mit der eigentlichen Arbeit begonnen werden, stellte sich das Pflichtenheft trotz der investierten Zeit oft als unzureichend oder fehlerhaft heraus. Erneute Verzögerungen oder gar der Abbruch der Softwareentwicklung waren die unerwünschte Folge. Dieses behäbige Vorgehen passt nicht mehr in die moderne Welt. Sie zeichnet sich durch Schnelllebigkeit, Flexibilität und ständigen technischen und digitalen Fortschritt aus. Vor allem die Softwareentwicklung musste also flexibler, dynamischer und interaktiver werden – „Softwareentwicklung 4.0“. Aus diesem Grund haben sich in den vergangenen Jahren zunehmend agile Projektmethoden durchgesetzt. Doch wie soll die Software des 21. Jahrhunderts mit den Regeln des Bürgerlichen Gesetzbuchs (BGB) aus dem Jahre 1896 in Einklang gebracht werden? Juristen liebten die alten Pflichtenhefte – je präziser, desto besser. Funktionierte etwas nicht, konnte der Soll- (Pflichtenheft) mit dem Ist-Zustand (fertiggestellte Software) verglichen werden. Und nun? Was ist der geschuldete Soll-Zustand?[/vc_column_text][vc_custom_heading text=“Was ist agile Software?“ font_container=“tag:h3|text_align:left“][vc_column_text]Die wohl gängigste agile Projektmethode ist Scrum. Bei Scrum wird in einem interdisziplinären Team ein einheitlicher, komplexer Entwicklungsprozess in mehrere kleine Zyklen von je ca. 30 Tagen Länge (sogenannte Sprints) aufgeteilt. Am Ende der einzelnen Sprints steht jeweils ein betriebsfähiges und selbstständig nutzbares Teilprodukt der Software. So werden in der Softwareentwicklung bereits frühzeitig funktionstüchtige Zwischenergebnisse erzielt. Eine genaue, allgemeingültige Definition agiler Softwareentwicklung gibt es hingegen nicht. Im weitesten Sinne versteht man darunter einen Prozess, in dem der Fortschritt steten Änderungen ausgesetzt und die weitere Entwicklung deshalb nicht von vornherein absehbar ist. So bleibt der Entwicklungsprozess flexibel. Pflichtenhefte im klassischen Sinne existieren nicht mehr. Vielmehr entwickelt sich die Leistungsbeschreibung und damit die Zielerreichung dynamisch zum Fortschritt der Software. Im Gegensatz zur klassischen Vorgehensweise stehen spezifische Ziele nicht schon bei Projektbeginn abschließend fest. Die Entwicklung der Software sowie die Konkretisierung des angestrebten Ergebnisses werden bei agilen Methoden also parallel realisiert. Somit zeichnet sich das genaue Projekt-Ergebnis erst am Ende des gesamten Prozesses ab. Agile Entwicklung verzichtet (weitgehend) auf eine zeitlich vorgeschaltete Planungsphase. Vor- und Nachteile der agilen Softwareentwicklung. Durch den weitgehenden Wegfall der vorgeschalteten Planungsphase müssen präzise Anforderungsbeschreibungen nicht bereits zu Projektbeginn vorliegen. Die dafür benötigten Ressourcen werden bei der agilen Methode von Anfang an produktiv in die Umsetzung der Softwareerstellung investiert. Das führt zu frühen Ergebnissen und schnellen ersten, bereits funktionsfähigen Softwareversionen. Im Gegenzug ist der Auftraggeber in den Entwicklungsprozess stark eingebunden. Die Anforderungen müssen ständig neu ausgearbeitet, und die entstehenden Zwischenergebnisse laufend kontrolliert werden. Dadurch kann der Kunde das Projekt mitleiten und nach seinen Vorstellungen und Wünschen Einfluss nehmen.Trotzdem erwartet der Kunde vom Softwareentwickler Erfolgsverantwortung sowie Planungs- und Kostensicherheit. Solche Kalkulationen sind ohne Pflichtenheft (und damit ohne feststehende Leistungsbeschreibung) schwierig bis unmöglich. Hierin liegt auch die Herausforderung auf juristischer Ebene. Die widersprüchliche Interessenlage macht eine klare rechtliche Beurteilung komplex. Auch passt die Flexibilität der agilen Methoden nur eingeschränkt zur strukturierten Denk- und Vorgehensweise eines Juristen. Ein Umdenken ist auch dort gefordert.

[/vc_column_text][vc_custom_heading text=“Vertragstypologische Einordnung“ font_container=“tag:h3|text_align:left“][vc_column_text]Bedeutung

Früher wurden Softwareentwicklungsverträge als Werkverträge eingeordnet. [1] Der Entwickler musste das verabredete Ergebnis garantieren und abweichende Ergebnisse später beheben. Weil heute bei Vertragsschluss ein solches Ergebnis noch nicht klar definiert ist, streiten Juristen darüber, ob eine solche Erfolgshaftung auch bei agilen Methoden gerechtfertigt ist. [2] Diese Einordnung ist an verschiedenen Stellen von großer Bedeutung, etwa bei der Wirksamkeit von Allgemeinen Geschäftsbedingungen nach §§ 305 ff. BGB oder für Gewährleistungsrechte mit ihren jeweiligen Verjährungsfristen und Kündigungsregelungen. Ausschlaggebend für die vertragliche Einordnung ist die Risikoverteilung. Beim Dienstvertrag kommt es im Gegensatz zum Werkvertrag nicht auf den Erfolg der Tätigkeit an: das bloße Tätigwerden reicht aus. Folglich trägt beim Dienstvertrag der Auftraggeber das Erfolgsrisiko.

Einordnung

Für die Einordnung maßgeblich ist, was die Parteien bei Vertragsschluss vereinbaren. [3] Manche Juristen ordnen die agile Entwicklung von Software als Dienstvertrag ein, weil dem Entwickler nur noch zugemutet werden kann, qualifiziert tätig zu werden. [4] Weil er bei Vertragsschluss nicht wisse, was er schulde, könne er mehr auch nicht garantieren. Ein reiner Dienstvertrag wird aber im Regelfall dem Interesse des Auftraggebers nicht gerecht. Schließlich investiert dieser viel Zeit, Geld und andere Ressourcen in eine Softwareerstellung und konkretisiert im Laufe des Projekts seine Anforderungen. Am Ende darf er eine lauffähige Software erwarten, die den in der Zwischenzeit konkretisierten Zielen entspricht. Die Programmierarbeit als solche ist lediglich das Mittel zum Zweck. Das spricht für einen Werkvertrag. [5] Auch das Landgericht Wiesbaden geht in den wenigen Gerichtsentscheidungen zu dieser Thematik von einem Werkvertrag aus. [6]Die fehlende Leistungsbestimmung in Form eines zuvor festgelegten Pflichtenhefts macht jedoch auch eine Einordnung als Werkvertrag schwierig. Ein konkreter Leistungsgegenstand gehört zu den notwendigen Bestandteilen eines Werkvertrags, da bei diesem ein Erfolg im Sinne eines Ergebnisses geschuldet ist. Eine skizzierte Zielrichtung zu Projektbeginn ist dafür allerdings grundsätzlich ausreichend. Der Interessenlage am besten gerecht wird jedoch eine Einordnung als typengemischter Vertrag mit dienst- und werkvertraglichen Elementen. [7] Die Planung wird als Leistung eines Rahmen-Dienstvertrags erbracht, in der die einzelnen Sprints als Werkverträge mit Erfolgsverpflichtung eingebettet werden. Weil Vertragsfreiheit herrscht, steht es den Vertragspartner jedoch frei, ihre Rechtsbeziehungen sowie Verantwortungs- und Risikozuordnungen abweichend zu regeln. Im Rahmen von Standardverträgen trifft den Verwender aber eine Transparenzpflicht (§ 307 Abs. 1 BGB). Er darf Regelungen, die für die Vertragseinordnung wichtig sind, nicht im Kleingedruckten verstecken. Darüber hinaus sind überraschende Klauseln nach § 305c BGB unwirksam. Gut beratene Parteien sollten also in transparenter Weise Regelungen treffen und schriftlich festhalten.

 Konsequenz/Rechtsfolge

Haben die Parteien keinen konkreten Leistungserfolg vereinbart, ist Dienstvertragsrecht anwendbar. Dann endet der Vertrag erst bei einem erfolgreichen Abschluss oder einer Kündigung. Auch wenn dabei keine brauchbaren Ergebnisse erzielt werden, muss der Kunde für das (zumindest sorgfältige) Tätigwerden des Entwicklers zahlen. Auf Nachbesserung, Schadensersatz, eine Minderung des Preises (und auf andere Gewährleistungsrechte) hat er keinen Anspruch. Ist der Vertrag nach dem Ausgeführten hingegen als Werkvertrag einzuordnen, muss der Auftragnehmer eine fehlerfreie und voll funktionstüchtige Software zur Verfügung stellen. Der entscheidende Zeitpunkt ist hier die Abnahme. Mit Abnahme der Software bestätigt der Auftraggeber, dass die Software (auf den ersten Blick) den vertraglichen Vereinbarungen entspricht. Erst dann hat der Softwareersteller den Vertrag erfüllt. Stellt der Auftraggeber später Mängel fest, ist der Softwareersteller verpflichtet, diese Fehler kostenfrei zu beheben. Unter bestimmten weiteren Voraussetzungen kann der Auftraggeber auch Schadensersatz verlangen oder sogar vom Vertrag zurücktreten. Im Vergleich hat der Auftraggeber bei einem Werkvertrag deutlich mehr Rechte auf seiner Seite als bei einem Dienstvertrag. Als dritte Möglichkeit kann man den Vertrag als typengemischt einordnen. Die Planung wird hierbei in einem Rahmen-Dienstvertrag und die einzelnen Sprints als Werkverträge eingestuft. Hat der Auftraggeber einen Sprint abgenommen, also als Leistungserfüllung akzeptiert, kann er nach jedem fehlerhaften Sprint Nacherfüllung verlangen oder – unter einschränkenden Bedingungen – vom Vertrag zurücktreten. Durch den flexiblen, kontinuierlichen Entwicklungsprozess wäre es jedoch praxisfern, diese Fehler sofort, also vor Beginn des nächsten Sprints, beheben zu müssen. Schließlich zeichnet sich der flexible Entwicklungsprozess mit den einzelnen Sprints gerade dadurch aus, solche Unwägbarkeiten berücksichtigen und Ausbesserungen im nächsten Sprint vornehmen zu können. Vorzugswürdig erscheint es deshalb, die Gewährleistungsrechte in jedem Fall erst mit Abnahme des letzten Sprints beginnen zu lassen. Die Möglichkeit, für einzelne abgeschlossene Sprints bereits eine Vergütung verlangen zu können, bleibt davon unberührt (vgl. § 632a BGB). Beides sollte zur Klarstellung in einer vertraglichen Vereinbarung ausdrücklich festgehalten werden.

Fazit

Es gibt nach wie vor keine klare Linie für die vertragliche Einordnung von agiler Softwareentwicklung. Auch wenn sie im Normalfall als Werk- oder typengemischter Vertrag mit starken werkvertraglichen Elementen eingeordnet werden sollte, verbietet sich eine pauschale Einordnung. Vielmehr ist hier nach den Gesamtumständen im Einzelfall zu differenzieren und der Vertragsgestaltung sowie dem Willen der Vertragsparteien eine besondere Bedeutung beizumessen. Wichtig ist die Vertragstypologie vor allem im Hinblick auf die Risikoverteilung. Dessen sollten sich die Parteien bei der Vertragsgestaltung bewusst sein und ihre Vorstellungen in klaren Regelungen ausdrücken, um im Haftungsfall keine unerwartete Überraschung zu erleben.[/vc_column_text][vc_single_image image=“15474″ img_size=“medium“ alignment=“center“][/vc_column][/vc_row][vc_row][vc_column][/vc_column][/vc_row][vc_row][vc_column][ult_createlink title=“Zu den Literaturangaben.“ btn_link=“url:https%3A%2F%2Fwww.aws-institut.de%2Fim-io%2Fausgabe-2019-4-316%2F|title:Ausgabe%202019-4-316||“][/vc_column][/vc_row]