Projektplanung, wie?

[Thomas Kuse]

Es gibt da ganz verschiedene Möglichkeiten und Vorgehensweisen (Wasserfall-, Iterativ- und Spiralprinzip) aber letztlich gibt es für Software-Entwicklung keine Formeln durch die das ganze Prinzip geprüft werden kann. Entwicklung von Software basiert auf vielen subjektiven Einflüssen.

Qualitätssicherung wird natürlich auch betrieben, aber meistens erst zum Ende der Entwicklungszeit.

 

[Christian Fein]

Original geschrieben von Slizzzer

Ich denke ein allgemein gehaltener Projektablaufplan sollte zumindest vorhanden sein, der die einzelnen Projektabschnitte beschreibt. Sonst fährt man doch zwangsläufig ins Chaos!
Gerade wenn man im Team arbeiten will/muss ist eine gute Dokumentation wichtig.
Auch eine evtl. Wiederverwendbarkeit von Code, also das Lagern in Datenbanken o. ä. halte ich für wichtig. Was sich bewährt hat und ausgereift ist, braucht ja nicht immer neu "erfunden" zu werden.

Ja es gibt auch Design Patterns und andere Richtlinien. Nur wie gesagt ist vieles sehr theoretisch und spielt seine Stärke erst bei grösseren Teams (ab 6 Mann) eine grössere Rolle.

Zudem gibt es wiederrum Gegenverfahren wie Extreme Programming.

Aber bei Hobby Programmierung kann mann das getrost ignorieren, weil Hobby-Programmierung spass machen soll .

Viel OpenSource Software entstand relativ ungeplant und nach dem Bazzar Prinzip
(siehe The Cathedral and the Bazaar <- kult) http://www.oreilly.com/catalog/cathbazpaper/
Die Entwicklung grosser OpenSource Projekte hat viele Theorien über "Qualitätssicherung" über den Haufen geworfen

 

[Carndret]

Es ist schon erstaunlich, dass es doch viele Leute gibt die ein Pflichtenheft machen. Klar bei manchen ist es nicht nur ein Hobby sondern ihr Job.
Als ich einmal ein Pflichtenheft gemacht hatte (weil ich gelesen hab, dass das toll sei) habe ich gemerkt, dass das nichts wird. Seit dem kritzel ich als erstes ein Mögliches User Interface. Die Grundidee gibts ja sowieso meinst vorher auf einen Schlag. Danach... lange danach überlege ich mir wie ich die Probleme programmiertechnisch lösen könnte.
Sowas wie ein Struktogramm würde ich vorher nie mehr machen, weil ich mich da immer ins Detail verwurschtel und es in der Zeit schon längst fertig sein könnte. In der Schule habe ich diese Dinger immer gemacht nach dem ich fertig war mit dem Programm .
Bei Homepages ist es etwas anders. Da Versuche ich ein ganz grobes Design (auf Papier) zu finden. Wo soll das Menü sein, wo der Text welche Farben etc. Dann wird das Bildbearbeitungsprogramm geladen und los geht's (meistens) mit der Willkommensseite der HP. Die Grafiken nehme ich dann nur noch aus dem Komplettbild raus und verändere es dann noch so das es passt. Manchmal ändert sich das Design natürlich auch noch etwas stärker, aber dann passiert der Rest im Kopf.
Ich habe eher viele kleine Zettel wo Ideen drauf sind. So eine Ordnung tut dem Projekt zwar gut, aber für ein Hobby wäre es mir zu anstrengend.

 

[Slizzzer]

Die Entwicklung grosser OpenSource Projekte hat viele Theorien über "Qualitätssicherung" über den Haufen geworfen

Wenn Du mit Qualitätssicherung sowas wie DIN 9001 meinst, ja das ist ohnehin nur auf dem Papier. Wenn eine Zertifizierungsprüfung vom TÜV ansteht, wird eine Woche vorher alles "einstudiert" und nach der Prüfung wird wieder so gearbeitet, wie es bewährt und effektiv ist .
Ich kenn das, auch aus meinem Fachbereich.

 

[Nils Hitze]

Also ich denke mal Holyfly hat da Recht.

Bei kleinen Projekten, also Hobbyprogrammierung
lohnt es sich einfach nicht erstmal Strukturierung
zu erlernen. Davon ab daß die meisten sich eh
früher oder später eine eigene Art erarbeiten wie
sie Projekte anfangen.

Aber ab 2 Leuten, daß zeigt mir die Erfahrung,
braucht man ein gewisses Mindestmaß an Struktur
und Dokumentation. Sonst passiert es ganz schnell
daß Codes überspeichert werden oder extrem wuchern.

Ich für meinen Teil habe leider nicht den Luxus im
Team zu arbeiten im Moment und meistens garnicht
die Zeit für großartige Organigramme. Also muss
bei mir der Code größtenteils im Kopf entstehen.
Danach auf's Papier skizzieren und dann Klasse für
Klasse, Funktion für Funktion in den PC.

Jona

 

[Wolfsbein]

Original geschrieben von Carndret
Es ist schon erstaunlich, dass es doch viele Leute gibt die ein Pflichtenheft machen. Klar bei manchen ist es nicht nur ein Hobby sondern ihr Job...

Glaub mir du brauchst ein Pflichtenheft, oder zumindest einen haarklein ausformulierten Auftrag. Du kannst dir nicht vorstellen was einem Kunden so allle einfallen kann wenn nicht jedes Detail vorher feststeht.

 

[methodus]

Original geschrieben von Carndret
Es ist schon erstaunlich, dass es doch viele Leute gibt die ein Pflichtenheft machen. Klar bei manchen ist es nicht nur ein Hobby sondern ihr Job.
Als ich einmal ein Pflichtenheft gemacht hatte (weil ich gelesen hab, dass das toll sei) habe ich gemerkt, dass das nichts wird. Seit dem kritzel ich als erstes ein Mögliches User Interface. Die Grundidee gibts ja sowieso meinst vorher auf einen Schlag. Danach... lange danach überlege ich mir wie ich die Probleme programmiertechnisch lösen könnte.
Sowas wie ein Struktogramm würde ich vorher nie mehr machen, weil ich mich da immer ins Detail verwurschtel und es in der Zeit schon längst fertig sein könnte. In der Schule habe ich diese Dinger immer gemacht nach dem ich fertig war mit dem Programm .
Bei Homepages ist es etwas anders. Da Versuche ich ein ganz grobes Design (auf Papier) zu finden. Wo soll das Menü sein, wo der Text welche Farben etc. Dann wird das Bildbearbeitungsprogramm geladen und los geht's (meistens) mit der Willkommensseite der HP. Die Grafiken nehme ich dann nur noch aus dem Komplettbild raus und verändere es dann noch so das es passt. Manchmal ändert sich das Design natürlich auch noch etwas stärker, aber dann passiert der Rest im Kopf.
Ich habe eher viele kleine Zettel wo Ideen drauf sind. So eine Ordnung tut dem Projekt zwar gut, aber für ein Hobby wäre es mir zu anstrengend.

Pflichtenheft ist einfach "pflicht", am ende der planung kommt dir dein kunde daher gedackelt und verlangt dinge, die gar nicht abgemacht waren, lehnst du ab, ist der deal komplett geplatzt, nimmst du an machst du miese! das pflichtenheft gibt dir sicherheit. ich würds nicht missen wollen!

da ich bisher auch noch hobbymäßig den spaß betreibe ist ne formlose einigung auf ein pflichtenheft völlig ausreichend, ich weiß gar nicht ob es irgendwelche normen dafür gibt. das pflichtenheft legt ja nicht hauptsächlich fest wie du ein projekt planst sondern was am ende rausspringen soll, für beide seiten natürlich

und ordnung halten... naja hängt halt von der größe des projektes ab, irgendwann wird das projekt zu groß und man wünscht sich von beginn an alles geordnet und durchplant organisiert zu haben.

 

[Slizzzer]

Pflichtenheft ist einfach "pflicht", am ende der planung kommt dir dein kunde daher gedackelt und verlangt dinge, die gar nicht abgemacht waren, lehnst du ab, ist der deal komplett geplatzt, nimmst du an machst du miese! das pflichtenheft gibt dir sicherheit. ich würds nicht missen wollen!

Stimmt! Ich bin zwar kein Programmierer, aber in meinem Gewerbe gibt es sogenannte Leistungsverzeichnisse. Die haben den Vorteil, dass alles, was nicht darin enthalten ist, extra Geld bringt .
Mein Chef sagt immer: Kein Tag ohne Nachtrag!

 

[dennislassiter]

Ich habe viel geplant.....
Aber letztendlich habe ich immer nur mit spontanen Sachen erfolg gehabt.

 

[dezwo]

Hallo Ihr,

Original geschrieben von Christian Fein
[...]
Zudem gibt es wiederrum Gegenverfahren wie Extreme Programming.

Aber bei Hobby Programmierung kann mann das getrost ignorieren, weil Hobby-Programmierung spass machen soll .
[...]

Es gibt Leute, die würden behaupten, eines der Paradigmen des Extreme Programming ist es, Spaß dabei zu haben. Zumindest aber gibt es "Regeln" um den Frustfaktor zu reduzieren (Project Velocity, keine Überstunden, etc.). Persönlich habe ich recht gute Erfahrungen zumindest mit einzelnen Methoden des Extreme Programmings gemacht und kann nur jedem Empfehlen, es einmal auszuprobieren. Ein guter Einstieg in das Thema sind http://www.extremeprogramming.org und natürlich das Ur-Wiki auf http://c2.com/cgi/wiki.

Zum eigentlichen Thread:
Ich benutze (wenn mögliche) zumindest Story und Task Cards für die Projektspezifikationen, da es mir persönlich leichter fällt, Aufwandsschätzungen und Spezifikationen für einzelne Funktionalitäten abzugeben als das ganze Projekt auf einmal zu überschauen. IMHO hat das auch den Vorteil, daß sich durch die Menge an Prognosen Fehler eher ausgleichen.
Es folgt die Festlegung von Prioritäten und Risiken. Damit ergibt sich eigentlich auch schon die Reihenfolge der Implementierung (der Iterative Ansatz hat den Vorteil, daß schon früh Prototypen entstehen und der Kunde damit schnell auf Fehlentwicklungen reagieren kann).
Für besonders riskante Projektbestandteile (alle, für die gilt: "Habe ich noch nie gemacht und kann mir nur vage vorstellen, wie das geht.") entwickle ich, wenn die Zeit und das Budget es zuläßt, Spikes (Stand-Alone Implementationen der Funktionalität) um die Aufwandsschätzung zu überprüfen (gut gelungene Spikes lassen sich auch in das Projekt übernehmen).
Anschließend beginnt die schrittweise Implementierung der Funktionalitäten anhand der festgelegten Prioritäten.

Pflichtenhefte (insbesondere der Anforderungskatalog) lassen sich mit den Storycards relativ leicht zusammenschreiben, auf UML-Diagramme (vielleicht mit Ausnahme eines Klassendiagramms und in komplizierten Fällen eines Sequenzdiagramms) verzichte ich im Allgemeinen, wenn das Projekt nicht zu groß ist.

Das waren meine 42 Cent, bis dann,
dezwo