Softwareentwicklung im Team – Teil 1 – Einleitung

Ich habe vor kurzem ein Dokument wiedergefunden, welches ich im Oktober 2008 bei meinem alten Arbeitgeber geschrieben habe. Zu diesem Zeitpunkt waren wir mitten in einem (Web-)Projekt für einen Kunden. Das Team bestand aus fünf Entwicklern, wovon einige lediglich Teilzeit gearbeitet haben (unter anderem ich. Ich war also “nur” ein Entwickler und hatte keine Projektverantwortung oder ähnliches).

Die Teamarbeit gestaltete sich ein wenig schwierig, da eigentlich keine der allgemein bekannten Best-Practices umgesetzt wurden. Da ich ein halbes Jahr zuvor mit dem Versuch gescheitert war, im Alleingang die (Ant-)Build-Skripte so zu generalisieren, dass diese auch auf einem CI-Server laufen, habe ich meine Vorschläge zur Verbesserung des Projektablaufs aufgeschrieben und diese als Diskussionsgrundlage den restlichen Teammitgliedern vorgelegt.

Da der Text im Allgemeinen nichts an Aktualität verloren hat, werde ich diesen hier nach und nach veröffentlichen. Das ich nicht alles auf einmal poste, liegt zum einen daran, dass einige Textstellen einer näheren Erläuterung bedürfen und zum anderen daran, dass man nach über 16 Monaten auch zu den einzelnen Punkte jeweils ein Fazit geben kann, ob und wie sich die Vorschläge entwickelt haben.

Auch wenn die hier angesprochenen Punkte eigentlich zum Standard-Repertoire eines jeden Entwickler-Teams gehören sollten, weiß ich, dass das leider nicht immer der Fall ist. Wer also in einem Team arbeitet, bei dem alles drunter und drüber läuft, darf sich gerne an diesen (eigentlich lange bekannten) Ideen bedienen, in der Hoffnung, dass diese dem einen oder anderen das Leben leichter machen.

Die Einleitung

Langfristig gesehen wird die Art wie wir Software entwickeln keinen Erfolg haben. Projekte könnten z.B. zum jetzigen Zeitpunkt ohne bestimmte Entwickler überhaupt nicht gepflegt und/oder erweitert werden. Darüber hinaus ist beim aktuellen Stand der Dinge der Entwicklungsprozess stressiger, als er eigentlich sein müsste.

Daher ein paar Verbesserungsvorschläge wie wir einige Probleme in den Griff bekommen könnten. Ich möchte hiermit weder jemandem “ans Bein pissen” noch klammere ich mich aus, was die hier genannten Probleme anbelangt.

Sämtliche Vorschläge lassen sich innerhalb kürzester Zeit umsetzen. Damit sie sich aber auch langfristig etablieren, sollte eine gemeinsame Entscheidung getroffen werden. Daher sind die Vorschläge auch wirklich nur Vorschläge. Sobald eine gemeinsamer Beschluss gefasst wurde, so ist dieser auch vehement durchzusetzen!

Ich habe die folgenden angesprochenen Probleme wie folgt gegliedert:

Problem / Beispiel
Lösungsvorschlag
Vorteile
Nachteile / Probleme
Aufwand

Die Probleme sind bereits so sortiert, wie sie meines Erachtens nach angegangen werden sollten (also nach Dringlichkeit), wobei sich einige sicherlich parallel umsetzen lassen könnten.

Rückblickend gesehen…

Zugegeben, die Einleitung war ein “wenig” drastisch formuliert. Das lag daran, dass unsere Probleme nicht erst seit gestern bestanden und jedes Mal, wenn einer der Entwickler sagte, wir müssten mal XYZ umsetzen, bekam man als Antwort irgendwas in der Art von: “Ja, das können wir mal machen, wenn wir Zeit dazu finden. Aber der Zeitplan ist so straff, dass wir das jetzt nicht machen können.”
Man hatte Angst, dass man noch weiter im Zeitplan zurückfallen könnte. Das aber gerade diese Probleme Hauptgrund für den ständigen Verzug waren und wir mit dem Lösen der Probleme Zeit gewinnen würden, wurde überhaupt gar nicht wahrgenommen.

Die zusätzliche Betonung, dass dies nur Vorschläge seien und nicht der Weisheit letzter Schluss, lag an meiner vorherigen Erfahrung, als ich versuchte, im Alleingang einen Continious Integration Server aufzusetzen. Der lief zwar, wurde aber von niemanden verwendet / beachtet, so dass meine vorherigen Bemühungen als gescheitert betrachtet werden mussten. Es war mir also wichtig, dass wir einen Konsens finden, der vom gesamten Team getragen wird und nicht von einem einzelnen “diktiert” wird.

Da ich den kompletten Text einige Tage vor dem angesetzten Meeting jedem Entwickler ausgedruckt und auf den Tisch gelegt habe, war es mir wichtig, dass sich niemand angegriffen und/oder übergangen fühlte. Hätte ich erst ein Protokoll nach dem Meeting geschrieben oder hätte ich mein Anliegen mündlich vorgetragen, hätte die Einleitung ganz anders ausgesehen. Es war mir aber auch wichtig, meine Kollegen nicht zu überrumpeln und erst im Meeting die Katze aus dem Sack zu lassen, so dass jeder genügend Zeit hatte, sich selber Gedanken zu den von mir angesprochenen Problemen und Lösungsvorschlägen zu machen.

Zusammenfassung

  • Es ist wichtig, dass Änderungen vom Großteil des Teams getragen werden. Diktierte Änderungen setzen sich nicht durch! Wie hieß es so schön in einigen meiner Vorlesungen aus Studienzeiten? “Beteiligte zu Betroffenen machen”!
  • Betroffene dürfen nicht überrumpelt werden. Sie benötigen genügend Zeit, sich selbst ein Bild zu machen. Selbst wenn sie jeden Tag mit einem Problem konfrontiert werden, heißt das noch lange nicht, dass sie sich jemals Zeit dazu genommen haben, alternative Lösungen anzuschauen.

Ausblick

Nach der kurzen Einleitung, werden im folgenden ungefähr 10 Probleme unter den oben genannten Gesichtspunkten angesprochen. Als nächstes: “Unabhängiger Buildprozess

2 Gedanken zu „Softwareentwicklung im Team – Teil 1 – Einleitung“

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>