Le développement agile

Le développement agile de logiciels n’est plus tellement une nouveauté, et des méthodes agiles se sont déjà bien établies dans de nombreux domaines. Pourtant, le phénomène reste encore flou pour beaucoup. À partir de quand y a-t-il agilité dans une société ? Et s’il ne s’agissait en fait que de travail traditionnel revalorisé avec un mot à la mode ?

Dès les années 1990, des équipes de développeurs ont commencé à travailler avec des méthodes qui s’apparentaient déjà à ce que l’on appelle aujourd’hui « développement de logiciel agile ». Jusqu’à la fin du 20^e siècle, différents développeurs et équipes de développeurs se sont attachés à alléger le travail de programmation ; c’est pourquoi la méthode était décrite principalement par la notion de légèreté (« lightweight »). C’est aussi à cette époque que sont apparues les méthodes Scrum et Kanban, qu’on ne désignait pas encore comme développement de produit agile car l’expression n’avait pas encore été créée.

C’est en 2001 qu’eut lieu un tournant : lors d’une réunion aujourd’hui connue sous le nom de « Snowbird meeting », du nom d’une station de ski dans l’Utah où elle se tenait, dix-sept développeurs ont rédigé le Manifeste agile. Ils y rassemblaient leur expérience dans le développement de logiciels et la gestion d’équipes, proposaient des solutions, établissaient des principes, et rassemblaient le tout sous la notion de « développement de logiciel agile », qui est devenue depuis emblématique des méthodes de travail modernes.

Lorsqu’on a commencé à se pencher en détail sur les méthodes de développement des logiciels, pour aboutir, avec le Manifeste agile, à un nouveau type de gestion de projet, l’objectif était toujours de pouvoir travailler de façon plus flexible, plus créative et plus productive. Au lieu de se conformer à une procédure planifiée, linéaire et bureaucratique comme avec les méthodes traditionnelles (par exemple le modèle en cascade, on fractionne le projet. Ce faisant, le développement agile confère à l’équipe de programmateurs une responsabilité bien plus importante.

Cette évolution est associée à un abandon plus ou moins marqué des projets de très grandes dimensions. Au lieu de passer des mois, voire des années, à la réalisation d’un produit, les équipes agiles travaillent par phases successives de quelques semaines seulement. Il en résulte un produit fini, une mise à jour ou une partie de programme qui peut être présenté au client. Pour y arriver, les auteurs du Manifeste agile se sont accordés sur une douzaine de principes et sur quatre valeurs.

Les valeurs du développement agile définissent les objectifs que doivent se fixer les équipes de développement et ne jamais perdre de vue. Elles sont données sous forme de paires opposées, les deux pôles de chaque paire conservant leur importance, mais le développement agile privilégiant l’une par rapport à l’autre.

• Individuals and interactions over processes and tools : les participants au projet et leur collaboration sont plus importants que la question d’une procédure ou d’un outil spécifique.
• Working software over comprehensive documentation : on se concentre sur le but, un produit final qui fonctionne. Quant à la documentation du travail, elle est considérée comme secondaire.
• Customer collaboration over contract negotiation : le développement agile se préoccupe d’abord de répondre au client et à ses exigences, moins de répondre à des obligations contractuelles.
• Responding to change over following a plan : on part du principe que le développement des logiciels doit tenir compte de modifications constantes. Cela peut impliquer de bousculer un planning établi à l’avance.

Ces valeurs sont à concevoir comme un mantra. Elles ne donnent pas d’instructions précises, elles sont plutôt destinées à rappeler constamment aux développeurs les aspects réellement importants de la production : travailler en équipe, se concentrer sur le logiciel, penser au client, faire toute sa place aux modifications ! Tous les autres aspects du travail de développement, même importants, sont subordonnés à ceux-ci.

Les douze principes du Manifeste agile sont, eux, plus concrets. Ils fournissent des éléments supplémentaires et élargissent les thématiques définies par les valeurs. Mais, là encore, il ne s’agit pas à proprement parler d’instructions, le Manifeste s’y refuse. Les principes sont définis de façon très générale et visent surtout à faire la différence entre les méthodes dites agiles et celles qui ne le sont pas.

• Satisfaction client : une publication précoce et continue, conformément à la notion de livraison continue (continuous delivery), doit assurer la satisfaction du client à tout moment.
• Flexibilité : les équipes agiles considèrent les modifications comme quelque chose de positif, même si elles n’apparaissent que tardivement dans le développement. Pour le Manifeste agile, il s’agit de toujours s’adapter aux exigences du client telles qu’elles évoluent, lui procurant ainsi un avantage compétitif.
• Livraison : les solutions sont livrées au client dès qu’elles ont atteint le stade opérationnel, à une fréquence allant de quelques semaines à quelques mois, et même moins, si possible.
• Travail en collaboration : les développeurs et leurs collègues des ventes doivent travailler en étroite collaboration. Le Manifeste agile prévoit des réunions quotidiennes.
• Soutien : pour permettre à des personnes motivées et à des équipes créatives de bien travailler, elles doivent bénéficier d’un environnement favorable. Pour cela, elles ont besoin du soutien des personnes qu’elles côtoient, et surtout de la confiance de la hiérarchie.
• Culture de l’échange : pour assurer un partage de l’information aussi efficace que possible et exempt de malentendus, la communication directe reste la meilleure option. Avoir une conversation en face à face permet de procéder à des mises au point fines et d’éviter les mauvaises décisions.
• Réussite : la réussite d’une équipe se mesure principalement à la publication de logiciels qui fonctionnent.
• Cadence de travail : on a tout avantage à assurer une bonne régularité dans le travail de développement. Et ce sont tous les participants au sens large, et pas seulement les développeurs eux-mêmes, qui doivent y contribuer.
• Qualité : par ailleurs, les développeurs doivent toujours veiller à ce que leurs produits répondent aux plus hautes exigences, aussi bien d'un point de vue technique qu’en matière de design.
• Simplicité : le travail doit être réalisé aussi simplement que possible, Laisser de côté tout ce qu’on peut éviter allège la procédure et donne de meilleurs résultats.
• Auto-organisation : ce n’est que lorsqu’on laisse les équipes s’organiser elles-mêmes qu’on peut s’attendre à des résultats qui sortent de l’ordinaire.
• Rétrospective : un aspect important du développement agile est la capacité à se remettre en question. Pour assurer une amélioration constante du travail de l’équipe, il est important que ses membres communiquent régulièrement sur leurs méthodes de travail et les ajustent en conséquence.

Dans le domaine du développement logiciel, un certain nombre de pratiques se sont établies, permettant la mise en œuvre de l’agilité dans une équipe ou une société, la notion de « développement agile » restant très générale. On retrouve beaucoup de ces méthodes dans des variantes du développement de logiciel agile, comme Scrum, le Kanban, l’extreme programming (XP) le développement basé sur les fonctionnalités (ou Feature-driven developement), le Behaviour Driven Development ou Chrystal.

• Backlog : la méthode agile se fonde en grande partie sur l’idée d’avoir un catalogue rassemblant toutes les tâches restant à accomplir, mais qui ne sont pas encore en cours. La raison en est la brièveté des phases de développement. Au lieu d’aborder plusieurs tâches simultanément, ou bien de planifier dans le temps chaque tâche dans un grand programme, on rassemble l’ensemble des tâches à réaliser dans ce qu’on appelle le « backlog produit ». C’est dans cet ensemble que l’équipe choisit la tâche suivante.
• Rétrospective : les réunions régulières ne sont pas seulement un principe abstrait de la méthode agile, elles s’imposent dans la pratique. On sait que la méthode Scrum en particulier planifie toutes sortes de réunions. Ce n’est que lorsque l’équipe discute régulièrement des challenges et des problèmes qu’elle peut s’améliorer sur le long terme.
• Récit utilisateur : on peut répondre à l’exigence de la concentration sur le client ou sur l’utilisateur par la technique des récits utilisateur. Il s’agit, avec ces « user stories », de décrire en termes simples ce que le client attend d’une fonctionnalité. Cette description est notée sur une « story card », laquelle est intégrée à une « story map ».
• Les tests agiles : dans la méthode de développement de logiciel agile, la phase de test est considérée comme faisant partie intégrante du processus de développement. Normalement, un produit se teste en équipe après chaque itération (chaque courte phase de travail) avant d’être validé et livré au client. Ce n’est qu’ensuite qu’on passe à la prochaine itération avec une nouvelle tâche.
• Programmation en binôme : la programmation en binôme applique le principe des quatre yeux. Cela consiste à faire partager un poste de travail par deux développeurs. Pendant que l’un écrit le code, l’autre contrôle le code saisi. Cela demande certes un plus grand investissement en temps, que le contrôleur pourrait passer à écrire du code lui-même, mais permet de réduire le nombre d’erreurs.
• Boîte temporelle : certaines formes de développement agile se fixent des délais très précis. Ici aussi, le Scrum est un bon exemple, les sprints (itérations) étant d’une durée bien précise. L’équipe doit livrer un produit fini en temps voulu. Cela nécessite de définir et de choisir les tâches de façon adéquate.

On rencontre dans les méthodes agiles beaucoup d’autres méthodes. Elles ont comme point commun de viser à une amélioration de l’efficacité et de la qualité du travail.

Les défenseurs du développement de logiciel agile disent volontiers que c’est la seule façon qu’il y a aujourd’hui de développer des produits. Pourtant, l’agilité n'est pas la bonne solution pour toutes les équipes et toutes les entreprises. En fonction de la situation de l'entreprise, les inconvénients peuvent dépasser les avantages.