Vorgehensweise bei Teamarbeit

[Florian Hämmerle]

Hallo!

Ich stehe vor dem erstmaligen Leiten eines Programmier-Teams. Im Moment sind wir noch zu zweit, aber das kann sich auch noch ändern und wir sind auf einmal 3 oder 4 Leute.
Mich würde interessieren, wie ihr an so was rangehen würdet bzw. rangeht (im Falle, dass ihr schon Erfahrung habt).
Welche Software ist empfehlenswert, damit immer alle auf dem neuesten Stand sind? Wie organisiert man das Team am besten? ...?

Bin schon gespannt auf eure Antworten.

Viele Grüße,
Florian

[blackfin]

Was die Software angeht, habe ich bisher ziemlich gute Erfahrungen mit mantis gemacht, was die "Organisation" im Team angeht.
Eigentlich ist das Ding ja ein Bugtracker, aber es lässt sich auch wunderbar dafür verwenden, einzelne Tasks an TeamMitglieder zuzuweisen und deren Status an die Entwicklung anzupassen.
Das schöne an Mantis ist, dass es wirklich sehr einfach zu bedienen ist und (zunächst zu meinem Erstaunen) auch gut von Leuten bedient werden kann, die eigentlich mit Software-Entwicklung vorher gar nichts am Hut hatten und vorher all ihr Zeug in Excel-Listen geschrieben haben :)

Als Versionskontrolle des quellcodes im Team habe ich bisher eigentlich immer Subversion benutzt. Es dauert zwar immer ein Weilchen, bis man alle Leute in das Ding eingewiesen hat und es kommt immer wieder am Anfang zu Fehlbedienungen, aber wenn nach ein paar Wochen dann der Hase läuft, will man es nicht mehr missen.

Ansonsten ist es wichtig, dass es generell einen gibt, der die "End-Entscheidung" fällt :) Ansonsten geht ein haufen Zeit für Diskussionen drauf.

[freak4fun]

Wenn ihr externe Tickets von Kunden bekommt braucht ihr noch ein Ticketverwaltungssystem, das zB vom SUpport geführt wird und wo man sich dann die Aufgaben hin und herschieben kann. ;)

[Florian Hämmerle]

Zitat:

Zitat von blackfin (Beitrag 1025863)

Was die Software angeht, habe ich bisher ziemlich gute Erfahrungen mit mantis gemacht, was die "Organisation" im Team angeht.
Eigentlich ist das Ding ja ein Bugtracker, aber es lässt sich auch wunderbar dafür verwenden, einzelne Tasks an TeamMitglieder zuzuweisen und deren Status an die Entwicklung anzupassen.
Das schöne an Mantis ist, dass es wirklich sehr einfach zu bedienen ist und (zunächst zu meinem Erstaunen) auch gut von Leuten bedient werden kann, die eigentlich mit Software-Entwicklung vorher gar nichts am Hut hatten und vorher all ihr Zeug in Excel-Listen geschrieben haben :)

Danke für den Tipp mit mantis. Werd mir das bei Gelegenheit mal genauer anschauen. Nicht dass das etwas overflow ist. Sonst schreib ich mir das selbst. Mal wieder PHP anwenden :)

Zitat:

Zitat von blackfin (Beitrag 1025863)

Als Versionskontrolle des quellcodes im Team habe ich bisher eigentlich immer Subversion benutzt. Es dauert zwar immer ein Weilchen, bis man alle Leute in das Ding eingewiesen hat und es kommt immer wieder am Anfang zu Fehlbedienungen, aber wenn nach ein paar Wochen dann der Hase läuft, will man es nicht mehr missen.

Mit Subversion hab ich jetzt noch gar keine Erfahrung. Zwar schon viel darüber gehört und gelesen, aber noch nie benutzt. Ich weiß zwar, was das Ding in etwa so macht, aber es ist jetzt wohl an der Zeit sich das mal näher anzusehen.

Zitat:

Zitat von blackfin (Beitrag 1025863)

Ansonsten ist es wichtig, dass es generell einen gibt, der die "End-Entscheidung" fällt :) Ansonsten geht ein haufen Zeit für Diskussionen drauf.

Ja, das denk ich mir. Wenn man zu zweit ist, kann man das noch relativ gut zusammen machen (denk ich mal), aber wenn es dann mehrere werden, fängt es an im Team zu "menscheln" ;).

Zitat:

Zitat von freak4fun (Beitrag 1025867)

Wenn ihr externe Tickets von Kunden bekommt braucht ihr noch ein Ticketverwaltungssystem, das zB vom SUpport geführt wird und wo man sich dann die Aufgaben hin und herschieben kann. ;)

Jupp, wird im Moment nicht der Fall sein, aber ansonsten kann ich das entweder selbst integrieren mit PHP oder ein kleines Forum dürfte da auch gute Dienste leisten.

Danke vielmals und schöne Grüße,
Florian

[freak4fun]

Zitat:

Zitat von Florian Hämmerle (Beitrag 1025872)

Zitat:

Zitat von blackfin (Beitrag 1025863)

Als Versionskontrolle des quellcodes im Team habe ich bisher eigentlich immer Subversion benutzt. Es dauert zwar immer ein Weilchen, bis man alle Leute in das Ding eingewiesen hat und es kommt immer wieder am Anfang zu Fehlbedienungen, aber wenn nach ein paar Wochen dann der Hase läuft, will man es nicht mehr missen.

Mit Subversion hab ich jetzt noch gar keine Erfahrung. Zwar schon viel darüber gehört und gelesen, aber noch nie benutzt. Ich weiß zwar, was das Ding in etwa so macht, aber es ist jetzt wohl an der Zeit sich das mal näher anzusehen.

Aus meiner Sicht unverzichtbar, wenn mehr als einer an einer Software arbeitet. Und dann auch gleich Richtlinien mit zu wie Kommentare auszusehen haben. ;)

[Florian Hämmerle]

Zitat:

Zitat von freak4fun (Beitrag 1025874)

Zitat:

Zitat von Florian Hämmerle

Zitat:

Zitat von blackfin (Beitrag 1025863)

Als Versionskontrolle des quellcodes im Team habe ich bisher eigentlich immer Subversion benutzt. Es dauert zwar immer ein Weilchen, bis man alle Leute in das Ding eingewiesen hat und es kommt immer wieder am Anfang zu Fehlbedienungen, aber wenn nach ein paar Wochen dann der Hase läuft, will man es nicht mehr missen.

Mit Subversion hab ich jetzt noch gar keine Erfahrung. Zwar schon viel darüber gehört und gelesen, aber noch nie benutzt. Ich weiß zwar, was das Ding in etwa so macht, aber es ist jetzt wohl an der Zeit sich das mal näher anzusehen.

Aus meiner Sicht unverzichtbar, wenn mehr als einer an einer Software arbeitet. Und dann auch gleich Richtlinien mit zu wie Kommentare auszusehen haben. ;)

Eine Art Style-Guide wie hier meinst du denk ich mal. Ist sicher von Vorteil, damit man sich besser in fremden Code zurechtfindet.

Danke für das Posting,
Florian

[wicht]

SubVersion ist eigentlich pflicht.
Als Alternativen zu Mantis gibt's noch Redmine und Trac glaube ich. Aber noch nie genutzt, auch wenn Redmine einen guten Eindruck machte. Wir benutzen zur Zeit Sourcesafe (Visual Studio), wollen bald aber auch endlich auf SubVersion umstellen. Projektverwaltung besteht aus einem MediaWiki mit eingebautem 'IssueTracker'. Ist gerade noch erträglich aber meiner Meinung nach nicht so sauber...

[Florian Hämmerle]

Zitat:

Zitat von wicht (Beitrag 1025899)

SubVersion ist eigentlich pflicht.
Als Alternativen zu Mantis gibt's noch Redmine und Trac glaube ich. Aber noch nie genutzt, auch wenn Redmine einen guten Eindruck machte. Wir benutzen zur Zeit Sourcesafe (Visual Studio), wollen bald aber auch endlich auf SubVersion umstellen. Projektverwaltung besteht aus einem MediaWiki mit eingebautem 'IssueTracker'. Ist gerade noch erträglich aber meiner Meinung nach nicht so sauber...

Werd mir Redmine und Trac auch mal anschauen; neben Mantis.
Wiki + IssueTracker wär sicher auch ne Lösung für ein kleines Team. Werd mich in die Richtung auch mal erkundigen.
Danke für Ideen.

Grüße,
Florian

[Matze]

Ich habe gehört, dass Git sehr gut sein soll. Getestet habe ich es jedoch nicht.

[Florian Hämmerle]

Zitat:

Zitat von Matze (Beitrag 1025921)

Ich habe gehört, dass Git sehr gut sein soll. Getestet habe ich es jedoch nicht.

Kommt auch sofort auf die Liste der Dinge, die ich mir mal näher ansehen muss :)

Danke für die Info,

Florian

[Florian Hämmerle]

Redmine ist mal in RubyOnRails geschrieben. Kann ich nichts mit anfangen. Trotzdem Danke für den Tipp.
Trac ist ne "GUI" für Subversion.
Gibt eben nicht viele Freehoster, die Subversion anbieten und man Kontrolle darüber hat.
Hoster wie Google-Code und SourceForge sind ja soviel ich weiß so aufgebaut, dass jeder den Source ansehen kann und runterladen, etc. Nur die Bearbeitung ist auf die Teammitglieder beschränkt.

Werd mal weitersuchen, ob ich noch was finde wo nicht so overloaded ist.

Ich meld mich, wenn ich ne Lösung gefunden habe.

Schöne Grüße,
Florian

[Matze]

Git ist auch nichts?

[Khabarakh]

Ein kostenloser Anbieter von privaten Repositories ist auch ein bisschen viel verlangt...

PS: Git Git Git :D

[H4ndy]

BitBucket.org bietet in der kostenlosen Variante auch ein privates Repo an, bei den Bezahlpaketen kann man beliebig viele anlegen.
Laueft allerdings mit Mercurial (hg) als Quellcodeverwaltung (funktioniert aehnlich wie Git) und bietet direkt ein Wiki und nen Issuetracker.

Ich nutze privat BitBucket und TortoiseHG, reicht (Link zu meinem Repo, TorsoiseHG).

Auf Arbeit (12 Entwickler) nutzen wir SVN (Subversion) mit Redmine als Weboberflaeche (sehr maechtig in Sachen Issue-Tracking, da landen auch alle Support-Tickets drin). Redmine bietet auch ein Zeitmanagement und eine Roadmap. Auf den PCs wird TortoiseSVN mit dem Redmine-Issues-Plugin als Client benutzt. TortoiseSVN hat auch ein Delphi-Plugin. Wir haben uns fuer SVN entschieden, da das wie Microsoft Visual Sourcesafe das Locking ("auschecken") von Dateien erlaubt, was Merging auf ein Minimum reduziert (und damit Fehler vermeidet). Als fuer Diffs und Merges nutzen wir WinMerge, dass kann sich waehrend der Installation automatisch in TortoiseSVN eintragen.

[DenSchub]

Es sei zu erwähnen, das trac auch git unterstützt. So mache ich das immer und meiner Meinung mit das Beste und einfachste.
Und mit TortoiseGit vollendest du dein Management. :)

[mjustin]

Zitat:

Zitat von Khabarakh (Beitrag 1026141)

Ein kostenloser Anbieter von privaten Repositories ist auch ein bisschen viel verlangt...

Für Subversion und Git ist da zum Beispiel

http://www.projectlocker.com/

"5 Users, 500 MB, unlimited projects, FREE"

[Florian Hämmerle]

Hallo!

@Matze: Git hab ich mir noch nicht näher angeschaut
@mjustin: Werd mir das Angebot der verlinkten Seite mal anschauen. Sonst werd ich einen der Forge-Systeme verwenden (Sourceforge, Codeplexx, ...)

Ich meld mich, wenn ich die für mich optimale Lösung gefunden habe.
Issue-Tracker hab ich gestern Abend noch angefangen in PHP selbst zu schreiben. Falls der was wird werd ich ihn mal ins Projekte-Forum schmeißen.

Schöne Grüße, und danke an alle Antworten,
Florian

[PhilmacFLy]

Zitat:

Zitat von Matze (Beitrag 1025921)

Ich habe gehört, dass Git sehr gut sein soll. Getestet habe ich es jedoch nicht.

Git > Subversion

Hier mal die Gründe dafür: http://whygitisbetterthanx.com/

Ich muss sagen ich benutze selber git im kommerziellen Einsatz und es ist sehr gut für die Arbeit im Team geeignet.

Für Private Opensource Sachen würd ich github verwenden, oder einen eigenen Git Server auf einem linux server erstellen.

[Namenloser]

Ich habe mich gestern u.a. wegen dieses Threads auch mal etwas genauer über Git informiert und bin auf diese Präsentation von Linus Torvalds von 2007 gestoßen. Ist auf jedenfall sehenswert. Ich bin derzeit ernsthaft am überlegen, auf Git umzusteigen (von SVN).

[s.h.a.r.k]

Hier noch ein wenig Werbung von mir bzgl Git :mrgreen: Würde es auf jeden Fall jedem empfehlen, zumal Projectlocker SVN und Git unterstützt, samt Trac und was weiß ich noch alles. Und dabei muss das Project nicht mal Open Source sein. Ein Blick darauf lohnt sich auf jeden Fall..

[blackfin]

Ich muss mir das Git auch mal ansehen, so wie hier geschwärmt wird.

Welchen Client würdet ihr denn empfehlen? TortoiseGit? Oder wat janz anderes?

Und noch eine Frage: Einen "nativen" Git-Server ohne Cygwin gibts wohl nicht, der auf nem W2003 Server läuft?

[s.h.a.r.k]

Einen Server brauchst du rein theoretisch gar nicht, wenn du das Repository nicht auf einen Server speichern willst und nur alleine nutzt. Aber ich denke mal, dass das nicht deine Intension ist.

Ich persönlich nutze TortoiseGit, wobei in dem Thread weiter oben eine andere interessante Software vorgestellt wurde.

[Mithrandir]

Hab mir eben mal Linus Vortrag über git angesehen. Klingt interessant. :thumb:

[PhilmacFLy]

Zitat:

Zitat von blackfin (Beitrag 1027358)

Ich muss mir das Git auch mal ansehen, so wie hier geschwärmt wird.

Welchen Client würdet ihr denn empfehlen? TortoiseGit? Oder wat janz anderes?

Und noch eine Frage: Einen "nativen" Git-Server ohne Cygwin gibts wohl nicht, der auf nem W2003 Server läuft?

ne und git + windows is immer eine komisch mischung, das würd ich leiber nicht machen.

ich würd auch tortoise git empfehlen.