Bill of Rights im Agilen Manifest

Gastbeitrag von | 17.08.2020 | Prozesse & Methoden | 0 Kommentare

„Agiles Arbeiten“ ist heute ein vielgenutzter Begriff in Unternehmen jeglicher Art und Größe. Dessen Ursprung lässt sich nach Snowbird, Utah, zurückverfolgen. Dort trafen sich vor rund 20 Jahren 17 Menschen, um darüber zu sprechen, was in der Produktentwicklung zu Erfolg führt. Ihr Treffen und Brainstorming damals führte zum „Manifest für agile Softwareentwicklung“ – heute eher als „Agiles Manifest“ bekannt.

Ein Teil dieses Manifests ist die folgende „Bill of Rights“, eine Art Grundrechtskatalog mit dem Ziel, die Kluft zwischen geschäftlichen Belangen und Entwicklern zu überbrücken. Beachten Sie bitte bei der Lektüre, dass die Rechte von Kunden und Entwicklern einander ergänzen. Sie erzeugen so ein Gleichgewicht zwischen den Erwartungen der beiden Gruppen.

Bill of Rights für Kunden

Die Bill of Rights für Kunden umfasst folgende Punkte:

  • Sie haben das Recht auf einen vollständigen Zeitplan, aus dem hervorgeht, was wann erreichbar ist und welche Kosten damit verbunden sind.
  • Sie haben das Recht, bei jeder Iteration das bestmögliche Ergebnis zu erhalten.
  • Sie haben das Recht, Einblick in die Fortschritte eines laufenden Systems zu nehmen, dessen Funktionsfähigkeit durch das wiederholte Bestehen von ihnen festgelegter Tests belegt wird.
  • Sie haben das Recht, ihre Meinung zu ändern, Funktionalitäten zu ersetzen und neue Prioritäten vorzugeben, ohne dass exorbitante Kosten anfallen.
  • Sie haben das Recht, über Änderungen des Zeitplans und der Schätzungen informiert zu werden, und zwar so rechtzeitig, dass Anpassungen am Projektumfang vorgenommen werden können, um Termine einzuhalten. Sie können die Weiterentwicklung jederzeit abbrechen und behalten als Ergebnis der bisher getätigten Investitionen ein nützliches, funktionsfähiges System.

 

Bill of Rights für Entwickler

Die Bill of Rights für Entwickler umfasst folgende Punkte:

  • Sie haben das Recht, die Anforderungen und deren genauen Prioritäten zu kennen.
  • Sie haben das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.
  • Sie haben das Recht, Kollegen, Manager und Kunden um Hilfe zu bitten und diese zu erhalten.
  • Sie haben das Recht, eigene Schätzungen vorzunehmen und zu aktualisieren.
  • Sie haben das Recht, ihre Verantwortlichkeiten zu akzeptieren. Sie werden ihnen nicht einfach zugewiesen.

 

Kunden

Mit „Kunden“ sind in diesem Kontext Geschäftsleute im Allgemeinen gemeint. Dazu gehören die eigentlichen Kunden, Manager, Führungskräfte, Projektleiter sowie alle anderen Personen, die für Zeitplan und Budget Verantwortung tragen oder die für das System bezahlen und einen Nutzen daraus ziehen.

  • Kunden haben das Recht auf einen vollständigen Zeitplan, aus dem hervorgeht, was wann erreichbar ist und welche Kosten damit verbunden sind.

Viele haben behauptet, dass eine vorherige Planung kein Teil agiler Softwareentwicklung sei. Das erste Kundenrecht widerlegt diese Behauptung. Selbstverständlich ist ein Zeitplan erforderlich. Dieser Zeitplan muss natürlich Termine und Kosten beinhalten. Und dass der Zeitplan so realistisch und präzise wie praktikabel sein sollte, versteht sich auch von selbst.

Der letzte Satz beschreibt den Grund dafür, warum Entwickler oft in Schwierigkeiten geraten, denn es gibt nur eine Möglichkeit, sowohl realistische als auch präzise Angaben zu machen, nämlich das Projekt tatsächlich zu entwickeln. Es ist unmöglich, mit weniger Aufwand realistische und präzise Angaben zu machen. Um das erste Kundenrecht garantieren zu können, müssen die Entwickler gewährleisten, dass ihre Planung, ihre Schätzungen und Termine das Ausmaß der Unsicherheit korrekt wiedergeben, und festlegen, durch welche Maßnahmen die Unsicherheit verringert werden kann.

Kurz und bündig: Die Entwickler dürfen sich nicht darauf einlassen, einen festgelegten Funktionsumfang an einem bestimmten Datum abzuliefern. Es muss entweder beim Funktionsumfang oder beim Datum einen Spielraum geben, den sie durch eine Wahrscheinlichkeitskurve repräsentieren. Die ersten zehn Storys können beispielsweise mit 95 Prozent Wahrscheinlichkeit bis zum festgesetzten Datum fertiggestellt werden? Die Wahrscheinlichkeit, weitere fünf bzw. zehn bis zu diesem Datum fertigstellen zu können, beträgt 50 bzw. 5 Prozent. Die Kunden haben ein Anrecht auf eine solche, auf Wahrscheinlichkeiten beruhende Planung, weil sie ohne sie ihre Geschäftstätigkeit nicht ausüben können.

  • Kunden haben das Recht, bei jeder Iteration das bestmögliche Ergebnis zu erhalten.

Bei der agilen Softwareentwicklung werden die Bemühungen in Zeitintervalle fester Größe unterteilt, die sogenannten Iterationen. Der Kunde darf zu Recht davon ausgehen, dass die Entwickler zu jedem beliebigen Zeitpunkt an den wichtigsten Dingen arbeiten und dass ihm bei jeder Iteration das bestmögliche geschäftlich verwertbare Ergebnis bereitgestellt wird. Diese Priorisierung wird vom Kunden während der Planungssitzung am Anfang jeder Iteration festgelegt. Der Kunde wählt die Stories aus, die für ihn den höchsten Return on Investment bedeuten und mit der Schätzung der Entwickler für die Iteration vereinbar sind.

  • Kunden haben das Recht, Einblick in die Fortschritte eines laufenden Systems zu nehmen, dessen Funktionsfähigkeit durch das wiederholte Bestehen von ihnen festgelegter Tests belegt wird.

Aus Sicht des Kunden liegt das auf der Hand. Selbstverständlich haben Kunden das Recht, die allmählichen Fortschritte zu begutachten. Ebenso selbstverständlich ist, dass sie die Kriterien festlegen, denen die erzielten Fortschritte genügen müssen. Gleiches gilt natürlich auch für das Recht, schnell und wiederholt zu prüfen, ob ihre Akzeptanzkriterien erfüllt werden.

  • Kunden haben das Recht, ihre Meinung zu ändern, Funktionalitäten zu ersetzen und neue Prioritäten vorzugeben, ohne dass exorbitante Kosten anfallen.

Hier handelt es sich schließlich um Software. In der Lage zu sein, das Verhalten der Maschinen schnell und einfach zu ändern, ist ja der eigentliche Sinn von Software. Diese Flexibilität war der Grund dafür, dass Software überhaupt erfunden wurde. Deshalb haben Kunden selbstverständlich das Recht, die Anforderungen zu ändern.

  • Kunden haben das Recht, über Änderungen des Zeitplans und der Schätzungen informiert zu werden, und zwar so rechtzeitig, dass Anpassungen am Projektumfang vorgenommen werden können, um Termine einzuhalten.

Kunden können die Weiterentwicklung jederzeit abbrechen und behalten als Ergebnis der bisher getätigten Investitionen ein nützliches, funktionsfähiges System.

Beachten Sie hier, dass Kunden nicht das Recht haben, auf die Einhaltung des Zeitplans zu bestehen. Ihr Recht ist darauf beschränkt, den Funktionsumfang zu ändern, um den Zeitplan zu handhaben. Der entscheidende Punkt ist hier, dass dem Kunden das Recht gewährt wird, darüber informiert zu werden, wenn der Zeitplan in Gefahr ist, damit rechtzeitig entsprechende Maßnahmen getroffen werden können.

Entwickler

„Entwickler“ sind in diesem Kontext alle, die an der Entwicklung von Code arbeiten. Dazu gehören Programmierer, Mitarbeiter der Qualitätssicherung, Tester und Business Analysts.

  • Entwickler haben das Recht, die Anforderungen und deren genaue Prioritäten zu kennen.

Auch hier geht es wieder vornehmlich um Wissen. Entwickler haben Anspruch darauf, präzise über die Anforderungen und ihre Wichtigkeit informiert zu werden. Für die Anforderungen gelten hinsichtlich der Praktikabilität natürlich die gleichen Einschränkungen wie für Schätzungen. Es ist nicht immer möglich, die Anforderungen exakt festzulegen. Und tatsächlich haben Kunden ja auch das Recht, ihre Meinung zu ändern. Dieses Recht ist also lediglich innerhalb des Kontexts einer Iteration anwendbar. Außerhalb dieses Kontexts werden sich Anforderungen ändern und Prioritäten verschieben. Innerhalb einer Iteration haben Entwickler jedoch das Recht, sie als unveränderlich zu betrachten. Allerdings können Entwickler auch auf dieses Recht verzichten, falls sie eine der angeforderten Änderungen für unbedeutend halten.

  • Entwickler haben das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.

Hierbei dürfte es sich wohl um das tiefgreifendste all dieser Rechte handeln. Entwickler haben das Recht, vernünftige Arbeit zu leisten. Man darf sie nicht anweisen, Abstriche zu machen oder schlampig zu arbeiten. Oder anders ausgedrückt: Sie dürfen nicht aufgrund von geschäftlichen Umständen dazu gezwungen werden, ihren guten Ruf aufs Spiel zu setzen oder gegen ihren Berufsethos zu verstoßen.

  • Entwickler haben das Recht, Kollegen, Manager und Kunden um Hilfe zu bitten und diese zu erhalten.

Diese Art der Hilfe ist vielgestaltig. Programmierer können unter anderem Kollegen um Hilfe bei der Lösung eines Problems, der Überprüfung eines Ergebnisses oder dem Erlernen eines Frameworks bitten. Entwickler können Kunden darum bitten, die Anforderungen besser zu beschreiben oder die Prioritäten genauer festzulegen. Vor allem verleiht diese Aussage Programmierern das Recht, zu kommunizieren. Und mit dem Recht, um Hilfe zu bitten, geht die Pflicht einher, Hilfe zu leisten, wenn sie darum gebeten werden.

  • Entwickler haben das Recht, eigene Schätzungen vorzunehmen und zu aktualisieren.

Die Aufgabe der Aufwandsschätzung kann Ihnen niemand abnehmen. Und wenn Sie eine Schätzung vornehmen, können Sie diese korrigieren, wenn weitere Faktoren ins Spiel kommen. Schätzungen sind Mutmaßungen. Zweifelsohne wohldurchdachte Mutmaßungen, aber dennoch Mutmaßungen. Es sind Mutmaßungen, die im Laufe der Zeit immer besser werden. Schätzungen sind nie verbindlich.

  • Entwickler haben das Recht, ihre Verantwortlichkeiten zu akzeptieren. Sie werden ihnen nicht einfach zugewiesen.

Professionelle Entwickler akzeptieren eine Aufgabe. Sie wird ihnen nicht einfach nur zugewiesen. Ein Entwickler ist berechtigt, eine Aufgabe abzulehnen. Vielleicht traut er sich nicht zu, die Aufgabe zu bewältigen oder findet, dass die Aufgabe besser für jemand anderen geeignet ist. Es könnte auch sein, dass ein Entwickler eine Aufgabe aus persönlichen oder moralischen Gründen ablehnt. (Denken Sie nur an die Entwickler bei Volkswagen, die es „akzeptiert“ haben, die Abgastests der kalifornischen Umweltschutzbehörde zu umgehen.)

Das Recht, Aufgaben zu akzeptieren, bedeutet aber auch, Verantwortung zu übernehmen. Ein Entwickler, der eine Aufgabe akzeptiert, ist für die Qualität und die Durchführung der Aufgabe verantwortlich. Er muss die Aufwandsschätzung kontinuierlich aktualisieren, damit der Zeitplan angepasst werden kann. Er muss den Status dem gesamten Team mitteilen und bei Bedarf um Hilfe bitten. Bei der Programmierung im Team müssen Anfänger und erfahrenen Programmierern eng zusammenarbeiten. Das Team hat das Recht, gemeinsam zu entscheiden, wer welche Aufgaben erledigt, hat dabei aber nicht das Recht, irgendjemanden dazu zu zwingen, eine bestimmte Aufgabe zu übernehmen.

 

Hinweis:

Dieser Artikel ist ein Auszug aus dem neuen Buch „Clean Agile – Die Essenz der agilen Softwareentwicklung“ von Robert C. Martin. Alle Infos zum Buch, das Inhaltsverzeichnis und eine kostenlose Leseprobe finden Sie hier beim Fachbuchverlag für IT, Business und Fotografie mitp

Clean Agile - das aktuelle Buch von Robert C. Martin

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie Aspekte anders sehen oder ergänzen wollen, hinterlassen Sie bitte einen Kommentar.

Robert C. Martin
Robert C. Martin

Robert C. Martin („Uncle Bob“) ist bereits seit 1970 als Programmierer tätig. Neben seiner Beraterfirma Uncle Bob Consulting, LLC gründete er gemeinsam mit seinem Sohn Micah Martin auch das Unternehmen The Clean Coders, LLC. Er hat zahlreiche Artikel in verschiedenen Zeitschriften veröffentlicht und hält regelmäßig Vorträge auf internationalen Konferenzen. Zu seinen bekanntesten Büchern zählen Clean Code, Clean Coder und Clean Architecture. Und er ist einer von 17 Personen, die das Agile Manifest unterzeichnet haben.