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

Stephan Schmidt1&1 Internet AG

Stephan Schmidt

• Software-Entwickler und "Beinahe Pädagoge"

• Kombiniert gerne beides im Beruf

• Head of Web Sales Development bei der

1&1 Internet AG

• Autor, Redner und die ganzen anderen

Sachen

• (außer Consultant)

"Yogi" Berra

• Bürgerlicher Name Lawrence Peter Berra

• Spielte von 1946 bis 1964 professionellen

Baseball in der Major League

• Kein anderer hat die World Series so oft

erreicht und gewonnen

• Bekannt für seine Yogiisms

• Auch kein Consultant

• Eventuell auch Namensgeber für

Yogi-Bear

"In theory there is no

difference between theory

and practice.

In practice there is."

Yogi Berra

Theorie vs Praxis

• Die Präsentation beruht auf meiner

Erfahrung.

• Die Regeln 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.

Es geht um Menschen

Teil 1:Tools und Code

#1

Etablieren Sie

Collective Code

Ownership.

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.

• Macht den Code besser.

• Sie profitieren von den Stärken aller

Teammitglieder.

#2

Setzen Sie ein Werkzeug

zur Revisionskontrolle

ein.

Revisionskontrolle

• Nur dadurch werden parallel Änderungen

an einem Projekt möglich.

• Es ist egal, welches System Sie einsetzen,

aber tun Sie's.

• CVS

• Subversion

• GIT

• Team Foundation Server

• etc.

" Our similarities are

different."

Dale Berra (Sohn von Yogi Berra)

#3

Standardisieren Sie die

Entwicklungsumgebung

Ihres Teams.

Standardisierung

• Spart Zeit, wenn eine neue Instanz benötigt

wird.

• 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 1 Stunde statt

2 Tagen

#4

Definieren Sie Coding

Standards.

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

#5

Stellen Sie sicher, dass

Ihre Standards

eingehalten werden.

Standards forcieren

• Coding Standards sind nur sinnvoll, wenn

sie eingehalten werden.

• Statische Code-Analyse mit PHP_CodeSniffer

überprüft den gesamten Code auf Regel-

verletzungen.

• Sinnvoll: Integration in den Build-Prozess und

die IDE.

• Umstritten: Integration in SVN Pre-Commit-

Hooks oder Deployment.

#6

Führen Sie Code

Reviews durch.

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.

#7

Sorgen Sie dafür, dass Ihr

Build reproduzierbar

ist.

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

$ // evtl. Apache Config einbinden

$ ./start.sh

"We made too many wrong

mistakes."

Yogi Berra

#8

Tests erlauben Ihrem

Team die Freiheit, Code zu

ändern.

Testen des Codes

• Im Team wird der Code von verschiedenen

Entwicklern erstellt oder modifiziert.

• Tests ermöglichen Entwicklern zu prüfen

ob die Änderungen negative Auswirkungen

hatten.

• Tests nehmen dem Team die Angst,

Änderungen durchzuführen.

• Tests sind außerdem eine gute

Dokumentation.

• Mit "Tests" meine ich nicht manuelle Tests.

"It's like déjà vu all over

again."

Yogi Berra

#9

Integrieren Sie Ihren Build

regelmäßig.

Continuous Integration

• Build wird in regelmäßigen Abständen oder

nach jedem Commit angestoßen.

• Dabei wird immer ein vollständiger Build

erzeugt und alle Unit- und Integrationstests

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.

#10

Nutzen Sie Task-Boards

zur Planung Ihrer

Projekte.

JIRA und Greenhopper

Outlook

#11

Verwenden Sie

nicht für alles ein

elektronisches Tool.

Taskboard v1.0

Taskboard v1.0

Teil 2:Prozesse, Menschen

und Kommunikation

Cowboys und Indianer

#12

Kommunikation

entscheidet in den

meisten Projekten über

Erfolg und Niederlage.

Kommunikation

• 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?

"It was hard to have a

conversation with anyone;

there were so many people

talking. "Yogi Berra

#13

Sorgen Sie dafür, dass

genug Möglichkeiten zur

Kommunikation

geschaffen werden.

Kommunikationsmittel

• Treffen von Angesicht zu Angesicht

• Treffen von Angesicht zu Angesicht

• Treffen von Angesicht zu Angesicht

• E-Mails und Instant Messenger

• Projekt-Blogs

• Microblogging / Twitter

• Telefonkonferenzen

• Videokonferenzen

#14

Suchen Sie kreative Wege,

um persönliche

Kommunikation

herzustellen.

Kreative Wege

#15

Gemeinsames Essen

stärkt die Teambildung.

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.

#16

Verwenden Sie nicht den

erprobtesten Prozess.

#16

Verwenden Sie nicht den

erprobtesten besten

Prozess.

#16

Verwenden Sie nicht den

erprobtesten besten

neusten Prozess.

#16

Verwenden Sie nicht den

erprobtesten besten

neusten coolsten Prozess.

#16

Verwenden Sie nur den

Prozess, der bei Ihnen

funktioniert.

Prozessmodelle

• Wasserfall-Modell

• Hat in meinen Projekten noch nie

funktioniert.

• Agile Prozesse

• Versprechen deutlich höhere Erfolgs-

chancen.

• Bitte nicht sklavisch einhalten.

• Sprechen Sie nicht nur von Chickens,

Scrum-Master, etc.

#17

Es gibt immer mehr als

nur einen Prozess.

Jutta Eckstein

Verschiedene Prozesse

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

"If you don't know where

you're going, you'll wind

up somewhere else."Yogi Berra

#18

Sitzen Sie nicht dem

Irrtum auf, dass "agil" mit

"ungeplant" gleich-

zusetzen ist.

Sie sind es

wirklich nicht.(ganz ehrlich)

#19

Machen Sie Planungen

und Aufwands-

schätzungen im Team.

Aufwandsschätzungen

• Planning Poker kann ein hilfreiches

Mittel sein.

"The future ain't what it

used to be."

Yogi Berra

#20

Nur Teams, die sich an

Veränderungen anpassen,

sind erfolgreich.

Embrace Change

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

#21

Hinterfragen Sie

regelmäßig den Status

Quo.

Der Status Quo

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

"Nobody goes there

anymore. It's too

crowded."Yogi Berra

#22

Verhindern Sie eine Kultur

der Angst.

Kultur der Angst

"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"

Kultur der Angst

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

" I want to thank you for

making this day

necessary."Yogi Berra

#23

Hören Sie auf Tom

DeMarco, Spencer Johnson

und das Agile Manifest.

" I never said most of the

things I said. "

Yogi Berra

Bücher

" It ain't over till

it's over. "

Yogi Berra

Vielen Dank für

Ihre Aufmerksamkeit.

stephan.schmidt@1und1.de