Je crois surtout que la plupart des dev open-source pensent, pour utiliser un euphémisme, que ce genre de chose n'a pas grand intérêt et que les entreprises les utilisent pour que le manager qui connait rien à l'informatique ait une vague idée de ce qui se passe...
Il y a premièrement beaucoup d'étudiants qui n'ont pas beaucoup d'expérience qui développent des logiciels libres et qui sont des "programmeurs intuitifs" qui ont appris la programmation tout seul, deuxièmement beaucoup de "petits logiciels" pour lesquels une spec claire et précise paraît moins utile, et enfin troisièmement beaucoup de logiciels qui sont des copies de logiciels existants pour lesquels les specs sont donc déjà claires : copier.
À première vue on peut penser qu'une spec c'est un truc chiant à faire, qui prend du temps et qui est inutile. Il ne faut pas oublier les autres intérêts d'une spec : c'est aussi un outil de communication vers les autres départements de l'entreprise (pour qu'ils soient au courant de la situation du produit dans 3/6/9 mois) et vers les clients (pour qu'ils voient si ça correspond à ce qu'ils veulent et anticipent de leur côté l'évolution de leur interface/utilisation). Le cycle en V a toute sa place ici. Ces deux aspects effectivement n'ont rien à faire dans les projets libres. Mais il y a aussi un autre intérêt : forcer une réflexion de plus haut niveau et être un outil de communication dans les équipes de développement. C'est utile mais pas dans les petits projets libres.
Enfin j'ajouterai que dans mon expérience personnelle (ingénieur en informatique, professionnel depuis presque 5 ans, et auteur de logiciels libres de seconde/troisième importance) je n'ai jamais réussi à faire correctement des specs détaillées, et de m'en tenir à celles-ci : au moment des spécifications je n'arrive tout simplement pas à "voir" toutes les implications de tous les choix. Au moment du codage je dois changer des choses. J'ai toujours pensé que la raison c'était que je n'étais pas assez fort. Certains m'ont dit que c'est une question d'expérience. Bref, donc maintenant je fuie les "spécs détaillées auxquelles on se tient" pour privilégier des approches de spécs partielles (les spécs fonctionnelles, celles qui décrivent l'interface utilisateur) ou les specs livrées après implémentation partielle. Mais bon je n'ai jamais participé à une équipe de développement avec beaucoup de gens qui travaillent tous sur la même chose.
[^] # Re: bof..
Posté par gc . En réponse au journal Conception et OpenSource. Évalué à 4.
Il y a premièrement beaucoup d'étudiants qui n'ont pas beaucoup d'expérience qui développent des logiciels libres et qui sont des "programmeurs intuitifs" qui ont appris la programmation tout seul, deuxièmement beaucoup de "petits logiciels" pour lesquels une spec claire et précise paraît moins utile, et enfin troisièmement beaucoup de logiciels qui sont des copies de logiciels existants pour lesquels les specs sont donc déjà claires : copier.
À première vue on peut penser qu'une spec c'est un truc chiant à faire, qui prend du temps et qui est inutile. Il ne faut pas oublier les autres intérêts d'une spec : c'est aussi un outil de communication vers les autres départements de l'entreprise (pour qu'ils soient au courant de la situation du produit dans 3/6/9 mois) et vers les clients (pour qu'ils voient si ça correspond à ce qu'ils veulent et anticipent de leur côté l'évolution de leur interface/utilisation). Le cycle en V a toute sa place ici. Ces deux aspects effectivement n'ont rien à faire dans les projets libres. Mais il y a aussi un autre intérêt : forcer une réflexion de plus haut niveau et être un outil de communication dans les équipes de développement. C'est utile mais pas dans les petits projets libres.
Enfin j'ajouterai que dans mon expérience personnelle (ingénieur en informatique, professionnel depuis presque 5 ans, et auteur de logiciels libres de seconde/troisième importance) je n'ai jamais réussi à faire correctement des specs détaillées, et de m'en tenir à celles-ci : au moment des spécifications je n'arrive tout simplement pas à "voir" toutes les implications de tous les choix. Au moment du codage je dois changer des choses. J'ai toujours pensé que la raison c'était que je n'étais pas assez fort. Certains m'ont dit que c'est une question d'expérience. Bref, donc maintenant je fuie les "spécs détaillées auxquelles on se tient" pour privilégier des approches de spécs partielles (les spécs fonctionnelles, celles qui décrivent l'interface utilisateur) ou les specs livrées après implémentation partielle. Mais bon je n'ai jamais participé à une équipe de développement avec beaucoup de gens qui travaillent tous sur la même chose.