Prenons un instant pour réfléchir au processus de construction d’une maison. La première étape consiste en une communication des besoins de la part du propriétaire. En se basant sur ces lignes directrices, des plans peuvent ensuite être produits afin de définir comment la construction pourra être réalisée pour arriver au résultat voulu dans le temps planifié.
Le domaine du développement logiciel traditionnel a suivi cette même manière de faire. Avant l’arrivée de l’Agilité, les analystes et les architectes avaient comme mandat de définir comment le produit allait être construit de A à Z. Encore aujourd’hui, on peut fréquemment voir des projets investir de 10% à 20% du temps de réalisation dans l’analyse et la prise de besoins, pour ensuite passer un autre 10% à 20% de la durée totale du projet à l’étape du design et de l’architecture du système. On parle donc de presque 40% du temps qui est déjà investi alors qu’aucune ligne de code n’a encore été écrite.
C’est une étape très coûteuse si on la compare à son équivalent dans le cadre de la construction d’une maison. On peut même trouver des plans gratuits sur Internet aujourd’hui!
L’étape d’implémentation qui suit le développement est également beaucoup plus risquée que dans le cas d’une maison. En effet, il est rare de trouver le plan d’un bâtiment pour lequel on ignore si les murs tiendront debout ou si le toit ne s’effondrera pas sous son propre poids. Alors qu’en développement logiciel, il est fréquent d’avoir à changer de direction parce que nous avons appris qu’une composante n’était pas compatible avec les besoins que nous avions.
Changement de direction ai-je bien dit? Alors pourquoi ne pas réaliser le projet de manière Agile? Bonne idée! D’accord, regardons le manifeste Agile de plus près pour nous imprégner de sa philosophie.
Le Manifeste Agile
Trois des quatre valeurs du manifeste Agile affectent la vision qu’on peut avoir de l’architecture et de l’analyse d’un projet :
- Des logiciels opérationnels plus qu’une documentation exhaustive;
- La collaboration avec les clients plus que la négociation contractuelle;
- L’adaptation au changement plus que le suivi d’un plan.
Ces points priorisent une solution tangible qu’on peut tester plutôt que d’avoir un plan qui détaille le résultat global qu’on doit atteindre à la fin. Pourquoi? Parce que peu importe l’effort qu’on investit dans la planification, tout peut changer d’une journée à l’autre.
Il faut donc bien s’outiller pour ce changement. Sinon, on se retrouve à utiliser les pratiques de l’Agilité, sans en retirer les bienfaits. Pour réussir une transition et avoir une bonne opinion à tous les niveaux d’une entreprise, il est important de maximiser les avantages. Ensuite, en fournissant une simple comparaison entre l’« avant » et l’ « après » la transition, tous peuvent voir facilement pourquoi cette décision a été prise et personne ne veut retourner en arrière.
Si on veut une version du logiciel opérationnelle à partir du premier sprint, il est logique de s’assurer que le travail de tous les membres de l’équipe est réalisé au même rythme que le développement. Dans le cas des analystes et des architectes, cela soulève un défi particulier, car leur apport au projet est traditionnellement nécessaire avant même que les programmeurs n’écrivent une ligne de code. On leur annonce maintenant qu’ils n’ont aucune préparation possible, qu’ils doivent maîtriser la matière dès le début.
Comment peut-on s’y prendre? Est-ce que cela implique que les architectes doivent travailler jour et nuit dans les premiers jours de l’itération pour s’assurer que l’équipe a ce qu’il lui faut afin de réaliser son travail dans les jours suivants?
Si on suit les principes de l’Agilité, les architectes font partie d’une équipe qui est responsable de livrer un résultat à la fin de l’itération. Alors, pourquoi diviser les équipes en silos tandis que nous pouvons tous collaborer pour arriver au même résultat?
Architecture Émergente
À l’opposé d’avoir un design complet avant la phase de programmation, l’architecture émergente encourage la mise en place des pièces d’infrastructure du logiciel en même temps que sa construction.
Il est évidemment irréaliste de penser qu’on peut commencer à développer sans avoir pris quelques décisions au préalable. Par exemple, les choix du langage, de certaines librairies et des couches architecturales de base doivent être faits pour éviter que chacun des membres de l’équipe ne s’engage sur un chemin qui ne pourra pas être consolidé par la suite.
C’est pourquoi il est primordial de trouver seulement ce qui est « juste assez » (just enough) pour lancer les travaux de développement et de s’attaquer à ces exigences en premier. En collaboration avec le Product Owner, on peut utiliser différents outils comme : une charte de projet, un user story mapping, un diagramme de séquence ou encore un diagramme de couches afin de définir les critères d’affaires et les considérations techniques qui impacteront comment le logiciel sera construit.
Si vous n’avez jamais fait d’analyse ou d’architecture émergente, sachez que comme avec toute bonne transition, vos habitudes peuvent être changées. Donc pour y arriver, il vous faudra de la discipline pour suivre des principes qui peuvent paraître simplistes à première vue, mais qui feront une bonne différence sur le long terme.
Principes de l’architecture émergente
Penser grand, à petits pas. Échouer rapidement, et apprendre aussitôt…
On le voit dans les concours de groupes, comme les « hackathons » par exemple. Une équipe n’a pas d’autre choix que de viser un résultat exceptionnel pour être en mesure de compétitionner avec les autres. Par contre, pour y arriver, tous doivent s’y mettre pour trouver les petites étapes qui dresseront un chemin réaliste vers ce but commun qui leur permettra d’atteindre la première place.
La même vision doit être adoptée pour un projet. Les partenaires voudront avoir un logiciel qui fait toute la différence, mais la confiance des membres de l’équipe ne doit pas être déstabilisée par une barre qui peut sembler trop haute. Il faut garder une attitude positive devant chaque défi parce que le pire qui peut arriver sera de ne faire qu’un seul échec : la livraison finale. Voilà pourquoi il est nécessaire de découper en étapes plus petites. De cette façon, les échecs seront aussi petits et l’apprentissage qui vient avec eux bonifiera considérablement l’évolution de l’équipe et tous pourront le constater avec le résultat final.
Le dernier moment responsable
Plus une décision est prise tôt, plus elle est risquée car elle peut changer à tout moment et entraîner une chaîne de conséquences sur d’autres fonctionnalités, d’autres modules ou même d’autres équipes. Si un retour est fait sur ces changements, on constate que le coût de ce choix était énorme, alors que si elle avait été prise plus tard, lorsque l’équipe en avait réellement besoin, la décision aurait été prise avec une meilleure vision.
Le concept qui représente cette réalité se nomme le cône d’incertitude. Pour bien l’illustrer, nous pouvons penser à la cartographie de la trajectoire d’un ouragan ou d’un cyclone.
Le cyclone tropical Irène
Plus nous regardons loin dans le temps afin de prédire la trajectoire, plus le cône s’élargit. On peut l’expliquer par la difficulté de savoir s’il y aura un changement de température ou un front d’air qui viendra affecter le chemin que la tempête suit. Le même concept s’applique dans le développement logiciel : plus nous essayons de nous appuyer sur ce qui se passera dans le futur pour prendre nos décisions, plus celles-ci risquent de changer.
Il est difficile de trouver le moment précis où on doit prendre une décision. C’est pourquoi l’équipe, incluant le Product Owner, doit utiliser son jugement et en discuter ouvertement et avec transparence. Il faut trouver le bon équilibre entre le moment présent et ce qui pourrait arriver, en faisant attention de ne pas regarder trop loin.
Livrer l’incrément opérationnel le plus simple possible
L’objectif de ce point est d’avoir le plus petit incrément possible, avec lequel on peut expérimenter et sur lequel on peut développer itérativement pour répondre aux exigences une à une.
Les besoins doivent donc être minimisés de manière à pouvoir valider les hypothèses sans se lancer dans des jours d’efforts inutiles. Le Product Owner amènera de grosses fonctionnalités, les programmeurs en feront plus que prévu, mais tous doivent être vigilants pour ne pas perdre de vue les petites étapes qui doivent être franchies une à la fois.
Le Lean Startup suit justement cette pratique en amenant le concept de MVP (Minimum Viable Product). Le but reste de toujours garder en tête l’objectif d’affaires en priorité et de s’assurer que l’utilisateur reste satisfait de ce qu’il a entre les mains, même si ce n’est pas complet.
Cette approche permet d’éviter d’investir beaucoup d’efforts dans une solution qui risque d’être différente de ce qui était requis à la base. De plus, le produit pourra être démontré dès les premiers jours, maximisant sa visibilité et permettant d’aller chercher plus de clientèle.
Une fois la première version livrée, les autres qui viennent par la suite donnent l’opportunité de faire avancer le produit de manière itérative (en le rendant meilleur) et de manière incrémentale (en ajoutant des fonctionnalités).
Inévitablement, le moment viendra où l’équipe fera face à des problèmes l’empêchant de prendre des décisions d’architecture ou de design. Ceux-ci sont souvent dus à l’incertitude, ou à un risque trop grand face à une technologie peu connue de tous.
Pour mieux comprendre comment composer avec ces problèmes, je vous invite à lire la suite de cet article : Spikes et architecture émergente.
The post L’Architecture Agile : Mais où sont les plans? appeared first on Blogue Savoir Agile.
