# Projektmanagement Software.



## Guest (27. Dez 2007)

Moin,

was setzt ihr so in euren Projekten ein und warum? 
Kennt jemand vielleicht Plugins für Eclipse, die den gesamten Entwicklungsprozess unterstützen? 

Gruß,
Gast


----------



## The_S (27. Dez 2007)

Kommt darauf an

a) was verstehst du unter Projektmanagment
b) kommt darauf an wie umfangreich das Projekt ist

Benötigst du nur sowas wie UML-Diagramme und ähnliches, oder soll es schon noch ne Ecke komplexer sein!?


----------



## Guest (27. Dez 2007)

Hobbit_Im_Blutrausch hat gesagt.:
			
		

> Benötigst du nur sowas wie UML-Diagramme und ähnliches, oder soll es schon noch ne Ecke komplexer sein!?


Zwei Ecken komplexer.  

Was mich an meinem bisherigen Workflow stört, ist der Mix aus Anwendungen, die da zum Einsatz kommen, um die
verschiedenen Artifakte eines Projekts zu erstellen/verwalten.

- Verwaltung der Kundenkontakte/Projekte/Projektartifakte in einer Datenbank (Marke Eigenbau, war ein Kundenprojekt)
- Jegliche Dokumente (Requirements, Checklisten, TODO-Listen, Projektdoku etc.) mit Word/Excel bzw. seit kurzem 
immer mit Writer/Calc (Open Office)
- Der Modellierungspart (UML etc.) wirder mit einem anderen (z.Z. wieder Magicdraw, früher Visio und TogetherJ)
- usw.

Es sind irgendwie zu viele Anwendungen, die nicht wirlich einen sauberen Arbeitsfluss ermöglichen.  ???:L 

Wie geht Ihr damit um?


----------



## Guest (27. Dez 2007)

Ätch, Artefakte, nicht Artifakte. :autsch: das sind die Nachwirkungen der leckeren Weihnachtsplätzchen, die ich gefuttert habe.


----------



## Wildcard (27. Dez 2007)

OpenOffice ließe sich zB einfach in Eclipse integrieren (Stichwort NOA4e). UML kannst du mir Eclipse sowieso gut abdecken. Ein nettes Projektmanagement Plugin ist mir jedoch leider nicht bekannt (würde mich auch interessieren).
Das Eclipse Communication Framework bzw. das Corona Projekt könnten in Zukunft allerdings den Teamworkflow deutlich komfortabler gestallten, leider steht man hier zZ aber noch am Anfang.


----------



## kama (27. Dez 2007)

Hallo,



			
				Gast hat gesagt.:
			
		

> - Verwaltung der Kundenkontakte/Projekte/Projektartifakte in einer Datenbank (Marke Eigenbau, war ein Kundenprojekt)


Kundenkontakte sollten in einem CRM liegen, Projekte und Projektartefakte in einem Versionierungstool....
dazu gehören auch:


			
				Gast hat gesagt.:
			
		

> - Jegliche Dokumente (Requirements, Checklisten, TODO-Listen, Projektdoku etc.) mit Word/Excel bzw. seit kurzem
> immer mit Writer/Calc (Open Office)
> - Der Modellierungspart (UML etc.) wirder mit einem anderen (z.Z. wieder Magicdraw, früher Visio und TogetherJ)
> - usw.



Das Ganze hat recht wenig mit Projektmanagement als mehr mit dem Thema: Software Entwicklungs Prozess zu tun.

Zum Einsatz von Tools wäre z.B. als Tracking Tool zu nennen: trac, Integration in Eclipse per Mylyn (Buckminster), 
oder Kommerzielle Tools z.B. JIRA oder Polarion (mehr ALM)...oder oder...

Versionierungstool z.B. Subversion oder Kommerziell z.B. ClearCase, ....
dazu gehört dann auch ein Software Konfigurationsmanagement,....(Branchings Strategien in Abhängigkeit des Release-Managementes).

Build-Management (Build-Server, Continious Integration...)...Release-Management, Test-Management....
Dabei spielt Continious Integration wieder in Richtung der Software Entwicklung (Unit-Tests etc.).


Dabei kommt es immer auf Deine Anforderungen an, sprich was möchtest bzw. mußt Du machen....

MfG
Karl Heinz Marbaise


----------



## Guest (28. Dez 2007)

Es geht mir hauptsächlich darum, meine Vorgehensweise zu verbessern/optimieren. Für jedes Projekt lege ich eine 
Verzeichnisstruktur an, wo alle projektrelevanten Dokumente abgelegt werden. Damit meine ich u.a. Projektauftrag, 
Kundendaten/Kontakte, Pflichtenheft/Lastenheft, Anforderungslisten, Meetingprotokolle, Zeitplanung/Termine/
Status(berichte), Rechnungen etc.
Zur Zeit ist es eher ein organisiertes Chaos.  Hat zwar bisher immer gut funktioniert, irgendwie bin ich aber nicht 
ganz zufrieden damit und habe den Eindruck, dass es Tool-unterstützt um einiges effizienter gehen könnte.
Es geht ein Haufen Zeit für die Pflege der Dokument drauf, obwohl ein großer Teil davon reine Routine ist.

@Wildcard
NOA4e scheint ein nettes Ding zu sein. Danke für den Tipp. Was da z.Z. alles im Kükenstadium bei Eclipse läuft, klingt
sowieso vielversprechend. 

@kama
Versionskontrolle ist selbstverständlich. Ich setze Subversion ein. Continious Integration oder Mylyn-ähnliche Trackingtools 
sind eher uninteressant für mich. Es geht hier nicht um größere Teamprojekte, sondern um die übliche One-Man-Show, 
die man als Freelancer so zu bewältigen hat. Es variiert von ganz kleinen, bis hin zu mittelgroßen Projekten.

Daher die Frage an die "Alleinunterhalter" hier. Wie organisiert ihr eure Arbeit? Womit arbeitet ihr (welche Anwendungen)?


----------



## kama (28. Dez 2007)

Hallo,



			
				Anonymous hat gesagt.:
			
		

> Es geht mir hauptsächlich darum, meine Vorgehensweise zu verbessern/optimieren. Für jedes Projekt lege ich eine
> Verzeichnisstruktur an, wo alle projektrelevanten Dokumente abgelegt werden. Damit meine ich u.a. Projektauftrag,
> Kundendaten/Kontakte, Pflichtenheft/Lastenheft, Anforderungslisten, Meetingprotokolle, Zeitplanung/Termine/
> Status(berichte), Rechnungen etc.
> ...


Da war ja mein Vorschlag eben Tracking Tools o.ä. zu nutzen, anstatt große Dokumente zu Pflegen...
Außer beim Pflichtenheft, dass ja Teil des Projekt-Vertrages ist....



			
				Anonymous hat gesagt.:
			
		

> @kama
> Versionskontrolle ist selbstverständlich. Ich setze Subversion ein.


Sehr gut. Aber die Aussage "ist selbstverständlich" habe ich in der Zwischenzeit die Erfahrung gemacht, dass das alles andere als Selbstverständlich ist....aber wenn es bei Dir so ist umso besser.
Abgesehen davon, hast Du es etwas anders beschrieben...



			
				Anonymous hat gesagt.:
			
		

> Continious Integration oder Mylyn-ähnliche Trackingtools
> sind eher uninteressant für mich. Es geht hier nicht um größere Teamprojekte, sondern um die übliche One-Man-Show,
> die man als Freelancer so zu bewältigen hat. Es variiert von ganz kleinen, bis hin zu mittelgroßen Projekten.


Ein Continious Integration Prozess und/oder Build-Server oder Tracking Tools haben nichts damit zu tun, wie groß ein Projekt ist....das bringt auch Vorteile für die One-Man-Show....Beim CI kann man das ja im Rahmen einer OMS (One-Man-Show) auf das laufen lassen der Unit Tests reduzieren, dass aber auch sehr viel hilft. Vor allem im Bereich Refactoring etc.



			
				Anonymous hat gesagt.:
			
		

> Daher die Frage an die "Alleinunterhalter" hier. Wie organisiert ihr eure Arbeit? Womit arbeitet ihr (welche Anwendungen)?


Wie vorher schon genannt. Derzeit setze ich trac als Tracking Tool ein. Als Dokumentationstool, auch in Richtung des Kunden und damit organisiere ich auch meine Arbeit. Eben per Tickets...

Weiterhin definiere ich darüber mein Release Management und mithilfe eines Build-Serves (Continuum) erzeuge ich meine Releases bzw. läuft daräuber auch mein Continious Integration....Unit Tests etc. Derzeit teste ich die Mylyn Integration in Eclipse....aber bei trac bin ich noch nicht richtig zu frieden....

Die Aufwandserfassung ist hier noch ein Thema, dass ich derzeit versuche im Rahmen mit trac zu bekommen.....


----------



## AlArenal (28. Dez 2007)

Da hab ich die passende Literaturempfehlung.


----------



## Guest (28. Dez 2007)

kama hat gesagt.:
			
		

> Da war ja mein Vorschlag eben Tracking Tools o.ä. zu nutzen, anstatt große Dokumente zu Pflegen...
> Außer beim Pflichtenheft, dass ja Teil des Projekt-Vertrages ist....


Das ist ja der Punkt. Da mal ein Pflichtenheft, da paar Dokumente vom Kunden, paar Meetingprotokolle usw.
Ein Haufen Dokumente, die verwaltet werden müssen. Die Erstellung und Pflege der Dokumente ist leider eine
zeitraubende, aber notwendige Handarbeit. Wer schon mal ohne Pflichtenheft oder wie auch immer geartete
Umschreibung des Leistungsumfangs eines Projekts gearbeitet hat, weiss warum.
Optimal stelle ich es mir so vor, dass die wichtigsten Dokumente in einer speziellen Anwendung verfasst
werden, die daraus dann die endgültigen Dokumente generiert.



			
				kama hat gesagt.:
			
		

> Sehr gut. Aber die Aussage "ist selbstverständlich" habe ich in der Zwischenzeit die Erfahrung gemacht, dass das alles andere
> als Selbstverständlich ist....aber wenn es bei Dir so ist umso besser.
> Abgesehen davon, hast Du es etwas anders beschrieben...


Die ganzen Dokumente sind in SVN, die Struktur (was, wo, wann) in einer Datenbank. SVN ist allein schon für's
Releasemanagement unerlässlich. Wie auch immer, ich stehe auf die grünen SVN-Icons in Eclipse. 



			
				kama hat gesagt.:
			
		

> Ein Continious Integration Prozess und/oder Build-Server oder Tracking Tools haben nichts damit zu tun, wie groß
> ein Projekt ist....das bringt auch Vorteile für die One-Man-Show....Beim CI kann man das ja im Rahmen einer OMS
> (One-Man-Show) auf das laufen lassen der Unit Tests reduzieren, dass aber auch sehr viel hilft. Vor allem im Bereich
> Refactoring etc.


JUnit-Tests habe ich in jedem Projekt drin (allerdings nix mit 100% test coverage) und kann sie jederzeit laufen lassen.
Da sehe ich keinen Bedarf an CI. JUnit-Tests, Metrics, Checkstyle, Profiling etc. sind super mit Ant abgedeckt.
Refactoring geht auch direkt in Eclipse. In diesem Bereich läuft bei mir alles einwandfrei. Da sehe ich z.Z. kaum
Verbesserungspotential.



			
				kama hat gesagt.:
			
		

> Wie vorher schon genannt. Derzeit setze ich trac als Tracking Tool ein. Als Dokumentationstool, auch in Richtung
> des Kunden und damit organisiere ich auch meine Arbeit. Eben per Tickets...


Ich stelle es mir ziemlich schwierig vor, dem Kunden zu verticken, dass er ein bestimmtes Tracking Tool einsetzen soll,
um seine Anforderungen/Änderungswünsche erfassen zu können oder Bugs zu melden. Oder habe ich dich missverstanden und
du setzt es nur für dich ein? Oft sind auch die Paranoiker bei den Kunden das Problem. Vor allem bei grösseren Kunden
wie bei den Telekomikern gibt es Richtlinien, auf welche Systeme zugegriffen werden kann/darf oder weleche
Software an einem Arbeitsplatz zulässig ist.
Ein anderes Problem ist, dass man u.U. die Ansprechpartner zuerst schulen müsste, damit sie mit dem, ihnen unbekannten,
Werkzeug umgehen können. Die Gespräche darüber, wer die Kosten dafür übernimmt, stelle ich mir ziemlich uncool vor.

Den anderen Weg, dass ich mich an die Software des Kunden anpasse, passt wieder mir nicht so ganz, daher der Standardweg
über diverse Dokumente, die eine, mit dem Kunden vereinbarte Struktur haben.



			
				kama hat gesagt.:
			
		

> Weiterhin definiere ich darüber mein Release Management und mithilfe eines Build-Serves (Continuum) erzeuge ich meine Releases
> bzw. läuft daräuber auch mein Continious Integration....Unit Tests etc.


OK, Build-Server brauche ich nicht. Ich lasse einfach ein Ant-Script laufen und alles ist gebaut, dokummentiert, verpackt
während ich Kafee holen gehe. 



			
				kama hat gesagt.:
			
		

> Derzeit teste ich die Mylyn Integration in Eclipse....aber bei trac bin ich noch nicht richtig zu frieden....


Das erste, was ich in Eclipse gemacht habe, war, Mylyn zu deaktivieren. Ich kann mich damit irgendwie nicht anfreunden.



			
				kama hat gesagt.:
			
		

> Die Aufwandserfassung ist hier noch ein Thema, dass ich derzeit versuche im Rahmen mit trac zu bekommen.....


Das habe ich bisher immer in Excel/Calc gemacht. Was fehlt, ist die Möglichkeit vernünftige Statistiken daraus zu erstellen,
um aus den Erfahrungswerten auch in künftigen Projekten zu profitieren. Da muss ich mich grösstenteils auf die eigene Erinnerung
verlassen. Das ist wieder so ein Bereich, der automatisiert werden könnte.

Ich bin gestern auf das hier gestossen Project Cards. Es macht einen guten Eindruck und kostet fast nix.





			
				AlArenal hat gesagt.:
			
		

> Da hab ich die passende Literaturempfehlung.


Ich auch. Siehe hier  (Die Leseprobe hier macht auf mich keinen guten Eindruck.)


----------



## MiMij (28. Dez 2007)

@gast
das mti dem scheissprojekt ist mal richtig genial


----------



## Wildcard (28. Dez 2007)

Anonymous hat gesagt.:
			
		

> @Wildcard
> NOA4e scheint ein nettes Ding zu sein. Danke für den Tipp. Was da z.Z. alles im Kükenstadium bei Eclipse läuft, klingt
> sowieso vielversprechend.


Ehrlich gesagt ist NOA4e nur ein kleiner 'Auswuchs' der NOA API. OpenOffice ist dank der Java API derart trivial in Eclipse zu integrieren, das ich NOA4e wohl innerhalb von 2-3 Tagen auch selbst schreiben könnte. 
Kann man also trotz 'Kückenstadium' getrost einsetzen  :wink:


----------

