Wie bereitest du dich auf Feature Creep vor?

Wie kann ich mich während der Vorproduktion auf Feature Creep vorbereiten?

Feature Creep ist, wenn Sie sich in der Produktionsphase befinden und entscheiden "Es wäre cool, wenn dies ein Feature wäre!" Das erhöht die Entwicklungszeit um n Stunden, die nicht berücksichtigt wurden. Wenn Sie nicht Blizzard sind, haben Sie keine Zeit für. Sie können nicht erwarten, dass es sich bei der Vorproduktion um ein cooles Feature handelt, da das Feature nur während der Produktion erkannt wird.

Was kann ich während der Vorproduktion tun, um Feature-Creep zu berücksichtigen, zu verhindern oder vorzubereiten?

Sollte ich das Kriechen von Features zulassen und weniger gewünschte Features schneiden? Oder wird dies zu Problemen führen, da die Architektur nicht für die neuen Funktionen ausgelegt ist? Sollte ich keine Features angeben, es sei denn, sie passen in die vorhandene Architektur?

Ich weiß, dass dies eine weit gefasste Frage ist, aber ich hoffe, dass sie nicht als solche abgeschlossen wird. Dies ist ein Hauptproblem bei der Spieleentwicklung und sollte berücksichtigt werden.

Während es bei der Vorproduktion natürlich keine strengen Regeln gibt, helfen verschiedene Heuristiken. Einige Eigenschaften sind natürlich und notwendig - kein Plan übersteht den ersten Kontakt mit der Realität und Sie wissen möglicherweise nicht, was "cool" wäre, bis Sie es sehen.

Stellen Sie zuerst Ihre Entwicklung auf die Bühne. Zeichnen Sie Ihren Umriss in eine Feature-Map und suchen Sie nach Möglichkeiten, Ihre Features in testbaren Iterationen mit jeweils einer Frist zu gruppieren . Wenn Sie mit einer Iteration beginnen, sollten Sie nicht länger neue Funktionen hinzufügen. Alle unvorhergesehenen technischen Anforderungen sollten natürlich in die aktuelle Iteration einfließen, aber neue Ideen für Funktionen sollten zur künftigen Prüfung in eine Liste aufgenommen werden. Sie können dann überlegen, ob Sie es einer Iteration hinzufügen möchten, sobald die aktuelle abgeschlossen ist.

Dies folgt aus der MoSCoW-Methode , mit der Sie Features wie folgt kategorisieren:

• Must Haves - Features, die für die Stabilität der aktuellen Iteration wichtig sind, dh testbar sind . Wenn die Iteration ohne sie nicht funktioniert, ist sie ein Muss.
• Sollte es - Features geben, die irgendwann erledigt werden müssen, aber wenn die Iteration über die Zeit geht, kann sie in die nächste Iteration verschoben werden . Dinge, die zum Beispiel ein Verlag benötigt, könnten hier hingehen.
• Könnte haben - Funktionen , die Sie denken an die aktuelle Iteration wichtig sein kann , aber aus dem Projekt gelöscht werden konnte. Dies sind die wichtigsten polnischen Merkmale .
• Wird nicht haben - Elemente, die möglicherweise das Backlog befeuern , in dieser Iteration identifizierte Funktionen, die für spätere Iterationen berücksichtigt werden sollen.

Idealerweise möchten Sie, dass Entwicklung eine progressive Verfeinerung ist, nicht alles oder nichts. Wenn Sie innerhalb einer endgültigen Frist arbeiten, sollten die unwichtigsten Funktionen zu Ende sein. Was Sie also nicht bekommen, ist alles, was Sie schneiden können. Stellen Sie sicher, dass Sie abschätzen, wie lange jedes Feature benötigt, um diese Schätzungen zu entwickeln und zu verfeinern. Komprimieren Sie niemals den Zeitplan, um Platz für weitere Funktionen zu schaffen. Vermeiden Sie es, Termine (Iterationen oder Endtermine) in die Zukunft zu verschieben oder auszuschneiden, wenn möglich. Wenn Sie sich Ihrer Deadline nähern und das Spiel immer noch ein unverkäufliches Chaos ist, ist es an der Zeit, Ihre Entscheidungen ernsthaft zu überdenken und in Betracht zu ziehen, das Projekt zu kannibalisieren, bevor es zu einer Zeit- / Geldgrube wird.

• Planen Sie, einen Bruchteil Ihrer verfügbaren Vorproduktionszeit für das Basisfeatureset zu verwenden.
• Base Featureset sollte mit geringem Risiko, hohe Belohnung Funktionen, so dass Sie kriechen müssen nicht auf diejenigen
• Das Basisfeatureset ist minimal und nicht verhandelbar - es muss vorhanden sein - ansonsten gibt es keine solide Arbeitsgrundlage und Sie werden mit Selbstzweifeln / "Sollte ich dieses" Syndrom konfrontiert
• Stellen Sie sicher, dass die frühesten Iterationen Ihres Spiels attraktiv genug sind, um sich Feature-Creep leisten zu können . Ein von Grund auf unscheinbares Spiel wird es nicht weit bringen, geschweige denn kriechen.
• Informieren Sie sich im Voraus darüber, welche Zeitspanne Sie sich leisten können, damit Sie diese Zeitspanne mit Bedacht einsetzen können.
• Verwenden Sie vorgefertigte, stark verallgemeinerte Technologien wie Unity und verwenden Sie sie kanonisch, um die Flexibilität zu verbessern, damit sich das Kriechen von Features nicht zu stark auf die vorhandene Architektur auswirkt
• Bauen Sie keine komplexen Subsysteme auf - ein eXtreme-Programming- Ansatz ist hierfür geeignet
• Lassen Sie andere (Designer und Programmierer), deren Gehirn Sie in regelmäßigen Abständen antippen können, um Prioritäten für die Funktionen festzulegen, die Sie erstellen dürfen, Ihren Code von einer erfahrenen Person überprüfen.
• Sie müssen das Kriechen von Features immer noch begrenzen, also müssen Sie ständig Prioritäten setzen und wissen, wo Sie die Linie zeichnen müssen

Letztendlich würde ich Anfängern nicht empfehlen, weil man in jeder Phase die richtige Entscheidung treffen muss, und das ist selbst für die erfahrensten nicht einfach. Wenn Sie sich nicht sicher sind, welche Entscheidungen richtig sind, sollten Sie strikt darauf achten, dass Sie nicht über diesen Punkt hinausgehen.

Sie können auch sehen, dass der erste Punkt und die Frage nach der Verwendung einer Technologie, die Sie gut kennen , umfangreiche Erfahrung sowohl im Rapid Prototyping (Game Jams) als auch in dem von Ihnen gewählten Toolset erfordern.