Comment se déroule la conception architecturale dans un environnement agile?
J'ai lu Principes pour l'architecte agile , où ils ont défini les principes suivants:
Principe # 1 Les équipes qui codent le système conçoivent le système.
Principe # 2 Construire l'architecture la plus simple qui puisse fonctionner.
Principe # 3 En cas de doute, codez-le.
Principe # 4 Ils le construisent, ils le testent.
Principe # 5 Plus le système est gros, plus la piste est longue.
Principe # 6 L'architecture système est une collaboration de rôles.
Principe # 7 Il n'y a pas de monopole sur l'innovation.
Le document indique que la plupart de la conception de l'architecture se fait pendant la phase de codage, et seulement la conception du système avant cela. C'est bon.
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?
Disclaimer: Je suis architecte dans un environnement agile mais, comme le dit Helmuth von Moltke l'Ancien, "Pas de bataille le plan survit au contact de l'ennemi ". En d'autres termes, les aspects pratiques signifient que la lettre exacte des lignes directrices 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 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, plus le problème logistique de tous étant présents pour recueillir les exigences 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 principaux composants puis définit les interfaces entre eux (y compris les exigences non fonctionnelles comme la sécurité, la vitesse et la fiabilité) et délègue la conception interne des composants à des équipes individuelles . Il s'agit d'un bon compromis entre laisser les équipes concevoir leurs propres composants sans exiger que tout le monde sache 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 effectuée avant que l'équipe ne commence à coder ou le plus tôt possible et contient généralement (et n'est pas une liste complète):
- Elargissement des exigences et définition de la portée. Il s'agit notamment de cas d'utilisation ou de user stories qui étoffent les exigences métier de niveau supérieur. Personnellement, j'aime utiliser RFC 2119 pour les exigences non fonctionnelles. Le design est basé sur ces éléments et remonte à ceux-ci. Bien que cela ne corresponde pas à la définition commune du design, ceux-ci sont souvent tout aussi importants.
- Un aperçu composé d'un schéma de réseau ou de composants de haut niveau et d'une page de texte. Ceci est destiné à un public très large, de la haute direction au développement et au contrôle qualité. Cela utilise rarement UML ou une notation définie en raison du large public.
- Détails pour les composants individuels, se concentrant souvent 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 des détails de précondition et de postcondition. Les composants peuvent avoir des diagrammes de réseau, comme montrer la disposition des machines virtuelles dans un cloud ou un centre de données et leurs dispositions 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, s'ils sont connus. 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. Cependant, dans les environnements agiles, une partie moins importante de la conception est effectuée en amont et une plus grande partie est déléguée aux équipes de composants . La clé consiste à déterminer jusqu'où aller au départ, quelles décisions reporter et à déterminer quand les décisions doivent être prises. Les décisions qui affectent plusieurs équipes de développement doivent être prises plus tôt, en particulier l'évolutivité et la sécurité. Les décisions comme l'ajout de langues supplémentaires à un produit déjà internationalisé peuvent être différées jusqu'à très tard.
Une fois la conception initiale créée, l'architecte travaille avec chacune des équipes et examine leurs conceptions. Si une conception ou des modifications de conception supplémentaires sont nécessaires pour une unité de travail (comme un sprint de mêlée), l'architecte vise à la rendre disponible au moment où cette unité de travail commence. L'architecte est également responsable de la communication de tout changement aux équipes ou parties prenantes concernées.
Avertissement: je ne suis pas un coach/architecte agile - c'est ce que j'ai vu dans les projets agiles sur lesquels j'ai travaillé et je pense que cela fonctionne bien.
Je ne pense pas que la façon dont vous faites l'architecture soit tout à fait définie par Agile - Agile se concentre sur les méthodologies et pratiques de développement. UML d'autre part est juste un langage pour communiquer votre architecture qui est au-delà de l'agilité (vous l'utilisez s'il convient à votre projet et à votre équipe).
L'un des principes d'architecture qui s'applique vraiment, est de prendre la décision au dernier moment responsable possible - ce qui est bien si vous n'avez pas pris toutes les décisions au début du projet, d'autant plus que vous avez le moins d'informations à ce stade. Au fil du temps, vous pouvez prendre des décisions qui "font évoluer" l'architecture. Oui, cela pourrait ressembler à quelques retouches, mais cela est également dû au fait que vous avez appris de nouvelles choses sur l'environnement, les exigences, ce qui est possible ce qui ne l'est pas, etc.
La principale chose que vous voudriez éviter est la pourriture de l'architecture - où le code n'est pas vraiment conforme à n'importe quelle architecture particulière et n'est qu'un désordre embrouillé. La principale différence par rapport à l'évolution d'une architecture est que dans cette dernière, vous prenez périodiquement des décisions concises et les documentez avec des raisons claires, puis suivez pour vous assurer que votre code le suit.
Lorsque vous effectuez un développement piloté par les tests, vous créez un code de test qui teste vos modules de manière isolée (= aussi indépendant des autres modules que possible)
Pour faciliter la création de testingcode, vous introduisez des interfaces avec d'autres modules qui peuvent être facilement raillés.
De cette façon, comme un effet secondaire, vous obtenez automatiquement une architecture où le couplage entre les modules est aussi petit que possible.
À mon avis, tdd est aussi un travail architectural.