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.

[Drawingrom]

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

Il est d'usage d'utiliser un product backlog pour ce genre de chose.

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.

Là encore un product backlog peut partiellement couvrir ce besoin. Personnellement, je pense que des docs complémentaires pour préciser certaines fonctionnalités peuvent être utile. Exemple typique : un contrat d'interface. Mais ça dépend des cas.

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.

En effet, ça n'a pas de valeur métier donc il n'y a pas lieu de dépenser du temps dessus. Cependant il peut être utile de faire une analyse technique sur des points précis sans pour autant les mettre dans un document livrable, juste pour que l'équipe soit en phase avec ce qui est réalisé. Radicalement, on pourrait dire que la spec technique, c'est le code (et les tests unitaires).

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."

Si on parle de Scrum, ça me parait génant. On fixe le contenu d'un sprint et on livre ce contenu (en gros, on planifie sur 2 ou 3 semaines). Changer de scope tous les jours me semble difficile à gérer. Si tu parles qu'une spécification COMPLETE n'est pas nécessaire alors je suis d'accord avec toi.

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.

En lien avec ma réponse du dessus. Je ne sais pas comment tu peux assurer le contenu d'un sprint si tu permets que son scope change alors que celui-ci est en cours. Après, ça peut être possible, mais ça va dépendre de l'encadrement contractuel.

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.

C'est un point de vue plus technique. Si tu parles de java, sa verbosité permet de se passer de bcp de commentaires, ce qui est moins le cas pour un langage dynamique. La javadoc ne devrait être reservée aux API / bibliothèques réutilisables par l'équipe.

[Luckyluke34]

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.

Il s'agit pour moi d'une mauvaise interprétation du manifeste agile : "Working software over comprehensive documentation" n'a jamais voulu dire "Working software instead of documentation". Si l'équipe de développement a besoin de différents documents de conception, d'architecture... alors il est légitime qu'elle les ait. Invoquer Scrum ou l'agilité pour dire "on ne fait pas car ça prend trop de temps" est tout simplement fallacieux. Bien que les méthodes agiles recommandent de s'affranchir de la "dictature de la spec" qui donne un faux sentiment de contrôle et empêche la communication, il ne s'agit pas de tomber dans l'excès inverse. En résumé, la bonne quantité de doc, c'est juste ce qu'il faut de doc.

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."

Y-a-t-il un Product Owner intégré à l'équipe ? La condition sine qua non pour que cela marche est 1/ des spécifications minimales sous forme de user stories plus ou moins détaillées au départ et 2/ la présence à temps plein d'un représentant du client que les développeurs sollicitent en cours d'itération pour affiner les particularités de chaque user story. Il est de coutume de consigner quelque part ces détails supplémentaires mis au jour lors de la conversation avec le Product Owner : au dos de la carte représentant la user story, dans l'outil de gestion des exigences, dans une doc... On parle souvent de paradigme des 3 C (Card, Conversation, Confirmation).

Pour plus de détails sur les user stories, tu peux te référer à "User Stories Applied" de Mike Cohn ou aux différents livres sur eXtreme Programming de Kent Beck.

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.

Evoluer, c'est normal, tant qu'elle ne change pas du tout au tout ou qu'on ne substitue pas tout un pan de features à d'autres en cours d'itération. L'analyste / Product Owner n'est pas le détenteur d'une science infuse qu'il suffirait de plaquer sur les développeurs pour produire le code qu'il faut. La conversation entre développeur et Product Owner est un échange qui permet aussi de se rendre compte de choses que le PO n'avait pas imaginées auparavant et de faire émerger de nouveaux concepts ou d'en préciser d'autres. La gestion du changement est une des clés des méthodes agiles : plutôt que de s'entêter à respecter à la lettre un plan soi-disant parfait préparé à l'avance, on accepte la nature changeante du besoin et on s'adapte.

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.

Là on bascule plus du côté eXtreme Programming et pratiques d'ingénierie. La quantité de commentaires considérée comme suffisante en développement agile est en effet généralement basse. Entre un bloc de code avec des lignes de commentaires et le même bloc sans commentaires mais avec des noms de variables et méthodes suffisamment significatifs, la deuxième solution sera préférée car plus lisible, plus concise et moins "fouillis". L'idéal théorique est un code entièrement auto-descriptif, mais j'ai tendance à dire que le minimum est souvent de placer un commentaire au-dessus de chaque méthode et classe. En ce qui concerne la javadoc, à part pour une API qui sera diffusée en externe à l'organisation ou à des développeurs qui n'auront pas accès au sources dans un premier temps, j'ai rarement ressenti le besoin de la générer. Pour moi, les indications sur le code existant fournies par l'IDE lorsqu'on développe sont généralement suffisantes, et il y a d'autres manières plus efficaces d'explorer la base de code : par exemple, lire les tests unitaires.

[tchize_]

Je rejoint les points ci-dessus:
L'expression des besoins se trouve en grande partie dans le backlogs (user stories). L'analyse se retrouve via les task découpant les user stories du sprint en cours. Tout document dont l'équipe exprime le besoin d'existance doit exister. C'est le rôle du scrum master de s'assurer que l'équipe dispose de ce dont elle demande (dans les limites du raisonnables) pour pouvoir atteindre l'objectif du sprint. C'est le rôle de l'équipe de rédiger toute forme de document qu'elle juge utile. L'analyste, si il existe une personne dédiée à se role, devra assumer sa part. Si l'équipe juge inutile la rédaction de ce genre de document, on ne le rédige pas. Si l'équipe se plante parce que ce document en fait elle en avait besoin, la prochaine fois elle le demandera

L'absence de javadoc est une maivais pratique en terme général dont il est difficile de se défaire. Il est faux de prétendre que scrum dit qu'on doit pas documenter le code. Un code documenté est un code utilisable facilement.


Et dernier point: Scrum n'apporte pas la scélérité dans le développement d'un projet. Il permet juste de finir plus tôt un projet dans la mesure ou le client est souvent prêt à accepter une couverture de seulement 80% de ses besoins initiaux, si ces 80% représentent la quasi totalité de ses cas d'utilisation réguliers Les 20% restant étant dans la catégorie "rarement utilisé et cher à développer". Le but de scrum est surtout d'apporter au client ce qu'il veux et non pas ce qu'il a demandé

[montesq]

Le but de scrum est surtout d'apporter au client ce qu'il veux et non pas ce qu'il a demandé

Bonne remarque, je note cette idée, mais je la reformulerais plutôt en: "le but de scrum est surtout d'apporter au client ce dont il a besoin et non pas ce qu'il a demandé"

[tchize_]

exact

[grunt2000]

Aujourd'hui, notre situation est que notre équipe s'est autorisée - en accord avec ce que chacun d'entre-vous a admis dans cette discussion - de n'avoir aucun de ces documents puisqu'elle ne jugeait pas utile.
Elle compte effectivement sur le nom des méthodes, des variables et les tests expliquer son code.

Mais à mes yeux, cela produit un code de mauvaise qualité.

Il ne s'explique jamais aux nouveaux venus. Il réclame pour avoir des précisions une communication orale:
En effet, la ligne 214 du source ChaineDeFrabrication.java ne dit pas qu'elle est associée aux stories 114 et 220...

Puisque les développeurs ne documentent rien, quand le chef de projet demande "mais au fait, qu'avez-vous fait pour traiter tel chose [d'il y a un mois]"? Ils ne peuvent que répondre: "Je ne sais pas, il faut regarder."

Quand le programmeur B intervient après A dans une application, il la continue sans se soucier du design, puisqu'il n'y en a aucun d'établi.
S'il y en avait un, il y aurait un document.

Quand il faut énumérer l'ensemble des règles de gestion qui traitent d'un point précis, ce n'est pas possible:
1) Parce que comme la spécification fonctionnelle n'a jamais été rédigée en objet, les story ne sont pas vraiment des cas d'utilisation.

2) Parce que les services créés n'ont pas eu le temps d'être pensés et mêlent des tâches de domaines divers.

Donc, quand un utilisateur final réclame inquiet une vérification sur la réalité d'un traitement métier un peu conséquent,
- L'analyste fonctionnel doit retrouver des stories qui n'y correspondent qu'imparfaiement et ne peut pas avoir une vision cohérente d'ensemble qu'il aurait eu s'il avait pris le temps d'avoir un découpage en cas d'utilisation, acteurs et services, mais c'est trop tard.

- Les développeurs ne peuvent assurer que ce qu'il de ce qui se passe, puisque leur code n'est pas organisé dans une orientation métier, et qu'il faut pour comprendre les - mettons 5000 lignes - du code considéré le lire intégralement, y ajouter la lecture de ses tests unitaires, ce qui prend plus d'une journée car le code n'est ni commenté ni documenté.


Eh bien, pour le moment, cette technique de programmation n'a ni accru la célérité, ni réduit les besoin, ni permis de tenir les délais chez nous.

Si j'ai écrit ce message c'est que cette méthode agile que nous employons a diminué la production de notre équipe d'un facteur deux ou trois par rapport à ce que j'ai vu en cycle en V. Et cela a même eu des conséquences plus lourdes...

C'est l'obscurité et la lenteur générée par la méthode agile,
le manque de preuves (plutôt d'assurances) métier qu'elle donne sur ce qu'elle fait qui m'étonne.

Agile = un prétexte pour s'abstenir de réfléchir ?
= un moyen pour foncer dans le code (les développeurs adorent ça) sans cogiter une seconde.
= un moyen d'empiler des trucs sur d'autres trucs jusqu'à ce qu'un jour, ça tombe par manque de structuration.

Ce que je vois se dérouler devant moi me choque un peu.

[Drawingrom]

En même temps, Scrum ou l'agilité en générale ne dit pas qu'il faut laisser les problèmes s'installer et ne pas réagir .

S'il s'avère que plus de doc est nécessaire pour maintenir ou accroitre la vélocité de l'équipe, il faut décider de faire plus de doc.

Le principe d'avoir des cycles courts est qu'on peut réagir rapidement si on note des freins de productivité. Normalement, on fait des retrospectives en fin d'itération pour ça...

Tu relève aussi un manque de soin de la part des développeurs ayant mené à un code peu lisible. Tu auras la même chose avec du cycle en V, sauf que si tu as une spec tu te baseras dessus pour expliquer ce qui se passe (c'est un coup de poker, la spec doit être bien implémenté). Avoir une couverture de TU te permet toutefois de corriger assez facilement la situation par refactoring.

Je suis sur un projet qui a 10 ans d'ancienneté, en cycle de dev classique, il faut s'accrocher pour aller chercher des fonctionnalités quand tu trouves des fonctions C de 4000 lignes.

[tchize_]

Qu'en dit le Scrum master? Il doit bien les constater ces problèmes.

Les délais ne sont pas tenus -> Quelles ont été les réactions du product owner face à ça? Normalement, lors de la rétrospective après au moins deux sprints, on a déjà une idée de la durée globale du projet. A ce moment là si c'est partis pour 2 ans au lieu de 6 mois par rapport à l'évaluation de backlog, le product owner doit déjà se mettre à table avec l'équipe pour voir comment réduire son domaine de besoin afin de rester dans ses couts.

Rappel aussi: scrum est considéré comme une boite à outil (toolbox) PAS comme une méthodologie. Ca ne te dispense pas dans ton équipe d'avoir des méthodes de travail cohérentes et efficaces.

Par contre, j'ai tendance à ne pas associer de code à des backlog. De toutes facons, 2 mois après avec tous les refactoring, ca n'aura plus de sens. Par contre, chez moi, chaque "besoin" (issu d'un backlog ou de plusieurs réunis) est exprimé dans un unit test. Si le product owner fait entrer dans le backlog un spécialisation ou un précision d'un besoin "Machin chose doit macher exactemnt comme ça dans telle condition", je rajoute cet ensemble de condition au test unitiare, je le lance. Si ça casse, je corrige le code Parfois ca implique des gros changement dans l'architecture, parfois ça passe tout seul.

L'adequation de l'application avec le besoin du product owner, au final, se fait toujours lors de la phase de validation (a faire -> en cours -> fait -> validé). Le product owner est le seul à pouvoir faire passer un item de fait à validé. Si ce n'est pas fait, l'item est considéré comme non-fait en fin sprint.


L'analyse doit être faite, à différents niveaux:
En début de projet, avant de démarrer le sprint lorsque l'ont revoit l'ensemble des besoins avec le product owner. Bien qu'on aille pas dans les détails architecturaux, il faut consacrer quand même du temps à ça. Au minimum trois jours complet + des jours supplémentaire si le projet est estimé comme long. Le but est d'établir là la vision globale (language, méthodes de développement à employer, architecture matérielle prévue chez le client, restrictions de licences, controle nécessaire aux administrateurs, stratégie de backup, etc) ainsi que la direction que va prendre le projet.

Au début de chaque sprint, l'équipe consacre du temps à analyser et architecturer entre eux les items du backlog afin de sortir quelque chose de cohérent et de s'assurer que tout le monde va dans la même direction.


Là, avec ce que tu me décrit, j'ai l'impression de voir un scrum "chacun pour soi et tant pis pour le client", ça risque de ne pas marcher très fort J'ai aussi l'impression qu'il y a dans l'équipe un analyste fonctionnel dédié (normalemet en scrum le role le plus proche de l'analyste c'est le product owner) qui a oublié de faire une partie de son boulot ou mal fait. Si les besoin buisness sont mélangé dans tous les sens dans toutes les couches, c'est un peu sa faute quand même. Personellement, je suis plutot pas fanatique des logiciels multi couche, mais je ne suis pas fanatique du bordel non plus.

Je serais curieux de savoir
1) quelle est la taille de l'équipe (scrum master et product owner exclu)
2) dans cette équipe, quelle est la proportion de junior, senior et intermédiaire
3) qui choisit dans le product backlog les items qui feront partie du sprint

Scrum ne génère pas une obscurité, c'est le contraire, le but de scrum est de tout exposer au client si il le veux. Le manque de preuve d'adéquation avec le domaine buisness doit être vérifié par les test que fait le product owner (validation) en cours et en fin de sprint. Si ce n'est pas fait, forcément ca va etre dur à prouver. Et je t'assure que courir après le PO pour lui faire faire ses validations, c'est parfois à coup de fouets qu'il faut y aller. Il a souvent tendance à dire "non mais c'est bon continuez, je vérifierais plus tard"

Ceci dit: une spécification fonctionnelle de 500 page ce n'est pas non plus une preuve que l'application fonctionne suivant les besoin du client. J'ai eu un formateur scrum qui nous a expliqué qu'il a eu un projet de 2 millions $ avec une spec fonctionelle kilométrique. Le client ne voulait pas admettre qu'elle était inutile. Alors il l'a implémentée en 1 semaine en mettant simplement ensemble une masse de briques logicielles récupérée à gauche et à droit. Il est arrivé avec un logiciel qui ne faisait rien d'utile, mais qui implémentait 100% de la spec et lui a dit "vous me devez 2 millions. On passe en scrum maintenant?" La seule preuve que tu pourra jamais fournir à ton client, c'est un logiciel qu'il peux tester. D'ou l'intéret de lui fournir à chaque itération

[Luckyluke34]

Il ne s'explique jamais aux nouveaux venus. Il réclame pour avoir des précisions une communication orale:
En effet, la ligne 214 du source ChaineDeFrabrication.java ne dit pas qu'elle est associée aux stories 114 et 220...

Puisque les développeurs ne documentent rien, quand le chef de projet demande "mais au fait, qu'avez-vous fait pour traiter tel chose [d'il y a un mois]"? Ils ne peuvent que répondre: "Je ne sais pas, il faut regarder."

Une solution simple serait de traiter ça dans le gestionnaire de sources. Une pratique répandue consiste à mettre en commentaire de chaque commit le numéro de la user story ou des user stories concernées, de manière à pouvoir ressortir facilement par la suite ce qui a été fait et quand. C'est aussi valable pour les bugs.

Donc, quand un utilisateur final réclame inquiet une vérification sur la réalité d'un traitement métier un peu conséquent,
- L'analyste fonctionnel doit retrouver des stories qui n'y correspondent qu'imparfaiement et ne peut pas avoir une vision cohérente d'ensemble qu'il aurait eu s'il avait pris le temps d'avoir un découpage en cas d'utilisation, acteurs et services, mais c'est trop tard.

- Les développeurs ne peuvent assurer que ce qu'il de ce qui se passe, puisque leur code n'est pas organisé dans une orientation métier, et qu'il faut pour comprendre les - mettons 5000 lignes - du code considéré le lire intégralement, y ajouter la lecture de ses tests unitaires, ce qui prend plus d'une journée car le code n'est ni commenté ni documenté.

Pour les fonctionnalités conséquentes, on utilise souvent la notion de feature qui regroupe plusieurs stories (donc plus facile de les identifier). En revanche, je ne suis pas persuadé qu'un unique traitement métier devrait faire l'objet de plusieurs stories. Encore une fois aucune méthode agile n'empêche d'avoir des descriptions précises de règles métier très pointues dans ou à côté de la user story du moment qu'elles sont utiles.
D'autre part pour répondre aux enjeux de critères d'acceptation par le client (le 3è des 3 C) et de validation, on utilise souvent des tests d'acceptance de haut niveau, automatisés ou non, couplés aux TU.

Eh bien, pour le moment, cette technique de programmation n'a ni accru la célérité, ni réduit les besoin, ni permis de tenir les délais chez nous.

Même si sur le long terme on devrait noter une amélioration de l'efficacité de l'équipe, aucun de ces 3 effets ne sera obtenu miraculeusement par la simple utilisation de Scrum ou toute autre méthode agile. Ce qui disent le contraire sont juste des margoulins désireux de vendre des certifications ou du coaching.
Le bénéfice primordial et immédiat de Scrum à mon sens, c'est de livrer plus régulièrement, et de livrer précisément ce qui a le plus de valeur métier pour le client à l'instant T. Accomplir cela c'est déjà répondre en grande partie aux problèmes traditionnels des projets informatiques.

Si j'ai écrit ce message c'est que cette méthode agile que nous employons a diminué la production de notre équipe d'un facteur deux ou trois par rapport à ce que j'ai vu en cycle en V. Et cela a même eu des conséquences plus lourdes...

Ca parait énorme... En tout cas c'est le genre de choses qu'une équipe agile devrait constater et établir des actions à faire pour s'améliorer.

C'est l'obscurité et la lenteur générée par la méthode agile,
le manque de preuves (plutôt d'assurances) métier qu'elle donne sur ce qu'elle fait qui m'étonne.

Agile = un prétexte pour s'abstenir de réfléchir ?
= un moyen pour foncer dans le code (les développeurs adorent ça) sans cogiter une seconde.
= un moyen d'empiler des trucs sur d'autres trucs jusqu'à ce qu'un jour, ça tombe par manque de structuration.

Ce que je vois se dérouler devant moi me choque un peu.

Je trouve que les problèmes que tu évoques sont fortement liés à des pratiques de développement contestables et que partiellement à l'utilisation de Scrum ; et encore, à une mauvaise implémentation/interprétation de Scrum... Sinon, comme dit Drawingrom tu peux tirer parti de la méthode pour faire remonter tout cela en rétrospective