Agile Programmierung

A. Einleitung

Stellen wir uns einmal zwei verschiedene Menschen vor: auf der einen Seite steht Person L, auf der anderen Seite Person A.

L ist ein begeisterter Urlauber, jedoch ist er ein Freund umfangreicher Planung und Strukturierung seiner Reise vor Urlaubsantritt. Er plant und konzeptioniert seine Reise bis ins letzte Detail und möchte seine Planungen während des Urlaubs lediglich „abspulen“. L kann auf Grundlage seiner vorgelagerten Planung ziemlich detailliert planen, welches Budget er benötigen wird für seine Reise. Er wird allerdings während der Reise nur geringe Möglichkeiten haben, um außerplanmäßige Aktivitäten einzubauen.

A hingegen geht seine Reise ganz anders an: Er ist im Vorfeld nur um wenige Informationen und Details bemüht und lässt die Reise auf sich zukommen. A ist nicht festgelegt auf ein Ziel, sondern dazu bereit, während des Urlaubs selbst spontane Änderungen einzubauen, sodass er zu Beginn seiner Reise überhaupt nicht prognostizieren kann, was er am Ende seiner Reise alles erlebt und gesehen haben wird. A kann – anders als L – keine detaillierte Budgetermittlung vornehmen und kann die Kosten seiner Reise nur grob kalkulieren.

Aus diesem Alltagsbeispiel lässt sich der Schluss ziehen, dass es grundverschiedene Charaktere und Vorgehensweisen gibt. Es gibt diejenigen, die linear einem Konzept nachgehen, welches detailliert aufgearbeitet und vorbereitet wurde und es gibt diejenigen, die „agil“ – ohne vorher detailliert festgelegtes Konzept – ihren Weg bestreiten.

In der Softwareentwicklung ist der Sachverhalt ähnlich gelagert. Unterschieden wird hierbei insbesondere zwischen der linearen Softwareentwicklung nach dem sog. „Wasserfallmodell“¹ sowie der agilen Programmierung.²

Diese Dissertation wird sich in den Kapiteln B und C allen voran den beiden genannten Arbeitsweisen der Softwareentwicklung widmen und die Unterschiede beider Herangehensweisen aufzeigen. Insbesondere die rechtlichen Probleme des agilen Programmierens sollen skizziert und kritisch untersucht werden. Im Fokus wird hierbei in Kapitel C die Typologisierung eines geeigneten Vertragstypen stehen.

Darüber hinaus soll anschließend in Kapitel D herausgearbeitet werden, ob und wie Probleme des IT-Vertragsrechts durch die Rechtsentwicklung im Bauvertragsrecht gelöst werden könnten.³ Das IT-Vertragsrecht kann was vom privaten Baurecht lernen.⁴ Es wird untersucht werden, ob dieser These zuzustimmen ist. Hierbei wird insbesondere ein Blick auf die Rechtsprechung zum privaten Baurecht unerlässlich sein. Es soll aufgezeigt werden, ob und wie die Besonderheiten des Bauvertragsrechts als Orientierungshilfe für softwarerechtliche Fragestellungen geeignet sind.

Es ist unter anderem aufzuzeigen, inwieweit Änderungen durch das „Gesetz zur Reform des Bauvertragsrechts […]“⁵, welches zum 01. Januar 2018 in Kraft getreten ist, Einfluss auf Softwareentwicklungsverträge und vor allem das agile Programmieren nehmen werden. Vereinzelt wurde bereits in Aussicht gestellt, dass die Neuregelungen der Reform des Werkvertragsrechts das „IT-Vertragsrecht nachhaltig verändern“⁶ werden. Ob und inwieweit dieser Auffassung zuzustimmen ist, soll im Verlauf dieser Dissertation herausgestellt werden. Auch zur Klärung dessen wird sich gleichermaßen an bau- und werkvertragsrechtlichen Entscheidungen orientiert.

Im Anschluss hieran wird in Kapitel E die digitale Planungsmethode Building Information Modeling vorgestellt und mit Blick auf mögliche Gemeinsamkeiten mit agiler Programmierung erörtert.

Schließen soll diese Arbeit mit einem Fazit sowie einem Ausblick auf die weitere Zukunft der Softwareentwicklung, insbesondere in Form des agilen Programmierens.

B. Gegenüberstellung von agilem Programmieren (insb. unter Einsatz von SCRUM) und linearer Softwareentwicklung nach dem sog. „Wasserfallmodell“

I. Allgemeine Einleitung in das Themengebiet Softwareentwicklung

Die Welt entwickelt sich jeden Tag weiter und die globale Digitalisierung schreitet täglich voran.⁷ Eine große Rolle spielt hierbei Software.⁸ Durch sie soll eine technische Vorrichtung durch eine Folge von Befehlen für eine festgelegte Aufgabe einsatzfähig gemacht werden.⁹

In einer zunehmend digitalisierten Wirtschaftswelt ist Software mehr denn je ein Faktor für unternehmerische Wettbewerbsfähigkeit.¹⁰ Die Aufgabe eines Software-Entwicklers ist es eine benutzungsfähige Software für den Kunden nach dessen Anforderungen zu erstellen.¹¹

Die Entwicklung von Software ist daher häufig eine Leistung, die an die speziellen Bedürfnisse und Wünsche des (späteren) Verwenders angepasst werden muss.¹² Eine Software, die von Grund auf nach Kundenwunsch entwickelt wird, nennt man Individualsoftware.¹³

Neben der Individualsoftware für einen bestimmten Verwender und einen Einzelfall gibt es jedoch auch Software, die für eine Vielzahl von Verwendern bereits erstellt und unabhängig von individuellen Wünschen programmiert wurde.¹⁴ Hierbei handelt es sich um sog. Standardsoftware.¹⁵

Eine dritte Ausprägung der Softwareerstellung stellt das sog. „Customizing“ dar.¹⁶ Hierbei wird eine entwickelte Standardsoftware durch Einarbeitung spezieller Kundenwünsche individualisiert und umgestaltet, sodass sie vom Kunden bestmöglich genutzt werden kann.¹⁷ Das „Customizing“ ist insoweit ←18 | 19→gewissermaßen eine Kombination aus klassischer (Standard-)Softwareentwicklung einerseits sowie Individualisierung dieser Software andererseits.¹⁸

Üblicherweise ist somit stets zwischen der Entwicklung von Standardsoftware und der Entwicklung von Individualsoftware zu unterscheiden.¹⁹

Bei einer Standardsoftware handelt es sich um ein Produkt, bei welchem vor massenhaftem Produktionsstart der Softwaresysteme eine umfangreiche Konzeption stattgefunden hat, welche in der Entwicklung und Produktion lediglich ausgeführt wird.²⁰ Mangels notwendiger Individualisierung der Software ist daher üblicherweise kein Bedarf gegeben, diese Software nach Wunsch und Anspruch des jeweiligen Kunden zu personalisieren.²¹ Die möglichen Probleme in der Zusammenarbeit von Kunden und Softwareentwickler stellen sich somit bei Standardsoftware im Regelfall gar nicht erst. Die Herstellung von Standardsoftware stellt daher üblicherweise keinen allzu großen Problemfall in der rechtlichen Handhabung ihres Entwicklungsprozess sowie einer etwaigen Mängelgewährleistung dar.²²

Aufgrund dessen wird hierbei auch unproblematisch anerkannt, dass der (nicht nur zeitweilige und entgeltliche) Erwerb einer solchen Standardsoftware dem Kaufrecht gemäß §§ 433 ff. BGB unterliegt.²³ Die Software wird hierbei als „sonstiger Gegenstand“ gemäß § 453 Abs. 1 Alt. 2 BGB charakterisiert, auf welchen die Vorschriften über den Kauf von Sachen entsprechend angewendet werden.²⁴ Dementsprechend existieren folglich die kaufrechtlichen Gewährleistungsrechte gemäß §§ 437 ff. BGB im Falle einer Mangelhaftigkeit der Standardsoftware.²⁵

Gerade bei der Entwicklung und Programmierung von Individualsoftware stellt sich allerdings die Frage, wie dieses Softwareprojekt zwischen dem späteren Verwender und dem Programmierer durchgeführt wird. Unterschieden wird allen voran zwischen zwei möglichen Herangehensweisen der Programmierung: einerseits besteht die Möglichkeit, die Software in einem linearen Verfahren nach dem sog. „Wasserfallmodell“ zu erstellen, andererseits kann die Software „agil“ programmiert werden.²⁶

Doch wie lassen sich diese beiden Vorgehensweisen überhaupt charakterisieren und wie unterscheiden sie sich voneinander? Diese Fragen sollen im Folgenden geklärt werden – an dieser Stelle jedoch zunächst ohne nähere Berücksichtigung der zugrundeliegenden vertragstypologischen Differenzierungen.

II. Lineare Softwareentwicklung nach dem sog. „Wasserfallmodell“

Das sog. Wasserfallmodell ist die traditionelle Weise der Softwareentwicklung.²⁷ Hierbei ist die Vorgehensweise der Entwicklung unterteilt in mehrere eigenständige Abschnitte.²⁸ Das Projekt startet mit einer Planungsphase, es folgt hiernach die sog. Durchführungs- bzw. Entwicklungsphase.²⁹ Sein Ende findet das Projekt in der Testphase durch den Kunden sowie dessen endgültiger Abnahme der Software.³⁰ Diese Phasen werden ihrerseits jeweils vollständig abgeschlossen, bevor es in die nächste Phase übergeht.³¹ Die Planungs- und Durchführungsphasen sind somit eigenständig und strikt voneinander getrennt.³²

1. Planungsphase

Das Softwareentwicklungsprojekt beginnt mit Abschluss eines sog. Projektvertrages zwischen Auftraggeber und Auftragnehmer.³³ Im Anschluss hieran startet die Entwicklung bei dieser linearen Vorgehensweise mit der Planung ←20 | 21→und Konzeptionierung der Software.³⁴ Diese erfolgt durch die umfangreiche Zusammenstellung der gewünschten Anforderungen durch den Auftraggeber sowie einer darauf aufbauenden Funktionsbeschreibung durch den Softwareentwickler.³⁵

In der juristischen Literatur wird das Anforderungsprofil eines solchen Softwareentwicklungsprojekts regelmäßig lediglich mit dem Begriff „Pflichtenheft“ versehen.³⁶ In technischer Hinsicht ist jedoch zwischen dem sog. Pflichtenheft und dem sog. Lastenheft zu unterscheiden.³⁷ Ursprünglich stammen diese Begriffe aus dem Maschinenbau, wobei DIN 69901-5:2009 das Lastenheft als „Gesamtheit aller Anforderungen des Auftraggebers an die Lieferungen und Leistungen des Auftragnehmers“ beschreibt und das Pflichtenheft als „ausführliche Beschreibung der Leistungen des Auftragnehmers, die zur Erreichung der Projektziele gefordert oder erforderlich sind“ definiert.³⁸ Die Folge hieraus ist, dass das Lastenheft das „was“ beschreibt,³⁹ während ein Pflichtenheft das „wie“ beschreibt.⁴⁰ Hierbei ist zu beachten, dass das Lastenheft nach dieser Definition ausschließlich durch den Auftraggeber bereits vor dem eigentlichen Projektbeginn erstellt wird,⁴¹ während das Pflichtenheft für gewöhnlich in Zusammenarbeit von Auftraggeber und Auftragnehmer erarbeitet wird.⁴² Das Lastenheft definiert vereinfacht gesagt alle Wünsche und Vorstellungen des Auftraggebers an die zu erstellende Software.⁴³ Das Pflichtenheft hingegen ist eine Reaktion des Auftragnehmers auf das Lastenheft und legt fest wie die Software erstellt ←21 | 22→werden soll.⁴⁴ Das Pflichtenheft beinhaltet somit das „Soll-Konzept“ des Projekts, genauer gesagt die „vereinbarte Beschaffenheit“ gemäß § 633 Abs. 2 S. 1 BGB.⁴⁵

Durch vielfache fehlerhafte Darstellungen werden die Begriffe jedoch häufig nicht nennenswert differenziert, sodass vereinzelt das „Pflichtenheft“ als Anforderungsprofil angesehen wird.⁴⁶ Trotzdem sei jedoch nochmals darauf hingewiesen, dass Lasten- und Pflichtenheft zwei unterschiedliche Dokumente sind, die beide dem Projektvertrag zugrunde liegen (sollten),⁴⁷ beispielsweise als Anlage zu diesem.

Um keinen Verständnisbruch mit der übrigen juristischen Literatur zur Softwareentwicklung herbeizuführen, wird die anfängliche Anforderungsspezifikation eines Projekts ebenfalls nur als „Pflichtenheft“ bezeichnet.⁴⁸

Vereinfacht gesagt beinhaltet dieses „Pflichtenheft“ eine präzise Festlegung dessen, was die zu entwickelnde Software leisten soll.⁴⁹ Neben den technischen Ansprüchen an die Software wird zudem im „Pflichtenheft“ festgelegt, welche Qualität die später zur Verfügung gestellte Software haben muss.⁵⁰ Mögliche regelbare Kriterien hierbei sind u.a. die Wartbarkeit, die Softwaresicherheit, die Bedienfreundlichkeit, mögliche Testumfänge während der Entwicklung oder auch die Dokumentation der Systemarchitektur während des Entwicklungsprozesses.⁵¹

Bestenfalls wird im „Pflichtenheft“ alles festgehalten, was sowohl technisch wie auch rechtlich zu berücksichtigen ist, um allen Vertragsparteien im Streitfall konkrete Maßstäbe für die rechtliche Beurteilung des Softwareerstellungsprojektes zu gewährleisten.

2. Durchführungsphase

Im Anschluss an die vollständige Planung der zu erstellenden Software startet die sog. Durchführungsphase.⁵² In der Durchführungsphase wird die Software entwickelt.⁵³ Der Softwareentwickler gestaltet hierbei die Software nach den Vereinbarungen, die innerhalb der Planungsphase durch die Parteien getroffen wurden.⁵⁴ Gewöhnlich endet diese Durchführungsphase mit umfangreichen Funktionstests der fertigen Software durch den Ersteller vor endgültiger Ablieferung an den Kunden.⁵⁵

Die Software muss hierbei jedoch nicht als Ganzes fertiggestellt werden.⁵⁶ Es besteht für die Parteien ebenso die Möglichkeit, die Gesamt-Software-Entwicklung in einzelne sog. „Meilensteine“⁵⁷ aufzuteilen, welche ihrerseits als eigenständige Leistung programmiert, getestet und an den Kunden geliefert werden.⁵⁸ Solche Vereinbarungen werden gemeinhin im Rahmen der Leistungsvereinbarung während der Planungsphase getroffen.⁵⁹

3. Testphase

Die letzte Phase der linearen Softwareentwicklung ist die Testphase durch den Kunden selbst.⁶⁰ Der Kunde unterzieht die fertige Software einem umfangreichen Testverfahren. Hierbei prüft er allen voran, ob die Anforderungen, die in der Planungsphase vereinbart wurden, in der fertigen Software wie gewünscht umgesetzt wurden.

Bei Zufriedenheit mit dem Ergebnis erfolgt im Anschluss hieran eine Abnahme der Software durch den Kunden.⁶¹ Mit erfolgter Abnahme findet das Softwareentwicklungsprojekt seinen Abschluss.

III. Agile Programmierung (insb. unter Einsatz von SCRUM)

Die agile Programmierung bewährt sich seit ca. 15 Jahren als Alternative zur vorstehend dargestellten Variante linearer Programmierung.⁶² In der juristischen Diskussion ist sie bereits seit ca. 10 Jahren ein Thema.⁶³ Es ist festzustellen: agile Methoden „setzen sich gerade in der IT immer mehr durch“.⁶⁴ Überraschend ist daher, dass es bislang kaum eine instanzgerichtliche Entscheidung der ordentlichen Gerichtsbarkeit in Bezug auf agile Programmierung gibt.⁶⁵

Einheitlich definierbar ist der Begriff „agil“ bislang nicht.⁶⁶ Agile Projekte unterscheiden sich von der linearen Vorgehensweise dahingehend, dass hierbei allen voran auf eine umfangreiche Anforderungsfestlegung vor Entwicklungsbeginn verzichtet wird.⁶⁷ Es wird eben gerade kein ausführliches Pflichtenheft erstellt, welches die Anforderungen so genau wie möglich skizzieren soll.⁶⁸ Hierdurch soll dem wesentlichen Grundgedanken der agilen Vorgehensweise nachgekommen werden: Die Dokumentation soll während der agilen Projektentwicklung auf das nötigste Minimum reduziert werden,⁶⁹ sodass der Fokus auf die Entwicklung der Software durch Kooperation von Softwareersteller und ←24 | 25→Kunden gerichtet ist.⁷⁰ Seinen Ursprung hat dieser Grundgedanke im „Agilen Manifest“.

Das „Agile Manifest“ wurde im Februar 2001 von mehreren Softwareentwicklern formuliert und enthält die grundlegenden Werte agiler Projektmethoden.⁷¹ Dem „Agilen Manifest“ ist zu entnehmen, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge.⁷² Eine funktionierende Software hat mehr Wert als eine umfassende Dokumentation.⁷³ Die Zusammenarbeit mit dem Kunden ist der Vertragsverhandlung vorzuziehen.⁷⁴ Das Reagieren auf Veränderung ist notwendiger als das Befolgen eines Plans.⁷⁵

Im Ergebnis ist die agile Vorgehensweise folglich darauf bedacht, die möglichen Änderungen im Anforderungsprofil der Projektentwicklung durch Flexibilität und Kommunikation mit dem Kunden abzustimmen und umzusetzen.⁷⁶ Wie genau diese Leitprinzipien während eines agilen Projekts berücksichtigt und respektiert werden müssen lässt das „Agile Manifest“ jedoch offen.⁷⁷ Somit sind diese Prinzipien lediglich als Orientierungshilfe für die Gestaltung agiler Projekte heranzuziehen.

Ein agiles Projekt verzichtet auf aufeinanderfolgende, eigenständige Phasen während der Entwicklung.⁷⁸ Die strikte Trennung von Planungs- und Durchführungsphasen, wie sie im Wasserfallmodell üblich sind, wird aufgelöst.⁷⁹ Hierdurch wird nicht nur der Ablauf des Projektes beeinflusst: Auch die Verantwortungsbereiche der einzelnen Projektparteien, vor allem Softwareersteller und Kunde, werden im Rahmen der auf Kommunikation und Interaktion ausgelegten Zusammenarbeit miteinander vermischt.⁸⁰ Trotz dessen soll die übliche Struktur eines IT-Projektes hierbei nicht beeinflusst werden: Es soll bei einer ←25 | 26→klaren Rollenverteilung der Projektparteien bleiben, d.h. die Konzeptionshoheit soll auch bei agilen Methoden dem Auftraggeber zustehen, wohingegen die Programmierungshoheit weiterhin dem Auftragnehmer obliegen soll.⁸¹

Die agile Softwareentwicklung kennt zahlreiche sog. „agile Prozesse“, welche allesamt darauf ausgelegt sind, die vorgestellten Prinzipien und Grundgedanken des „Agilen Manifests“ umzusetzen.⁸²

Die populärsten agilen Prozesse sind hierbei Kanban, Extreme Programming (XP), Behaviour Driven Development (BDD) oder auch SCRUM.⁸³

Besondere Bedeutung hat das sog. SCRUM.⁸⁴ Es ist mittlerweile eine etablierte und anerkannte Form agiler Entwicklung.⁸⁵ Bei SCRUM handelt es sich um eine Arbeitsweise, bei welcher die Aufgaben der Softwareentwicklung durch verschiedene „Teams“ in sich regelmäßig wiederholenden Zeitabständen (sog. „Sprints“) kollegial und kommunikativ abgesprochen und ausgearbeitet werden, um auf diese Weise eine zügige Herstellung nutzbarer Software zu ermöglichen.⁸⁶

SCRUM wurde in den frühen 1990er Jahren entwickelt und dient seither zur Entwicklung von komplexen Produkten,⁸⁷ worunter auch Software zu verstehen ist.⁸⁸ Ken Schwaber und Jeff Sutherland haben SCRUM 1995 erstmals vorgestellt ←26 | 27→und seither weiterentwickelt.⁸⁹ SCRUM ist nach Auffassung von Schwaber und Sutherland kein eigenständiger Prozess, keine Technik und auch keine Methode, sondern ein Rahmenwerk, welches die Einsatzmöglichkeit verschiedener Prozesse und Techniken ermöglicht.⁹⁰

SCRUM wird getragen von drei grundlegenden Werten: Es gibt das SCRUM-Team, welches sich wiederum in drei grundlegende Rollen aufteilt.⁹¹ Hierneben gibt es die SCRUM-Ereignisse, d.h. die schrittweisen Phasen eines SCRUM-Ablaufs.⁹² Diese Ereignisse sind der Sprint, das Sprint Planning, der Daily SCRUM, der Sprint Review sowie die Sprint Retrospektive.⁹³ Zuletzt gibt es drei SCRUM-Artefakte, welche der Transparenz der Arbeit dienen sollen.⁹⁴ Die drei SCRUM-Artefakte lauten Product Backlog, Sprint Backlog und Inkrement.⁹⁵ Beim SCRUM hat die Berücksichtigung und Respektierung dieser grundlegenden SCRUM-Werte oberste Priorität.⁹⁶ Ein Abweichen davon ist nicht vorgesehen, sondern bewirkt nach Auffassung von Schwaber und Sutherland lediglich, dass die angewendete Arbeitsweise nicht mehr dem SCRUM entspricht, wie es durch ihren „Scrum-Guide“ definiert ist.⁹⁷