Agile Verträge

Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche

Fritz-Ulli Pieper, Stefan Roock

• Verlag: dpunkt.verlag
• Jahr: 2017
• ISBN:
  9783960881704
• Thema: Betriebswirtschaft
• Thema: Projektmanagement

Agile Softwareentwicklung ist in vielen Bereichen längst zum Status quo geworden. Dabei existiert häufig ein Auftraggeber-Auftragnehmer-Verhältnis, das vertraglich geregelt werden muss.Die Autoren beschreiben die vertragsrechtlichen Grundlagen bei agiler Entwicklung, die verschiedenen Varianten der Vertragsgestaltung sowie die einzelnen Vertragsformen mit ihren Eigenschaften, Funktionsweisen, Vorteilen und Risiken, wobei auch eine formalrechtliche Einordnung vorgenommen wird. Dabei wird insbesondere zwischen klassischen kostenorientierten Verträgen und nutzenorientierten Verträgen unterschieden. Im Einzelnen werden behandelt: - Schätzung, Planung und Controlling bei agiler Entwicklung- Festpreisverträge in den unterschiedlichen Ausprägungen: vom klassischen Festpreis bis hin zum agilen Festpreis (Money for Nothing, Change for Free)- Verträge mit Bezahlung nach Aufwand: neben dem reinen Time & Material-Vertrag auch Varianten wie Design to Cost und die Bezahlungnach Produktivität- Bezahlung pro Sprint: vom Festpreis je Sprint bis hin zu Modellen, in denen der Auftraggeber die Software nur bei Gefallen bezahlt (Pay what you get)- Nutzenorientierte Verträge, bei denen sich die Bezahlung am generierten Nutzen orientiert: Proviant & Prämie, Profit-Sharing, Pay per UseDieses Buch richtet sich an diejenigen, die mit der Vertragsgestaltung für agile Entwicklungsprojekte befasst sind. Es verschafft den inhaltlich Verantwortlichen einen Einblick in die juristischen Hintergründe und gibt einen Überblick über die verschiedenen Möglichkeiten der Vertragsgestaltung.

1Einführung in agile Softwareentwicklung

Dieses Buch hat den Anspruch, generelle Aussagen über die Vertragsgestaltung für agile Entwicklung zu tätigen. Damit adressiert das Buch neben Scrum prinzipiell auch Kanban (siehe [Anderson 2010], [Burrows 2015]), Extreme Programming (siehe [Beck 2000]), Feature Driven Development (siehe [Palmer & Felsing 2002]), Crystal (siehe [Cockburn 2004]) etc.

In diesem Kapitel beschreiben wir neben den agilen Prinzipien das Scrum-Framework als den agilen Ansatz, der die größte Verbreitung erreicht hat. In den folgenden Abschnitten werden wir auch die Scrum-Nomenklatur verwenden (Sprint, Product Owner etc.). Die Übertragung auf andere agile Ansätze sollte problemlos möglich sein.

Wir diskutieren in diesem Kapitel außerdem, welche Vorteile durch agile Entwicklung erreicht werden können.

Dieses Kapitel richtet sich an Leser, die die Konzepte agiler Entwicklung und die Begrifflichkeiten von Scrum noch nicht kennen.

1.1Das Agile Manifest

Im Jahr 1997 veröffentlichte Ken Schwaber ein Paper mit dem Titel »SCRUM Development Process« auf der OOPSLA (siehe [Schwaber 1997]). Dieser Artikel war die erste veröffentlichte Beschreibung von Scrum für die Softwareentwicklung. Im Jahre 1999 erschien ein Artikel von Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber und Jeff Sutherland auf der PLOP-Konferenz mit dem Titel »SCRUM: A Pattern Language for Hyperproductive Software Development« (siehe [Beedle et al. 1999]).

2000 brachte Kent Beck sein Buch »Extreme Programming Explained – Embrace Change« heraus (siehe [Beck 2000]) und begleitete die Markteinführung des Buches durch eine Reihe von Konferenzvorträgen. Extreme Programming (XP) nahm Grundgedanken von Scrum auf und ergänzte sie um Programmiertechniken, wie die testgetriebene Entwicklung und das Pair Programming. XP war für die damalige Zeit radikal und polarisierte: Der Großteil der Softwareentwicklungsbranche fand XP absurd oder utopisch. Eine kleine, aber sehr leidenschaftliche Gemeinschaft von Entwicklern sah darin jedoch einen notwendigen Paradigmenwechsel. Immer mehr Teams setzten XP erfolgreich ein, und das Interesse stieg immer weiter an. In diesem Zuge erlangte auch Scrum eine größere Bekanntheit. Die Community war sehr wissbegierig und experimentierfreudig und suchte stets nach neuen Inspirationen. So wurden weitere Ansätze mit ähnlichen Denkmodellen entdeckt oder entwickelt, wie z.B. Crystal (siehe [Cockburn 2004]) und Feature Driven Development (siehe [Palmer & Felsing 2002]).

Diese Ansätze wurden zunächst unter dem Sammelbegriff »leichtgewichtig« zusammengefasst. Im Jahre 2001 trafen sich einflussreiche Vertreter dieser »leichtgewichtigen« Ansätze (inkl. Ken Schwaber und Jeff Sutherland) in Snowbird und definierten das Agile Manifest, das gemeinsame Werte und Prinzipien festlegte (siehe [Agile Manifesto 2001]). Für die Werte wählten die Autoren Gegensatzpaare:

»Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge
• Funktionierende Software mehr als umfassende Dokumentation
• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
• Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.«

In klassischen Kontexten generieren die Dinge auf der rechten Seite subjektiv wahrgenommene Sicherheit. Wer sich an die Prozesse hält und die vorgeschriebenen Tools einsetzt, wer jede seiner Tätigkeiten haarklein dokumentiert, wer alle Eventualitäten in Verträgen berücksichtigt und wer sich an den Plan hält, kann bei Problemen nachweisen, dass er nicht Schuld war. Leider generieren wir auf diese Weise in komplexen dynamischen Märkten keinen Geschäftswert. In dynamischen Märkten brauchen wir die Flexibilität, die uns die Dinge auf der linken Seite geben.

Dieser Gegensatz erklärt zum Teil, warum die Einführung agiler Verfahren in der Praxis häufig so schwierig ist. Alle Beteiligten müssen ein Stück dieser »Sicherheit durch Statik« loslassen, um auf den Kunden und den Geschäftswert fokussieren zu können.

Ergänzt werden die vier Wertaussagen durch zwölf Prinzipien, die konkretisieren, wie die Werte sich auf die tägliche Arbeit auswirken:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.
2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
4. Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.
5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
7. Funktionierende Software ist das wichtigste Fortschrittsmaß.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
10. Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.
11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an.

Oder in einem Satz:

Agilität bedeutet:

Autonome Teams mit Business-Fokus, die ihren Prozess in Besitz und Verantwortung nehmen.

1.2Scrum-Ablauf

Scrum hat von den agilen Ansätzen in der Praxis die größte Verbreitung erlangt. Der generelle Ablauf von Scrum (Scrum-Flow) passt im Gegensatz zur Steuererklärung tatsächlich auf einen Bierdeckel. Den Beweis liefert Abbildung 1–1¹.

Abb. 1–1Der Scrum-Ablauf passt auf einen Bierdeckel.

Am Anfang steht eine Vision davon, was für ein Produkt eigentlich entstehen (oder was an einem vorhandenen Produkt geändert) werden soll. Aus der Vision werden konkrete Eigenschaften des Produkts abgeleitet, die der Product Owner im Product Backlog organisiert und priorisiert. Die Einträge im Product Backlog werden Product Backlog Items genannt. Der Product Owner ist für den wirtschaftlichen Erfolg des Produkts verantwortlich. Dieser Verantwortung folgend, wird er die Product Backlog Items im Product Backlog nach Geschäftswert priorisieren und sie in eine klare Reihenfolge bringen.

Die Entwicklung erfolgt bei Scrum in Iterationen fester und immer gleicher Länge, die Sprints heißen. Sprints sind maximal 30 Tage lang. Das Entwicklungsteam ist für die Umsetzung der Product Backlog Items verantwortlich. Der Product Owner ist damit für das Was und das Entwicklungsteam für das Wie der Entwicklung verantwortlich.

Zu Beginn jedes Sprints führen Product Owner und Entwicklungsteam ein Sprint Planning (Sprint-Planung) durch, das der Scrum Master moderiert. In der Sprint-Planung wird festgelegt, welche Product Backlog Items in das Sprint Backlog übernommen werden und damit für diesen Sprint eingeplant werden. Dies erfolgt so, dass der Product Owner die Reihenfolge der Items vorgibt und das Entwicklungsteam entscheidet, wie viele Items in den Sprint passen.

Direkt nach der Sprint-Planung beginnt die Entwicklungsarbeit im Sprint, bei der das Entwicklungsteam sich selbst organisiert, also z.B. selbst entscheidet, welcher Entwickler als Nächstes welche Aufgabe angeht. Der Scrum Master unterstützt das Team bei der Selbstorganisation und sorgt dafür, dass Scrum effektiv angewendet wird. Dazu gehört unter anderem, dass der Scrum Master eine störungsfreie Umgebung schafft, in der das Entwicklungsteam fokussiert arbeiten kann.

Zur Abstimmung im Entwicklungsteam findet jeden Werktag während des Sprints das Daily Scrum statt. Im Daily Scrum trifft sich das Entwicklungsteam im Stehen für maximal 15 Minuten, um den Fortschritt im Sprint zu begutachten und die Arbeit im Team bis zum nächsten Daily Scrum zu organisieren.

Am Ende des Sprints liefert das Entwicklungsteam ein Produktinkrement ab. Das Produktinkrement soll auslieferbar sein (Shippable Product Increment). Es muss nicht zwingend ausgeliefert werden, muss aber die Qualität haben, dass es ausgeliefert werden könnte. Im Sprint-Review präsentiert das Entwicklungsteam die neuen Produkteigenschaften, um Transparenz über den Entwicklungsfortschritt zu schaffen und Feedback zum P...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Überblick über das Buch
• Inhaltsübersicht
• Inhaltsverzeichnis
• 1 Einführung in agile Softwareentwicklung
• 2 Verträge für agile Softwareentwicklung
• 3 Juristische Grundlagen
• 4 Schätzung und Planung
• 5 Festpreisverträge
• 6 Time & Material
• 7 Bezahlung pro Sprint
• 8 Nutzenorientierte Verträge
• 9 Zusammenfassung und Ausblick
• Anhang
• Literatur
• Index
• Weitere