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

0PARTAGES

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-le nous !

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 ZenZiTone
Membre expert https://www.developpez.com
Le 25/08/2015 à 16:58
Citation Envoyé par transgohan Voir le message
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).
1  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 martopioche
Membre éclairé https://www.developpez.com
Le 26/08/2015 à 0:35
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.
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."

1  1 
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 abriotde
Membre expérimenté https://www.developpez.com
Le 26/08/2015 à 14:40
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.
1  0 
Avatar de abriotde
Membre expérimenté https://www.developpez.com
Le 26/08/2015 à 14:46
Citation Envoyé par Laurent 1973 Voir le message
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.
0  0 
Avatar de Luckyluke34
Membre émérite https://www.developpez.com
Le 26/08/2015 à 14:49
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.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web