GCDC 2008: Was ist "Agile Development"? - 4Players.de

4Players.de Das Spielemagazin. Kritisch. Ehrlich. Aktuell. 4Players.de Das Spielemagazin. Kritisch. Ehrlich. Aktuell.
Messen
Entwickler: -
Publisher: -
Release:
kein Termin
kein Termin
18.08.2008
kein Termin
kein Termin
kein Termin
18.08.2008
kein Termin

Wie findest Du das Spiel?

Spielinfo Bilder Videos

Schnäppchen-Angebote

Stellenmarkt Jobbörse Jobware

Nachrichten

Folge uns

       

GCDC 2008: Agile Development

Lange Zeit wurde die Entwicklung von Software oftmals entgegen der eigentlichen Alltagserfahrung als streng lineares Modell aufgefasst, in dessen Verlauf es vom Anfang an fest definitierte Anforderungen und ein ausführlich definiertes Ende gibt. Der aus sich wiederholenden und aufeinander aufbauenden Schritten bestehenden Natur des Vorgangs wurde erst nach und nach Rechnung getragen. So macht seit einigen Jahren das Schlagwort "Agile Development" die Runde, das verschiedene Erkenntnisse aus dem Bereich der Arbeitspsychologie, Informatik und den allgemeinen Geschäftsabläufen mischt.

Nachdem das so genannte Scrum-Modell bei vielen Firmen aus dem Businesssoftwarebereich Fuß gefasst hat, wird es nach und nach auch von Spieleherstellern angenommen und umgesetzt. Scrum geht davon aus, dass Anwender und Entwickler anfangs noch nicht unbedingt wissen, wohin die Reise am Ende führen könnte. Die Unschärfe ist einkalkuliert und soll im Rahmen der Entwicklung schrittweise beseitigt werden.

Anforderungen und Wünsche werden in Form des Product-Backlogs festgehalten. Die Entwicklung besteht aus Sprints genannten Zyklen, die für gewöhnlich ca. 30 Tage dauern, in denen das Team recht autonom an der Umsetzung festgelegter Teilziele und Features arbeitet, dabei möglichst abgeschirmt vor Einflussfaktoren von außen ist. So soll das Produkt bzw. das Team in dieser Zeit vor oftmals sich ändernden Anforderungen geschützt werden, die die Fertigstellung verzögern - etwaige Abweichungen und Neuerungen können i.d.R. erst vor kommenden Sprints eingebracht werden.

Dabei entscheiden alle direkt an der Entwicklung beteiligten Personen gemeinsam, welche Ziele demnächst erreicht werden können. Es obliegt den Teammitgliedern abzuschätzen, was in welcher Zeit und mit welchen Maßnahmen realisiert werden kann. Im Gegensatz zu traditionellen Modellen kann und muss jedes einzelne Teammitglied mehr Verantwortung übernehmen - und genau das gehört auch zu einer der großen Herausforderung beim Einführen von Scrum, so Patric Palm von Hansoft, der den Ansatz auf der GC Developers Conference erläuterte.

In Unternehmen, wo die Firmenkultur eher durch eine starke hierarchische Struktur (Top-Down) geprägt ist. Dort müsse ein notfalls von Trainern unterstütztes Umdenken stattfinden, sonst würde Scrum dort kaum in einer Verbesserung der Abläufe resultieren. Ebenfalls zum Scheitern verurteilt sei der Ansatz naturgemäß, wenn das Management nicht hinter ihm steht und ihn stützt - auch hier komme es auf die Firmenkultur an.

Am anderen Ende des Problemspektrums sei die übermotivierte Verwendung von Scrum. Dabei bestehe nämlich die Gefahr, dass auch bewährte und etablierte Prozesse über Bord geschmissen werden könnten. Das Modell sei eben keine magische Lösung, deren Einsatz ohne Risiken ist.


Kommentare

Metalsplitter schrieb am
Bei uns wurde Agile Development vor einem Jahr eingeführt und habe deshalb bei einer Schulung eines wahren Guru's teilgenommen (Larman, Craig) War wirklich Interessant, als er auch die Geschichtliche Entwicklung durchgenommen hat. Wenn mich nicht alles täuscht, wurde es bei der Nasa oder irgendeiner grossen amerikanischen Organisation 1960 entwickelt (lt. Wiki erst 1990) aber erst 40 Jahre später setzt es sich langsam durch. Eigentlich erstaunlich, da KANBAN oder just in time Verfahren schneller ging.
An sich eine logischer Schritt in die Zukunft. Aber ich habe in diesem Artikel ein wichtiges Kriterium vermisst lt. Craig Larmann programiert man erst den Test und danach den neuen Code. Da sich das Programm jede Sekunde selbst testet, werden Bugs vermieden.
Bin kein Programmierer sondern Kaufmann, daher konnte ich natürlich nicht alles verstehen. Aber es hat irgenwie den Toyota Ansatz. Es ist ein gutes Modell, aber manchmal scheitert es auch den länderspezifischen Mentalitäten. Wir Deutsche sind halt nicht noch nicht so teamorientiert wie manch andere Länder und die Umstellung darauf ist nicht ohne wie Kajetan geschrieben.
Kajetan schrieb am
Wer sich ein wenig für das Chaos im Zuge der Schliessung der Flagship Studios interessiert hat, hat bestimmt auch mitbekommen, wie dort entwickelt wurde.
Nämlich nach dem Scrum-Modell, welches aber falsch verstanden und aufgefasst wurde, so dass jeder einzelne wild vor sich hinentwickelte, es keine vernünftige Projektplanung gab, die all diese Einzelarbeiten beobachten, werten und notfalls steuernd eingreifen konnte. Als Folge dieses Mißverständnisses kam Hellgate dann in dem Zustand auf den Markt, den wir alle kennen. Technisch unausgereift, spielerisch unausgewogen, Features nicht vernünftigt durchdacht und ausbalanciert, sowie Minimal-Content, weil einfach keine Ressourcen mehr übrig waren, um dieses Kuddelmuddel mit Inhalt zu füllen. Ein einziger, großer Haufen unbrauchbarer Code-Scheisse.
Das Modell als solches ist gar nicht schlecht, weil es sich bemüht dem tatsächlichen Ablauf in der Software-Entwicklung zu entsprechen. Jedoch muss man es auch verstehen, es richtig anwenden und nicht einfach denken, dass mit Laissez Faire und "Mach halt mal irgendwas" irgendwann per Zauberhand ein vernünftiges Endprodukt entstehen kann.
schrieb am

Facebook

Google+