Agile Softwareverträge

Größe: px

Ab Seite anzeigen:

Download "Agile Softwareverträge"

Joachim Weiner
vor 8 Jahren
Abrufe

1 Zeitschrift Informatik-Spektrum der deutschen Gesellschaft für Informatik Ursula Sury Agile Softwareverträge AGILE SOFTWAREENTWICKLUNG Komplexität, steter Wandel, Umgang mit vielen Unbekannten das sind sicher Hauptaspekte, welche das Business generell prägen und sich natürlicherweise auch in Softwareentwicklungsprojekten niederschlagen. Vor diesem Hintergrund haben sich für die Softwareerstellung agile Vorgehensmodelle entwickelt. Erfahrungsgemäss sind die Anforderungen an die Software vor Projektstart aus verschiedenen Gründen nicht tatsächlich genau definierbar. Zudem verändern sich im Laufe des Projektes eben wegen den eingangs genannten Parametern des Wechsels etc. die Anforderungen an die Software. Dies führt häufig, vor allem bei längeren Entwicklungszeiten, zu einem grossen Delta zwischen den Vorstellungen und Wünschen des Kunden einerseits und den tatsächlich realisierten Funktionalitäten andererseits. Methoden agiler Softwareentwicklungen versuchen dank iterativem Vorgehen sich der Lösung eines Problems schrittweise anzunähern. Geänderte Anforderungen werden in einem relativ engen Zeitrhythmus in jeweils lauffähige Softwarereleases eingebaut, welche idealerweise beim Kunden schon direkt eingesetzt werden können. VERTRAGSGEGENSTAND Ein Vertrag sollte grundsätzlich immer klar die folgende Frage beantworten: Wer will was von wem und zu welchem Preis bis wann? Das Spezielle bei der agilen Softwareentwicklung ist nun, dass viele dieser Anforderungen an einen Vertrag zum Zeitpunkt des Vertragsabschlusses nur ungefähr feststehen. Wer ist möglicherweise noch klar, aber auch hier können sich Veränderungen ergeben, je nach dem ob vom Kunden vielleicht geplant ist, das Produkt dann auch noch bei mit ihm verbundenen Unternehmen wie Tochter- oder Holdinggesellschaften einzusetzen. 1

Vor diesem Hintergrund haben sich für die Softwareerstellung agile Vorgehensmodelle entwickelt.

2 Die Frage nach dem Was wird entsprechend der iterativen Vorgehensweise zu Beginn tatsächlich nur sehr ungenau beantwortet sein. Beide Parteien sind sich aber über das Vorgehensmodell einig und dieses impliziert, dass das Was, also der Vertragsgegenstand, in einem genau definierten Prozess laufend gemeinsam präzisiert wird. Die genaue Definition des Vertragsgegenstandes, wie beispielsweise beim Wasserfallmodell, wo das Detailkonzept als integrierender Bestandteil des Realisierungsvertrags das Vertragsziel genau umschreibt, wird somit ersetzt durch ein spezifisches Projektvorgehen mit einzelnen Teilschritten. Die Herausforderung besteht also darin, dies im Softwarevertrag angemessen zu berücksichtigen und abzubilden. Ein entscheidendes Element agiler Softwareentwicklung ist der sehr starke Einbezug und die dauernde Interaktion mit dem Kunden. Über diese enge Zusammenarbeit erhält der Kunde eine andere Rolle und Verantwortung in Bezug auf den Erfolg des Projektes. Dies ergibt, stärker noch als bei den traditionelleren Phasenmodellen, eine noch stärkere Vergemeinschaftung zwischen Softwareanbieter und Kunde und somit eine noch grössere Abhängigkeit des Projekterfolges vom Mitwirken des Kunden. Also wird auch die Vertragsanforderung von wem der Vertrag erfüllt werden muss, komplexer, da der Kunde selber einen entscheidenden Teil beiträgt. Zudem wird, entsprechend dem iterativen Vorgehen, erst im Verlaufe des Projektes festgelegt, welche Beiträge die Vertragspartner inhaltlich konkret zu leisten haben. Wir sind uns gewohnt, einen spezifischen Vertragserfolg bis zu einem bestimmten Zeitpunkt zu vereinbaren. Da bei agilen Vorgehensmodellen das Vertragsziel qualitativ und quantitativ nur sehr ungefähr umschrieben ist, wird zu Beginn der Zusammenarbeit auch der Zeitpunkt der Realisierung, also das Wann, in Relation zum Vertragsziel nur ungefähr vereinbart sein. Entsprechend dem zu Vertragsbeginn nur ungefähren Vertragsziel wird es also nicht möglich sein, einen genau definierten Preis für den genau definierten Vertragserfolg zu vereinbaren. Es wird wohl eher so sein, dass ähnlich wie in Verträgen des Personalverleihs eine bestimmte Anzahl Personenressourcen mit bestimmten Profilen zur Verfügung gestellt werden und man ein spezifisches Budget vereinbart. Welche Resultate mit dem vorgesehenen Budget dann aber tatsächlich erreicht werden oder erreicht werden können, ist entsprechend der Vorgehensmethodik eben nur ungefähr bestimmbar. 2

Die genaue Definition des Vertragsgegenstandes, wie beispielsweise beim Wasserfallmodell, wo das Detailkonzept als integrierender Bestandteil des Realisierungsvertrags das Vertragsziel genau

3 ABBILDUNG DER DYNAMIK IM VERTRAG Die meisten klassischen und somit allgemein bekannten Verträge sind auf einen bestimmten Zeitpunkt bezogen und statisch. Ein Haus wird zum Beispiel auf einen bestimmten Zeitpunkt verkauft. Zeit-Raum bezogene Verträge wie Softwarerealisierungsverträge sind grundsätzlich seltener und dass die Berücksichtigung von Iterationen und Wandel im Zeit-Raum bezogenen Vertrag abgebildet werden muss, ist ein neues Phänomen und somit auch eine neue Herausforderung. Ein Vertrag entsteht durch gegenseitige übereinstimmende Willensäusserung. Die eigentlichen zentralen Elemente (eben wer will was von wem wann zu welchem Preis) sind im agilen Softwarevertrag nicht bestimmt, sondern nur bestimmbar. Diese Situation muss in der Ausgangslage transparent gemacht werden. Zudem ist die gewählte iterative Methodik zu umschreiben und somit das Vorgehen verbindlich festzuhalten. Dazu gehört auch, dass man die entsprechenden Verantwortlichkeiten (Projektorganisation) und Rollen, die den beteiligten Parteien (also auch den Kunden!) zukommen, genau umschreibt. Im Verlaufe des Projektes wird der Vertragsgegenstand über die einzelnen Releases, aber auch über Absprachen der Parteien, laufend präzisiert. Zudem müssen die Aufgaben der Parteien für die einzelnen Projektschritte genau geplant werden. Da diese Zwischenresultate den Vertrag laufend präzisieren und somit den Vertragswillen der Parteien ausdrücken, müssen sie auch offiziell zum Vertragsgegenstand erklärt werden. Die Herausforderung ist es, den ursprünglichen Vertrag, welcher zu Beginn des Projektes abgeschlossen wird, und die während dem Projekt entstehenden Dokumenten und Softwarereleases zu verknüpfen. Dabei gilt es auch zu klären, dass jüngere Dokumente bei Widersprüchen älteren vorgehen. Bei komplexen Projektorganisationen und Dokumente verschiedener Hierarchieart ist zudem das Verhältnis dieser Dokumente zu klären. SCHLECHTERFÜLLUNG DES VERTRAGES Eine grosse Herausforderung bei agilen Softwareverträgen ist die Frage, wie sich eine mögliche Nicht- oder Schlechterfüllung feststellen lässt, das heisst, an was sich diese 3

Zeit-Raum bezogene Verträge wie Softwarerealisierungsverträge sind grundsätzlich seltener und dass die Berücksichtigung von Iterationen und Wandel im Zeit-Raum bezogenen Vertrag abgebildet werden

4 misst. Die klassische Gegenüberstellung eines im Voraus definierten Soll-Zustandes mit einem Ist-Zustand im Zeitpunkt der Abnahme ist nur schwer möglich. Die Parteien sind also gefordert, laufend messbare Qualitätskriterien im Rahmen der Zusammenarbeit festzulegen und diese auch laufend gemeinsam zu überprüfen. Auch sollte der Vertrag die Konsequenzen festlegen, die eintreten, falls diese Qualitätskriterien nicht oder wiederholt nicht eingehalten werden. Vor diesem Hintergrund sollte im Vertrag auch festgehalten werden, wie die Abnahme eines einzelnen Release rechtlich qualifiziert wird. Heisst dies, im Sinne einer eigentlichen Abnahme, Befreiung des Anbieters von seiner Haftung, also Akzeptanz der Mängelfreiheit oder ist es eher nur ein kleiner Schritt auf dem langen Weg zum Ziel, der, obwohl mängelbehaftet, akzeptiert wird um dann eben den nächsten Schritt machen zu können? Ein Akzept im letztgenannten Sinn wäre nur ein Ja zum nächsten Schritt, mit dem dann die im letzten Schritt festgestellten Probleme hoffentlich (mindestens teilweise) behoben werden. ÜBRIGE VERTRAGSBESTIMMUNGEN Die übrigen Vertragsbestimmungen, wie beispielsweise die Regelung über die Urheberrechte, die Einhaltung von Datenschutz und Geheimhaltung, gegenseitiges Abwerbeverbot, Pay-Back-Regelungen, Exklusivitätsklauseln etc. sind vom agilen iterativen Vorgehen weniger berührt. Diese können im Eingangsvertrag allgemein geregelt werden, müssen dann aber, wie auch beim traditionellen Phasenkonzept, konkret bei der Realisierung berücksichtigt werden. Dies betrifft insbesondere die Anforderungen des Datenschutzes, welche auch in der Software abgebildet werden müssen. ZUSAMMENFASSUNG Die Anwendung agiler Vorgehensmodelle für die Softwareentwicklung erfordert die entsprechende Abbildung in agilen Softwareverträgen. Speziell muss beachtet werden, dass das Vertragsziel zu Beginn nur ungefähr feststeht und erst im Verlaufe des Projektes präzisiert und detailliert wird. Deshalb müssen die Zwischenergebnisse des Projektes dynamisch mit dem ursprünglichen Projektvertrag verknüpft werden. Ursula Sury ist selbständige Rechtsanwältin in Luzern (CH) und leitet die Studienrichtung Management + Law an der Hochschule Luzern Wirtschaft. Sie ist zudem Dozen- 4

Auch sollte der Vertrag die Konsequenzen festlegen, die eintreten, falls diese Qualitätskriterien nicht oder wiederholt nicht eingehalten werden.

5 tin für Informatikrecht an verschiedenen Nachdiplomstudien, welche am Institut für Wirtschaftsinformatik der Hochschule durchgeführt werden. Die Autorin ist hauptsächlich im Bereich Informatikrecht und Datenschutz tätig. im Januar 2010 / Ursula Sury 5

Ähnliche Dokumente

Vertragsrecht in agilen Softwareprojekten. Prof. Ursula Sury, RA

Vertragsrecht in agilen Softwareprojekten Prof. Ursula Sury, RA 1 Agenda Die zentrale Frage/ Grundelemente des Softwarevertrags Ablauf der Softwareentwicklung Ziele der agilen Software Besonderheiten der