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

  • 4,496 views
Uploaded on

Slides des Vortrags auf der International PHP Conference Spring Edition 2010

Slides des Vortrags auf der International PHP Conference Spring Edition 2010

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,496
On Slideshare
0
From Embeds
0
Number of Embeds
5

Actions

Shares
Downloads
54
Comments
0
Likes
7

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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