Die werkvertragliche Abnahme bei agilen IT-Projekten

Transkript

1 Die werkvertragliche Abnahme bei agilen IT-Projekten Juristisches IT-Projektmanagement Lehr- und Forschungseinheit für Programmierung und Softwaretechnik bei Dr. Frank Sarre vorgelegt von: Studiengang: Michael Kirsch Master Informatik 2013 Dieses Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtgesetzes ist ohne Zustimmung des Autors unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Einspeicherung und Verarbeitung in elektronischen Systemen.

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung 1 2 Eigenschaften agiler IT-Projekte Hohe Flexibilität Hohe Qualität Geringer Zeitaufwand Vertragsrechtliche Einordnung von agilen IT-Projekten Merkmale des Werkvertrags Merkmale agiler IT-Projekte Zeitplanung und Vergütung Definition des Leistungsgegenstands Mitwirkungsleistung des Auftraggebers Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum Rollenverteilung in Scrum Product Owner Scrum Master & Entwicklungsteam Scrum-Artefakte als mögliche Basis zur Abnahme Product Backlog Sprint Backlog Definition of Done Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum Teilabnahmen / Gesamtabnahme Zeitliche Planung der Abnahme Abnahmegegenstände Bereitstellung der Abnahmegegenstände Abnahmekriterien, Testfälle und Testdaten Stellung der Testumgebung Mangelkategorien Formen und Erklärung der Abnahme Wiederholung der Abnahme Scheitern der Abnahme Fazit 18 Literaturverzeichnis 19 Michael Kirsch I

3 1 Einleitung 1 Einleitung Agile Projektmethoden werden immer populärer 1 und sind aus heutigen IT-Projekten nicht mehr weg zu denken. So hat bspw. eine Studie der OOSE-Group 2 ermittelt, dass Projekte mit agilen Vorgehensmodellen immer erfolgreicher waren als Projekte, bei denen klassische Vorgehensmodelle wie bspw. das Wasserfallmodell verwendet wurden. Für die Studie wurden 135 Projektmanager über ein klassisches und ein agiles Projekt ihrer Wahl im Detail befragt. Die Studie hat weiterhin gezeigt, dass 64% der agilen, aber nur 42% der klassischen Projekte erfolgreich umgesetzt wurden. Zudem wurde deutlich, dass kleinere Firmen (< 500 Mitarbeiter) eher zu agilen Methoden greifen (75%) als größere Unternehmen (12%). Das mit Abstand am häufigsten verwendete agile Vorgehensmodell war laut Studie Scrum, mit 52% aller untersuchten agilen Projekte. Alleine der hohe Anteil an agilen Projekten und die höhere Erfolgsquote lassen ein Umdenken beim Management von IT-Projekten erkennen. Jedoch erfordert ein alternatives Vorgehensmodell nicht nur Anpassungen innerhalb des fachlichen Vorgehens, sondern auch bei der juristischen Betrachtung von IT-Projekten. Während bei klassischen Projekten eine ausgereifte Spezifikation die Grundlage für den Fortlauf eines Projektes bzw. den Beginn der Entwicklung bedeutet, ist beim agilen Vorgehen die Spezifikation ein eher volatiles Fragment, das im Laufe des Projekts an Detailtiefe gewinnt und letztendlich erst mit dem fertigen Gewerk abgeschlossen ist. Ausgehend davon, dass Verträge in IT-Projekten erfahrungsgemäß in den meisten Fällen als Werkverträge eingeordnet werden können, ist der Auftraggeber nach 640 Bürgerliches Gesetzbuch (BGB) 3 in der Pflicht, [...] das vertragsmäßig hergestellte Werk abzunehmen. 4 Hierbei stellt sich nun die Frage, ob ein Gewerk vertragsmäßig hergestellt wurde, wenn der Vertrag vor Beginn der Entwicklung keine detaillierte Beschreibung des gewünschten Werks enthielt. Die Praxis zeigt jedoch, dass es verschiedene Möglichkeiten gibt, die vertraglichen Rahmenbedingungen einzuhalten und die Vorteile durch agiles Vorgehen zu nutzen. In dieser Arbeit werden Grundlagen zu agilen Vorgehensmodellen am Beispiel von Scrum im Kontext der gesetzlichen Regelung nach 640 BGB (Abnahme bei Werkverträgen) erläutert und aufgezeigt, welche Möglichkeiten IT-Dienstleister als auch Auftraggeber haben, agiles Vorgehen und die werkvertragliche Abnahme in Harmonie zu bringen. 1 OOSE-Group [2013]. 2 OOSE-Group [2013]. 3 BGB [2013a]. 4 BGB [2013a]. Michael Kirsch 1

4 2 Eigenschaften agiler IT-Projekte 2 Eigenschaften agiler IT-Projekte In der IT-Praxis ist der Begriff agil allgegenwärtig und kann als Trend gesehen werden, sodass viele IT-Dienstleister gerne auf der Höhe der Zeit sein und demnach auch agile IT- Projekte durchführen möchten. Erfahrungsgemäß werden all zu oft Projektmethoden als agil bezeichnet, obwohl sie es nicht sind und eher Abwandlungen klassischer Vorgehensmodelle darstellen. Um erkennen zu können, wann ein IT-Projekt agil ist, gibt es drei grundlegende Eigenschaften die alle agilen IT-Projekte gemein haben. Sie werden im Folgenden vorgestellt. Dabei sind sie unabhängig von den tatsächlich eingesetzten agilen Methoden wie bspw. Scrum, XP (Xtreme Programming) oder Kanban. 2.1 Hohe Flexibilität Agile Entwicklungsmethoden kommen ohne Pflichtenhefte aus. Der Auftraggeber gibt am Anfang des Projektes nur einige wenige Basisfunktionalitäten vor und es startet sofort ohne Verzögerung. Während des Projektverlaufs können jederzeit neue Anforderungen definiert bzw. bestehende Anforderungen geändert werden, z.b. weil festgestellt wurde, dass die Software andere Merkmale haben muss als bisher angenommen, oder weil sich die Wettbewerbssituation geändert hat. Durch dieses iterative Vorgehen können Erfahrungen aus dem laufenden Projekt in den weiteren Entwicklungsprozess mit einfließen und es wird nur das entwickelt, was tatsächlich von Nutzen ist Hohe Qualität Entwickler möchten sich mit ihrer Arbeit identifizieren und gute Software erstellen. Agile Methoden liefern dafür den passenden Rahmen: So werden die Aufwände von den Entwicklern selbst geschätzt und können dadurch früh auf mögliche Probleme hinweisen. Durch das zyklische Vorgehen können regelmäßig individuelle Messungen für das jeweilige Projekt vorgenommen werden, so dass jeder im Entwicklungsteam direkt aus seinen eigenen Erfahrungen lernen kann und stets eine realistische Vorstellung der tatsächlichen Entwicklungsgeschwindigkeit besteht. So ist die Wahrscheinlichkeit für einen zeitlichen Verzug aufgrund überzogener Anforderung geringer Geringer Zeitaufwand Zum Erfolg von Entwicklungsprojekten trägt einfache und effiziente Kommunikation mindestens ebenso bei wie die eingesetzten Technologien. Deswegen arbeiten die Entwickler in agilen Projekten meist beim Auftraggeber vor Ort und stehen in ständigen Kontakt mit ihm. 5 [Vgl. Opelt u. a. 2012, S.10]. 6 [Vgl. Opelt u. a. 2012, S.11]. Michael Kirsch 2

5 2 Eigenschaften agiler IT-Projekte Details können so schnell geklärt, Missverständnisse sofort beseitigt werden. Weil die Entwickler regelmäßig Feedback vom Auftraggeber erhalten, wird die Gefahr minimiert, dass die Entwicklung in eine falsche Richtung gelenkt wird. Darüber hinaus kann sich der Auftraggeber jederzeit den aktuellen Systemzustand vorführen lassen, er behält so stets den Überblick und die Kontrolle über das Projekt. 7 7 [Vgl. Opelt u. a. 2012, S.12]. Michael Kirsch 3

6 3 Vertragsrechtliche Einordnung von agilen IT-Projekten 3 Vertragsrechtliche Einordnung von agilen IT-Projekten Wie in der Einleitung bereits erwähnt, zeigt die Erfahrung, dass die meisten klassischen IT-Projekte über einen Werkvertrag geregelt sind. Jedoch weisen agile IT-Projekte Charakteristika auf, die eine mögliche werkvertragliche Einordnung zu einem viel diskutierten Thema in der Praxis gemacht haben. In seiner Siloanlagen-Entscheidung vom hat der Bundesgerichtshof (BGH) die Relevanz des Planungsanteils am Gesamtprojekt als entscheidendes Kriterium für eine werkvertragliche Einordnung hevorgehoben und ausgeführt, dass eine Beschränkung des Anwendungsbereichs von 651 BGB dann anzunehmen sei, wenn die Planungsleistung so dominierend ist, dass sie den Schwerpunkt des jeweiligen Vertrages bilde. Die Planungsleistung wird gerade bei agilen Projekten hauptsächlich iterativ während der Entwicklung erbracht. So wird die vorvertragliche Planungsphase im Rahmen agiler Methoden (bspw. durch Verzicht auf die Erstellung einer detaillieren Spezifikation) durch den Planungsprozess ausgeglichen, der die gesamte Entwicklung begleitet. Dabei entwickelt der Auftraggeber auf Basis der Erkenntnisse aus vorherigen Entwicklungsschritten einen ständig weiter konkretisierten Katalog an Anforderungen. Diese finden in regelmäßigen Abständen Eingang in den Entwicklungsprozess. 9 Daraus folgt, dass sich ein durchgehender planerischer Aufwand des Auftragnehmers in Bezug auf die Umsetzung der sich iterativ konkretisierenden Anforderungen ergibt. Aufgrund dieser Art von Merkmalen erlangen die Planungsleistungen bei agilen Vorgehensweisen eine enorme Bedeutung des Vertrags. Demnach stellt die Planung nicht einen abgeschlossen Teil dar, der bspw. vor der Implementierung weitestgehend abgeschlossen sein muss, sondern vielmehr den Kern des Vertrags. Der Planungs- und Anpassungsprozess läuft parallel zu allen anderen Prozessen und schließt somit eine Außerachtlassung des Planungsanteils als reine Vorbereitungshandlung nach den Grundsätzen des BGH aus. Im Bezug auf die Siloanlagen-Entscheidung des BGH spricht der planerische Schwerpunkt bei agilen Projektmethoden daher eher für eine generelle werkvertragliche Einordnung derartiger Verträge. 10 Die Einordnung von agilen IT-Projekten ist nach wie vor stark umstritten und die dargelegte Argumentation ist nur eine von vielen, agile Projekte einer Vertragsart zuzuordnen. Im weiteren Verlauf der Arbeit wird ausschließlich vom Vertragstyp Werkvertrag ausgegangen. 3.1 Merkmale des Werkvertrags Der Werkvertrag wird in den BGB geregelt. Im Folgenden werden die grundlegend relevanten Teile für diese Arbeit kurz erläutert. 8 [Vgl. BGH 2010]. 9 [Vgl. Fuchs Anke 2012, S.437]. 10 [Vgl. Witte 2010a]. Michael Kirsch 4

7 3 Vertragsrechtliche Einordnung von agilen IT-Projekten Vertragstypische Pflichten beim Werkvertrag nach 631 BGB (1) Durch den Werkvertrag wird der Unternehmer zur Herstellung des versprochenen Werkes, der Besteller zur Entrichtung der vereinbarten Vergütung verpflichtet. 11 (2) Gegenstand des Werkvertrags kann sowohl die Herstellung oder Veränderung einer Sache als auch ein anderer durch Arbeit oder Dienstleistung herbeizuführender Erfolg sein. 12 Daraus ergeben sich die folgenden Pflichten für den Auftraggeber als auch für den Auftragnehmer 13 Der Auftragnehmer hat die Erfolgsverantwortung Der Auftraggeber wirkt mit (Mitwirkungsleistung) Der Auftragnehmer hat die Projektleitung, auch wenn sie ihm nicht explizit übertragen wird Der entscheidende wichtige Punkt an dieser Stelle ist, dass der Auftraggeber die Pflicht hat, an der Herstellung des Werkes seinen Anteil zu leisten. Dies ist besonders im Bezug auf die Anwendung von agilen Projektmethoden wichtig, da ohne ein aktives Mitwirken des Auftraggebers ein agiles IT-Projekt von Beginn an zum Scheitern verurteilt ist. Zudem ist sein Mitwirken bei der iterativen Erstellung und Detaillierung der Anforderungen unerlässlich. Abnahme nach 640 BGB Die werkvertragliche Abnahme wird in 640 BGB geregelt. Im Folgenden wird der Inhalt des Paragraphen dargestellt und die relevanten Inhalte für diese Arbeit ausgeführt. (1) Der Besteller ist verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen, sofern nicht nach der Beschaffenheit des Werkes die Abnahme ausgeschlossen ist. Wegen unwesentlicher Mängel kann die Abnahme nicht verweigert werden. Der Abnahme steht es gleich, wenn der Besteller das Werk nicht innerhalb einer ihm vom Unternehmer bestimmten angemessenen Frist abnimmt, obwohl er dazu verpflichtet ist. 14 (2) Nimmt der Besteller ein mangelhaftes Werk gemäß Absatz 1 Satz 1 ab, obschon er den Mangel kennt, so stehen ihm die in 634 Nr. 1 bis 3 bezeichneten Rechte nur zu, wenn er sich seine Rechte wegen des Mangels bei der Abnahme vorbehält. 15 Besonders relevant ist Absatz 1 des 640 BGB: Der Besteller ist verpflichtet, das vertragsmäßig hergestellte Werk abzunehmen[...]. Ist ein Werk vertragsgemäß erstellt worden, so ist der Besteller dazu verpflichtet eine Abnahme durchzuführen, also zu bestätigen, dass das Werk die im Vertrag definierten Anforderungen erfüllt. Um eine Abnahme des Werkes zu erreichen ist aus Sichtweise des Dienstleister demnach unabdingbar zu wissen, welche Anforderungen erfüllt werden müssen, bevor dieser mit der Erstellung beginnen kann. Bei klassischen IT- Projekten ist es der Regelfall, das eine (ausreichend detaillierte) Spezifikation vorliegt, auf die 11 [BGB 2013b]. 12 [BGB 2013b]. 13 [Vgl. Sarre 2013, S. 112]. 14 [BGB 2013a]. 15 [BGB 2013a]. Michael Kirsch 5

8 3 Vertragsrechtliche Einordnung von agilen IT-Projekten sich sowohl Auftraggeber und Auftragnehmer bei Vertragsabschluss stützen. Auf Basis dieser Spezifikation wird das vom Auftraggeber gewünschte Werk vom Auftragnehmer erstellt. Am Ende der Entwicklung entsteht im Idealfall ein Gewerk, dass den im Vertrag definierten Anforderungen entspricht. Auf Basis dieser Anforderungen führt der Auftraggeber die Abnahme durch. Nun stellt sich die Frage, wie ein Werk abgenommen werden kann, dessen Anforderungen nicht von Anfang an detailliert definiert wurden und bei Unterzeichnung des Vertrages demnach nicht dessen Bestandteil waren. Bevor auf diese Fragestellung im Detail eingegangen werden kann, sind jedoch noch weitere Grundlagen aus dem Bereich der agilen Softwareentwicklung nötig. 3.2 Merkmale agiler IT-Projekte Projekte bei denen agile Methoden angewendet werden unterscheiden sich grundlegend von klassischen Projekten. Im Folgenden werden drei für die werkvertragliche Abnahme relevante Eigenschaften betrachtet Zeitplanung und Vergütung Das agile Modell versucht, zwei angebliche Widersprüche zu vereinen: Zum einen enthalten Werkverträge einen Festpreis (bzw. Festpreisobergrenze) für das Gesamtprojekt und Konsequenzen, falls der Preis überschritten wird, obwohl zum Umfang nichts dazugekommen ist, ohne etwas anderes wegzunehmen (Exchange for free). Eine Konsequenz ist z.b. die Halbierung des Preises für einzelne User Stories (im agilen Umfeld v.a. bei Scrum verwendete Art von Funktionsbeschreibung). Ist der Auftraggeber besonders an der Leistungserbringung für das gesamte Projekt interessiert, kann auch vereinbart werden, dass bei Projektabbruch durch den Auftragnehmer die verbleibenden x % (z. B. 20 %) für die Endabnahme nicht mehr ausbezahlt werden. Zum anderen basiert der Preis auf einem beweglichen System zur finalen Leistungsdefinition in Form einer Vision des Auftraggebers, User Stories, Themen sowie Sprints zur Umsetzung. Beendet der Auftragnehmer die Kooperation, weil etwa das Projekt die wirtschaftlichen Erwartungen nicht erfüllt, wird er sich regelmäßig darauf berufen, dass sich die Rahmenbedingungen für das gemeinsame agile Vorgehen erheblich geändert hätten und die Umsetzung daher nicht zum vereinbarten Festpreis möglich sei. 16 Diese Möglichkeit kann wie durch eine Art Risikoteilung zu Lasten des Auftragnehmers unattraktiver gestaltet werden. Gerade das gemeinsame Scheitern ist aber bei einem agilen Projekt in der Regel weniger problematisch und kostenintensiv als bei einem klassischen IT-Projekt. Der Grund dafür liegt im agilen Modell selbst und dessen Grundsatz, wonach jeder Sprint für sich selbst nutzbar ist und das Projekt in jeder Phase gegebenenfalls vom Auftraggeber selbst oder einem Dritten fortgesetzt oder weiterentwickelt werden kann. Durch die Sanktionen bei Nichteinhaltung des Maximalpreisrahmens ist es für den Auftragnehmer nicht attraktiv, das Projekt in die Länge zu ziehen. Außerdem ist es auch tatsächlich nicht möglich, weil der Auftraggeber die Sprints abnimmt und dadurch einen genauen Überblick über den Stand der Dinge bekommt. Das agile Modell setzt allerdings voraus, dass sich der Auftraggeber aktiv beteiligt - und das muss im Vertrag klar verankert werden. Den Mitwirkungsverpflichtungen des Auftraggebers ist somit großes Augenmerk zu schenken, da diese für den Projekterfolg unmittelbar notwendig sind. 17 Bei größeren Projekten kann es zielführend sein, die Zahlung nicht nur an 16 [Vgl. Opelt u. a. 2012, S. 113]. 17 [Vgl. Opelt u. a. 2012, S. 200]. Michael Kirsch 6

9 3 Vertragsrechtliche Einordnung von agilen IT-Projekten die Abnahme von Sprints zu binden, sondern einen Teil der Zahlung abgenommener Sprints an besondere Meilensteine zu binden - z.b. für die Realisierung eines Themas. Mit welchen Konsequenzen Meilensteine gebrochen oder verschoben werden können, muss von Fall zu Fall der Vertrag definieren (z. B. Reduktion der Zahlung, Recht zum Ausstieg) Definition des Leistungsgegenstands Das wesentliche Charakteristikum agiler Projekte besteht darin, dass der Vertragsgegenstand im Vorfeld - also zum Zeitpunkt des Vertragsabschlusses - noch nicht im Detail definiert und spezifiziert sein muss. Allerdings muss zu Beginn des Projekts ein guter Überblick darüber herrschen, welches Resultat das Projekt bringen soll. Es muss eine Beschreibung des Vertragsgegenstandes auf einem gewissen Detaillevel geben. Das braucht zum einen der Auftraggeber, um intern den entsprechenden Business Case zu argumentieren und um einen geeigneten Dienstleister zu wählen. Zum anderen ist es für den Lieferanten notwendig, um zu Beginn ein vollständiges Bild der Gesamtanforderung zu haben. Dem agilen Vorgehen ist inhärent, dass ein Projekt auf Basis einer Produkt- oder Projektvision definiert wird. Wie zum Beispiel Roman Pichler schreibt, ist es essenziell, dass das gesamte Team vom Product Owner bis zum einzelnen Teammitglied diese Vision mitträgt. 19 Deshalb wird als ein erster Meilenstein die Vision als zentrales Element im Vertrag verankert. Beispielhaft kann wie folgt beschrieben werden, was ein Softwaresystem aus Sicht des Auftraggebers leisten muss. 1. Begonnen wird mit den Themen, die die wesentlichen Bereiche auflisten, die das Projekt umfasst. 2. Dann wird weiter in Epics verfeinert, die eine inhaltlich zusammenhängende Gruppe von User Stories repräsentieren. 3. Auf der granularsten Detailebene weisen die User Stories Eigenschaften entsprechend dem Akronym INVEST auf: Independent, Negotiable, Valuable, Estimatable, Small, Testable. Das heißt, es sind Anforderungen, die umgesetzt werden können und auch als einzelne Elemente bereits einen Mehrwert für den Auftraggeber darstellen Mitwirkungsleistung des Auftraggebers Gerade bei agilen Projekten ist es unabdingbar, dass der Auftraggeber aktiv an der Entwicklung beteiligt ist. Im Vergleich zu klassischen IT-Projekten ist die Mitwirkungsleistung sehr viel höher, was für den Auftraggeber anfangs befremdlich wirkt. Das erfordert u.a. auch einen hohen Kommunikations- und Arbeitsaufwand des Auftraggebers, da er in Scrum oft die Rolle des Product Owner (Produktverantwortlicher) inne hat bzw. sie indirekt erhält, wenn der Product Owner vom Dienstleister gestellt wird. Die Teilnahme an täglichen Meetings, die aktive und regelmäßige Kontrolle der geleisteten Arbeit sowie die Einhaltung kurzer Kommunikationswege und gute Erreichbarkeit sind nur einige wenige Pflichten, die auf den Auftraggeber dabei zu kommen. Dafür erhält er jedoch alle Vorteile, die ein agiles Vorgehensmodell bietet. 18 [Vgl. Opelt u. a. 2012, S. 115]. 19 [Vgl. Pichler 2010, S. 115]. Michael Kirsch 7

10 3 Vertragsrechtliche Einordnung von agilen IT-Projekten Abbildung 3.1: Detaillierung der Vision des Auftraggebers 20 Michael Kirsch 8

11 4 Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum 4 Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum Nachdem ein knappes Verständnis von agilen Projektmethoden vermittelt wurde, behandelt der folgende Abschnitt, welche Rolle Scrum bei der Vertragsgestaltung von agilen IT- Projekten haben kann. Scrum wird fälschlicherweise oft als Vorgehensmodell bezeichnet, jedoch ist es das nicht. Scrum ist ein Framework, dass die Entwicklung komplexer Produkte unterstützen und vereinfachen soll. Dabei werden Scrum Teams definiert und jedem Teammitglied wird eine vordefinierte Rolle zugewiesen, die es erfüllen muss. Es gibt in jedem Team einen Product Owner, einen Scrummaster und das Entwicklungsteam. Scrum Teams arbeiten interdisziplinär und sind vollkommen selbstorganisiert. Sie entscheiden selbstständig und im Team, wie sie die Arbeit am besten umsetzen und planen. Es gibt dabei keine höhere Instanz die dem Team vorgibt, wie sie ihre Arbeit bewältigen soll. Dabei muss darauf geachtet werden, dass Scrum Teams aus ausreichend qualifizierten Personen bestehen, die von niemand anderem abhängig sind, sodass sie die Probleme selbstständig lösen können. Scrum verwendet ein iteratives Vorgehensmodell, um das Produkt in regelmäßigen Abständen zu liefern. Dabei erreicht das Produkt immer einen auslieferbaren, abnahmebereiten Stand und wird von Iteration zu Iteration inkrementell erweitert. Welche Anforderungen bestehen und welche Inhalte in einem Sprint umgesetzt werden, wird in den Backlogs definiert. Um Anforderungen zu spezifizieren werden User Stories verwendet, die es erlauben, kompakte Arbeitspakete zu erstellen und diese in einem Sprint umzusetzen. Die Arbeitspakete enthalten in sich abgeschlossene Funktionalitäten, die am Ende eines Sprints abgenommen werden können. Das impliziert, dass am Ende eines Sprints immer ein lauffähiger Softwarestand zur Verfügung steht Rollenverteilung in Scrum Scrum beschreibt verschiedene Rollen in einem Scrum Team. In Bezug auf die Vertragsgestaltung ist die Rolle des Product Owner von größter Bedeutung, da er u.a. für die Anforderungsdefinition verantwortlich ist. Um die Rolle ins Gesamtbild einordnen zu können, werden zudem die Rollen des Scrum Master und des Entwicklungsteam beschrieben Product Owner Der Product Owner 23 ist für den Leistungsgegenstand (das Produkt oder das Gewerk) sowie für die geleistete Arbeit des Entwicklungs-Teams verantwortlich und hat zudem das Ziel den 21 [Vgl. Opelt u. a. 2012, S. 13]. 22 [Vgl. Ken Schwaber 2011, S. 5]. 23 [Vgl. Ken Schwaber 2011, S. 5]. Michael Kirsch 9

12 4 Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum Wert des Produkts zu maximieren. Er ist der Einzige, der das Product Backlog verantwortet und verwaltet. Die Verwaltung besteht aus den folgenden Punkten: Klare Formulierung der Einträge im Product Backlog Die Anordnung der Einträge in der gewünschten Fertigstellungsreihenfolge Sicherstellung, dass das Team die Arbeit rechtzeitig erfolgreich abschließt Sicherstellung, dass das Product Backlog für alle Beteiligten einsehbar und klar definiert ist Aktualisierung und Qualitätssicherung des Product Backlog, sodass immer ersichtlich ist, an was das Scrum Team momentan und als nächstes arbeitet Klare und verständliche Vermittlung der Inhalte des Product Backlog an das Scrum Team Scrum Master & Entwicklungsteam Der Scrum Master 24 ist prinzipiell dafür verantwortlich, dass Scrum richtig angewendet wird. Jedoch ist er dem Product Owner unterstellt und unterstützt diesen in dem er bspw. Techniken zur effektiven Verwaltung des Product Backlogs etabliert, oder Vision, Ziele und Einträge aus dem Product Backlog gegenüber dem Entwicklungs-Team klar kommuniziert. 4.2 Scrum-Artefakte als mögliche Basis zur Abnahme In klassischen Vorgehensmodellen, wie bspw. dem Wasserfallmodell, ist die Grundvoraussetzung für die Konstruktion und Implementierung einer Software die ausgearbeitete Spezifikation. Sie enthält im Regelfall eine umfassende und möglichst detailierte Beschreibung der Anforderungen. Im Gegensatz dazu, wird eine solch detaillierte Spezifikation bei agilen Projekten gerade nicht gefordert. Vielmehr sollen die gewünschten Funktionen und Anforderungen der Software beschrieben werden. Die genauere und detailliertere Beschreibung erfolgt sukzessive im Verlauf des Projekts. Für eine werkvertragliche Abnahme ist es jedoch nach 640 (1) BGB essenziell, einen Nachweis darüber zu haben, was als Leistungsgegenstand vereinbart wurde. Ansonsten ist die Überprüfung, ob ein Werk vertragsgemäß hergestellt wurde nur sehr schwer möglich. Im Folgenden werden verschiedene Scrum-Artefakte als mögliche Basis für eine werkvertragliche Abnahme vorgestellt Product Backlog Das Product Backlog 25 enthält alle Anforderungen, die in einem Produkt enthalten sein könnten: Features, Funktionen, Verbesserungsvorschläge, Fehlerbehebungen und weitere. Vor Beginn des ersten Sprints müssen der Auftraggeber und der Dienstleister in Zusammenarbeit das Product Backlog erstellen. Letztendlich kann der Auftraggeber die Anforderungen auch alleine definieren, jedoch ist es für Scrum grundlegend, dass alle Beteiligten eng zusammenarbeiten. Vor Beginn der Arbeiten am Produkt werden zunächst alle Anforderungen an den 24 [Vgl. Ken Schwaber 2011, S. 7]. 25 [Vgl. Ken Schwaber 2011, S. 14]. Michael Kirsch 10

13 4 Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum Vertragsgegenstand beschrieben, priorisiert und in das Product Backlog eingetragen. Dies umfasst alle Anforderungen des zu erstellenden Vertragsgegenstandes. Die daraus resultierende genauere Spezifikation für einen Teil des Vertragsgegenstandes wird anschließend in das Product Backlog eingetragen. Zudem wird über den gesamten Verlauf des Projekts die Priorisierung immer wieder angepasst. Zur Beschreibung der Anforderungen an den Vertragsgegenstand im Product-Backlog wird jeweils knapp ein Szenario oder Vorgang beschrieben, in dem sich der Vertragsgegenstand auf eine bestimmte Weise verhält. Das sind in Scrum die sogenannten User Stories. Die Beschreibungen werden allgemeinverständlich unter Verwendung der Terminologie des Auftraggebers formuliert und sind jeweils selbständig - soweit möglich. Eintragungen des Product Owner in das Product Backlog stellen die Ausarbeitung der mit dem Auftraggeber abgestimmten Anforderungen an den Vertragsgegenstand dar. Dem Auftraggeber wird in regelmäßigen Abständen eine aktualisierte Version des Product Backlogs zur Verfügung gestellt Sprint Backlog Vor Beginn eines jeden Sprints findet das Sprint Planning Meeting (SPM) statt. An diesem Treffen sind auf Seiten des Auftragnehmers der Scrum Master, sowie die Programmierer, die für die Entwicklung des Vertragsgegenstandes verantwortlich sind beteiligt. Auf Seitens des Auftraggebers ist der Product Owner, sowie weitere in Frage kommenden Personen (wie bspw. Vertreter des Fachbereichs). Basierend auf dem Product Backlog werden Anforderungen ausgewählt, die im jeweiligen Sprint umgesetzt werden. Anforderungen mit einer hohen Priorisierung werden vorrangig ausgewählt und umgesetzt. Die zur Umsetzung im nächsten Sprint ausgewählten Anforderungen werden im SPM weiter spezifiziert. Eine genauere Spezifizierung der Anforderung sollten neben detaillierten Beschreibungen u.a. auch Testszenarien enthalten. Die Testszenarien sollten die Anforderungen vom Auftraggeber und demnach auch des Product Backlogs widerspiegeln. Dabei sollte gefordert werden, dass der Vertragsgegenstand sich in einer bestimmten Weise verhalten und spezifische Ergebnisse liefern muss. Darüber hinaus sollte auch beschrieben werden unter welchen Rahmenbedingungen die Tests durchgeführt werden sollen (Softwareplattform, Betriebssystemversion, Servicepack- und Patchlevel usw.). 26 Die ausgearbeiteten Anforderungen werden zu Beginn eines neuen Sprints vom Product Backlog in das Sprint Backlog übertragen. Ein Sprint Backlog ist ein Teil des Product Backlogs. Zudem werden in den SPM die Aufwände für die Umsetzung der in diesem Sprint geplanten Anforderungen geschätzt. Ziel der Planung ist es, bis zum Ende des Sprints ein lauffähiges, theoretisch auslieferbares Produktinkrement vom Vertragsgegenstand fertigzustellen, das die Anforderungen des Sprint Backlog für den jeweiligen Sprint erfüllt. Ebenso müssen bisherige Funktionen und umgesetzte Anforderungen aus evtl. vorherigen Sprints funktionsfähig sein. Um eine kontinuierliche Qualitätssicherung zu gewährleisten ist es ebenso von Interesse, wenn für jeden Sprint Testszenarien entworfen und anhand derer die Funktionalität überprüft wird. Der Auftraggeber wird genauso wie beim Product Backlog ständig über Änderungen informiert und erhält regelmäßig eine Kopie des Sprint Backlogs. Verbindlichkeit Damit Product Backlog als auch Sprint Backlog als vertragliche Beschreibung des Leistungsgegenstands verwendet werden können, bedarf es der Zustimmung beider Seiten über deren 26 [Vgl. Ken Schwaber 2011, S. 15]. Michael Kirsch 11

14 4 Vertragsgestaltung von agilen IT-Projekten am Beispiel von Scrum Inhalte. Auftraggeber als auch Dienstleister sind mit den Änderungen, Einträgen und Ergänzungen einverstanden, insofern sie nicht innerhalb einer geeigneten Frist widersprechen. So könnte bspw. spätestens zu Beginn eines Sprints eine Frist für beide Parteien gesetzt werden, bis zu der sie widersprechen können. Wurde bis dahin kein Widerspruch eingelegt, gilt der Sprint Backlog als verbindlich und wird in diesem Moment Teil der Leistungsbeschreibung, die als Basis für die Abnahme verwendet wird. Die Gesamtheit aller Sprint Backlogs und die Kombination mit dem Product Backlog wird ebenso als verbindliche Beschreibung des Leistungsgegenstandes gesehen. Bei Widersprüchen zwischen diesen beiden Backlogs haben zeitlich nachfolgende Sprint Backlogs Vorrang Definition of Done Die Definition of Done 27 ist in erster Linie für das Scrum Team gedacht, damit es nachprüfen kann, ob eine User Story anforderungskonform umgesetzt wurde. Sie ist mehr eine Checkliste und kann die folgenden Ausprägungen haben: Definition of Done für ein Feature (Story oder Product Backlog Item) Definition of Done für einen Sprint (Menge an Features, die in einem Sprint implementiert wurden) Definition of Done für ein Release (potentiell auslieferbarer Zustand) Auf Basis der Definition of Done für einen Sprint, ist es möglich, die Funktionalität grob zu überprüfen, jedoch ersetzt es in keinster Weise die Durchführung von Tests und Überprüfung der Korrektheit anhand von Testszenarien [Vgl. Scrumalliance 2008]. 28 [Vgl. Ken Schwaber 2011, S. 16]. Michael Kirsch 12

15 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum Nachdem deutlich wurde, dass agile Projekte durchaus einen werkvertraglichen Charakter haben können und wie Scrum die Erstellung eines Werkvertrages beeinflussen kann, wird im Folgenden erläutert, wie eine werkvertragliche Abnahme durchgeführt werden kann. Dabei sind die bisherigen gesammelten Erkenntnisse von grundlegender Bedeutung. 5.1 Teilabnahmen / Gesamtabnahme Bei Scrum ist nach jedem Sprint ein funktionierender Stand der Software vorhanden, der (im Idealfall) abgeschlossene Funktionen (User Stories) beinhaltet. Es bietet sich an, die bereits entwickelten Funktionen im Anschluss eines Sprints in Form von Teilabnahmen abzunehmen. 29 Dadurch erkennen sowohl Auftraggeber als auch Auftragnehmer, ob in der vorrangegangenen Arbeit Kommunikationsprobleme auftraten und ob für den kommenden Sprint vorgenommen werden müssen. Hierbei ist zu erwähnen, dass selbst mit Teilabnahmen der Verjährungfrist für Mängelrechte ( 634 a (2) BGB) beginnt und es dazu kommen kann, dass die Frist abgelaufen ist, bevor das Gesamtwerk erstellt ist. 30 Zum Zweck der Abnahme in sich abgeschlossener Teile findet am Ende eines jeden Sprints und vor Beginn des jeweils nächsten Sprints ein Treffen statt, in dem das Ergebnis des letzten Sprints in Form des aktuellen Entwicklungsstands vorgeführt wird. Dabei wird der Vertragsgegenstand anhand der in dem jeweiligen SPM festgelegten Tests auf seinen vertragsgemäßen Zustand hin überprüft. Anforderungen, die erfüllt sind, werden im Sprint Backlog des jeweiligen Sprints entsprechend gekennzeichnet. Anforderungen, die nicht erfüllt sind, werden in das Product Backlog wieder eingepflegt und in einem späteren Sprint umgesetzt. Sie gelten als nicht abgenommen Anforderungen, die im Sprint Backlog als erfüllt gekennzeichnet oder in das Product Backlog nicht wieder eingepflegt werden, gelten als abgenommen, wenn der Auftraggeber nicht spätestens in dem auf den Zugang der Änderungen an dem Product Backlog bei dem Auftraggeber folgenden Sprint Planning Meeting die Abnahme ausdrücklich verweigert. Auf Anforderung des Auftragnehmers erklärt der Auftraggeber ausdrücklich die Abnahme dieser Leistungen. Alternativ könnte auch eine Sprint- und Releaseplanung vorgenommen werden, wenn absehbar ist, dass nicht jeder Sprint zu einem tatsächlich auslieferbaren (Teil-)Produkt führt. In der Planung wären dann jeweils Release-Sprints vorzusehen, an deren Ende die jeweiligen Teilleistungen abgenommen werden könnten. Das Werk gilt als fertiggestellt, wenn das Product Backlog keine offenen Anforderungen mehr enthält. Hier ist es ratsam, im Vertrag eine Frist zu setzen, bis wann der Auftraggeber die Endabnahme durchgeführt haben muss. Bei der Endabnahme werden alle verbleibenden Anforderungen abgenommen, die noch nicht in 29 [Vgl. Auer-Reinsdorff 2010, S. 469]. 30 [Vgl. MIP-Consult 2008, S. 8]. 31 [Vgl. Hofmann 2010, S. 7]. 32 [Vgl. Capgemini 2013, S. 15]. Michael Kirsch 13

16 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum Teilabnahmen abgenommen worden sind sowie nicht funktionale Anforderungen wie die Performance des Gesamtsystems. 33 Werden Mängel entdeckt, so werden sie erst verschiedenen Mangel-Kategorien zugeordnet und anschließend beurteilt, ob sie einer Schlussabnahme im Wege stehen (siehe dazu auch Abschnitt ). 5.2 Zeitliche Planung der Abnahme Abhängig vom gewählten Vorgehen (Teilabnahmen und/oder Gesamtabnahme) wir die Abnahme jeweils am Ende des Sprints erfolgen. Ein guter Zeitpunkt für den Beginn der Abnahmefrist ist die Sprint Review, bei der Product Owner, Scrum Team und interessierte Stakeholder (bspw. Projektleitung des Auftraggebers) anwesend sind. Bei diesem Treffen werden die Ergebnisse vorgestellt und wie der Sprint verlaufen ist. Bevor mit dem zweiten Sprint fortgefahren wird, ist es ratsam, das Werk dem Auftraggeber vorzuführen und wichtiges Feedback für den weiteren Verlauf einzuholen Abnahmegegenstände Basierend auf den Anforderungen, die im Product Backlog dokumentiert sind und in einem Sprint umgesetzt werden, ist jeweils die Funktionalität, die im Sprint Backlog beschrieben ist, der Abnahmegegenstand. Das bedeutet, dass der Auftraggeber n der Regel selbst dafür verantwortlich ist, welche Anforderungen in welchem Sprint umgesetzt werden und demnach auch wann welche Funktionen zur Abnahme zur Verfügung stehen. Eine Teilabnahme beinhaltet den Source Code, die Funktionalität und die Dokumentation des gelieferten Softwareinkrements. Wenn spätere Änderungen im Umfang zu Änderungen bei schon teilabgenommenen Funktionalitäten führen, ist dieser Aufwand entweder durch Reduktion des Umfangs im Maximalpreisrahmen auszugleichen oder als Zusatzaufwand außerhalb der Regelung des Risikoverteilung zu betrachten Bereitstellung der Abnahmegegenstände Damit der Auftraggeber das Gewerk testen und abnehmen kann, muss es ihm auch zur Verfügung gestellt werden. Dazu empfiehlt es sich, dass der Abnahmegegenstand in der Umgebung installiert wird, in der er später auch eingesetzt werden soll. Zudem muss ein Termin vereinbart werden, wann der Vertragsgegenstand zum Test und zur Abnahme bereit stehen soll. Dieser Termin muss rechtzeitig allen Beteiligten mitgeteilt werden, sodass der Auftraggeber als auch der Auftragnehmer ihre Ressourcen planen können [Vgl. Schneider, S. 21 f]. 34 [Vgl. Capgemini 2013, S. 23]. 35 [Vgl. Hofmann 2010, S. 9]. 36 [Vgl. Opelt u. a. 2012, S. 69]. 37 [Vgl. Osterhage 2009, S. 69]. Michael Kirsch 14

17 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum 5.5 Abnahmekriterien, Testfälle und Testdaten Basierend auf vorhergehend definierten Testszenarien und Testdaten sollten Testfälle definiert werden. Diese Testfälle spiegeln die Funktionalität, die im Sprint Backlog und Product Backlog beschrieben sind wider. Eine Möglichkeit ist es, die gesamte Entwicklung als Test Driven Development durchzuführen, sodass vor Beginn der Entwicklung erst die Testfälle formal beschrieben und vom Auftraggeber offiziell auf Korrektheit bestätigt werden. In jedem Fall sollten die Testfälle die User Stories und Einträge des Sprint Backlog der Version widerspiegeln, die zur Abnahme steht. Falls spezielle Testdaten gefordert werden, bspw. bei einer einhergehenden Datentransformation aus einem vorherigen Softwaresystem, muss dies im Vertrag aufgenommen werden. Als Abnahmekriterium wird in der Praxis oft eine vorher definierte Testabdeckung gefordert. Fehler, die bestimmten Fehlerklassen zugeordnet werden können, bspw. keine kritischen Fehler, sind ebenso ein geeignetes Abnahmekriterium. Oft kommt es hierbei zu Unstimmigkeiten zwischen Auftraggeber und Auftragnehmer, ob ein Fehler dieser oder jeder Klasse angehört, denn abhängig davon kann die Abnahme erfolgen oder auch nicht erfolgen Stellung der Testumgebung Vor Beginn der Abnahme sollte vertraglich vereinbart werden, wer die Testumgebung stellt. In der Regel wird es bei großen IT-Projekten mehrere Testumgebungen beim Dienstleister als auch beim Auftraggeber geben, da die Software nicht sofort in den Betrieb gehen wird. Die Ausgestaltung der Testumgebungen müssen vertraglich geregelt werden. Ebenso muss hierbei auch festgelegt werden, welche Software und welchen Softwarestand (Patchlevel, Version usw.) die Testumgebung haben soll, auf der das Werk abgenommen wird. 5.7 Mangelkategorien Es gibt keine gesetzliche Grundlage, welche Fehlerklassen beschreibt und somit liegt es im Gestaltungsbereich der Vertragspartner wie Fehler klassifiziert werden. Der EVB-IT-System- Vertrag 39 gibt bspw. die folgenden Fehlerklassen/Mangelkategorien vor, die bei Bedarf auch abgeändert werden können. 1. Ein betriebsverhindernder Mangel liegt vor, wenn die Nutzung des Gesamtsystems unmöglich oder schwerwiegend eingeschränkt ist. 2. Ein betriebsbehindernder Mangel liegt vor, wenn die Nutzung des Gesamtsystems erheblich eingeschränkt ist. 3. Ein leichter Mangel liegt vor, wenn die Nutzung des Gesamtsystems ohne oder mit unwesentlichen Einschränkungen möglich ist. 4. Ein trivialer Mangel liegt vor, wenn die Nutzung des Gesamtsystems nicht eingeschränkt ist (Rechtschreibfehler usw.) 38 [Vgl. Capgemini 2013, S. 15]. 39 [des Inneren 2008]. Michael Kirsch 15

18 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum Aus juristischer Sichtweise werden Mängel bzw. der Umgang mit Mängeln bei einem Werkvertrag in erster Linie in den a BGB geregelt. Werden Mängel festgestellt, können diese im nächsten Sprint behoben werden. Handelt es sich um den letzten Sprint und werden gravierende, betriebsverhindernde Mängel festgestellt, muss keine Abnahme durch den Auftragnehmer erfolgen. Wie Mängel kategorisiert werden beschreibt der EVB-IT-Systemvertrag nicht. Diese Einordnung müssen die Vertragspartner individuell aushandeln Formen und Erklärung der Abnahme Die Abnahme ist eine rechtsgeschäftliche Erklärung des Auftraggebers, an die zahlreiche Rechtsfolgen geknüpft sind. Allgemein werden die folgenden Abnahmeformen unterschieden: 41 Ausdrückliche oder erklärte Abnahme förmliche Abnahme fiktive Abnahme ( 640 Abs. 1 Satz 3 BGB) konkludente Abnahme Bei der ausdrücklichen oder auch erklärten Abnahme wird vom Auftragnehmer mündlich oder schriftlich mitgeteilt, dass das Werk fertiggestellt und eine Abnahme möglich sei und setzt eine Frist. Nun hat der Auftraggeber bis Ende dieser Frist Zeit, das vollendete Werk zu testen. Wird die Frist vom Auftraggeber überschritten, gilt das Werk als abgenommen und man spricht von einer fiktiven Abnahme. Bei der förmlichen Abnahme bittet der Auftragnehmer den Auftraggeber schriftlich um Erklärung der Abnahme. Der Auftraggeber erstellt eine unterschriebene Abnahmebescheinigung, die er dem Auftragnehmer zusendet. Der Auftragnehmer wiederum unterschreibt diese Erklärung, womit eine förmliche Abnahme erfolgt ist. Hierbei ist zu beachten, dass der Auftraggeber nicht zwingend eine Unterschrift leisten muss, damit die förmliche Abnahme erfolgen kann. 42 Unter einer konkludenten Abnahme versteht man eine Abnahme durch schlüssiges Handeln. dies bedeutet, dass der Auftraggeber seinen Willen nicht ausdrücklich, sondern durch Handeln zum Ausdruck bringt, das hergestellte Werk als im Wesentlichen vertragsgerecht entgegenzunehmen. Dies wäre zum Beispiel erbracht, durch vorbehaltlose Zahlung der vereinbarten Summe, Auszahlung von Sicherheitsbeträgen und bestimmungsgemäße Ingebrauchnahme. 5.9 Wiederholung der Abnahme Kann eine Abnahme nicht erfolgen, so hat der Auftragnehmer die Möglichkeit der Nacherfüllung, die in 635 BGB geregelt wird. Dabei hat der Auftragnehmer die Möglichkeit die beanstandeten Mängel zu beseitigen, oder ein neues Werk zu erstellen, wobei er hierbei die Kosten für alle Aufwendungen selbst tragen muss. Falls die Kosten für eine Mangelbeseitigung unverhältnismäßig sind, kann er die Nacherfüllung auch verweigern. Wenn die Abnahme selbst nach der Nacherfüllung nicht möglich ist, kann unter Umständen 646 Vollendung statt Abnahme wirksam werden. 40 [Vgl. des Inneren 2008]. 41 [Vgl. Valuenet]. 42 [Vgl. Oberlandesgericht]. Michael Kirsch 16

19 5 Durchführung der Abnahme bei agilen IT-Projekten am Beispiel von Scrum 5.10 Scheitern der Abnahme Für den Fall, das der Auftraggeber die Abnahme des Werkes verweigert, müssen besondere Bestimmungen für Rücktritt und Schadensersatz geregelt werden. Grundsätzlich finden 636 BGB sowie Selbstvornahme und Minderung in 637 und 638 BGB Anwendung. Der Regelung bedarf auch das Vorgehen wenn die Software bereits beim Auftraggeber installiert ist und die Abnahme scheitert. Solange das Werk nicht abgenommen ist gehört es noch dem Auftragnehmer, was zu einem restlosen Deinstallieren der Software führt, also etwa auch dem (physikalischen) Löschen der Client- und Serversoftware auf den Systemen des Auftraggebers [Vgl. Koch 2009]. Michael Kirsch 17

20 6 Fazit 6 Fazit Alleine die juristische Einordnung von Verträgen über agile IT-Projekte ist ein Thema, das in der Praxis hohe Relevanz hat und sehr umstritten ist Dennoch zeigt die Praxis, dass agile Projekte auf dem Vormarsch sind und mit ihren charakteristischen Merkmalen erfolgreicher als bisherige Herangehensweisen sein können. Wenn beide Seiten wenig Erfahrung mit agilen Methoden haben besteht bei der Vertragsgestaltung vor allem das Risiko, dass der Vertrag nicht ausreichend formuliert ist und Raum für Streitfragen offen hält. Vor allem die erst im Laufe des Projekts entstehende Spezifikation kann ein großer Streitpunkt werden, wenn der Auftraggeber den relativ hohen Eigenanteil an der Entwicklung unterschätzt oder am Ende nicht alle geforderten Anforderungen erfüllt werden. Im Kontrast steht an dieser Stelle die eingangs erwähnte Studie, die besagt, dass agile Projekte erfolgreicher sind, obwohl der Auftraggeber nur grob weiß, was er am Ende für sein Geld bekommen wird. Scrum ist die sowohl in der Literatur als auch in der Praxis verbreitetste agile Methode. Auf Basis eines Werkvertrags ist es mit Scrum relativ einfach möglich, die gesetzlichen Anforderungen zu erfüllen und trotzdem agil zu sein. Die Spezifikation wächst von Sprint zu Sprint weiter an, ermöglicht kontinuierliche Anpassungen und durchlebt zudem eine Art Reifeprozess. Es wurde deutlich, wie Product Backlog als auch Sprint Backlog als Spezifikation- Ersatz dienen können und somit als Vorgabe bei der Abnahme verwendet werden kann. Die Tatsache, dass am Ende eines Sprints ein lauffähiger Softwarestand erreicht wird, lässt sich für Teilabnahmen nutzen. Eine Gesamtabnahme am Ende ist dennoch nicht ausgeschlossen, denn gerade Nicht-Funktionale Anforderungen beziehen sich häufig auf das Gesamtsystem, dass erst mit Vollendung des letzten Sprints abgeschlossen ist. Einige der besprochenen Themen innerhalb der Abnahme wie Mangelkategorien und Formen und Erklärung der Abnahme können unabhängig von agilen oder klassichen Projektmethoden betrachtet werden, da sie nur einen geringen oder gar keinen Einfluss auf sie haben. Vergleicht man sowohl die Herausforderungen als auch die Vorteile, die agiles Vorgehen mit sich bringt muss trotzdem jeder Auftraggeber als auch Auftragnehmer wissen, worauf er sich einlässt und vor allem, ob er sich selbst und sein Unternehmen dafür als geeignet ansieht. Agilität kann nicht einfach genutzt werden, sondern muss gelebt werden - von allen Beteiligten. 44 siehe Witte [2010b]. 45 siehe Kremer [2010]. 46 siehe Witte [2010b]. 47 siehe Fuchs Anke [2012]. 48 siehe Claus Müller-Hengstenberg [2008]. Michael Kirsch 18

21 Literaturverzeichnis Literaturverzeichnis Auer-Reinsdorff 2010 Auer-Reinsdorff: Siebers in Taeger, Digitale Evolution. ITRB, BGB 2013a BGB: Abnahme. Website, Online verfügbar unter BGB/640.html; aufgerufen am , 4, 14, 15 BGB 2013b BGB: Abnahme. Website, Online verfügbar unter BGB/631.html; aufgerufen am , 12 BGH 2010 BGH: BGH MMR 2010, 23 m. Anm. Hoffmann Capgemini 2013 Capgemini, Deutschland G.: Individualsoftwareerstellung mit agilen Methoden - Muster. Internal, , 34, 38 Claus Müller-Hengstenberg 2008 Claus Müller-Hengstenberg, Stefan K.: Gestaltung von Verträgen für die agile Softwareerstellung. Aufsatz, ITRB , Computer und Recht - Verlag Dr. Otto Schmidt, Köln 48 Fuchs Anke 2012 Fuchs Anke, Jochen Morsbach und Lous P. Christine Meierhöfer M. Christine Meierhöfer: Agile Programmierung - Neue Herausforderungen für das Softwarevertragsrechts? Unterschiede zu den klassischen Softwarentwicklungsprojekten. Multmedia und Recht (MMR), Aufsatz S. 427 ff, Online verfügbar unter beck.de/default.aspx?typ=reference&y=300&z=mmr&b=2012&s=427&n=1; aufgerufen am , 47 Hofmann 2010 Hofmann, Marcus A.: Individualsoftwareerstellung mit Scrum. Website, Online verfügbar unter aufgerufen am , 35 des Inneren 2008 Inneren, Bundesministerium des: EVB-IT und BVB. Website, Online verfügbar unter Aktuelle_EVB-IT/aktuelle_evb_it_node.html; aufgerufen am , 40 Ken Schwaber 2011 Ken Schwaber, Jeff S.: Scrum Guide - Der gültige Leitfaden für Scrum - Die Spielregeln. Website, Online verfügbar unter aufgerufen am , 23, 24, 25, 26, 28 Michael Kirsch 19

22 Literaturverzeichnis Koch 2009 Koch, Dr. Frank A.: IT-Projektverträge rechtssicher gestalten. Website, Online verfügbar unter rechtssicher_gestalten.pdf; aufgerufen am Kremer 2010 Kremer, Sascha: Gestaltung von Verträgen für die agile Softwareerstellung. Aufsatz, ITRB , Der IT-Rechtsberater - Verlag Dr. Otto Schmidt, Köln 45 MIP-Consult 2008 MIP-Consult: IT-Projekte und Rechtsfragen. Website, Online verfügbar unter aufgerufen am Oberlandesgericht Oberlandesgericht: Förmliche Abnahme. Website,. Online verfügbar unter aufgerufen am OOSE-Group 2013 OOSE-Group: Einfluss klassischer und agiler Techniken auf den Erfolg von IT- Projekten. Website, Online verfügbar unter fachliches/pm-studie/; aufgerufen am , 2 Opelt u. a Opelt, Andreas ; Gloger, Boris ; Pfarl, Wolfgang ; Mittermayr, Ralf: Der agile Festpreis Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. München : Hanser Verlag, ISBN , 6, 7, 16, 17, 18, 21, 36 Osterhage 2009 Osterhage, Wolfgang W.: Abnahme komplexer Software-Systeme: Das Praxishandbuch (Xpert.press) Springer, Pichler 2010 Pichler, Roman: Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn)). Addison-Wesley Professional, ISBN Sarre 2013 Sarre, Frank: Juristisches IT Projektmanagement. Website, Online verfügbar unter vorlesungen-ab-dem ; aufgerufen am Schneider Schneider: ITRB 18. ITRB, 33 Scrumalliance 2008 Scrumalliance: Definition of Done: A Reference. Website, Online verfügbar unter definition-of-done-a-reference; aufgerufen am Valuenet Valuenet: Rechtslexikon. Website,. Online verfügbar unter rechtslexikon-online.de/; aufgerufen am Michael Kirsch 20

23 Literaturverzeichnis Witte 2010a Witte: Zutreffend Witte, ITRB, 33, 46f Witte 2010b Witte, Andreas: IT-Projektverträge rechtssicher gestalten. Aufsatz, ITRB 44-47, Der IT-Rechtsberater - Verlag Dr. Otto Schmidt, Köln 44, 46 Michael Kirsch 21