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