Les méthodes de développement agiles sont, selon l’auteur, consultant et président de l’association toulousaine Sigma T, dédiée à la promotion de méthodes agiles, « un mouvement novateur ». Pourquoi ? Parce qu’elles « visent à apporter plus de valeur aux clients et aux utilisateurs, ainsi qu’une plus grande satisfaction dans leur travail aux membres de l’équipe ».
Une méthode agile est « une approche itérative et incrémentale pour le développement de logiciel, réalisé de manière très collaborative par des équipes responsabilisées, appliquant un cérémonial minimal et qui produisent un logiciel de grande qualité dans un délai contraint, répondant aux besoins changeants des utilisateurs », précise l’auteur, pour qui l’agilité constitue « une nouvelle culture du développement ».
Cet ouvrage est consacré à la méthode Scrum, apparue dans les années 1990 (les premières expérimentations datent de 1993). Qu’on le désigne comme un cadre, un processus ou une méthode, Scrum « définit des éléments qui feront partie du processus appliqué pour développer un produit ». L’approche est la suivante : les fonctionnalités souhaitées sont collectées dans le « backlog » (liste des tâches à effectuer) de produit et classées par priorités.
Scrum, le guide pratique de la méthode agile la plus populaire, par Claude Aubry, Dunod, 2010, 267 pages
C’est le « Product Owner » qui est responsable de la gestion de ce backlog. Ensuite, une version est produite par une série d’itérations, appelés « sprints ». « Le contenu d’un sprint est défini par l’équipe, avec le Product Owner, en tenant compte des priorités et de la capacité de l’équipe, note l’auteur. À partir de ce contenu, l’équipe identifie les tâches nécessaires et s’engage pour réaliser les fonctionnalités sélectionnées par le sprint. »
Durant les sprints, des points de contrôle sur le déroulement des tâches sont effectués lors de « scrums » (mêlées quotidiennes). « Cela permet au « ScrumMaster », l’animateur chargé de faire appliquer Scrum, de déterminer l’avancement par rapport aux engagements et d’appliquer, avec l’équipe, des ajustements pour assurer le succès du sprint », explique l’auteur.
Puis, à la fin de chaque sprint, l’équipe obtient un produit partiel (un « incrément ») qui fonctionne et qui est potentiellement livrable.
L’usage de l’approche Scrum a été tardif en France, mais le succès est indéniable. En 2009, un millier d’équipes de développement utilisaient Scrum, contre moins d’une dizaine en 2005. L’un des freins à l’utilisation de Scrum reste le découpage entre MOA et MOE.
Cela contribue en effet à privilégier la communication basée sur des documents au détriment de la communication orale, des spécifications trop détaillées dès le début du projet, des documents redondants entre les deux entités, qui mélangent le pourquoi et le comment.
En outre, ce découpage occasionne « du temps perdu dans un processus de validation de documentation, et des tests d’acceptation passés tardivement ». « Il convient de faire tomber les murs et de créer une seule équipe qui contribue au même objectif, qui n’est pas d’écrire de la documentation », précise l’auteur qui reste persuadé que « renoncer aux bienfaits de l’agilité plutôt que d’essayer d’impliquer plus la MOA, c’est prendre le problème à l’envers ».
Une autre difficulté concerne les modes contractuels, en particulier une éventuelle contradiction entre agilité et contrat au forfait. Ce malentendu vient de l’idée que « le périmètre fonctionnel semble être fixé à l’avance par le client , note l’auteur. Mais c’est un leurre. Dans la réalité, le périmètre n’est pas strictement défini au début du projet et évolue toujours. »
Pour rendre les contrats plus agiles, l’auteur suggère par exemple de décomposer l’appel d’offres en deux parties (une première pour évaluer la capacité du fournisseurs, une deuxième avec un engagement d’agilité), de rédiger un contrat avec une enveloppe fixée et un périmètre évalué par morceaux (comme pour la TMA avec la notion d’unités d’œuvre), ou encore de rédiger un contrat de façon habituelle mais en introduisant la possibilité de changer d’avis sans que cela remette en cause le contrat ni les prix.
Le backlog de produit étant un élément essentiel de la démarche Scrum, il peut, selon les caractéristiques du projet, être annexé à l’appel d’offres.
« L’agilité permet de s’adapter plus vite au changement. Cependant, tous les environnements des organisations ne sont pas turbulents. En tout cas, il y en a qui sont moins soumis aux changements que d’autres, qui ne sont pas dans un milieu concurrentiel, ajoute l’auteur. Cela ne signifie pas que l’agilité n’est pas nécessaire à ces projets et ces organisations, mais que la façon de l’appliquer doit être adaptée à leur contexte. »