Wie erkläre ich einem klassischen Manager, warum Programmierer effizienter werden, wenn sie mit zwei Leuten an der gleichen Aufgabe sitzen? Warum ein Programmierer in 14 Stunden täglich nicht mehr schafft als in 8, warum ein Team schneller wird, wenn man das Programmiergenie entfernt. Warum man effizienter wird, wenn man Low-Prio-Tasks vor High-Prio-Tasks macht und nur 6 von 8 Stunden planen will.
7. Hier haben wir einen international anerkannten Experten in Nichtwissen.
8. Donald
Rumsfeld
Genau, das ist Donald Rumsfeld, seines Zeichens ehemaliger Verteidigungsminister der USA,
ausserdem Erfinder von Bio- Atom- Chemiewaffen und vermutlich auch Alientechnologie im
Irak, und einer der profiliersten Nichtwisser der Welt. Er war in der Lage, mit Nichtwissen
sogar Kriege zu beginnen.
9. Donald
Rumsfeld
We do know of
certain knowledge
that Osama Bin
Laden is either in
Afghanistan, or in
some other
country, or dead.
Der hat solche Dinge gesagt. Eigentlich sagt er damit: wir haben keine ahnung bis auf die
tatsache, dass er auf diesem Planeten ist. Ausser wenn er tot ist, dann kann es auch sein,
dass er bei den aliens ist.
10. Donald
Rumsfeld
But there are also
unknown
unknowns – there
are things
we do not know
we don't know.
Hier hat er versucht Nichtwissen zu systematisieren, mit den unknown unknows.
Jetzt kann man sagen - das ist ja sein Problem, nicht unseres.
Aber ist das wirklich so?
11. „Wielange
würde ein
kompletterRewrite
mit node.js dauern?“
Das ist so ein Klassiker. Heute fragt jeder „Wie lange würde ein Komplett-Rewrite auf Basis
von Symfony2, Zend Framework 2 oder, für die mutigen, node.js, dauern?“.
12. Selbst wenn alle Features
bekannt sind haben wir
keine präzise Schätzung.
WTF?!Das muss man sich mal auf der Zunge zergehen lassen: wir kennen schon alle Features, wir
wissen wie es aussieht, trotzdem haben wir in Wahrheit keine Ahnung.
13. Wir können noch nicht
mal gut erklären, warum
wir das nicht wissen.
Und es wird noch schlimmer - wir können noch nicht mal erklären, warum wir so dermassen
daneben liegen.
14. Selbst wenn wir es
empirisch wieder und wieder
bewiesen haben.
Und wir können es nicht erklären, obwohl wir die schlechte Qualität unserer Schätzungen
wieder und wieder unter Beweis gestellt haben. Selbst empirischem Wissen wird nicht
geglaubt.
15. ?Pair Programming
Zwei Programmierer
werden effizienter wenn
nur einer arbeitet und
der andere zuguckt
Das gilt genauso für die durchaus positiven Dinge, die Thema dieses Vortrags sind.
Pair Programming: Ich setzte zwei Developer an die gleiche Aufgabe, und am Ende sind sie
effizienter. Und zwar mit dem an dieser Aufgabe Beteiligtem Code und so, nicht etwa durch
Wissenstransfer oder Juniors einlernen.
16. 27 %
more productive
!Eine akademische Case-Study von Jensen aus 2003 hat einen Produktivitätsvorsprung von
127% durch Pair Programming nachgewiesen. Das waren natürlich echte Projekte, und man
kann ihnen vorwerfen, nicht unter Laborbedingungen passiert zu sein.
17. !101%
more productive
Unter Laborbedingungen sieht es sogar noch besser aus: In einem Experiment von 2006, von
Xu und Rajlich, wurde sogar eine Produktivitätssteigerung von 201 Prozent gegenüber
einzelner Programmierung nachgewiesen.
18. ?Overhours
Ein Programmierer leistet
mehr in 8 Stunden
als in 14 Stunden?
Ein ähnliches Beispiel sind Overhours. Wenn jemand 8 Stunden arbeitet, und dann noch mal 6
hinterher, dann sollte das zumindest grob in Richtung des anderthalbfachen an
Arbeitsleistung gehen, oder?
19. !Productivity
6h
> 8h
> 14h
Für Wissensarbeiter liegt der Peak sogar bei 6h - wenn er 6 Stunden am Tag aktiv arbeitet ist
das Maximum erreicht (Quelle: Why Crunch Modes Doesn’t Work: Six Lessons)
Eine einfache Addition gilt nicht.
21. Team Size
?Wenn ich ein Team
deutlich größer
mache wird es nicht
deutlich produktiver?
Es gibt in Brooks Law auch eine Ausprägung davon: Adding people to a late project makes it
later.Diesen Fehler machen wir sogar bei Mayflower noch regelmässig.
22. !100.000 LOC
<5 Personen:
ca 9 Monate
>20 Personen:
ca 9 Monate
Doug Putnam von QSM ist neben der Standish Group der Mensch, der am meisten Statistik
über Softwareprojekte betreibt. Und dort haben sie die Produktivät von grossen und kleinen
Teams bewertet, anhand von 100.000 equivalent source lines of code. Und heraus kam, dass
mittlere Teams mit 5 bis 9 Leuten nur knapp weniger Code schaffen als grosse Teams mit
mehr als 20 Leuten.
Auch hier gilt eine einfache Addition nicht.
23. ?less knowledge
Wenn ich den besten
Senior aus dem Team
entferne wird das Team
effizienter?
Aber die einfache Addition geht nicht nur in den Fällen von Arbeitszeit oder Leuten nicht auf.
Auch bei Knowhow im Team gilt die Regel nicht.
24. !more productive
40%der Velocity
durch den Senior
Gesamtvelocity
um 20%gesteigert
Das ist sogar eine Geschichte die uns selbst passiert ist - ein wirklich, wirklich guter Mann,
Teamplayer, freundlich und cooler Kollege macht den größten Teil der Arbeit in jedem Sprint,
bringt brillante Ideen ein. Doch als er aus dem Team verschwindet steigert sich die
Performance des Gesamtteams.
25. ?many more
Low Prio First
Dumb Developer First
Das sind noch längst nicht alle Brainfucks, die Software bereithält. Wenn man in jeden Sprint
Low-Prio-Tasks mit einbezieht wird die Gesamtperformance besser. Und ein Team ist
effizienter, wenn man die Tasks als erstes dem Kollegen mit der kleinsten Erfahrung assigned
und der erfahrenste Kollegen nur noch die Tasks bekommt, die am Ende übrig bleiben. Wer
Rückfragen dazu hat kann sich bei mir melden.
26. !http://davidfrico.com/agile-book.htm
Oder man wendet sich direkt an den Experten, was empirisches Wissen angeht. David F Rico
hat im Rahmen seiner Forschung einmal alle Studien auf dem Gebiet gesammelt und
zusammengefasst, und stellt netterweise auch auf seiner Website die Daten zur Verfügung.
Das Buch leider nicht.
27. Selbst wenn wir es
empirisch wieder und wieder
bewiesen haben.
Aber, wie bereits oben - das reicht nicht. Es reicht nicht, dass jede Studie, jede akademische
Untersuchung, jede Untersuchung von IBM oder Consulting-Unternehmen beim gleichen
Ergebnis herauskommt.
28. Man kann es
Managern
nicht erklären.
Wir kommen einfach nicht zu den Managern durch. Dieses empirische Wissen hat die gleiche
Qualität wie die „Amerikanische Wissenschaftler haben herausgefunden“-Einspaltenartikel in
der Bildzeitung.
29. Ich weiß das,
ich bin einer von ihnen.
Und ich muss das wissen, denn ich bin selbst einer. Wer kennt mich noch nicht? Ich bin auf
vielen IPCs, deshalb frage ich :-).
31. ?Warum nicht einfach
Stunden?
Warum schätzen wir nicht einfach in Stunden, wie damals vorm Krieg. Warum sagen wir nicht
einfach: das dauert 3 Tage, und dann dauert es eben drei Tage.
32. Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
33. „Mein Debugger funktioniert bei
den Unit-Tests nicht.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
34. „Mein Debugger funktioniert bei
den Unit-Tests nicht.“
„Vagrant startet die virtuelle
Maschine nicht mehr.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
35. „Mein Debugger funktioniert bei
den Unit-Tests nicht.“
„Vagrant startet die virtuelle
Maschine nicht mehr.“
„Der Bug ist erst in der neuen
Library gefixed, und die braucht
andere Updates.“
Weil wir bereits wissen, dass etwas dazwischen kommen wird. Und zwar Pi mal. Typische
Beispiele sind ...
Was haben alle diese Punkte gemeinsam?
36. Ich wusste die Antwort
vorher nicht.
Ich wusste sie vorher nicht. Und nicht nur das.
37. Ich wusste vorher noch nicht,
dass ich eine Antwort brauche.
Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste.
Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
38. Ich wusste vorher noch nicht,
dass ich eine Antwort brauche.
Und noch schlimmer: Ich wusste vorher auch noch nicht, dass ich sie nicht wusste.
Also die Unknown Unknowns, von denen Donald Rumsfeld sprach.
39. Orders of Ignorance
Orders of
Ignorance
Das offizielle Organ der Association for Computing Machinery, die Communications of the
ACM, haben sich mal einen Kopf darüber gemacht, was man so alles nicht wissen kann. und
das ganze Ausformuliert. Genannt haben sie es die Orders of Ignorance.
40. Orders of Ignorance
Ignoranz 0ter Ordnung:
Ich weiss etwas.
Das klingt zwar jetzt schwachsinning, macht aber durchaus Sinn. Wenn ich etwas sicher
weiss, bin ich kein Stück ignorant. Diesbezüglich.
41. Orders of Ignorance
Ignoranz 1ter Ordnung:
Ich weiss etwas
bestimmtes nicht.
Wenn ich etwas nicht weiss, geht das auch ok. Wenn in meiner Anforderung steht
„Backgroundcolor bitte aus dem Styleguide.“, dann weiss ich zwar die Farbe nicht, ich kann
aber nachgucken, nachfragen oder ähnliches.
42. Orders of Ignorance
Ignoranz 2ter Ordnung:
Ich weiss nicht,
was ich nicht weiss.
Hier kommen wir bei Donald Rumsfeld an, oder bei unserem Business- uns fehlt nicht nur
eine Antwort, wir wussten vorher noch nicht mal, dass wir fragen müssen. Klassiker sind
natürlich Bugs, aber auch inkompatible Libraries, Webservices oder sonstige Schnittstellen.
Aber ich weiss was ich machen kann, um es herauszufinden - im agilen meist einfach
machen, die fragen kommen schon von alleine.
43. Orders of Ignorance
Ignoranz 3ter Ordnung:
Ich weiss nicht wie ich
herausfinde, was ich
nicht weiss.
Und was ist, wenn wir es nicht ausprobieren können? Das sind natürlich zum einen schlecht
probierbare Dinge wie die Bugs im Notfallprogramm unseres Kernkraftwerkes unter realen
Bedingungen, aber auch einfache Dinge wie zukünftige Nutzerwünsche vor Launch.
44. Orders of Ignorance
Ignoranz 4ter Ordnung:
Ich weiss nicht, dass es
unterschiedliche Arten von
Nichtwissen gibt.
Das wird die anwesenden Informatiker freuen - es gibt auch Meta-Ignoranz, wenn ich nicht
weiss, dass es unterschiedlichen Arten von Nichtwissen gibt.
45. Orders of Ignorance
Ignoranz 4ter Ordnung:
Es gibt nur 1te Ordnung:
Ich weiss etwas
bestimmtes nicht.
Und genau da liegt eines der Management-Probleme: es gibt nur Nichtwissen erster
Ordnung. Ich muss vorher alle richtigen Fragen stellen, dann weiss ich alles und kann nach
Plan vorgehen.
46. CHAOS REPORT 2011
WASSERFALL
29%
57%
14%
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011
Mit wieviel Nichtwissen wir es zu tun haben habe ich schon am Detailbeispielen gezeigt, aber
das gilt natürlich auch für das Gesamtbild. Wenn wir schon alles wüssten, brauchten wir nur
nach Plan zu arbeiten. Fakt ist aber, dass am Ende das Nichtwissen über den ganzen
Projekterfolg entscheidet.
47. CHAOS REPORT 2011
AGILE
9%
49%
42%
Successful
Challenged
Failed
Quelle: Standish Group Chaos Report 2011
Ich hatte ja schon erwähnt, dass agil besser mit nichtwissen umgeht, und deshalb etwas
besser darsteht. Nichtsdestotrotz kommen wir auch hier nicht über 42% erfolgreiche Projekte.
51. Dave Snowden
Und die hat diesen Menschen beauftragt, das herauszufinden. Er kommt aus Wales und
forscht an der Komplexitätstheorie im Bereich Sensemaking.
52. Study the
actual,
not the
official
management practice
Und IBM hat ihm einen sehr schönen Auftrag gegeben:
die echten Managementmethoden, die praktiziert wurden, und nicht die offiziellen
anzugucken. Und da gab es ein interessantes Ergebnis. Mit einem interessanten Namen.
53. Cynefin
Lebensraum, Platz
Und zwar mit dem Cynefin-Framework. Ich hoffe ich spreche es richtig aus, mein walisisch ist
etwas eingerostet. Cynefin beschreibt meine Umgebung, die Welt, in der ich lebe - und zwar
inklusive Ort, Kultur und Leuten.
54. Komplex Kompliziert
Chaotisch Einfach
Verwirrung
Und so sieht das aus.
Und mit diesen Quadranten kam herr snowden am ende heraus
Er sagt: Manager nehmen ihre Arbeitswelt als komplex, kompliziert, chaotisch oder einfach
wahr. Und je nach Wahrnehmung agieren sie anders.
55. Einfach
Der Zusammenhang zwischen
Ursache und Wirkung ist bekannt,
vorhersagbar und wiederholbar.
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten.
56. Einfach
Beispiele:
Email schreiben
Browser bedienen
Es ist keine Rückfrage notwendig
Im Software Development gibt es kaum Beispiele für solche Tätigkeiten, selbst ein CRUD oder
ein zusätzliches Formular braucht Rückfragen.
58. Kompliziert
Ursache und Wirkung sind über
Zeit und Raum getrennt, aber
nachvollziehbar und
wiederholbar.
Wenn ich im komplizierten Quadranten bin ist es nicht mehr trivial, aber machbar. Es ist
besser, wenn ich eine Ausbildung und/oder Erfahrung mitbringe. Wird auch Knowable
genannt, man kann es also sicher wissen, wenn man will.
59. Beispiele:
CRUD
Layout anpassen
Es kann immer wie geplant umgesetzt
werden.
KompliziertBei uns in der IT gibt es leider nur wenige Beispiele für solche Sachen, vielleicht der 10te
CRUD im gleichen System.
63. Handeln
Erkennen
Reagieren
Chaotisch
Novel Practice
Wie gehe ich vor - ich probiere etwas aus und gucke, ob das klappt. Kennt Ihr Shotgun
Debugging? Ich tweake an diversen Stellen im Code und gucke, ob sich was ändert. Wer hat
das schon mal gemacht?
64. Komplex
Im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Einfach bzw Simple im Original wird auch „Known“ genannt. Bekanntes Gelände, keine
Überraschungen zu erwarten.
66. Probieren
Erkennen
Reagieren
Komplex
... Practice
In einem komplexen System probiere ich etwas aus, erkenne die Wirkung und reagiere
darauf. Aber ich habe einen vorteil gegenüber der chaotischen Welt, und es haben sich
bestimmte Praktiken bewährt. Welche erkläre ich gleiche.
67. Komplexe
Systeme
Wir haben es meistens mit komplexen systemen zu tun. Viel second order ignorance
bedeutet, dass nicht alles im Vorfeld knowable ist. Wasserfall ist ein modell, das in der
komplizierten Welt mit first order ignorance funktionieren würde, aber in einer Welt mit
second order ignorance scheitern muss. Simple ist es manchmal, und das ist auch super so.
chaotisch ist es auch manchmal, und das ist nicht so super so. meistens ist es bei uns
komplex.
68. Komplexe Systeme bedeutet, dass ich verschiedene Komponenten habe, die autark agieren.
Diese Komponenten können selbst simpel sein, oder komplex. Oder Chaotisch. Aber ich kann
aus den Einzelnen Komponenten nicht ableiten, wie sich das Gesamtsystem verhält.
69. Das liegt daran, dass die Elemente interagieren. Es gibt viele Interaktionen zwischen den
Teilen des Systems, und sie reagieren aufeinander. Kleine Änderungen können grossen
Wirkungen haben (Schmetterlingseffekt). Ich kann nicht im Vorhinein wissen, wie alle Teile
sich gemeinsam auf Zeit verhalten werden.
72.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Software
Web Frontend
Auch Software selbst ist ein komplexes System. Gerade in der Entwicklung, wenn noch nicht
klar ist, wie alle Teile genau aussehen könen bzw welche Konsequenzen die Interaktionen
haben.
73. Erst im Nachhinein ist ein
Zusammenhang zwischen
Ursache und Wirkung erkennbar.
Es ist nicht vorhersagbar, aber eine
Wiederholung kann passieren.
Und wenn man sowas vor Augen hat ist auch das Verhalten plausibel: Wenn ich ein Team
wieder so zusammen an ein neues Projekt setzte, kann ein ganz anderes Ergebnis
herauskommen. Wenn ich die gleiche Architektur für eine andere Lösung einsetze kann sie
funktionieren, muss aber nicht. Sogar im gleichen System muss es nicht mehr funktionieren,
weil es sich selbst schon bewegt hat.
74. „Insanity: doing the same
thing over and over again
and expecting different
results.“
Und das ist gemein, was das schlicht unser normaler Wissen ausser Kraft setzt.
In komplexen Systemen erwarten wir unterschiedliche Resultate, wenn wir mehrfach das
gleiche machen.
75. „You can‘t control what
you can‘t measure.“
Tom DeMarco
Auch dieser Ausspruch von Tom DeMarco gilt nicht. Ich kann in einem komplexen System
zwar messen, aber ich kann deshalb noch lange nicht kontrollieren. Für welche Art von
Systemen gilt dieser Satz?
76. ?Aber was kann ich dann machen? Wie kann ich in so einer Branche überhaupt was sinnvolles
tun, wenn ich mich auf nichts verlassen kann?
78. Wenn etwas in 75% der Fälle
geholfen hat, werde ich es auch
weiterhin probieren.
Und wenn eine der probierten Sachen in 80% der Fälle funktioniert, dann wende ich sie in
Zukunft auch an.
79. Pair Programming
Test Driven Development
Sustainable Pace
Collective Code Ownership
Story Points ...
Emergente
PraktikenUnd genau diese agilen Prinzipien sind emergente Praktiken. Dinge von denen man mal
gemerkt hat, dass Software häufig, nicht immer, besser funktioniert wenn man sie macht.
80. Sie funktionieren
nicht immer, aber oft.
Emergente
PraktikenEmergente Praktiken sind Verhaltensmuster des komplexen Systems, nicht der
Einzelelemente. Ich kann sie nicht erzwingen. Sie gelten nicht immer. Aber oft. Es kann sein,
dass sie aufhören, in meinem System zu funktionieren.
Das ist der Grund, warum die agilen Methoden empirisch so schön nachweisbar sind,
wissenschaftlich aber nicht. Weil sie in einem komplexen System passieren.
81. Die Heuristik funktioniert,
nicht das einzelne Element.
Story Points Avg Hours
1 21
2 52
3 64
5 100
8 111
Velocity Hours
8+8=16
111+111=
222
5+3+2+2+2+1+
1=16
100+64+52+52
+52+21+21=
365
Mike cohn hat sich mal die Mühe gemacht mittlere Zeiten für Story Points zu ermitteln.
Wenn ich die durchschnittlichen Zeiten von Story Points nehme und addiere komme ich auf
eine Summe, die aller Statistik nach nicht das gleiche Aussagen kann.
Wenn ich eine normale Anzahl Stories über mehr als 10 Sprints nehme gibt mir die Velocity
trotzde mehr Aufschluß über Team-Performance und Releaseplanung als Alternativen.
82. Komplex Kompliziert
Chaotisch Einfach
Verwirrung
Und jetzt kommen wir zu dem Punkt, wo die meisten Management-Probleme herkommen.
Wenn ich nicht weiss, in welchem Quadranten ich arbeite, dann bin ich in der Mitte - in der
Verwirrung. Und in dem Fall wird auf den Quadranten defaulted, in dem man sich am
sichersten fühlt.
84. Default to Comfort Zone != Komplex
Management
Brainfucks
Und genau da kommen die Management Brainfucks her. Wenn ein Manager sich nicht bewusst
ist, dass er in einer komplexen Welt arbeitet, und deshalb auf seine Komfortzone
zurückgreift.
87. Default to Comfort Zone
Pair Programming
„Wir haben nicht die Ressourcen zum Pair
Programming.“
Emergente
Praktiken
Probieren
Erkennen
Reagieren
Noch mal zur Erinnerung: wenn ich weiss, dass ich in der komplexen Zone bin, versuche ich
kontinuierlich zu probieren, kontinuierlich zu erkennen und kontinuierliche zu reagieren. und
am Ende habe ich ein Set von emergenten Praktiken, die mir häufiger Erfolg gebracht haben
als andere. Aber was heisst das konkret?
88. Komplex
Pair Programming
Ok, wir probieren das einfach mal
aus und beobachten es.
Wenn der Manager weiss, dass er in der komplexen Welt unterwegs ist würde er es probieren
wollen - aber nicht einmal, sondern mehrfach, und jeweils beobachten ob man im nachhinein
einen Zusammenhang zwischen Pair Programming und Funktionalität erkennen kann.
Würde man es offiziell einführen, wenn es funktioniert?
89. Komplex
Wenn es funktioniert wird es nur
nicht abgeschafft.
Das braucht keine Entscheidung.
Nein - emergent heisst ja genau, dass sich die Praktiken durchsetzen, die Funktionieren. Und
sie werden nicht offiziell eingeführt, sondern man wiederholt einfach nur die Probieren-
Schritt.
90. Kompliziert
Pair Programming
Eine Gruppe arbeitet mit Pair-
Programming und eine ohne, und
am Ende gucken wir, wer mehr Zeit
pro Storypoint verbraucht hat.
Wenn der Manager sich in einer komplizierten Welt sieht dann will er es messen. Vielleicht
würde er mir sogar die Empirie glauben. Wenn es nicht funktioniert würde er aber wissen
wollen, warum wir von den empirischen Daten abweichen.
91. Kompliziert
Pair Programming
Ursache und Wirkung sind klar
erkennbar. Ich mache es einfach
wieder so.
Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein
positives Ergebnis verlässlich reproduzieren kann.
92. Einfach
Pair Programming
Wir müssen die Features damit
umgesetzt bekommen, da können
wir nicht die Zeit damit
verschwenden.
Für den Manager in einer einfachen Welt ist es - Überraschung - einfach. Er rechnet kurz die
verfügbaren Stunden pro Feature durch und stellt fest, dass man den Sprint nur zu Ende
bekommt wenn man nicht im Pair arbeitet. Es ist eine Zeitfrage, und Developmentzeit und
Produktivität verhalten sich linear.
93. Einfach
Pair Programming
Produktivität wird unmittelbar
durch Entwicklerstunden
verursacht.
Er glaubt, dass Ursache und Wirkung nachvollziehbar aneinanderhängen und man ein
positives Ergebnis verlässlich reproduzieren kann.
Kann er damit Erfolg haben?
94. !101%
more productive
Und ich erinnere an vorhin - Pair Programming ist empirisch sehr erfolgreich. Trotzdem
möchte man dem nicht glauben, wenn es der eigenen Weltsicht nicht entspricht. Und wird
empirisch nicht sehr erfolgreich sein.
103. Überreden.
Probieren
Erkennen
Reagieren
Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden.
Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf
verlassen. kann er aber nicht.
104. Überreden.
Probieren
Erkennen
Reagieren
Fake!
Oder ich nutze Statistiken wie in diesem Vortrag um meinen Chef zu überreden.
Das ist aber ein Fake, weil er dann unter Umständen immer noch denkt, er könne sich darauf
verlassen. kann er aber nicht.
107. Am Ende des
Coding Dojos
Probieren
Erkennen
Reagieren
Wenn man kein Scrum macht am Ende des Coding Dojos eine Kurzretro, ob es was hilft.
108. Auch alte Praktiken
bewerten und
Alternativen diskutieren.
Probieren
Erkennen
Reagieren
Wichtig dabei ist, dass man nicht nur das neue Benchmarked, sondern auch bei alten
Methoden über Änderungen und Experimente nachdenke.
111. Links:
Cynefin allgemein:
http://cognitive-edge.com/blog/entry/5855/cynefin-papers-a-summary/
Cynefin für Entwickler:
http://lizkeogh.com/2012/03/11/cynefin-for-devs/
Kleine Teams vs grosse Teams
http://spin.atomicobject.com/2012/01/11/small-teams-are-dramatically-more-efficient-
than-large-teams/
Agile Methoden empirisch betrachtet:
http://www.amazon.com/Business-Value-Agile-Software-Methods/dp/1604270314
http://davidfrico.com/agile-book.htm
Five Orders of Ignorance
http://www-plan.cs.colorado.edu/diwan/3308-s10/p17-armour.pdf
The Waterfall Accident
http://pascal.gugenberger.net/thoughts/waterfall-accident.html
Productivity vs Overhours
http://lunar.lostgarden.com/Rules%20of%20Productivity.pptx
113. Zusammenhänge, die
wir herstellen konnten.
Und wenn es noch mehr Argumente braucht: ich kann es zwar nicht garantieren dass es bei
euch funktioniert, aber ich kann erzählen, welchen Zusammenhang wir festgestellt haben.
114.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
TCO: 75% Maintenace
Web Frontend
Am meisten Zeit verbringt man mit der Software nach der initialen Fertigstellung, man geht
von ca 3/4 der Aufwände aus, die nach dem Release passieren. Maintenance gibt es weil es
unknown unknowns gibt. Features die der Kunde erst kennt wenn er die Software sieht und
nachdenkt. Und weil nachträgliche Änderungen langsamer sind als initiale Entwicklung, und
weil lesen von software langsamer ist als schreiben von software. Wichtig ist also das wissen
über die Zusammenhänge und Effekte innerhalb der Software.
115. Collective
Code
Knowledge
Es ist gut, wenn jeder möglichst viele Teile vom System versteht, um ein paar der Effekte
seiner Handlung einschätzen zu können. Dazu brauche ich verteiltes Wissen, dass mir
erheblich mehr Benefit gibt als Spezialisierung.
116.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
PP
Web Frontend
Wenn man Pair Programming macht kann man besser überschauen, welche Änderung in den
Business Objects welche Auswirkungen im Rest des Systems hat, und was daraus folgt. Das
liegt zum einen daran, dass der Navigator sich darum kümmern kann, während der Driver auf
den Code Fokussiert ist.
117.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
TDD
Web Frontend
Bei Test Driven Development macht man das Netz der Abhängigkeiten explizit, indem man
sie als Test oder als MockUp manifestiert. Generell programmiert man mit TDD mit weniger
Seiteneffekten.
118.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Collective Code Ownership
Web Frontend
Ähnlich wirkt auch Collective Code Ownership - weil jeder jeden Code anfasst lernt er immer
mehr über die Effekte im Netz. Und weil er die Seiteneffekte kennt
119.
Workflow Engine
ORM
User Management
Business Objects
E-Commerce-Module
Low Prio First
Web Frontend
Das gleiche gilt für Low-Prio-Tickets, die einen grossen Netzwerkeffekt haben - sie verzinsen
sich durch andere Tickets, und deshalb lohnt es sich, sie vorzuziehen.
120. Team > Indivuum
Scrummaster
Product Owner
Senior Dev
Junior Dev
QA
User Experience
Das ist auch der Grund, warum das Team mehr zählt als das Individuum. Vernetzte Effekte
lassen sich am besten über mehrere Leute klären als individuell. Wenn das Team keine
Verantwortung übernimmt weil der Senior sie aktiv wahrnimmt und kompetent ist, dann ist
die Produktivität schlechter als wenn alle Ihr Wissen über das Netz einbringen. Individuen
sind nicht gut in Komplexität.
121. Probieren und Emergenz erzeugen
Optimieren für Netze -> TEAM
Priorisieren und Verteilen für
Komplexität