Discussion :

[Xelland]

Pas cher et de bonne qualité, ça me semble sacrément fumeux quand même xD. Parce que plus long=plus cher.

en fait, les développeurs ne seront pas à 100% sur la tâche; la tâche aura une priorité moindre , d'où le temps plus élevé (voir diagrammes de gantt)
sinon, c'est vrai que ça fait bizarre

[Glutinus]

L'effet tunel c'est le 'je fais à ma sauce mais je pense faire bien' (dis grossièrement).

L'effet tunnel c'est surtout :
1/ les possibilités d'être bloqué sur une section du projet genre, doit passer de chez A à chez Z, il est actuellement chez N mais il est en vacances... pas grave, c'est jamais plus que deux semaines sur un projet de trois ans. Oui mais c'est vital.
2/ c'est pas faire à sa sauce, c'est que l'utilisateur se rend compte seulement au dernier moment que ce n'était pas ce qu'il voulait, qu'il l'a mal exprimé auprès du MOA, ou que le MOA l'a mal exprimé, ou le MOE l'a mal développé.

Si on attend deux ans de projet pour s'apercevoir qu'on voulait un fichier de débit et non de crédit, c'est qu'il aurait fallu faire la recette bien avant.

Qui plus est, on n'a de plus en plus d'utilisateur "facebook" maintenant. Avant, on faisait bien les interviews et on comprenait peu ou prou ce qu'il voulait. Maintenant, les utilisateurs c'est plutôt du genre "je sais pas du tout mais pas du tout ce que je veux, donc tu vas me développer le truc de ton choix et je te dirai après si ça me convient ou non". Le développeur fait au mieux un projet de trois jours, au pire un projet de trois mois, avant que l'utilisateur dise "Mouii, mais non j'en veux pas". Et parfois juste parce que c'est la couleur qu'il n'aime pas, mais il se garde bien de le dire. L'IT devient alors le bouc-émissaire "Y sont cons ces développeurs, y comprennent rien, je leur ai demandé un bouton rouge qui calcule mon taux, c'est pas compliqué pourtant"


Un peu comme Facebook qui est arrivé sur le marché sans réel besoin, et finalement le besoin s'est créé par la suite.

[zecreator]

Du coup, j'an reviens à cette question : Qu'est-ce qui et facturé au client en mode Agile ? Le temps passé ou le résultat ?

Car dans une gestion en V, on est assez transparent sur le prix que paiera le client, et les délais de production. Par exemple, je convient d' un planning avec mon client avant de démarrer chaque projet, avec des étapes de check bien précises. C'est une sécurité pour moi, et c'est rassurant pour lui.

Je ne bosse jamais sans cahier des charges.

[gangsoleil]

Du coup, j'an reviens à cette question : Qu'est-ce qui et facturé au client en mode Agile ? Le temps passé ou le résultat ?

De ce que j'ai vu (mais il y a sûrement d'autres manières de faire) : l'équipe commerciale signe un contrat avec le client, quelle que soit la méthodologie employée.

Une fois que ceci est signé, tu sais combien tu vas facturer au client, ce qui revient donc à dire que tu connais également le nombre de jours de dev que tu peux payer (normalement, cela a été vérifié avant avec les équipes de dev hein).

La méthodologie que tu utilises derrière importe peu.

[zecreator]

De ce que j'ai vu (mais il y a sûrement d'autres manières de faire) : l'équipe commerciale signe un contrat avec le client, quelle que soit la méthodologie employée.

Une fois que ceci est signé, tu sais combien tu vas facturer au client, ce qui revient donc à dire que tu connais également le nombre de jours de dev que tu peux payer (normalement, cela a été vérifié avant avec les équipes de dev hein).

La méthodologie que tu utilises derrière importe peu.

J'ai cru comprendre qu'en Agile le projet évoluait en fonction des itérations, rien n'est vraiment figé. Cela permet au client de revenir sur un besoin, d'en apporter d'autres... Maus quelles sont les limites imposées au client, car on ne peut pas être full pendant 3 ans sur un projet dont le budget ne couvre pas ce temps ?

[transgohan]

En fait si le besoin du client évolue en dehors du contrat initial (budget/temps) alors on fait signer un avenant.
On peut aussi choisir de déscoper du travail qu'il reste à faire et qui coûte aussi cher que ce que veut le client.

[Mat.M]

Tu te trompes

Zecreator n'a peut-être pas tout à fait tort non plus
Car lorsque le projet a pris du retard , qu'il y a des grosses problématiques techniques, que l'architecture du projet est mal faite , il faut bien donner des explications au client.
Et c'est là tout l'art de la communication de dire au client "ne vous inquiétez-pas le projet avance".
Comme dirait l'autre dans un sketch bien connu "trouvez tous les subterfuges adéquats"

[foetus]

Car lorsque le projet a pris du retard , qu'il y a des grosses problématiques techniques, que l'architecture du projet est mal faite , il faut bien donner des explications au client.

C'est aussi une raison de l'existence des méthodes agiles : prévoir tout ce qui va se passer pendant un développement c'est soit très très long pour faire le cahier des charges soit impossible - autant faire le minimum en termes de spécifications et fournir des prototypes.
Et comme d'hab, il va y avoir rallonge budgétaire (parce qu'1 fois le projet lancé et très avancé dans son développement, il faut le finir coûte que coûte).
En France, par exemple, il me semble qu'au niveau architecture on est champion pour cela Au début "on a tout prévu, tout tient dans le budget, signez là " Et combien de fois le budget est multiplié par 2.

Mais il faut dire aussi que les méthodes traditionnelles (cycle en V, waterfall, ...) sont nées dans les années 70 où les ordinateurs n'avaient ni de souris, ni d'écrans couleurs, que Internet était inexistant et qu'on ne parlait pas de multi-plateformes, multi-écrans et d'intégration réseaux sociaux.
Maintenant, rien qu'une petite application mobile est déjà très complexe.

[zecreator]

Si un client pose un cahier des charges fixes, avec des délais précis car cela fait parti de ses enjeux (95% de mes projets) du coup est-ce que Agile est utile dans ce contexte ? Surtout si le client n'a pas plus de temps à investir que ça sur ce projet, car ayant plusieurs projets sur le feu. Pour lui, les besoins sont exprimés dans le cahier des charges, et ils changent rarement en cours de route...

[Glutinus]

Mais il faut dire aussi que les méthodes traditionnelles (cycle en V, waterfall, ...) sont nées dans les années 70 où les ordinateurs n'avaient ni de souris, ni d'écrans couleurs, que Internet était inexistant et qu'on ne parlait pas de multi-plateformes, multi-écrans et d'intégration réseaux sociaux.
Maintenant, rien qu'une petite application mobile est déjà très complexe.

Et également, soit globalement les SSII étaient éditrices ou au forfait, soit le le "client final" avait déjà ses propres structures.
C'était peut-être plus simple, et plus les mains dans le cambouis. Et certainement plus de budget pour payer même des "petites mains" (testeurs qui déroulaient bêtement un cahier de recette, équipe complète de release etc.)
A la multiplication des intermédiaires, se rajoutent aussi une vision d'un projet comme étant un moyen et non une fin... Pour les derniers clients que j'ai faits, les projets étaient surtout un moyen de bien se faire voir, de montrer qu'on a la plus grosse etc. Alors oui, vous me direz que c'est directement lié au résultat et la satisfaction des utilisateurs, n'empêche quand les projets durent 3 ans on a beaucoup le temps de faire de la politique. Donc finalement les trucs de longue haleine, ça intéresse beaucoup plus les gens.

Faut pas oublier que l'Agilité est né du pragmatisme : s'assurer très rapidement qu'on fait bien ce qui est demandé, minimiser les réunions chronophages...

Sans avoir bossé en Agile, je pense que ça se résume plus à une enveloppe : on met à disposition N développeurs estimé selon la produit demandé, on fait des sprints, et le client fait une rallonge de budget selon les besoins en fin d'enveloppe.

[foetus]

est-ce que Agile est utile dans ce contexte ?

Les méthodes agiles sont des méthodes de développement. Et donc, si tu codes un site Internet ou une application, que tu es seul ou dans une petite équipe (environ 5 personnes), tu vas t’apercevoir que tes méthodes vont se rapprocher des méthodes agiles (ou sinon tu codes comme un gros goret)
Surtout si tu utilises correctement des outils comme git, qui te "force" à versionner petit incrément par petit incrément tout en ayant un code cohérent pour revenir en arrière.

Après je pense que si tu n'as pas une structure qui t'accompagne dans les relations avec le client, seul ou avec une petite équipe, cela va être compliqué de faire des avenants sur le contrat initial, déscoper des fonctionnalités pour s'accorder avec les besoins du client (comme l'a dit @transgohan), ...
Et donc seul ou avec une petite équipe, je pense que c'est plus facile de travailler en mode mission projet : tu signes des spécifications, un budget et un délai, avec des démonstrations planifiées, et tu t'y tiens.

[yento]

Sans avoir bossé en Agile, je pense que ça se résume plus à une enveloppe : on met à disposition N développeurs estimé selon la produit demandé, on fait des sprints, et le client fait une rallonge de budget selon les besoins en fin d'enveloppe.

Concretement, c'est comme ca que quasiment tous les projets operent en pratique. Ressources fixes, c'est a dire N développeurs pendant X mois.
Pareil que ce soit en interne ou en SSII.
L'objectif est bien sur d'aller le plus loin possible. Ca demande d'identifer et de realiser les features les plus importantes, dans l'ordre.


Mais les clients sont trop cons pour admettre ce mode de travail alors ils preferent travailler en mode projet. Objectif fixe. Le projet P doit etre délivrer a telle date. (Qu'est ce que qui doit etre livre? c'est tout une histoire a débattre!).
Ca donne l'illusion que c'est infaillible, tout est deja prevu d'avance. Ca ne peut que reussir a temps. Facile a vendre pour sa carriere.
Et c'est coherent avec la legal et la compta. Genre la SSII ne sera pas paye si le projet n'est pas complété parfaitement a la date prevue. (correct pour certains business mais pas en sous traitance informatique).

[zecreator]

Ben prenons l'exemple du feu d'artifice du 14 juillet, celui de Versailles par exemple. Il y a un appel d'offre, avec une date de livraison fixe. On doit donc créer un projet de spectacle, avec une enveloppe fixée à la proposition. On revient rarement dessus, c'est au prestataire de faire tenir ses coûts dans ce budget. Du coût, on est d'accord que Agile, n'est pas vraiment adapté à cette situation. Et la marge de modification du client doit être limitée au maximum si l'on veut tenir les délais.

Comme beaucoup de prestations d'artisanat, comme la création d'une terrasse, d'une piscine, la déco de sa maison...

Agile appliqué à tous les types de projet, c'est un peu utopique non ?

[foetus]

C'est surtout que tes exemples sont bidons pour 2 raisons :

• il y a trop peu d'itérations. Pour la piscine, 1) le trou 2) coffrage+fondation 3) béton 4) carrelage (en gros). Dans un projet informatique, entre les écrans, les accès base de données, les tests, ... cela en fait du travail. Comme je l'ai dit, actuellement même une petite application représente un travail assez conséquent.
• on ne peut pas modifier les choses. Pour la piscine, si le client s’aperçoit pendant l'étape 3 que le trou est trop grand/ petit. On fait quoi ? Il faut tout péter et tout recommencer. Par contre, avec une application/ site et si tu as utilisé correctement une méthode agile, la majorité des modifications sont réalisables rapidement (changement de couleur, réorganisation d'1 écran, ajout d'un nouveau réseau social, ajout d'un identifiant/ mot de passe, ...) Mais, il faut quand même discuter de leur réalisation et notamment du temps. En Scrum tout est planifié et prioritisé.

[transgohan]

Agile appliqué à tous les types de projet, c'est un peu utopique non ?

Le manifeste n'a jamais indiqué que la méthode était applicable à tout projet, bien au contraire.
Il y a une liste de règles, si ton projet ne rentre pas dans ces règles alors ne fais surtout pas d'Agile.

On pourrait même dire que faire de l'Agile en interne avec un client qui a un contrat fixe sans négociation c'est du suicide...
Bon après, c'est surtout que les équipes se sentent plus motivées pour bosser en Agile, mais dans un cas comme celui-là c'est déconseillé comme méthode.
A part peut être te rendre compte que tu dérives vers le mur au fur et à mesure de l'avancement.

[zecreator]

C’est là où il y a un manque de clarté, car dans certains cours Agile sur un autre site par exemple, il est souvent dit que Agile est une méthode de gestion de projet, et applicable à n’importe quel produit développé. Dans le cours, il y a une balançoire en exemple.

Mais ici, on affirme que c’est surtout lié au dev informatique. Alors qu’a Priori, on pourrait appliquer Agile a d’autres types de projet, s’il rentre dans le manifeste.

Pourquoi parler de méthodes de dev ? Pour créer une balançoire, on développe rien.

[Marco46]

C’est là où il y a un manque de clarté, car dans certains cours Agile sur un autre site par exemple, il est souvent dit que Agile est une méthode de gestion de projet, et applicable à n’importe quel produit développé.

Bah ils doivent avoir des problèmes de relecture de leurs cours je suppose ...

Pourquoi parler de méthodes de dev ? Pour créer une balançoire, on développe rien.

Ben c'est un ensemble de pratique créer par des devs pour faire du dev pas de la menuiserie. Après il y a des personnes et des sociétés qui font leur beurre en surfant sur cette mouvance et son adoption massive et qui racontent n'importe quoi mais c'est un autre sujet.

Ne jamais oublier que ça a été créé par des devs pour faire face aux problèmes du waterfall et du cycle en V. Et ne jamais oublier non plus que les auteurs sont sortis de la salle aboutissant à la rédaction du manifeste avec un très grand nombre de désaccords.

C'est un guideline, pas une méthode ou une bible.

[zecreator]

Merci @Marco46 pour ces précisions.

Comme je m’impreigne de la culture Agile, c’est quoi la différence avec Scrum ? J’entends aussi parler de XP ??

[tesla]

Merci @Marco46 pour ces précisions.

Comme je m’impreigne de la culture Agile, c’est quoi la différence avec Scrum ? J’entends aussi parler de XP ??

Scrum c'est une des méthodes Agile, sans doute la plus répandue avec Kanban. XP en est une autre.

Faut pas s'imaginer que c'est très compliqué hein.
Des tas de gens appliquaient déjà les "méthodes Agile" sans le savoir avant que ne sorte le Manifeste Agile, un peu comme Mr Jourdain faisait de la prose.
En gros, lorsque tu découpes ton projet par lot (avec validation des livrables intermédiaires par le métier), tu appliques une méthode qui se rapproche de Scrum.
Après c'est la granularité des lots et leur fréquence de livraison qui jouent.

[zecreator]

Scrum c'est une des méthodes Agile, sans doute la plus répandue avec Kanban. XP en est une autre.

Faut pas s'imaginer que c'est très compliqué hein.
Des tas de gens appliquaient déjà les "méthodes Agile" sans le savoir avant que ne sorte le Manifeste Agile, un peu comme Mr Jourdain faisait de la prose.

Voilà. Je me demande si au bout de presque 20 ans de XP avec des clients divers, sans le savoir, j'ai régulièrement appliqué Agile. Car quand je lis les tutos, articles et guides, ça fait souvent écho à ce que j'applique.

Et j'ai aussi ce sentiment sur des méthodes de dev ou des technicités. Je n'utilise pas les mêmes termes qu'un recruteur, mais je veux dire la même chose.

C'est le fardeau du mec qui a été autodidacte à 80% de sa carrière, et qui à surtout pratiqué des méthodes inspirées du standard. Après, est-il moins compétent ? Je ne pourrais pas dire...