+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : solutions de gestion pour rapport de bug/etc.. (/showthread.php?tid=3376)
solutions de gestion pour rapport de bug/etc.. - wild-D - 15-12-2008
je m'interroge sur l(es) outil(s) à employer durant la phases de beta de mon futur jeu.
Je cherche et ne trouve rien me convenant.
Le truc on a soit
- les bugzilla-like, c'est très carré, et même intégrable avec SVN&co, mais niveau accessiblilité de l'outil pour le béta-testeur lambda ça me parait pas le top. (c'est plutot des outils destinés aux codeurs)
- ou à l'opposé alors simplement une section de forum dédiée au rapport de bugs, suggestions, etc...
existe-t-il d'autre solutions/méthodes ?
(y a parfois sur des jeu PHP, des systèmes maison pour afficher des état d'avancemnts, etc... mais me semble jamais avoir vu un système prenant en charge la gestion complètes des bugs/amélioration.)
:heuuu: enfin si je me complique la vie pour rien faut me le dire ^^
p.s.
en parlant de bugs; dans les smileys, y a 2 fois le code =langue2= pour 2 smileys différents.
RE: solutions de gestion pour rapport de bug/etc.. - Zamentur - 16-12-2008
Ben juste en passant je te renvois (toi et les autre) au wiki, ou il y a déjà pas mal de réponse...
http://wiki.jeuweb.org/organisation/debug
Perso je suis pour une solution maison, accessible par les membres du groupe betatesteur. Avec un sytème de priorisation des bugs.
Pour algol je discoci la beta de la production (ce que je n'ai pas fait pour la v1: ragol) même durant les mise à jour.
Une procédure mettra automatiquement la production à jour une fois une version déclaré stable. Une procédure étant stable aprés une période d'éssai sans bug déclaré et une présence suffisante.
Il faut pouvoir déclaré un bug comme caché, afin de ne pas le publier dans la liste des modif (ou plutot juste indiqué le nombre du style "et une dizaine d'autre bug") Et çà pour des raison de clarté et de mise en avant des nouvelles fonctionnalités
Aprés concernant l'ajout de fonctionnalité, il faut avoir définit sa façon d'avancer, perso je ne résiste pas à passer du temps à l'ajout d'une fonctionnalité en comparaison d'un bug.
RE: solutions de gestion pour rapport de bug/etc.. - wild-D - 16-12-2008
un RTFM m'apporte aucune aide, je te répondrais volontiers RTFQ ^^
j'ai des progès à faire niveau communication ?
non non y a pas LA réponse que je cherche dans le wiki. Je vais essayer de prendre le temps de bien recadrer ma question.
je suis comme toi; un être humain, et à choisir entre programmer une fonctionnalité pour mon futur jeu ou débuguer, ou même encore programmer un outil pour gérer le débugage; y a pas photo.
et pour la réalisation de mon projet de jeu; je dois prendre en compte mon budget passion-temps qui n'est pas illimité; je me connais suffisamment.
---
le wiki présente des solutions "pro" ou "semi-pro" pour faire les choses si possible proprement. Bref "qui le fait bien"; en théorie je suis parfaitement d'accord avec ce qui est présenté.
Mais le wiki zape un peu les solutions plus amateur/system-D qui peuvent offrir un rapport inestissement/complexité/besoin du projet tout a fait correct. (utiliser juste un fofo; quitte à donner quelques consignes sur comment rédiger son post; ou même carrément se limiter à quelque chose d'encore plus informel type post libre, PM, MSN)
Perso mon expérience développeur à ce niveau se limite au système-D (extension firefox ou petit site toujours en rapport avec le jeu "du moment"; bref mes petit projet satellite d'une durée de vie de 6mois, 1an voir max 2 avec une audience très limitée genre ma guilde; qui se satisfont donc très bien de système de débugage informel).
---
revenons mon projet présent.
on va dire que je dois avoir quelque chose comme 6mois passion-temps de budget pour arriver à la première alpha/béta bref un premier truc potable à mettre entre les mains de testeurs. (en temps réels ça peu faire entre 4 et 12 mois selon mes disponibilités, motivation, etc..)
(Et point non négligeable qui font qu'il est pas question d'avoir un budget illimité: c'est qu'à l'arrivée du béta-testing, il y aura en plus une étape cruciale: à savoir voir réellement ce qu'il en est de mon amour ou pas pour gérer/administrer mon propre jeu. En plus ça ne dépendra pas automatiquement que de moi; mais aussi des joueurs/testeurs et du feeling qui se créera)
Me voilà donc à devoir caser tout ce qui reste à faire dans ce budget; c'est donc plutot chaud.
- conception & programmation du jeu
- graphismes
- recrutement testeur/organisation du beta-test (y compris sélection/création outils idoines)
- etc...
y a pas de miracle, va falloir que je coupe dans le vif; je pourrais pas tout faire de A à Z avec mes petites mimines.
me faut donc trouver des briques de préfabriqué pour compléter ce que je devrais faire à la mimine; décider ce qui est pas indispensable pour une première beta version et voir comment je vais monté tout ça.
au niveau bug tracking system y a le choix:
a) préfabriqué: trac, mantis, flyspray...
+ c'est carré
- C'est lourd, selon les cas login propre au système, et niveau intégration/réponse au plus prêt des besoins de mon projet ça me semble pas le top du top; sans parler de l'ergonomie pour les testeurs non-codeur.
- outils que je maitrise pas vraiment vu que jamais utilisé en temps que dev. (c'est pas pour la vingtaine de rapport du bugs que j'ai fait sur l'un ou lautre que je vais aller loin)
b) le fait maison sur mesure avec mes petites minmines, alors là on peut imaginer bcp de choses;
+ normalement niveau intégration/adéquation avec les besoin spécifique de mon projet ça devrait être au poil.
- par contre au niveau budget temps-passion ça va être super chronophage. (même si temps réels je me contente d'un système relativement simple et donc assez vite réalisé; c'est un truc qui va me barbé et que je vois à 1 mois temps-passion minimum; et ça c'est même pas pour la version idéal du system de bug tracking maison)
c) system-D (simple section de forum a priori; avec un post-it présentation un modèle de rapport de bug)
+ investissement initiale en dev/config etc.. minimal; niveau budget temps-passion ça me coute rien quasiment
= intégration ce sera au niveau de celle du fofo
- à 1 contre 10 testeurs/joueurs j'ai une chance de m'en sortir; à 1 contre 100 je suis mort :rip: ; en plus un fois lancé niveau temps/clareté ça sera surement plus lourd à gérer qu'un système dédié.
bref, pas de solution idéale a priori. D'où ma question:
>> existe-t-il d'autre solutions/méthodes ? (j'ai p-e zapé quelque chose de tout bête ça m'arrive)
RE: solutions de gestion pour rapport de bug/etc.. - Zamentur - 16-12-2008
Citation :un RTFM m'apporte aucune aide, je te répondrais volontiers RTFQFaut pas le prendre comme çà, j'ai dit que j'étais préssé "Ben juste en passant ". Et puis j'avais précisé que c'était aussi pour les autres...
Pour ce qui est des autres solutions, je ne sais pas! Il y a sans doute d'autre bug tracker...
Sur qu'il faut que ce soit simple pour le betatesteur.
Enfin bon j'ai pas de solution toute faite pour l'instant!
Peut etre que quelqu'un a quelques choses de tellement génialissime qu'ilo va nous en parler (à moins qu'il ne garde tout pour lui o_O)?
RE: solutions de gestion pour rapport de bug/etc.. - Seren - 16-12-2008
Pour le développeur, le a) est clairement le mieux.
ça permet de classer par composant, d'éventuellement mettre une release différente, d'assigner le bug à un éventuel co-dévelopeur...
Par contre pour le bêta testeur par forcément très technique, c'est plus facile d'utiliser c).
J'ai pas la solution miracle, mais je te conseillerais d'essayer de mélanger a) et c) :
1. Tu laisses un forum ouvert où tout le monde colle ses bugs.
2. Tu délègues le pouvoir de trier les bugs à quelqu'un de confiance qui est un peu plus technique, et tu lui donnes le boulot de rentrer les bugs dans Trac (ou autre).
A la limite tu peux même délèguer à plusieurs personnes.
Si tu as 10/20 bêta testeur tu peux espérer qu'une personne se dévoue.
Ensuite je te conseillerais de pas trop t'encombrer l'esprit avec des choses que tu risques de mettre en place que dans six mois ou un an.
Sinon dans un futur lointain, je compte utiliser les possibilités de www.unfuddle.com. En plus d'un dépôt git, il y a un bug tracker très simple qu'un beta testeur devrait être capable de maitriser. =)
RE: solutions de gestion pour rapport de bug/etc.. - Anthor - 16-12-2008
En même temps un bug tracker ne met pas beaucoup de temps à se développer, 2h tout au plus.
Un formulaire avec un textarea pour le commentaire, un select avec différents thèmes, et le bouton d'envoi.
Une page de listing, et un formulaire pour changer le statut/voir le détail.
RE: solutions de gestion pour rapport de bug/etc.. - Hakushi - 17-12-2008
(16-12-2008, 10:40 PM)Anthor a écrit : En même temps un bug tracker ne met pas beaucoup de temps à se développer, 2h tout au plus.
Un formulaire avec un textarea pour le commentaire, un select avec différents thèmes, et le bouton d'envoi.
Une page de listing, et un formulaire pour changer le statut/voir le détail.
Exact, et si tu veux gerer des niveaux de priorites, ca te prend juste une champ en plus dans ta table pour affecter une niveau de prio.
RE: solutions de gestion pour rapport de bug/etc.. - wild-D - 18-12-2008
enfin j'ai déjà pris ma décision: c)
pas besoin de se prendre la tête; tant que j'ai aucun motif réel. Sera toujours temps lorsque y aura vraiment une beta; de voir quels sont les vrais besoins (pour moi et les testeurs)
@seren
^^ ben voilà une option que j'avais pas considéré (complètement zapé ce genre de service tiers). http://www.unfuddle.com en private à l'air pas mal pour des petits projets solo ou a 2, juste ce qu'il faut. Enfin faudra que je regarde.
@anthor et Hakushi
je visais un poil plus haut; non parce que genre si faut fermer les tickets à la mimines, etc... au final ce formulaire je vois pas bien ce qu'il apporte de plus que le fofo avec un modèle de post. (si ce n'est le plaisir de dev un truc en plus, et pour les testeurs le plaisir d'avoir une fonctionnalités qu'à été dev rien que pour eux; enfin les testeurs ça court pas tous les coins de rues, c'est p-e bien de les caresser dans le sens du poils
)