Discussion :

[grunt2000]

Bonjour,


Les projets de l'entreprise pour laquelle je travaille sont fait en méthode agile et SCRUM. Ce choix a été fait pour rechercher de la célérité, du dynamisme.

La méthode Agile est réputée pour limiter la documentation produite. Et aujourd'hui, voici ce qui se passe:

1) Il n'y a pas de document d'expression des besoins.

2) Il y a une spécification métier (analyse fonctionnelle), non objet (qui ne décrit pas les objets métiers et services eux-mêmes, et ne connait pas la notion de cas d'utilisation), qui a le quart de la taille de celles que je rencontrais auparavant en cycle en V.

3) La traduction de cette spécification fonctionnelle (métier) en cas d'utilisations, objets métiers et services dans un document dédié n'a pas lieu: ce serait un document technique, de conception ou d'architecture - selon comment on le comprend - dont la réalisation serait coûteuse en temps.

4) Il est d'usage que les développeurs débutent le codage avant que la spécification fonctionnelle ne soit terminée, car il est de bon ton, en Agile, que "le développeur n'attende pas la spécification pour programmer. Qu'il s'adapte."

5) Au cours du développement, la spécification fonctionnelle de ce que l'on souhaite livrer évolue en parallèle réclamant des synchronisations pour prendre en compte ses changements: lors de l'itération n, la partie spécification liée au lot n peut évoluer de nombreuses fois au cours du développement. Ce lot n partira en recette à un instant où spécification fonctionnelle et code produit sembleront synchrones et stables.
Il arrive que l'analyste fonctionnel vienne auprès du développeur et fasse sa spécification à l'oral, car la sienne n'est pas complète: s'il s'en souvient, il reportera ce qu'il a dit au développeur dans son document de spécification.

6) Il n'y a pas nécessité de placer ni javadoc ni commentaires dans le code source. Il semble qu'il s'agisse là encore de documentation un peu superflue, qui limite la vitesse d'implémentation.


Est-ce vraiment comme cela que cela doit se passer?


En vous remerciant,

Grunt.

[hegros]

Est-ce vraiment comme cela que cela doit se passer?

oui et non.

Non, parce que rien ne t'empêche d'avoir des itérations (sprint pour parler scrum) qui concerneraient des objectifs de définition des spécifications avec des stories comme "décrire la fonctionnalité x" comportant des tâches comme "écrire les scénarios nominaux et de tests", "réaliser un diagramme d'architecture général" etc... En effet, Scrum ne connaît pas de phases que se soit spécification ou codage.

Oui, parce que les expériences ont montré que ce n'est pas parce que tu as 1 million de documentations que le projet va mieux réussir et que cela sera plus facile à développer. On peut documenter à posteriori. La documentation permet surtout comme son nom l'indique de documenter et de sceller de la connaissance alors que dans une équipe qui se parle tout le temps et tout les jours il n'y a pas ce besoin.