spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Das aktuell im Trend liegende Vorgehen ist agile Softwareentwicklung. Z.B. Scrum.

Hey,

ich finde Pivotal Tracker [1] für ein kleines SCRUM Team toll. Bin mir aber nicht sicher, ob das auch für Scaled-Agile skaliert. Ich habe aber auch schon Projekte mit Trello [2] und dem "Scrum for Trello" [3] Plugin absolviert. Kann ich auch empfehlen. Privat für mich nutze ich ebenfalls Trello, um mein tägliches Leben (Uni, Projekte, ...) zu organisieren. Den Prozess umgestellt habe ich mit diesem [4] Buch.

Grüße T0a

[1] http://www.pivotaltracker.com/
[2] https://trello.com/
[3] https://chrome.google.com/webstore/detai…nkjmndgje?hl=en
[4] http://www.amazon.de/Getting-Things-Done…ing+things+done

Solche Diagramme fertigt man in agiler Entwicklung eigentlich maximal als Dokumentation hinterher an. Wenn man sie vorher anfertigt, dann zumeist als "Gesamtplan" im Wasserfallverfahren. UML-Diagramme, speziell Klassen-Diagramme sind ein sehr starkes Indiz dafür. In agiler Entwicklung sind mir die bisher noch nie begegnet.

Kann BlueCobold da beiflichten. Kann man auch aus dem Agile Manifesto [1] entnehmen. Das heißt jedoch nicht, dass "working software" super und "documentation" doof ist. Auch in Agile Projekten fertigt man Dokumentation an

[1] http://agilemanifesto.org/

Zitat von »BlueCobold«

Nach meiner Erfahrung ist Wasserfall tot und das haben die meisten schon verstanden.

In reinen Softwareprojekten definitiv, jedoch gibt es viele Projekte in denen Wasserfall durchaus noch Sinn macht. Z.B. wenn ein Grossteil des Projects aus ME/EE Arbeit besteht wo iterative Entwicklung sehr schwierig umzusetzen ist. Eine Iteration kann mehrere Wochen in der Produktion verbringen und viel, viel Geld kosten. Oder wenn es schwierig ist updates auszurollen, z.B. ist es schwierig das Onboard System eines Autos zu aktualisieren sobald es vom Fliessband gerollt ist (Wobei auch sich der Trend auch hier langsam aendert, siehe Tesla).

Ich wuerde also nicht sagen, dass es ueberall tot ist (oder sein sollte). Es kommt einfach auf die Industrie und die Projekte an.

Ich nutze eigentlich nur Git und LaTeX (Anforderungen, Überlegungen). Diagramme -> meist das gute alte Papier.

Zitat von »xardias«

Oder wenn es schwierig ist updates auszurollen, z.B. ist es schwierig das Onboard System eines Autos zu aktualisieren sobald es vom Fliessband gerollt ist (Wobei auch sich der Trend auch hier langsam aendert, siehe Tesla).

Man kann auch agil ohne Wasserfall entwickeln, wenn am Ende ein abgeschlossenes Produkt rauskommt. Unsere Firma ist zufällig sogar Zulieferer für Onboard Software in Trucks und der Kunde arbeitet explizit nach Scrum. Es muss ja nicht heißen, dass das Produkt nach jedem Sprint als neue Software-Version ausgerollt wird wie z.B. bei Firefox. Es wäre aber möglich.
Alles bis in's Detail nach Wasserfall in Fluss- und Klassendiagrammen zu modellieren und es dann implementieren zu lassen, funktioniert nach meiner Erfahrung nirgends. Ich höre mir gern Gegenbeispiele an, wo solch ein Vorgehen funktioniert. Agil entwickeln heißt ja auch nicht, dass man nicht ein finales Ziel oder Meilensteine vor Augen hat oder dass man seine Software beim Kunden reifen lässt.

Bei uns wird das komplette Model vorher als UML erstellt (Architektenarbeit) und dann das Grundgerüst des Codes daraus generiert.
Die Entwickler füllen dann im Grunde den Code ein. Ob das so super funktioniert kann ich noch nicht beurteilen, da ich noch nicht lang genug dabei bin. Aber das geht in Richtung Wasserfallmodel. Natürlich wird dann das Model angepasst wenn man später merkt das man Mist modeliert hat.

Wie ist das denn bei euch Blue? Fangt ihr gleich an Code zu schreiben?