Das Dokument bietet 23 wichtige Aspekte der Software-Entwicklung in Teams, die auf den Erfahrungen des Autors basieren. Es betont die Bedeutung von Tools, Prozessen, Kommunikation und Teamdynamik, um effiziente und erfolgreiche Software-Entwicklungsprojekte zu gewährleisten. Der Autor fordert dazu auf, theoretisches Wissen in praktischen Kontexten anzuwenden und dabei eine kultur der Offenheit und Kreativität im Team zu fördern.

1. ( 23 Dinge,
die Sie über Software-Entwicklung in
Teams wissen sollten.
)

2. ( Stephan Schmidt
⊛ Zwei Herzen in einer Brust
)
⊛ Software-Entwickler
⊛ Pädagoge
⊛ Head of Web Sales Development bei der
1&1 Internet AG in Karlsruhe
⊛ Autor und Redner
⊛ Erst Entwickler, dann Manager

3. ( Yogi Berra
⊛ Bürgerlicher Name „Lawrence Peter Berra“.
)
⊛ Spielte von 1946 bis 1964 professionellen
Baseball in der Major League.
⊛ Erst Spieler, dann Trainer.
⊛ Kein anderer hat die World Series so oft
erreicht und gewonnen wie er.
⊛ Bekannt für seine Yogiisms.
⊛ Eventuell auch Namensgeber für Yogi-Bear.

4. ( Yogi Berra
⊛ Bürgerlicher Name „Lawrence Peter Berra“.
)
⊛ Spielte von 1946 bis 1964 professionellen
Baseball in der Major League.
⊛ Erst Spieler, dann Trainer.
⊛ Kein anderer hat die World Series so oft
erreicht und gewonnen wie er.
⊛ Bekannt für seine Yogiisms.
⊛ Eventuell auch Namensgeber für Yogi-Bear.

5. ( „In theory there is no difference
between theory and practice.
In practice there is.“ )
Yogi Berra

6. ( 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 )

9. ( #1
Etablieren Sie Collective Code
Ownership.
)

10. ( Collective Code
Ownership
⊛ Aus dem Extreme Programming.
)
⊛ 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.

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

12. ( Revisionskontrolle
⊛ 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
⊛ Team Foundation Server, ...

13. ( „Our similarities are
different.“
Dale Berra (Sohn von Yogi)
)

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

15. ( Standardisierung
der IDE
⊛ Spart Zeit bei neuen Instanzen.
)
⊛ Idealerweise installiert die EDV-Abteilung
nur noch ein Image für PHP 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.

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

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.
⊛ PEAR Coding Standards
⊛ Zend PHP Coding Standards
⊛ Eigene Coding Standards

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

19. ( Coding Standards
einhalten
⊛ Nur ein angewandter Standard ist ein
)
sinnvoller Standard.
⊛ Statische Code-Analyse mit
PHP_CodeSniffer überprüft den gesamten
Code auf Regelverletzungen.
⊛ Sinnvoll: Integration in den Build-Prozess
und die IDE.
⊛ Umstritten: Integration in SVN Pre-Commit-
Hooks oder Deployment.

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

21. ( Durchführung von
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.
OK, das waren drei.

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

23. ( Reproduzierbare
Builds
⊛ 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 || make || php build.php
$ // evtl. Apache Config einbinden
$ ./start.sh

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

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

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 eine gute Dokumentation.
⊛ „Tests“ sind nicht manuelle Tests, also
„Coden Sie Ihren Test und testen Sie Ihren
Code“.

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

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

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.
⊛ Bereits einige Lösungen für PHP vorhanden.

30. ( #10
Nutzen Sie Task-Boards zur
Planung Ihrer Aufgaben.
)

31. ( )

32. ( )

33. ( #10
Verwenden Sie nicht für alles ein
elektronisches Tool.
)

34. ( )

35. ( )

36. ( Teil 2: Prozesse, Menschen
und Kommunikation )

37. ( )

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

39. ( Communication is
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?

40. ( „It was hard to have a
conversation with anyone; there
were so many people talking.“ )
Yogi Berra

41. ( #13
Sorgen Sie dafür, dass genug
Möglichkeiten zur Kom-
munikation geschaffen werden.
)

42. ( Kommunikations-
wege
⊛ Treffen von Angesicht zu Angesicht.
)
⊛ Treffen von Angesicht zu Angesicht.
⊛ Treffen von Angesicht zu Angesicht.
⊛ Videokonferenzen.
⊛ Telefonkonferenzen.
⊛ E-Mails und Instant Messenger.
⊛ Projekt-Blogs.
⊛ Microblogging / Twitter.

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

44. ( )

45. ( #15
Gemeinsames Essen stärkt die
Teambildung.
)

46. ( Teambildung
⊛ 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. ( #16
Verwenden Sie nicht den
erprobtesten Prozess.
)

48. ( #16
Verwenden Sie nicht den
besten Prozess.
)

49. ( #16
Verwenden Sie nicht den
neusten Prozess.
)

50. ( #16
Verwenden Sie nicht den
coolsten Prozess.
)

51. ( #16
Verwenden Sie nur den Prozess,
der bei Ihnen funktioniert.
)

52. ( 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.
⊛ Sprechen Sie nicht nur von Chickens,
Scrum-Master, etc.

53. ( #17
„Es gibt immer mehr als nur
einen Prozess.*“
)
*Jutta Eckstein

54. ( 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.

55. ( „If you don't know where you're
going, you'll wind up somewhere
else. “ )
Yogi Berra

56. ( #18
Sitzen Sie nicht dem Irrtum auf,
dass "agil" mit "ungeplant"
gleichzusetzen ist.
)

57. ( 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.

58. ( #19
Machen Sie Planungen und
Aufwandsschätzungen im Team.
)

59. ( Planning Poker
)

60. ( „The future ain‘t what it used to
be.“ )
Yogi Berra

61. ( #20
Nur Teams, die sich an
Veränderungen anpassen, sind
erfolgreich.
)

62. ( 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. ( #21
Hinterfragen Sie regelmäßig den
Status Quo.
)

64. ( 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 im Web
ablöst.
⊛ Die Geschichte „Who moved my cheese?“
von Spencer Johnson hilft Ihnen dabei.

65. ( „Nobody goes there anymore.
It‘s too crowded.“ )
Yogi Berra

66. ( #22
Verhindern Sie eine „Kultur der
Angst“ in Ihrem Team.
)

67. ( )
„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. ( 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. ( „I want to thank you for making
this day neccessary.“ )
Yogi Berra

70. ( #23
Hören Sie auf Tom DeMarco,
Spencer Johnson und das
Agile Manifest.
)

71. ( „I never said most of the things I
said.“ )
Yogi Berra

72. ( )

73. ( )

74. ( )

75. ( )

76. ( )

77. ( )

78. ( )

79. ( )

80. ( )

81. ( )

82. ( )

83. ( )

84. ( )

85. ( )

86. ( „It ain‘t over till it‘s over.“
)
Yogi Berra

87. ( Vielen Dank,
für Ihre Aufmerksamkeit. )
stephan.schmidt@1und1.de
http://blog.schst.net/
@schst