Discussion :

[Matthieu Vergne]

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

Autant l'analogie est plaisante, autant pour rester rigoureux je dirais que c'est un raccourci maladroit (mais n'étant pas un dév de jeu, c'est peut-être ma compréhension de la notion de "Early Access" qui est maladroite), et cela pour deux raisons :
- raison de forme : je dirais plutôt que l'Early Access se base sur la même idée que de faire de l'Agile, donc plutôt "L'Early Access permet de faire de l'Agile" et non l'inverse,
- raison de fond : l'Early Access est avant tout un moyen de permettre à certaines personnes (hors projet) d'obtenir un accès privilégié en échange de ressources pour continuer le dév (financements, feedback, etc.), on fonctionne donc en sens inverse : la demande ne vient pas du client (identification des besoins, etc.) mais du dév ("Ça vous dirait d'essayer ce que j'ai fais ?").

NB : Ceci est mon 1000e post ! Et je suis content que ce ne soit pas un troll. {^_^}

[dacodemaniak]

Après avoir lu le post, les méthodes agiles permettent effectivement de tenir compte de la réalité effective des projets et donc, de faciliter les corrections en cours de route qui sont excessivement nombreuses plus le projet est long. Quelque part, j'ose estimer que l'agilité n'est qu'une réponse à la défaillance de la définition préalable d'un projet, de sa non spécification, de la nébuleuse qui entoure un certain nombre de points autant du au client qu'au technico-commercial.
Par contre, utiliser une méthode agile peut permettre de livrer rapidement des fonctionnalités et les corriger au fur et à mesure jusqu'à obtention du résultat final escompté.
Pour pouvoir livrer plus rapidement une application, il est à mon avis impératif de se souvenir des concepts de réutilisabilité, d'abstraction et être capable de fournir au développeur des lignes guides de développement suffisamment rigides pour éviter les pertes de temps liées à la reprise (parfois la réécriture complète) et en redite, surtout, d'avoir défini précisément les fonctionnalités à mettre en oeuvre.
Pour ce qui me concerne, l'intérêt des méthodes agiles est d'impliquer l'ensemble des intervenants dans la boucle de développement, d'instaurer une dynamique de groupe et une motivation plus globale.
Donc non, les méthodes agiles n'ont pas pour but de réduire le temps de développement, mais d'en améliorer la qualité générale.

[Neckara]

Qu’en pensez-vous ?

Que les chroniqueurs actualités sont à court d'actualité .
C'est qui ce Lewis Foti ? Avec un post datant du 18 sans aucun commentaires, je n'ai pas trop l'impression qu'il fasse référence dans le domaine.

L'art de transformer un post quelconque en actualité… quitte à faire, autant le faire bien non ?


Rien de vraiment nouveau sous le soleil, je pense qu'on est tous d'accord. Bien sûr que l'essence d'agile n'est pas d'aller plus vite. À part en pinaillant sur les mots, je pense qu'on est tous d'accord.


En ce, la remarque à l'origine de cet article est bien plus intéressante que la réponse :
“Agile is not fast enough, we have to be liquid”

Cela me fait penser à des questions bien plus intéressant :

• qu'est-ce que liquid ?
• agile est-il réellement plus lent que d'autres méthodes ? Dans quelles proportions ? Est-ce qu'il y a des études à ce sujet ? Ce serait intéressant de faire quelques recherches.
• est-ce que cette éventuelle perte de temps vaut réellement le coût face aux avantages d'agiles ?
• si agile fait perdre trop de temps, est-ce dû à une mauvaise utilisation d'agile ? Ou y-a-t-il des moyens/astuce pour éviter de perdre trop de temps ? Ou est-ce une perte nécessaire à l'agilité ?
• est-ce qu'au final, on ne perd pas du temps pour en gagner ?

Personnellement, je trouve dommage de transformer un post random en actualité en claquant des doigts, sans même faire de recherches complémentaires.

[aurelienboudoux]

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.

[autran]

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?

Le commercial va malheureusement chiffrer le projet en avant-vente en planifiant des macro-fonctionnalités (identification – commandes – facturation – réapprovisionnement…) en partant du principe que ces macro-fonctionnalités peuvent faire l’objet de modification intérieures durant le projet. C’est ce qui porte les germes des futurs conflits agiles.
Et reconnaissons que ton épicier connait ses produits mieux que ton commercial ne connait le management de projet agile

[Laurent 1973]

agile est-il réellement plus lent que d'autres méthodes ? Dans quelles proportions ? Est-ce qu'il y a des études à ce sujet ? Ce serait intéressant de faire quelques recherches.
est-ce que cette éventuelle perte de temps vaut réellement le coût face aux avantages d'agiles ?
si agile fait perdre trop de temps, est-ce dû à une mauvaise utilisation d'agile ? Ou y-a-t-il des moyens/astuce pour éviter de perdre trop de temps ? Ou est-ce une perte nécessaire à l'agilité ?
est-ce qu'au final, on ne perd pas du temps pour en gagner ?

Pourquoi tu parles que l'Agilité est plus lente que le Waterfall?

On ne parle pas de cela, on évoque juste que l'agilité n'a pas comme avantage d'aller plus vite.
Cela ne veux pas dire que l'on va moins vite.
Cela ne veux pas dire non plus que parfois on ne va pas plus vite.

Cet article rappel juste que ce point là, n'est pas l'argument de travailler en Agile.

[autran]

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é.

C'est très juste mais je ne sais pas comment faire cela avec le code des marchés publics

[manu007]

Agile, pour moi, serait un peu... Nous allons faire un dévelopement, on ne sait pas trop quoi, qui et comment... On écrit un canvas, et on avance au fûr et à mesure des entretiens avec le client, ceci put nous donner que, si au début, il fallait faire un bateau sans moteur, on peut se trouver a la fin du project avec le France totalement retapé, renfloué et volant sur la crête des vagues.

Je crois que Agile est un très bon moyen de définir des lagunes dans la définition d'un project, mais encadrée dans des limites d'une façon très claire, c'est un dire, un complèment, jamais un outil de design complet.

[Saverok]

Donc non, les méthodes agiles n'ont pas pour but de réduire le temps de développement, mais d'en améliorer la qualité générale.

Tout dépend de ce que tu mets derrière le terme qualité.

En ce qui concerne la qualité du code, ce n'est pas l'Agile qui permet d'agir sur ce point mais l'intégration continue (TU, analyseur de code, etc.).
Cela n'a rien de spécifique à l'Agile.
La méthode Agile peut être parfaitement suivi et produire un code de merde s'il n'y a pas l'encadrement technique suffisant

De même, si par qualité, tu entends performance et tenue à la charge.
La encore, l'Agile n'agit pas sur ces points.

Reste la qualité fonctionnelle : est-ce que les fonctions métiers sont présentes et utilisables facilement ?
Là, effectivement, l'Agile répond à cet aspect.
Nous seulement les spécifications fines se définissent par itération en lien direct avec les utilisateurs (on se garanti une implémentation fonctionnelle qui correspond à l'usage réel) mais en plus, les priorités sont redéfinies à chaque itération (on se garantit que les besoins les plus importants, avec la plus forte valeur ajoutée, sont couverts).

Par expérience, l'Agile ne permet pas d'aller plus vite mais il permet de mieux satisfaire les besoins réels des clients.
Avec l'Agile, on se garantit d'avoir une application fonctionnelle à un instant T.
Autrement dit, on se garantit de tenir une date de livraison mais si l'ensemble des fonctionnalités voulues au départ du projet ne sont pas couvertes mais celles qui sont présentes, sont utilisables et avec une forte adhérences des utilisateurs.

[behall]

A mon avis le développement agile est destiné à mieux développer, absolument pas développer plus vite.
Mieux développer, ça veut entre autre réduire les dérives et pertes de temps ce qui peut aboutir à un gain de temps au final. Mais pas à développer plus vite.
En fait en agile on a une durée estimée imprécise, mais beaucoup moins de risques de dérive et pertes de temps et une bien meilleure visibilité de ces dérives quand il y en a (ce qui permet de les corriger rapidement). Dans un développement en cascade en théorie la spécification est parfaite et toute erreur devrait être juste une mauvaise interprétation (c'est possible) qui risque de ne se voir que trop tard (à la livraison), et donc de faire perdre plus de temps. Si vu plus tôt on peut se retrouver devant l'obligation éventuellement de remettre en question la spécification ce qui est dangereux si on le fait sans consulter la moa/moe ou long en passant par le cycle normal (re-document au moins amendés approuvés et redémarrage du développement (dans le pire des cas suspendu).
Les méthodes agiles améliorent la visibilité des problèmes et souvent leur résolution en tout cas c'est l'intention derrière.
La visibilité du terme est plus floue mais le seul moyen de réduire les risques dans la méthode cascade est de maximiser l'estimation des dérives possibles et donc d'augmenter le coût dès l'estimation.

[Huggy60]

L'Agile, Scrum, XTP et consorts... ne ciblent que les projets des clients qui ne sont pas parfaitement préalablement documentés.
Tout est une question de choix, mais pour bien choisir, il faut se poser les bonnes questions et prendre de la hauteur.

Cette approche Agile sert pour l'essentiel à couvrir un manque de spécification, ce qui est pourtant du plein et entier ressort du client.
Quand le client comprend que le product owner c'est lui et uniquement lui, mais aussi et surtout que cette activité est particulièrement chronophage, il fini soit par demander à ce qu'on torde le coup aux bases de l'agilité pour travailler dans un mode semi agile (où sa présence est minorée), soit il abandonne purement et simplement ce mode d'organisation pour revenir au bon vieux waterfall !!
Je vous en parle d'expérience...

Et oui, le client DOIT spécifier son besoin, et ce, dans tous les cas de figure : avant ou pendant les dev.
De fait, le degré de précision du besoin est un point essentiel. Le moment où le besoin est spécifié aussi.

Le fond de la question n'est pas tant de savoir si le mode Agile permet de produire des lignes de code plus vite, mais de savoir quel est le niveau de qualité que le client est prêt à payer pour un investissement minimal de sa part.
En effet, soit il investit du temps en rédaction de spécifications fonctionnelles et techniques générales et détaillées (idéalement AVANT le build), soit il passe du temps au quotidien à suivre les sprint au jour le jour (et là, je vous certifie que la majorité des clients s'en mordent les doigts), mais c'est dans ce second cas que l'agilité peut prendre tout son sens... !

En fait, le choix de l'Agile ou du Waterfall est fonction du client et/ou de son écosystème projet : un client qui sait majoritairement ce qu'il veut aura tout intérêt à opter pour le cycle en V, et à l'inverse, un client qui ne sait pas vraiment bien définir finement ce qu'il veut pourra opter pour une approche dite Agile.

Quand à l'écosystème du projet, l'influence sur le choix de la démarche est à l'identique :
Si par exemple c'est le besoin marketing qui prime et qui du fait des enjeux business, d'image, etc..., il se trouve que le projet est soumis a de très fortes contraintes de temps et donc de réactivité, l'Agile peut être une solution.
Si c'est le DAF de l'entreprise qui a un besoin de type législatif ou réglementaire, il devra préférablement s'orienter vers un mode de gestion en mode Waterfall pour être un peu plus sûr de respecter le triptyque Cout/Qualité/délai de son projet (surtout le délai dans ce cas là...).

Ma modeste vision du monde sur ce sujet est que l'Agile n'a jamais eu pour but d'optimiser les temps de développement, mais de répondre à un manque d'implication ou de travail de la part du client, ou encore à un très fort besoin de réactivité, par exemple sur des marchés très concurrentiels.

[Neckara]

Pourquoi tu parles que l'Agilité est plus lente que le Waterfall?

Je n'ai jamais affirmé cela.

On ne parle pas de cela, on évoque juste que l'agilité n'a pas comme avantage d'aller plus vite.
Cela ne veux pas dire que l'on va moins vite.
Cela ne veux pas dire non plus que parfois on ne va pas plus vite.

Bien évidement, mais si on parle de rapidité sans parler de rapidité, on ne parle plus de rien.

L'origine du débat est bien "Agile is not fast enough". On s'en moque que ce soit l'objectif ou non de l'Agile, c'est une constatation (erronée ou non). À partir de là, on peut partir sur des questions très intéressantes que j'ai évoqué plus haut.

Si l'Agile induit intrinsèquement une multiplication du temps de développement par 10, on est en droit de se poser des questions, même si la rapidité n'est pas l'objectif premier de l'Agilité.
L'Agilité, c'est aussi essayer de s'améliorer entre chaque itérations, si on est pas assez rapide, ce peut être une piste d'amélioration.

Pareil, si on dit que l'Agilité coûte plus cher, par exemple, bien que ce ne soit pas l'objectif intrinsèque de l'Agilité de réduire les coûts, il y a tout de même un seuil à ne pas dépasser. Une entreprise n'a pas un budget infini.

Je vois mal une entreprise choisir une méthode agile si cela induit un "retard" de 9 ans sur un projet de 10 jours. J'exagère, mais avant de pouvoir parler, il serait bien, déjà, de savoir ce qu'il en est en pratique, si il y a des études sur le sujet, plutôt que de parler dans le vide.

Cet article rappel juste que ce point là, n'est pas l'argument de travailler en Agile.

Ce n'est pas un article mais une actualité/débat sur un billet de blog choisit aléatoirement.

On est tous d'accord pour dire que la rapidité n'est pas l'objectif d'Agile, rien de nouveau. Si c'est juste pour définir ce qu'est l'Agile, c'est finalement une discutions stérile où on sera tous d'accord sauf sur les mots employés et on va partir sur une discutions de pinaillage.

C'est tout aussi intéressant que de faire un débat pour dire que la somme des angles d'un triangle vaut 180°. À part avoir plein de réponses qui disent que c'est vrai, mais qui le disent d'une manière différente, c'est assez limité. Jusqu'à avoir une personne qui se trompe sur l'emploie d'un mot, on va partir sur un HS de pinaillage, ou se retrouver dans un espace pseudo-euclidien par transition dérivative du cosinus tangent.

Si c'est juste pour dire ce que tout le monde sait déjà, j'ai quelques doutes quant à l'intérêt.
Si on veut apprendre aux autres ce qu'est l'Agile, on écrit un article, pas une actualité/débat.

[Luckyluke34]

En ce qui concerne la qualité du code, ce n'est pas l'Agile qui permet d'agir sur ce point mais l'intégration continue (TU, analyseur de code, etc.).
Cela n'a rien de spécifique à l'Agile.
La méthode Agile peut être parfaitement suivi et produire un code de merde s'il n'y a pas l'encadrement technique suffisant

Pas vraiment d'accord, l'intégration continue telle qu'on la connait actuellement a été formalisée dans eXtreme Programming qui est une méthode agile.

On croit souvent à tort que l'agilité ne concerne que la gestion de projet et pas les pratiques techniques. Appliqué littéralement, ça donne des dysfonctionnements comme ce que certains ont appelé Flaccid Scrum il y a déjà quelques années avec - et sur ce point je te rejoins - du code de m**** si on ne fait pas attention. Pourtant si on regarde bien, les principes du manifeste agile mettaient déjà l'accent sur la technique : "Continuous attention to technical excellence and good design" et des méthodes agiles comme XP nous le disent depuis des années. Le hiatus vient juste du fait que Scrum, la méthode la plus populaire, n'inclut pas de pratiques d'ingénierie.

[souviron34]

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...

[Laurent 1973]

...
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.