23 Dinge, die Sie über Software Entwicklung in Teams wissen sollten
1. Stephan Schmidt
Head of Web Sales Development @ 1&1 Internet AG
05.06.2012
23
DINGE,
die Sie über Software-Entwicklung in Teams wissen sollten.
1
2. Stephan Schmidt
Head of Web Sales Development @ 1&1 Internet AG
17.04.2012
23 NICHT UNBEDINGT
TOTAL NEUE
DINGE,
die Sie über Software-Entwicklung in Teams wissen sollten.
2
3. DALE
,YOGI‘
BERRA
‣ Spielte von 1946 bis 1964
professionellen Baseball in
der Major League.
‣ Erst Spieler, dann Manager.
‣ Bekannt für seine Yogiisms.
4. „Baseball is ninety
percent mental.
The other half is
physical.“
Yogi Berra
4
6. „In theory there is no
difference between
theory and practice.
In practice there is.“
Yogi Berra
6
7. THEORIE VS PRAXIS
‣ Die Präsentation beruht auf meiner Erfahrung.
‣ Die Regeln funktionierten und funktionieren in meinen
Teams.
‣ Einige funktionieren in allen Teams, andere
abgewandelt oder auch gar nicht.
‣ Versuchen Sie, das heute theoretisch vermittelte
Wissen in Ihrer Praxis anzuwenden.
7
10. COLLECTIVE CODE
OWNERSHIP
‣ Der gesamte Code gehört allen Entwicklern.
‣ Alle Entwickler sind dazu aufgefordert an allen Stellen
Bugs zu fixen, Refactorings durchzuführen oder neue
Ideen einzubringen.
‣ Macht den Code besser und reduziert den „Truck
Factor“.
‣ Sie profitieren von den Stärken aller Teammitglieder.
10
12. REVISIONS-
KONTROLLE
‣ Nur dadurch werden parallel Änderungen an einem
Projekt möglich.
‣ Es ist egal, welches System Sie einsetzen, aber tun
Sie's.
‣ CVS (wenn‘s denn sein muss)
‣ Subversion
‣ GIT oder Mercurial oder anderen hippen Scheiss.
12
13. „You can't compare me
to my father.
Our similarities are
different.“
Dale Berra
13
15. STANDARDISIERUNG
DER IDE
‣ Spart Zeit bei neuen Instanzen.
‣ Idealerweise installiert die EDV-Abteilung nur noch ein
Image für Entwickler.
‣ In vielen Unternehmen schwer einzuführen, da das
Thema religiöse Sprengkraft hat.
‣ Ist den Stress der Diskussion jedoch trotzdem wert.
‣ In unserem Team noch eine Stunde statt zwei Tagen.
15
17. CODING
STANDARDS
‣ Spart Zeit, da sich jeder Entwickler im Code der
anderen Entwickler zurecht findet.
‣ Hier gilt wieder: Es ist egal, welchen Standard Sie
einsetzen, aber tun Sie's.
‣ Die Coding-Standards des Frameworks, das Sie
einsetzen sind ein guter Ausgangspunkt.
17
19. STANDARDS
EINHALTEN
‣ Nur ein angewandter Standard ist ein sinnvoller
Standard.
‣ Sinnvoll: Integration in den Build-Prozess und die IDE.
‣ Umstritten: Integration in SVN Pre-Commit-Hooks oder
Deployment.
‣ Schrittweise einführen.
‣ Sie sind Pfadfinder, ihr Code ist der Zeltplatz.
19
21. CODE REVIEWS
‣ Sind nicht einfach einzuführen, Entwickler sind
sensible Geschöpfe.
‣ Sie schlagen zwei Fliegen mit einer Klappe:
‣ Ihr Code wird besser.
‣ Sie lernen voneinander.
‣ Ihr Team hält besser zusammen.
21
23. DER BUILD IST
REPRODUZIERBAR
‣ Spart Ihnen Zeit (ja, schon wieder).
‣ Spart Ihnen Ärger.
‣ Bei jedem neuen Mitarbeiter müssen diese Schritte
ausreichen:
$ svn co http://example.com/svn/trunk project
$ cd project
$ phing | ant | php build.php
$ // oder ähnliches
23
24. „We made too many
wrong mistakes.“
Yogi Berra
24
26. TESTEN SIE IHREN
CODE
‣ Im Team wird der Code von verschiedenen Entwicklern
erstellt oder modifiziert.
‣ Tests ermöglichen Entwicklern zu prüfen, ob die
Änderung negative Auswirkungen hat.
‣ Tests nehmen dem Team die Angst, Änderungen
durchzuführen.
‣ „Tests“ sind nicht manuelle Tests, also „Coden Sie
Ihren Test und testen Sie Ihren Code“.
26
29. CONTINUOUS
INTEGRATION
‣ Build wird in regelmäßigen Abständen oder nach jedem
Check-In angestoßen.
‣ Dabei wird immer ein vollständiger Build erzeugt und
alle Tests ausgeführt.
‣ Fehler werden dadurch sofort entdeckt und nicht
verschleppt.
‣ Verhindert das Auftreten des „Broken Window“
Phänomens.
29
31. CONTINUOUS
DELIVERY
‣ Stoppen Sie nicht nach dem erfolgreichen Kompilieren
und Durchführen der automatisierten Tests.
‣ Bauen Sie eine Deployment-Pipline auf und Integrieren
Sie auch andere Teams außerhalb der Entwicklung.
‣ Wenn es weh tut, tun Sie es noch öfter.
‣ Bis Sie das „One-Click-Deployment“ erreicht haben.
31
39. KOMMUNIKATION
IST KING
‣ Verstehen die Entwickler, was der Kunde möchte?
‣ Versteht der Kunde, was der Entwickler liefern kann?
‣ Verstehen die Entwickler gegenseitig wirklich, wie die
Schnittstellen aussehen?
‣ Verstehen die Entwickler, was die Qualitätssicherung
braucht?
‣ Verstehen Sie, was ich damit sagen will?
39
40. „It was hard to have a
conversation with
anyone; there were
so many people
talking.“
Yogi Berra
40
41. #13
Sorgen Sie dafür, dass genug
Möglichkeiten zur Kommunikation
geschaffen werden.
41
42. KOMMUNIKATIONS-
MITTEL
‣ Treffen von Angesicht zu Angesicht.
‣ Treffen von Angesicht zu Angesicht.
‣ Treffen von Angesicht zu Angesicht.
‣ Videokonferenzen & Telefonkonferenzen.
‣ E-Mails & Instant Messenger.
‣ Projekt-Blogs, Microblogging & Twitter.
42
47. GEMEINSAME
ERLEBNISSE
‣ Schaffen Sie Rituale.
‣ Gemeinsame private Erlebnisse stärken das Teamgefühl
und fördern die Zusammenarbeit.
‣ Das gilt nicht nur für gemeinsame Essen, jedoch ist der
Effekt dabei besonders groß.
47
53. PROZESSMODELLE
‣ Wasserfall-Modell
‣ Hat in meinen Projekten noch nie funktioniert.
‣ Wir bauen Software, keine Häuser.
‣ Agile Prozesse
‣ Versprechen deutlich höhere Erfolgschancen.
‣ Bitte nicht sklavisch einhalten.
49
55. DREI PROZESSE
EINES PROJEKTS
‣ Der offizielle Prozess, entspricht so gut wie nie der
Realität.
‣ Der wahrgenommene Prozess, ist meist Kombination
aus Wunschdenken und Fehlinterpretation.
‣ Der tatsächliche Prozess.
Machen Sie den Prozess, der dafür
sorgt, dass Sie zu Lösungen kommen
explizit.
51
56. „If you don't know
where you're going,
you'll wind up
somewhere else.“
Yogi Berra
52
57. #18
Sitzen Sie nicht dem Irrtum auf, dass
„agil“ mit „ungeplant“ gleichzusetzen
ist.
53
58. AGILE
PROJEKTPLANUNG
‣ „Planning is guessing.“ ist keine Ausrede, um nicht
planen zu müssen.
‣ Planen Sie, aber implementieren Sie mehr, als Sie
planen.
‣ Passen Sie Ihre Planung an, wenn sich
Rahmenbedingungen der ursprünglichen Planung
ändern.
54
63. GAMIFICATION
‣ Nutzen Sie das „Continuous Integration Game“ für
Jenkins.
‣ Vergeben Sie Punkte für gefixte Bugs und eingehaltene
Standards.
‣ MS Visual Studio bietet ein Plugin, das den Entwicklern
Badges verleiht.
59
67. DIE WELT IST IM
WANDEL
‣ Anforderungen werden sich immer ändern.
‣ Technologien und Methodiken auch.
‣ Nehmen Sie Änderungen freudig an.
‣ Die Geschichte „Who moved my cheese?“ von Spencer
Johnson hilft Ihnen dabei.
63
69. WANDEL
HERBEIFÜHREN
‣ Wenn sich sowieso alles ändert, dann sollten Sie die
Änderungen möglichst früh feststellen.
‣ Oder besser noch: Stoßen Sie die Änderungen an.
‣ Erfinden Sie die Sprache, die PHP aus dem Web
verdrängt.
65
72. „Was wären wir sündigen Kreaturen
dann ohne die Angst, diese
vielleicht wohltätigste und
gnädigste Gabe Gottes?“
Umberto Eco, "Der Name der Rose"
68
73. SIE LEBEN IN EINER KULTUR
DER ANGST, WENN...
‣ …es gefährlich ist, bestimmte Dinge auszusprechen.
‣ …Zielvorgaben so aggressiv sind, dass diese unmöglich
erreicht werden können.
‣ …Macht über gesunden Menschen-verstand
triumphieren darf.
‣ …die Leute, die gehen müssen, sind im Durchschnitt
kompetenter als die, die bleiben.
Aus „Spielräume“ von Tom DeMarco 69
74. „I never said most of
the things I said.“
Yogi Berra
70