IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Michael Guilloux

56PARTAGES

4  2 
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 26/08/2015 à 10:37
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.
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 26/08/2015 à 10:40
Citation Envoyé par martopioche Voir le message
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?
3  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 26/08/2015 à 10:47
Citation Envoyé par LSMetag Voir le message
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.
Citation Envoyé par Agile Manifesto - 8ème principe de l'agilité
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é.
3  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 26/08/2015 à 16:00
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.
4  1 
Avatar de transgohan
Expert éminent https://www.developpez.com
Le 25/08/2015 à 15:56
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.
2  0 
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 25/08/2015 à 19:05
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.
2  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 27/08/2015 à 10:34
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é.
2  0 
Avatar de aurelienboudoux
Nouveau membre du Club https://www.developpez.com
Le 28/08/2015 à 10:28
Comme le souligne cet article ainsi que la plupart des commentaires, le but de l'agilité n'est pas d'aller plus vite.
On est tous d'accord là dessus.

Mais alors comment faire pour aller plus vite ?

La réponse naïve à cette question est souvent la suivante : il nous faut plus de ressources (plus de développeurs, plus de testeurs, plus d'argent, plus de café,...)

Pour avoir bien étudié la question, rajouter des ressources à un projet fait plus souvent perdre du temps qu'autre chose ! (formation des nouveaux, temps d'intégration, investissement dans de nouveaux sous projets, crise cardiaque due à un surconsommation de café, ...)

Donc c'est quoi la solution ?

Un début de réponse est à trouver du coté de Kanban, qui peut être couplé à Scrum (appelé ScumBan pour les intimes).

La méthode Kanban permet d'appliquer la théorie des contraintes sur votre projet, ce qui permettra de fluidifier le processus en détectant rapidement les goulots d'étranglement. Cette méthode est d'autant plus intéressante que bien souvent, on pense que développer un logiciel se cantonne à pisser du code, ce qui permet aux chefs de projets d'incriminer directement les développeurs sur leur vitesse de production.

Or, une fonctionnalité n'a de valeur que lorsque celle-ci est entre les mains de l'utilisateur. Une fois qu'on à compris cela, on se rend rapidement compte que la chaine de création d'une fonctionnalité commence au moment de l'expression du besoin, et se termine à son déploiement, c'est donc l'ensemble du processus qu'il faut pouvoir mesurer pour l'améliorer.

La méthode Scrum est appliquée pour le développement, c'est pour cela qu'elle ne peut pas être garante de la rapidité du projet, car bien souvent les goulots d'étranglement se trouvent dans l'étude du besoin ou au moment du déploiement.

Et bien sûr, ces deux domaines demandent des méthodes de gestions différentes avec des problématiques différentes !

With programming, it's always begining again.
2  0 
Avatar de souviron34
Expert éminent sénior https://www.developpez.com
Le 03/09/2015 à 19:13
Citation Envoyé par Huggy60 Voir le message
L'Agile, Scrum, XTP et consorts... ne ciblent que les projets des clients qui ne sont pas parfaitement préalablement documentés.
..
Cette approche Agile sert pour l'essentiel à couvrir un manque de spécification, ce qui est pourtant du plein et entier ressort du client.
Tout à fait faux...

Un gros projet (gros == >= 10-50 années/h) avec une super belle spec bien dans le cycle Waterfall a d'excellentes chances de se planter...

Que ce soit parce que l'analyse/spec est faite à un temps X, que entre ce temps et la mise en place bien des changements technologiques ont pu avoir lieu, que ce soit du côté des devs ou des utilisateurs, que ce soit parce que ceux qui rédigent les specs sont des informaticiens peu au courant des pratiques des utilisateurs, que ce soit que ceux qui rédigent le Cahier des Charges qui ne PEUVENT pas tout savoir ni tout appréhender, dans un très gros projet, mais aussi parce que on ne peut JAMAIS faire une analyse totale, et du problème, et de la manière de travailler des utilisateurs, et/ou de leurs mécanismes "automatisés" dont ils ne se rendent même pas compte, mais que l'info doit faire..

Tu peux avoir la plus belle et complète spec possible, si tu suis Waterfall tu risques de manquer tout un tas de trucs.. et avoir éventuellement un truc qui marche, mais qui correspond pas à ce qui était demandé (ce qui était réellement souhaité)

C'est en ça (du point de vue dev) que l'agilité est irremplaçable...
2  0 
Avatar de Laurent 1973
Membre chevronné https://www.developpez.com
Le 04/09/2015 à 10:35
Citation Envoyé par souviron34 Voir le message

...
Un gros projet (gros == >= 10-50 années/h) avec une super belle spec bien dans le cycle Waterfall a d'excellentes chances de se planter...

Que ce soit parce que l'analyse/spec est faite à un temps X, que entre ce temps et la mise en place bien des changements technologiques ont pu avoir lieu, que ce soit du côté des devs ou des utilisateurs, que ce soit parce que ceux qui rédigent les specs sont des informaticiens peu au courant des pratiques des utilisateurs, que ce soit que ceux qui rédigent le Cahier des Charges qui ne PEUVENT pas tout savoir ni tout appréhender, dans un très gros projet, mais aussi parce que on ne peut JAMAIS faire une analyse totale, et du problème, et de la manière de travailler des utilisateurs, et/ou de leurs mécanismes "automatisés" dont ils ne se rendent même pas compte, mais que l'info doit faire..
...
Réaliser un gros projet informatique de ce type en waterfall reviens à vouloir pré-régler à l'avance la température d'une pièce via de simple robinet de radiateur
On va passé beaucoup de temps à analyser les capacités thermiques de la pièce, l'incidence des baies vitrées, le rendement des radiateurs en fonte, .....
On connaissant à l'avance le nombre de personnes présentes pour une réunion
On récupère les prévisions météo avec l'indice de confiance associé.
Mais le nombre de PCs présents est inconnus.
=> On a toute les chances qu'il fasse soit trop chaud soit trop froid dans la pièce.

En agile, on sait que l'on ne sait pas tout.
On ne cherche pas a faire un grosse étude du départ mais on met en place avec un thermomètre une régulation de la température.

L'agilité, c'est comme un "thermostat" finalement dont le "thermomètre" est la satisfaction client.
2  0