Exigences des architectes en dehors de l'équipe Scrum

Il y a quelque temps, on m'a demandé ce que je pensais de confier aux "Sages Architectes" d'une entreprise la supervision technique des différentes équipes projet. J'entends souvent l'argument selon lequel ces architectes ne font pas partie de l'équipe et ne devraient donc pas décider de la manière dont l'équipe développe quelque chose…

…mais ce n'est pas un argument très convaincant, car il y a suffisamment d'autres personnes externes qui imposent également des exigences à une équipe. Ces exigences sont cependant toujours filtrées par le Product Owner – c'est lui qui décide si elles sont importantes ou non.

« Les architectes avisés » ne font pas de propositions de solutions

Un "Architecte Sage" donne souvent à l'équipe des exigences non fonctionnelles, que je considère plutôt comme des contraintes ou des conditions. Il ne peut donc pas dicter à l'équipe comment résoudre un problème. En revanche, il peut définir certaines spécifications, par exemple : "Le système doit pouvoir monter en charge pour un certain nombre d'utilisateurs simultanés (utilisateurs qui accèdent au système en même temps)", "il doit traiter X transactions par minute", "il doit fonctionner sous Linux", "il doit pouvoir s'intégrer à tel ou tel système", etc.

Les exigences non fonctionnelles deviennent des Product Backlog Items et peuvent être priorisées par le Product Owner – selon l'importance qu'il leur accorde. Par exemple, s'il ne considère pas comme déterminant que le système fonctionne sous Linux et qu'il pourrait tout aussi bien fonctionner sur un autre système d'exploitation, le Product Owner peut supprimer cette exigence ou la déplacer vers le bas du Product Backlog (pour que l'équipe puisse au moins voir que l'architecte le souhaite).

Ce texte est tiré du blog de Mike Cohn et a été traduit par nos soins.