Beitragsreihe: Verträge für agile Softwareprojekte – Konventionelle Vertragsmodelle
Agile Softwareentwicklung – Teil III
Die Beitragsreihe “Verträge für agile Softwareprojekte” setzt sich mit den schuld- und urheberrechtlichen Aspekten der agilen Softwareentwicklung auseinander. Unter der Prämisse, dass agile Verträge als Lösungsansatz auch für deutsche Unternehmen zunehmend Relevanz erlangen, diese Thematik bisher jedoch nur rudimentär aufgearbeitet wurde, wird anhand von Rechtsprechung und Literatur die gegenwärtige Rechtslage veranschaulicht. Schlussendlich werden Empfehlungen zu vertraglichen Regelungen ausgesprochen, die sich mit Blick auf die Vielzahl von Problemen und Risiken ergeben, die bei agilen Softwareentwicklungsprojekten zu erwarten sind.
Zurück zu Teil II: Risiken konventioneller Verträge
Konventionelle Vertragsmodelle
Die Vertragsgestaltung ermöglicht es, den vorher genannten Gefahren entgegenzutreten und die Verantwortlichkeit durch eine einvernehmliche Verlagerung in beiderseitigem Interesse gleichmäßig zu verteilen. Das passende Vertragsmodell hängt hierbei von den individuellen Anforderungen und Bedürfnissen der Parteien ab, es gibt also keine universelle Lösung für alle Sachverhalte der agilen Softwareentwicklung. In Betracht kommen zunächst die konventionellen Vertragsmodelle, also der Werkvertrag, der Dienstvertrag, aber auch kombinierte Verträge mit dienst- und werkvertraglichen Elementen.
Der klassische Werkvertrag bildet hierbei das Ausgangsmodell. Beim Werkvertrag schuldet der Dienstleister die Erstellung eines mangelfreien Werks, gemessen auf Grundlage einer konkreten Spezifikation, die vor Arbeitsbeginn einmalig vereinbart wurde. Die Vergütung erfolgt über einen Festpreis und Änderungen an oder der Austausch von Features erfolgt im Rahmen von Change-Requests mit Preissteigerungen auf der Basis von Time and Materials. Der klassische Werkvertrag sieht somit eine Kostensicherheit bei gleichbleibender Spezifikation, die Verantwortung des Auftragnehmers bei Mängeln und dadurch eine Vorhersehbarkeit für Auftraggeber und Auftragnehmer vor. Dies bedeutet zugleich, dass Änderungen stets Nachverhandlungen erfordern, mit nicht-einkalkulierten Kosten verbunden sind und es bedingt Anreize für den Arbeitnehmer gibt, über Verbesserungen im Sinne des Arbeitgebers nachzudenken. Der klassische Werkvertrag ist in der Gesamtbetrachtung für einfache Projekte in unveränderlichen Umgebungen geeignet.
Der Dienstvertrag scheint demgegenüber eher auf die Bedürfnisse der agilen Projektleitung zugeschnitten zu sein. Beim Dienstvertrag schuldet der Dienstleister kein definiertes Ergebnis (Werk) sondern lediglich seine Arbeitsleistung in Form der Tätigkeit. Dadurch verschiebt sich das Erfolgsrisiko zu Lasten des Auftraggebers. Innerhalb des Projekts würde die Software in sogenannten Sprints entwickelt, bei denen jeweils einzelne User-Stories entwickelt und implementiert werden. Ein Sprint ist ein abgeschlossener Zeitrahmen innerhalb dessen vorher bestimmte Entwicklungsziele verwirklicht werden und auf den sofort der nächste Sprint folgt.[1] Die Vergütung erfolgt nach Aufwand, also Time and Materials. Dadurch bietet der Dienstvertrag eine völlige Flexibilität im Hinblick auf den Vertragsgegenstand und eine wirtschaftliche Sicherheit für den Auftragnehmer. Die Projektkosten können für den Auftraggeber jedoch nicht abschließend bestimmt werden, und so bleiben Zeit und Kosten unvorhersehbar. Die Mängelbeseitigung durch den Auftragnehmer führt unweigerlich zu Zusatzkosten für den Auftraggeber. Im Ergebnis ist der Dienstvertrag eher für kleinere Projekte für die Entwicklung von Einzelkomponenten geeignet, die im Rahmen einer bereits eingespielten Zusammenarbeit verwirklicht werden soll.
Einen Kompromiss versucht der Rahmenvertrag mit einzelnen, untergeordneten Werkverträgen darzustellen. Der Rahmenvertrag regelt hierbei die Beziehung von Auftragnehmer und Auftraggeber und fasst einen Großteil des Verhandlungsumfangs einmalig ab. Für jeden Sprint vereinbaren die Parteien sodann einen präzisen Scope mit umzusetzenden User-Stories zu einem festen Preis nach werkvertraglichem Charakter. Die Mängelbeseitigung erfolgt nach jeder Teilabnahme im Rahmen der gesetzlichen Gewährleistung. Dieses Modell erreicht eine hohe Flexibilität, ohne Kostensicherheit bei gleichbleibender Spezifikation zu gefährden und bietet durch die Teilabnahmen und die gesetzliche Gewährleistung einen hervorragenden Ausgleich in der Qualitätssicherung. Jedoch ist jeder Sprint mit einem Verhandlungsaufwand verbunden und die beabsichtigte Agilität, also Änderungen im Scope, führen zu Kostenunsicherheiten. Der Rahmenvertrag mit einzelnen Werkverträgen ist demnach besonders gut für komplizierte Projekte geeignet, an denen ohne Zeitdruck gearbeitet werden kann.
Das Vertragsmodell des agilen Festpreises ist die Fortentwicklung und Anpassung des Werkvertrages mit Werkzeugen, die durch die agile Arbeitsweise selbst bereitgestellt werden. Hierbei werden im Rahmen einer Testphase Referenz-Userstories festgelegt, anhand derer dann allen User-Stories Storypoints zugewiesen werden. Die Parteien vereinbaren einen Festpreis für eine bestimmte Anzahl von Storypoints, die in den jeweiligen Sprints vom Auftraggeber genutzt flexibel genutzt werden können. Die Haftung des Auftragnehmers für Mängel ergibt sich aus den werkvertraglichen Regelungen. Durch dieses Modell wird eine hohe Flexibilität in der Ausgestaltung der Arbeitsleistung vorgesehen, ohne die Haftung des Auftragnehmers für die eigene Arbeitsleistung zu berühren. Change-Requests und Änderungen des Scope unterliegen klaren Prozessen, die im Vertrag beschrieben sind. Die Erforderlichkeit der Testphase und die Möglichkeit, Zeit und Kosten erst nach der Durchführung dieser Testphase bestimmen zu können, verursachen bei den Beteiligten dahingegen einen unproduktiven, möglicherweise sogar vergeblichen Aufwand. Das agile Festpreismodell ist für eingespielte Teams aus Auftragnehmern und Auftraggebern geeignet, insbesondere bei hausinterner Softwareentwicklung.
Weiter zu unserer Empfehlung Teil IV: Agile “Time and Materials”-Projekte
[1] Schwaber/ Sutherland, The Scrum Guide, S. 7.
RA Bilal Abedin
Wiss. Mit. Burak Zurel