Pourquoi nous trompons-nous toujours dans l’estimation des délais ?

Citation:

---

Envoyé par Matthieu Vergne

Pour ma part, les deadlines ne font plus partie de mon vocabulaire. J'ai une todolist de choses à faire, s'il y a besoin d'un suivi on met en place des meetings, mais si on me pose la question quand est-ce que ce sera fini, la réponse est "Quand ce sera fini.".

---

Je suis d'accord dans le sens où il faut faire attention à ce sur quoi on s'engage, mais ce mode de fonctionnement n'est pas une option pour beaucoup d'entre nous. Lorsqu'un client demande un calendrier parce qu'il doit planifier ses mises en production ou organiser ses propres projets internes en fonction de ça, c'est pas trop possible de s'en sortir sans avoir à fournir au moins un ordre de grandeur.

Puis le problème des retards de projet, lorsqu'ils dépassent totalement l'entendement, c'est soit que les besoins ont rien à voir avec le projet initial, ou alors qu'on a été trop ambitieux sans faire de POC suffisantes. Faut dire qu'étrangement, pendant des années on nous a répété que les spécifications avancées de début de projet c'était du temps gaspillé, c'était fastidieux, ça changeait forcément et de fait ce n'était pas "agile" et peu à peu on y revient naturellement car on se rend compte que sans elles, on peut passer des semaines, (mois? années?) entières à ajouter des fonctionnalités ou lisser des détails. Les projets qui n'ont jamais de fin, en chantier perpétuel, c'est ce qui vous tue une boîte. Ca vous empêche de planifier, d'organiser vos ressources et ça vous condamne à passer votre vie à être à la bourre dans tout ce que vous entreprenez.

Dans mon environnement actuel, on essaie de plus en plus d'être précis sur ce qu'on fait et sur le suivi, malgré ça la plus grande source de retard ce n'est pas la mauvaise évaluation de la charge de travail (sans dire qu'on se trompe jamais) mais les nombreux dérangements qu'on subit. Les cas typiques sont tout ce qui concerne la maintenance des anciens clients, le support, les incidents. Impressionnant de voir le retard que ça peut vous faire prendre. On a beau connaître les méthodes, les bonnes pratiques, c'est très difficile et il existe absolument pas de recette magique.

Citation:

---

Envoyé par _skip

...
Puis le problème des retards de projet, lorsqu'ils dépassent totalement l'entendement, c'est soit que les besoins ont rien à voir avec le projet initial, ou alors qu'on a été trop ambitieux sans faire de POC suffisantes. Faut dire qu'étrangement, pendant des années on nous a répété que les spécifications avancées de début de projet c'était du temps gaspillé, c'était fastidieux, ça changeait forcément et de fait ce n'était pas "agile" et peu à peu on y revient naturellement car on se rend compte que sans elles, on peut passer des semaines, (mois? années?) entières à ajouter des fonctionnalités ou lisser des détails. Les projets qui n'ont jamais de fin, en chantier perpétuel, c'est ce qui vous tue une boîte. Ca vous empêche de planifier, d'organiser vos ressources et ça vous condamne à passer votre vie à être à la bourre dans tout ce que vous entreprenez.
...

---

Je suis pas tout a fait d'accord au sens que l'on peux changer le périmètre d'un développement et même ajouter autant de fonctionnalité que l'on veux, ce n'est pas ça le problème.
Le souci, c'est que si on fait des changements au plan initiaux, faut aussi accepté que l'on ne livre pas la même chose.
Ça parait une évidence comme ça, mais visible ce ne l'est pas dans les faits.

Conserver une date de livraison précise est souvent nécessaire.
Cela impacte peut être le travail de mise en production ou celui d'un commercial qui souhaite faire tel ou tel présentation.
C'est donc important de devoir respecter ces jalons.

Mais souvent, en effet, la "lettre au Père Noël" du demandeur est un peu trop ambitieuse.
Donc, on ne livre que ce qui est terminé (+ testé + documenté + validé + ...) à la date prévu et pas ce qui est prévu dans la totalité.

Déjà, il faut avoir de la transparence avec notre client, ce qui doit être pire pour lui, c'est de découvrir l'étendu des problèmes (et des retards) la veille de la livraison.
Il faut donc savoir l'accompagner pour qu'il sache ce qu'il va reçoive à la date de livraison en définissant clairement avec lui ses priorités.
Mais par contre, l'équipe peux continuer pour proposer une deuxième (voir une troisième ou quatrième) livraison.

L'autre souci rencontré, surtout dans le cas de contractualisation entre fournisseur/client, c'est justement le contrat.
Celui-ci n'est pas bien fait pour gérer les impondérables.

Le plus souvent ces contrats nous contraint à respecter un délais très précis et un périmètre figé qui ne correspondra pas finalement aux besoins
Cette problématique contractuelle a un gros impact sur notre travail en particulier sur les dates de livraison.
Voir même, on peux se retrouve dans la situation extrême où le prestataire a "bouffé la grenouille" en terme de coût (dépassement de délais + pénalité de retard) et le client a un logiciel inutilisable et non adapté: tout le monde a perdu !

Je reviendrai seulement là dessus :

Citation:

---

Envoyé par _skip

ce mode de fonctionnement n'est pas une option pour beaucoup d'entre nous. Lorsqu'un client demande un calendrier parce qu'il doit planifier ses mises en production ou organiser ses propres projets internes en fonction de ça, c'est pas trop possible de s'en sortir sans avoir à fournir au moins un ordre de grandeur.

---

Si tu pars du principe que le client est roi est que tu es pieds et poings liés dès lors que le client te dis "moi, j'ai dis que", je comprends ta réserve, mais ce n'est pas mon point de vue. Un contrat ça se négocie, c'est un accord entre deux parties. C'est pas une liste de règles à suivre pour obtenir un salaire. Le client n'est pas roi, c'est celui qui est dans le besoin, et toi tu es celui qui lui permet d'y répondre, au moins jusque dans une certaine mesure (à hauteur de tes capacités). Les deux sont sur un pied d'égalité, et chacun son boulot, le contrat étant là pour établir les contraintes pour les deux. Tout comme un bon entretien d'embauche se fait à deux, chacun ayant son rôle, un bon projet se fait avec les deux parties, et ça commence par le contrat voire avant.

À partir de là, si tu estimes que le projet est trop vague pour donner des estimations probantes, alors le client doit le savoir et choisir entre passer davantage de temps sur la spéc. ou accepter une plus grosse marge d'erreur sur le résultat final (ou aller voir ailleurs). Mais si le client te demande une garantie de livraison et de résultat, tu peux lui dire gentiment que tu préfères ne lui en donner qu'une seule, au choix, de façon à passer ton temps à gérer ton projet efficacement pour en faire un maximum plutôt qu'à te demander si oui ou non tu tiendras des délais décidés avec des informations parcellaires. C'est une approche responsable qui a au moins le mérite de chasser ceux qui ne savent pas ce qu'ils veulent et qui te permet de te focaliser sur des projets vraiment assumés, où le client n'est pas juste là pour déléguer du travail et avoir quelqu'un à qui rejeter la faute si ça se passe mal. Après, si tu gratte sur chaque contrat et que tu ne peux pas te permettre d'en perdre un seul, là je pense que c'est un problème de gestion d'entreprise (au sens large). Mais après on me dira que je ne suis pas assez expérimenté sur le sujet pour en parler.

Je suis juste un peu étonné que l'article parle d'estimation des délais à propos de méthode Agile puisque le principe même de l'Agilité est de ne plus se focaliser sur les délais de réalisation.

En gestion de projet "classique" (genre cycle en V): on fixe les fonctionnalités au départ, on fixe aussi généralement la deadline/budget au départ et la variable d’ajustement c'est la deadline/bugdet qui n'est jamais respectée.

En gestion de projet Agile, la variable d'ajustement ce sont les fonctionnalités, donc (à moins d'avoir vraiment mis un délai trop court), le délai sera forcément respecté mais il n'y aura pas forcément (et probablement pas) toutes les fonctionnalités. Et là on voit si ça vaut le coup de remettre de l'argent en plus ou si on se contente de ce qu'on a.

C'est certain que ce doit être plus simple d'évaluer les tâches pour une seule semaine, c'est plus simple de se projeter et on sera plus prudent sur quoi on s'engage le lundi pour le vendredi (on n'a pas la marge de manœuvre du week-end). En contrepartie, il faut déjà être bien à l'aise avec l'agilité pour faire des sprint d'une seule semaine.

Pour moi la problématique de passer d'une gestion classique à une gestion agile c'est de penser à tout prendre en compte dans l'évaluation: pas seulement évaluer le développement de la fonctionnalité elle-même, mais aussi prendre en compte les tests, l'intégration, la doc, etc. qu'on a vite tendance à ne pas considérer alors que ça consomme pas mal de temps.

Citation:

---

Envoyé par olreak

Pour moi la problématique de passer d'une gestion classique à une gestion agile c'est de penser à tout prendre en compte dans l'évaluation: pas seulement évaluer le développement de la fonctionnalité elle-même, mais aussi prendre en compte les tests, l'intégration, la doc, etc. qu'on a vite tendance à ne pas considérer alors que ça consomme pas mal de temps.

---

Il me semble que c'est plutôt l'inverse : en agile il ne faut plus (et même surtout pas) tout prendre en compte, contrairement au classique, justement parce que tu y vas par itération. Tu considères 1 chose à la fois et tu prend en compte ce qui se réfère à cette chose là uniquement dans ton estimation. Sinon tu ne peux pas être "agile".

Citation:

---

Envoyé par olreak

Je suis juste un peu étonné que l'article parle d'estimation des délais à propos de méthode Agile puisque le principe même de l'Agilité est de ne plus se focaliser sur les délais de réalisation.

---

Bien sûr que si
Sinon comment définir le contenu du backlog du sprint sans cela ?

Avec l'Agilité, on s'enlève énormément de pression en gérant des priorités.
Autrement dit, on détermine une liste de tâches à réaliser dans un sprint et on la trie en fonction de sa criticité et on démarre du haut de la pile.
De ce fait, en fin de sprint, il ne doit rester que les tâches les moins prioritaires ce qui fait que ce n'est pas "trop grave" si celles-ci sont décalées au sprint suivant ou pour une V2 du soft, si v2 il y a...

Cependant, il faut tout de même construire une liste réaliste.
Le but reste de tout faire, dans la mesure du possible. C'est tjrs motivant d'avoir un challenge.
Fixer une liste trop longue peut provoquer un sentiment de découragement dans l'équipe et surtout, donne de faux espoirs aux clients.

Désolé je vais hijacker ce fil.

Bonjour Saverok, tu bosses en Agile sur tes projets ? Si oui, comment gères-tu une livraison qui ne correspond pas aux attentes clients d'un point de vue facturation ?

@Reward: je me permet de te répondre sur la facturation.

Déjà, si tu bosses en Agile, en toute transparence, ton client est au courant.
Vaux mieux, vu que tu vas fortement l'impliqué tout au long de ton développement.;)

Et donc, du départ, ton contrat est agile (par exemple, celui ci: http://www.contrat-agile.org/)
Dans ce contrat, tu ne t'engages pas sur un contenu figé comme sur un contrat au forfais mais plutôt sur un processus de travail et une relation donnant/donnant entre les 2 protagonistes.
La facturation se fera donc, chaque sprint par exemple, sur la quantité de travail fournis (en gros, un nombre de jours/homme).

Tu vas me dire qui y a plein de déviance:
- Pourquoi le fournisseur ne va pas gonfler la facture?
- Pourquoi le client ne fera pas preuve de mauvaise foi sur ses spécifications ?
....

Ça marche parce que le contrat prévois, comme tout projet agile, que celui-ci peux se terminer à tout moment (moyennant un préavis défini à l'avance) par l'un des deux partie.
Donc, le client et le fournisseur deviennent de vrai partenaire où aucun des deux ne veux pas "pigeonner" l'autre sous peine que l'autre se retire:
- Le fournisseur est réglo en facturation pour pouvoir continuer le projet.
- Le client s'implique dans le projet au risque que le fournisseur le laisse tomber.
Les acheteurs & vendeurs se trouvent enfin lier par ce partenariat: le premier à un besoin informatique "métier" que le deuxième peux réaliser.

Les techniques des deux cotés peuvent enfin travailler sereinement et en confiance pour le bien du produit sans être le nez dans le contrat.

Merci Laurent c'est vraiment très intéressant.

Et si, comme dans une méthode traditionnelle, la livraison répond au cahier des charges, mais ne correspond pas à ce que voulait le client (contentieux assez classique), comment fais-tu ? C'est de ta poche, 50/50, ou tu te fais quand même facturer ?

Le cahier des charges évolue avec le projet quand tu fais de l'agile. C'est le principe de l'itération : tu décides en début d'itération avec le client ce que tu comptes faire, puis à la fin de l'itération tu livre, puis en début d'itération suivante tu fais une petite analyse avec le client pour voir quoi faire pendant la prochaine itération (autre chose, quelque chose de pas fini pendant l'itération précédente, revoir ce qui a déjà été fait, etc.). Ton cahier des charges est donc revu à chaque itération en fonction des besoins actuels du client, et non pas défini une fois pour toute en début de projet. Donc ça n'a pas vraiment de sens de parler d'un cahier des charges satisfait avec un client insatisfait.

Pris autrement, si on part du principe que le cahier des charges est le document établit en début de projet uniquement, ce que tu implémentes correspond à ce qui se décide en début d'itération, et qui dépend des besoins actuels du client. Le cahier des charges ne donne alors qu'une base, et le projet peut s'en éloigner si le client estime que finalement il lui fallait autre chose. Donc s'il devait y avoir une divergence, ce serait plutôt une divergence vis-à-vis du CdC et non du besoin du client.

C'est un peu comme si tu faisais construire la maison de tes rêves.

Au début, architecte te propose un plan initial suivant des envies est une estimation du coût.
Cela te permet de négocié ton prêt avec ton banquier.

A mesure que les travaux avance tu fais le point sur l'avancé avec lui mais cela peux te donner des idées différentes sur la suite en voyant la maison se construire.

Tu peux alors revoir avec l'architecte des modifications sur la suite (finalement la porte plutôt ici que là, une baignoire plutôt qu'une douche, pas ce mur entre le salon et la cuisine, ...)
Et tu refais alors éventuellement des devis en conséquence sur la modification (montant qui peux être supérieur ou inférieur au devis initial)
Bien sur, les modifications ne coûterons pas le même pris suivant l'avancer du chantier: on peux changer tard la couleur d'une peinture, très difficile de déplacer un mur porteur quand presque tout est fini.
Et si ton banquier ne veux pas payé plus qu'initialement prévu, à toi de faire remplacer un équipement par un autre suivant ce que tu préfères le plus.

Mais à chaque livraison intermédiaire des artisans, tu ne règles que les travaux réellement réalisés, pas les devis initiaux qui n'ont rien a voir et ni ceux qui ont été abandonné.

Quand tu emménages dans ta maison, tu es satisfaits de ton logement qui correspond à ce que tu pourrais avoir de mieux par rapport à ton budget.
Par contre, elle n'a peut-être plus rien avoir avec le plan initial, mais tu t'en contre-fou.

Finalement, c'est un peu pareil avec un projet agile en informatique.
La différence, c'est qu'en agile, les estimations de coût se font en "points d'effort" (~ des jours de développement) sur chacune des fonctionnalités atomiques.

Wep, et faire une estimation du temps nécessaire pour un gros projet, c'est déjà pas simple (ca se saurait).
Mais faire une estimation d'un projet dont le perimetre est mouvant, c'est encore moins simple :) C'est quand même peau de banane comme concept.

T'as intérêt que ton client soit Agile/Compliant (et qu'il ne passe tout les deux jours pour voir ou tu en es).
Et ca, ca arrive assez trop peu souvent.

Citation:

---

Envoyé par Nicam

Wep, et faire une estimation du temps nécessaire pour un gros projet, c'est déjà pas simple (ca se saurait).
Mais faire une estimation d'un projet dont le perimetre est mouvant, c'est encore moins simple :) C'est quand même peau de banane comme concept.

---

A priori, l'évaluation totale ne t'intéresse pas, justement parce que tu sais que ça peut bouger. On se focalise sur les itérations, chaque itération étant un mini-projet, et c'est sur ces mini-projets qu'on fait des estimations, un mini-projet après l'autre (on n'évalue pas un mini-projet avant d'y être). Tu peux faire une estimation globale pour dire d'avoir une idée, mais tu sais d'avance que ce n'est pas ce sur quoi tu dois te baser, justement parce que ça doit être revu à chaque itération, sinon c'est pas agile. Quand je dis dois, évidemment, ça veut pas dire tout rediscuter toutes les semaines (à supposer que ce soit des itérations d'une semaine), mais bien faire l'effort chaque semaine de discuter des objectifs de la semaine en question, et pas se contenter de dire plusieurs fois d'affilée "aujourd'hui j'ai pas le temps, suivez le planning établit il y a trois mois". Sinon on perd le contact avec le client et le projet se fige sur les spéc telles qu'interprétées par les dévs, et non sur les besoins réels du client. On revient donc à du classique.

Si ça doit de toute façon être revu chaque semaine, y'a pas grand intérêt à faire une estimation globale fiable. Donc si c'est effectivement plus dur, c'est de toute façon pas un problème.

Je comprends plutôt bien le changement de paradigme de l'agile, à savoir des itérations qui permettent de toujours coller avec le beoin du client, et une estimation qui intervient en début de sprint pour quelques semaines uniquement, ce qui apporte beaucoup de flexibilité dans l'évolution du projet. Ca, c'est du côté opérationnel.

Maintenant, j'ai du mal à voir comment cela s'intègre dans les processus de décisions plus globaux. Si mon entreprise hésite entre deux gros projets (de l'ordre du semestre ou de l'année ou même quelques années) mais ne peux en faire qu'un des deux, comment peut-elle choisir? On a alors besoin d'une estimation du coût de chacun des deux projets pour décider lequel des deux faire non? Comment l'agile propose-t-il de répondre à cela?

Exemple concret, imaginons que je suis CEO d'une petite boîte dans le retail. J'hésite entre mettre mes ressources sur un nouvel ERP pour aider mes magasins, ou obtenir une plate-forme d'e-commerce pour vendre sur internet. Je ne pourrais en faire qu'un des deux, et il le faudrait avant décembre (ça me laisse 6 mois), parceque je fais la moitié de mon chiffre d'affaire annuel en 1 mois lors de la période de Noël. Si j'ai des estimations et des engagements contractuels (coûts/délais, et pénalités associées), je sais comment prendre une décision entre les deux projets. Maintenant, comment l'agile me permet-il de décider quel est le bon projet à choisir?

Merci à tous pour vos réponses :).

Citation:

---

Envoyé par GeoffreyOnRails

Je comprends plutôt bien le changement de paradigme de l'agile, à savoir des itérations qui permettent de toujours coller avec le beoin du client, et une estimation qui intervient en début de sprint pour quelques semaines uniquement, ce qui apporte beaucoup de flexibilité dans l'évolution du projet. Ca, c'est du côté opérationnel.

Maintenant, j'ai du mal à voir comment cela s'intègre dans les processus de décisions plus globaux. Si mon entreprise hésite entre deux gros projets (de l'ordre du semestre ou de l'année ou même quelques années) mais ne peux en faire qu'un des deux, comment peut-elle choisir? On a alors besoin d'une estimation du coût de chacun des deux projets pour décider lequel des deux faire non? Comment l'agile propose-t-il de répondre à cela?

Exemple concret, imaginons que je suis CEO d'une petite boîte dans le retail. J'hésite entre mettre mes ressources sur un nouvel ERP pour aider mes magasins, ou obtenir une plate-forme d'e-commerce pour vendre sur internet. Je ne pourrais en faire qu'un des deux, et il le faudrait avant décembre (ça me laisse 6 mois), parceque je fais la moitié de mon chiffre d'affaire annuel en 1 mois lors de la période de Noël. Si j'ai des estimations et des engagements contractuels (coûts/délais, et pénalités associées), je sais comment prendre une décision entre les deux projets. Maintenant, comment l'agile me permet-il de décider quel est le bon projet à choisir?

---

A priori l'agile ne le permet pas, car il se base justement sur du progressif. Si tu veux trancher tout de suite pour les prochains mois à venir, c'est une décision qui nécessite une évaluation globale, et donc tu retombes sur du management classique. L'agile est là justement pour être plus flexibles face aux évolutions. C'est comme pour faire un airbus : on ne fait pas un avion en agile, pour la simple raison qu'à la fin on veut :
- un avion
- qui vole
- qui consomme peu
- qui est conforme à la règlementation en vigueur
- ...

Le besoin est fixé au départ et on ne veux pas que ça change. Dans ton cas c'est pareil : tu veux savoir s'il vaut mieux l'un ou l'autre système, mais tu ne veux pas changer d'avis en cours de route. Il te faut donc retourner sur du cycle en V. L'agile n'est pas mieux que le cycle en V, c'est une autre façon de faire, plus adaptée aux projets naturellement évolutifs où il n'est pas nécessaire d'avoir une évaluation poussée des besoins dès le départ. Si tu veux à tout prix le faire en agile, de façon à repousser au plus tard la décision, alors il te faut par exemple identifier les parties communes entre les deux système (e.g. stockage et logistique) et commencer par là. Le jour où il te faudra effectivement trancher, tu auras eu plus de temps pour réunir les informations suffisantes et tu auras déjà une base fonctionnelle prête à être étendue dans un sens ou dans l'autre. Voire tu auras fait des parties communes suffisamment solides pour faire les deux de manière basique, de façon à essayer les deux à court terme avant de te retrancher sur l'un ou l'autre si vraiment tu n'as pas besoin des deux. Mais ça c'est si tu changes d'avis sur la nécessité de trancher dès le départ.

Il faut utiliser la méthode qui correspond au besoin :
- fixer et ne plus changer => cycle en V
- évolutif => agile

Je pense surtout qu'on ne prend pas le temps de faire correctement les chiffrages, de manière générale. Comment bien de fois m'a t-on demandé à brûle-pourpoint
"Comment de temps il te faut pour faire ça ?
- Je sais pas, faut que je regarde.
- Oui mais c'est 1 jour ? 2 jours ?
- 1 semaine ?
- OK !"
Et puis en regardant en détails, il faut non pas 5 jours (1 semaine) mais 7. Trop tard, on a déjà lancé les plannings avec 5 jours. Remarquez, des fois c'est l'inverse, je dis 5 jours et en fait je le finis en 2 jours car il y avait déjà du code qui trainait pour faire ça.

Chiffrer, ça prend du temps car comme il est dit dans l'article, il faut commencer à travailler un peu (beaucoup ?) sur le problème pour bien comprendre les tenants et les aboutissants. Sur des petits chiffrages (de l'ordre de la semaine), le temps de chiffrage est rapide (1 heure ou 2) ; sur des gros chiffrages, ça devient souvent trop long pour qu'on nous laisse le temps de le faire correctement.

Citation:

---

Envoyé par Matthieu Vergne

Je reviendrai seulement là dessus :
Si tu pars du principe que le client est roi est que tu es pieds et poings liés dès lors que le client te dis "moi, j'ai dis que", je comprends ta réserve, mais ce n'est pas mon point de vue. Un contrat ça se négocie, c'est un accord entre deux parties. C'est pas une liste de règles à suivre pour obtenir un salaire. Le client n'est pas roi, c'est celui qui est dans le besoin, et toi tu es celui qui lui permet d'y répondre, au moins jusque dans une certaine mesure (à hauteur de tes capacités). Les deux sont sur un pied d'égalité, et chacun son boulot, le contrat étant là pour établir les contraintes pour les deux. Tout comme un bon entretien d'embauche se fait à deux, chacun ayant son rôle, un bon projet se fait avec les deux parties, et ça commence par le contrat voire avant.

---

On le fait pas pour se retrouver dans un rapport hiérarchique entre les deux parties, on le fait parce que c'est nécessaire pour tout ce qui nécessite de planifier et d'organiser. Et c'est normal.

Sans tomber dans un rapport maître-esclave, il est parfaitement normal lorsque tu réponds à un appel d'offre que tu dises combien de temps il te faut et combien ça va coûter, ces deux choses étant étroitement liées. C'est le principe même d'un devis ou d'une étude pré-contractuelle et c'est pareil dans tous les domaines. Ca n'empêche pas que tu fasses des réunions, que tu négocies en cours de route entre le dépassement délai-coût dus aux ajustements ou que tu recadres. Cependant tu échappes pas au besoin de savoir quand tu livres et quand c'est considéré comme fini ne serait-ce que pour toi pour planifier tes ressources, et aussi d'avoir un semblant de cahier des charge pour pouvoir distinguer correctement ce qui était prévu ou ce qui est de la plus-value.

Je comprends que ça arrange un développeur de dire: ok j'ai que 2 mains, je fais les choses par ordre de priorité et je finis quand je finis. Mais c'est pas forcément la logique du chef d'entreprise, du maître d'ouvrage ou des autres intervenants du projet. Le maçon pourrait tenir ce genre de propos aussi mais je doute que ça arrange son entreprise, le client de son entreprise, le carreleur, l'installateur sanitaire, le cuisiniste, l'électricien et j'en passe. On peut pas toujours imposer sa façon de bosser au reste du monde, on peut parfois trouver des arrangements mais faut justifier et faire comprendre que les deux parties s'y retrouvent, et c'est moins évident que dans les manuels de méthodologie.

Citation:

---

Envoyé par GeoffreyOnRails

Exemple concret, imaginons que je suis CEO d'une petite boîte dans le retail. J'hésite entre mettre mes ressources sur un nouvel ERP pour aider mes magasins, ou obtenir une plate-forme d'e-commerce pour vendre sur internet. Je ne pourrais en faire qu'un des deux, et il le faudrait avant décembre (ça me laisse 6 mois), parceque je fais la moitié de mon chiffre d'affaire annuel en 1 mois lors de la période de Noël. Si j'ai des estimations et des engagements contractuels (coûts/délais, et pénalités associées), je sais comment prendre une décision entre les deux projets. Maintenant, comment l'agile me permet-il de décider quel est le bon projet à choisir?

---

Je pense que quand même, l'agilité peux t'aider comme CEO.

Par contre, dans ton exemple, la question ne se pose pas en ce terme.
Un manager ou PDG ne doit pas prendre une décision sur un investissement du point de vu de "qu'est ce que je suis capable de financer?" mais plutôt "sur lequel j'aurais le plus de retour sur investissement rapide?"

Tu dois donc, avec des collaborateurs impliqués dans les 2 outils, faire une analyse de ces deux projets et identifier ce qu'il manque dans ton ERP et ta plate-forme d'E-commerce.
De là, tu définis les premiers items fonctionnelles que tu as besoin: c'est une ébauche de 2 futures product backlogs finalement.
Par contre, tu vas chiffré sur chacun d'eux qu'elle incidence financière cela aura sur ton entreprise suivant s'il y a tels ou tels items en décembre ou pas.

Et alors, tu auras un plan comprenant 2 listes de fonctionnalités chiffré en "valeur" R.O.I
En discutant éventuellement avec des experts techniques développements, tu pourras quand même te faire une idée "grosse maille" d'une fourchette d'un nombre de fonctionnalité réalisable en 6 mois avec l'équipe de développement disponible (mais avec une forte dose d'incertitude sur les dernière).
tu vas alors pouvoir prendre ta décision sur lancer tel ou tel projet pour que dans 6 mois avoir soit un ERP, soit un portail E-commerce qui te fasse gagner un maximum d'argent.
Et pourquoi pas, la décision sera peut-être de faire 3-4 items en 2 mois sur l'ERP et 8-10 items en 4 mois sur le E-commerce pour être optimal.
Il y a de grande chance que ni l'un ni l'autre n'aura l'ensemble des besoins que tu avais identifiés, mais l’investissent sera déjà amortie au mieux en 6 mois.

Et puis, le travail d'analyse des 2 projets informatiques n'est pas perdu.
Tu pourras très bien les réutiliser dès janvier pour lancer d'autres développements .... en Agile bien sur ;)

Donc, en effet, l'agilité peux aussi aider à prendre de bonne décision stratégique.

Chez moi, ils ont engagé un cadre avant vente frais sorti d'une école de commerce qui nous a rapporté 2 clients avec un pré chiffrage.
Une fois ce chiffrage acté par le direction on nous a lancé dans le developpement. j'ai manifester mais crainte en ma qualité de développeur full stack.
j'ai été convoqué chez le chef avec monsieur avant vente. j'ai présenté mais arguments technique avec mon jean et mon TShirt. Monsieur Avant vente a parlé francais et americain (Delivery - Time to Market - digitalisation) le chef lui a dit ok on check à midi en salle de sport sur ce point mais je voius que tu maitrise bien. j'ai pris une tape sur l'épaule kevin on a confiance vous serez au rendez vous.
On a pris 3 mois de retard, ce fut de ma faute et de celle de mon collegue sur l'autre projet de monsieur Avant vente qui lui continu sa progression dans une autre BU de la boite.

alors que si on m'avais demandé j'aurais donné un chiffrage que je maitrise.

et si le chiffrage était fait par ceux qui vont developper