Tu as tout à fait raison :)
En fait, ça a dérivé à partir de :
en haut de la page 3...
:aie:
Désolé d'avoir pollué le thread...:oops:
Version imprimable
"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.
Parce que c'est donner un peu plus de "pouvoir" a l'équipe de développement et leur donner des arguments supplémentaires :lol: 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 :lol: Mais ce ressenti est lié a ma propre expérience.
Sinon, oui, on est complètement hors sujet ...
+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...
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". ;)
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?)
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... :roll: 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..
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 :mouarf:)
et si on parlait CODE ? :D
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.
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.
Quelle méthode ? SCRUM ? XP ? UP ?
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).
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.
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. ;)
La faute à la méthode ou au client et aux dev ?
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".
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 ?).
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 ?
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.
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.
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.
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 ...
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.
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.
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.
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 ?
+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.
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 :D
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 :mrgreen: sauf qu'une méthode "agile" donne plus d'arguments a l'une des parties ...
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 ...
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.
C'est pas mieux dans mon contexte ... Je compte même plus les évolutions fonctionnelles qui arrivent en pleine recette !
Théoriquement, les décisions appartiennent au "Product Owner". Quelque soit la méthode, seul le nom changera.
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.
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.
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.
Tu me tends un peu la perche :D 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.
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.
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.
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.
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.