Améliorer le processus de développement

Llyn · 2017-05-22 19:26:59

Alors, le sujet est délicat, je tiens à préciser que ce post n'est pas une critique de l'équipe de dev,
j'en ai d'autant moins le droit que j'avais promis de faire du dev et que je n'ai pas tenu ma parole,
donc je me sens tout-à-fait fautif.
Par contre, j'ai une expérience de développement de code scientifique, et même si Nacridan est un
jeu amateur, ça me semble bien que ceux qui ont une expérience professionelle liée au jeu profitent
de topic pour diffuser leur expérience (le lien entre amateur et pro est assez flou de toute façon).

En l'occurence, je vois deux aspects qui pourraient être applicables avec profit au process de
développement.

1) Les étapes d'une modif sous assurance qualité
il ne s'agit pas de se faire certifier ISO9001, mais j'ai pu constater que formaliser un minimum
certaines étapes était toujours extrêment rentable en termes de développement, même si
c'est uniquement un exercice de pensée
- Cahier des charges : penser un dev en termes de demandes d'utilisateur (pour nous un utilisateur
c'est à la fois les joueurs et les l'équipe qui veille à l'équilibre et l'intérêt du jeu). Grosso modo
cette étape actuellement c'est ce qui ressort des fils "demandes d'évolution"
- Spécification : là, c'est la réponse en termes de dev, avec la définition précise des paramètres
des formules. Eventuellement comment faire pour l'aspect technique, mais ça n'est pas obligatoire
pour nous je pense. Il y a deux possibilités. Soit on fait un post de conclusion du fil des demandes de
modifs qui résume ça, comme ça les utilisateurs sont au courant des modifs à venir (ceux qui lisent
le forum au moins). C'est parfois ce qui se fait déjà. Soit on en fait carrément un petit doc, solution que
je préfère en général, étant donné que ça va se retrouver à l'identique dans les règles, c'est donc du temps
gagné
- Codage : là c'est purement technique. Idéalement, on fait la vérification en même temps que le codage
(voir mon deuxième point). Il y a eu des d'études sérieuses qui montrent qu'on gagne du temps à vérifier
systématiquement le code qu'on produit plutôt qu'à traquer les bugs une fois la release faite (c'est un facteur
5 à 10 en temps de mémoire). Développer sale et en un temps record, c'est bon pour quelqu'un qui vend
un code sur un contrat, et qui ensuite va se faire payer une deuxième fois pour assurer la maintenance...
sinon ça n'est pas efficace.
- Documentation : c'est une étape importante, je carricature un peu, mais une différence entre la doc et le code
c'est un bug (bug = ça ne fait pas ce qui est affiché que ça devrait faire). Ou alors c'est que la modif n'a pas
d'influence sur l'utilisateur et alors elle est probablement inutile. Il y a aussi le fait que dans des devs collectifs,
il faut toujours s'assurer qu'une autre personne puisse prendre le relai derrière, d'où l'importance des commentaires
dans le source. En fait, pour moi la doc est partie intégrante du code (j'ai même travaillé sur un projet où elle était
directement générée à partir du source)

2) Verification et Validation (V&V)
La vérification, c'est s'assurer que le code fait bien ce qu'il est censé faire. La validation, dans le domaine de la
modélisation scientifique, c'est s'assurer que le code colle à la réalité de façon convenable. Pour nous, ça se transcrit
par : coller au monde imaginaire de Nacridan, tel qu'on l'imagine (c'est l'aspect RP), et tel que les joueurs le pratiquent (GP).
On peut discuter à l'infini là-dessus, mais c'est nécessaire, je pense, quand on fait une modif que l'on se pose la question
systématique : quelle influence, non seulement sur la cible de la modif, mais aussi sur tous les autres aspects du jeu.
Typiquement, on fait une modif qui cible une classe à un certain niveau, il faut s'assurer que ça reste acceptable pour
les autres classes à d'autres niveaux. Et on ne peut pas faire de beta à chaque fois pour tester à la main toutes les
configurations pendant des mois. On a donc besoin de cas-test prédéfinis que l'on peut lancer de façon assez systématique
dès qu'on fait une modif un peu grosse, et qui couvre au mieux l'ensemble des configurations possibles du jeu : on appelle ça une
matrice de validation.

On peut définir des persos-types par exemple, représentés par un coefficient de progression dans chacune des caractéristique et par
son niveau (y compris matos et boost). On peut déterminer les coefficients effectivement utilisés sur le plateau de jeu et voir ainsi
des "groupes" (on devrait retouver le full vit, le dex-mm etc..., chacun avec des variantes optimisée ou non, stuffée en matos ou pas).
Ce qui permet ensuite de balayer tous ces groupes à tous les niveaux de façon quasi instantannée quand on envisage une modif,
et détecter s'il va y avoir un problème d'équilibre. Ou anticiper un peu ce qui va se passer au niv 50.

Voilà, désolé si ça parait un peu dogmatique, j'ai essayé de résumer au maximum. Et je suis sûr que d'autres pourraient aussi faire
part de leur expérience pour tenter d'améliorer les choses.

Lotharim · 2017-05-22 19:48:07

Je suis d'accord avec toi sauf que... pour faire ça il faut du temps... donc on fait de modifs petits bouts par petits bouts.

Llyn · 2017-05-22 20:29:08

C'est indépendant de faire de gros devs ou de petits, commit-few/commit-often c'est même plutôt recommandé.
En général il suffit de se poser la question pour bien distinguer les étapes et ça suffit

Pour la validation, hier, j'ai fait le test pour le feu-fol avec 4 persos type, pour des niveaux de 1 à 50. Ca m'a pris 10 mn de temps sur un tableur excel...

Bon après, trop formaliser les choses, c'est contre-productif. Mais attendre d'avoir le nez dans le code pour se poser les questions, c'est une grosse erreur.
Entre les deux il y a une marge

Ce que je voulais suggérer aussi, c'est de ne pas attendre le retour des joueurs, beaucoup ne passent pas sur le forum d'ailleurs et les top squattent la discussion.
C'est d'aller chercher directement dans leur profil, ça a un côté un peu big brother, mais on est sûr au moins que ça représente les persos du plateau tels qu'ils sont
et pas tels qu'on les rêve

Dernière modification par Llyn (2017-05-22 20:34:55)

Lotharim · 2017-05-22 20:58:39

Tu sais quand tu as 30 minutes pour coder un tr7c c'est pas évident il faut aller vite. Je faisais plus que des corrections de bugs sur la fin. J'ai un gros dev lancé sur l'Ia des monstres que j'ai jamais fini et que je finirais jamais. La modification de projection m'a demande pas loin de 6 mois.

Si tu veux mettre ce susteme en place il faut decouper les taches une par personne.

breizhou13 · 2017-05-22 22:51:43

Sur du vrai projet je suis d'accord avec toi llyn. Par exemple en ce moment, je suis sur un projet de changement de Conduite Numerique Centralisée en passant de chez ABB vers Honeywell. On en est a ce qu'on nomme les FAT. Seulement, pour preparer les fiches de FAT, ca nous a pris quasiment 2 ans. Et au fur et a mesure qu'on avance, on se rend compte de chses qui ne vont pas dans nos FAT.

Ici, je suis pas sur que qui que ce soit ait le temps de faire ce travail monstrueux.

On m'avait demandé au debut de tester toutes les comps pour trouver les bugs. J'avais fait ce genre de fichier en simplifié. Ca m'avait pris plus d'un mois a faire le fichier et pas loin du meme temps pour tester....

Furtif · 2017-05-23 03:24:05

Quelque soit l'ampleur du projet, maintenir un "carnet de bord" comme ceci est une bonne idée.

Mettre en place la méthodo prend du temps, mais c'est, je pense, toujours bénéfique. Apres, à chacun sa façon de bosser.

Ceci n'est qu'un avis extérieur, d'une personne qui sait la charge de travail que cela represente, malgré l'inexpérience dans le domaine du code.

Aé Li · 2017-05-23 08:13:22

On a plusieurs fois essayé de tendre vers une organisation de ce type. La création de la section "Modification en cours" en est l'un des vestiges. Idems, les appels réguliers pour les tests, Breizhou sait le temps que ça prend, et surtout la difficulté de la régularité là dessus.

Par fois on y est presque. Je juge que pour les consommables c'était presque bon. On a eu une discussion, un post de clair de chiffrage épinglé pendant longtemps, les règles à peu près à jour etc. Sauf que là encore à peu près 5 mois.

Je pense que le vrai problème sur la dernière modif des FF c'est de ne pas avoir fait le post de chiffrage séparé. C'est rapide à faire, et ça permet de mieux communiquer, de voir des problèmes, etc. A part ça, difficile d'améliorer beaucoup.

Nacridan le forum

#1 2017-05-22 19:26:59

Améliorer le processus de développement

#2 2017-05-22 19:48:07

Re : Améliorer le processus de développement

#3 2017-05-22 20:29:08

Re : Améliorer le processus de développement

#4 2017-05-22 20:58:39

Re : Améliorer le processus de développement

#5 2017-05-22 22:51:43

Re : Améliorer le processus de développement

#6 2017-05-23 03:24:05

Re : Améliorer le processus de développement

#7 2017-05-23 08:13:22

Re : Améliorer le processus de développement

Pied de page des forums