Beim Stöbern in der Bücherecke bin ich über „Uncle Bob’s“ Buch Clean Agile. Die Essenz der agilen Softwareentwicklung – Zurück zu den Ursprüngen: Die agilen Werte und Prinzipien effektiv in der Praxis umsetzen gestolpert. Es ist bereits im July 2020 raus gekommen, aber das ist an mir vorbeigerauscht… Jetzt habe ich es entdeckt und gelesen. Ich finde es ein sehr cooles Buch. Es beschreibt die Ursprünge der agilen Bewegung und um was es sich wirklich geht.
Dabei hat er die Bill of Rights der Kunden und der Entwickler erwähnt. Das kannte ich bis heute nicht. Finde diesen als Zusatz zum agilen Manifesto aber sehr spannend und hilfreich.
Einige der Autoren des Agilen Manifests haben die Customer Bill of Rights und die Developer Bill of Rights entwickelt. Durch diese Rechte wird klarer, was agile Entwicklung ist und was nicht. Die Kenntnis dieser gegenseitigen Rechte hilft dem Kunden, den Entwickler zu verstehen und umgekehrt.
Hier die Übersicht:
Kundenrechte (Bill of Rights)
Die Kundenrechte beinhalten die folgenden Punkte:
- Du hast das Recht auf einen Gesamtplan und darauf zu wissen, was wann und zu welchen Kosten erreicht werden kann.
- Du hast das Recht, aus jeder Iteration den größtmöglichen Nutzen zu ziehen.
- Du hast das Recht, den Fortschritt in einem laufenden System zu sehen, das durch wiederholbare Tests, die du festgelegt hast, bewiesen hat, dass es funktioniert.
- Du hast das Recht, deine Meinung zu ändern, Funktionen auszutauschen und Prioritäten zu ändern, ohne exorbitante Kosten zu zahlen.
- Du hast das Recht, über Änderungen im Zeitplan und im Kostenvoranschlag informiert zu werden, so dass du rechtzeitig entscheiden kannst, wie du den Umfang reduzierst, um den gewünschten Termin einzuhalten. Du kannst jederzeit kündigen und erhältst ein funktionierendes System, das deine bisherigen Investitionen widerspiegelt.
Rechte des Entwicklers
Die Rechte des Entwicklers umfassen Folgendes:
- Du hast das Recht zu wissen, was benötigt wird, und zwar mit klaren Prioritätserklärungen.
- Du hast das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.
- Du hast das Recht, um Hilfe von Kollegen, Managern und Kunden zu bitten und diese zu erhalten.
- Du hast das Recht, deine eigenen Schätzungen zu erstellen und zu aktualisieren.
- Du hast das Recht, deine Verantwortung zu übernehmen, anstatt sie dir auferlegen zu lassen.
Das sind sehr starke Aussagen. Wir sollten sie nacheinander betrachten. Der nachfolgende Text stammt im Original von Robert C. Martin Oct 29, 2019
Ich habe den Text übersetzt und an einigen Stellen leicht angepasst.
Rechte der Kunden
Das Wort „Kunde“ bezieht sich in diesem Zusammenhang auf Geschäftsleute im Allgemeinen. Dazu gehören echte Kunden, Manager, Führungskräfte, Projektleiter und alle anderen, die die Verantwortung für den Zeitplan und das Budget tragen oder die für die Ausführung des Systems bezahlen und davon profitieren werden.
1. Die Kunden haben das Recht auf einen Gesamtplan und darauf zu wissen, was wann und zu welchen Kosten erreicht werden kann.
Viele Menschen haben behauptet, dass die Planung im Voraus nicht Teil der agilen Entwicklung ist. Schon das erste Kundenrecht widerlegt diese Behauptung. Natürlich braucht das Unternehmen einen Plan. Natürlich muss dieser Plan den Zeitplan und die Kosten enthalten. Und natürlich sollte dieser Plan so genau und präzise wie möglich sein.
Gerade der letzte Punkt bringt uns oft in Schwierigkeiten, denn die einzige Möglichkeit, sowohl genau als auch präzise zu sein, besteht darin, das Projekt tatsächlich zu entwickeln. Wenn wir weniger tun, ist es unmöglich, beides zu erreichen. Um dieses Recht zu gewährleisten, müssen wir Entwickler also sicherstellen, dass unsere Pläne, Schätzungen und Zeitpläne den Grad unserer Unsicherheit richtig beschreiben und die Mittel festlegen, mit denen diese Unsicherheit gemindert werden kann.
Kurz gesagt, wir können uns nicht darauf einigen, feste Umfänge zu festen Terminen zu liefern. Entweder müssen die Umfänge oder die Termine weich sein. Wir stellen diese Weichheit mit einer Wahrscheinlichkeitskurve dar. Wir schätzen zum Beispiel, dass es eine 95%ige Wahrscheinlichkeit gibt, dass wir die ersten zehn Stories bis zum Termin fertigstellen können. Eine 50%ige Chance, dass wir die nächsten fünf bis zum Termin fertigstellen können. Und eine 5 %ige Chance, dass die fünf darauffolgenden bis zum Termin fertig werden.
2. Die Kunden haben ein Recht auf diese Art von wahrscheinlichkeitsbasierten Plänen, weil sie ohne sie ihr Geschäft nicht führen können.
Die Kunden haben das Recht, aus jeder Iteration den größtmöglichen Nutzen zu ziehen.
Agile unterteilt den Entwicklungsaufwand in feste Zeitabschnitte, die Iterationen genannt werden. Das Unternehmen hat das Recht zu erwarten, dass die Entwickler zu jedem Zeitpunkt an den wichtigsten Dingen arbeiten und dass jede Iteration den größtmöglichen Nutzen für das Unternehmen bringt. Diese Wertpriorität wird vom Kunden in den Planungssitzungen zu Beginn einer jeden Iteration festgelegt. Die Kunden wählen die Storys aus, die ihnen den größten Nutzen bringen und die in die Schätzung des Entwicklers für die Iteration passen.
3. Die Kunden haben ein Recht darauf, den Fortschritt in einem laufenden System zu sehen, dessen Funktionstüchtigkeit durch wiederholbare, von ihnen festgelegte Tests nachgewiesen ist.
Das scheint offensichtlich zu sein, wenn du es aus der Sicht des Kunden betrachtest. Natürlich haben sie das Recht, schrittweise Fortschritte zu sehen. Natürlich hat er das Recht, die Kriterien für die Akzeptanz dieses Fortschritts festzulegen. Natürlich haben sie das Recht, schnell und wiederholt den Beweis zu sehen, dass ihre Abnahmekriterien erfüllt wurden.
4. Die Kunden haben das Recht, ihre Meinung zu ändern, Funktionen auszutauschen und Prioritäten zu ändern, ohne exorbitante Kosten zu zahlen.
Schließlich handelt es sich um Software. Der Sinn von Software besteht darin, dass wir das Verhalten unserer Maschinen leicht ändern können. Die Weichheit ist der Grund, warum Software überhaupt erst erfunden wurde. Deshalb haben die Kunden natürlich das Recht, die Anforderungen zu ändern.
5. Die Kunden haben das Recht, rechtzeitig über Änderungen im Zeitplan und in der Schätzung informiert zu werden, damit sie entscheiden können, wie sie den Umfang ändern, um den gewünschten Termin einzuhalten.
Die Kunden können jederzeit kündigen und erhalten ein brauchbares, funktionierendes System, das die bisherigen Investitionen widerspiegelt.
Beachte, dass die Kunden nicht das Recht haben, die Einhaltung des Zeitplans zu verlangen. Ihr Recht beschränkt sich darauf, den Zeitplan durch Änderung des Umfangs zu beeinflussen. Das Wichtigste, was dieses Recht mit sich bringt, ist das Recht zu wissen, dass der Zeitplan in Gefahr ist, damit er rechtzeitig geändert werden kann.
Die Rechte der Entwickler/innen
In diesem Zusammenhang sind Entwickler/innen alle, die an der Entwicklung von Code arbeiten. Dazu gehören Programmierer, QA, Tester und Business-Analysten.
1. Die Entwickler haben das Recht zu wissen, was benötigt wird, und zwar mit klaren Prioritätserklärungen.
Auch hier liegt der Schwerpunkt auf dem Wissen. Die Entwickler haben ein Recht darauf, die Anforderungen und die Wichtigkeit dieser Anforderungen genau zu kennen. Natürlich gelten für Anforderungen dieselben Einschränkungen der Praktikabilität wie für Schätzungen. Es ist nicht immer möglich, die Anforderungen genau zu formulieren. Und natürlich haben Kunden das Recht, ihre Meinung zu ändern.
Dieses Recht gilt also nur im Rahmen einer Iteration. Außerhalb einer Iteration werden sich die Anforderungen und Prioritäten verschieben und ändern. Aber innerhalb einer Iteration haben die Entwickler das Recht, sie als unveränderlich zu betrachten. Denke jedoch immer daran, dass die Entwickler/innen auf dieses Recht verzichten können, wenn sie eine geforderte Änderung für unbedeutend halten.
2. Entwickler/innen haben das Recht, jederzeit qualitativ hochwertige Arbeit zu leisten.
Dieses Recht ist vielleicht das wichtigste von allen. Entwicklerinnen und Entwickler haben das Recht, gute Arbeit zu leisten. Das Unternehmen hat kein Recht, den Entwicklern vorzuschreiben, dass sie Abstriche machen oder minderwertige Arbeit leisten sollen. Oder anders ausgedrückt: Das Unternehmen hat kein Recht, Entwickler/innen dazu zu zwingen, ihren beruflichen Ruf zu ruinieren oder gegen ihre Berufsethik zu verstoßen.
3. Entwickler/innen haben das Recht, um Hilfe von Kolleg/innen, Manager/innen und Kund/innen zu bitten und diese auch zu erhalten.
Diese Hilfe kommt in vielen Formen. Programmierer/innen können sich gegenseitig um Hilfe bei der Lösung eines Problems, der Überprüfung eines Ergebnisses oder dem Erlernen eines Frameworks bitten, um nur einige Beispiele zu nennen. Entwickler/innen können Kunden bitten, Anforderungen besser zu erklären oder Prioritäten zu verfeinern. Meistens gibt diese Erklärung den Programmierern das Recht zu kommunizieren. Und mit dem Recht, um Hilfe zu bitten, kommt auch die Verantwortung, Hilfe zu geben, wenn man darum gebeten wird.
4. Entwickler/innen haben das Recht, ihre eigenen Schätzungen zu erstellen und zu aktualisieren.
Keiner kann eine Aufgabe für dich schätzen. Und wenn du eine Aufgabe schätzt, kannst du deine Schätzung jederzeit ändern, wenn neue Faktoren ans Licht kommen. Kostenvoranschläge sind Schätzungen. Es sind zwar intelligente Schätzungen, aber es sind immer noch Schätzungen. Es sind Schätzungen, die mit der Zeit besser werden. Schätzungen sind niemals Verpflichtungen.
5. Entwickler/innen haben das Recht, ihre Aufgaben anzunehmen, anstatt sie zugewiesen zu bekommen.
Fachleute nehmen Arbeit an, sie bekommen keine Arbeit zugewiesen. Ein professioneller Entwickler hat das Recht, „nein“ zu einer bestimmten Aufgabe zu sagen. Es kann sein, dass der/die Entwickler/in sich nicht sicher ist, ob er/sie die Aufgabe erledigen kann, oder dass er/sie glaubt, dass die Aufgabe besser für jemand anderen geeignet ist. Oder es kann sein, dass der/die Entwickler/in die Aufgabe aus persönlichen oder moralischen Gründen ablehnt.6
In jedem Fall hat das Recht, eine Aufgabe anzunehmen, seinen Preis. Akzeptanz bedeutet Verantwortung. Der akzeptierende Entwickler übernimmt die Verantwortung für die Qualität und die Ausführung der Aufgabe, für die ständige Aktualisierung des Kostenvoranschlags, damit der Zeitplan eingehalten werden kann, für die Mitteilung des Status an das gesamte Team und für die Bitte um Hilfe, wenn diese benötigt wird.
Programmieren im Team bedeutet, eng mit Junioren und Senioren zusammenzuarbeiten. Das Team hat das Recht, gemeinsam zu entscheiden, wer was tun soll. Ein technischer Leiter kann einen Entwickler bitten, eine Aufgabe zu übernehmen, hat aber nicht das Recht, jemandem eine Aufgabe aufzudrängen.
