Softwareentwicklungsprozess
-
Hallo,
programmiert denn irgendwer nach so einem Software entwicklungsprozess ?
Erst macht man die Analyse,Klassen werden definiert, und dann programmiert man und am Ende wird getestet. Oder macht das jemand anders ?
--ursprünglich von Blurry33
-
Am besten gar nie mit dem Zustand der "vollständigen Information" beginnen.
Stichwörter:
- Iterativ und inkrementell
- V-Modell
- Agile Software EntwicklungZusätzlich nie irgendwelche Dogmen einführen, sondern den Prozess dem Unternehmen und dem Projekt entsprechend anpassen.
Gibt durchaus Unternehmen, welche damit ganz gute Ergebnisse erzielen konnten. Ich persönlich fahre sowas auch für grössere private Projekte. Bei mir hat es definitiv auch zu einer Qualitätssteigerung geführt.
Ein Entwicklungsprozess sollte jedenfalls ganz sicher jeder haben. Egal wie der Prozess am Ende aussieht, er muss einfach für das Projekt und die Person, bzw. das Unternehmen, stimmen. Wild drauf losprogrammieren führt mit sehr hoher Sicherheit zur Katastrophe.
Grüssli
-
Scrum ist ein ganz gutes, iteratives Modell. Da werden erst mal die Kundenanforderungen ermittelt und die mit der größten Priorität für die nächste Iteration (3-30 Tage) geplant und umgesetzt. Nach jeder Iteration folgt ein Release, d. h. der Kunde setzt dann die Software ein und gibt möglichst schnell Feedback, um dann für die nächste Iteration evtl. Änderungen weiterzugeben.
-
Bei uns ist es so:
Der Chef rotzt mündlich oder in 3 Zeilen E-Mail eine neue Anforderung raus. Anschließend beschäftigt man sich etwas mit der Problematik, um eine grobe Vorstellung davon zu bekommen, wo die Probleme liegen und was getan werden müsste.
Dann geht das Ganze durch mehrere Meetings, in denen man aneinander vorbeispricht und eine Menge Zeit verplempert, weil alle Absprachen mündlich und relativ unkonkret erfolgen. Man versucht jeweils die Gedanken des anderen zu lesen.
Am Ende hat man meistens einen Kompromiss ausprogrammiert, welcher die Anforderung des Kunden mehr oder weniger erfüllt. Intern erfolgten Planung und Ausführung nach dem Prinzip: Es gibt die Quaität, die zu einer Deadline zu realisieren ist.
Ich würde das ganze als Ultra-Agil bezeichnen (
).Würden ausgearbeitete Konzepte helfen? Sicherlich. Das ist aber Sache des Produktmanagements und der Softwarearchitekten. Es hat sich allerdings gezeigt, dass Anforderungen sich schneller ändern als man "Meeting" sagen kann, und die Entwicklung eines Konzeptpapers dauert länger als eine Prototyp Implementierung, die kontinuierlich verschlimmbessert wird. In den meisten Fällen wird der Prototyp zur Release-Version.
Ich bin daher vollkommen deillusioniert, was diese ultra-ausgefeilten Entwicklungsprozesse angeht. Wenigstens in den kleineren bis mittleren Software Klitschen wird m.m.n. weder großartig geplant noch "konzeptioniert". Wichtig ist, dass man den Schrott, der für Zeitpunkt XYZ schon verkauft wurde, rechtzeitig hingedengelt bekommt. Ich musste mir den Perfektionismus daher gründlich abgewöhnen (Was gut ist).
Ist das jetzt schlimm? Nö. Es ist nur meilenweit von dem entfernt, was man gemeinhin in der schönen Theorie-Welt der Hochschulen und der Ausbildung so lernt. In wirklich großen Unternehmen kann so etwas wie Softwarearchitektur und -Planung sogar klappen, da machen ganze Abteilungen aber auch nichts anderes und programmieren tuts der Chinese. Der macht sich dann auch keinen Kopf, wie der Kunde darauf reagiert.
Würde ich so planen und programmieren wie privat, würde ich längst nicht mehr arbeiten dürfen, da ich viel zu uneffektiv wäre.
-
kumpel von mir arbeitet fuer eine firma die an ruestung und raumfahrt programmiert, da wird die meiste zeit ueber was anderes gemacht als zu implementieren. es gibt viele normen und wenn man aufsteigen will, muss man allerlei zertificates sammeln.
gebe aber auch mit der gewerkschaft stress falls man motiviert ist und mehr als 8h arbeiten wollen wuerde.meine welt waere genau das gegenteil, etwa so:
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
-
Steffo schrieb:
Scrum ist ein ganz gutes, iteratives Modell. Da werden erst mal die Kundenanforderungen ermittelt und die mit der größten Priorität für die nächste Iteration (3-30 Tage) geplant und umgesetzt. Nach jeder Iteration folgt ein Release, d. h. der Kunde setzt dann die Software ein und gibt möglichst schnell Feedback, um dann für die nächste Iteration evtl. Änderungen weiterzugeben.
SCRUM setzt aber voraus, daß der Kunde das Modell versteht. Das ist ein großer Knackpunkt an SCRUM!
-
rapso schrieb:
meine welt waere genau das gegenteil, etwa so:
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdfHab noch nicht alles gelesen, erinnert mich aber sehr an SCRUM. SCRUM ist eine typischer Vertreter des Agilen Manifests.
Im Bereich der Rüstung oder von Behörden findet man die agile Softwareentwicklung meistens gar nicht, weil hier alles ganz genau festgehalten werden muss, wer was wo, wie und wann nach welchen Kriterien und Entscheidungen gemacht hat und wer es gebilligt, authorisiert und genehmigt hat, usw. usf. Siehe z.B. RUP oder HERMES.
@Marc++us,
Kommt sehr stark darauf an, wer der Kunde ist und wie das Verhältnis zu diesem aussieht.Grüssli
-
Stellen Firmen eigentlich die Analyse, also wenn der Firmenkunde gefragt wird, was er will, was er braucht und wie das bei dessen Firma momentan abläuft in Rechnung?
Immerhin muss der Informatiker, der den IST-Zustand bei der Firma des Kunden ermitteln soll, damit überhaupt eine Umsetzung einer Software möglich wird, ja bezahlt werden.
Werden diese Kosten dann aufgeschlüsselt, oder fallen die dann einfach Pauschal unter die gesamten Projektkosten?
-
Da gibt es alle Varianten von
"100% in Rechnung gestellt" bis "0% in Rechnung gestellt"
In größeren Projekten, wo sich der Lieferant evtl. in einem Ausschreibungsverfahren bewirbt, muß der Lieferant die Voranalyse sicherlich zu 100% selbst tragen. Das muß man dann in die Projektkosten packen.
[Das ist ja der Grund auch für hohe Tagessätze - wenn nachher ein Programmierer einen Tagessatz von 800,- EUR hat, sind da auch einige Euro von Projekten enthalten, wo jemand eine Voranalyse gemacht hat, und wo man den Auftrag nicht bekam. "Unternehmerisches Risiko"]
