Die Präsentation von Stephan Schmidt behandelt 23 wesentliche Aspekte der Software-Entwicklung in Teams, die auf persönlichen Erfahrungen basieren. Sie umfasst wichtige Themen wie kollektiv besessenen Code, die Notwendigkeit von Tests und kontinuierlicher Integration sowie die Bedeutung von Kommunikation und Teamdynamik. Der Fokus liegt darauf, dass Teams sich an Veränderungen anpassen und Prozesse implementieren sollen, die für sie funktionieren.

1. Stephan Schmidt
Head of Web Sales Development @ 1&1 Internet AG
17.04.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 Trainer.
‣ Bekannt für seine Yogiisms.

4. „Baseball is ninety
percent mental.
The other half is
physical.“
Yogi Berra
4

5. YOGI
BEAR
5

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

8. TEIL 1:
TOOLS
UND
CODE
8

9. #1
Etablieren Sie Collective Code
Ownership.
9

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.
‣ Vermeidet Flaschenhälse in ihrem Team und macht den
Code besser.
‣ Sie profitieren von den Stärken aller Teammitglieder.
10

11. #2
Setzen Sie ein Werkzeug zur
Revisionskontrolle ein.
11

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

14. #3
Standardisieren Sie die
Entwicklungsumgebung Ihres Teams.
14

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

16. #4
Definieren Sie Coding Standards in
Ihrem Team.
16

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 SUN-Standards sind ein guter Ausgangspunkt.
17

18. #5
Stellen Sie sicher, dass Ihre Standards
eingehalten werden.
18

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.
19

20. #6
Führen Sie
Code-Reviews durch.
20

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

22. #7
Sorgen Sie dafür, dass Ihr Build
reproduzierbar ist.
22

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
$ mvn tomcat:run
$ // oder ähnliches
23

24. „We made too many
wrong mistakes.“
Yogi Berra
24

25. #8
Machen Sie nicht den Fehler, keine
Tests zu schreiben.
25

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

27. „It's like déjà vu all
over again.“
Yogi Berra
27

28. #9
Integrieren Sie Ihren Build regelmäßig.
28

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

30. #10
Liefern Sie so oft wie nur möglich
fertige Software aus.
30

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

32. CODE.FLICKR.COM
32

33. THOUGHTWORKS
33

34. #11
Verwenden Sie nicht für alles ein
elektronisches Tool.
34

35. PAPPKARTEN
35

36. MAGNETE
36

37. TEIL 2:
MENSCHEN
UND
PROZESSE

38. #12
Kommunikation entscheidet in den
meisten Projekten über Erfolg und
Niederlage.
38

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

43. #14
Suchen Sie kreative Wege, um
persönliche Kommunikation
herzustellen.
43

44. 44

45. KONSUM WÄCHST MIT
DEM TEAM.
45

46. #15
Gemeinsames Essen stärkt die
Teambildung.
46

47. GEMEINSAME
ERLEBNISSE
‣ 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ß.
‣ Schaffen Sie Rituale.
47

48. #16
Verwenden Sie nicht den erprobtesten
Prozess.
48

49. #16
Verwenden Sie nicht den besten
Prozess.
48

50. #16
Verwenden Sie nicht den neusten
Prozess.
48

51. #16
Verwenden Sie nicht den coolsten
Prozess.
48

52. #16
Verwenden Sie nur den Prozess, der bei
Ihnen funktioniert.
48

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

54. #17
„Es gibt immer mehr als nur einen
Prozess.“
Jutta Eckstein
50

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

59. #19
Machen Sie Planungen und
Aufwandsschätzungen im Team.
55

60. PLANNING POKER
56

61. „Congratulations.
I knew the record
would stand until it
was broken.“
Yogi Berra
57

62. #20
Spielerisch geht alles leichter.
58

63. GAMIFICATION
‣ Nutzen Sie das „Continuous Integration Game“ für
Jenkins.
‣ MS Visual Studio bietet ein Plugin, das den Entwicklern
Badges verleiht.
‣ Vergeben Sie Punkte für gefixte Bugs und eingehaltene
Standards.
‣ Entwickler können verschiedene Level erreichen.
59

64. VERGEBEN SIE
BADGES
60

65. „The future ain‘t what
it used to be.“
Yogi Berra
61

66. #21
Nur Teams, die sich an Veränderungen
anpassen, sind erfolgreich.
62

67. DIE WELT IST IM
WANDEL
‣ Anforderungen werden sich immer ändern.
‣ Technologien und Methodiken auch.
‣ Nehmen Sie Änderungen freudig an.
‣ Agile Methoden stellen Ihnen dafür Werkzeuge zur
Verfügung.
63

68. #22
Hinterfragen Sie regelmäßig den
Status Quo.
64

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.
‣ Die Geschichte „Who moved my cheese?“ von Spencer
Johnson hilft Ihnen dabei.
65

70. „Nobody goes there
anymore.
It‘s too crowded.“
Yogi Berra
66

71. #23
Verhindern Sie eine „Kultur der Angst“
in Ihrem Team.
67

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

75. 71

76. DAS WAR EINE
PRÄSENTATION VON
72

77. STEPHAN
SCHMIDT
‣ Software-Entwickler
‣ Pädagoge
‣ Head of Web Sales
Development bei
1&1 Internet AG

78. „If you ask me
anything I don't know,
I'm not going to
answer.“
Yogi Berra
74

79. VIELEN
DANK.
‣ stephan.schmidt@1und1.de
‣ http://blog.schst.net
‣ @schst