„Agile Softwareentwicklung“ – ein absolutes Reizthema zwischen IT-Rechtlern und ihren Mandanten. Wenn man in der täglichen Beratungspraxis auf bestimmte Themen (Lastenheft, Pflichtenheft, Abnahme von Teilen, Milestones) hinweist, bekommt man in der Regel erstmal als Antwort, dass das alles total old school sei und überhaupt agile Entwicklung der Trend sei und man sich nicht so anstellen solle. Doch was ist „agile Softwareentwicklung“ eigentlich? Und gibt es sie nicht ohnehin schon überall?
wikipedia.org
Laut wikipedia.org ist „Agile Softwareentwicklung“ der Oberbegriff für den Einsatz von Agilität (lateinisch agilis: flink; beweglich) in der Softwareentwicklung. Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming angeführt. Agile Softwareentwicklung versucht mit geringem bürokratischem Aufwand, wenigen Regeln und meist einem iterativen Vorgehen auszukommen. Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele konzentrieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell. (Quelle: wikipedia.org)
Der Unterschied
Klingt auf den ersten Blick alles sexy, cool und praktikabel. Agil, individuell, flexibel – alles Begrifflichkeiten, die sich super anhören, wenn alles glatt läuft und alle zufrieden sind. Der Hauptunterschied zu den klassischen Vorgehensmodellen ist hauptsächlich der Versuch, die Projektierungsphase so kurz und knapp wie möglich zu halten und schnell an die „eigentliche“ (aus Sicht des Programmierers, nicht des Juristen) Arbeit zu gehen. Auch das ist natürlich dem Grunde nach ein sehr löblicher und zielführender Ansatz.
In jedem Fachanwaltslehrgang für IT-Recht oder auch bei IT-rechtlichen Fortbildungen wird eisern gepredigt, wie wichtig bestimmte Details, wie zum Beispiel ein perfektes Pflichtenheft oder ein vernünftiger Vertrag mit perfekt geregelten beiderseitigen Pflichten, sind. Doch wie sieht das eigentlich in der täglichen Beratungspraxis aus? Kann man so was überhaupt gewährleisten? Anwälte aus Großkanzleien, die Dax-Konzerne beim Einkauf von Softwareprojekten im Millionenbereich vertreten, würden das sicher bejahen. Bei kleineren Firmen sieht das aber sicher anders aus.
Die Problematik – die echte Welt
In einer heilen, perfekten Welt könnten Softwareprojekte sicher toll funktionieren. Im klassischen Sinne würde man verschiedene Phasen vertraglich festlegen, auf Basis eines herausragenden Lastenheftes ein perfektes Pflichtenheft erarbeiten, welches selbstverständlich auch bezahlt wird und am Ende kann man Stück für Stück die Software umsetzen und man bekommt das fertige Werk ohne Murren abgenommen. Bei agiler Programmierung würde man sich im Gegensatz dazu in einer kurzen Projektierungsphase bei Espresso unter Freunden darüber unterhalten, was die Software können soll und die Programmierer setzen es einfach perfekt um. Am Ende kommt eine funktionierende Software zu einem fairen Preis raus und alle sind glücklich.
Leider sieht das in der echten Welt oft anders aus: Es gibt (vor allem bei kleineren Unternehmen) in der Regel ein paar Anfragen über irgendwelche Portale oder eine Art Ausschreibung mit ein paar beispielhaft gewünschten Spezifikationen; dann unterbieten sich die Anbieter der Software gegenseitig, ohne genau zu wissen, worauf sie sich einlassen und dann bekommt der billigste den Zuschlag. Ein Pflichtenheft wird – wenn überhaupt – erst nach Vertragsschluss erstellt und kalkuliert wird es schon gleich gar nicht. Stundenlang herausgearbeitete, von Profi-IT-Rechtlern überprüfte Verträge, gibt es in der Regel nicht, weil man so etwas nur sehr schwer einpreisen kann. Am Ende arbeiten also viele Kunden und Softwareschmieden frei nach dem Motto „wird schon gut gehen“. Und das funktioniert ganz oft auch sehr gut so!
Was tun als Anwalt?
Fühlt sich also alles schon extrem agil an… Als Anwalt steht man bei solchen Angelegenheiten oft nur wie ein abgehobener Oberlehrer da, der seinem Mandanten vorschreibt, dass er einen Vertrag und ein Pflichtenheft braucht oder andere für den Mandanten unangenehme Dinge. Man kann sich dann dem Grunde nach entscheiden, ob man weiter den Oberlehrer mimt und den Mandanten verliert, oder ob man konstruktiv hilft und versucht, die Fehler in einem vernünftigen Aufwand zu minimieren und den Mandanten zumindest auf die jeweiligen Risiken hinzuweisen, denn davon gibt es reichlich.
Am Ende muss man also festhalten: Ein perfekt geplantes und vertraglich herausgearbeitetes Projekt ist aus rechtlicher Sicht in der Regel immer zu bevorzugen. Das echte Leben bei kleinen Firmen und kleineren Mittelständlern ist aber ohnehin total „agil“. Das kostet als Anwalt zwar manchmal ein paar Nerven und ist nicht immer cool und sexy, aber das ist die Realität und die macht oft auch viel Spaß! 🙂
Autor: Holger Loos
Kein Kommentar