Garder le Cap ?

[Melimelo]

Hello,

ca fait longtemps que j'ai pas posté mais je continue a vous lire Et je voulais savoir quels étaient vos trucs pour garder le cap ainsi qu'un rythme de développement soutenu. Moi personnellement j'ai tjrs un cahier des charges plus ou mains complet mais je parviens pas a me tenir au objectif défini. Je suis pas assez discipliné, une méthode pour y arriver ? Un moyen de booster sa motivation ?

Melimelo

[Argorate]

Salut!

Je pense que le mieux est de se fixer des delais, des dates, un planing même. Le truc c'est que même si tu as un peu de retard, cela te permet d'avoir une ligne directrice, une dead ligne pour te mettre la pression a toi meme... Tu vois?

[php_addict]

moi je fonctionne a l'entêtement...

[Mycroft]

Avoir du temps.
Avoir un planning et une feuille de route globale (qui de toute façon sera complétement explosée )
Se donner des objectifs réalistes (pas "Je vais faire le meilleur jeu du monde de la mort qui tue" avec 50 000 options de personnalisations différentes, c'est pas réaliste de faire ça seul...)
Se donner des petits objectifs de proche en proche réalisable en une ou deux journées de travail pour bien voir sa progression.


Maintenant que j'ai dit tout ça je peux dire que j'avance pas du tout au rythme que je voudrais. :]

[Sephi-Chan]

Pareil, j'aimerai bien connaître les secrets, s'il y en a vraiment !
Je m'améliore un peu depuis quelques temps, j'arrive à des prototype assez utilisables avant de lâcher l'affaire !


Sephi-Chan, Keep la pêche, drink de l'eau fraîche…

[Melimelo]

Moi ce que je fais souvent c'est :

Day 1 : Espace membres & strucutre
Day 2 : gestion des ressources et de leur production
Day 3 : .....

....

Etc

mais j'arrive rarement jusqu'au day 3 en me tenant au objectif ... (les jours ne sont pas spécialement consécutif) L'idéal pour moi serait d'avoir soit un coéquipier fictif hyper motivant / exigeant mais je risque de couper tout contact avec lui si il l'est trop ^^ par raz le bol. Ou mieux un coéquipier réel qui me fouette et me fixe lui même les objectifs

[pascal]

Hello,

Il n'y a pas de recette universelle mais un ensemble de trucs qui aident à avancer - ou pas.

En vrac :
Avoir un projet le plus petit et le plus ciblé possible. Un grand projet, c'est beaucoup de temps et la motivation fond à vue d'œil, surtout si aucun résultat concret (prototype jouable...) n'arrive. Si le projet n'est pas ciblé, on risque de ne pas savoir exactement l'objectif et travailler sur une partie, ou l'autre, ou un peu des deux mais ne pas finir.

Monter une équipe dans sa ville. Travailler à distance est compliqué. Lorsqu'on recrute sur le net, on n'a aucune garantie que les personnes aux quatre coins de la France et de la Belgique sont fiables :
- Pourquoi sont-elles dans le projet ?
- Quelles sont les disponibilités ?
- Quel est le niveau réel de compétence ?
Lorsqu'on peut se rencontrer IRL, les projets avancent lus vite, la communication est facilitée, on voit tout de suite les personnes foireuses.

Ne pas se laisser emmerder par la technique. Le disque dur crash, le PC est volé, le projet est fini si on n'a pas de sauvegarde externe. C'est l'exemple extrême, mais au quotidien il faut aussi éviter les tracas, qui mis bout à bout font baisser les bras. On se crée un environnement de travail avec les bons outils :
- sauvegardes : en ligne, sur le serveur et aussi via un SVN/git
- captures d'écran : on lâche paint et printscreen, on utilise capturino par exemple
- un bon éditeur de code, avec coloration syntaxique
- on configure le PHP local pour qu'il soit identique à la config serveur
- on se crée les raccourcis sur le bureau pour lancer tous les logiciels facilement et ne pas chercher sur l'ordi à chaque fois
- on enregistre les liens vers de la doc utile (aide PHP, aide sur un framework, syntaxe MySQL...) pour les trouver rapidement
- dès qu'on a un bug d'install, de code, ... on cherche sur google pour le résoudre tout de suite au lieu de le subir

Utiliser du code pour gagner du temps. ça peut être un framework ou un logiciel de jeu open source, peu importe. L'idée est de créer un jeu, pas de perdre son temps à coder un site web ou un moteur de jeu. Avec ce code déjà là, on se consacre à l'essentiel : le jeu. ça évite de perdre la motivation sur l'inscription, la gestion de compte, créer un système de carte et de déplacement.
Au lieu de coder ces choses et d'y perdre de l'énergie ( = motivation), on se consacre au jeu en lui même, qui est une tâche beaucoup plus gratifiante.

Faire une chose à la fois, la plus importante en premier, terminer avant de passer à la suite. ça permet d'avancer sur des éléments importants dans le déroulement du projet, de ne pas se disperser et de ne pas revenir sans cesse sur la même chose. Terminer ça ne veut pas dire faire tout de A à Z, mais avoir la fonctionnalité voulue pour qu'elle marche, même si on ne sait pas encore régler les 50 options.

Se faire plaisir. La réalisation du projet doit rester un plaisir. Si faire le jeu devient pénible, on va lâcher l'affaire pour un autre projet ou une autre activité. Le plaisir de bosser sur le projet peut venir de :
- l'apprentissage
- des résultats visibles
- la réussite dans le travail en équipe
- barrer les éléments de la TODO liste

Se connaitre. Savoir :
- ce qui nous motive particulièrement
- ce qui nous démotive
- ce qui a fait rater les projets précédents
- ce qui a permis de réussir dans d'autres projets
On essayera d'amplifier les éléments positifs et de mettre de coté tout ce qui gêne le projet.

++

Pascal

[Colmea]

Pascal à tout dit :respect:

Après, c'est clair que ça dépend de chaque personne et de ses défauts.
Par exemple, dans mon cas, j'ai abandonné mon dernier projet parce que je n'arrivais pas à respecter le point: terminer avant de passer à la suite..
Et on se retrouve avec une moitié de jeu ou tous les modules sont fait, mais à moitié. Et là, quand on doit revenir après 1 mois sur un code fini à moitié, on se décourage et on ne veut plus entrer dedans (dans le code).

Donc, dans mon cas encore une fois, j'ai appris à me connaître. Désormais je sais que quand je commence un nouveau projet, je suis hyper motivé et j'ai envie de foncer tête baissée dans la prog de mon jeu. Or, c'est une grave erreur (elle m'a coûté l'abandon de mon dernier projet): il faut d'abord que je prépare tout avant de vraiment passer à la prog.

Ou sinon, sujet très intéressant :good:

[pascal]

Pour le codage en particulier, j'utilise une méthodologie en plus des points précédents :

Déjà, commencer par définir une fonctionnalité précise, ou un groupe de fonctionnalités cohérent. Ensuite, dessiner les écrans :
- soit sur papier, tout simplement
- soit avec un logiciel comme http://gomockingbird.com/ pour pouvoir partager les écrans avec les coéquipiers

Avec les écrans avant, on sait vers quoi on va. On peut avoir une idée de l'écran, mais si on ne l'exprime pas par un dessin on risque de perdre du temps lors de sa création, en oubliant / ajoutant des détails. Avec des écrans dessinés, on voit tout de suite si c'est cohérent, on peut se dire "si je clique là, il se passe ça". On gagne du temps.

Ensuite, savoir ce qu'il y a à coder, dans les différentes couches. On peut faire une liste :
- base de données : les tables à créer, les champs à ajouter
- les classes : attributs, méthodes
- les scripts utilisés pour lancer les fonctionnalités
- les écrans / parties d'écrans à créer

Soit une liste simple, soit sous forme de mind map. Personnellement j'utilise un peu les deux. La mind map pour une vue d'ensemble des différentes couches, les listes pour des détails plus terre à terre.

Pour coder, il n'y a pas 36 solutions. Je prévois 1 à 3 h par séance, j'évite autant que possible les sources de distraction et je suis la mind map et la liste. J'essaie d'obtenir :
- un résultat visible : coder une classe sans l'utiliser, c'est cool mais mieux avec le résultat concret de l'utilisation, car on peut naviguer dans le site (ce qui est motivant)
- un domaine traité : modéliser le schéma de données et créer les tables; coder les templates html des écrans

A la fin de la séance, je fais une revue des résultats obtenus et de ce qu'il reste à faire :
- les trucs pas tout à fait finis
- les fautes d'orthographe sur les écrans
- les bugs graphiques
- le refactoring pour respecter le système de couches

Je garde la liste pour la traiter en début de prochaine séance. ça permet :
- de savoir par quoi commencer la suite
- se remettre à coder tout doucement
- obtenir un bon résultat dès le début de séance
- terminer une partie du code et ne plus y revenir

La demie heure passée sur tout ça permet de s'échauffer, avancer et garder la motivation. On profite de la lancée pour attaquer la suite du code dans de bonnes conditions.

J'ai utilisé cette technique au boulot et pour coder CreaJeu (avec symfony).

++

Pascal

[Melimelo]

Très sympa le logiciel pour créer les écrans