[erledigt] Wieder pic: Kreislinien verbergen? ‒ und "Clean Agile"

[paedubucher]

Ich übe mich wieder einmal etwas in pic, dieses mal geht es darum, drei konzentrische Kreise mit jeweils vier Boxen auf den einzelnen Bahnen darzustellen.

Hier ist mein Ansatz:

Code: Alles auswählen

.PS

PP: box invis wid 1 ht 0.5 "Pair" "Programming"
TDD: box invis same "Test-Driven" "Development" at PP + (1.0, 1.0)
SD: box invis same "Simple" "Design" at PP + (1.0, -1.0)
RFT: box invis same "Refactoring" at PP + (2.0, 0)

arc cw rad 1.0 from PP to TDD 
arc cw rad 1.0 from SD to PP
arc cw rad 1.0 from TDD to RFT
arc cw rad 1.0 from RFT to SD

CI: box invis same "Continuous" "Integration" at PP + (-0.25, 1.25)
MT: box invis same "Metaphor" at PP - (0.25, 1.25)
CO: box invis same "Collective" "Ownership" at RFT + (0.25, 1.25)
SP: box invis same "Sustainable" "Pace" at RFT + (0.25, -1.25)

arc cw rad 1.75 from CI to CO chop
arc cw rad 1.75 from SP to MT
arc cw rad 1.75 from MT to CI
arc cw rad 1.75 from CO to SP

WT: box invis same "Whole" "Team" at TDD + (0.0, 1.5)
SR: box invis same "Small" "Releases" at SD - (0.0, 1.5)
AT: box invis same "Acceptance" "Tests" at PP - (1.5, 0)
PG: box invis same "Planning" "Game" at RFT + (1.5, 0)

arc cw rad 2.5 from AT to WT
arc cw rad 2.5 from SR to AT
arc cw rad 2.5 from WT to PG
arc cw rad 2.5 from PG to SR

.PE

Und hier ist die Ausgabe dazu:



Die Radien stimmen, doch sie verdecken die Boxen und den Text. Das ist nicht weiter verwunderlich, da ich ja die Boxen zuerst zeichne, dann den Text. Nun sehe ich verschiedene Lösungsansätze:

1. Ich könnte die Bögen nicht im Zentrum, sondern an den Kompasspunkten aussen an den Boxen andocken. Dadurch werden aber die Bögen gestaucht, wodurch sich keine schönen Kreise mehr ergeben.
2. Ich könnte im ersten Durchlauf leere Boxen an den richtigen Stellen hinmalen, dann die Bögen machen. Anschliessend überschreibe ich die leeren Boxen mit solchen,d ie einen textuellen Inhalt haben. Ob das funktioniert?
3. Die Hintergrundfarbe der Boxen auf Schwarz stellen und die Schrift auf weiss (geht das?) hilft ja wohl wenig, wenn nacher die Bögen darübergemalt werden.

Hat jemand eine Idee, welcher Anssatz der erfolgversprechendste sein könnte? Ich verwende GNU pic.

[Meillo]

Siehe 10.5 ``the chop modifier'' in http://ytdp.ee.wits.ac.za/help/gpic.pdf

Du machst den Arc dann zwischen den Mittelpunkten der Boxen und laesst die Linie mittels `chop' passend zuschneiden. Das sollte dein Problem loesen.

[paedubucher]

Siehe 10.5 ``the chop modifier'' in http://ytdp.ee.wits.ac.za/help/gpic.pdf

Du machst den Arc dann zwischen den Mittelpunkten der Boxen und laesst die Linie mittels `chop' passend zuschneiden. Das sollte dein Problem loesen.

Das hatte ich auch versucht, aber vergessen zu erwähnen. Tatsächlich habe ich es vergessen zu entfernen oben in meinem Beispiel, siehe ungefähr in der Mitte. Leider klappt das nicht

[Meillo]

Ist das Verhalten gleich wenn die Box nicht `invis' ist?


Edit: Vielleicht geht das auch nur bei Kreisen. Nimm vielleicht mal ein `circle invis' statt einer `box invis'.

[paedubucher]

Ist das Verhalten gleich wenn die Box nicht `invis' ist?


Edit: Vielleicht geht das auch nur bei Kreisen. Nimm vielleicht mal ein `circle invis' statt einer `box invis'.

Da helfen weder sichtbare Boxen, noch Circles. Ich habe aber jetzt mit mehrmaligen Überschreiben eine Lösung gefunden:

Code: Alles auswählen

.PS

PP: box invis rad 0.25 wid 1 ht 0.5
TDD: box invis same at PP + (1.0, 1.0)
SD: box invis same at PP + (1.0, -1.0)
RF: box invis same at PP + (2.0, 0)

arc cw rad 1.0 from PP to TDD 
arc cw rad 1.0 from SD to PP
arc cw rad 1.0 from TDD to RF
arc cw rad 1.0 from RF to SD

box fill 1.0 same at PP; box fill 0.05 same "Pair" "Programming" at PP
box fill 1.0 same at TDD; box fill 0.05 same "Test-Driven" "Development" at TDD
box fill 1.0 same at SD; box fill 0.05 same "Simple" "Design" at SD
box fill 1.0 same at RF; box fill 0.05 same "Refactoring" at RF

CI: box invis same at PP + (-0.25, 1.25)
MT: box invis same at PP - (0.25, 1.25)
CO: box invis same at RF + (0.25, 1.25)
SP: box invis same at RF + (0.25, -1.25)

arc cw rad 1.75 from CI to CO chop
arc cw rad 1.75 from SP to MT
arc cw rad 1.75 from MT to CI
arc cw rad 1.75 from CO to SP

box fill 1.0 same at CI; box fill 0.1 same "Continuous" "Integration" at CI
box fill 1.0 same at MT; box fill 0.1 same "Metaphor" at MT
box fill 1.0 same at CO; box fill 0.1 same "Collective" "Ownership" at CO
box fill 1.0 same at SP; box fill 0.1 same "Sustainable" "Pace" at SP

WT: box invis same "Whole" "Team" at TDD + (0.0, 1.5)
SR: box invis same "Small" "Releases" at SD - (0.0, 1.5)
AT: box invis same "Acceptance" "Tests" at PP - (1.5, 0)
PG: box invis same "Planning" "Game" at RF + (1.5, 0)

arc cw rad 2.5 from AT to WT
arc cw rad 2.5 from SR to AT
arc cw rad 2.5 from WT to PG
arc cw rad 2.5 from PG to SR

box fill 1.0 same at WT; box fill 0.15 same "Whole" "Team" at WT
box fill 1.0 same at SR; box fill 0.15 same "Small" "Releases" at SR
box fill 1.0 same at AT; box fill 0.15 same "Acceptance" "Tests" at AT
box fill 1.0 same at PG; box fill 0.15 same "Sustainable" "Pace" at PG

.PE

Mit Schattierungen kann man die unterschiedlichen Ebenen auch noch schön hervorheben.

[Meillo]

Ist das Verhalten gleich wenn die Box nicht `invis' ist?


Edit: Vielleicht geht das auch nur bei Kreisen. Nimm vielleicht mal ein `circle invis' statt einer `box invis'.

Da helfen weder sichtbare Boxen, noch Circles.

Hmm, sieht so aus, wie wenn es nur mit Lines und Circles gehen wuerde, nicht aber mit Arcs. Wenn man sich ueberlegt wie das implementiert sein koennte, macht das auch Sinn, denn Arcs um einen bestimmten Abstand zu einem Punkt oder gar am Schnittpunkt mit einer Box zu kuerzen ist sehr viel aufwaendiger zu berechnen als das was bei Lines und Circles noetig ist, siehe im Manual:

Notice that the chop attribute moves arrowheads rather than stepping on them. By default, the chop modi-
fier shortens both ends of the line by circlerad. By suffixing it with a number you can change the amount
of chopping.

If you say line ... chop r1 chop r2 with r1 and r2 both numbers, you can vary the amount of chop-
ping at both ends. You can use this in combination with trigonometric functions to write code that will deal
with more complex intersections.

Aber noch etwas anderes: Nun, wo du uebermalst, koenntest du doch statt den vier Arcs einen Circle nehmen. Das wuerde die Sache einfacher machen. Und dann: `box with .c at last circle .n'.

[paedubucher]

Aber noch etwas anderes: Nun, wo du uebermalst, koenntest du doch statt den vier Arcs einen Circle nehmen. Das wuerde die Sache einfacher machen. Und dann: `box with .c at last circle .n'.

Ausgezeichent, da ich jeweils vier Boxen habe, geht das mit der Anordung auf einem Kreis ja ausgezeichnet!

Ich habe es jetzt als Ellipse gemacht, da ich ja entsprechend der Textrichtung in der Horizontalen mehr Platz brauche als in der Vertikalen.



Hier der Code, der nun wesentlich übersichtlicher und klarer ist:

Code: Alles auswählen

.PS

C0: ellipse wid 2 ht 1.1
box fill 0.05 rad 0.25 wid 1 ht 0.5 same "Test-Driven" "Development" at C0.n
box fill 0.05 same "Refactoring" at C0.e
box fill 0.05 same "Simple" "Design" at C0.s
box fill 0.05 same "Pair" "Programming" at C0.w

C1: ellipse wid 3.5 ht 2.2 at C0
box fill 0.1 same "Collective" "Ownership" at C1.ne
box fill 0.1 same "Sustainable" "Pace" at C1.se
box fill 0.1 same "Metaphor" at C1.sw
box fill 0.1 same "Continuous" "Integration" at C1.nw

C2: ellipse wid 4.75 ht 3 at C0
box fill 0.15 same "Whole" "Team" at C2.n
box fill 0.15 same "Planning" "Game" at C2.e
box fill 0.15 same "Small" "Releases" at C2.s
box fill 0.15 same "Acceptance" "Tests" at C2.w

.PE

[eggy]

Ich finde die Grautöne eher ablenkend, zumindest auf meinem Monitor sind die "Farben" schlecht unterscheidbar und kosten mich ziemlich viel Mühe in Gruppen einzuordnen ... und selbsterklärend ist der Rest dann auch noch nicht. Was sollen die Kreise darstellen?

(ist nicht bös gemeint, sondern konstruktive Kritik im Sinne von "für bessere Lehre")

[paedubucher]

Ich finde die Grautöne eher ablenkend, zumindest auf meinem Monitor sind die "Farben" schlecht unterscheidbar und kosten mich ziemlich viel Mühe in Gruppen einzuordnen ... und selbsterklärend ist der Rest dann auch noch nicht. Was sollen die Kreise darstellen?

(ist nicht bös gemeint, sondern konstruktive Kritik im Sinne von "für bessere Lehre")

Die Grafik ist nicht von mir, ich habe sie nur nachgebaut. Es handelt sich um den "Circle of Life" der agilen Softwareentwicklung. Es gibt drei Ringe von Praktiken, von innen nach aussen: technical, team-facing und business-facing. Die Farben sollen einerseits bei der optischen Gruppierung helfen und die Wichtigkeit der inneren Praktiken hervorheben.

Den Kontext findest du hier auf Seite 6.

[eggy]

Für mich machen da "Ringe" (bzw inkludierende Kreise, wonach das Bild eher aussieht) inhaltlich überhaupt keinen Sinn. Wird wohl daran liegen, dass ich das Buch, auf das sich das bezieht, vermutlich nicht gelesen hab.

Ich bin aber grundsätzlich der Meinung, dass wenn man Lernenden mit Bildern kommt, dann sollten die bestehende Fragen aus der Welt räumen und nicht für neue Verwirrung sorgen ... und nur weil das Bild in nem Buch abgebildet ist, muss es ja nicht gut sein. Bei Deinem anderen Beispiel letztens fand ich die Aussage gut nachvollziehbar, hier fehlt mir irgendwie der "tiefere Sinn" der Darstellung.

[paedubucher]

Für mich machen da "Ringe" (bzw inkludierende Kreise, wonach das Bild eher aussieht) inhaltlich überhaupt keinen Sinn. Wird wohl daran liegen, dass ich das Buch, auf das sich das bezieht, vermutlich nicht gelesen hab.

Ich bin aber grundsätzlich der Meinung, dass wenn man Lernenden mit Bildern kommt, dann sollten die bestehende Fragen aus der Welt räumen und nicht für neue Verwirrung sorgen ... und nur weil das Bild in nem Buch abgebildet ist, muss es ja nicht gut sein. Bei Deinem anderen Beispiel letztens fand ich die Aussage gut nachvollziehbar, hier fehlt mir irgendwie der "tiefere Sinn" der Darstellung.

Ich schreibe eben eine Buchzusammenfassung, und gebe darum die Grafik in der Struktur wieder, wie sie im Buch auch vorkommt. Da oft die Rede von "innermost circle" usw. ist, ist es doch sinnvoll, diese Grafik mit drin zu haben, auch wenn sie nicht sehr viel aussagt.

Bei obigem Link findet sich auf Seite 5 noch eine Grafik. Die war im Buch nie abgebildet, aber ich habe sie zusammenfassend aus dem Geschriebenen erstellt. Ich hoffe, diese ist aussagekräftig.

[eggy]

Bei der "Iron Cross"-Grafik, frage ich mich: warum sind gegenüberliegende Seiten stärker gegenüberstehend als benachbarte?
Das ist jedenfalls der visuelle Eindruck, den die gestrichelten Linien bei mir hinterlassen.

Bei gleicher Gewichtung hätte ich das Bild vermutlich mit gleichartigen Strichen verbunden.
Ohne den Text zu kennen, würde ich mal ausprobieren, ob "Fast" einen weniger präsenten Eindruck macht, wenn man die Anordnung der Kästchen ändert, das Kreuz um 45 Grad dreht, also weniger ein wie ein "+", mehr wie ein "X" darstellt, und somit das eine Kästchen nicht mehr zentral dominant über den Kreuzmittelpunkt stehen hat.
Nur so eine Idee, kann auch Murks sein, also eh Du da viel Arbeit reinsteckst, lieber mal auf Papier ausprobieren.

Kleine Frage zu dem Abschnitt bei Wikipedia https://de.wikipedia.org/wiki/Extreme_P ... _Praktiken :
Du behandelst nur das Originalmodell? Dann macht evtl. eine verweisende Fußnote Sinn? Sonst vielleicht ne Abbildung der Gegenüberstellung der unterschiedlichen Ansätze?

[paedubucher]

Bei der "Iron Cross"-Grafik, frage ich mich: warum sind gegenüberliegende Seiten stärker gegenüberstehend als benachbarte?
Das ist jedenfalls der visuelle Eindruck, den die gestrichelten Linien bei mir hinterlassen.

Meiner Meinung nach sind sich die Kästchen auf den Hauptachsen stärker entgegengesetzt als die jeweils anderen Paare.

Bei gleicher Gewichtung hätte ich das Bild vermutlich mit gleichartigen Strichen verbunden.

Die Raute soll einen Raum symbolisieren, in dem man sich bewegen kann.

Ohne den Text zu kennen, würde ich mal ausprobieren, ob "Fast" einen weniger präsenten Eindruck macht, wenn man die Anordnung der Kästchen ändert, das Kreuz um 45 Grad dreht, also weniger ein wie ein "+", mehr wie ein "X" darstellt, und somit das eine Kästchen nicht mehr zentral dominant über den Kreuzmittelpunkt stehen hat.
Nur so eine Idee, kann auch Murks sein, also eh Du da viel Arbeit reinsteckst, lieber mal auf Papier ausprobieren.

Die Sache heisst eben "Iron Cross", da dachte ich eher an ein + als an ein x .

Kleine Frage zu dem Abschnitt bei Wikipedia https://de.wikipedia.org/wiki/Extreme_P ... _Praktiken :
Du behandelst nur das Originalmodell? Dann macht evtl. eine verweisende Fußnote Sinn? Sonst vielleicht ne Abbildung der Gegenüberstellung der unterschiedlichen Ansätze?

Ich behandle das, was im Buch "Clean Agile" drin steht. Fussnoten spare ich mir, da diese dem Originaltext entnommen werden können.

[Meillo]

(Edit: paedubucher war schneller ...)

Bei der "Iron Cross"-Grafik, frage ich mich: warum sind gegenüberliegende Seiten stärker gegenüberstehend als benachbarte?
Das ist jedenfalls der visuelle Eindruck, den die gestrichelten Linien bei mir hinterlassen.

Bei gleicher Gewichtung hätte ich das Bild vermutlich mit gleichartigen Strichen verbunden.
Ohne den Text zu kennen, würde ich mal ausprobieren, ob "Fast" einen weniger präsenten Eindruck macht, wenn man die Anordnung der Kästchen ändert, das Kreuz um 45 Grad dreht, also weniger ein wie ein "+", mehr wie ein "X" darstellt, und somit das eine Kästchen nicht mehr zentral dominant über den Kreuzmittelpunkt stehen hat.
Nur so eine Idee, kann auch Murks sein, also eh Du da viel Arbeit reinsteckst, lieber mal auf Papier ausprobieren.

Kleine Frage zu dem Abschnitt bei Wikipedia https://de.wikipedia.org/wiki/Extreme_P ... _Praktiken :
Du behandelst nur das Originalmodell? Dann macht evtl. eine verweisende Fußnote Sinn? Sonst vielleicht ne Abbildung der Gegenüberstellung der unterschiedlichen Ansätze?

@eggy: Ich bin mir nicht sicher, ob du realisiert hast, dass paedubucher hier eine Zusammenfassung eines bestimmten Buches macht und darum die dort verwendeten Grafiken und Modelle aufgreift. Das ist, soweit ich das verstanden habe, eine andere Schiene als die derzeit ebenfalls von ihm angestellten Ueberlegungen zur Lehre.

Persoenlich kann ich mit dem Bild des ``Iron Cross'' auch wenig anfangen. Fuer mich ist das nur eine kultfoerndernde Benennung, die in diesem Kontext (Clean Code und Co.) typisch und IMO gewollt ist. Weit besser gefaellt mir die unterliegende Business-Projekt-Modell, das aus einem Dreieck mit den Zielen Kosten, Zeit, Qualitaet besteht. Dieses spannt einen Raum auf in dem man seine Prioritaeten darlegt. So sollte es auch hier eine Raute sein und kein Kreuz. Ich verstehe, dass man die Zielerfuellung in diese Abwaegung einbringen will, jedoch funktioniert damit das zweidimensionale Modell nicht mehr. Es muesste nun ein Tetraeder sein, um die Idee des Modells angemessen darzulegen ... nur geht der halt als 2D-Abbildung schlecht. Ohne wirklich nachgelesen zu haben wie hier das mit der Zielerfuellung gemeint ist, kommt es mir nicht ganz passend vor, diese in das Dreieck der Projektprioritaeten aufzunehmen. Nur weil sie wichtig ist und priorisiert werden muss, ist sie IMO nicht von gleicher Art wie die anderen drei. Entweder man sieht sie als Teil der Qualitaet an, oder legt sie als grundlegendere Ebene unter das Dreieck (plastisch gesprochen vielleicht als Hoehe des Dreiecksprismas). Aber wie ich geschrieben habe: In meiner Wahrnehmung ist dies in diesem Clean-Code-Denken und -Umfeld von geringerer Bedeutung als kultfoerndernde Bilder und Begriffe. Darum das ``Iron Cross of Project Management'' -- was fuer ein Name!

[paedubucher]

Persoenlich kann ich mit dem Bild des ``Iron Cross'' auch wenig anfangen. Fuer mich ist das nur eine kultfoerndernde Benennung, die in diesem Kontext (Clean Code und Co.) typisch und IMO gewollt ist. Weit besser gefaellt mir die unterliegende Business-Projekt-Modell, das aus einem Dreieck mit den Zielen Kosten, Zeit, Qualitaet besteht. Dieses spannt einen Raum auf in dem man seine Prioritaeten darlegt. So sollte es auch hier eine Raute sein und kein Kreuz. Ich verstehe, dass man die Zielerfuellung in diese Abwaegung einbringen will, jedoch funktioniert damit das zweidimensionale Modell nicht mehr. Es muesste nun ein Tetraeder sein, um die Idee des Modells angemessen darzulegen ... nur geht der halt als 2D-Abbildung schlecht. Ohne wirklich nachgelesen zu haben wie hier das mit der Zielerfuellung gemeint ist, kommt es mir nicht ganz passend vor, diese in das Dreieck der Projektprioritaeten aufzunehmen. Nur weil sie wichtig ist und priorisiert werden muss, ist sie IMO nicht von gleicher Art wie die anderen drei. Entweder man sieht sie als Teil der Qualitaet an, oder legt sie als grundlegendere Ebene unter das Dreieck (plastisch gesprochen vielleicht als Hoehe des Dreiecksprismas). Aber wie ich geschrieben habe: In meiner Wahrnehmung ist dies in diesem Clean-Code-Denken und -Umfeld von geringerer Bedeutung als kultfoerndernde Bilder und Begriffe. Darum das ``Iron Cross of Project Management'' -- was fuer ein Name!

Ich kannte bisher auch nur das Dreieck, das ich recht sinnvoll finde, gerade zum Argumentieren: "Good, cheap, fast: pick two!"

In diesem Buch wird nun das "Iron Cross" verwendet. Die Bezeichnung ist auf Englisch nichtssagend und weckt in Deutschland böse Assoziationen. Klingt wohl so, als ob jemandem das Eiserne Kreuz für hervorragendes Projektmanagement verliehen worden ist. (Ich möchte die Zusammenfassung anschliessend auf Deutsch übersetzen, was sicherlich sehr schwierig wird mit solchen Begriffen.)

Das mit dem zweidimensionalen "Raum" funktioniert dann wirklich nicht mehr. Darum habe ich die beiden Achsen eingefügt. Gut oder billig, schnell fertig oder alles fertig; das sind schon die stärksten Gegensätze. Natürlich gibt es auch den Gegensatz zwischen schnell fertig und gut. Oben hätte man eigentlich das originale Dreieck. Das "Done" unten ist dann ein Fremdkörper und zerstört das ganze Konzept. Ich wollte aber noch die Variablen (Quality, Schedule, Staff, Scope) mitaufnehmen, die durch das Management verändert werden können um das jeweilige Ziel zu steuern. (Natürlich steuert man dadurch auch immer die anderen Ziele mit.)

Hier bin ich etwas im Clinch, da die Grafik so nirgends im Buch auftaucht, jedoch in dieser Form beschrieben wird. Andererseits ist es besser dieses Bild als Grafik zu zeichnen, als zu beschreiben. Die Widersprüche des Modells werden dadurch umso schneller sichtbar. In der Grafik wird also auch die Unzulänglichkeit des beschriebenen Modells hervorgehoben. Nicht unbedingt gewollt, aber als Konsequenz.

Überhaupt habe ich mit den Büchern von Robert C. Martin (ich nenne ihn "Boomer Bob", nicht "Uncle Bob") immer etwas Mühe. Einen grossen Teil der Aussagen kann ich unterschreiben, aber dann kommt irgendwo wieder ein Widerspruch oder eine herablassender Satz, wodurch das ganze einen faden Beigeschmack bekommt.

Warum "Boomer Bob"? Wegen Aussagen wie: "Wenn ich in meinem langjährigen Hobbyprojekt [ein Wiki für Akzeptanztests] eine Testabdeckung von über 95% erreiche, dann kannst du das auch an deinem Arbeitsplatz erreichen." Klingt für mich wie: "Ich habe damals in den 60er-Jahren studiert und gleichzeitig für ein Haus gespart. Dafür brauchte ich bloss freitagabends in einer Bar Bier zu zapfen. Das solltest du doch auch schaffen!"

Nachtrag: Ich fasse das Buch zusammen, weil ich demnächst ein paar Unterrichtsblöcke zum Thema agile Methoden halten werde. Das Buch gibt einen guten Überblick, hat aber auch seine Schwächen. Ich werde also den Schülern sicherlich noch das sinnvollere Dreieck zeigen und erläutern. Die Zusammenfassung ist dann das Rohmaterial für weitere Unterlagen, die Auszüge davon behandeln.

[eggy]

@Meillo: Ja, das mit dem Buch hab ich mitbekommen. Deswegen ja auch meine Nachfrage, ob er auch die "Errata" behandelt.

Und auch wenn man ein Buch zusammenfasst, kann man ja trotzdem versuchen, es besser zu machen (zumal es in bei den Originalgrafiken vielleicht ja auch Probleme in Bezug aufs Urherberrecht geben könnte).
Ich hab versucht auszublenden, was ich zu der Thematik im Studium gehört hab und versucht "mit frischen Augen" auf die Grafik zu schauen ... und da ist, wie bei vielen dieser Schlagwortmodellbilder, eben nicht eindeutig klar, was mit dem Bild gesagt werden soll.
Jedenfalls mir nicht, kann ja gut sein, dass andere das anders sehen. Der Text hingegen wirkt auf mich gut strukturiert, beim Überfliegen hatte ich den Eindruck, "ok, da gibts Kategorien und die gleichzeitige Erfüllbarkeit ist nicht gegeben" ... diesen klaren Erkenntnis-Eindruck hab ich bei dem Bild eben nicht. Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

Ich hab mich beim Lesen von anderen Papern/Büchern halt schon öfter geärgert, wenn ich minutenlang auf eine Abbildung gestarrt hab, um den verborgenen Sinn darin zu finden und dann stellt sich raus, die Grafiken sind absolut überflüssig und vermutlich nur drin, damit ne gewisse Menge Seiten erreicht wird oder noch schlimmer, nur damit der umgebene Text "wissenschaftlich" aussieht.

@paedubucher: Meine Probleme mit dem "ganzen Modell" fangen aber schon viel früher an, nämlich bei der Annahme, dass man die Aufgaben überhaupt immer in gleichwertige Tasks zerlegen könnte.
Folglich passt die, von Dir in 3.1 zugrunde gelegte, Mathematik so nämlich nicht, Stichwort: "bedingte Wahrscheinlichkeiten". Die Prozente der simplen Tasks gleichen sich nämlich nicht über einen Zeitraum gegenseitig aus. In der Realität multiplizieren sie sich: mit jedem neuem kleinem Task wird es unwahrscheinlicher, dass nen Projekt überhaupt fertig wird.
Grundsätzlich bleibt's bei der Erkenntnis aus Frederick Brooks "the mythical man month": Eine Frau braucht neun Monate für ein Baby; neun Frauen dann also einen Monat - oops.

[paedubucher]

@paedubucher: Meine Probleme mit dem "ganzen Modell" fangen aber schon viel früher an, nämlich bei der Annahme, dass man die Aufgaben überhaupt immer in gleichwertige Tasks zerlegen könnte.
Folglich passt die, von Dir in 3.1 zugrunde gelegte, Mathematik so nämlich nicht, Stichwort: "bedingte Wahrscheinlichkeiten". Die Prozente der simplen Tasks gleichen sich nämlich nicht über einen Zeitraum gegenseitig aus. In der Realität multiplizieren sie sich: mit jedem neuem kleinem Task wird es unwahrscheinlicher, dass nen Projekt überhaupt fertig wird.
Grundsätzlich bleibt's bei der Erkenntnis aus Frederick Brooks "the mythical man month": Eine Frau braucht neun Monate für ein Baby; neun Frauen dann also einen Monat - oops.

Vielen herzlichen Dank für diese Einschätzung. Ich bin sehr froh darüber, dass ich nicht der einzige bin, der von dieser Methodik wenig hält. Man kann nicht schätzen, schätzt dann eben ungenau, in der Hoffnung, dass die Wahrheit im Unschärfebereich liegt. Der ganze Text ist auch dahingehend widersprüchlich, dass man später einfach mal anfängt zu entwickeln, und dann erst auf eine seriöse Einschätzung von Aufwand kommt. Dieses ganze Schätzen vorab ist deshalb völlig sinnlos. Mir scheint, dass hier den Leuten etwas an die Hand gegeben wird, die in ihrem Beruf dann doch zu einer Schätzung genötigt werden.

Dass sich die Unschärfe mit der Zeit augleicht, ist eine völlige Schönwetterannahme. Bei solchen Vorgängen gibt es eine Asymmetrie: Die Wahrscheinlichkeit an einer Aufgabe doppelt so lange zu haben ist wesentlich grösser, als nur halb so lange daran zu sitzen. (So ähnlich wie bei Interkontinentalflügen, wo man im besten Fall eine halbe Stunde früher, im schlechtesten Fall erst viele Stunden später da ist.)

Ich schätze diese Kritik sehr, gerade weil Boomer Bob sonst immer nur in den Himmel hoch gepriesen wird. Meine Zusammenfassung muss aber im Endeffekt das wiedergeben, was im Buch steht. Aber ich muss es nicht so an meine Schüler weitergeben.

[Meillo]

Das mit dem zweidimensionalen "Raum" funktioniert dann wirklich nicht mehr. Darum habe ich die beiden Achsen eingefügt. Gut oder billig, schnell fertig oder alles fertig; das sind schon die stärksten Gegensätze.

Diese ``staerksten Gegensaetze'' will ich so nicht akzeptieren. Die Aussage des Dreiecks ist IMO gerade, dass es drei in jeweils gleicher Weise von den anderen zwei abhaengende Faktoren gibt. Du bzw. das Iron Cross sagt nun, dass dem nicht so waere. Das ueberzeugt mich nicht und reduziert damit IMO gerade die wertvollste Aussage des Dreiecks.

Aus meiner Sicht ueberschneidet sich der Faktor Scope am staerksten mit dem Faktor Qualitaet, hat aber wenig mit Kosten oder Zeit zu tun. Genau genommen ist ja gerade dieser ganze agile Ansatz der Versuch das Scope-Problem in den Griff zu bekommen, waehrend man bei den anderen drei Faktoren weiterhin frei waehlen kann. Am Scope zu schrauben waere wie mehr oder weniger agil zu arbeiten.

Ueberhaupt finde ich diese Scope-Faktor als freie Entscheidungsachse seltsam. Fuer mich macht es Sinn, zu sagen, dass ich wenig Geld ausgeben will, oder in Kauf zu nehmen, dass es teuer wird. Fuer mich macht es auch Sinn, zu sagen, dass es schnell fertig sein soll, oder in Kauf zu nehmen, dass es laenger dauert. Fuer mich macht es auch Sinn, zu sagen, dass die Programmqualitaet hoch sein soll, oder in Kauf zu nehmen, dass manches nicht so gut funktioniert oder Folgekosten hoeher sind. Fuer mich macht es aber wenig Sinn, zu sagen, dass das Programm mein Problem loesen soll, oder in Kauf zu nehmen, dass es unpassend ist.

Gibt es im Buch denn eine Erklaerung, warum der Scope hinzugefuegt worden ist und warum er gleichwertig zu den anderen drei Faktoren angesehen wird?

[Meillo]

Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

So denke ich auch ... Aber: Ich habe gelernt, dass fuer manche das Optische/Grafische enorm wichtig ist, um Informationen aufzunehmen. Es ist fuer diesen Zweck nicht so wichtig wie genau die Grafik aussieht oder wie korrekt sie ist, sie koennen sich die Dinge dann trotzdem besser merken oder auch ueberhaupt nur aufmerksam bleiben. Mir sind andere Dinge wichtiger aber das trifft nicht auf jeden gleichermassen zu. Darum wuerde ich sagen, dass die Abbildung *nicht* ueberfluessig ist (auch wenn sie es rein inhaltlich womoeglich doch ist). Besser waere es allerdings eine wirklich passende und wertschoepfende Grafik einzufuegen ... das ist halt eine Qualitaetsfrage ... und da liegen im Clean-Code-Umfeld IMO die Prioritaeten halt leider eher bei Zeit und Geld.

[paedubucher]

Das mit dem zweidimensionalen "Raum" funktioniert dann wirklich nicht mehr. Darum habe ich die beiden Achsen eingefügt. Gut oder billig, schnell fertig oder alles fertig; das sind schon die stärksten Gegensätze.

Diese ``staerksten Gegensaetze'' will ich so nicht akzeptieren. Die Aussage des Dreiecks ist IMO gerade, dass es drei in jeweils gleicher Weise von den anderen zwei abhaengende Faktoren gibt. Du bzw. das Iron Cross sagt nun, dass dem nicht so waere. Das ueberzeugt mich nicht und reduziert damit IMO gerade die wertvollste Aussage des Dreiecks.

Im Endeffekt reduziert das "Iron Cross" die Darstellung auf die beiden Achsen Qualität (X) und Quantität (Y). Gut oder günstig; viel vornehmen oder fertig werden. Das ist ein Rückschritt gegenüber dem Dreieck, das mit drei Variablen operiert. Aber diesen Rückschritt kommt mit den beiden dargestellten Achse auch zum Ausdruck.

Aus meiner Sicht ueberschneidet sich der Faktor Scope am staerksten mit dem Faktor Qualitaet, hat aber wenig mit Kosten oder Zeit zu tun. Genau genommen ist ja gerade dieser ganze agile Ansatz der Versuch das Scope-Problem in den Griff zu bekommen, waehrend man bei den anderen drei Faktoren weiterhin frei waehlen kann. Am Scope zu schrauben waere wie mehr oder weniger agil zu arbeiten.

Ueberhaupt finde ich diese Scope-Faktor als freie Entscheidungsachse seltsam. Fuer mich macht es Sinn, zu sagen, dass ich wenig Geld ausgeben will, oder in Kauf zu nehmen, dass es teuer wird. Fuer mich macht es auch Sinn, zu sagen, dass es schnell fertig sein soll, oder in Kauf zu nehmen, dass es laenger dauert. Fuer mich macht es auch Sinn, zu sagen, dass die Programmqualitaet hoch sein soll, oder in Kauf zu nehmen, dass manches nicht so gut funktioniert oder Folgekosten hoeher sind. Fuer mich macht es aber wenig Sinn, zu sagen, dass das Programm mein Problem loesen soll, oder in Kauf zu nehmen, dass es unpassend ist.

Fertig werden oder nicht ist ja im Grunde eine Frage des gewählten Scopes. Von daher wirkt diese vertikale Achse eben schon sehr gesucht auf mich. Wie gesagt: wir hatten eigentlich drei Variablen, jetzt wird noch eine vierte eingefügt. Vielleicht war das Dreieck nicht cool genug, und da musste eben etwas "krasseres" her: das eiserne Kreuz!

Gibt es im Buch denn eine Erklaerung, warum der Scope hinzugefuegt worden ist und warum er gleichwertig zu den anderen drei Faktoren angesehen wird?

Das werde ich gelegentlich nachlesen. Ich habe die Stelle gerade nicht mehr so präsent. Tatsächlich wird zunächst im Buch dieses Kreuz eingeführt, später wird es dann um die Steuerungsmassnahmen ergänzt. Ich bin jetzt schon länger an dieser Arbeit dran, schaffe vielleicht eine halbe bis eine Seite pro Tag. Dann verliere ich die Motivation.

Gegen hinten wird das Buch dann nervig. Zuerst meint der Autor etwa, dass Zertifizierungen für "Agile" (alleine der Begriff nervt mich mittlerweile) völliger Schwachsinn seien. OK, diese Meinung ist jetzt nicht so abwegig. Aber im gleichen Kapitel folgt ein Gastbeitrag von einem Autor, der seitenlang verschiedene Zertifizierungen empfiehlt. (Das gleiche dann noch mit Meta-Frameworks wie SAFE und LESS; Martin findet es unnötig, der Gastbeitrag preist es an.) So ein Buch von ca. 180 Seiten sollte schon so etwas wie eine Einheit haben.

Hätte ich doch einfach Weinberg genommen, da wäre etwas zu lernen gewesen. Ist halt leider nicht "agil" bzw. "Agile".

Was auch auf dem vorgegebenen Lehrplan steht: "Clean Code"

Ich glaube, ich erlaube mir da einen derben Witz, irgend etwas mit dem "Klean Kode Klan", der Brian Kernighan dafür lyncht, dass er in for (i = 0; i < n; i++) "wenig aussagekräftige Variablennamen" verwendet (kein Witz, hat mal ein Professor so kritisiert).

Außerdem: der Text wird durch das Bild auch nicht verständlicher - und damit ist das Bild überflüssig. Und das trifft (ohne mich an das Buch erinnern zu können) vermutlich auch auf die Ring-Abbildung zu.

So denke ich auch ... Aber: Ich habe gelernt, dass fuer manche das Optische/Grafische enorm wichtig ist, um Informationen aufzunehmen. Es ist fuer diesen Zweck nicht so wichtig wie genau die Grafik aussieht oder wie korrekt sie ist, sie koennen sich die Dinge dann trotzdem besser merken oder auch ueberhaupt nur aufmerksam bleiben. Mir sind andere Dinge wichtiger aber das trifft nicht auf jeden gleichermassen zu. Darum wuerde ich sagen, dass die Abbildung *nicht* ueberfluessig ist (auch wenn sie es rein inhaltlich womoeglich doch ist). Besser waere es allerdings eine wirklich passende und wertschoepfende Grafik einzufuegen ... das ist halt eine Qualitaetsfrage ... und da liegen im Clean-Code-Umfeld IMO die Prioritaeten halt leider eher bei Zeit und Geld.

Das ist auch der Grund, warum ich überhaupt Grafiken mache. Einerseits möchte ich natürlich pic lernen, was ja wirklich eine interessante Sache ist. Aber andererseits sind eben nicht alle Leute so textorientiert wie ich, sondern eher "visuelle Lerntypen" (gibt es das wirklich?). Dem will ich gerecht werden.

Nachtrag: ich zitiere (Clean Code, p. 15):

The reason that these techniques fail so spectacularly is that the managers who use them do not understand the fundamental physics of software projects. This physics constrains all projects to obey an unassailable trade-off called the Iron Cross of project management. Good, fast, cheap, done: Pick any three you like. You can't have the fourth. You can have a project that is good, fast, and cheap, but it won't get done. You can have a project that is done, cheap, and fast, but it won't be any good.

Hier klingt "done" fast schon wie "existiert in der Realität oder nur in der Fiktion". Weiter:

The reality is that a good project manager understands that these four attributes have coefficients. A good manager drives a project to be good enough, fast enough, cheap enough, and done as much as necessary (Hervorhebung paedubucher) [...]

Hier wird es geradezu lächerlich. Ich hätte es gerne erledigt, aber nur zu 72.5%.

Die ganze Kategorie "Done" ist somit, jedenfalls wie sie hier erklärt wird, kompletter Humbug.



"Look here, I'm full of shit!"

[Meillo]

Danke fuer den Nachtrag. Schon davor ist mir beim Lesen deines Post bewusst geworden, dass ich nicht verstanden habe, was mit ``Scope'' oder ``done'' gemeint ist. Ich dachte, ``Scope'' bedeutet ``Zielrichtung'', aber dann hatte ich langsam eher den Eindruck, es wuerde ``Umfang'' bedeuten. Den Begriff ``done'' verstehe ich noch weniger. Wenn es nicht fertig wird, dann macht es doch ueberhaupt keinen Sinn ... aber nicht fertig zu werden ist ja schon ueber die Zeitachse abgedeckt. Ich werde nur verwirrter.

Dann sagt er -- wie du schreibst --: you can't have all four of them. Und danach empfiehlt er doch von allen vieren ``genug'' zu nehmen. Ich gewinne daraus jedenfalls keine Weisheit. Nun schaue ich mir das ja nur ganz oberflaechlich ueber deine Beitraege hier an. Eigentlich sollte ich mir das Buch selber vornehmen, genau hinschauen und es in Ruhe durchdenken ... aber ehrlich gesagt habe ich schon vier Anlaeufe unternommen ``Clean Code'' zu lesen, aber jedes Mal nach den naechsten fuenfzehn Seiten gebe ich enttaeuscht auf, finde meine Zeit dafuer zu schade. Dann nehme ich mir ein Buch von Kernighan oder Weinberg zur Hand oder lese einen EWD ... und mein Geist weitet sich!


P.S. Vielleicht solltest du mutig sein und den Begriff ``Clean Code'' in deinem Lehrplan sinngemaess verstehen ... und deinen Schuelern zeigen wo man wirklich lernen kann was guter Code ist.

[paedubucher]

Danke fuer den Nachtrag. Schon davor ist mir beim Lesen deines Post bewusst geworden, dass ich nicht verstanden habe, was mit ``Scope'' oder ``done'' gemeint ist. Ich dachte, ``Scope'' bedeutet ``Zielrichtung'', aber dann hatte ich langsam eher den Eindruck, es wuerde ``Umfang'' bedeuten. Den Begriff ``done'' verstehe ich noch weniger. Wenn es nicht fertig wird, dann macht es doch ueberhaupt keinen Sinn ... aber nicht fertig zu werden ist ja schon ueber die Zeitachse abgedeckt. Ich werde nur verwirrter.

Ich habe zunächst darüber mehr oder weniger hinweggelesen. Ich erinnerte mich an das Dreieck, und fragte mich, wozu jetzt die weitere Variable gut sein soll. Aber da ich am zusammenfassen war, habe ich das einfach mal so wiedergegeben. Vielleicht sollte man das so lesen, und nicht etwa kritisch

Dann sagt er -- wie du schreibst --: you can't have all four of them. Und danach empfiehlt er doch von allen vieren ``genug'' zu nehmen. Ich gewinne daraus jedenfalls keine Weisheit. Nun schaue ich mir das ja nur ganz oberflaechlich ueber deine Beitraege hier an. Eigentlich sollte ich mir das Buch selber vornehmen, genau hinschauen und es in Ruhe durchdenken ... aber ehrlich gesagt habe ich schon vier Anlaeufe unternommen ``Clean Code'' zu lesen, aber jedes Mal nach den naechsten fuenfzehn Seiten gebe ich enttaeuscht auf, finde meine Zeit dafuer zu schade. Dann nehme ich mir ein Buch von Kernighan oder Weinberg zur Hand oder lese einen EWD ... und mein Geist weitet sich!

Hier geht es übrigens um "Clean Agile", nicht um "Clean Code". Es gibt noch "Clean Architecture" und "The Clean Coder". Im Herbst kommt dann noch "Clean Craftsmanship". Aber nach zwei Büchern erscheint mir jedes Weitere nur als Remix der vorherigen.
Bei "Clean Code" bin ich übrigens nie durchgekommen. Ist man erstmals von Java weg, sieht man, wie eingeschränkt die Perspektive dort ist.

P.S. Vielleicht solltest du mutig sein und den Begriff ``Clean Code'' in deinem Lehrplan sinngemaess verstehen ... und deinen Schuelern zeigen wo man wirklich lernen kann was guter Code ist.

Kernighan und Dijkstra oben sind gute Stichworte. "The Elements of Programming Style" kann ich sicherlich nicht direkt verwenden, aber was er in einem dazugehörigen Vortrag Jahre später brachte, ist perfektes Anschauungsmaterial!

[eggy]

[url=https://www.youtube.com/watch?v=8SUkrR7ZfTA]

Danke, das Video kannte ich noch nicht

Offtopic, aber auch sehenswert: https://www.youtube.com/watch?v=EY6q5dv_B-o (ab etwa 8:00 min)

[paedubucher]

[url=https://www.youtube.com/watch?v=8SUkrR7ZfTA]

Danke, das Video kannte ich noch nicht

Offtopic, aber auch sehenswert: https://www.youtube.com/watch?v=EY6q5dv_B-o (ab etwa 8:00 min)

Dieses Interview kannte ich schon, es ist aber wirklich grossartig. Es ist so schön zu sehen, wie solche gestandenen Profis völlig auf dem Boden geblieben sind. Das ist genau das Gegenteil dieser "Boomer"-Attitüde, die mich an Robert C. Martin so nervt.

[paedubucher]

Nachtrag zu Clean Code: Ich bin heute auf dieses sehr kritische Review gestossen.