Vor knapp einem Jahr habe ich bereits an dieser Stelle dargelegt, warum die Methodik der agilen Programmierung Juristen vor Probleme stellt. Kurz gesagt, passen die juristischen Modelle, die das BGB anbietet nicht. Inzwischen bilden sich aber einzelne Tendenzen heraus, wie das Problem zu lösen kann. Diese sind für Nichtjuristen nicht einfach zu verstehen. Deshalb kurz zuvor noch einmal ein Problemabriß:
Das BGB wurde im Jahr 1900 erfunden und viele Techniken und Methoden waren den Erfindern des BGB schlicht unbekannt. Die Arbeit der Juristen besteht heutzutage häufig darin, diese Regelungen für einen Bereich anzupassen, für den sie niemals gedacht waren. Dabei erreicht man häufig Grenzen, die nicht überwindlich sind. Agile Programmierung beinhaltet einen Interessenkonflikt zwischen dem Kunden (vom BGB Besteller genannt) und dem IT Unternehmen (Unternehmer). Das BGB sieht im Grundsatz ein Modell vor, das beispielsweise für Tischler erdacht ist. Ein Kunde gibt einen Auftrag, der Tischler realisiert den Tisch gegen den Auftrag. In der Sprache der ITler gibt es solche Verträge. Man realisiert gegen den Auftrag oder gegen das Lastenheft (Workshopprotokoll oder Grobspec.). Bei der Abnahmeprüfung werden IST und SOll Zustand miteinander verglichen. Stimmen beide überein, muß der Kunde die Abnahme erklären. Dies entspricht dem Modell eines hermeneutischen Zirkels, der genau einmal durchlaufen werden muß. Schon dann, wenn dieser Zirkel mehr als einmal zu durchlaufen ist, gerät das juristische Modell ins Schlingern. Namentlich bei der Wasserfallmethodik Lastenheft-Pflichtenheft-Realisierung findet man im Werkvertragsrecht des BGB nichts. Denn in Wahrheit sieht das BGB nur vor, daß sich die Parteien dazu verpflichten, einen Vertrag abzuschließen und diesen zu erfüllen. Das Problem der Projektverträge besteht darin, daß das nicht funktioniert. Die Parteien kennen das Ziel der Realisierung zum Zeitpunkt der Eingehung des Vertrags nicht. Der Kunde muß das Produkt noch besser kennenlernen und der ITler den Kunden und seine Bedürfnisse. Hinzukommen technische Imponderabilien.
Aus der Sicht der juristischen Methodik ist agile Programmierung nun nichts weiter, als den hermeneutischen Zirkel zu vervielfältigen. Ständig ist zu kommunizieren, ständig ist der Abgleich zwischen Ist und Soll Zustand vorzunehmen und zu verbessern. Just jenes Modell kannten die Väter des BGB auch und nannten es Dienstvertrag. Der Dienstvertrag unterscheidet sich so vom Werkvertrag, daß im Rahmen des Dienstvertrags die Bemühung um die Realisierung geschuldet ist, beim Werkvertrag hingegen der Erfolg. Der Kunde aber will den Erfolg und nicht die Bemühung; der ITler sagt zu Recht, wenn ich zu Beginn des Vertrags den erst später erkennbaren Wunsch des Kunden nicht kennen kann, kann ich den Erfolg nicht schulden. Man kennt solche Verträge aus dem Bereich FuE (Forschung und Entwicklung) und dort vereinbaren die PArteien Dienstvertragsrecht. Mann kennt solche Verträge nicht im Bereich der normalen Industrieprojekte, dort herrscht das Werkvertragsrecht.
Teil II
