23 Dinge, die Sie über Software-Entwicklung in Teams wissen sollten.
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.
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.
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.
)
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.
)
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.
)
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