Das Dokument behandelt die Herausforderungen und Erfahrungen der Offshore-Entwicklung unter Verwendung von Scrum-Methoden und Teamdynamik. Es werden Probleme wie schlechte Performance und unklare Aufgabenverteilung diskutiert, sowie Ansätze zur Verbesserung wie Kennzahlen, Pair Programming und die Implementierung von effektiven Kommunikationstools. Gleichzeitig wird die Wichtigkeit von Transparenz und Teamkultur hervorgehoben, um den Erfolg in der Offshore-Entwicklung zu sichern.

1. Offshoreentwicklung
- Scrum, Teambildung, Tools, Kennzahlen
Wolfgang Kraus
29.01.2009, München

2. Allgemeines
Motivation, Gründe



Ressourcenmangel
Preis
Management Attention

3. Meinungen, Vorurteile - 1
Preis



Offshore ist „billig“
Unendlicher Ressourcenpool
Alles High-Professionals

4. Meinungen, Vorurteile - 2
Skalierbarkeit


1 Chinese 100 Chinesen
100 Projekttage  1 Projekttag 

5. Meinungen, Vorurteile - 3
Projektvorbereitungen




Mauerbesuch
Land und Leute
Termin, Budget
Wir probieren das mal

6. Beispielszenario - 1
Web-Anwendung


J2EE-Umfeld
Landschaft
 Jboss, Linux
 Eclipse, Maven, Junit, Selenium
 Jira, SVN, Hudson

7. Beispielszenario - 2
Team

OnSide



1 Projektleiter, 1 Teamleiter
2 Entwickler (Architektur, Tool, Support)
1 Produktmanager

8. Beispielszenario - 3
Team
Offshore Team



1 Projektleiter, 1 Teamleiter
3 Entwickler
1 Testingenieur

9. 1.Versuch
Prozess


Scrum
Iteration 2 Wochen

10. 1.Versuch
Infrastruktur




VPN-Verbindung
Applikationserver
DB-Server
Entwicklungsserver

11. 1. Versuch
Tools


Software Configuration Mangement
 Hudson
Versionskontrolle
 Subversion

12. 1. Versuch
Tools


Build
 Maven
Anforderungsmanagement
 TrendAnalyst

13. 1. Versuch
Test


Junit
Selenium

14. 1. Versuch
Kommunikation





Spark (Chat)
JIRA (Ticketsystem)
Wiki
Telefon
Videokonferenz

15. 1. Versuch
Ergebnisse




Schlechte Performance
geringe Qualität
schleppende Kommunikation
instabiler Prozess (häufige
Änderungen)
 Was läuft hier falsch?

16. 1. Versuch
Ursachen




mangelnde Kompetenz des Teams
unzureichende Spezifikationen
unklare Aufgabenverteilung, Rollen
keine Kennzahlen

17. 2. Versuch
Kennzahlen






Daily Burn Down Chart
StoryPoint für Aufwandsschätzung
Testabdeckung, Performancemessungen
Soll-, Istaufwände
Reifegrad von Spezifikationen
MIX und BSI (Team, Kunde)

18. 2. Versuch
Team


Pair Programming
Teamverantwortung (‚Sippenhaft‘)

19. 2. Versuch
Analyse / Design




UseCase driven
Dokumenten Metamodell
Testbarkeit,
Messbarkeit von Anforderungen

20. 2. Versuch
Reviews



Produkt
Prozess
Kommunikation

21. Ergebnis
Transparenz



Täglich aktueller Projektstatus
gültige Dokumentation
gelebter Prozess

22. Ergebnis
Messbarkeit


Entwicklungsergebnisse
Softwarequalität
 Performance
 Testabdeckung
 Architekturstandards

23. Ergebnis
Testbarkeit

Klare Abnahmekriterien

24. Fazit





Prozess
Tools
Kommunikation
Transparenz
Teamkultur

25. Fazit
Offshore = Collaboration