Le dé­ve­lop­pe­ment agile

Le dé­ve­lop­pe­ment 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 tra­di­tion­nel re­va­lo­risé avec un mot à la mode ?

Dès les années 1990, des équipes de dé­ve­lop­peurs ont commencé à tra­vail­ler avec des méthodes qui s’ap­pa­ren­taient déjà à ce que l’on appelle aujourd’hui « dé­ve­lop­pe­ment de logiciel agile ». Jusqu’à la fin du 20^e siècle, dif­fé­rents dé­ve­lop­peurs et équipes de dé­ve­lop­peurs se sont attachés à alléger le travail de pro­gram­ma­tion ; c’est pourquoi la méthode était décrite prin­ci­pa­le­ment par la notion de légèreté (« light­weight »). C’est aussi à cette époque que sont apparues les méthodes Scrum et Kanban, qu’on ne désignait pas encore comme dé­ve­lop­pe­ment de produit agile car l’ex­pres­sion 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é­ve­lop­peurs ont rédigé le Manifeste agile. Ils y ras­sem­blaient leur ex­pé­rience dans le dé­ve­lop­pe­ment de logiciels et la gestion d’équipes, pro­po­saient des solutions, éta­blis­saient des principes, et ras­sem­blaient le tout sous la notion de « dé­ve­lop­pe­ment de logiciel agile », qui est devenue depuis em­blé­ma­tique des méthodes de travail modernes.

Lorsqu’on a commencé à se pencher en détail sur les méthodes de dé­ve­lop­pe­ment des logiciels, pour aboutir, avec le Manifeste agile, à un nouveau type de gestion de projet, l’objectif était toujours de pouvoir tra­vail­ler de façon plus flexible, plus créative et plus pro­duc­tive. Au lieu de se conformer à une procédure planifiée, linéaire et bu­reau­cra­tique comme avec les méthodes tra­di­tion­nelles (par exemple le modèle en cascade, on frac­tionne le projet. Ce faisant, le dé­ve­lop­pe­ment agile confère à l’équipe de pro­gram­ma­teurs une res­pon­sa­bi­lité bien plus im­por­tante.

Cette évolution est associée à un abandon plus ou moins marqué des projets de très grandes di­men­sions. Au lieu de passer des mois, voire des années, à la réa­li­sa­tion d’un produit, les équipes agiles tra­vail­lent par phases suc­ces­sives 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é­ve­lop­pe­ment agile dé­fi­nis­sent les objectifs que doivent se fixer les équipes de dé­ve­lop­pe­ment et ne jamais perdre de vue. Elles sont données sous forme de paires opposées, les deux pôles de chaque paire con­ser­vant leur im­por­tance, mais le dé­ve­lop­pe­ment agile pri­vi­lé­giant l’une par rapport à l’autre.

• In­di­vi­duals and in­te­rac­tions over processes and tools : les par­ti­ci­pants au projet et leur col­la­bo­ra­tion sont plus im­por­tants que la question d’une procédure ou d’un outil spé­ci­fique.
• Working software over com­pre­hen­sive do­cu­men­ta­tion : on se concentre sur le but, un produit final qui fonc­tionne. Quant à la do­cu­men­ta­tion du travail, elle est con­si­dé­rée comme se­con­daire.
• Customer col­la­bo­ra­tion over contract ne­go­tia­tion : le dé­ve­lop­pe­ment agile se préoccupe d’abord de répondre au client et à ses exigences, moins de répondre à des obli­ga­tions con­trac­tuelles.
• Res­pon­ding to change over following a plan : on part du principe que le dé­ve­lop­pe­ment des logiciels doit tenir compte de mo­di­fi­ca­tions cons­tantes. Cela peut impliquer de bousculer un planning établi à l’avance.

Ces valeurs sont à concevoir comme un mantra. Elles ne donnent pas d’ins­truc­tions précises, elles sont plutôt destinées à rappeler cons­tam­ment aux dé­ve­lop­peurs les aspects réel­le­ment im­por­tants de la pro­duc­tion : tra­vail­ler en équipe, se con­cen­trer sur le logiciel, penser au client, faire toute sa place aux mo­di­fi­ca­tions ! Tous les autres aspects du travail de dé­ve­lop­pe­ment, même im­por­tants, sont su­bor­don­nés à ceux-ci.

Les douze principes du Manifeste agile sont, eux, plus concrets. Ils four­nis­sent des éléments sup­plé­men­taires et élar­gis­sent les thé­ma­tiques définies par les valeurs. Mais, là encore, il ne s’agit pas à pro­pre­ment parler d’ins­truc­tions, le Manifeste s’y refuse. Les principes sont définis de façon très générale et visent surtout à faire la dif­fé­rence entre les méthodes dites agiles et celles qui ne le sont pas.

• Sa­tis­fac­tion client : une pu­bli­ca­tion précoce et continue, con­for­mé­ment à la notion de livraison continue (con­ti­nuous delivery), doit assurer la sa­tis­fac­tion du client à tout moment.
• Flexi­bi­lité : les équipes agiles con­si­dè­rent les mo­di­fi­ca­tions comme quelque chose de positif, même si elles n’ap­pa­rais­sent que tar­di­ve­ment dans le dé­ve­lop­pe­ment. Pour le Manifeste agile, il s’agit de toujours s’adapter aux exigences du client telles qu’elles évoluent, lui procurant ainsi un avantage com­pé­ti­tif.
• Livraison : les solutions sont livrées au client dès qu’elles ont atteint le stade opé­ra­tion­nel, à une fréquence allant de quelques semaines à quelques mois, et même moins, si possible.
• Travail en col­la­bo­ra­tion : les dé­ve­lop­peurs et leurs collègues des ventes doivent tra­vail­ler en étroite col­la­bo­ra­tion. Le Manifeste agile prévoit des réunions quo­ti­diennes.
• Soutien : pour permettre à des personnes motivées et à des équipes créatives de bien tra­vail­ler, elles doivent bé­né­fi­cier d’un en­vi­ron­ne­ment favorable. Pour cela, elles ont besoin du soutien des personnes qu’elles côtoient, et surtout de la confiance de la hié­rar­chie.
• Culture de l’échange : pour assurer un partage de l’in­for­ma­tion aussi efficace que possible et exempt de ma­len­ten­dus, la com­mu­ni­ca­tion directe reste la meilleure option. Avoir une con­ver­sa­tion 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 prin­ci­pa­le­ment à la pu­bli­ca­tion de logiciels qui fonc­tion­nent.
• Cadence de travail : on a tout avantage à assurer une bonne ré­gu­la­rité dans le travail de dé­ve­lop­pe­ment. Et ce sont tous les par­ti­ci­pants au sens large, et pas seulement les dé­ve­lop­peurs eux-mêmes, qui doivent y con­tri­buer.
• Qualité : par ailleurs, les dé­ve­lop­peurs 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.
• Sim­pli­cité : le travail doit être réalisé aussi sim­ple­ment que possible, Laisser de côté tout ce qu’on peut éviter allège la procédure et donne de meilleurs résultats.
• Auto-or­ga­ni­sa­tion : 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é­tros­pec­tive : un aspect important du dé­ve­lop­pe­ment agile est la capacité à se remettre en question. Pour assurer une amé­lio­ra­tion constante du travail de l’équipe, il est important que ses membres com­mu­ni­quent ré­gu­liè­re­ment sur leurs méthodes de travail et les ajustent en con­sé­quence.

Dans le domaine du dé­ve­lop­pe­ment logiciel, un certain nombre de pratiques se sont établies, per­met­tant la mise en œuvre de l’agilité dans une équipe ou une société, la notion de « dé­ve­lop­pe­ment agile » restant très générale. On retrouve beaucoup de ces méthodes dans des variantes du dé­ve­lop­pe­ment de logiciel agile, comme Scrum, le Kanban, l’extreme pro­gram­ming (XP) le dé­ve­lop­pe­ment basé sur les fonc­tion­na­li­tés (ou Feature-driven de­ve­lo­pe­ment), le Behaviour Driven De­ve­lop­ment ou Chrystal.

• Backlog : la méthode agile se fonde en grande partie sur l’idée d’avoir un catalogue ras­sem­blant 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é­ve­lop­pe­ment. Au lieu d’aborder plusieurs tâches si­mul­ta­né­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é­tros­pec­tive : les réunions ré­gu­liè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 par­ti­cu­lier planifie toutes sortes de réunions. Ce n’est que lorsque l’équipe discute ré­gu­liè­re­ment des chal­lenges et des problèmes qu’elle peut s’améliorer sur le long terme.
• Récit uti­li­sa­teur : on peut répondre à l’exigence de la con­cen­tra­tion sur le client ou sur l’uti­li­sa­teur par la technique des récits uti­li­sa­teur. Il s’agit, avec ces « user stories », de décrire en termes simples ce que le client attend d’une fonc­tion­na­lité. Cette des­crip­tion est notée sur une « story card », laquelle est intégrée à une « story map ».
• Les tests agiles : dans la méthode de dé­ve­lop­pe­ment de logiciel agile, la phase de test est con­si­dé­rée comme faisant partie in­té­grante du processus de dé­ve­lop­pe­ment. Nor­ma­le­ment, 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.
• Pro­gram­ma­tion en binôme : la pro­gram­ma­tion en binôme applique le principe des quatre yeux. Cela consiste à faire partager un poste de travail par deux dé­ve­lop­peurs. Pendant que l’un écrit le code, l’autre contrôle le code saisi. Cela demande certes un plus grand in­ves­tis­se­ment en temps, que le con­trô­leur pourrait passer à écrire du code lui-même, mais permet de réduire le nombre d’erreurs.
• Boîte tem­po­relle : certaines formes de dé­ve­lop­pe­ment agile se fixent des délais très précis. Ici aussi, le Scrum est un bon exemple, les sprints (ité­ra­tions) é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é­lio­ra­tion de l’ef­fi­ca­cité et de la qualité du travail.

Les dé­fen­seurs du dé­ve­lop­pe­ment de logiciel agile disent vo­lon­tiers que c’est la seule façon qu’il y a aujourd’hui de dé­ve­lop­per des produits. Pourtant, l’agilité n'est pas la bonne solution pour toutes les équipes et toutes les en­tre­prises. En fonction de la situation de l'en­tre­prise, les in­con­vé­nients peuvent dépasser les avantages.