Nous sommes d'accord que tu parles ici de documents purement destinés aux développeurs ?
Personnellement, mon premier niveau d'analyse consiste à réduire la tâche en autant de sous features que possible : il faut des tâches à échelle humaine. Cela passe par de la pure réflexion, sans outil particulier. Quelles sont les parties qui composent cette tâche ? Qu'est-ce qui peut faire sens tout seul ? Une fois fait, je déduis les spécifications purement sur la base du résultat escompté : la feature doit permettre de faire ci, ce qui implique que telle autre feature doit prendre en compte que ça, et une fois que si se produit, ça doit survenir derrière. Mon principal outil ici est ... les issues github :) (enfin gitlab, mais c'est pareil). Si aucun design n'a été produit, je fais un rapide mockup dans mon browser en modifiant une page existante avec l'inspector chrome, afin de fournir dans l'issue un screenshot du résultat attendu. Ensuite, le développeur qui prend l'issue "développe", au sens littéraire ou philosophique : il prend une idée abstraite et en déduis les conséquences immédiates, puis prend chacune de ces conséquences et en déduis les conséquences immédiates, jusqu'à arriver au dernier niveau de détail, qui est l'architecture finale. Concrêtement, ça veut dire qu'il implémente d'abord les features spec en décrivant ce qu'il doit se passer. Une fois fait, il écrit ce qui sera la base de la view et répond aux attentes de la feature spec (qui ne peut pas être exécutée à ce point, mais indique tout ce dont on a besoin). L'écriture de la vue indique ce que le controller doit fournir, ce qui permet l'écriture des specs de controller, ce qui permet l'écriture du controller, ce qui indique ce que le model doit fournir, ce qui permet d'écrire les specs du modèle, puis le modèle, et enfin la structure de la db. C'est un processus naturel qui s'applique bien à la réactivité nécessaire de l'environement startup, je ne sais pas si ce serait applicable dans une relation intervenant / client (je faisais signer des user stories impératives, à l'époque où j'étais freelance, donc c'était mon outil principal d'architecturage, mais le "développement" restait le même). On Monday, October 13, 2014 4:37:06 PM UTC+2, Guirec Corbel wrote: > > Bonjour, > > J'aimerai savoir avec quels outils vous faites vos analyses. Comme > beaucoup, à l'école, j'ai appris l'UML et les MCD mais je trouve ces > outils trop lourd. J'aime bien faire des scénarios et des wireframes > pour décrire les besoins du client mais ça ne décrit pas l'architecture > à adopter. Je pense que j'aurais plutôt tendance à faire des schémas sur > un tableau blanc ou sur une feuille de papier et a m'adapter au fil du > temps. > > Et vous, vous faites comment? > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
