20-07-2007, 10:10 PM
Le processus qu'on suit avec les 4 autres membres de ma team de dev :
- au début définition du concept global, des axes du jeu, des possibilités offertes au joueur, et découpage en modules (beaucoup de discussions IRL et un peu de forum)
- établissement d'un planning définissant l'ordre dans lequel les modules seront ajoutés
Ensuite pour chaque module :
- discussions plus précises pour définir totalement les fonctionnalités du module (beaucoup de forum et un peu d'IRL)
- établissement d'un mini cahier des charges pour le module (pas par écrit mais par google doc, on est souvent par équipe de 2 sur un module, donc vive les applis de travail collaboratif à distance)
- création d'UML du module (au moins un diagramme de classes, éventuellement un diagramme de use cases et d'activité)
- implémentation
- tests (on essaie de coder par tests, donc la majeure partie d'entre eux sont écrits avant la fin, mais vu le temps que prend cette méthode on peut laisser quelques cas non traités pendant l'implémentation)
Sachant que pour essayer de rassembler des idées sur une période de temps la plus longue possible on commence à discuter du prochain module alors qu'on a à peine commencé à coder le précédent.
- au début définition du concept global, des axes du jeu, des possibilités offertes au joueur, et découpage en modules (beaucoup de discussions IRL et un peu de forum)
- établissement d'un planning définissant l'ordre dans lequel les modules seront ajoutés
Ensuite pour chaque module :
- discussions plus précises pour définir totalement les fonctionnalités du module (beaucoup de forum et un peu d'IRL)
- établissement d'un mini cahier des charges pour le module (pas par écrit mais par google doc, on est souvent par équipe de 2 sur un module, donc vive les applis de travail collaboratif à distance)
- création d'UML du module (au moins un diagramme de classes, éventuellement un diagramme de use cases et d'activité)
- implémentation
- tests (on essaie de coder par tests, donc la majeure partie d'entre eux sont écrits avant la fin, mais vu le temps que prend cette méthode on peut laisser quelques cas non traités pendant l'implémentation)
Sachant que pour essayer de rassembler des idées sur une période de temps la plus longue possible on commence à discuter du prochain module alors qu'on a à peine commencé à coder le précédent.