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.

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.

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 ;)

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.