Ich hab das ganze hier gelesen und bin froh, dass ein Absehbares Ausarten nicht eingetreten ist

Ich programmiere sehr gerne in Java, nachdem ich es als für mich besser als Delphi befunden habe. Beim Projektmanagement (gerade im Hinblick auf Softwareprojekte) habe ich sehr gute Erfahrungen mit agilen Ansätzen wie SCRUM gemacht. Bei der Programmiermethodik finde ich von allen bisher getesteten incremental&iterative Development auf Basis eines evolutionären Prototypen im Moment am besten.

Ich hau hier grad die Begriffe alle so hintereinander, weil ich momentan genau dies ganze Kram im Theorieteil meiner Bachelorarbeit zu einer Softwarerentwicklung beschreibe. Ich möchte allerdings anmerken, dass ich - obwohl ich mir wirklich viele Ansätze angesehen habe, bevor ich mich entschieden habe - mich bei solchen Entscheidungen sehr schnell umentscheide und von im Nachhinein betrachtet eher nebensächlichen Features beeindrucken lasse.

Ich fänds auch mal gut von euch zu hören, mit welchen Ansätzen im Bereich Projektmanagement, Softwaredevelopment und -weiterentwicklung ihr gute/schlechte Erfahrungen in einem möglichst praktischen Umfeld gemacht hab. Sonst haben wir ja fast wirklich nur diskussionen über die Wahl der Programmiersprache.

@ Thema "Verwendung bestehender Bibliotheken, GC etc": ich benutze seit langer Zeit Java und möcht es nicht missen. Und ich bin auch ein bekennender Freund meiner Meinung nach wirklich guter Frameworks ala Spring.

Ich hab das mal abgetrennt, weil das jetzt schon ne neue Fragestellung ist.

Scrum habe ich noch nicht genutzt, würde ich aber gern mal live ausprobieren...

Unsere Firma ist extrem(!) Prozessgetrieben. Wir lizensieren sogar unsere Prozesse inkl. Schulung und Tools an andere Firmen, daher bin ich eher mit dieser Art des Projektmanagements vertraut. Das hat den vorteil, dass du aus einem Pool an Templates die Dokumente/Methoden/Teilprozesse heraussuchen kannst, die für dein Projekt am passendsten sind.


Für mich privat denke ich ist das Iterative vorgehen ala Bubbles On A Wire funktionieren würde. Ich muss etwas sehen, und wenn es eine GUI Mockup ist, und dann von dem ab weiter arbeiten. Wenn ich nur an den Eingeweiden der App schraube, macht es auf dauer keinen Spass.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich bin bekennender Prozessionshasser. Mich werden z.B. auch keine 10 Pferde in ein Unternehmen bringen, wo man der Herrschaft von EPKs (Ereignisprozessketten) unterliegt. Das, womit SAP sein dickes Geld verdient
Ich hab überhaupt nichts dagegen, wenn Prozesse grundlegend und sinnvoll dokumentiert werden - aber sobald das ganze anfängt in Bürokratie oder massiver Tool-"Unterstützung" auszuarten, bin ich weg
Deswegen ist z.B. auch Siemens für mich ein absolutes No-Go.

Zurück zum Software-Kram... Da code ich einfach vor mich hin. Geplant wird da nicht mehr viel. Swift Steel steht eigentlich schon komplett im Kopf Ich leg' mir aber spaßeshalber so ne Art rote Fäden durch den Code. Sage mir also: Ich will bestimmte zusammenhängende Sachen runtercoden, die dann zusammen abgetestet werden können.

z.B. Grundlegende KI (Wegfindung), Bewegung, Drehung der Schwebepanzer und zeitlicher Verlauf im Spiel. Das brauche ich alles, um nen Panzer von A nach B zu bewegen und daran bau ich grad. Das ist aber auch das Höchstmaß an Prozess... :p

Das ist auch sowas, wo specs hilft. Das motiviert halt auch mehr zu sowas... Test-First und so lässt grüßen

*auch grüß*
~ Frase

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Naja... eigene Spiele/Ideen coden ist ja auch ein besonders "einfacher" Fall. Die Prozesse sind ja dazu da in einem Umfeld SW zu schreiben, dass du nicht kennst, und der einzelne Kundenmitarbeiter auch nicht. D.h. du sollst eine SW schreiben die du Fachlich dir erst erarbeiten musst. Das ganze dann in einem Team aus Leuten die vorher schlimmstenfalls noch nie zuammen gearbeitet haben und für eine Infrastruktur die gerade erst gebaut wird und dadurch auch noch sehr beweglich ist.
Da bist du froh, wenn zumindest dein Prozess stabil ist.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Interessantes Thema, ich melde mich auch mal zu wort.

Ich programmiere nun seit 3 Jahren bei uns komplexe Server Software in verbindung mit EMC Documentum eRoom.
Was eRoom ist, kann man schnell einfach über Wikipeda rausfinden

Das fängt bei einfachen Customizations mit 50 Zeilen code an und endet dann bei Windows Dienste die aus 30 DLL´s bestehen die um ~100.000 zeilen code oder mehr enthalten.

Diese Projekte mach ich nahezu alleine, geplant wird schlicht-weg nur der reine "Funktionsteil", also was muss es können, wie muss es aussehen, was erwartet der Kunde". Das wird bei uns Unterteilt dann in sogenannte Arbeitspakete, die auch Zeitmässig geschätzt werden, indem auch eine grobe Umsetzungsbeschreibung definiert ist (Meistens einfache Worddateien mit viel Text ) die dann umgesetzt werden.

Mit dem Thema Planung habe ich mich noch nie richtig auseinandergesetzt.
Defakto werden alle Projekte einfach so aus dem Boden gestampft, egal wie einfach oder komplex.

Das geht auch ganz gut, sofern man diese nahezu alleine macht.
Wichtig dabei nur, das es sauber Strukturiert und so wenig Redundant wie nur möglich ist und vor allem stabiles und sinnvolles Logging enthält.

Möglicherweise wäre das anderst wenn ich viel mehr im Team arbeiten würde, dann würde ich auch viel mehr Flussdiagramme, whatever machen ^^

Denke häufiger nach wie es wohl wäre, wenn ich Studiert hätte ob ich dann mit dem viel mehr "Hintergrundwissen" an Projekte anderst herangehen würde...

Das hat nichts mit dem Studium zu tun, sondern mit der Unternehmenskultur und auch Kundenanforderungen (Schlagwort "Compliance", DIN Normen etc).
Da muss(!) dann eine gewisse Dokumentationslage da sein.

Bei deiner Firma würde mich interessieren, was passiert, wenn du mal 4Wochen Urlaub machst und ein Bug das System lamlegt. Oder du verläßt die Firma oder wirst Krank... was macht dein Chef dann (bzw. euer Kunde mit deinem Chef )?

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also ich bin in einer Firma, die vor Prozessen und Methoden nur so strotzt. Da regt man sich gerne auf, weil man das Gefühl hat, dass man eigentlich Prozesse zur Orchestrierung der Prozesse bräuchte. Aber eigentlich ist das eher Schwarzmalerei.
Ich habe die Erfahrung gemacht, dass das blose Vorhanden-sein von Prozessen nicht dazu verpflichtet, jeden dieser Prozesse zu 100% exakt einzuhalten. Gerade die Prozesse der Softwareentwicklung, die bei uns so angeboten werden, sind zahlreich. Da gibt es von Agil bis RUP alles. Und trotzdem ist das ganze eher als eine Toolbox zu verstehen, aus der man sich bedienen kann. Natürlich wird immer nahegelegt, sich nahe am Prozess zu bewegen - das liegt aber gerade daran, dass der Prozess gedacht ist, dem Entwickler Guidance zu geben. Flash hatte schon gesagt, dass man Prozesse dann braucht, wenn man das Fachgebiet nicht kennt. Die sind aber genauso hilfreich, wenn man gar nicht weiß, wie man an das Projekt von Entwicklungsseite herangehen soll. Wenn man zb. die zugrunde liegende Architektur noch nie verwendet hat (Man entwickelt sein Lebenlang Standalone Applications und soll nun eine große JEE Umgebung auf die Beine stellen zb).

Hab in meiner Bachelorarbeit einen Prozessbaukasten verwendet, der von dem Unified Method Framework abgeleitet ist. An so einer Ableitung sieht man schon, dass die oberste Lösung gedacht war, auf alles zu passen und dadurch so generisch wurde, dass keiner mehr weiß, was man damit anfangen soll. Und dann entwickelt sich eine spezielle Adaptierung. Vorteil bleibt aber weiterhin, dass die Prozesse und Templates usw. zwischen Allgemein und Speziell austauschbar sind und zueinander passen. Wie die Vererbung in der Programmierung eben auch