Nachdem ich während des Anfangs des
zweiten Vortrags (Jutta Eckstein: Wie
wird man agil?) noch bei der Nacharbeitung
meines ersten Blog-Eintrags und damit den Einstieg leider etwas verpasst
habe, nun der dritte Vortrag wieder live. Ich bin auf dem Agile Day auf
der JAX
08.
Georg Molter und Torben Knerr, beide
Zühlke Engineering GmbH:
Kollaboration
in Java-Projekten ? Anspruch und Realität
- Anforderungen an Kollaborationsplattformen
- Level 1: Mix von einzelnen Tools
- Level 2: Integrierte Plattform, hauptsächlich web-basiert
- Level 3: Integrierte Plattform, Einbettung in IDE + web-basiert
- What really matters...
Anforderungen an Kollaborationsplattformen
Probleme aller Projekte + durch räumliche
Verteilung herbeigeführte Schwierigkeiten
- Gefahr von Kommunikationsfehlern
- Gefahr unterschiedlicher Interpretation von Requirements
- Unzureichende Transparenz von Planung und Projektfortschritt
weitere
Implikationen:
- Verfügbare Kommunikationsmittel
- Hohe Latenzen, geringe(re) Netzwerkbandbreite
Erfolgrsvoraussetzungen für verteilte
Projekte
- Einheitliche Grundlage für Planung, Steuerung, Controlling und Entwicklung (Work items, Requirements)
- Einheitliche Begriffswelt, Konzepte, Tools und Prozesse an allen Projektstandorten
- Toolunterstützung für kollaborative Entwicklung
Werkzeugunterstützung für Kollaboration
- Requirements Management und Change Request Management
- Test Management
- Issue Tracking
- Konfigurations- und Buildmanagement
- Dokumentenverwaltung
- Projekt- und Ressourcenplanung, Reporting
- Kommunikation
Randbedingunen
- Offline-Fähigkeiten
- Einsetzbarkeiten in räumlich verteilten Umgebungen (VPN?)
Im Java-Umfeld
- Quasistandards und mächtige Tools
- Sprachunterstützung für Kapselung und Separation of Concerns
- Erfahrung mit Open Source-Projekten (generell kollaborativ entwickelt)
Ebenen von Kollaborationsplattformen
- Level 1: Mix von einzelnen Tools
- Level 2: Integrierte Plattform, hauptsächlich web-basiert
- Level 3: Integrierte Plattform, Einbettung in IDE + web-basiert
Level 1: Mix von einzelnen Tools
Pro
- häufig frei von Lizenzkosten
- viele Open Source-Lösungen verfügbar
- breite Benutzerbasis
Contra
- Erhöhter Administration- und Konfigurationsaufwand
Beispiele
- Subversion + Trac + Mylyn + ...
- CVS + BugZilla + TWiki + ...
Level 2: Integrierte Plattform, hauptsächlich
web-basiert
Pro
- durchgängige Integration der Konzepte
- einheitliche Benutzeroberfläche, web-basiert
- weniger Konfigurations- und Administationsaufwand
Contra
- Lizenzkosten
- nur teilweise Integration in IDE über Plugins
Beispiel
- Polarion ALM Enterprise (+ FastTrack)
Level 3: Integrierte Plattform, Einbettung
in IDE + web-basiert
Pro
- vollständige und disziplinsübergreifende Integration
- IDE als zentrales Tool, alternativ Web UI
- hohe Usability durch Rich Client
Contra
- signifikante Lizenzkosten
- steigende Komplexität der IDE
Beispiele
- IBM Rational Jazz Platform
- Microsott Team Foundation Server
What really matters...
Enge Abstimmung von Tooling und Prozessen
(Lücken im Tooling können durch Prozesse
kompensiert werden)
Aber: Tools können keine Prozesse ersetzen!
Tooling für Kollaboration
- erfordert ein Adressieren aller für die Entwicklung relvanter Disziplinen
- erfordert eine möglichst hohe Durchgängigkeit von Konzepten über die Disziplinen hinweg
Voraussetzung für gemeinsames Verständnis,
durchgängige Planung und durchgängiges Reporting
Parameter für die Auswahl
- Organisatorische Komplexität des Projekts
- Zuordnung von Aufgaben/Rollen zu Standorten
- lokale/gemeinsame Ownership von Subsystemen oder Komponenten
Ziel: sinnvolle Balance zwischen
- Vereinheitlichung/detaillierter Planung vs. Gestaltungsfreiheit
- globaler Konsistenzsicherung vs. Performance (Antwortzeiten/Netzwerkbandbreite)
- Benefit durch die Toolunterstützung vs. Kosten/Betriebsaufand/Verlust von Freiheitsgraden
