Aujourd’hui, outre l’impartition et l’intégration de progiciels, une part importante du développement concerne les applications Web, généralement destinées à soutenir des services. Qu’en est-il de la rigueur de tels développements et des méthodes dites « agiles »?
La problématique
Le développement d’applications est de plus en plus complexe et celui des services Web n’y fait pas exception : le temps et les budgets alloués de plus en plus serrés; les besoins des utilisateurs de plus en plus vastes; les délais de plus enplus courts; les demandes de changement de plus en plus nombreuses et impératives; les risques inhérents sont de plus en plus cruciaux et doivent être gérés au cordeau.
Le fait de devoir disposer d’une méthodologie n’est plus une option, mais la difficulté est de choisir laquelle.
Les faits
En cette ère de rationalisation intensive des TI, le processus de développement des applications est sur la sellette, et la suprématie du Web n’y a rien changé. Aussi, les méthodes et les approches en tous genres se succèdent décennie après décennie. Depuis le début des années 90, c’est la rivalité, dans l’agora de la multitude des méthodologies quasi patrimoniales, entre les méthodes dites « unifiées » et les méthodes dites « agiles ».
L’évolution
Si le concept de développement agile est unique, les méthodologies agiles élaborées à partir du concept initial sont nombreuses. Elles regroupent, pour leur part, des méthodes comme XP, Crystal, FDD, Scrum, etc. Cependant, bon nombre des principes de base qui soutiennent toutes ces méthodes trouvent leur origine dans l’approche RAD Rapid Application Dévelopment initiée en son temps par James Martin, ce qui explique que ces méthodes disposent de certains préceptes de base communs et identiques.
Il s’agit surtout de la pratique du développement itératif et incrémental, du développement à base de composants, de l’établissement de bonnes communications entre l’équipe et les utilisateurs, de la gestion des risques et des exigences tout au long du projet, et de l’intégration des tests comme une pratique fréquente, essentielle et incontournable. Ces méthodes considèrent les tests comme intégrés au processus de développement et elles y ont recours de façon particulièrement intensive dans toutes les itérations. Une telle similarité parmi les méthodes ne pouvait que prêcher pour un rapprochement et une forme quelconque de collaboration des promoteurs.
Ainsi, en 2001, à Snowbird dans l’Utah, un séminaire a regroupé les principaux promoteurs de ces méthodes. C’est à cette occasion que les différents promoteurs ont entériné le vocable « agile ». Depuis, il existe un consortium, l’Agile Alliance (www.agilealliance.com). Ce consortium s’est donné comme mission de promouvoir l’approche agile des processus de développement et des méthodologies disponibles. L’Agile Alliance dispose d’un chapitre à Montréal – le Groupe d’utilisateurs Agiles de Montréal (www.agilemontreal.ca).
Le manifeste du développement agile
Les fondateurs de l’Alliance ont également produit un « Manifeste pour le développement agile », nommé Agile Manifesto. C’est un document qui traite des valeurs communes et des principes de base des processus de développement agile. Ce manifeste est donc la « Bible » de tous les développements et méthodes agiles (www.agilemanifesto.org).
Le Manifeste propose quatre valeurs fondamentales, qui prônent :
• De pratiquer plus l’interaction avec les personnes que de se concentrer sur des processus et des outils;
• De concentrer les efforts pour réaliser un produit opérationnel, plutôt qu’une documentation pléthorique;
• D’utiliser au maximum le temps disponible pour collaborer avec l’utilisateur, plutôt que pour négocier un contrat, aussi exhaustif soit-il;
• De faire preuve de beaucoup plus de souplesse et de réactivité face aux demandes de changement, plutôt que de s’en tenir au suivi d’un plan initial.
À la suite de ces quatre valeurs fondamentales, le Manifeste présente les douze principes de base du développement agile :
1- La priorité est de satisfaire l’utilisateur en lui livrant rapidement et régulièrement des logiciels utiles;
2- Les changements doivent être régulièrement acceptés, même s’ils interviennent tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour l’utilisateur;
3- S’astreindre à une livraison régulière et fréquente d’une application fonctionnelle. La fréquence recommandée va de deux semaines à deux mois, mais avec une préférence pour la période la plus courte;
4- Les spécialistes du métier et les développeurs doivent collaborer quotidiennement au projet;
5- Le projet doit être bâti en s’appuyant sur des personnes motivées. Il faut leur donner l’environnement et le soutien dont elles ont besoin, et croire en leur capacité à faire un travail de qualité;
6- Accepter comme axiome que la façon la plus efficace pour transmettre de l’information est une conversation en face à face;
7- Établir dans sa gestion qu’un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet;
8- Les processus agiles sont basés sur un rythme de développement calculé et soutenable. Les mandataires, les développeurs et les utilisateurs doivent pouvoir maintenir ce rythme indéfiniment;
9- Il est crucial de porter une attention particulière et continue à l’excellence technique et à la qualité de la conception, afin d’améliorer l’agilité;
10- Soutenir la simplicité et l’art de restreindre la quantité de travail à ne pas faire;
11- Promouvoir que les meilleures archi-tectures, spécifications et concep–tions sont issues d’équipes qui s’auto-organisent;
12- Il est nécessaire qu’à intervalles réguliers l’équipe de développement réfléchisse aux moyens disponibles pour devenir plus efficace, et implante ces changements dans son fonctionnement et son comportement.
L’utilisation des retours d’expérience
Les projets de développement agile utilisent les retours d’expérience pour améliorer le produit, la planification et le processus de développement. L’approche incrémentale offre régulièrement, à chaque fin d’incrémentation, des mesures sous la forme de points de retours d’expérience.
L’équipe utilise les retours d’expérience pour ajuster son intervention, essentiellement dans trois domaines. D’abord, elle les utilise pour les spécifications logicielles et leurs priorités. Le chef de projet fait une revue des fonctionnalités et en change les priorités pour l’incrémentation suivante. Ensuite, elle les utilise pour le périmètre fonctionnel, la date de livraison et les ressources. Le chef de projet mesure la vélocité des équipes de développement, puis les chefs d’équipe doivent affiner la valeur des efforts nécessaires pour les fonctionnalités restant à produire. Si nécessaire, le chef de projet ajuste le périmètre fonctionnel du projet et la date de livraison.
Enfin, l’équipe les utilisent pour les modes de travail de l’équipe. Elles permettent aux chefs d’équipe de faire une évaluation régulière des pratiques utilisées. Ils identifient les changements de pratiques à mettre en place et ce qui pourrait être abandonné sans nuire au développement.
Voici quelques-unes des principales approches agiles de développement:
XP, pour « Extreme Programming »
Proposée par Kent Beck, c’est la méthode la plus connue et peut-être la plus utilisée. Il faut bien reconnaître qu’elle a plusieurs aspects très positifs. Elle est assez facile à mettre en œuvre, parfois même au prix d’un changement de mentalité. Il s’agit ici d’appliquer « à l’extrême » les principes du développement agile en se concentrant sur les besoins de l’utilisateur, des individus, du développement itératif et de l’intégration continue.
Les développeurs et leurs relations avec les utilisateurs sont au cœur de cette méthode. Cette méthode peut sembler naturelle, mais elle réclame beaucoup de discipline et de communication. Il s’agit d’aller vite, sans perdre de vue la rigueur du codage et les fonctions finales de l’application. La grande force de XP est précisément sa simplicité, le fait qu’elle va à l’essentiel, selon un rythme qui reste constant et que tant les programmeurs que les utilisateurs pourraient poursuivre indéfiniment.
RUP, pour « Rational Unified Process »
RUP fut initialement élaborée par Rational Software, et plus particulièrement Philippe Kruchten. C’est une véritable méthode qui couvre l’ensemble du cycle de développement. Son étendue, son coût et sa lourdeur apparente la réservent pour les projets de taille assez importante. RUP fournit un cadre générique qu’il faut adapter à chaque application.
Moins « extrémiste » que XP, RUP donne en même temps une apparence plus rigoureuse, ce qui rassure certains utilisateurs habitués aux documentations exhaustives.
Crystal
Depuis les années 90, Alistair Cockburn est devenu le maître à penser des méthodologies de la famille Crystal. Les méthodes Crystal partagent avec XP l’orientation vers l’individu, mais le côté humain est abordé différemment. Crystal considère que les gens trouvent difficile de suivre un processus discipliné : plutôt que de leur imposer la rigueur du processus XP, Crystal explore les méthodologies les moins disciplinées et qui pourraient fonctionner, en favorisant la facilité d’exécution plutôt que la productivité.
FDD, pour « Feature Driven Development »
FDD a été développée par Jeff de Luca et par Peter Coad, un expert de l’orienté-objet. Comme toutes les méthodologies adaptatives, FDD se concentre sur des itérations courtes qui fournissent un résultat tangible sous la forme d’une fonctionnalité logicielle. Dans le cas de FDD, les itérations ont généralement une durée de deux semaines.
La conclusion
Le développement d’applications Web est fondamentalement « agile » dans son concept. Aussi, les méthodes de développements agiles y semblent bien adaptées, à la condition de disposer d’une équipe de développement suffisamment aguerrie à la pratique d’une telle méthode.
Mais attention à certains exégètes du Web qui pourraient se mettre à crier tout haut : « Pourquoi agile? Ne pourrait-on pas parler de développement 2.0? » Prudence avec la linguistique et le vocabulaire spécialisé! Une citation d’un texte de Jean-Pierre Wickoff, un spécialiste en la matière, pourrait être à propos : « […] Rappelons le principe du “nécessaire et suffisant ». En matière de projets, et plus particulièrement en ce qui concerne les développements informatiques, tout ce qui ne constitue pas la production d’un des composants utiles de l’application est une action parasite, aussi indispensable qu’elle puisse théoriquement paraître… »
Gérard Blanc est associé principal d’une firme conseil en gestion et en systèmes d’information.
