Probleme beim Einloggen
Nur für XING Mitglieder sichtbar Einheitlicheres Design für die "Marke" CCD?
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Ralf Westphal
+4 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
habs mal getwittert. (mist, leider mit einem schreibfehler drin :-) sorry. so kommt es, wenn man es besonders gut machen will und noch lange dran rumfeilt.)
Ralf Westphal Results only software development?
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.
XDSD gibt keine Schätzungen ab. Es wird höchstens aufgrund von historischen Daten vorhergesagt (vgl. https://ralfw.de/2018/02/featureforecast-sagst-du-schon-vorher-oder-schatzt-du-noch/).
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.
Philipp Stiefel Maximilian Raab
+19 weitere Kommentare
Letzter Kommentar:
Benjamin Wolf
Ich finde den Ansatz recht interessant. Bisher arbeitete ich immer in Teams, die zum Großteil im gleichen Büro arbeiteten. Das erleichtert einerseits ungemein, auf Grund der direkten Kommunikation. Andererseits geht doch einiges verloren, das nicht in Issues geschrieben wird. Ich hatte versucht, meine Kolleginnen und Kollegen mehr Richtung Issues zu schieben, jedoch erfordert das in dieser Konstellation sehr viel Selbstdisziplin der einzelnen Leute.
Aktuell arbeite ich in einem Projekt, wo wir größtenteils verteilt sitzen, so dass die Kommunikation für die Entwicklung dort zumeist über Issues läuft (>90%). Gerade für Architekturentscheidungen bzw. die vorhergehenden -Diskussionen finde ich persönlich jedoch die direkte Kommunikation wichtig, sei es vor Ort am Whiteboard oder über Telefonie (slack, Skype, etc.). Aber möglicherweise sind das die Punkte, die als „Fundament“ gesehen werden, das zuerst existieren muss, bevor man mit XDSD loslegt.
Ich werde aber einiges davon mal in den Alltag hineinwerfen und schauen, wie es funktioniert.
Noch kurz etwas zur Kritikphase der agilen Entwicklung, Ralf:
Aus eigener Erfahrung kann ich sagen, dass im Enterprise-Umfeld Agile erst so langsam als tatsächliche Möglichkeit der Entwicklung in Betracht gezogen wird. ;-)
Ralf Westphal Arbeitgebern auf den Zahn fühlen
Die Zeiten wandeln sich wahrlich: Jetzt bewerben sich schon die Arbeitgeber bei den Arbeitnehmern. Zumindest in der Softwarebranche. Und das mit einigem Feuerwerk.
Auf der OOP Konferenz in München war ich schon erschlagen von den ganzen Recruitern. Früher wurden da Produkte an den Messeständen feilgeboten, jetzt schienen es mir vor allem Jobs. VW war auch da und ich habe geschwankt zwischen Lachen und Kopfschütteln. Wahnsinn, wie die ganz unbeeindruckt vom Dieselskandal, der ja ein Softwareskandal ist, mich anheuern wollten: "Alles super bei VW!" Na, ich weiß nicht... Aber egal.
Heute nun bin ich über diesen Event gestolpert, der das nochmal auf ein neues Niveau hebt: https://www.thepitchclub.com/de/pcde/
Am 14.3. in Hamburg sowie am 15.3. in Berlin preisen sich Arbeitgeber auf einem augenscheinlich coolen Event an. Für Softwareentwickler ist die Teilnahme natürlich kostenlos.
Ich bin dabei in Hamburg. Das will ich mir mal anhören. Da kann ich gleich mal den Arbeitgebern auf den Zahn fühlen, was die von nachhaltiger Softwareproduktion denken. Wer macht noch mit? Oder in Berlin?
-Ralf
Clean Code online Mentoring: ccd-school.de/online-mentoring/
Markus Wagner Warum Clean Code Developer...
In diesem Beitrag werden wir uns mit der Frage beschäftigen, warum es innerhalb eines Entwicklungsteams Prinzipien und Praktiken braucht, um qualitativ hochwertige Softwaresysteme zu erstellen. Um den Stellenwert von CCD zu bestimmen sehen wir uns folgende Ebenen der Softwareentwicklung und ihre Aufgaben an:
• Agile Frameworks, Vorgehensmodelle, Prozesse (Scrum, Kanban, LeSS, SAFe usw.)
• Übersetzungsprozesse, fachliche Ebene: (IIBA, Volere, CMMI, BDD usw.)
• Architektur (DDA, DDD, MDA, SOA, Microservice usw.)
• Agile Entwicklungsmethoden (Pairprogramming, TDD, CI/CD, Codereviews usw.)
Denis Kuniss Markus Wagner Roland Golla Ralf Westphal
+6 weitere Kommentare
Letzter Kommentar:
Markus Wagner

>Hilfreich wäre noch, diesen Artikel kurz ins Verhältnis zum ersten geposteten Artikel im adesso-Blog (https://www.xing.com/communities/posts/clean-code-developer-teil-1-1014424953) zu setzen. Sie scheinen das selbe Thema zu beleuchten, aber sind schon unterschiedlich...
Nun ich denke das hier der Titel einiges sagt. Wären die Adesso Blogs doch eher eine kurze Übersicht über CCD bieten, versuche ich dagegen in meinen devblogs.ch Beiträgen etwas tiefer in die Fragen: Warum, Was, Wie einzutauchen.
Aber danke für den Hinweis, ich werde versuchen in Zukunft eine etwas genauere Moderation zu den Beiträgen hinzuzufügen.
Viele Grüsse
Markus Wagner
Nur für XING Mitglieder sichtbar Clean Java Script - Strategien für die Quadratur des Kreises
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Roland Golla Stefan Lieser Denis Kuniss
+6 weitere Kommentare
Letzter Kommentar:

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.954
  • Sichtbarkeit: offen
  • Beiträge: 477
  • Kommentare: 2.973