Discussion :

[souviron34]

Déjà que je trouvais que l'agilité avait un côté "communiste" mais l'a tu m'as définitivement convaincu !
Tout cela suppose l'absence de rapport qualité/coût ou bien l'infinité des ressources (... sans parler de l'effacement des individualités).
Je me demande bien pourquoi il y a plus de gens qui achètent des Dacia que des Mercedes, pourtant cette dernière est bien meilleur.

je ne vais pas détailler aujourd'hui une réponse à tout, mais juste sur ça maintenant :

honnêtement, (comme pour d'autres de tes remarques) tu te fourvoes et prouve un peu ton manque d'expéreince dans des environnements différents (et ce n'est pas du tout pour te diminuer, c'est normal)

Je ne vois pas où tu vois dans ce que j'ai dit une "absence de rapport quelité/coût" ou une "infinité de ressources"...

Bien au contraire..

En mettant beaucoup moins de ressources (financières et humaines) que avec une approche traditonnelle, tout le monde y gagne : ça coûte moins cher, et comme souvent le résultat suit au plus près ce qui est demandé et les évolutions, au final le "client" a le truc le plus adapté possible en le moins de temps et le moins d'argent possible..

Quant au "fournisseur", vu qu'il n'a mis qu'une petite équipe et relativement "peu" de temps, il lui reste (éventuellement si c'est une SSII) pleins de gens et plein de temps pour faire d'autres contrats, au lieu d'avoir immobilisé 50 personnes pendant 5 ans sur un seul truc..

Mais je sens d'après tes remarques que je parle dans le vide, car tu es trop ancré dans la mentalité existante (surtout comme mentionné plus haut en France). Ceci dit sans aucune connotation négative envers toi : tu n'as simplement pas vu assez de choses différentes (et eu à gérer dans ces contextes).. Quand tu auras été comme moi dans une dizaine de projets en V qui échouent pour quelques centaines de millions, à cause soit du nombre de personnes impliquées et de la rigidité du processus, soit de l'incompétence d'un seul élément, fût-il le DG, soit de la "courbure d'échine" du CP devant ses supérieurs, incapable d'aller défendre sa vision devant le CA, tu arriveras aux conclusions de Manifeste...

Deux exemples que j'ai déjà cité :

• la Météo Nationale canadienne pour qui j'ai développé un soft avait dépensé 28 millions de dollars, en mettant des informaticiens de tout le pays en structure "en V", pendant 10 ans... Nous avons, à 4, fait le soft équivalent pour 350 000 dollars en 7 ans. Finalement, après 14 ans d'opérations, le National n'a pas souhaité continuer et faire de petites modifs (pour environ 100 000 dollars)... Résultat : ils ont dépensé 77 millions jusqu'à maintenant, et ça continue ....
  
• Une (très grosse) SSII a créé une filiale pour faire un soft médical style DMP (Dossier Médical Personnalisé). 60 personnes pendant 14 ans en V... pour 82 millions.. Avec une équipe de 6, en 1 an 1/2, j'ai fait mieux (nettement, puisque les clients se précipitaient au lieu de faire la grève), pour 1.5 million...

Si t'appelles pas ça des gains, que ce soit en délai ou en coût, alors je sais pas, moi...

D'autres exemples : la boîte qui fait le soft des centraux 911 en Amérique du Nord dépense 35 millions pour faire son soft... Mais les standardistes trouvent que ça va pas... En 4 jours de retouchage ergonomique et de ré-architecturation du soft, à 4, soit un peu moins de 8000 dollars, ils ont pu remporter le marché de la Californie (état le plus peuplé).. Et j'en ai plein comme ça...

[Logan Mauzaize]

Réponse aussi rapide de ma part

J'assume complètement mon côté "débutant", ca ne fait que 3 ans que je suis sorti de l'école. Et même si j'ai connu quelques environnements bien différents ils sont loin de refléter l'ensemble du marché.
D'où mes nombreuses interrogations. Pour le moment j'arrive pas à me mettre à ta portée et c'est certains que 9999 posts ne remplaceront certainement pas les 10-15 années qui me manquent. Cependant j'ai l'espoir d'arriver un jour à comprendre.
Même s'il faudrait également que je me débarrasse des idées de fonctionnement de mon client actuel (et également celui d'une petite PME).

A titre d'exemple, l'année dernière le client nous a compressé pour faire une version d'un produit en moins 2 mois alors qu'on estimait plutôt le travail à 4-5 mois avec notre équipe. Seulement les deadlines sont les deadlines et quand tu as 10-15 projets qui doivent se synchroniser et que tu es "petit sous-traitant", tu dois supporter les contraintes tant bien que mal.
Avec beaucoup d'effort on a réussi à gagner 10% de délai mais ca ne tenait toujours pas.
Alors on a aligné une "armée" (on est passé de 3,5 à 8), est on a eu seulement une petite semaine de retard.

Certes cette expérience repose sur un client non agile, mais je me dis que des fois ce genre de contrainte doit arriver. Par exemple tout ce qui est législatif. Quand je dis qu'il y a bataille ce n'est pas forcément le client ou le prestataire qui le fait exprès juste pour "tirer la bourre" à l'autre.


Enfin quand tu compares, les coûts de revient, les coûts de vente, la taille des équipes et les délai. Comme ça, j'ai tout de même l'impression que les autres travaillent à 60-75% et toi à 125-150% ...
Seul une différence d'organisation me semble pas expliquer de tels écarts.

[souviron34]

Cependant j'ai l'espoir d'arriver un jour à comprendre.

Certainement

(même si tu passeras par quelques phases de désespoir.... C'est notre lot à tous...)

A titre d'exemple, l'année dernière le client nous a compressé pour faire une version d'un produit en moins 2 mois alors qu'on estimait plutôt le travail à 4-5 mois avec notre équipe. Seulement les deadlines sont les deadlines et quand tu as 10-15 projets qui doivent se synchroniser et que tu es "petit sous-traitant", tu dois supporter les contraintes tant bien que mal.
Avec beaucoup d'effort on a réussi à gagner 10% de délai mais ca ne tenait toujours pas.
Alors on a aligné une "armée" (on est passé de 3,5 à 8), est on a eu seulement une petite semaine de retard.

Certes cette expérience repose sur un client non agile, mais je me dis que des fois ce genre de contrainte doit arriver.

ça dépend...

Des fois il vaut mieux refuser un contrat que d'être dans la m.rde.. Disons que d'après ce que je comprend c'est le patron de cette boîte qui accepte tout et n'importe quoi... C'est ça le problème... Et il finira par couler.. Un jour où il aura accepté beaucoup trop gros..

"qui va piano va sano", ou "rien se sert de courir, il faut partir à point", ou "qui trop embrasse mal étreint"...

C'est un peu le contraire que je perçoit dans ta vision et celle de ta boîte...

La course à l''argent pour l'argent sans tenir compte des réalités fera comme la bulle immobilière ou des .com : ça éclatera, c'est écrit...

Faire beaucoup, mais dans ses capacités/limites, paie toujours plus sur le long terme.. Et le long terme, c'est ça qui fait la pérennité d'une boîte et d'un revenu / chiffre d'affaire..

Par exemple tout ce qui est législatif. Quand je dis qu'il y a bataille ce n'est pas forcément le client ou le prestataire qui le fait exprès juste pour "tirer la bourre" à l'autre.

Alors là, je ne sais pas vraiment... Je suppose que ça dépend dans quoi.. C'est sûr que si c'est politique, ou l'administration des technicrates à la française, il faut que ça soit fait pour avant-hier.. Mais c'est au patron/CP/Directeur marketing de dire non, ça ne peut pas se faire..

ça m'est arrivé au Canada, à la météo, pour l'an 2000 et le Y2k : le minsitre a demandé un truc, le chef du bureau a fait descendre l'ordre.. Or toutes les équipes étaient sur le passage et la vérif du bug de l'an 2000... Eh ben le chef de mon équipe a dit "non, pas tout de suite..Dans 2 mois"..

Sinon, en général en "législatif" (je ne sais pas ce que tu appelles comme ça) j'ai travaillé pour un système expert pour la Protection de la Jeunesse, eh bien on avait un an... Et comme entre le projet de loi, le vote, les AR assemblée/sénat, et le décret, il se passe du temps, il me semble que c'est plutôt le contraire..

C'et à mon avis plus sur des boîtes priivées que le délai est crucuial : un salon international, un concurrent dont on sait qu'il va sortir quelque chose, un appel d'offres, etc etc...

Comme ça, j'ai tout de même l'impression que les autres travaillent à 60-75% et toi à 125-150% ...
Seul une différence d'organisation me semble pas expliquer de tels écarts.

L'organisation explique 90%..

Les 10% restants sont effectivement parce qu'on travaille plus, sauf qu'on prend plus de repos

Si je travaille 4 semaines à double-temps, je récupère un mois (par exemple, à mon compte, pour la météo, pendant 7 ans j'ai bossé 6 à 8 mois par an max, tout en gagant très honnêtement ma vie, et en n'ayant facturé que 7 à 8 mois à 50% du tarif d'une grosse SSII. En tant que salarié, pour le truc médical, d'une part du coup j'avais horaires libres (ma PDG était tenue au courant de l'avancement et des difficultés, principalement "politiques" (Conseil d'Administration et Directeur Technique et DG)), et de plus j'avais le double des congés (plus une prime parce que ça marchait parfaitement bien))

[Luckyluke34]

De ce que j'ai compris le "Manifeste Agile" est simplement née de l'abstraction des méthodes des auteurs à savoir celles justement citées.

Tu es passé complètement à côté de l'origine...

C'est le contraire...

[...]

C'est au contraire à l'opposé de l'abstraction !!!! Il n'y a rien de plus terre à terre...

Nemek voulait parler de l'abstraction des méthodes déjà existantes au moment de l'écriture du manifeste, dans le sens recherche d'un plus petit commun dénominateur à ces méthodes.

En ce sens, il a raison. Sutherland et Schwaber sont venus avec Scrum, Beck avec XP, Cockburn avec Crystal... Si on regarde comment s'est déroulé le rassemblement, il s'agissait bel et bien de tirer une essence commune de ces méthodes et plus abstraite que les pratiques proposées par chacune d'entre elles.

En agilité (suivant le Manifeste) le chiffrage se fait en jours. (compte-tenu de l'équipe que tu as ou peut assembler..)

J'aimerais bien savoir où tu as vu ça Le manifeste ne parle pas de chiffrage ni même d'estimation (terme qui semble plus adéquat). Certaines équipes agiles estiment leurs tâches en jours, d'autres ne découpent pas en tâches et estiment uniquement en story points, d'autres en tailles de T-shirt... C'est assez varié.

[Logan Mauzaize]

(même si tu passeras par quelques phases de désespoir.... C'est notre lot à tous...)

Je suis plutôt optimiste alors je m'accroches à fond

ça dépend...

Des fois il vaut mieux refuser un contrat que d'être dans la m.rde.. Disons que d'après ce que je comprend c'est le patron de cette boîte qui accepte tout et n'importe quoi... C'est ça le problème... Et il finira par couler.. Un jour où il aura accepté beaucoup trop gros..

"qui va piano va sano", ou "rien se sert de courir, il faut partir à point", ou "qui trop embrasse mal étreint"...

C'est un peu le contraire que je perçoit dans ta vision et celle de ta boîte...

La course à l''argent pour l'argent sans tenir compte des réalités fera comme la bulle immobilière ou des .com : ça éclatera, c'est écrit...

Faire beaucoup, mais dans ses capacités/limites, paie toujours plus sur le long terme.. Et le long terme, c'est ça qui fait la pérennité d'une boîte et d'un revenu / chiffre d'affaire..

Quelques précisions s'imposent :

Premièrement, dans ma boîte on travaille plus pour le service que pour la rentabilité ... Même si je donne l'impression du contraire en occultant certaines parties qui vont dans ton sens. Ce qui m'intéresse c'est surtout ce qui va à contre-courant, histoire que quand je prends une décision je sois suffisamment armé

Deuxièmement, l'aspect contractuel est un peu particulier (ou peut-être pas d'ailleurs ...). On a un contrat "maître" de type "bundle de service". En gros, ça dit qu'on gère les supports niveau 2 et 3 de certaines applications.
Ensuite pour chaque version de chaque application, on reçoit un "cahier des charges" (liste de modifications, nouvelles versions des spécifications, autre) auquel on attribue un coût et un "planning" (dates clés : livraisons, fin prévue de recette, fin prévue de garantie, etc.).
Le principe du contrat "maître" vient un peu forcé la main ... Après sur la phase négociation, ça dépend pas mal de la "conscience" qu'ils ont du coût par rapport à leur budget :

• Les applications pour lesquels ils n'ont pas d'argent, ils nous demanderont en avance de phase une estimation de coût pour telles ou telles modifs
• Pour ceux où ils sont peu plus justes ou pour lesquelles ils pensent que c'est bon, ils essaient de faire baisser le prix.
• Si c'est vraiment trop juste, on discute avec eux suite à la réponse ce qu'ils veulent intégrer ou non et nous renvoient ensuite un nouveau "cahier des charges" qui correspond sur quoi on s'est mis d'accord.

Sinon je ne sais pas si nous avons déjà "refusé" de faire quelque chose. Pour le moment, ça s'est toujours bien passé. Sur mes projets, le client finit par comprendre qu'il peut pas tout avoir avec son budget.

Sinon, en général en "législatif" (je ne sais pas ce que tu appelles comme ça) j'ai travaillé pour un système expert pour la Protection de la Jeunesse, eh bien on avait un an... Et comme entre le projet de loi, le vote, les AR assemblée/sénat, et le décret, il se passe du temps, il me semble que c'est plutôt le contraire..

Quand je parle de "législatif", il s'agit des lois, elles arrivent parfois comme un cheveu sur la soupe. Pour peu que ca n'intéresse pas beaucoup de sénateur/député, la loi passe en deux-deux et applicable quasi-immédiatement sans trop se demander ce que cela peut impliquer sur la mise à jour des systèmes (papier, ou informatique).
Sans compter le délai que ça peut prendre chez les décideurs avant de lancer une commande de "logiciels" (analyse/étude incluse).

Bref, tout cela pour signaler, qu'un projet subit des "pressions externes" qu'il faut gérer du mieux qu'on peut.

L'organisation explique 90%..

Les 10% restants sont effectivement parce qu'on travaille plus, sauf qu'on prend plus de repos

Ca devait vraiment être le chaos en face pour avoir de tels écarts O.o
Tu me diras on a récupéré certains projets avec notre fameux "bundle", il faut voir la tronche. Un projet avec plus de 70% de lignes dupliquées, un autre avec une méthode de 2-3k lignes, encore un autre avec même pas 5% de compliance avec les règles dictées par le client, etc...
Et le client continue de leur donner des contrats ... Encore pire, pour un projet un concurrent a retardé la livraison pendant plusieurs mois pour au final dire qu'il ne pouvait pas le faire et qu'il ne livrerait jamais ....

Nemek voulait parler de l'abstraction des méthodes déjà existantes au moment de l'écriture du manifeste, dans le sens recherche d'un plus petit commun dénominateur à ces méthodes.

En ce sens, il a raison. Sutherland et Schwaber sont venus avec Scrum, Beck avec XP, Cockburn avec Crystal... Si on regarde comment s'est déroulé le rassemblement, il s'agissait bel et bien de tirer une essence commune de ces méthodes et plus abstraite que les pratiques proposées par chacune d'entre elles.

C'est exactement ça. Ils ont communalisé leurs pratiques pour en faire des valeurs et des principes.
Le pas est facile à franchir pour dire que ça ne vaut pas mieux que CMMi ... Sauf que le manifeste tient en 19 phrases.