Die Präsentation von Stephan Schmidt behandelt 23 wichtige Aspekte der Softwareentwicklung in Teams, einschließlich der Bedeutung von kollektiver Codeverantwortung, Revisonskontrolle, Standardisierung, Testing und kontinuierlicher Integration. Schmidt betont, dass Kommunikation entscheidend für den Erfolg von Projekten ist und empfiehlt kreative Mittel zur Förderung des Teamgeists und der Anpassungsfähigkeit an Veränderungen. Zudem wird auf die Bedeutung von umsetzbaren Prozessen und der Vermeidung einer 'Kultur der Angst' im Team hingewiesen.

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

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.
‣ Macht den Code besser und reduziert den „Truck
Factor“.
‣ 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 Coding-Standards des Frameworks, das Sie
einsetzen 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.
‣ Sie sind Pfadfinder, ihr Code ist der Zeltplatz.
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
$ phing | ant | php build.php
$ // 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
‣ 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

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. #20
Spielerisch geht alles leichter.
57

62. 58

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

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.
‣ Die Geschichte „Who moved my cheese?“ von Spencer
Johnson hilft Ihnen dabei.
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.
‣ Erfinden Sie die Sprache, die PHP aus dem Web
verdrängt.
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. 71

77. 71

78. 71

79. 71

80. 71

81. 71

82. 71

83. 71

84. 71

85. 71

86. 71

87. 71

88. DAS WAR EINE
PRÄSENTATION VON
72

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

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

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