Organisierte Planung bei Programmen und Projekten

[Nax]

Wir lernen in der Schule wie man auf "professionelle" Art und Weise Projekte plant und dokumentiert etc.

Dabei gibt es schon mehr oder minder genaue Regeln wie das ganze ablaufen muss und wie die einzelnen Dokumente (Projektantrag, das von dir bereits angesprochene Pflichten- & Lastenheft, Agendas und Protokolle, ....) ausschauen sollen.
Allerdings kann ich dir nicht wirklich empfehlen das bei privaten Projekten zu machen. Das ganze ist eigentlich nur fuer professionelle Firmenprojekte in der Wirtschaft gedacht. Bei privaten (OS) Projekten kannst du getrost darauf verzichten und dich stattdessen auf eine moeglichst gute technische Dokumentation konzentrieren.

[Deathball]

Hm, über die Art wie man an ein Projekt heran geht kenn ich eigentlich nur die beiden Tutorials:

Softwareentwicklung 1
Softwareentwicklung 2

hab sie beide allerdings noch nicht durchgelesen, kann also nicht sagen ob sie gut sind...

cya,
Deathball

[derBenny]

Es macht auch noch einen Unterschied, ob du alleine oder in einer Gruppe arbeitest. In letzterem Fall ist das Zeitmanagement etwas komplizierter. Man muss die ganze Geschichte so organisieren, das voneinander zunächst unabhängige Arbeitsschritte parallel erledigt werden.

Außerdem muss man sich in einer Gruppe Meilensteine setzen. Bei einem gewissen Fortschritt des Projekts trifft man sich und diskutiert eventuell aufgetretene Schwierigkeiten oder das weitere Vorgehen.
Dabei sollte man am Anfang ruhig ein paar mehr Meilensteine setzen, da das meist eine sehr kritische Pase ist.

Was das Zeitmanagment angeht hab ich einmal einen guten Tipp gelesen:
Überlege dir in welcher Zeit du sicher bist das Projekt vollenden zu können. Verdoppele diese Zeit und nimm das als realistisches Minimum. Es hilft sicherlich bestimmte Milestones mit bestimmten Daten zu verknüpfen, aber ich glaube für eine realistische Einschätzung des Zeitaufwandes braucht es vor allem viel Erfahrung. Solang man aber keinen Kunden im Nacken sitzen hat, der auf ein bestimmtes Datum pocht, ist es sicher besser lieber ein wenig zuviel Zeit als zuwenig einzuplanen.

...

Oder man macht es wie die Japaner. Wenn die merken, dass die Zeit nicht reicht, dann fragen sie nicht nach einer Verschiebung der Frist, sondern arbeiten eben die Nächte durch ...

[Jesus_666]

Oder man macht es wie die Japaner. Wenn die merken, dass die Zeit nicht reicht, dann fragen sie nicht nach einer Verschiebung der Frist, sondern arbeiten eben die Nächte durch ...

...

Oder man macht es wie Redmond und verschiebt zweimal den Termin, dann entfernt man einfach so lange Features und kürzt die QA-Phase, bis es hinkommt. Den "Nächte durcharbeiten"-Kram macht man parallel. Außerdem stellt man erst noch 1000 Entwickler ein.


Es gibt wirklich keine optimale Lösung. Man kann zwar nach ISO-Standard arbeiten und Kram wie Ist- und Sollanalysen machen, Gantt-Diagramme und Risikotabellen erstellen etc., aber das macht wirklich nur bei größeren kommerziellen Projekten Sinn. Wenn man nur mit zehn Leuten an einer kleinen Anwendung rumbastelt wird der Aufwand für die korrekte Abarbeitung der Vorschriften fast schon größer als der der eigentlichen Entwicklung.

Idealerweise sollte man einfach so viele Informationen erarbeiten, wie jeder Mitarbeiter braucht, um jederzeit über den aktuellen Status und die noch ausstehenden Sachen im Bild zu sein. Außerdem sollte man sich ein Entwicklungsmodell suchen und dementsprechend arbeiten - wenn man agil entwickelt ist der ISO-Standard teilweise eher hinderlich als nützlich, während er bei einem traditionellen Wasserfallmodell praktisch unabdingbar ist.

Absolut extrem wichtig ist die Kommunikation zwischen den Entwicklern. Jeder muß jederzeit im Bild sein, wie es um das Projekt steht und wo noch was getan werden muß. Wenn man einen Spezialisten für ein Thema hat so sollte er den anderen genug davon vermitteln, daß im Notfall jemand für ihn einspringen kann. Und die Leute sollten erreichbar sein. Wenn die Reaktionsgeschwindigkeit des Teams davon beschränkt wird, daß ein Mitglied nur alle drei Tage in die Mailbox schaut dann hat das deutliche Auswirkungen auf die Qualität des Endproduktes.


Die Organisation von Softwareentwicklung ist ein Thema für sich und als solches nicht gerade trivial. Außerdem ist eine der wichtigsten Komponenten Erfahrung - denn ohne selbige kann man bei einigen wichtigen Entscheidungen nur raten (beispielsweise dabei, wie lang die QA-Phase im Vergleich zum Rest der Entwicklung sein sollte).

[Niji-chan]

k, thx @ all.

Ich habe jetzt 2 Bücher von irgend einem Prof. bei meinem Vater entdeckt. Da steht alles drin, was ich sonst noch so wissen muss.

Habe die momentan nicht parat. per Edit werd ich den Titel und ein paar Daten noch schreiben.

lg

EDIT: Lehrbuch der Software-Technik Band 1 und 2, ISBN: 3-8274-0042-2 (Band 1), Spektrum Verlag, von Helmut Balzert