Comment vous préparez-vous au fluage des fonctionnalités?

Comment puis-je me préparer au fluage des fonctionnalités pendant la pré-production?

Le fluage des fonctionnalités, c'est quand vous êtes en phase de production et décidez "Ce serait cool si c'était une fonctionnalité!" Cela ajoute n heures au temps de développement qui n'étaient pas prises en compte, et à moins que vous ne soyez Blizzard, vous n'en avez pas le temps. Vous ne pouvez pas vous attendre à ce que ce soit une fonctionnalité intéressante pendant la pré-production, car la fonctionnalité n'est découverte que pendant la production.

Que puis-je faire pendant la préproduction pour prendre en compte ou empêcher ou préparer le fluage des fonctionnalités?

Dois-je autoriser le fluage des fonctionnalités et couper moins de fonctionnalités souhaitées? Ou cela créera-t-il un problème puisque l'architecture n'est pas conçue pour les nouvelles fonctionnalités? Dois-je dire aucune fonctionnalité à moins qu'elles ne s'intègrent dans l'architecture existante?

Je sais que c'est une vaste question, mais j'espère qu'elle ne sera pas fermée en tant que telle. Ceci est un problème majeur dans le développement de jeux et doit être pris en compte.

Bien qu'il n'y ait bien sûr pas de règles strictes en matière de pré-production, il existe une variété d'heuristiques pour vous aider. Certaines fonctionnalités sont naturelles et nécessaires - aucun plan ne survit au premier contact avec la réalité, et vous ne savez peut-être pas ce qui serait "cool" avant de le voir.

Tout d'abord, mettez en scène votre développement. Dessinez votre plan dans une carte d'entités, puis recherchez des moyens de regrouper vos entités en itérations testables , chacune avec une échéance . Une fois que vous avez commencé une itération, évitez d'y ajouter de nouvelles fonctionnalités. Tout besoin technique imprévu devrait bien sûr entrer dans l'itération actuelle, mais de nouvelles idées de fonctionnalités devraient entrer dans une liste pour un examen futur. Vous pouvez ensuite décider de l'ajouter ou non à une itération une fois celle-ci terminée.

Cela découle de la méthode MoSCoW , par laquelle vous catégorisez des fonctionnalités comme ceci:

• Doit avoir - des fonctionnalités qui sont essentielles pour que l'itération actuelle soit stable , c'est-à-dire testable . Si l'itération ne fonctionne pas sans elle, c'est un must have.
• Devrait avoir - des fonctionnalités qui devront être réalisées à un moment donné, mais si l'itération se prolonge, le temps peut être poussé dans la toute prochaine itération . Les choses requises par un éditeur, par exemple, pourraient aller ici.
• Peut avoir - des fonctionnalités qui, selon vous, peuvent être importantes pour l'itération actuelle, mais pourraient être supprimées du projet. Ce sont les caractéristiques polonaises toutes importantes .
• N'aura pas - les éléments qui alimentent potentiellement le backlog , les fonctionnalités identifiées dans cette itération à prendre en compte pour les itérations ultérieures.

Idéalement, vous voulez que le développement soit un raffinement progressif, pas tout ou rien. En travaillant dans un délai final, les fonctionnalités les moins importantes doivent être poussées jusqu'au bout, donc tout ce que vous n'obtiendrez pas sera quelque chose de correct. Assurez-vous d'estimer le temps nécessaire à chaque fonctionnalité pour développer et affiner ces estimations au fur et à mesure. Ne compressez jamais le programme pour faire de la place pour plus de fonctionnalités. Résistez à repousser les délais (itération ou final) dans le futur - déplacez ou coupez les fonctionnalités à la place, si possible. Si vous approchez de votre échéance et que le jeu est toujours un gâchis invendable, vous savez qu'il est temps de réévaluer sérieusement vos décisions et d'envisager de cannibaliser le projet avant qu'il ne se transforme en fosse de temps / argent.

• Prévoyez d'utiliser une fraction de votre temps de pré-production disponible pour l'ensemble de fonctionnalités de base.
• Les fonctionnalités de base doivent être des fonctionnalités à faible risque et à récompense élevée, afin que vous n'ayez pas peur de celles-ci
• L'ensemble de fonctionnalités de base est minimal et non négociable - ils doivent être présents - sinon aucune base solide pour travailler et vous serez criblé de doute / "devrais-je remplacer ce" syndrome
• Assurez-vous que les premières itérations de votre jeu sont suffisamment attrayantes pour que vous puissiez vous permettre de vous déplacer. Un jeu fondamentalement peu impressionnant n'ira pas loin, encore moins avec le fluage.
• Sachez à l'avance quelle marge de fluage vous pouvez vous permettre, afin que vous puissiez utiliser cette marge à bon escient.
• Utilisez une technologie pré-construite et hautement généralisée comme Unity, et utilisez-la de manière canonique pour améliorer la flexibilité afin que le fluage des fonctionnalités n'ait pas trop d'impact sur l'architecture existante
• Ne construisez pas de sous-systèmes complexes - une approche de programmation eXtreme convient ici
• Demandez à d'autres (concepteurs et codeurs) dont vous pouvez périodiquement exploiter le cerveau pour vous aider à hiérarchiser les fonctionnalités que vous autoriserez à faire glisser, demandez à quelqu'un de vérifier votre code comme point de départ principal pour ces questions.
• Vous devrez toujours limiter le fluage des fonctionnalités, alors priorisez constamment et sachez où tracer la ligne

En fin de compte, ce n'est pas quelque chose que je proposerais aux débutants, car vous devez être en mesure de prendre la bonne décision à chaque étape et ce n'est pas facile, même pour les plus expérimentés. Si vous ne savez pas quelles sont les bonnes décisions, adoptez une politique stricte "pas de fluage au-delà de ce point".

Vous pouvez également voir comment le premier point et celui concernant l'utilisation d'une technologie que vous connaissez bien signifie que vous avez besoin d'une expérience substantielle à la fois dans le prototypage rapide (game jams) et le jeu d'outils que vous avez choisi.