Lodigkeit博士律师事务所坐落于汉堡市中心,紧邻汉堡市政府,专注于商标法、知识产权、IT和媒体法。Lodigkeit律师博士作为专业律师,在这些领域拥有广泛的专业经验。Lodigkeit博士律师最初从事于慕尼黑德国专利商标局, 随后于美国德克萨斯州休斯顿大学法律中心完成信息法硕士和知识产权硕士学业,随即在数座知名的律师事务所任职。Lodigkeit博士于2008年被授予为IT法律和知识产权的专家律师称号,并于2014年起,Lodigkeit博士进而被授予版权和媒体法专家律师称号。Lodigkeit博士于2011年初于德国汉堡创建Lodigkeit律师事务所。 律所地址及联系方式如下: 律所名称:Lodigkeit Rechtsanwälte 地址:Poststr. 25, 20354 Hamburg, Germany 电话:+49 40 3500489-0 (德语、英语 –…
Rechtliche Schwierigkeiten bei der agilen Softwareentwicklung
In der Softwareentwicklung verändern sich nicht nur die technischen Gegebenheiten ständig, sondern auch die Zusammenarbeit zwischen Auftraggeber und Software-Entwickler. Insoweit ist es wichtig einen passenden Vertrag zu vereinbaren.
Gerade wenn es um die Entwicklung von Software für sehr spezielle Aufgaben mit komplexen Inhalten geht, ist häufig eine ausgiebige Planung erforderlich. Klassisch wird dies mit dem „Wasserfall-Modell“ gestaltet, also die stufenweisen Analyse der Kundenwünsche, Planung, Entwurf, Realisierung und Schulung bzw. Nutzung durch den Kunden.
Die Agile Softwareentwicklung
Vielerorts ist den Kunden heute aber auch daran gelegen sich im Laufe der Entwicklung einzubringen oder Wünsche anzubringen, um später mit der Software produktiv arbeiten zu können.
Bei einer feststehenden Planung und entsprechender Abarbeitung ist das häufig nicht möglich oder aber bietet rechtliche Schwierigkeiten bei der vertraglichen Umsetzung.
Daher bedienen vermehrt Auftraggeber und Entwickler der agilen Softwareentwicklung, bei der die Entwicklung zeitnah starten kann und während der Entwicklung laufend Änderungen und Wünschen eingebracht werden können.
Scrum
Weit verbreitet ist die „Scrum-Methodik“ bei der nach einer Produktvision kleinere (lauffähige) Teile der Gesamtsoftware Stück für Stück programmiert werden. Zuvor werden diese Teilbereiche in enger Zusammenarbeit mit dem Auftraggeber geplant und abgestimmt. Jeder Programmierdurchgang stellt dann aber ein oder mehrere Elemente der Gesamtsoftware fertig.
Durch diese Vorgehensweise können Änderungswünsche bereits vor der vollständigen Fertigstellung eingebracht und umgesetzt werden.
Aus rechtlicher Sicht ist dafür jedoch ein geeigneter Vertag erforderlich, weil diese Vorgehensweise viel Mitwirkung des Auftraggebers erfordert. Zudem wird bei jeder Ablieferung nach einem Programmierabschnitt (Sprint) nicht zwangsläufig ein fertiges Produkt fertiggestellt.
Zudem übernimmt der Auftraggeber zahlreiche Planungsaufgaben und arbeitet an der Ausarbeitung der jeweiligen Elemente (User Storys), die jeweils programmiertechnisch umgesetzt werden sollen, mit. Auch eine sachgerechte Protokollierung der einzelnen Schritte ist deswegen essentiell für ein erfolgreiches Projekt.
Das zeigt bereits, dass hier vom Auftraggeber deutlich mehr Einsatz verlangt wird, als bei klassischen Entwicklungsprozess. Das muss der Vertrag natürlich wiederspiegeln.
Dennoch bleibt es im Wesentlichen bei der Einordnung als Werkvertrag, selbst wenn sich das Programmierteam selbst organisiert. Aber auch das will vertraglich geregelt sein, damit die Aufgabenverteilung und die Rollen klar erkennbar verteilt sind.
Andernfalls wird der Vertrag anhand der tatsächlichen Umsetzung ausgelegt und kann im Streitfall Überraschungen bieten, was die Art des Vertrages angeht. Die Rechtsprechung zu derartigen Verträgen ist im Moment sehr überschaubar.
Rechtliches zu agiler Softwareentwicklung
Eine Entscheidung des OLG Frankfurt a.M. (Urteil vom 17.08.2017, Az. 5 U 152/16, MMR 2018, 100) lässt zwar offen, wie im dort vorliegenden Fall ein Scrum-Vertrag generell zu beurteilen ist, beanstandet aber auch die Auslegung durch die Vorinstanz (LG Wiesbaden Urteil v. 30.11.2016 Az. 11 O 10/15, CR 2017, 298) als Werkvertrag nicht. Gewährleistungsrechte seien bei derartigen Verträgen also durchaus nach Werkvertragsregeln abzuwickeln. Dennoch spricht auch das OLG Frankfurt a. M. davon, dass eine Auslegung als Dienstvertrag möglich wäre. Aus diesem Grund musste das Gericht sich in dem Fall auch nicht festlegen, welche Vertragsart zu Grunde zu legen ist, weil der Fall bei beiden Auslegungen gleich entschieden worden wäre.
Im Ergebnis sprechen zudem sehr viele Arbeitsweisen, insbesondere durch die Abstimmung und Beauftragung einzelner Sprints für die überwiegende Annahme eines Werkvertrags, da sich der jeweils geschuldete Erfolg immer wieder durch die Sprints definieren und am Backlog nachprüfen lässt.
Sie benötigen Beratung für Ihr Software-Projekt?
Kontaktieren Sie uns gerne bei Fragen oder um rechtliche Unterstützung für ihr Projekt anzufragen.
Das ist tatsächlich ein Thema, über das man sich selten Gedanken macht. Wer hätte gedacht, dass es bei Scrum zu Vertragsproblemen kommen kann?
Super geschriebener und informativer Artikel :-). In diesen Blog werde ich mich noch richtig einlesen