Neulich bin ich über XDSD gestolpert:
http://www.xdsd.org Das bedeutet: eXtremely Distributed Software Development.
Oder ich würde sagen, man kann es auch noch anders nennen: eXtremely Different Software Development :-) Weil es schon sehr anders als üblich abläuft. Da werden einige sehr liebgewonnene Muster auf den Kopf gestellt. I like :-) Schon wegen der Provokation des status quo.
Die grundsätzliche Verteilung der Entwickler ei XDSD finde ich allerdings gar nicht so entscheidend. Sie ergibt sich als Möglichkeit schlicht durch den ganz anderen Fokus. Deshalb würde ich die Bezeichnung anders wählen und sagen, es handelt sich um ROSD: Results Only Software Development. Es wird nämlich nur für Resultate bezahlt.
Ich versuche mal, den absoluten Kern des Ansatzes zu beschreiben. Dabei gehen natürlich Nuancen verloren, so dass bei euch mehr Stirnrunzeln als nötig entsteht. Aber es hilft nichts. Wer sich für die Nuancen interessiert, der kann von der Website ausgehend eine ganze Menge Lesestoff und Videos finden. Der Erfinder Yegor Bugayenko ist ein Enthusiast und hat viel veröffentlicht.
Also:
Bei XDSD geht es nur um den Code. Oder besser: um das Repository. Alles dreht sich um Veränderungen an Artefakten, die ein Projekt auf Kurs halten und dem Ziel näher bringen. Vorzugsweise geht es natürlich bei den Artefakten um Code-Dateien, aber Dokumentation in Form von Markdown-Files wird nicht ausgeschlossen.
Das Repo ist the single source of truth. Endlich ;-)
Da ist XDSD total rigoros. Denn es wird jede andere Kommunikation außerhalb des Repo untersagt. Klingt extrem, ist aber so. Also keine Meetings, kein Team-Chat, keine Hangouts, keine Skype, keine Email. Nichts außer hinterlassen von Spuren in Artefakten - und Kommunikation über Repo-Issues.
Aber das ist nicht das einzige Extrem. XDSD ist auch extrem beim Kleinschneiden von Anforderungen. Issues im Repo sind so konzipiert, dass sie immer [1] mit einem Aufwand von 30min zu erledigen sind.
Damit nicht genug. Wer ein Issue erledigt, wird bei XDSD nicht vom Entwickler bestimmt, sondern "vom System". Und zwar per Zufall. Niemand weiß also, welches Issue er/sie als nächstes zu bearbeiten hat.
Natürlich ist es unmöglich vorherzusehen, ob ein Issue wirklich in 30min komplett erledigt werden kann. Aber das ist auch nicht nötig. Denn wieder ist XDSD extrem. Es geht nämlich nicht um Erledigung aus Sicht des Kunden. Wenn ein Issue lautet "Schreibe eine Funktion, die die nicht-Kommentar-Zeilen in einer Code-Datei zählt.", dann glaubt XDSD nicht daran, dass das jmd wirklich funktional und auch noch sauber in 30min hinbekommt.
Ziel jedes Issue ist es vielmehr, 30min thematisch fokussiert auf die Herstellung eines Resultats zu verwenden. Die Entwicklerin, die das Issue zugewiesen bekommt, kann als Lösung also z.B. einen Funktionsrumpf plus einen grünen Test einreichen.
Einreichungen geschehen immer per Pull-Request. Der PR wird dann reviewt und wenn er formal passt und der Reviewer den Eindruck hat, dass der Inhalt nicht trivial ist, dann wird der PR akzeptiert und gemerget und das Issue geschlossen und die Entwicklerin für 30min bezahlt.
XDSD betont, dass jeder, der ein Issue bearbeitet, faul sein soll :-) So wenig Aufwand treiben wie möglich, um das Issue zu befriedigen, also etwas zu liefern, das akzeptiert wird.
Das bedeutet auch, dass man gar nicht erst anfängt mit dem Issue, solange noch etwas unklar ist. Erstes Mittel bei Unklarheit: eine Frage stellen an den Issue-Autor im Repo.
Zweites Mittel: selbst ein Issue aufmachen mit der Forderung nach mehr Information. Wenn man merkt, dass Grundlegendes fehlt, dann hilft nicht der Austausch mit dem Autor, sondern dann muss ein Artefakt ergänzt/erstellt werden. Vielleicht muss auch refaktorisiert werden. Aber das macht man eben nicht selbst, wenn man ein Issue an der Backe hat, sondern schreibt dafür eine Aufforderung "an das System" - und lehnt sich zurück, bis das erledigt ist.
Für solche Issues kann man sogar bezahlt werden. Man bekommt dafür durchaus Zeit gutgeschrieben. Dito für Bug Reports: 15min.
XDSD legt also viel wert auf innere Qualität, auf Sauberkeit!
Wenn man dann aber ein Issue wirklich erledigen will, dann bedeutet das nicht - wie gesagt -, dass man die Lösung komplett liefert. Stattdessen macht man einen Beitrag, der die Lösung näher rücken lässt - und schreibt weitere Issues zu dem, was man bewusst nicht getan hat.
In Bezug auf das Beispiel oben könnte das so aussehen:
* Die Entwicklerin reicht einen Test ein, der grün ist, weil der Funktionsrumpf hart verdrahtet das korrekte Resultat liefert.
* Außerdem schreibt die Entwicklerin 3 Issues (XDSD nennt das "puzzles",
http://www.yegor256.com/2010/03/04/pdd.html):
1. Es ist ein weiterer Test für den Fall soundso nötig.
2. Es ist eine Funktion nötig, die Quelltext in Tokens der der Art A,B,C zerlegt.
3. Es ist eine Funktion nötig, die aus der Reihenfolge der Tokens erkennt, wann Zeilen ausschließlich in einem Kommentar liegen.
Diese "Rätsel" würde die Entwicklerin sogar im Code hinterlassen als Kommentare. Ein XDSD Tool sammelt sie und macht autom. daraus Issues.
Damit hat die Entwicklerin ihre Schuldigkeit getan und wird entlohnt. Vielleicht hat sie 25min dafür gebraucht, vielleicht 35min, Geld gibt es aber nur für die festgelegten 30min.
Wie viel ein Entwickler für die Behandlung eines Issue bekommt, ist also klar. Wie viel Zeit er hineinsteckt, ist ihm überlassen.
Wie viel die Entwicklung eines Feature kostet, das mit einem "root issue" beginnt, ist hingegen nicht klar. Aus dem einen Issue, das sich aus dem Gespräch mit dem Kunden ergeben hat, wächst unter Umständen ja ein Baum von Issues; es können Dutzende oder Hunderte entstehen.
Der Kunde bekommt also keinen Fixpreis. Der Kunde bezahlt aber auch nicht einfach Zeit. Er bezahlt - und das ist XDSD ganz wichtig - Resultate. Auf der Rechnung stehen all die vielen Issues, die im Verlauf einer Periode erledigt wurden (
http://www.yegor256.com/2014/10/21/incremental-billing.html).
Jedes geschlossene Issue ist ein Resultat, ein Fortschritt. Eine kleine Verbesserung wurde eingebaut, ein Bug gefixt usw. usf. Das versteht der Kunde vllt nicht alles - aber jedenfalls sieht er ganz konkret, was alles getan wurde. Er bezahlt nicht irgendwie für Zeit, in der Entwickler etwas Unbestimmtes (womögl. in Meetings sitzen), sondern für Effekte auf der Codebasis.
Ich finde XDSD sehr spannend. Einerseits, weil es Entwickler befreit von der Co-Location. Das ist vorteilhaft für Entwickler, weil sie damit freier in Zeit und Raum sind. Das ist vorteilhaft für Unternehmen, weil die damit beim Recruiting mehr Wahl bekommen.
Andererseits und vor allem gefällt mir, dass hier jeder Silobildung entgegen gewirkt wird. Wissen in Köpfen ist verpönt. Darauf wird ganz bewusst nicht gesetzt. Deshalb werden Entwickler zufällig den Issues zugewiesen. Deshalb wird man belohnt, wenn man Issues eröffnet, die der Dokumentationsverbesserung oder Strukturverbesserung dienen, um schneller mehr Klarheit zu bekommen.
Ich sehe auch Lücken und offene Fragen bei XDSD; es ist nicht alles rosig. Doch das ist wirklich mal ein Ansatz, der über das Bisherige hinausgeht.
Agil ist "nur" waterfall on steroids ;-) Das grundsätzliche Paradigma des Vorgehens wird nicht wirklich hinterfragt, wenn man die Kommunikation aufdreht und inkrementell in 1-2 Wochen Iterationen arbeitet.
Bei XDSD hingegen wird der agile Grundgedanke negiert: dass es um Menschen geht bei der Softwareentwicklung. Dass es um spezielle Menschen geht.
Bisher kontrollieren Menschen Code, ob im Wasserfall oder agil, ob mehr oder weniger lean.
Bei XDSD gibt es diese Kontrolle nicht mehr. Das ist mein Verständnis, auch wenn Yegor das so nicht sagt. Bei XDSD ist der Gedanke, Überblick behalten zu wollen, nämlich illusorisch und überflüssig. Niemand muss oder soll wissen, was wo gerade getan wird. Der Fortschritt ist automatisch, denn Issues, die vom zugewiesenen Entwickler nicht erledigt werden, werden ihm nach einigen Tagen entzogen und jmd anderem zugewiesen. Dafür bekommt der ursprüngliche Entwickler eine Strafzeit. Das ist total unemotional. Schlicht eine Regel, die motivieren soll, vorwärts zu gehen. Irgendwie. Hauptsache PR einreichen und akzeptiert bekommen.
Bei XDSD gibt es keine Kontrolle mehr, sondern Evolution. Die Software (oder das Repo) evolviert aus sich heraus. Die Regeln sorgen dafür, dass das Ganze sich positiv entwickelt, auch wenn jeder nur lokal für sich optimiert handelt.
Von außen kommen immer wieder Anregungen/Impulse in Form von neuen root issues - und die führen dann zu Veränderungen in der Codebasis. Issue für Issue. Ohne, dass das vorhergesehen oder kontrolliert würde.
Das (!) ist für mich ein Paradigmenwechsel.
Soweit mal meine Vorstellung von XDSD. Würde mich freuen, wenn sie zu Diskussionen hier Anlass gäbe.
[1] Ok, nicht immer. Aber so oft, dass es nicht lohnt, hier zu nuancieren.
