Discussion :

[Michael Guilloux]

Agile : un blogueur estime que le but n’est pas de réduire le temps de développement des logiciels
Qu’en pensez-vous ?

Quel est le but du développement Agile ? Développer des systèmes plus vite ou être agile dans le sens littéral du terme ? C’est à cette question que Lewis Foti - architecte de logiciel - a essayé de répondre pour corriger certaines conceptions que beaucoup pourraient avoir au sujet du développement Agile.

La question a été suscitée par un développeur qui estime que l’Agile n’est pas assez rapide et qu’il faudrait aller plus vite. En y réfléchissant, Foti parvient à la conclusion selon laquelle le développement Agile peut permettre de livrer rapidement des projets, mais c’est à tort de croire que l’objectif est de développer des systèmes plus vite.

Pour l’architecte de logiciel, comprendre le but de l’Agile passe par la compréhension des différences entre les méthodes Agiles et les méthodes de développement traditionnelles dites en cascades. « Agile est basé sur la planification légère, le développement incrémental, la livraison précoce et une réponse flexible au changement », rappelle-t-il pour commencer.

Par contre, les développements en cascades gravitent autour d’un planning défini dès le départ avec un délai et un budget à respecter, et c’est la raison pour laquelle ce type de projets connait un faible taux de succès. En effet, comme l’explique Foti, il n’y a aucun moyen de savoir exactement combien complexe le système à livrer peut-il être avant qu’il ne soit mis en œuvre. Des imprévus peuvent se produire à tout moment et affecter le planning, tant au niveau du délai qu’au niveau du budget. Faire donc un planning global peut facilement conduire à la livraison d’un produit incapable d’offrir le nécessaire à l’utilisateur final.

Si au début du projet, les développeurs n’ont pas vraiment une idée claire de ce qu’ils essaient de livrer, ils en saisissent toutefois une meilleure compréhension alors que le projet progresse. Le développement Agile exploite cette compréhension accrue du projet pour améliorer le plan initialement défini.

Pour répondre à sa question, Lewis Foti conclut que « le développement Agile permet de reconnaître les réalités de l'exécution du projet, sachant que nous ne connaissons pas assez ce qui est nécessaire au début du projet. Agile fournit un mécanisme et un environnement où les plans et les priorités sont adaptés pour profiter des connaissances acquises. La visibilité accrue du progrès et la validation fréquente de ce qui est développé réduit les risques liés à la livraison du projet. Les projets agiles peuvent permettre de livrer plus rapidement, mais ils doivent veiller à ce que l'effort soit investi de manière appropriée et conduire à la qualité de livraison ».

Source : Big architecture

Et vous ?

Qu’en pensez-vous ? Quelle est votre expérience du développement Agile ? Dans la pratique, Agile permet-il de réduire le temps de développement de logiciel ?

[transgohan]

Agile n'a en effet jamais eu pour but de travailler plus vite... Sinon ça serait la méthode miracle !

Après en général on fait souvent de l'Agile car c'est classe, mais avec un client et une maitrise d’œuvre qui n'en fait pas et qui ne jure que par la date de livraison avec contenu à 100%.
Du coup l'Agile c'est beau en théorie, dans la pratique c'est une façon de travailler différente mais qui d'un point de vue projet ne change pas grand chose (si c'est dans le cas que je décris dans la phrase du dessus).

Si Agile vous dit que vous finissez 100% dans 6 mois mais que la livraison est dans 3 mois vous vous tournez vers vos chefs. Et là qu'on soit Agile ou en Cascade la réponse c'est la même.

[ZenZiTone]

Après en général on fait souvent de l'Agile car c'est classe

Pas tout à fais convaincu... Les méthodes Agiles nécessitent un minimum de rigueur et d'investissement des acteurs. Si on s'y intéresse ce n'est pas pour le vendre auprès de ses clients mais bien pour essayer de résoudre les problèmes que l'on peut rencontrer dans des méthodes de gestion de projet telles que le Cycle en V (ou alors on risque d'aller droit dans le mur).

Qu’en pensez-vous ? Quelle est votre expérience du développement Agile ? Dans la pratique, Agile permet-il de réduire le temps de développement de logiciel ?

Je n'ai pas encore expérimenté l'agilité, mais il me semble que le but premier n'est pas de réduire le temps de développement, mais de se concentrer sur le besoin du client (d'où une réponse flexible au changement). Je pense que la réduction du temps de développement n'est qu'une conséquence (on développe des fonctionnalités demandées/confirmées par le client en début de sprint et pas une solution négociée l'année dernière).

[LSMetag]

Le but d'Agile n'est pas de réduire le temps de développement logiciel. C'est de donner plus de marges de manoeuvre, en rendant possible un dialogue plus direct avec les clients, en s'adaptant en temps réel à la demande client (et ses changements d'avis), qui permet de corriger un bug sans avoir à attendre 1 an l'aval de la hiérarchie.

Avec Agile ça peut au contraire se révéler plus long. Mais à mes yeux ça permet de faire du meilleur travail, d'avoir une façon de travailler un peu plus "humaine", où, au lieu de passer par un téléphone arabe (CP, MOE, MOA, utilisateur,...) on discute directement de vive voix, en toute cordialité.

Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.

[martopioche]

Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.

En fait, ce revers de la médaille, c'est la promesse de l'adaptabilité... "Finalement on ne veut plus la fonction comme ça (chiffrée à 1 jour et livrable pour la livraison de dans 2 jours) mais comme ci (nécessitant 4 jours). Nous attendons donc votre livraison après demain avec la fonction ci, merci."

[Laurent 1973]

De développer en Agile ne permet pas de réduire le temps de développement global d'un logiciel, on est bien d'accort.
Par contre, cela permettrait quand même d'avoir un retour sur investissement plus rapide.

Je m'explique.

En Agilité, le but est de livré régulièrement des versions intermédiaires pour avoir un feed-back rapide des clients/utilisateurs.
En Scrum (une des méthode agile les plus utilisé) on demande, même qu'en fin de sprint, de réaliser un version potentiellement livrable.

Comme rapidement, au bout de seulement quelque itération, on commence à avoir un logiciel, incomplet serte, mais fonctionnel et qui peut réaliser déjà certaines taches, on pourrait déjà le proposer à des utilisateurs.
Régulièrement, pas forcement à chaque itération, mais quand les évolutions sont considérer comme notable, on peux alors mettre à jour le logiciel en production alors que celui-ci n'est toujours pas terminer.

On voit bien, que dans cette logique de livraison, notre logiciel est utilisé au plus tôt et donc rentabilisé avant la fin de son développement.
Dans une logique concurrentiel, un tel produit prendrait des parts de marché face à un autre développé en Waterfall qui commencerait son développement en même temps.
Pour un investisseur, il commence également de rentabiliser son outil alors que celui-ci n'est pas encore terminé (voir pas encore payé).

La notion de 'temps de développement' prend alors un sens différent vu que ce n'est pas forcement le temps où notre logiciel commence à engendrer de l'argent, mais le temps où l'on en dépense plus.

[Laurent 1973]

En fait, ce revers de la médaille, c'est la promesse de l'adaptabilité... "Finalement on ne veut plus la fonction comme ça (chiffrée à 1 jour et livrable pour la livraison de dans 2 jours) mais comme ci (nécessitant 4 jours). Nous attendons donc votre livraison après demain avec la fonction ci, merci."

Là, ta contractualisation agile est très mal faite.
Le client ne doit pouvoir changer de fonctionnalité qu'avec une autre de même effort.

Ton épicier n'accepte pas de t'échanger une boite de pâté contre une boite de fois gras, pourquoi on l'accepterait en informatique?
Est ce que nos commerciaux sont plus mauvais qu'un épicier?

[Laurent 1973]

Le revers de la médaille, c'est que ça encourage les heures sups (non rémunérées). On n'est pas facturés au bug, mais à des lots comportant diverses fonctionnalités.

Là, je pense que c'est ta boite qui utilise cette argument pour vous faire des heures sups.

Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.

Au contraire, l'agilité encourage à avoir des journées régulières.

Les coups de bourres, les heures sups soudaines, les phases de surcharges, .... sont justement contraires à l'agilité et au développement logiciel de qualité.
On est dans un domaine créatif, pas dans une industrie de production: la multiplication des heures dégrades la qualité.

[abriotde]

L'intérêt du développement Agile est d'abord pratique. Cela combat le problème de l'usine a gaz. En effet il est très bien de développer un gros logiciel bien spécifié, mais en pratique le déploiement est complexe, et le besoin des utilisateurs est changeant. De plus quels que soit le logiciels, il n'est jamais finit / totalement stable.

Un développement agile, intelligent, consiste selon moi à de créer un squelette propre, un Proof Of Concept fonctionnel, de le mettre en prod. De laisser les utilisateur se l'approprié et au fur et a mesure d'y faire des retouches successive.

L'intérêt : On a un développement beaucoup plus souple ce qui est plus agréable pour le développeur comme pour l'utilisateur. On évite de développer pour rien parce que l’utilisateur n'en a pas besoin. D'un point de vue sécurité comme fonctionnel, le projet évolue vite et dans le bon sens.
L'inconvénient : On a beaucoup de mise en prod, et donc beaucoup plus de risque d'instabilité voire de faille de sécurité.

Conclusion : Le développement agile est beaucoup mieux, il offre un meilleur suivi mais n'est pas la solution ultime, il n'est pas adapté a tout les projets.

C'est comme le NO-SQL, le big data ou le Cloud, innovant, plus adapté parfois mais pas magique.

[abriotde]

domaine créatif, pas dans une industrie de production.

Ca ne veux rien dire, créatif ne s'oppose pas a industriel. Quel que soit le domaine (logiciel, cinéma, jeu vidéo, automobile...), il faut innover ET produire.
Les heures sup n'ont rien a voir avec ça. Quel que soit le travail la charge est bonne et la surcharge est mauvaise.

[Luckyluke34]

Je pense que l'agilité peut permettre de réduire le temps de développement même si ce n'est pas l'objectif principal.

Un truc qu'on oublie un peu, c'est qu'un des gros arguments marketing mis en avant par les créateurs d'une méthode comme Scrum est l'hyperproductivité des équipes. Bien sûr, je trouve le terme hyperproductif complètement surfait, mais il y a des éléments valides dans l'argumentation de Sutherland à propos de Scrum :

• Se focaliser sur la livraison de valeur métier en mettant dans une même équipe toutes les compétences pour y arriver
• Pas de multitasking (les équipes sont dédiées, dans une itération on se concentre sur un produit et une fonctionnalité)
• L'information doit être partagée immédiatement, en travaillant en binôme dès que nécessaire

Tout cela permet d'aller plus vite, ou plus exactement de ne pas être ralenti par des obstacles : défaut d'organisation personnelle/d'équipe/d'entreprise, manque de connaissance du code, latence de communication et de prise de décision.
Ces pratiques peuvent paraître évidentes mais force est de constater que le cadre traditionnel de projet cycle en V ne les favorisait pas vraiment jusqu'alors.

[Matthieu Vergne]

La question me semble mal posée : Agile permet-il de réduire le temps de développement de logiciel ?

Oui et non, tout dépend de quoi on parle. Faisons simple et demandons au Larousse :

Agile :
- Qui a de l'aisance et de la promptitude dans les mouvements du corps ; souple, alerte : Un enfant agile comme un chat.
- Qui est vif, prompt à comprendre : Un esprit agile.

En bref, on parle de rapidité dans l'instant (le court terme), et non de rapidité dans l'avenir (sur le moyen/long terme). On peut facilement amalgamer les deux, mais ce n'est rien de plus que cela : un amalgame. Je pense que les méthodes Agiles ont été pensées dans ce sens, et ce serait donc une erreur de considérer qu'elles permettent de travailler globalement plus vite.

Les méthodes agiles visant l'adaptation continue, cela nécessite de faciliter une telle adaptation, et cela a un coût, je m'attends donc à ce qu'en moyenne les développements soient plus long avec de l'Agile. Mais si on inclut toute la phase de correction et maintenance qui vient en extra à la suite d'un classique cycle en V, du fait des changements de besoins qui n'ont pas été considérés, alors il est probable que le temps total soit plus court en faisant de l'Agile. Mais le fait est que dans le cas du cycle en V, on part sur une idée et on en dévie peu, et si le résultat est exploitable alors on l'utilise tel quel et on change peu de choses. Alors que dans le cas de l'Agile, on change dès qu'on voit qu'il y a quelque chose à changer, donc le produit final a des chances d'être significativement différent de celui fait via un cycle en V. Donc dire qu'on développerait plus ou moins vite, alors que le produit final est différent, n'a pas beaucoup de sens.

Si on veut avoir tel produit impérativement pour telle date, on utilise un cycle en V et on fait avec ce qu'on a à la date prévue. Si on veut un produit qui répond impérativement au besoin, on fait de l'Agile et on s'adapte aux changements de planning. Question de priorités.

[LSMetag]

Là, je pense que c'est ta boite qui utilise cette argument pour vous faire des heures sups.

En fait je me suis mal fait comprendre. Souvent, dans ce genre de méthodologie, les développeurs sont des personnes motivées, qui ont le soucis de bien faire. Et dans la passion viennent les heures sup, puisqu'on ne nous dit pas précisément quoi faire et comment. On a certes des maquettes et directives sur un logiciel de bugtracking, mais on peut se réserver le droit d'ajouter des bugs au bugtracker, de choisir entre nous qui va prendre le bug, ou de téléphoner au client pour lui faire part d'une fonctionnalité ou erreur de spec.

Bref c'est la passion qui encourage les heures sup, sauf si le CP est mauvais, ou le client trop chiant.

[LSMetag]

Là, ta contractualisation agile est très mal faite.
Le client ne doit pouvoir changer de fonctionnalité qu'avec une autre de même effort.

Ton épicier n'accepte pas de t'échanger une boite de pâté contre une boite de fois gras, pourquoi on l'accepterait en informatique?
Est ce que nos commerciaux sont plus mauvais qu'un épicier?

Et pourtant ça arrive. Et après on livre en retard... Le client veut son produit. Même si le CP est là pour expliquer, le client ne comprend qu'à moitié.

[martopioche]

Là, ta contractualisation agile est très mal faite.
Le client ne doit pouvoir changer de fonctionnalité qu'avec une autre de même effort.

Ton épicier n'accepte pas de t'échanger une boite de pâté contre une boite de fois gras, pourquoi on l'accepterait en informatique?
Est ce que nos commerciaux sont plus mauvais qu'un épicier?

Ah, cette "contractualisation Agile"... Mon épicier ne fait pas de "sur mesure", ce n'est pas un créatif mais un commerçant, donc les tarifs des boites de pâté sont indiquées et fixes et ne m'a jamais promis d'adapter ses tarifs et se prestation en fonction de mes besoins (mon panier). À l'opposé, les fonctions que nous implémentons ne sont pas toutes sur étagères. Et le trade in/trade out n'a comme mesure que l'effort, pas le délais. Bah oui, il y a une semaine quand on avait proposé le choix des fonctions, on avait annoncé un délais de 1 jour mais aujourd'hui pour l'implémenter il faudra faire quelques modifications du fait du départ sur une autre direction et les ressources les plus adaptées ne sont ne sont pas dispo du jour au lendemain... Peu importe le scénario, de toutes manières, je n'ai jamais vu un pattern de "contrat Agile" où ces "points" sont définis de manières strict et mesurable (conceptuellement, c'est impossible), ce qui en soi peut permettre toute remise en cause.
Et nos commerciaux vont arriver au problème inhérent à tout produit : l'engagement de livraison. Le logiciel doit être en ligne pour la rentrée des classes (remplacez pas n'importe quel évènement) avec toutes les conséquences contractuelles qui vont avec.
Et ça, c'est le scénario relation client/prestataire, en interne, la notion de "contractualisation" existe rarement.

[Laurent 1973]

La contractualisation agile est en effet un vaste sujet.
Bon, mon exemple de l’épicier est un peu exagéré, je l'avoue (bien que parfois, certain commerciaux de SSII feraient mieux de ventre des petits pois)

Un vrai contrat agile (ex: http://www.contrat-agile.org/) impose justement cela.
On ne s'engage pas sur un livrable (contenu ou date) mais sur un processus (ex: Scrum).
On ne vent plus un résultat précis mais de l'effort de création.
Et l'ensemble des protagoniste sont impliqué dans les choix et leurs conséquences.
Le client veux la fonctionnalité A au lieu de la B (deux fois moins coûteuse) 1 mois avant la mise en production: contractuellement, il doit en accepter les conséquence (retard, autre fonction non faite, ...)
L'implication client, c'est là tout le sens de l'agilité.

Si l'équipe développe en Agile, mais que le commercial a signé un contrat 'forfais classique', c'est logique qu'à un moment le client va en profiter pour faire faire des changements de spécification (ben vous êtes agile, vous l'acceptez) qui ne colle plus avec la contrainte commercial et technique ... et là, on est plus dans l'agilité.

[oreI]

Un des buts de l'agile c'est une grande visibilité sur les changements.
ça donne une grande tracabilité des changements et des couts des changements.

Un effet pervers aussi est qu'on a un suivi de la performance des devs.

[Saverok]

Un effet pervers aussi est qu'on a un suivi de la performance des devs.

Pourquoi est-ce un effet pervers ?
Personnellement, je trouve que c'est une excellente chose et permet d'identifier les dérives très rapidement pour mieux les corriger

De plus, le suivi de la "performance" des dev n'est pas lié à l'Agile mais à l'intégration continue.

[mactwist69]

Une chose est sûr, la méthode Agile mal comprise et/ou mal utilisé, ça va rallonger considérablement les développements. En fait mon postulat est le suivant : Si on crois qu'on va gagner du temps, on va en perdre beaucoup !

Et là je parle d'un retour réel où dans une entreprise, les petits chefs informatique sous couvert "d'agilité", ne se sont plus embêter à écrire des cahiers des charges, ne font plus d'analyse... Mais créer à la volée avec aucune vision sur le global... Et à la fin, on se retrouve avec une usine à gaz digne d'il y a 30 ans.


Bien utilisée, la méthode Agile est en fait juste une approche qui paraît de nos jours censée : Plus de contacts avec le client et des équipes, plus à l'écoute des besoins... Ce n'est plus un développement rigide décidé pyramidalement par un chef qui décide de tout envers et contre les équipes et les clients. Éventuellement ça fait gagner du temps sur le projet global en évitant des "gros retours en arrière".

[ZJP972]

Ma conclusion après lecture de certains commentaires : l'Agile permet de faire de..l'Early Access.
(Désolé, terme utilisé pour le dev ludique : Une partie de mes activités.)