ich bin seit vielen Jahren als Java-Entwickler tätig, und frage mich immer mehr, ob wirklich alles so richtig ist, wie es ist. Mich würde interessieren, ob meine Vorstellungen von einer guten Vorgehensweise bezüglich Teamarbeit irgendwo da draußen tatsächlich so umgesetzt werden, wie ich mir das wünschen würde, oder ob ich völlig daneben liege:
- ein großes Projekt lässt sich typischerweise in zahlreiche autonome Module aufteilen, die über vordefinierte Schnittstellen miteinander verbunden sind. Die Schnittstellen sind Teil der Projektarchitektur. Die Projektarchitktur sollte gut geplant sein, aber sich keinesfalls mit Implementierungs-Detail befassen, sondern ein stabiles Gerüst für das Zusammenspiel der zu implementierenden Module darstellen, und ein gesundes Maß an Erweiterbarkeit mitbringen.
- Architektur und Schnittstellen sollten von allen Projektbeteiligten wie selbstverständlich respektiert werden. Änderungen oder Erweiterungen an Architektur und Schnittstellen sollten nur vom Projektleiter bzw. Systemarchitekten unter Abstimmung mit allen beteiligten Modul-Entwickler vorgenommen werden. Wenn sich während der Projektentwicklung neue Ziele ergeben, oder die Kommunikation der Module untereinander erweitert werden muß, dann sollte das immer erst in die Gesamtarchitektur einfließen, und von dort dann in die Module.
- Bei der Implementieung der Module haben die beauftragten Softwareentwickler Gestaltungsfreiheit. Wichtig ist nur die strikte Einhaltung der vorgegebenen Schnittstellen, termingerechte Fertigstellung, und möglichst fehlerfreie Funktion des Moduls. Auf diese Weise hat jeder Entwickler mit seiner Arbeit ein Stück von sich selbst in das Gesamtprojekt mit eingebracht. Man kann hunterher sagen: "diesen Teil habe ich gemacht", und stolz darauf sein. Zumindest für mich ist das eine sehr motivierende und erfüllende Vorstellung.
- wenn ein Programm-Modul eines bestimmten Entwicklers geändert oder erweitert werden soll, und dieser Entwickler im Team verfügbar ist, dann sollte eben dieser Entwickler auch die Änderungen implementieren dürfen. Falls aus zwingendem Grund doch ein anderer Entwickler die Arbeiten ausführen soll, dann sollte ein begleitender Dialog zwischen beiden Entwicklen stattfinden. Der ursprüngliche Entwickler sollte in jedem Fall eine "Patenschaft" für sein Stück Code behalten.
In meiner augenblicklichen Realität ist wenig von meinen oben beschriebenen Wünschen zu finden. Enterprise-Projekte werden hier mithilfe eines kommerziellen Frameworks, zahlreicher OpenSource Frameworks, einem Ticketsystem sowie mündlichen Absprachen, auf Basis einer Versionsverwaltung realisiert. Insbesondere die Versionsverwaltung führt dazu, dass sich jedermann berufen fühlt, in jedermanns Code zu jeder Zeit herumzumatschen. Es werden bereits funktionierende Programmteile kommentarlos gelöscht und durch Code anderer ersetzt. Es werden Seiteneingänge und Querverbindungen ohne Nachfragen eingebaut, und bereits implementierte Konzepte umgangen. Ehemals sorgfältig gekapselter Programmgode wird aufgebrochen, bestehende Konzepte werden ignoriert, und in so etwas wie "Spaghetticode auf hohem Niveau" verwandelt, wo sich mitunter eine ganze Schar von Entwicklern mit jeweils ganz unterschiedlichen Philosophien haben durchsetzen wollen.
Fazit: Mein jetziger Arbeitgeber ist ausgesprochen erfolgreich! Folglich muß das unten beschriebene Vorgehen wohl das Richtige sein, und meine oben beschriebenen Vorstellungen sind wohl falsch.
Ist das überall so, wie wird bei Euch in der Firma Software im Team entwickelt?
- ein großes Projekt lässt sich typischerweise in zahlreiche autonome Module aufteilen, die über vordefinierte Schnittstellen miteinander verbunden sind. Die Schnittstellen sind Teil der Projektarchitektur. Die Projektarchitktur sollte gut geplant sein, aber sich keinesfalls mit Implementierungs-Detail befassen, sondern ein stabiles Gerüst für das Zusammenspiel der zu implementierenden Module darstellen, und ein gesundes Maß an Erweiterbarkeit mitbringen.
- Architektur und Schnittstellen sollten von allen Projektbeteiligten wie selbstverständlich respektiert werden. Änderungen oder Erweiterungen an Architektur und Schnittstellen sollten nur vom Projektleiter bzw. Systemarchitekten unter Abstimmung mit allen beteiligten Modul-Entwickler vorgenommen werden. Wenn sich während der Projektentwicklung neue Ziele ergeben, oder die Kommunikation der Module untereinander erweitert werden muß, dann sollte das immer erst in die Gesamtarchitektur einfließen, und von dort dann in die Module.
- Bei der Implementieung der Module haben die beauftragten Softwareentwickler Gestaltungsfreiheit. Wichtig ist nur die strikte Einhaltung der vorgegebenen Schnittstellen, termingerechte Fertigstellung, und möglichst fehlerfreie Funktion des Moduls. Auf diese Weise hat jeder Entwickler mit seiner Arbeit ein Stück von sich selbst in das Gesamtprojekt mit eingebracht. Man kann hunterher sagen: "diesen Teil habe ich gemacht", und stolz darauf sein. Zumindest für mich ist das eine sehr motivierende und erfüllende Vorstellung.
- wenn ein Programm-Modul eines bestimmten Entwicklers geändert oder erweitert werden soll, und dieser Entwickler im Team verfügbar ist, dann sollte eben dieser Entwickler auch die Änderungen implementieren dürfen. Falls aus zwingendem Grund doch ein anderer Entwickler die Arbeiten ausführen soll, dann sollte ein begleitender Dialog zwischen beiden Entwicklen stattfinden. Der ursprüngliche Entwickler sollte in jedem Fall eine "Patenschaft" für sein Stück Code behalten.
In meiner augenblicklichen Realität ist wenig von meinen oben beschriebenen Wünschen zu finden. Enterprise-Projekte werden hier mithilfe eines kommerziellen Frameworks, zahlreicher OpenSource Frameworks, einem Ticketsystem sowie mündlichen Absprachen, auf Basis einer Versionsverwaltung realisiert. Insbesondere die Versionsverwaltung führt dazu, dass sich jedermann berufen fühlt, in jedermanns Code zu jeder Zeit herumzumatschen. Es werden bereits funktionierende Programmteile kommentarlos gelöscht und durch Code anderer ersetzt. Es werden Seiteneingänge und Querverbindungen ohne Nachfragen eingebaut, und bereits implementierte Konzepte umgangen. Ehemals sorgfältig gekapselter Programmgode wird aufgebrochen, bestehende Konzepte werden ignoriert, und in so etwas wie "Spaghetticode auf hohem Niveau" verwandelt, wo sich mitunter eine ganze Schar von Entwicklern mit jeweils ganz unterschiedlichen Philosophien haben durchsetzen wollen.
Fazit: Mein jetziger Arbeitgeber ist ausgesprochen erfolgreich! Folglich muß das unten beschriebene Vorgehen wohl das Richtige sein, und meine oben beschriebenen Vorstellungen sind wohl falsch.
Ist das überall so, wie wird bei Euch in der Firma Software im Team entwickelt?
- Thema "Alle Wege führen nach Rom"
