Suivi de la programmation par l'analyste

Explications fonctionnelles

Il arrive (et il est favorable) que le programmeur participe à certains ateliers avec les utilisateurs pendant le processus d'analyse. Ainsi, il a déjà une certaine connaissance du dossier avant même de commencer son travail. Mais l'analyste se doit de prendre une heure ou deux pour expliquer au programmeur ce qu'il a rédigé dans sa documentation. Le but n'est pas de lui faire la lecture (ce qu'il est capable), mais surtout d'expliquer au programmeur la vision, la solution fonctionnelle dans son ensemble et comment procéder pour savoir quelles étapes réaliser en premier. Le programmeur sait alors à quoi s'en tenir et peut évaluer le temps qu'il prendra pour réaliser le travail.

Demandes de précisions

L'analyste fonctionnel tente du mieux qu'il peut de couvrir un maximum de cas par sa solution. Or, il peut arriver que l'analyste n'ait pas précisé certains fonctionnements ou n'ait pas prévu, malgré lui, certains impacts sur le reste du système. Le programmeur est le premier à détecter ce genre de situation. Il en fait part à l'analyste fonctionnel, qui lui, doit trouver réponse. S'il connaissait déjà la réponse, il n'a qu'à le préciser au programmeur et mettre à jour son document. Sinon, il doit préciser le fonctionnement auprès des parties prenantes concernées, s'assurer que l'impact est minimal, aviser le programmeur, puis mettre à jour sa documentation. Dans le cas où une simple précision soulève chez certaines parties prenantes une envie de tout remettre en question, l'analyste se doit d'en faire part à son chargé de projet.

Retouches fonctionnelles

Dans la « chaîne de production », l'analyste fonctionnel a toujours une longueur d'avance sur le programmeur par rapport au dossier sur lequel il travaille. Autrement dit, pendant que l'analyste rédige un dossier fonctionnel, le programmeur produit du code sur le dossier précédent. Il se peut, en prenant les exigences pour son nouveau dossier, que l'analyste se rende compte qu'il aurait été mieux de faire certains ajustements aux autres dossiers existants, dont celui en cours de réalisation par le programmeur. Si à la suite d'une discussion avec le chargé de projet et le programmeur, cet ajustement peut bien s'intégrer à la programmation, l'analyste doit communiquer le détail de ces changements puis se doit encore une fois de maintenir sa documentation à jour.

Réactions aux contraintes techniques

L'analyste fonctionnel conçoit des solutions fonctionnelles. Souvent, il se valide auprès du programmeur pour s'assurer que la solution est réalisable techniquement. Mais le programmeur, de son côté, peut faire face à des difficultés en cours de réalisation. Par exemple, la librairie de composant ne fonctionne pas aussi bien que prévu, il peut avoir des limitations techniques au protocole de transfert utilisé ou au stockage sur une base de données. Ou encore, il pourrait détecter un problème de performance. En discutant ensemble, le programmeur et l'analyste peuvent convenir qu'il serait plus simple pour contourner le problème technique de modifier le comportement fonctionnel. Un atelier doit alors avoir lieu avec les parties prenantes et le chargé de projet pour voir s'il est possible de trouver un compromis.

Validation du fonctionnement

On dit, dans les bonnes pratiques, qu'un analyste et un programmeur devraient s'assoir ensemble 2 fois au minimum. Une première fois avant que le programmeur commence son travail, et une autre à la fin pour qu'il présente à l'analyste le résultat de son travail. Il n'est pas mauvais non plus que cette dernière opération, qui ne dure en réalité que quelques minutes, se reproduise plus régulièrement. L'analyste peut ainsi s'assurer de la compréhension du programmeur face au dossier et faire ses commentaires afin de s'assurer que les spécifications soient respectées.

Recherche de précisions

L'analyste fonctionnel peut travailler sur la modification d'un module applicatif existant et qu'il ait besoin de bien comprendre son fonctionnement avant de définir exactement ce qui doit être modifié. Si la documentation existante est incomplète ou désuète, il n'a pas d'autres choix que de demander au programmeur de trouver le code en lien avec ce qu'il recherche afin de bien voir quelle logique est appliquée.

Présentation aux utilisateurs

Après le développement de la solution, l'analyste et le programmeur peuvent être appelés à préparer et réaliser une présentation des nouvelles fonctionnalités aux parties prenantes en vue d'obtenir leurs commentaires.