Étant constamment à la recherche d’améliorer la gestion de projets chez Skalpel, j’ai passé un peu de temps à me documenter sur les méthodes Agiles pour le développement logiciel. Derrière le terme très séduisant « agile », j’ai découvert une « philosophie » du développement en équipe qui me semble correspondre aux projets que nous réalisons.
L’Agile Manifesto, un texte rédigé par 17 experts informatiques reconnus, synthétise cette vision du développement logiciel en 4 grands principes :
- Les individus et les interactions doivent primer sur les processus et les outils
- Le développement logiciel doit primer sur la documentation exhaustive
- La collaboration avec le client doit primer sur la négociation contractuelle
- L’ouverture au changement doit primer sur le suivi d’un plan rigide
Je ne suis pas un expert du développement logiciel, mais ces valeurs me semblent encore plus adaptées au développement web, puisqu’un site internet e-commerce par exemple, doit s’adapter constamment et rapidement à l’évolution de son environnement (technologique, concurrentiel, …) mais aussi à ses visiteurs. La communication et la collaboration entre le client et les équipes de développement sont alors la clé de voûte de la réussite du projet.
De ces 4 valeurs, nos experts en ont tiré 12 principes :
- Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utilisables.
- Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
- Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
- Les chargés d’affaires et les développeurs doivent collaborer quotidiennement au projet.
- Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
- La méthode la plus efficace de transmettre l’information vers et au sein d’une équipe de développement est une conversation en face à face.
- Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
- Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
- Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
- La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
- Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
- À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.
Ces principes me semblent là encore très pertinents, je me pose simplement la question de leur application dans un contexte commercial. Par exemple, l’acceptation du changement en cours de projet est une chose, sa facturation quand il implique du temps de développement supplémentaire en est clairement une autre ! Ou encore, à quoi cela sert de livrer très régulièrement un logiciel (ou une version du site) si le client n’est de toute façon pas assez impliqué pour en suivre les évolutions ? Un début de réponse est certainement dans l’éducation et le cadrage du client, mais je ne suis pas certain que cela suffise.
Si vous avez mis en place des méthodes agiles au sein de votre équipe de développement, je serai heureux d’avoir votre retour d’expérience en commentaire ! Quelles sont les difficultés que vous avez rencontré ? Quels bénéfices en avez-vous tiré ? Vos clients adhèrent-il à cette manière de travailler ?
Abonnez-vous au flux RSS
Suivez-moi sur Twitter !
Contactez-moi !
7 commentaires pour ce billet
Pour l’application dans un domaine commercial tu peux changer l’approche traditionnel par « cahier des charges » en proposant simplement de vendre des points de développement et après de réaliser des fonctionnalités en donnant le chiffrage de point. Voir une approche hybride ou tu commences par évaluer un cahier des charges qui donne un certains nombre de points et par la suite le client gère son budget s’il veut des modifications.
Nous réalisons un cahier des charges avec une estimation de budget.
Nous accompagnons nos clients dans la réussite des projets : Nous livrons nos clients régulièrement, nous les impliquons complètement dans le projet : une équipe (ou une personne) se charge d’être « bêta-testeur » : retours de bugs, améliorations de l’ergonomie, etc…
Les clients sont tous très satisfaits de ce fonctionnement : ça leur permet de développer une « expertise » de la solution en interne, et de voir aussi que le projet avance sûrement, sans peur d’une catastrophe après un silence de plusieurs mois.
Cette démarche rend le client plus créatif (et donc plus gourmand :) ) : il a plein d’idées d’améliorations, de nouvelles fonctionnalités, etc… Notre méthode est toujours la même : on recueille le besoin, on fait un estimation, si cela rentre dans le planning du projet (nous n’envisageons pas de livrer en retard !!!)et dons du budget, nous l’acceptons. Sinon, cela demande un budget, et si le client est prêt à suivre : cela passera dans la version V+1 (après le projet en cours).
Ce qui me dérange dans les développements agiles, c’est justement qu’on parle de « développement ». On ne parle pas de conception, on parle de coder rapidement, sans trop penser à dans un mois ou deux. Mais en parallèle d’un développement de type agile, je pense vraiment qu’il faut un analyste (le même) tout le long du projet pour qu’il y ait une conception globalisée sur le projet. C’est la meilleure optimisation que je connaisse.
« Ce qui me dérange dans les développements agiles, c’est justement qu’on parle de “développement”. On ne parle pas de conception, on parle de coder rapidement, sans trop penser à dans un mois ou deux. »
Agile ce n’est pas une étiquette à coller sur du grand n’importe quoi. Déclarer que les développeurs agiles ne font jamais de conception ou n’architecture jamais leur application c’est comme dire que dans ton mode de conception le client n’a jamais le droit de changer un iota des fonctionnalités une fois le cahier des charges établi.
Si déjà tu livres ton client à intervalle régulier avec un retour de sa part et un réétablissement du plan de marche je suis désolé de t’annoncer que tu fais déjà de l’agile.
Quand à « nous n’envisageons pas de livrer en retard », vous ne l’envisagez pas mais ça doit arriver quand même ;)
Tout à fait, nous faisons déjà de l’agile.
Je ne critique pas les méthodes agiles, c’est la façon dont on en parle qui me dérange. Pour les personnes qui ne connaissent pas, elles se disent que c’est le lot des développeurs et point barre. Hors ce sont des méthodes qui touchent à l’organisationnel, et je trouve que souvent, on manque de le noter.
Je ne colle pas l’étiquette « agile » sur le n’importe quoi. Encore une fois, je dénonce que l’on colle trop facilement cette étiquette à du n’importe quoi, aux mauvaises applications de ces méthodes.
Et, tiens-toi bien, nous ne livrons vraiment jamais en retard, dans la mesure où nous respectons NOS délais. Même si cela nous coûte parfois des samedis matins ou des soirées (ce qui reste rare).
Les cas de dépassement sont dûs aux retards de nos clients. Et nous travaillons pour anticiper cela.
Personnellement, je ne parle pas de « développements agiles », mais bien de « méthodes agiles ». Puisque c’est avant tout un état d’esprit et une méthodologie (et en conséquences, des outils).
alors nous sommes d’accord :)
Salut,
j’arrive un peu tard, mais ce que vous appellez agile, il me semble qu’avant ça s’appellait extrem programming, ou encore la programmation par itération. Je fais, je montre, j’analyse le retour, je fais, etc…
En gros toujours la même chose.
Toujours la même envie, d’arriver à un confort de developpement d’un coté et augmenter le niveau d’implication du client d’un autre.
Mais n’est ce pas une utopie ?
Les technologies evoluants, le temps de recherche et developpement est toujours le même, et ça le client ne tiens pas vraiment à le payer, sauf projet particulier.
J’ai connu quelqu’un qui vendait son developpement en précisant qu’il acceptait de depasser de 15 jours le projet de base, ces 15 jours correpondants soit à des erreurs d’estimation de sa part, soit des modifications demandées par le client.
Une fois ce bonus de temps ecoulé, le client était refacturé. Cette méthode avait l’air de fontionner.
Pour revenir sur le point : « L’ouverture au changement doit primer sur le suivi d’un plan rigide »; Ceci n’est valable que dans le cas d’un développement en interne. Et non pour un client extérieur.
Pour conclure, ce genre de méthode de développement, fonctionne très bien sur un projet interne à une société, ou avec un client qui est capable de voir le plus apporté par telle ou telle fonctionnalité et qui aurait le budget supplémentaire. Mais malheureusement ce doit être 5% des clients.