Softwareentwicklung und Lizensierung

Langjährige Erfahrung bei der Beratung in diesen Bereichen und das notwendige technische Verständnis helfen Ihnen als Mandant bei der Erreichung wirtschaftlicher Ziele.

Ihre Ansprechpartner in Fragen Softwareentwicklung und Lizensierung sind bei uns Rechtsanwalt Jens Liesegang und Normen Lang.

Die SCRUM Methode und ihre (vertrags-) rechtliche Einordnung

Die SCRUM Methode bezeichnet eine Vorgehensweise im Bereich der agilen Softwarenentwicklung.

Im Unterschied zu klassischen Softwareentwicklungsverträgen werden die zu erbringenden Leistungen nicht bei Vertragsschluss durch eine entsprechende Leistungsbeschreibung, bspw. in einem Pflichtenheft festgelegt, sondern im Wege einer flexiblen Vorgehensweise im Verlauf der Zusammenarbeit um bessere Ergebnisse zu erzielen.

Bei der hier besprochenen SCRUM Methode werden zunächst Anforderungen aus Anwendersicht formuliert und im sogenannten Product Backlog festgehalten. Diese werden dann in sogenannten Sprints umgesetzt.

In rechtlicher Hinsicht ist dabei eine vertragliche Lösung zu finden, die einerseits dem flexiblen Vorgehen gerecht wird und andererseits den Parteien ein gewisses Maß an Rechtssicherheit gibt.

Bevor auf die vertragsrechtlichen Aspekte eingegangen wird, wendet sich dieser Artikel zunächst den Grundzügen der Vorgehensweise zu, auf deren Grundlage sodann die vertragsrechtliche Einordnung bzw. Einkleidung vorgenommen wird.

A. Vorgehensweise nach der SCRUM Methode im Einzelnen

Bei der Vorgehensweise SCRUM müssen zunächst der Zweck und das Ziel des Projekts sowie das SCRUM Team festgelegt werden. Auf Grundlage des festgelegten Ziels und Zwecks ist das Product Backlog zu entwickeln. Schließlich werden die sogenannten Sprints geplant, durchgeführt und deren Ergebnis zum Abschluss des jeweiligen Sprints geprüft.

I. Zweck und Ziel des Projekts

Zunächst müssen die Zwecke und Ziele des Projekts zwischen Parteien feststehen. Die Zwecke und Ziele des Projekts werden in der sogenannten Produktvision festgehalten.

Aus der Produktvision sollte sich entnehmen lassen, an welche Zielgruppe sich die zu entwickelnde Software richten soll, welche Bedürfnisse die betreffende Zielgruppe bzgl. der betreffenden Software hat. Schließlich sollte die Produktvision skizzieren, welche Eigenschaften der Software das beschriebene Bedürfnis lösen können.

II. SCRUM Team

Das SCRUM Team besteht typischerweise aus dem Product Owner, dem Entwicklungsteam und dem SCRUM Master. Das SCRUM Team steht in Kontakt mit den Stakeholdern. Zu den Stakeholdern zählen regelmäßig die Kunden und Anwender der Software.

1. Product Owner

Der Product Owner steht in der Regel im Lager des Auftraggebers und ist dafür verantwortlich dessen Anforderungen dem Entwicklungsteam darzustellen. Hierzu erstellt er das Product Backlog (siehe hierzu unten) in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern.

Das Product Backlog wird in der Weise erstellt, dass der Product Owner regelmäßig mit den Stakeholdern Rücksprache hält. Nach Rücksprache mit dem Entwicklungsteam, erläutert und priorisiert der Product Owner dann im Product Backlog die Eigenschaften der Software.

Der Product Owner hat auch die Aufgabe in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern das Product Baklog im Wege des sogenannten Product Backlog Refinement weiter zu entwickeln.

2. Entwicklungsteam

Das Entwicklungsteam sollte aus mindestens 3 und höchstens 9 Mitgliedern bestehen. Die Zusammensetzung des Teams sollte interdisziplinär sein. Es liefert die Programmfunktionalitäten, in der vom Product Owner vorgegebenen Reihenfolge.

Das Entwicklungsteam erstellt das Sprint Backlog (siehe hierzu unten), indem es die im sogenannten Sprint Planning (siehe hierzu unten) ausgewählten Aufgaben aus dem Product Backlog in einzelne Schritte aufteilt.

3. SCRUM Master

Der Srum Master steht entweder im Lager des Auftragnehmers oder es handelt sich um eine eigenständige dritte Partei. Er ist gewissermaßen der Coach des Entwicklungsteams.

III. Product Backlog

Das Product Backlog enthält alle Anforderungen an das Produkt. Das Product Backlog wird von dem Product Owner in der oben beschriebenen Weise erstellt und weiterentwickelt. Die Anforderungen im Product Backlog sollten anwenderorientiert formuliert sein. Die Anforderungen werden in Form von sogenannten User Stories formuliert. Dabei sollten die User Stories folgende Voraussetzungen haben, welche unter der Abkürzung INVEST zusammengefasst werden:

• Einzelne User Stories sollten unabhängig voneinander sein (Independent).

• Die User Stories sollten abänderbar sein, solange des Produkt noch nicht ausgeliefert ist (Negotiable).

• Die in der User Story formulierte Anforderung erhöht den Gebrauchswert des Produkt(Valuable).

• Der Aufwand für die Umsetzung muss abschätzbar sein (Estimiable).

• Die Umsetzung der jeweiligen User Story sollte innerhalb weniger Tage umsetzbar sein (Small).

• Es sollte anhand objektiver Kriterien überprüfbar sein, ob die Programmfunktionanalität den in der User Story formulierten Anforderungen genügt (Testable).

Im Wege des sogenannten Product Backlog Refinement wird das Product Backlog stetig durch den Product Owner und das Entwicklungsteam weiterentwickelt. Hierbei werden bspw. die User Stories hinzugefügt, geändert und/oder zusammengefasst

IV. Sprint

Ein Sprint stellt einen Entwicklungszyklus der Software dar, dessen Ergebnis die Lieferung eines fertigen Teilprodukts der Software, des sogenannten Produktinkrements, ist. Der Funktionsumfang des Produktinkrements ist im Product Backlog beschrieben. Ein Sprint beginnt mit dem Sprint Planning und endet mit dem Sprint Review und der Sprint Retrospektive.

Ein grundsätzlich nicht verlängerbarer Sprint dauert ein bis vier Wochen.

1. Sprint Planning

Im Rahmen des Sprint Plannings soll im Sprint Backlog festgelegt werden, welche Produktfunktionalitäten entwickelt werden sollen, wann die Produktfunktionalitäten als fertiggestellt gelten und welche Aufgaben zur Erreichung des Sprintziels erledigt werden müssen.

a. Was soll im Sprint erreicht werden

Zunächst wird im Sprint Planning festgelegt, was im Einzelnen entwickelt wird.

Hierzu stellt der Product Owner dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften dar. Dem Entwicklungsteam wird dabei auch mitgeteilt, in welcher Reihenfolge die Produkteigenschaften abzuarbeiten sind.

Das SCRUM Team legt gemeinsam die Kriterien fest, nach denen bestimmt werden kann, ob die zu erstellende Produktfunktionalität fertiggestellt ist, sogenannte Definition of Done.

Ferner gibt das Entwicklungsteam eine Prognose ab, wie viele Product Backlog Einträge das Entwicklungsteam im nächsten Sprint liefern kann.

b. Welche Aufgaben müssen erledigt werden, um das Sprintziel zu erreichen

Nachdem festgelegt wurde, was in dem bevorstehenden Sprint entwickelt werden soll, legt das Entwicklungsteam fest, welche Aufgaben, die sogenannten Tasks, erledigt werden müssen, um das Sprintziel zu erreichen.

2. Ablauf des Sprints

a. Regelmäßige Treffen des Entwicklungsteams

Das Entwicklungsteam trifft sich an jedem Arbeitstag, um sich einen Überblick über den Stand der Entwicklung zu verschaffen. Die Treffen zielen auch darauf ab ggf. die sogenannten Tasks anders zu verteilen, um die im Rahmen Sprints zu erstellende Produktfunktionalität rechtzeitig fertigzustellen. Diese regelmäßigen Treffen werden Daily SCRUMs genannt.

b. Sprint Review

Am Ende des Sprints wird dem SCRUM Team das sogenannte Produktinkrement vorgestellt.

Dabei prüft der Product Owner im Wege von Tests, ob die in dem Sprint entwickelte Softwarefunktionalität der im Sprint Planning festgelegten Abnahmekriterium Defintion of Done entspricht.

Der Sprint Review dient auch regelmäßig dazu, das Product Backlog anzupassen. Dabei werden die Ergebnisse zwischen dem SCRUM Team und den Stakeholdern besprochen. Ggf. müssen die im Produktbacklog festgelegten Produktfunktionalitäten wegen eines sogenannten Product-Backlog- Refinements angepasst werden.

B. Vertragliche Einkleidung

Die vertragliche Einordnung bzw. Einkleidung von agilen Software Projekten ist regelmäßig schwierig. Im Gegensatz zur klassischen Wasserfallmethode, bei der in einem Pflichtenheft, welches Bestandteil des Vertrages ist, festgelegt ist, welche Funktionalitäten die zu entwickelnde Software haben soll, werden diese bei der SCRUM Methode erst im Wege der Zusammenarbeit und im Sprint Planning festgelegt.

Im Folgenden soll grob skizziert sein, wie ein Vertragsmodell für ein Softwareentwicklungsprojekt nach der SCRUM Methode aussehen könnte. Es soll sich bestenfalls um ein grobe Richtschnur, denn je nach Komplexität des Projekts und Parteiinteresse sind ergänzende und/oder alternative Regelungen erforderlich.

In Frage käme die Kombination aus einer dienstvertraglichen Rahmenvereinbarung und einzelnen unabhängigen Werkverträgen für die Sprints. Neben Regelungen zu Nutzungsrechten, Haftung und Gewährleistungen ist insbesondere folgendes zu beachten:

1. Festlegung der Rollen im SCRUM Team

Bei der vertraglichen Fixierung ist es unerlässlich zunächst die einzelnen Rollen des SCRUM Teams zu definieren und welche Mitwirkungspflichten und Kompetenzen die einzelnen Beteiligten haben.

2. Product Backlog

Weiterhin sollte festgelegt sein, wie das Product Backlog erstellt wird und dass der Product Owner alleine das Product Backlog verwaltet. Dabei sollte auch geregelt sein, wer bei Änderungen und Ergänzungen des Product Backlogs mitwirken darf und dass Änderungen und Ergänzungen entsprechend protokolliert werden müssen.

3. Sprints und Abnahme des Sprintergebnis

Die Dauer eines Sprints, die Daily SCRUMs und der Ablauf des Sprint Plannings sollten geregelt sein. Ferner ist zu regeln bis wann und unter welchen Voraussetzungen der Product Owner das im Rahmen eines Sprints entwickelt Produktinkrement abzunehmen hat. Voraussetzung der Abnahme sollte sein, dass das Produktinkrement, der im Rahmen des Sprint Plannings festgelegten Definition of Done entspricht. Es sollte bestimmt sein, dass das Sprint Backlog Gegenstand des Vertrages wird und die Leistungsbeschreibung darstellt.

Hierbei sollte der Zeitpunkt für einen Test bestimmt bzw. bestimmbar festgelegt sein. Ferner ist erforderlich, dass der Auftraggeber die für den Test erforderlichen Nutzungsrechte erhält und dass festgelegt wird wie und in welcher Testumgebung das Produktinkrement getestet wird.

Wenn das Ergebnis eines Sprints nicht der Definition of Done entspricht, sollte festgelegt sein, dass Fehler dem Auftragnehmer mitgeteilt werden und der Product Owner die Beseitigung der Fehler im Rahmen der Abnahme des nächsten Sprints erneut prüft.

4. Endabnahme

Schließlich muss die Endabnahme geregelt sein. Dabei werden Funktionen abgenommen, die nur bei der Gesamtintegration der Software überprüft werden können. Auch hier müssen dem Auftraggeber, die für den Test erforderlichen Nutzungsrechte eingeräumt werden und es sollte bestimmt sein, wann, wie und in welcher Testumgebung die Gesamtintegration der Software getestet wird.

5. Vergütung

Die Vergütung sollte sich einerseits an den im Rahmen der Sprints fertiggestellten Produktinkrementen orientieren und andererseits an der Fertigstellung der zu entwickelnden Software insgesamt.

Hierzu kann bspw. vereinbart werden, dass mit der Abnahme eines Sprints nur ein Anteil der jeweils auf die einzelnen Sprints entfallenden Vergütung gezahlt wird. Der ausstehende Anteil wird erst bei Abnahme des Gesamtprodukts gezahlt. Bspw. kann vereinbart werden, dass je abgenommen Sprints nur 70 % der auf den jeweiligen Sprint entfallenden Vergütung gezahlt werden. Die restlichen 30 % werden bei Abnahme des Gesamtprodukts gezahlt. Sollte der Vertrag vorzeitig gekündigt werden, so hat der Auftragnehmer keinen Anspruch auf Zahlung der ausstehenden 30 %.

6. Vertragsbeendigung

Es sollte in dem Vertrag festgelegt sein, dass der Vertrag zum Ende eines jeden Sprints unter Einhaltung der Textform und einer Kündigungsfrist für beide Parteien kündbar ist.

C. Zusammenfassung

Trotz der schwierigen vertragsrechtlichen Einordnung ist es ratsam ein Softwareprojekt nach der SCRUM Methode vertraglich in Textform zu regeln. Gerade wegen der schwierigen Einordnung sollte jedenfalls kein stillschweigender oder mündlicher Vertrag geschlossen werden.