Discussion :

[souviron34]

Cela dit, ne vous-êtes pas entrain de vous éloigner du sujet du post ?

Tu as tout à fait raison

En fait, ça a dérivé à partir de :

Comme dit dans le bouqin :[

La seule manière de respecter le planning, ou d'aller vite, est de garder en permanence le code aussi propre que possible.

Par contre, qu'est-ce que ça veut dire "La seule manière de respecter le planning" ???

Qu'est-ce qu'un planning ? Comment a-t-il été établi ? par qui ? qu'a-t-il pris ou pas pris en compte ? sur quelles personnes s'est-il basé ??

en haut de la page 3...



Désolé d'avoir pollué le thread...

[el_slapper]

Comment tu fais pour durer? Parce que là tu résumes dans ces propos la dérive complète de notre société. J'ai capitulé, je laisse faire, jusqu'à ce que ça explose.

"Si tu trouves que les autres devraient changer, alors commence par te changer toi-même". Je ne sais plus ou j'ai lu ça, peut-être dans une revue new age louche. Mais c'est ça qui me fait tenir. Si MOI je ne cherche pas à faire mieux que ma fiche de mission, alors qui le fera? Si MOI je me contente de chercher des excuses à chaque fois qu'un job me fait chier, comment s'etonner que tout s'effondre?

Alors, si parfois les éléments me sont favorables(l'exemple que j'ai cité ci-dessus ou j'avais eu carte blanche), le plus souvent, j'en prends plein la gueule. Mais j'ai la satisfaction d'avoir été aussi loin que possible.

Et, souvent(pas toujours, mais très souvent quand même), ça passe par un code un peu plus futé que la spécification. Ce qui nous ramène au débat.

[rimram31]

Je ne vois pas pourquoi.. En tous cas avec ma vision des choses, cela reste une évidence... Même en "approche" agile.

Parce que c'est donner un peu plus de "pouvoir" a l'équipe de développement et leur donner des arguments supplémentaires Ils ont tôt fait de t'expliquer que tu échoueras si tu ne respectes pas la "méthode" quand avant tu pouvais les fouetter en leur disant de se démerder Mais ce ressenti est lié a ma propre expérience.

Sinon, oui, on est complètement hors sujet ...

[souviron34]

Comment tu fais pour durer? Parce que là tu résumes dans ces propos la dérive complète de notre société. J'ai capitulé, je laisse faire, jusqu'à ce que ça explose.

+1 avec el_slapper

De plus, honnêtement ?? Je m'en tamponne de ce que pensent les autres..

• J'essaye autant que faire se peut de tenter d'éveiller les consciences quand je le peux (la raison de mes nombreuses interventions dans ce sens sur les forums de DVP où ce genre de débat arrivent)
  
  
• J'essaye tant que je peux de faire correctement mon travail, quitte à le qutter si ça ne va pas dans la direction que je souhaite * (je n'ai fais que démissioner des boîtes où j'étais (8 fois), certaines fois pour aller vers mieux directement, d'autres fois juste par désaccord.. Mais le fond, c'est que de toutes façons à la fin c'est forcément mieux, justement à cause de cet accord/désaccord)
  
  
• Je ne peux combattre le système, mais peux le dénoncer tant que je veux..
  
  
• Comme j'ai ma conscience pour moi, je me porte tout à fait bien *
  
  
• C'est aussi la raison pour laquelle je pense qu'un tel système ne peut perdurer... Cela finira par s'écrouler (et ça commence, avec la crise), et on reviendra vers du bon sens..
  
  
• En attendant c'est aussi une raison pour laquelle je ne crois pas (plus) aux "idéologies" et aux combats politiques : quel que soit le gouvernement et quelles que soient les opinions des gens que j'ai cotoyé depuis 30 ans, ils ont tous agi pareil, même ceux qui soi-disant avaient une "conscience de classe" et pensaient soi-disnt au "bien de l'Humanité". ça m'a laissé effectivement assez désabusé, mais néanmoins heureux de vivre car sans illusions de ce côté-là.
  
  
• J'ai par contre toujours l'illusion et la prétention de penser que, de temps en temps, je peux changer quelques choses.. et surtout satisfaire un client / un besoin avec quelque chose de bien fait qui dure et ne consomme que le minimum.. J'ai donc toujours une fierté (même si elle est peu partagée) et donc je vais très bien

* évidemment , ça passe par des hauts et des bas, des périodes de chômage, et, crûment, un revenu qu'un informaticien ou ingénieur d'aujourd'hui regarderait avec mépris... (en 20 ans je n'ai fait que diminuer de salaire (sauf en étant à mon compte))... Mais je m'en tamponne : ça me suffit à vivre (bien), je choisi ce sur quoi je travaille, et je le fais en plein accord avec ma conscience.. Je ne travaille donc que sur des choses qui me passionnent et avec lesquelles je suis en total accord... Donc tout va pour le mieux et ça fait tout à fait bien passer les périodes sans boulot.. PAr contre, ça suppose de ne pas avoir peur de la vie... Et moi ça me motive terriblement, d'être lâché dans le vide.. C'est super-dynamisant, parce qu'on fini par faire des choses qu'on n'aurait jamais pensé faire avant...

[el_slapper]

+1 avec el_slapper
(.../...)

Tu noteras que si j'ai parfois des messages à +10, celui-ci est toujours à 0 après le week-end. C'est significatif : tant que je tapes sur les autres, on me soutient, dès que je dis qu'il faut que moi je dois me secouer les puces, et SURTOUT que mettre la responsabilité sur les autres et me défausser de mes responsabilités, ça n'est pas très cohérent, bizarrement, les gens font semblant de n'avoir pas lu mon message.

[souviron34]

Tu noteras que si j'ai parfois des messages à +10, celui-ci est toujours à 0 après le week-end. C'est significatif : tant que je tapes sur les autres, on me soutient, dès que je dis qu'il faut que moi je dois me secouer les puces, et SURTOUT que mettre la responsabilité sur les autres et me défausser de mes responsabilités, ça n'est pas très cohérent, bizarrement, les gens font semblant de n'avoir pas lu mon message.

Je t'en ai mis un (habituellement je le fais pas lorsque c'est dans une discussion, mais bon..)

Sinon, un dernier point à ajouter sur ma liste plus haut :

J'évite comme la peste les offres d'emploi mentionnant "réalise un chiffre d'affaires de X millions d'euros et emploie plus de X milliers de personnes dans le monde".

[el_slapper]

Je t'en ai mis un (habituellement je le fais pas lorsque c'est dans une discussion, mais bon..)

Tiens, je me plains, et je monte à +2.... Bon, c'est pas très important, je m'en sers avant tout comme d'un feed-back : si j'ai plein de rouge, alors je dois me poser des questions(et si j'ai trop de vert, est-ce que ma manière de penser n'est pas trop conformiste?)

Sinon, un dernier point à ajouter sur ma liste plus haut :

J'évite comme la peste les offres d'emploi mentionnant "réalise un chiffre d'affaires de X millions d'euros et emploie plus de X milliers de personnes dans le monde".

Ce qui fait peur n'étant pas(dis moi si je te suis bien), la taille du groupe en question, mais le fait qu'il n'y aie pas de meilleur argument pour attirer le chaland...

[souviron34]

Ce qui fait peur n'étant pas(dis moi si je te suis bien), la taille du groupe en question, mais le fait qu'il n'y aie pas de meilleur argument pour attirer le chaland...

Les 2..

Plus un groupe est gros, plus tu es un pion, et plus la structure humaine /de projets/ de docs/ de procédures / de méthodologies / de leurs applications / est rigide...

Donc moins tu as de chances de te trouver dans un milieu où même une approche agile (au vrai sens) est faisable, et plus les rôles sont fixés par des statuts et des grades et des équipes différentes... (avec le plus souvent de plus en plus de chances d'avoir des rivalités entre équipes)

Ce qui n'est pas épanouissant, c'est le moins qu'on puisse dire..

Donc oui, la taille du groupe me fait fuir (mais je sais que pour des jeunes c'est souvent le contraire)..

Quant aux arguments, si ils les utilisent c'est bien ça touche un certain nombre... toujours la sacro-sainte "sécurité"....


* : une expérience de 2 ans dans une boîte de 300 000 salariés (Thomson-CSF) m'a suffit.. Et j'ai refusé des postes de fonctionnaire exactement pour cette raison : rivalités entre services..

[rimram31]

...Plus un groupe est gros, plus tu es un pion, et plus la structure humaine /de projets/ de docs/ de procédures / de méthodologies / de leurs applications / est rigide...

Vaste question qui a ses bémols, tu peux aussi te retrouver au sein d'une petite structure efficace dans une grosse boite! Tu n'es pas beaucoup plus a l'abri des rivalités et décisions "stratégiques" dans les petites boites qui finissent toujours un jour par avoir l'ambition de devenir grande (et tu es d'ailleurs confronté a un vrai souci, les profils et énergies des équipes très efficaces en mode "start up" se retrouvent frustrés en mode "corporate").

J'ai vécu les deux et aussi une situation hybride (petit qui devient grand ) pour aujourd'hui n'être attiré que par les démarrages... mais c'est aussi une question de personnalité. L'avantage des petites structures c'est que tu peux lier plus facilement ton "travail" aux résultats client/business et de fait, tu n'as pas a entrer dans milles polémiques pour justifier de tes choix car le "business" parle pour toi, mais, d'expérience, j'ai croisé très peu de "développeurs" souhaitant ce mode de fonctionnement, c'est même plutôt tout le contraire.

(euh ... on est toujours totalement hors sujet là si je ne m'abuse )

[infofree]

et si on parlait CODE ?

[chaplin]

Tu noteras que si j'ai parfois des messages à +10, celui-ci est toujours à 0 après le week-end. C'est significatif : tant que je tapes sur les autres, on me soutient, dès que je dis qu'il faut que moi je dois me secouer les puces, et SURTOUT que mettre la responsabilité sur les autres et me défausser de mes responsabilités, ça n'est pas très cohérent, bizarrement, les gens font semblant de n'avoir pas lu mon message.

J'ai lu ton message, j'y ai répondu et puis j'ai supprimé le message, car on ne peut faire de généralité sans connaître le contexte.
Il y aura toujours du code source, seulement quand il y a des délais, que les délais sont sous-estimés et que les gens ont peur lorsqu'on s'approche des délais, personne ne se mouille, tout le monde tire la nappe de son côté. Travailler dans un contexte où il faut toujours préparer des excuses parce que le projet est complexe et que les chances de réussites sont maigres, c'est pénible, il y a des champions dans ce domaine. Ensuite, faire/maintenair du code source que personne ne veut faire parce que c'est la partie la plus facile mais curieusement ça fait 1 ans, 2 ans voir + 10 ans que personne n'a touché au code source alors que c'est le code le plus facile à faire, les excuses deviennent du gros pipo.

PS: avoir un don, c'est bien, mais quand ça rapporte pas, ça sert à rien.

[Logan Mauzaize]

Je vois que finalement mes convictions et exposés, plus la pratique, t'ont convaincu

Nullement, cela a toujours été Il est pas bien compliqué de comprendre qu'avec un minimum de politesse un demandeur obtient bien plus qu'en braillant. De toutes façons dans une logique purement commerciale, si tu demandes un produit c'est que tu en as besoin et que tu en veux pour ton argent. Si tu commandes une armoire chez un ébéniste, plus tu seras précis dans ta demande quitte à venir le voir tous les jours, plus cela correspondra à l'image que tu t'en fais.

Tu me parles d'approche, je te parle de méthode

Quelle méthode ? SCRUM ? XP ? UP ?

A l'époque, on appelait ça une approche par prototype et/ou incrémentale et je n'avais pas besoin d'un arsenal de principes pour la faire fonctionner :-) simplement planifier de nombreuses réunions d'avancement et prévoir des livrables intermédiaires.

Avoir une approche par prototype et/ou incrémentale, ne signifie pas que tu ne traverses pas un long tunnel. Je travaille en RUP, mais les itérations sont "gigantissime" (3, 6 ou 12 mois).

Mais j'ai connu l'application de la "méthode" qui a déjà comme défaut d'ajouter des intermédiaires et de cloisonner (au contraire de ce que tu me décris)

Si tu cloisonnes tu perds l'agilité ... Entre dire et faire il y a une marge, mais dans ce cas tu peux cracher sur tout. Et surtout les policitiens.

une dérive que j'ai vécu c'est que le résultat était ajusté a l'effort et non l'inverse

L'éternel problème du décideur/chef/responsable. Il se pleint quand ce n'est pas assez mais ne veut pas reconnaître quand c'est trop.

j'ajouterai le résultat jugé possible par l'équipe et non celui demandé. J'ai donc connu exactement l'inverse de ce que tu décris, les pleins pouvoirs de l'équipe de dev au détriment des demandes client.

La faute à la méthode ou au client et aux dev ?

Tout ça c'est bien sympa mais quand "le client" te demande une date de correction ou de livraison parce que lui il a du business lié a ton produit, quand il doit anticiper un minimum l'allocation de ressources et de budget pour des tests et des campagnes de communication, tu fais comment? Bien entendu que cela dépend des contextes et des gens en présence, mais en tout cas de mon expérience, ça peut paraitre surprenant, j'ai trouvé que cela éloignait les équipes de dev du client et ça arrangeait bien l'équipe qui pouvait se cacher derrière "la méthode".

L'agilité ne convient pas à tout le monde. Et devrait selon moi s'étendre au dela de la réalisation, mais aussi dans les release et autre. Google l'a d'ailleurs bien compris.
Comme je l'ai expliqué, il peut avoir une date. Il suffit que la somme de travail et l'allocation possible de ces charges correspondent à une date qui lui conviennent. Agile ou pas, ca ne change rien. Seulement l'avantage c'est qu'il peut décider que le prochain "run" sera de finaliser le produit en y incluant ce qu'il pense nécessaire. Et de livrer le résultat de ce "run".

Ensuite, je suis au regret de te contredire, car, que ce soit la qualité des enseignants (ce qui se voit dans les arguments avancés ici par certains sur certains threads "généraux" touchant à l'informatique), ou la qualité des "enseignés", de base en termes de clarté de la pensée, de l'analyse, et de la mise en contexte (par exemple par rapport aux méthodes plus traditionnelles (affublées de "has been" ou "dinousauresques" (voir les commentaires sur les différents paradigmes et que l'OO est le Dieu et le procédural une horreur)), et de manière plus générale en termes de pensée "hors mode" ou "hors outils/framewotrk/IDE..." 'est considérablement appauvrie...

J'ai l'optimisme de croire que les "mauvaises graines" sont sur-représentées ici. Des enseignements que j'ai recu ou de ceux que je cotoie, il y a très peu d'apprentissage qui sont spécifiques à une mode, un outil, un framework, etc. Bien au contraire.
Après fatalement, vu le temps et la "pénibilité" gagnée via ces modes, outils, framework, c'est toujours bien de les maîtriser. Surtout qu'on peut pas tout savoir alors autant avoir un savoir utile (et rentable ?).

Et l'explication est assez simple : l'écrémage n'étant que peu fait, on se retrouve avec beaucoup de médiocres pour la même quantité de bons..

Ecrémage sur quel critère ? Quand j'étais petit les instits disaient à mes parents que j'étais un idiot fini et qu'on ferait rien de moi. Je trouve que vingt ans plus tard je m'en sors plutôt bien ... Et je me dis que je dois être loin d'être une exception alors pourquoi on laisserait moins de chance à mon voisin ?

Dans une grande SSII, le CP ou architecte est sur une mission donnée pour un temps donné.. Au bout du temps, si le boulot est pas fini et qu'il y a une autre mission, il est envoyé sur l'autre mission...
Vécu personnellement plusieurs fois, y compris pour le CP ou le Directeur Technique ou du Projet... y compris sur de très très gros projets..

SSII ou pas, tu peux pas empêcher quelqu'un de partir. Et de mon vécu, les commerciaux ne veulent pas que les gens bougent.

Comme je l'ai déjà dénoncé ailleurs, ce sont des "buzz-word" où les marketeux s'engouffrent, décrochent des contrats sur l'argument du siècle "c'est ce qui se fait de plus en pointe", et comme les grosses SSII et les groses boites n'aiment ni le flou, ni le fait de se reposer sur quelques personnalités, on a fait des belles théories et "méthodologies"...

Au delà du "buzz-word", qui n'est qu'un "buzz-word" lui-même, tout ce qui est connu pour avoir du succès fait vendre. T'inquietes pas qu'une société/école qui aurait vu passer Fowler&Co dans ces locaux le vendrait à ces clients. C'est mieux que de dire "souviron34" est passé par là

Concernant les méthodologies, elles ne sont pas si vides que ça. Sinon cela reviendrait à cracher sur les auteurs du manifeste agile. Comme je l'ai déjà indiqué avoir une méthode (ou disons un "buzz-word"), ca permet aux gens de se raccrocher à quelque chose. Désormais quand on dit "backlog", "daily meeting", les gens savent de quoi on parle. Pas la peine d'étaler dix pages de définition. Quand tu rapportes ça à un ensemble de pratiques, quand tu dis "Scrum" les gens savent de quoi on parle.
Cependant si tu regardes dans la vie de tous les jours, les gens n'appliqueront pas à la lettre. Ils auront des choses qui fonctionnent et d'autres qui ne fonctionnent pas. Et quand les choses vont mal, ils auront des idées pour redresser la barre.

Le cas est "un tout petit peu différent" pour les très grosses boîtes avec un gros SI interne... Mais peu, d'autant plus que ces très grosses boîtes sont en général des banques ou des assurances, pour lesquelles le budget info est un gros sac indiscriminé - et permanent d'une année sur l'autre.. Et donc le coût de tel ou tel projet est non seulement délayé dans le temps, mais dilué par projet sans vraiment de notion d'efficacité (un de mes beaux-frères au ex-GAN maintenant Groupama depuis 25 ans est .... totalement dégoûté.. Et parfaitement sur la même ligne d'analyse que moi là-dessus)

On a vraiment pas les mêmes références. De ce que j'ai vu l'informatique est plutôt vu comme un gouffre financier. Et les prix sont tirés un max vers le bas. Le client n'hésite pas à changer de prestataire pour gagner 10% sans tenir compte de la qualité, du service ou du respect des délais.

Dire que le premier négociateur auquel j'avais eu affaire sur ce dév m'a refusé un paiement de deux jours de prétendu dépassement, parce que j'avais dit, suite à la première écoute des besoins et comme toujours sans la moindre analyse, "Oh je ne sais pas mais disons qu'il y en aura pour une vingtaine de jours pour faire tout ce que tu demandes dans un premier temps - sans garantie" et que j'en avais mis 22, évidemment pour en faire plus que prévu !

Mais quelle est donc la valeur de mon travail dans ces circonstances ? Quand je travaille à merveille pour presque rien, on me chipote mon dû et quand je fais acte de présence dans une gabegie sans nom, ma déontologie est bousculée par la gêne d'être surpayé !

D'un point de vue gestionnaire ca se comprend. D'un côté une charge fixe et anticipiée, de l'autre un charge variable non anticipée. De toutes façons en cas de forfait c'est la règle ! D'ailleurs il ne faut pas croire que les SSII font un max d'argent sur le forfait. Ce serait même le contraire. En général, c'est externalisé donc les couts d'infrastructure sont à la charge de la SSII. Le temps d'analyse est considéré au même titre que de l'avant-vente, à pure perte. Ensuite le temps estimé doit être "juste". Pas trop cher pour que le client accepte, pas trop court pour qu'on reste dans nos frais ...

Moi j'ai vu (même sur ma tête) un facteur 3 entre le salaire horare que je gagnais et le prix demandé à l'heure... C'est pour ça que je disais entre 1 et 3 de marge.. Et c'est la moyenne de ce que j'ai vu.

Ca a beaucoup changé, et de toutes façons, il faut regarder tous les frais annexes. Je touche 43k brut(à 2PI près). Je dois coûter environ 65k à l'année, rien qu'en salaire et charges étatiques. Ajoute le salaire du commercial, des équipes administratives. Je dois être facturé un peu plus de 400 roros par jour de présence, soit 90k par an. Tu prends 80% de ce total pour compter les intercontrats, et tu arrives à une marge finalement assez faible.

Avec un salaire à 43K, je pense que t'es loin du compte avec les 65k. Car à 36K brut, 65K c'est déjà le coût de mon salaire pour ma boîte. Tu peux le voir sur ton bulletin de salaire, là où est indiqué le "net imposable", tu as également le cout du salaire (salaire brut + avantages + charges patronales) pour la boîte. Et tu omets les couts d'infrastruture (matériel, loyers, mobiliers), les pertes, l'avant-vente, etc.

D'une, je ne sais pas ce que tu comptes, mais entre ton salaire et le coût employeur, ajoute déjà entre 40 et 50% au brut salarié, de deux, tu ne travailles jamais qu'un peu plus de 200j par an (journées "facturées"), enfin, compte le "brut total", avantages éventuels compris: 13ème mois, frais, primes...

Normalement on travaille 218j/an. Cependant moins de 180 jours (25 CP, ~10 RTT, 3 pour formation/maladie/visite médicale/etc) seront facturés. Ce qui fait déjà près de 20% de perte.



En dehors du TJM, pour ceux qui crachent sur le "prix" des SSII VS un développement interne, sans critiquer le travail que chacun des intervenants ici ont fournis, j'ai vu un paquet de projet en AT/interne qui n'atteigne même pas les 10% d'exigence en matière de qualité par rapport à ce qui est demandé à une SSII. Alors oui on peut faire moins cher mais on n'a pas la même chose à l'arrivée ! C'est comme comparer le prix d'une Dacia et d'une Mercedes.

ne vous-êtes pas entrain de vous éloigner du sujet du post ?
En aucun cas je veux faire mon rabat-joie, si vous estimez que c'est la continuité du sujet, alors aucun problème pour moi, continuons dans ce sens...

Le problème c'est que je crois que l'on est tous d'accord sur le point que "coder" ne disparaitra jamais. Eventuellement la forme évoluera. Et quand bien même il y aura toujours les "hard codeurs" pour créer les écosystèmes des nouvelles formes de codage, sauf à revoir le principe même de l'ordinateur.
Cependant l'évolution la plus probable de l'ordinateur est celui quantique. Qui de toutes facons ne va pas révolutionner le "principe du codage". Et ne s'appliquera pas qu'à une niche d'application.

Tu as tout à fait raison
Désolé d'avoir pollué le thread...

Espece de délateur :p Idem, je suis désolé.


Néanmoins, cette dérive partait du même chapitre que le message originel. Est-on donc si éloigné du sujet ?

[chaplin]

L'éternel problème du décideur/chef/responsable. Il se pleint quand ce n'est pas assez mais ne veut pas reconnaître quand c'est trop

+1000
Du vécu, un responsable avait reporté un projet d'années en années, du coup nous étions la dernière entité nationnale à ne pas être dans les clous. Ce dernier me refile le bébé, 3 mois pour réussir ou la porte!! Quand je discute avec le responsable du partenaire (externe) sur le projet en question, il pète un cable en me demandant si je me foutais de sa gueule, car il n'avait eu aucun feedback sur les directives qu'il avait données, alors que je découvrais le projet 10 jours avant.

Ensuite, venir derrière un responsable qui a foutu la merde, ça prend du temps pour la nettoyer, et quand il est protégé par un N+1, ça devient mafieux. Quand le mafieux tombe, ça fait du bien mais ça ne répare pas le préjudice moral.

J'ai terminé le projet dans les temps à la grande stupeur de la direction!

Je traduis: l'entreprise est en retard, on me donne le projet pour que sciemment "je" le plante, même si l'entreprise est encore plus en infraction, l'immoralité totale.

[rimram31]

Quelle méthode ? SCRUM ? XP ? UP ?
... La faute à la méthode ou au client et aux dev ? ...

Scrum et l'approche a bien ajouté des intermédiaires dans mes expériences, au final avec ce fameux backlog qui ne cesse de se remplir sans jamais se dépiler et finit par donner le sentiment que plus grand monde ne contrôle grand chose

La méthode n'est pas la seule en cause, tout dépend du contexte et des gens en présence. Celui que je décris vient du monde du service ou il y a besoin d'arbitrage entre ce que souhaitent le mkt/dev et les demandes client, je trouve déjà que "le développement" a trop tendance a se regarder le nombril, en "mode agile", c'est lui donner encore plus d'autonomie/de pouvoir. Je parle effectivement plus de lutte d'influence que de méthodologie sauf qu'une méthode "agile" donne plus d'arguments a l'une des parties ...

L'éternel problème du décideur/chef/responsable. Il se pleint quand ce n'est pas assez mais ne veut pas reconnaître quand c'est trop.

Je ne te suis pas, mon commentaire est lié a ma remarque au dessus. Sans préjuger de la bonne solution (qui dépend de tout projet), quand une approche "classique" se pose régulièrement la question du "combien" concernant l'effort a fournir, l'approche agile répondra plutôt "quand". J'ai connu des "heures sup" (et/ou des bonus) en période chargée mode classique "projet" quand j'ai vu des équipes "agiles" avoir plutôt tendance a dérouler pépères ...

Normalement on travaille 218j/an. Cependant moins de 180 jours...

Le décompte des CP, RTT, jours fériés ... est déjà inclut dans les 218 jours ce qui doit être a peu près le nombre jours "facturables" annuels. Il ne faut pas non plus être aveugle sur le fait que les SSII se gavent, désolé, sur le dos des développeurs, surtout les jeunes, qu'ils placent en régie. C'est en gros une marge brute a 50%, au final aisément du 20/25% de marge nette (salaires conséquents des commerciaux déduits ...) pour le moins c'est une activité rentable surtout qu'elles sont loin d'être irréprochables quand tu te retrouves hors contrat.

[Logan Mauzaize]

Scrum et l'approche a bien ajouté des intermédiaires dans mes expériences, au final avec ce fameux backlog qui ne cesse de se remplir sans jamais se dépiler et finit par donner le sentiment que plus grand monde ne contrôle grand chose

C'est pas mieux dans mon contexte ... Je compte même plus les évolutions fonctionnelles qui arrivent en pleine recette !

La méthode n'est pas la seule en cause, tout dépend du contexte et des gens en présence. Celui que je décris vient du monde du service ou il y a besoin d'arbitrage entre ce que souhaitent le mkt/dev et les demandes client, je trouve déjà que "le développement" a trop tendance a se regarder le nombril, en "mode agile", c'est lui donner encore plus d'autonomie/de pouvoir. Je parle effectivement plus de lutte d'influence que de méthodologie sauf qu'une méthode "agile" donne plus d'arguments a l'une des parties ...

Théoriquement, les décisions appartiennent au "Product Owner". Quelque soit la méthode, seul le nom changera.

Je ne te suis pas, mon commentaire est lié a ma remarque au dessus. Sans préjuger de la bonne solution (qui dépend de tout projet), quand une approche "classique" se pose régulièrement la question du "combien" concernant l'effort a fournir, l'approche agile répondra plutôt "quand". J'ai connu des "heures sup" (et/ou des bonus) en période chargée mode classique "projet" quand j'ai vu des équipes "agiles" avoir plutôt tendance a dérouler pépères ...

Toujours pas d'accord. Les principes de plannification en "agile" ou en "classique" restent les mêmes. Identifier les tâches, "chiffrer" les tâches, organiser les tâches (priorité, dépendance, parréllisation), affectation, ajustement en fonction des taux d'occupation (présence, autres tâches ou projets, etc.). Il en découle une date de fin.
La différence avec "agile", c'est le nombre de tâches et l'implication du "Product Owner" dans le choix et l'organisation des tâches.

Concernant ma remarque sur l'effort, il est difficile d'estimer sur une personne est en moyenne bien impliquée dans son travail. Il y a certaines personnes qui seront compétentes qui n'en branleront pas une mais te torcherons les tâches en trois fois rien de temps, contre une personne qui va s'arracher les cheveux pendant des jours et ne même pas arrivé à un résultat convenable. Que ce soit en "agile" ou pas d'ailleurs.

Globalement, j'ai tendance à me baser sur le temps estimé. Si la personne met moins de temps c'est tant mieux, c'est elle met le temps indiqué, pas grave c'est ce qui était prévu. Par contre si elle met plus de temps, je veux savoir pourquoi.

Au final, il n'y a peu de reconnaissance pour les heures supplémentaires (un petit "merci" avec de la chance) et aucune si tu es en avance.

Le décompte des CP, RTT, jours fériés ... est déjà inclut dans les 218 jours ce qui doit être a peu près le nombre jours "facturables" annuels.

Effectivement je me suis peut-être planté dans le calcul, mais le principe reste vrai. 218 jours facturables contre au moins 40 de plus qui sont payés.

Il ne faut pas non plus être aveugle sur le fait que les SSII se gavent, désolé, sur le dos des développeurs, surtout les jeunes, qu'ils placent en régie. C'est en gros une marge brute a 50%, au final aisément du 20/25% de marge nette (salaires conséquents des commerciaux déduits ...) pour le moins c'est une activité rentable surtout qu'elles sont loin d'être irréprochables quand tu te retrouves hors contrat.

Le problème c'est que l'on peut pas trop connaître la marge nette dans la mesure où elle est réduite par le salaire de la direction qui très dépendant du CA. On est d'accord qu'ils doivent bien se gaver.

[rimram31]

Théoriquement, les décisions appartiennent au "Product Owner"...

Tu me tends un peu la perche c'est bien le fait que "le produit" devienne comme "propriété" du développement et non plus du "client" qui est a l'origine des dérives que je décris.

Pas de désaccord entre nous, je ne parle que d'un vécu où j'ai vu le développement s'éloigner plus encore du "client" ce qui est pour le moins contradictoire avec ce que porte en théorie ces approches.

...On est d'accord qu'ils doivent bien se gaver.

Ce n'est pas tant cela qui est, de mon point de vue, "choquant", toute société a des activités très rentables, d'autres moins, et même déficitaires, j'ai vécu mon début de carrière dans ce contexte où "mes marges" permettaient de financer d'autres activités, elles, très risquées et ça ne m'a jamais posé de problèmes. Car le vrai souci des SSSI tient a leur stratégie globale, si cette stratégie consiste en une approche disons "industrielle", prises de risques forfaits, produits, véritable gestion de carrière du personnel ... je dis bravo (et d'ailleurs ces boites là ne margent pas tant que ça ...) mais il est difficile de tenir la route quand il est très "facile" de gagner beaucoup dans une activité de régie.

[chaplin]

Pour avoir vécu une expérience semblable, quand on tombe sur de l'existant, on le prend comme repère, à partir de là, la première grosse itération est un prototype, mais les sous-itérations si j'ose dire précisent le prototype. Enfin vient la deuxième grosse itération qui elle est juste.

Quand le client ne comprend pas son projet et qu'il se contente de faire-faire en disant, "Si t'as pas compris, tu poses des questions", en clair cela veut dire, "nous on sait pas comment ça marche, on compte sur vous, mais s'il y une merde, c'est que vous n'avez pas compris ce qu'il fallait en théorie comprendre", il y a de quoi se mettre dans une colère noire.

Car le vrai souci des SSSI tient a leur stratégie globale, si cette stratégie consiste en une approche disons "industrielle", prises de risques forfaits, produits, véritable gestion de carrière du personnel ... je dis bravo (et d'ailleurs ces boites là ne margent pas tant que ça ...) mais il est difficile de tenir la route quand il est très "facile" de gagner beaucoup dans une activité de régie.

L'appas du gain! On encaisse le pognon et quand ça merde on paye pas les prestataires pour garder la marge.

Quand le presta signale des anomalies, on fait la sourde oreille jusqu'au moment où ça pête, et là ce qui est important, c'est de trouver des coupables et on oublie totalement les conflits chez le client, comme un cas de harcèlement moral grâve avéré, cette fois-ci qui se situe au niveau hierarchique. Les managers sont parfaits, c'est connu, et les plus irréprochables coutent des fortunes à la sécurité sociale.

[codefingers]

Il y'aura du code, tant qu'il y'aura de l'informatique, tant qu'il y'aura des télévisions et des téléphones, tant qu'il y'aura des avions, des trains, des voitures ... du transport, tant qu'il y'aura des banques, des magasins, des routes, des immeubles, des hôpitaux, tant qu'il y'aura de la musique, du sport, tant qu'il y'aura la guerre ..... tant qu'il y'aura des êtres humains, tant qu'il y'aura LA VIE !

Alors OUI, Il y'aura toujours du code.