Je te propose d'essayer de commencer sans plan ni méthode, juste en tournant autour du sujet et en prenant des notes très courtes (pense à ces amateurs d'art qui tournent autour d'une statue dans les musées).
Laisse toi l'occasion de suivre tes propres pensées dans la façon dont tu aborde la conception. Ainsi, n'hésite pas à passer du coq à l'âne si tu en éprouve le besoin.
Au bout d'un certain temps (vu ton planning pas plus de 10 j) le besoin de structurer la démarche se fera sentir car tu commenceras à tourner en rond et à revenir sur des sentiers que tu as déjà emprunté.
C'est à ce moment là que l'aspect méthodologique se posera avec acuité ; et pour cause tu en auras vraiment besoin pour avancer !
Définir des méthodes et des cycles de conception avant de s'être plongé réellement dans le sujet est pour moi le meilleur moyen de perdre tout plaisir pour la suite d'un projet.
Et le plaisir, c'est quand même ce qui motive sur un projet non ? ;-)
Une chose n'est pas claire : à quel moment comptes-tu rencontrer l'utilisateur ?
Je vois bien des scénarii d'utilisation, et je suppose que leur validation se ferra lors de la dernière étape (itérative), comme cela se fait souvent. Mais si c'est bien cela que tu as prévu, la consultation des utilisateurs arrive trop tard : elle doit être faite à chaque étape depuis la définition du logiciel.
D'autre part, « Il ne reste plus qu'à coder tout ça avec Django » est une autre erreur : on ne choisit les outils à utiliser que tardivement dans le processus de développement, sinon tu risques de faire des choix motivés non pas par la qualité du programme, mais par la facilité de les réaliser avec les outils choisis. Particulièrement en fin de développement quand tu serra pressé par le temps...
Sinon, bon courage !
Que signifie "méthodes de développement agiles" ?
PS: je n'ai pas lu Getting Real, mais je devrais peut être ...
@NiCoS : merci pour tes conseils et tes encouragements :-).
@Christian Fauré : en fait j'ai commencé le projet depuis le 2 janvier donc c'est déjà un peu le résultat de cette réflexion préalable (je suis dedans jusqu'au cou ! ;-)).
@Clément Pillias : excellente remarques.
> à quel moment comptes-tu rencontrer l'utilisateur ?
À plusieurs niveaux mais c'est effectivement une bonne chose de programmer ces rencontres. La première étape de capitalisation doit initier cette relation.
> D'autre part, « Il ne reste plus qu'à coder tout ça avec Django » est une autre erreur
C'est vrai. Officiellement je choisirais le framework juste avant d'avoir défini les cycles itératifs mais officieusement je dois bien avouer que Django part avec un avantage certain : je connais très bien le framework et le langage.
@Eftarjin : ça demande un billet à part entière, il y a pas mal de documentation sur le net là-dessus en attendant, la page de Wikipédia à ce sujet est bien faite : fr.wikipedia.org/wiki/M%C...
En lisant ce post, toute cette démarche et cette façon de faire me faisait penser à XP (eXtreme Programming), méthode de dev sur laquelle il faut que je me penche depuis un petit moment. Et c'est grâce à ton lien vers wikipedia que j'ai pu voir que XP faisait parti des différentes méthodes agiles.
Est-ce à ce méthode-même que tu t'appliques ? ou est-ce à une autre ?
N'ayant pas lu Getting Real non plus, je ne connais pas encore grand chose à tout ça.
En tout cas bonne chance pour la suite ;)
PS : Voici un lien vers un dossier sur l'eXtreme Programming si y en a que ça intéresse : www.design-up.com/article...
"Django part avec un avantage certain : je connais très bien le framework et le langage."
Pfff prétentieux - si tu le connaissais tant et si bien que ça, tu aurais résolu mon souci depuis des lustes ;-)
Pour revenir à l'utilisateur, faut pas non plus tomber dans l'excès inverse à savoir lui présenter toutes les possibilités et à te mettre dans la mouise. Je pense qu'il faut privilégier une bonne prise en compte du/des besoins et ensuite lui proposer une réponse. C'est cette réponse qu'il faut éventuellement aménager avec l'utilisateur. Si tu commences à lui présenter toutes les possibilités, tu es cuit et ça va te bouffer tout ton temps.
@Aguillem : bon il faut vraiment que je fasse un billet là-dessus :-)
@NiCoS : oui je sais tu es todoisé ;-)
Pour les utilisateurs tout dépend du projet je pense et de l'importance du client sur l'application, enfin la modération a toujours du bon.
J'ai l'impression désagréable que tu cumules le chef de projet et le développement, le tout par une approche type XP.
Est-ce que l'entreprise où tu es a l'expérience de ce type de développement? Si non c'est une lourde responsabilité pour toi. Il y a donc un risque important de dérapage lorsque l'on est pionnier, et surtout de problèmes techniques "time consuming" si tu es seul. Mais d'un autre côté s'il y a risque et que cela se passe bien cela peut être très favorable pour toi dans cette entreprise.
J'espère au moins qu'il y a d'autres développeurs dans cette boite.
> Si non c'est une lourde responsabilité pour toi.
Oui, je sais bien, mais c'est aussi une grande liberté que j'apprécie chaque jour. Après il faut faire attention à beaucoup de choses pour pas déraper en s'imposant une certaine rigueur.
> J'espère au moins qu'il y a d'autres développeurs dans cette boite.
C'est le cas.
Pense aussi que ta stratégie de recette devra se faire AVANT les développements.
Ok c'est noté, merci pour toutes vos remarques :-).
Bonjour étant informaticien, je me demande exactement l'étape developpement,
Essayer UWE,
">Si non c'est une lourde responsabilité pour toi.
Oui, je sais bien, mais c'est aussi une grande liberté que j'apprécie chaque jour"
Salut,
Je suis un peu pessimiste devant tout cela car présentement c'est une situation où tu apprends seul et où il n'y a pas de procédure de développement mise en place (c'est ce qui sort de ton texte) et malheureusement je ne pense pas que cela est un bon environnement de travail.
Bonne journée
Alors, comment cela se passe? Tout se déroule comme attendu?
Pas exactement... il faudra que je fasse un nouveau billet là-dessus d'ailleurs ;-)
Article intéressant !
Merci pour cette méthodologie
Disclaimer : Je n'ai pas lu en détail getting real, seulement quelques passages donc mon point de vue n'est pas forcément le plus pertinent.
Pour ce que j'en ai lu (ainsi que du bouquin de Rails), c'est vrai que c'est très séduisant et qu'il y a de bonnes idées. Toutefois, je pense que c'est valable pour des projets pas trop gros et surtout au sein d'une équipe qui se connait parfaitement bien. J'ai pas dit non plus qu'il fallait faire 10.000 pages de specs hein, cela a aussi ses travers ;-)
Je pense que tu as cité le principal et qu'avec du bon sens, tu devrais t'en sortir :-)
ah oui et si tu fais "chef de projet" et dev à la fois, pense à relever la tête pour anticiper et voir si tu tiens tes délais & co ;-)