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
Empfehungen Buch zum Thema Projektplanung
Hm "Lehrbuch der Softwaretechnik" von Balzert. Da wechselst Du dann von "gefrickel" zu "overplanned".
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
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.
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
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
- ...
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
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
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
Hm... das jetzt nochmal durchlesend habe ich das Gefühl, ein bisschen an der Frage von zero-one vorbei zu antworten. Egal ;)
Stefan
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.
"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.
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.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.
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 betreibtDas ist vielleicht einfacher und produktiver als sich an irgendeinen großmotzigen Projektplan zu halten.
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.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
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.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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice