„Rechtliche Aspekte und Haftungsfragen im agilen Requirements-Engineering“
In agilen Vorgehensweisen wird oft sehr locker mit ungenauen Requirements umgegangen mit dem Wissen, dass dies der Grundgedanke der agilen Vorgehensweise ist.
Doch wie sieht es in der Praxis mit verschiedenen rechtlichen Aspekten und Haftungsfragen aus, an die die Entwickler oder auch Kunden meist nicht denken? Erst im Schadensfall kommen dann die Probleme, die durch schlechtes Requirements-Engineering verursacht wurden, zu Tage. Dann ist es jedoch zu spät.
Im agilen Manifest steht „Funktionierende Software wird höher gewertet als umfassende Dokumentation.“ In jedem agilen Methodenbuch steht, dass besser kommuniziert werden sollte, als dass alles im Detail niedergeschrieben wird.
Im Idealfall kann dies voll unterstützt werden. Leider besteht das Leben aber nicht nur aus Idealfällen.
Requirements-Engineering kann man mit verschiedenen Situationen im Leben vergleichen, bei denen Risiken und Schadensituationen auftreten. Die meisten Menschen werden bestrebt sein, Risiken und Schäden gering zu halten. Das ist im täglichen Leben beim Autofahren, Hausbauen oder auch in Beziehungen der Fall.
Solange alles gut und in den erwarteten Bahnen verläuft, wird keiner auf die Idee kommen, dass er alles aufschreiben muss, um sich abzusichern. Wenn dann aber die Sache schief läuft, dann kommt meist die Aussage: „Hätten wir das doch vorher schriftlich festgehalten oder vereinbart“.
Bei den Juristen gibt es folgendes Sprichwort: „Wer schreibt der bleibt und wer red’t der geht!“
Dies kommt daher, dass in einem Streitfall - im schlimmsten Fall vor Gericht – alles Niedergeschriebene eine um vieles höhere Beweiskraft hat, als eine mündliche Aussage. Das ist natürlich ein konträrer Standpunkt zu den agilen Methoden und das andere Ende des Spektrums. In der Praxis kommen solche Fälle auch immer wieder vor, wie auch ein Fallbeispiel eines gescheiterten agilen Projekts konkret zeigen wird.
Ein ähnliches Problem tut sich auf bei der Vereinbarung von Festpreisen in Projekten. Der Kunde möchte verständlicherweise möglichst bald wissen, was denn sein Vorhaben kosten wird. Der viel zitierte Schätz-Unschärfetrichter ist jedoch ein Faktum und kann zwar ignoriert, aber nicht eliminiert werden. Damit tritt in praktisch jedem Projekt, bei dem vor der Fertigstellung ein Festpreis vereinbart wird das Problem auf, dass der geschätzte Preis und die Leistung nicht zusammen passen; bei größeren Abweichungen beginnen dann die Diskussionen wer nun (drauf-)zahlt.
Es gibt mittlerweile auch Literatur zum Thema „agiler Festpreis“. Darin wird jedoch nicht der Stein der Weisen beschrieben oder gar eine Lösung für den Unschärfetrichter gefunden, sondern meist alter Wein in neuen Schläuchen verkauft – sprich Methoden, die schon seit Jahrzehnten in Ausschreibungs-verfahren verwendet werden und hier in einem modernen Kontext dargestellt werden. Das eigentliche Problem wird dabei aber nicht gelöst.
Ein wichtiger Punkt bezüglich Haftung ist auch das Thema Normen und Standards. Praktisch alle gängigen Normen im Umfeld der SW-Entwicklung verlangen gewisse Mindestdokumentationen und spezifikationen für eine ordnungsgemäße Projektabwicklung.
Agile Methoden sind bislang nicht genormt bzw. beinhalten auch zu wenige und zu unkonkrete normative Elemente. Die Aussage, dass Requirements in einem Backlog verwaltet werden sollen, eine Definition of Ready/Done definiert werden soll, oder andere recht ungenaue Vorgaben sind im Grunde völlig unbrauchbar, wenn es zum Haftungs- oder Streitfall kommt, weil sie keinen konkreten Aussagen über Qualität und Inhalt der Spezifikation vorgeben. Sie werden daher im Streitfall nicht als Beurteilungsbasis herangezogen. Da die agilen Methoden hier die Detailausführungen vor allem im Requirements-Bereich völlig offen lassen, kann sich ein Sachverständiger bei Gericht nicht darauf beziehen und muss daher auf etablierte Normen und Standards zurückgreifen, die den „Stand der Technik“ darstellen und normative sowie qualitativ prüfbare Elemente beinhalten.
Damit hat man im Streitfall oft das Problem, dass man nicht einfach sagen kann „Wir haben ja eine agile Vorgehensweise vereinbart – dort wird eben weniger dokumentiert und mehr geredet“.
Dies wird nicht viel helfen, sondern es muss das „weniger Dokumentierte“ trotzdem den gängigen Standards im Requirements-Engineering entsprechen, damit hier keine fahrlässige Handlungsweise vorliegt.
Wir haben also die beiden Seiten „viel reden und weniger schreiben“ bis hin zu „möglichst alles aufschreiben, um abgesichert zu sein“.
Der Grad der Spezifikation bzw. Dokumentation ist sehr individuell für die jeweilige Projektsituation (und Umfeld) zu sehen und kann nicht für alle gleichermaßen definiert werden.
Dieser Vortrag beschäftigt sich mit Fragen wie:
- Welche rechtlichen Aspekte sind beim Requirements-Engineering in agilen Projekten besonders zu beachten, damit man nicht in die Haftungsfalle gerät?
- Wie sieht es bezüglich der Einhaltung von einschlägigen Normen und Standards aus?
- Wie kann/soll man mit Festpreisen in agilen Projekten umgehen und welche Auswirkungen hat dies auf die Requirements-Spezifikation?
- In welchen Projektsituationen ist welcher Detaillierungsgrad an Spezifikation zu empfehlen?
- Leider bleibt im Anlassfall bei zu wenig Dokumentation fast immer der Kunde auf der Strecke – warum das so ist, wird auch im Vortrag angesprochen.
Weiterführende Informationen:
Nähere Informationen dazu sind im Buch „Requirements Engineering für die agile Software-Entwicklung“ zu finden.
Software Quality Lab bietet interessierten Unternehmen auch einen Halbtagesworkshop zu diesem Thema an.
Im Rahmen des 3-tägigen Seminars <link leistungen academy seminare seminar-thema requirements-engineering-fuer-die-agile-softwareentwicklung>Requirements Engineering für die agile Softwareentwicklung wird dieses Thema ebenfalls behandelt.
Gerne kann dieser Vortrag auch speziell für Sie bei Ihnen im Unternehmen gehalten werden
