Empfehungen Buch zum Thema Projektplanung

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
zero-one
User
Beiträge: 58
Registriert: Dienstag 20. Mai 2008, 20:52

Samstag 24. Mai 2008, 16:02

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

Samstag 24. Mai 2008, 16:18

Hm "Lehrbuch der Softwaretechnik" von Balzert. :twisted: Da wechselst Du dann von "gefrickel" zu "overplanned".
zero-one
User
Beiträge: 58
Registriert: Dienstag 20. Mai 2008, 20:52

Samstag 24. Mai 2008, 16:30

is das jetzt ernsthaft zu empfehlen? oder war das ironisch gemeint ... kanns grad ned aus deinem posting rauslesen ^^
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5554
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Telfs (Tirol)
Kontaktdaten:

Samstag 24. Mai 2008, 17:07

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
:-)
[url]http://halvar.at[/url] | [url=http://halvar.at/elektronik/kleiner_bascom_avr_kurs/]Kleiner Bascom AVR Kurs[/url]
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Sonntag 25. Mai 2008, 08:48

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

Sonntag 25. Mai 2008, 10:24

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
User
Beiträge: 58
Registriert: Dienstag 20. Mai 2008, 20:52

Montag 2. Juni 2008, 09:04

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

Montag 2. Juni 2008, 10:01

gerold hat geschrieben: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
User
Beiträge: 58
Registriert: Dienstag 20. Mai 2008, 20:52

Montag 2. Juni 2008, 13:07

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

Montag 2. Juni 2008, 13:44

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
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 2. Juni 2008, 13:54

lunar hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
zero-one
User
Beiträge: 58
Registriert: Dienstag 20. Mai 2008, 20:52

Montag 2. Juni 2008, 14:42

und jetzt fuer dumme ... was is DVCS?
Panke
User
Beiträge: 185
Registriert: Sonntag 18. März 2007, 19:26

Montag 2. Juni 2008, 14:46

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.
Antworten