Initialement introduite par l’Extreme Programming, il existe une technique qui consiste à ajouter un élément au carnet de produit (product backlog) qu’on peut qualifier de « Spike ». Il s’agit d’un item pour lequel l’équipe s’entend sur une limite de temps à investir. Le but est d’acquérir des connaissances qui sont nécessaires pour réduire le risque, pour comprendre une exigence ou pour améliorer la précision d’une estimation sur un autre élément du carnet.
Il existe deux types de spikes : techniques et fonctionnels. Les spikes fonctionnels servent principalement à mieux comprendre un comportement requis de l’application pour être en mesure de mieux le découper, ou simplement de s’outiller pour pouvoir prendre de meilleures décisions d’implémentation. Les spikes techniques servent à comprendre la technologie pour déterminer la faisabilité et les répercussions de certaines implémentations qui doivent être réalisées.
Les spikes sont utilisés dans différentes situations :
- Dans l’intention d’analyser le comportement touché pour mieux découper les tâches et les estimer plus facilement.
- Pour analyser la faisabilité et déterminer la viabilité des plus gros éléments du carnet (Epics).
- Afin de faire une recherche de base pour se familiariser avec une nouvelle technologie ou un nouveau domaine d’affaires.
- Dans le but d’acquérir de la confiance dans une approche (technique ou fonctionnelle) pour réduire le risque ou l’incertitude.
Il est important de noter qu’un spike doit seulement s’intéresser au problème concerné et ignorer tout autre point d’incertitude. C’est la raison pour laquelle le code qui en résulte est rarement conservé dans les sources finales du logiciel, et il faut tenir pour acquis qu’il s’agit d’un code éphémère, qui terminera fort probablement aux poubelles.
Architecture en colonnes et non en couches
Le fait de se concentrer seulement sur le minimum requis pour chaque fonctionnalité à implémenter n’implique pas nécessairement que l’architecture de l’application restera minimale.
Cependant, un changement est exigé sur la manière de bâtir l’infrastructure. Le réflexe du développeur traditionnel est de réaliser une conception en couches, en ayant une couche pour la base de données, une couche pour accéder aux données, une couche pour la logique d’affaires et une couche pour la présentation de ces données.
Dans un contexte d’architecture émergente (Emergent Design), l’architecture doit se construire un peu à chaque sprint. On sera donc en mesure de tester un lien de la couche de la base de données jusqu’à la couche de présentation dès le premier sprint. De cette manière, l’équipe peut très tôt tester tous les niveaux de l’infrastructure et mettre en place des fonctionnalités complètes, sans attendre que toutes les parties impliquées aient terminé leur morceau.
Il est donc primordial d’avoir une structure incluant toutes les couches dès le début, mais elle doit être constamment définie et modifiée à travers le processus de développement qui s’effectue à petits pas. Chacun de ces pas est une chance de rester à la fine pointe de la technologie (autant en infrastructure qu’en ergonomie) sans avoir à subir de grosses répercussions dans le cas où le choix dont on a convenu n’était pas le bon.
Le rôle de l’architecte Agile
En voyant comment l’architecture peut se construire de façon verticale, on comprend que le rôle de l’architecte est différent lorsqu’on tombe dans un mode Agile. Plutôt que d’avoir la mainmise sur les décisions technologiques, l’architecte Agile se doit d’agir comme un expert ou un mentor présent auprès de l’équipe pour l’accompagner dans un développement qui satisfera les exigences.
L’architecte n’a pas seulement un rôle d’accompagnateur ; il reste également responsable de la définition et du maintien de la structure de la solution. Nous pouvons séparer son rôle en cinq parties :
Comprendre les exigences
Comme il est généralement plus expérimenté, l’architecte se doit de bien maîtriser l’analyse des exigences pour pouvoir participer à la stratégie de développement du produit, tout en s’assurant d’en retirer tous les points qui peuvent avoir une répercussion sur la définition de l’architecture.
Formuler le design
Son expertise permet aussi d’avoir une vision globale de la solution pour s’assurer de définir une structure qui permettra de ne pas augmenter la complexité inutilement. En travail collaboratif avec le responsable de produit (Product Owner), il peut alors maintenir un équilibre entre les objectifs et les contraintes de la solution.
Communiquer l’architecture
Il doit aussi s’assurer que tous comprennent bien la structure, peu importe leur niveau d’expérience et de connaissances. Chacun peut avoir un point de vue différent, l’architecte doit donc s’assurer de présenter plusieurs facettes du système pour adapter l’information selon le type d’auditoire des différentes équipes.
Soutenir les développeurs
Il est important d’avoir une structure bien définie, mais elle doit surtout être réalisable. L’architecte doit donc offrir du mentorat et avoir une implication directe dans le développement pour être rapidement informé des bloqueurs et aider les membres de l’équipe pour les résoudre.
Vérifier l’implémentation
Dès la première version livrée du logiciel, l’architecte effectue une veille technologique de ce qui a été programmé. Il doit vérifier que le code livré est cohérent avec l’architecture qui a été communiquée, et qu’il respecte les exigences qui ont été prises en charge par les fonctionnalités ajoutées.
Ces rôles doivent changer au fur et à mesure que le projet avance. En fait, c’est l’accent de l’architecte qui doit se modeler selon le niveau de maturité de chacune des parties de l’architecture du système. L’architecte peut donc remplir plusieurs rôles, et sa charge de travail peut souvent être répartie sur différents membres de l’équipe pour éviter de garder une seule source d’information.
Tout le monde change avec le temps. En partageant les différentes tâches, les préférences et les compétences de chacun évoluent, et certains peuvent alors être plus motivés par la possibilité de s’occuper de certaines parties de l’évolution du système. Par exemple, quelqu’un qui a une plus grande aisance pour expliquer les concepts aux gens d’affaires peut participer à la stratégie, alors qu’une autre personne avec des connaissances techniques approfondies peut s’impliquer beaucoup plus dans la création du design et sa communication à l’équipe.
Accepter le changement
Dans un mode Agile, l’architecte est le principal responsable des changements et de la gestion de la complexité qu’ils apportent, alors que les autres développeurs doivent quant à eux se concentrer sur la prochaine version.
Naturellement, dans un système complexe, on ne peut laisser quiconque apporter n’importe quel changement à n’importe quel moment. Tout comme il serait illogique de laisser n’importe quel membre de la famille détruire n’importe quel mur de la maison…
Il y a trois dangers principaux lorsqu’on a une trop grande facilité à accepter le changement :
- Mise au rancart et gaspillage des fonctionnalités, car les changements d’exigences étaient trop fréquents et instables.
- Perte de stabilité du système dans sa globalité, comme si l’édifice entier était en train de s’écrouler.
- Développement de la complexité, alors que les changements ont été apportés sans abstraire aucun niveau du concept. Nous perdons alors cette facilité qui nous permet de mieux réutiliser un code existant ou d’en faire un remaniement (refactoring) plus rapide.
En gardant un équilibre dans la gestion des changements qui ont des répercussions sur l’équipe, l’architecte agit comme le champion de la solution, et il a la responsabilité de le demeurer. Il doit bien vendre sa vision à chaque personne, qu’elle soit interne ou externe au projet, pour que tous comprennent bien comment ce qui est en place vient satisfaire chaque exigence, et la raison pour laquelle les changements sont entrepris dans cette direction.
Quelques conseils…
Pour que l’architecture émergente soit efficace :
- Utilisez des pratiques, des patrons de conception et des principes communs à l’équipe.
- Remaniez (refactoring) pour vous assurer que la complexité et la qualité restent à des niveaux acceptables.
- Testez tôt, souvent et automatiquement.
- Mettez en place une gestion du cycle de vie des applications (Application Lifecycle Management) [si vous utilisez Team Foundation Server, Done Techno donne un avantage intéressant pour la gestion Agile du travail à réaliser].
- Faites des déploiements fréquents.
N’oubliez pas, ce sont les premiers pas qui demandent une adaptation. Ensuite, la marche se déroule de mieux en mieux, et on peut même éventuellement se permettre de courir…
Bon développement !
N’hésitez pas à nous consulter pour en savoir d’avantage: connectez avec nous.
Ainsi que nos autres divisions d’affaires : Pyxis
