Wie behält man bei Großprojekten den Überblick?
Hallo,
ich wollte mal fragen wie man bei größeren Projekten den Überblick behält.
Welche Strategien verfolgt ihr?
Welche Tools benutzt ihr für Planung, Workflow-Management und -kontrolle?
Hallo Cyron,
tja, wenn es da mal ein Patentrezept geben würde. Gibt es aber nicht. Gerade deshalb gibt es auch massig Bücher zu dem Thema (Projektmanagement). Es ist ohnehin nicht so sehr eine Frage der Tools, sondern des Managements.
herbivore
ich habe zwar noch nicht damit gearbeitet, aber UML ist sehr verbreitet bei der softwaremodellierung.
Hallo Cyron,
ich schliesse mich der Meinung herbivores an und gehe davon aus, dass Du als Teamleitung fungierst?
Die eingesetzten Tools sind sekundär und subjektiv in der Bewertung. Dazu kommt, dass in manchen Projekten die Tool-Landschaft bereits vorgegeben ist.
Gutes Management ist das A und O. Niemals verzichten auf Coding-Coventions und Dokumentationen. Auch eine saubere Versionierung der Sourcen hat noch niemandem geschadet. Die schönste Planung ist futsch, wenn einfach drauflos codiert wird.
Sehr wichtig finde ich auch - die scheinbar leider nicht bekannte - Vorgehensweise des Code-Betrachtens. Schau Dir an, was Deine Entwickler so produzieren und ob Ihr alle in die gleiche Richtung denkt. Oftmals macht das niemand und am Ende wird sich gewundert warum dieser oder jener Code nicht erweiterbar ist oder vice versa zu oversized und vermustert.
Und vor allem nutze die Macht der Delegation. Wichtig ist rauszuspüren wer im Team welche Aufgaben zu Deiner Zufriedenheit ausführen kann. Wenn Du versuchst alles im Alleingang zu erledigen, wirst Du zwangsläufig scheitern.
Naja, was schreibe ich. Ein gutes Buch hilft Dir da wohl weiter. Aber nicht vergessen mit allen Sinnen bei der Sache zu bleiben - das ist die Beste und projektbezogenste Strukturierung.
Ich hoffe das ging so in Deine Richtung
🙂 Torsten
Ich gehe von .NET Projekten mit Visual Studio 2005 (um "den Überblick behalten" doch mal aus der praktischen Tool-Sicht zu beschreiben) aus:
Ganz wichtig ist zuerst mal eine konstante und sinnige Namensgebung für Namespaces, Assemblies, Klassen, Methoden und Variablen. Da man im Team oft mit Code der Kollegen zu tun hat, sollte fast jede Zeile Code (Manche finden das übertrieben, aber ich habe gute Erfahrungen damit gemacht) kommentiert sein. Auf diese Weise kann man den Code lesen wie ein Buch, was die Einarbeitungszeit in fremden Code verkürzt. Sachen die es zu erledigen gilt, sollten im Code per "//TODO: xxxx" markiert werden (Dann tauchen sie in der Aufgabenliste auf). Alte Methoden, die bald ausgemustert werden sollen, mit [Obsolete]-Attribute markieren und im Text angeben, welche Methode künftig verwendet werden soll. Kollegen, die vielleicht aus Gewohnheit die alte Methode verwenden, krigen so eine Compiler-Warnung.
Bei großen Projekten ist Architektur wichtig und kann helfen, den Überblick zu behalten und die Qualität der Software erhöhen. Dazu gehören Aufgaben, wie z.B. Einteilung des Projekts in klar gegeneinander abgegrenzte Komponenten/Dienste. Außerdem sollten für die Kommunikation zwischen den Komponenten/Diensten und ggf. Fremdanwendungen explizit definierte Schnittstellen (Je nach Bedarf C# Interfaces, XSD, WSDL, ...) verwendet werden.
Um erfolgreich im Team arbeiten zu können, ist auf jeden Fall eine Quellcode-Verwaltung (Subversion, Visual SourceSafe, ect.) einzusetzen.
Visual Studio 2005 ermöglicht die logische Einteilung von Projekten in einer Projektmappe in sogenannte Projektmappen-Ordner. Das hilft bei der strukturierung großer Projektmappen. Überhaupt sollten möglichts wenige (Am besten eine für das ganze Projekt), aber dafür große Projektmappen aufgebaut werden. Ich arbeite momentan mit einem Team von drei Leuten an einer Lösung, welche momentan 43 Visual Studio-Projekte (Tendenz steigend) in einer Projektmappe hat. Würden wir viele kleine Projektmappen verwenden, hätten wir einen deutlich höheren Synchronisierungsaufwand. Mit nur einer Mappe ist man mit einem Klick auf "Letzte Version abrufen" sofort auf dem neusten Stand.
Und vor allem im Team viel miteinander reden! Alle Team-Mitglieder sollten möglichst auf dem selben Informationsstand sein.
Hallo und vielen Dank für die Antworten. 👍
Ich konnte meine Teamkollegen schon davon überzeugen, statt direkter SQL-Anweisungen im Code, doch besser mit einem data access layer und BLL zu arbeiten. Das mal nur als Beispiel. Ich denke ich bin auf dem richtigen Weg. 🙂
Mit dem Projektplan, den ich heute ausgearbeitet habe, kristallisierten sich dann auch die Zuständigkeiten regelrecht von selbst heraus.
Na dann mal viel Erfolg! Und immer schön wachsam bleiben 😉
🙂 Torsten
Original von Rainbird
Überhaupt sollten möglichts wenige (Am besten eine für das ganze Projekt), aber dafür große Projektmappen aufgebaut werden. Ich arbeite momentan mit einem Team von drei Leuten an einer Lösung, welche momentan 43 Visual Studio-Projekte (Tendenz steigend) in einer Projektmappe hat. Würden wir viele kleine Projektmappen verwenden, hätten wir einen deutlich höheren Synchronisierungsaufwand. Mit nur einer Mappe ist man mit einem Klick auf "Letzte Version abrufen" sofort auf dem neusten Stand.
Sagt man normalerweise nicht immer, man sollte im Team nicht eine große Projektmappe, sondern viele kleine verwenden?
Vielleicht wenn man keine Quellcodeverwaltungs-Software hat. Worin sollte der Vorteil liegen, alles in kleine Brocken zu packen?
Architektonisch spielt es ja keine Rolle, da die Projektmappe nur eine Sammelfunktion hat.