Empfehungen Buch zum Thema Projektplanung

[zero-one]

Hi,
kann jemand von euch ein Buch zum Thema Projektplanung, Umsetzung und Entwurf empfehlen.

Bei mir ist es oft so das ich eine Idee für ein Projekt hab, doch dann nicht weiss wie und wo ich Anfangen soll, also Programmier ich meistens einfach mal drauf los. Irgendwie hat das für mich immer so nen frickel Beigeschmack ich würde gerne lernen wie man Systematisch an sowas rangeht.
Ich hoffe ihr Versteht was ich meine... danke

[BlackJack]

Hm "Lehrbuch der Softwaretechnik" von Balzert. Da wechselst Du dann von "gefrickel" zu "overplanned".

[zero-one]

is das jetzt ernsthaft zu empfehlen? oder war das ironisch gemeint ... kanns grad ned aus deinem posting rauslesen ^^

[gerold]

Hallo zero-one!

Vielleicht genügt es dir ja, wenn du dir die Gedanken zu einem neuen Projekt detailliert aufschreibst.

Diese Gedanken kannst du dann, bevor du anfängst zu programmieren, in die richtige Reihenfolge setzen und laufend ergänzen und anpassen. So hast du, wenn du einmal ein paar Wochen aussetzt, trotzdem noch einen Plan davon was gemacht werden muss.

Ich nehme dazu meist eine einfache Textdatei.

Code: Alles auswählen

Was soll das Programm alles können?
===================================

- Kundenverwaltung mit GUI, die primär unter Windows läuft.
  Es soll aber kein Problem sein, diese auch nach Linux zu
  portieren.

- Anzeige der Kunden in einer Tabelle. 

- Schnellsuche

- ...


Bereits erledigt
================

- ...


ToDo
====

- Datenbank planen

- Datenbankschnittstelle grob skizzieren

- Globale Programmoberfläche zeichnen (Papier)

- Ordnerstruktur erstellen

    - *help*-Ordner nicht vergessen

    - Globale Module kommen in den *lib*-Ordner

- ...

Diese Textdatei kann ich dann im Laufe der Programmierung um weitere Details erweitern. Außderdem wandern die erledigten Punkte in den Bereich *Erledigt*. So hat man am Ende des Tages auch einen Überblick, was erledigt wurde und kann sich schon während der Programmierung ein Bild davon machen, wie lange man noch brauchen wird.

Wenn mehrere Leute im Spiel sind. Ob das nun noch ein Programmierer oder jemand ist, der das Programm testet oder jemand vom Support. Dann würde ich zu *Trac* und *Subversion* greifen. Im Trac hast du ein Wiki in dem du dir alles aufschreiben kannst. Was ich gerne mache: Ich beauftrage andere, mir Informationen zusammenzusuchen und mir ins Trac-Wiki zu schreiben. Arbeitsteilung vom Feinsten.

Auch wenn du alleine bist oder nur sehr wenige am Projekt mitarbeiten -- Trac bietet ein paar Vorteile, die dir die Arbeit an einem Projekt sehr erleichtern können. Du kannst dir z.B. eine Roadmap zurechtlegen. Dann kannst du einzelne (kleine) Arbeitsschritte als Tickets hinterlegen, die du dann auch noch an einen Milestone (Programmversion) binden kannst. So kannst du über Tickets genau festlegen, welche Arbeiten bis zu welcher Programmversion fertig sein sollen. Diese Tickets kannst du mit Prioritäten markieren. So weißt du immer, welches die nächst wichtige Arbeit ist.

Außerdem können andere Leute (Support, Qualitätstest,...) Tickets mit Fehlerberichten anlegen. So geht nichts verloren.

Das ist vielleicht einfacher und produktiver als sich an irgendeinen großmotzigen Projektplan zu halten.

mfg
Gerold

[sma]

The Pragmatic Programmer passt eigentlich immer als Empfehlung, IMHO auch hier, selbst wenn es sich bei dem Buch nicht um einen Leitfaden zur Projektleitung und -durchführung handelt. Dazu gibt es diverse Methoden, wobei mir eigentlich Scrum sehr gut gefällt, welches agil und leichtgewichtig ist, nicht jedoch so extrem wie XP, wo die Projektplanung unter dem Begriff "Planspiel" (planning game) zusammengefasst ist. Ich kenne da allerdings nur die erste Auflage und habe mir sagen lassen, Beck hat später seinen extremen Standpunkt etwas aufgeweicht. Ein Blick auf RUP kann auch nicht schaden, ich glaube aber, das es besseres gibt.

Hm... das jetzt nochmal durchlesend habe ich das Gefühl, ein bisschen an der Frage von zero-one vorbei zu antworten. Egal ;)

Stefan

[BlackJack]

Aus der "pragmatischen" Buchreihe passt vielleicht "Ship it!" besser zur Ausgangsfrage, wobei ich den "Pragmatischen Programmierer" auf jeden Fall auch als Grundlektüre empfehlen würde.

"Ship It!" konzentriert sich laut Klappentext auf die Fertigstellung und Auslieferung von Projekten, während "Der Pragmatische Programmierer" das zwar auch anschneidet, aber auch viel "kleineres" und grundlegenderes enthält.

[zero-one]

habe mir jetzt das buch "Ship it!" zugelegt, es ist wirklich gut .. nur leider geht es in dem Buch eher um Projectmanagement als um Projektplanung...

[lunar]

Wenn mehrere Leute im Spiel sind. Ob das nun noch ein Programmierer oder jemand ist, der das Programm testet oder jemand vom Support. Dann würde ich zu *Trac* und *Subversion* greifen.

Ich würde ein VCS nicht erst dann einsetzen, wenn mehrere Leute beteiligt sind. Ein VCS sollte von Anfang an dabei sein. Anstelle von SVN würde ich da auch eher dein DVCS nehmen, weil die einfach flexibler und schneller aufzusetzen sind.

Das ist vielleicht einfacher und produktiver als sich an irgendeinen großmotzigen Projektplan zu halten.

Wohl gesprochen ... ein hochtrabener Projektplan führt zu purer Selbstverwaltung und wird eh nie eingehalten, schon gar nicht, wenn man ein Projekt in der Freizeit betreibt

[zero-one]

mir geht es ja in erster linie darum wie man an ein Projekt rangeht... also das Planen des Projektes ganuer der software architektur dieses...

[BlackJack]

Die Planung und der Entwurf sind in der Regel ineinander verzahnt, und da gibt's viele Ansätze und noch mehr Bücher. Ich weiss nicht, ob man da jetzt *ein* gutes Buch empfehlen kann.

[Leonidas]

Ich würde ein VCS nicht erst dann einsetzen, wenn mehrere Leute beteiligt sind. Ein VCS sollte von Anfang an dabei sein. Anstelle von SVN würde ich da auch eher dein DVCS nehmen, weil die einfach flexibler und schneller aufzusetzen sind.

Da stimme ich zu, ich fange jetzt ohne DVCS kaum noch irgendwas an. Repositories sind unglaublich billig und eine komplette History, Branches, Tags, ggf. auch noch Hooks, Annotations sind auch für den einzelnen Entwickler praktisch.

[zero-one]

und jetzt fuer dumme ... was is DVCS?

[Panke]

Verteile Versionskontrolle

Subversion hat einen zentralen Server auf dem ein Repo sitzt, das dann unter Versionskontrolle steht. Bei git hingegen hat jeder sein eigenes gleichberechtigtes Repo.