23-05-2010, 01:22 PM
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
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