Damien Thouvenin, CLT-Services
Von hibattery, 03:15Damien Thouvenin - Le choix d'utiliser des méthodes agiles n'a pas été si simple, ça a même été un long chemin ! Disons que la réflexion a débuté lors d'une vie antérieure. Je travaillais dans une autre entreprise où nous étions confrontés à des problématiques de criticité. On avait besoin d'avoir confiance en nos projets, de les livrer dans les délais, notamment. C'était il y a une dizaine d'années et nous avons découvert sur internet un petit groupe qui testait ses logiciels « en cours de développement ». Ils utilisaient en fait l'Extreme Programing. Nous avons dans un premier temps commencé à prendre des petits bouts de cette méthode avant de l'employer complètement.
DT - On va surtout répondre à des besoins de tenue des délais. Avec des méthodes de développement plus traditionnelles, on s'aperçoit que la livraison du produit est souvent reportée, qu'il y un véritable glissement dans les plannings. On s'aperçoit même parfois que très peu de projets sont menés à terme. Ensuite, on va produire un logiciel qui va être immédiatement opérationnel pour les utilisateurs. agile pose comme idée que le seul but d'un logiciel est d'être utilisé et que pour y arriver, il ne faut pas séparer les informaticiens des utilisateurs. Disons qu'avec la méthode traditionnelle, les rôles sont plus cloisonnés et on a plus d'intermédiaires. Avec la méthode agile, la communication entre les informaticiens et les utilisateurs se fait en face à face. La démarche est très transversale puisqu'on fait appel aux utilisateurs, on a donc affaire à de gens du marketing, de l'électronique ou en encore de la qualité. En restaurant la communication en face à face, on évite aussi les effets pervers du téléphone arabe.
DT - Avec des méthodes traditionnelles, on va tout planifier de bout en bout du projet. Il y a notamment un gros travail d'analyse préalable au lancement du projet. Toutes les actions, toutes les phases du développement sont planifiées dans leurs moindres détails. Le problème c'est qu'un changement d'environnement fait partie de la vie d'un projet et aura un impact sur son déroulement. Si on ne peut pas ajuster son programme en fonction des événements, on prend tout de suite du retard. Je fais souvent l'analogie avec une randonnée en montagne. Si vous partez simplement avec une paire de baskets et une bouteille d'eau en vous disant que vous voulez atteindre un sommet, ça ne va pas fonctionner. Si vous partez en ayant regardé la météo 15 jours avant et que vous avez prévu vos moindres actions, en vous disant que vous allez franchir un ruisseau à 17h12 et pivoter de 8° pour atteindre le refuge à 18h10, il y des chances que ça ne se passe pas comme prévu non plus. Avec les méthodes agiles, on va se dire qu'on va procéder étape par étape, et qu'on va pouvoir changer ses plans en fonction de la météo. On est par pour autant dans l'improvisation, mais on va travailler par emboîtements successifs.
DT - Si on fait exactement la même chose, le coût du développement est à peu près le même que l'on utilise une méthode traditionnelle ou une méthode agile. Par contre, le retour sur investissement est meilleur avec une méthode agile. Comme nous faisons du développement itératif, nous livrons une première version utilisable au client le plus tôt possible. Nous développons ensuite une deuxième version lorsque les utilisateurs en ont besoin.
Il n'y a pas de baguette magique, si on fait la même chose ça coûte le même prix. Mais dans la pratique, on fait moins de travail en agile car l'approche pilotée par l'utilité du logiciel élimine beaucoup de fonctions qui seraient dans un cahier des charges classique « au cas où ». Un développement agile coûte donc moins pour un même service rendu. Après ça, il y a un deuxième facteur qui entre en ligne de compte c'est que les projets sont souvent contraints par le budget : en agile on va donc continuer à consommer tout le budget, la plupart du temps, mais pour le prix on aura plus de fonctionnalités.
DT - Nous avons des clients qui connaissent ces méthodes, et c'est pour cela qu'ils viennent nous voir. Mais nous avons aussi des clients qui ne connaissent pas du tout ces méthodes. En fait, nous fournissons deux types de prestations aux entreprises : le développement de logiciels sur-mesure et depuis quelques temps nous faisons du conseil et de la formation. Typiquement, je sors d'une entreprise qui avait de gros problèmes de délais et qui a dû reporter plusieurs fois la sortie d'un produit parce que tout ne s'était pas passé comme prévu. Nous sommes intervenus pour leur expliquer comment marche l'agile.
Pour les entreprises qui ne connaissent pas ses méthodes, c'est sûr que c'est un changement culturel, il a y a forcément des freins et il y a de toutes façons un travail de conduite du changement. Et puis les entreprises ne réagissent pas toutes de la même façon. Je distingue deux groupes, les entreprises qui ont la culture de la solution à un problème donné et celles qui ont la culture du coupable. Évidemment, celles qui ont la culture de la solution sont plus réceptives aux méthodes agiles. Dans les démarches agiles, on donne le droit à l'erreur. On ne travaille pas pour autant sans filet, mais disons que l'approche est plus heuristique et plus pragmatique. On va créer des îlots de stabilité dans un monde mouvant en combinant à la fois une réponse aux besoins des utilisateurs et en étant plus souples sur les détails pratiques.
DT - On va surtout répondre à des besoins de tenue des délais. Avec des méthodes de développement plus traditionnelles, on s'aperçoit que la livraison du produit est souvent reportée, qu'il y un véritable glissement dans les plannings. On s'aperçoit même parfois que très peu de projets sont menés à terme. Ensuite, on va produire un logiciel qui va être immédiatement opérationnel pour les utilisateurs. agile pose comme idée que le seul but d'un logiciel est d'être utilisé et que pour y arriver, il ne faut pas séparer les informaticiens des utilisateurs. Disons qu'avec la méthode traditionnelle, les rôles sont plus cloisonnés et on a plus d'intermédiaires. Avec la méthode agile, la communication entre les informaticiens et les utilisateurs se fait en face à face. La démarche est très transversale puisqu'on fait appel aux utilisateurs, on a donc affaire à de gens du marketing, de l'électronique ou en encore de la qualité. En restaurant la communication en face à face, on évite aussi les effets pervers du téléphone arabe.
DT - Avec des méthodes traditionnelles, on va tout planifier de bout en bout du projet. Il y a notamment un gros travail d'analyse préalable au lancement du projet. Toutes les actions, toutes les phases du développement sont planifiées dans leurs moindres détails. Le problème c'est qu'un changement d'environnement fait partie de la vie d'un projet et aura un impact sur son déroulement. Si on ne peut pas ajuster son programme en fonction des événements, on prend tout de suite du retard. Je fais souvent l'analogie avec une randonnée en montagne. Si vous partez simplement avec une paire de baskets et une bouteille d'eau en vous disant que vous voulez atteindre un sommet, ça ne va pas fonctionner. Si vous partez en ayant regardé la météo 15 jours avant et que vous avez prévu vos moindres actions, en vous disant que vous allez franchir un ruisseau à 17h12 et pivoter de 8° pour atteindre le refuge à 18h10, il y des chances que ça ne se passe pas comme prévu non plus. Avec les méthodes agiles, on va se dire qu'on va procéder étape par étape, et qu'on va pouvoir changer ses plans en fonction de la météo. On est par pour autant dans l'improvisation, mais on va travailler par emboîtements successifs.
DT - Si on fait exactement la même chose, le coût du développement est à peu près le même que l'on utilise une méthode traditionnelle ou une méthode agile. Par contre, le retour sur investissement est meilleur avec une méthode agile. Comme nous faisons du développement itératif, nous livrons une première version utilisable au client le plus tôt possible. Nous développons ensuite une deuxième version lorsque les utilisateurs en ont besoin.
Il n'y a pas de baguette magique, si on fait la même chose ça coûte le même prix. Mais dans la pratique, on fait moins de travail en agile car l'approche pilotée par l'utilité du logiciel élimine beaucoup de fonctions qui seraient dans un cahier des charges classique « au cas où ». Un développement agile coûte donc moins pour un même service rendu. Après ça, il y a un deuxième facteur qui entre en ligne de compte c'est que les projets sont souvent contraints par le budget : en agile on va donc continuer à consommer tout le budget, la plupart du temps, mais pour le prix on aura plus de fonctionnalités.
DT - Nous avons des clients qui connaissent ces méthodes, et c'est pour cela qu'ils viennent nous voir. Mais nous avons aussi des clients qui ne connaissent pas du tout ces méthodes. En fait, nous fournissons deux types de prestations aux entreprises : le développement de logiciels sur-mesure et depuis quelques temps nous faisons du conseil et de la formation. Typiquement, je sors d'une entreprise qui avait de gros problèmes de délais et qui a dû reporter plusieurs fois la sortie d'un produit parce que tout ne s'était pas passé comme prévu. Nous sommes intervenus pour leur expliquer comment marche l'agile.
Pour les entreprises qui ne connaissent pas ses méthodes, c'est sûr que c'est un changement culturel, il a y a forcément des freins et il y a de toutes façons un travail de conduite du changement. Et puis les entreprises ne réagissent pas toutes de la même façon. Je distingue deux groupes, les entreprises qui ont la culture de la solution à un problème donné et celles qui ont la culture du coupable. Évidemment, celles qui ont la culture de la solution sont plus réceptives aux méthodes agiles. Dans les démarches agiles, on donne le droit à l'erreur. On ne travaille pas pour autant sans filet, mais disons que l'approche est plus heuristique et plus pragmatique. On va créer des îlots de stabilité dans un monde mouvant en combinant à la fois une réponse aux besoins des utilisateurs et en étant plus souples sur les détails pratiques.
