Disclaimer: Je suis un architecte dans un environnement agile mais, comme le dit Helmuth von Moltke l'Ancien, "Aucun plan de bataille ne survit au contact de l'ennemi". En d’autres termes, les aspects pratiques signifient que la lettre exacte des directives ne peut pas toujours être suivie.
La plupart des points soulevés ci-dessus sont suivis du mieux que l’équipe peut. Cependant, le principe 1 (les équipes qui codent le système conçoivent le système) est vraiment difficile à suivre lorsque l’équipe est composée de dizaines (ou de centaines) de développeurs répartis sur différents continents et fuseaux horaires . Cela n’a rien à voir avec les compétences ou les attitudes des développeurs, mais surtout avec le problème logistique qu’ils rencontrent tous pour rassembler les besoins des clients et comprendre les systèmes complexes existants.
Alors, comment se fait la conception du système? Vous utilisez UML? Ou un document qui définit les interfaces et les blocs majeurs? Peut-être autre chose?
Souvent, l’architecte identifie les composants principaux, puis définit les interfaces entre eux (y compris les exigences non fonctionnelles telles que la sécurité, la rapidité et la fiabilité) et délègue la conception interne des composants à des équipes individuelles . C'est un bon compromis entre laisser les équipes concevoir leurs propres composants sans que tout le monde soit au courant de tout sur le système.
Chaque organisation a son propre ensemble de normes pour les conceptions architecturales et cela varie parfois d'un projet à l'autre au sein de l'organisation. Cette conception est effectuée avant que l'équipe commence à coder ou le plus tôt possible et contient généralement (et n'est pas une liste complète):
- Exigences étendues et définition de la portée. Ceux-ci incluent des cas d'utilisation ou des histoires d'utilisateurs qui étoffent les exigences professionnelles de niveau supérieur. Personnellement, j'aime bien utiliser la RFC 2119 pour des besoins non fonctionnels. Le design est basé sur ceux-ci. Bien que cela puisse ne pas correspondre à la définition commune du design, celles-ci sont souvent tout aussi importantes.
- Présentation comprenant un diagramme de réseau ou de composants de haut niveau et une page de texte. Ceci s'adresse à un très large public, de la haute direction aux développeurs et à l'assurance qualité. Cela utilise rarement UML ou une notation définie en raison de la large audience.
- Détails pour les composants individuels, en mettant souvent l'accent sur les interfaces ou les API entre eux, comme mentionné ci-dessus. Les interfaces peuvent être spécifiées en tant que signatures de méthode dans la langue cible avec les détails de précondition et de postcondition. Les composants peuvent avoir des diagrammes de réseau, tels qu'illustrer la disposition des ordinateurs virtuels dans un cloud ou un centre de données et leurs arrangements de mise en réseau. Les bases de données relationnelles auront généralement des diagrammes Entité-Relation.
- Une liste des risques architecturaux et de leurs atténuations, si elles sont connues. Comme les exigences, celles-ci démontrent les décisions de conception et les compromis.
En bref, la conception d'un système dans un processus agile est exactement la même que celle d'un processus en cascade traditionnel. Toutefois, dans les environnements agiles, la conception est moins complexe et plus complexe est déléguée à des équipes de composants . La clé est de déterminer la profondeur à laquelle il faut aller au départ, quelles décisions reporter et d'identifier le moment où les décisions doivent être prises. Les décisions qui ont un impact sur plusieurs équipes de développement doivent être prises plus tôt, notamment en ce qui concerne l'évolutivité et la sécurité. Les décisions telles que l'ajout de langues supplémentaires à un produit déjà internationalisé peuvent être différées très tard.
Une fois la conception initiale créée, l'architecte collabore avec chacune des équipes et examine leurs conceptions. Si des modifications supplémentaires de la conception ou de la conception sont nécessaires pour une unité de travail (telle qu'un sprint Scrum), l'architecte souhaite la rendre disponible avant le début de cette unité de travail. L'architecte est également responsable de la communication de tout changement aux équipes ou aux parties prenantes concernées.