dezwo hat gesagt.:
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.
Wie gesagt, bei privat Projekten kommt es letztendlich darauf an Spass an der Sache zu haben. Wenn mann XP nutzt, und einem das Spass bereitet dann ist das
natürlich eine gute Sache.
dezwo hat gesagt.:
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.
Da gehe ich ähnlich vor. Nur treibe ich das teilweise ins Extreme. Meine Programme sind letztendlich sehr Komponentenorientiert.
Sprich:
Ich programmiere Standalone Applikationen der gewünschten Funktionen und
arbeite diese durch refactoring zu weiterverwendbare Komponenten um.
Diese werden dann letztendlich Baukastenartig zur Gesammtapplikation
zusammengesteckt.
Slizzzer hat gesagt.:
Wenn Du mit Qualitätssicherung sowas wie DIN 9001 meinst, ja das ist ohnehin nur auf dem Papier.
Nein mit Qualitätssicherrung meinte ich Release Cyclen, Beta & Alpha Phasen und ähnliches. Was in in DIN 9001 steht weiss ich nicht.
OpenSource aber hat ganz anderes Releasae Verständniss als Closed Source. So wird bei OpenSource viel und oft released. Zudem wird zwischen stable und produktiveinsatz und Releases unterschieden. So z.b FreeBSD 5.2 frisch released. Als FreeBSD stable wird aber noch 4.9 bezeichnet.
Das Releases meist erst nach einiger Zeit und patches wirklich stable sind wird bei Closed Source verschwiegen (muss verkauft werden).
methodus hat gesagt.:
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!
Das kommt wiederrum darauf an ob es sich um ein privat Projekt handelt oder aber kommerzielles Projekt.
Bei privaten Projekten verzichte ich darauf, weil ich das schreiben von Pflichtenheften nervig finde, und ich keine Lust habe damit meine Freizeit zu verbringen, reicht schon das ich beruflich und privat programmiere und viele anderen aktivitäten leiden müssen
