Scrum Master. J'ai jamais compris l'utilité de ce métier. Il réserve la salle, prépare les docs, le café et les petits gâteaux. Et il envoi des invitations par emails.
En fait, c'est un assistant avec un gros salaire quoi
Version imprimable
Ne serait-ce là pas un peu un discours réducteur et peu corporate ?
Sous réserve d'avoir bien compris, un scrum master réserve une salle sur les 4 mois que sont sensés durer les tests d'intégration du projet ( qui servent à implémenter les specs que personne ne voulait voir ), allume skype, lance un conf call avec une pieuvre et assiste au déroulement des opérations en mettant des cellules excel en vert, jaune ou rouge :aie:
Le vendredi soir, il t'a gentillement mis à un rappel outlook afin de que tu ailles checker dans une interface que tu as bien fait tes heures ( ce que tu fais en réalité tous les jours afin qu'il puisse montrer une belle courbe "burndown chart" lisse un peu pipotée car les projets en retards sont incorporés dans tous ceux planifiés faisant des retards de deux années sur certains tickets .. ), il va s'amuser également à déplacer tous les jours les priorités de tes 72 tickets Jira, qui à mettre parfois des pièces jointes illisibles et te dire un jour au développeur que son board est bordélique .. Il est également chargé de te placer 6 heures pour réaliser un ticket qui va pendre 3 semaines en réalité ..
Tous les vendredis après-midi, toutes les deux semaines, il va bloquer pendant 2 heures 15 personnes afin d'ajouter des post-its sur son dessin d'un bateau et d'une île paradisiaque, 2 heures de pictionnary joyeux pour dire que tous les projets sont en retard ..
Tes collègues des autres département, en salle de réunion, se demandent à quoi il sert et tu dois justifier tant bien que mal que c'est finalement ton responsable le plus direct ..
C'est également la personne qui reporte à ton N+2 (son N+1 ) si ton nombre de lignes commitées matchent les expectations statistiques as well, du coup si un de te collègues squash la branch et la commite sur son nom, tu passes rapidement pour un branquignole, et lui pour un génie ( true story )
Le dernier qui a fait ça chez nous a embarqué tous les développements en cours. Y compris ceux qui n'étaient pas pour tout de suite, qui ne devaient pas partir dans la prochaine version. 4 heures de boulot(pas pour moi, pfiouh) à détricoter tout le reste. Je crois qu'il ne refera pas le coup non plus, il avait 2 grands chefs sur le dos.
Beaucoup d'entreprises disent appliquer Scrum. Mais, en réalité...
Dans le vrai Scrum, c'est le Product Owner qui est responsable de la priorité des tâches du backlog.
Dans le vrai Scrum, c'est l'équipe de développement qui est responsable de l'estimation des délais.
Outre le fait que cette métrique est stupide (ce qui est un autre sujet), dans le vrai Scrum, la responsabilité du résultat appartient à l'équipe de développement comme un tout.
Extraits du guide Scrum, qui contient la définition officielle du Scrum :
Citation:
The Product Owner is the sole person responsible for managing the Product Backlog. [...] The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
Citation:
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Citation:
The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
Auriez-vous, vous aussi un responsable qui dit que les développeurs de l'équipe manquent de compétence, que la dette technique est le problème majeur de l'entreprise ?
Non ^^
Il peut arriver qu'un développeur n'ait pas les compétences adéquates pour un projet, ou qu'il soit un peu en dessous de ce qu'on attend de lui. Il faut alors l'accompagner le faire monter en compétences.
Si c'est vraiment une bille, le problème vient du recrutement (il faut recruter des gens compétents, ou des gens capables de monter en compétences). Et si tous les membres de l'équipe sont des billes, c'est au responsable de se remettre en question :mrgreen:
La dette technique n'est que le résultat d'une mauvaise gestion de projet, donc c'est aussi la responsabilité du manager de savoir dégager du temps ou du budget pour maintenant la qualimétrie applicative. Par exemple dans mon projet, tout chiffrage implique la réalisation des TUs et le fait de maintenir la qualimétrie Sonar. De toute façon, si on a une seule anomalie Sonar supérieure ou égale à critique, et un coverage sur le nouveau code inférieur à 80%, on livre pas :mrgreen: Ce genre de "contraintes", c'est au responsable de les mettre en place (que ça soit un responsable managériale ou technique).
Je pense que ton responsable justifie sa propre incompétence sur son équipe. Dommage, il n'a rien compris à son rôle.
Franchement, je ne sais pas dans quelle entreprise tu travailles, mais toutes celles que j'ai croisé étaient bien loin de se soucier de mettre à niveau les compétences des gens.
Ça fait 14 ans que je ne suis pas parti en formation, et c'est pas faute d'avoir demandé. J'ai dû me maintenir à niveau sur mon tps perso et avec mes propres deniers.
Comme m'a dit un de mes managers : "Ça fait parti du métier de développeur de s'auto-former et de faire de la veille technologique. On a pas à payer des formations pour ça."
Heureusement que je suis passionné par ce que je fais, sinon je ne sais pas si je pourrais encore pratiquer mon métier aujourd'hui.
Ce qui n'est pas vraiment faux, quelqu'un qui est blasé et n'a pas envie de progresser, tu peux l'envoyer en formation, ça n'aura servir à rien. J'essaye en permanence d'apprendre aux personnes autours de moi à progresser avec des trucs et astuces qui leur feraient gagner des dizaines d'heures sur le mois, il doit y avoir 1-2 personnes sur 10 que ça intéresse, les autres sont plus à te regarder blasé en te faisant bien comprendre que tu les em**** ;)
La résistance au changement est une triste réalité de la nature humaine, presque personne n'aime sortir de sa zone de confort et de son train-train quotidien. Donc les formations sont à réserver aux personnes motivés , qui en font la demande, sinon c'est de l'argent perdu.
C'est aussi le rôle du "team leader" / Scrum master / Manager de repérer les appétences de ses collaborateurs et de répondre à leurs attentes. Quelqu'un qui s'en fou des tickets sur Jira et que ça le fait **** de les remplir, tu peux mettre le meilleur process du monde, ça marchera jamais ;)
Remarque, je n'ai pas attendu d'avoir de formations pour me mettre à docker, kubernetes, selenium, behat, symfony, magento, drupal, tout seul .. Sinon je ferais encore du php4 en flat comme il y a 15 ans ..
Du coup je peux avoir des approches qui divergent du mainstream, c'est à double tranchant, tout dépend des responsables derrière, c'est généralement apprécié, mais l'inverse peut s'avérer très électrique ..
Je suis pourtant dans une (très) grosse ESN (en centre de services) :aie: Après quand je parle de faire monter en compétences, je ne parle pas spécialement de formation pure (j'en ai eu une de 3 jours en 2 ans), mais plutôt l'équipe de dev qui va arranger les tickets pour faire monter en compétences la nouvelle personne.
Le but est de mettre la personne sur des tâches de plus en plus complexes au fil du temps, d'apporter du support et donc au final de faire une montée en compétences. La mise en place de relecture de code et de pair programming aide bien à ce niveau là. Le combo des processus et de cette montée en compétences permet de ne laiser personne, que ça soit un stagiaire, un embauché ou une personne expérimentée.*
En fait comme le souligne Ekolamar, il faut aussi que la personne ait envie de monter en compétences. Malheureusement je te rejoins sur le fait que la veille technologique se fait sur le temps perso :/ Dans un monde parfait (qui sera d'ailleurs ma prochaine boite B)), il faudrait un certain temps alloué par semaine pour faire de la veille. Mais bon, le jour où ça arrivera en ESN ... au moins j'ai la chance d'avoir un accès illimité à des formations en ligne :D
* après relecture on dirait que je suis dans un projet parfait. En réalité, sur 2 ans, on a eu une période avec un leadtech classique, ensuite pas de leadtech où c'est parti en cacahuètes, et là depuis quelques mois on a un leadtech super rigoureux qui a mis tous les bons process en place. Donc je pense que c'est super dépendant de la mentalité de celui-ci, s'il arrive à persuader les chefs que bons process = bonne qualité = des sous :mrgreen:
Salut, je me permets de me joindre à la discutions, actuellement mon entreprise forme tous le monde à scrum, à git, aux test untaire etc ... et on nous a proposé le scrum master tournant aussi, ça fait beaucoup de changement en une fois mais ont peut pas leur reprocher de pas y mettre les moyens, je me sens chanceux de pouvoir être formé sur plein de sujet en même temps tout en étant payer ( alors que sur le temps libre on est pas payé ) alors que pour choisir/obtenir une formation tout seul c'est la croix et la bannière :(
Les petits gâteaux, c'est pas à la charge du (ou de la, car il faut le dire, c'est surtout un métier féminin...) Chief Happiness Officer ?
Lorsque David Graeber, le créateur du mot "bullshit-job" est venu à paris en septembre dernier pour faire la promotion de son bouquin, j'avais vu une interview d'un Scrum Master. Qui était en bore-out parce qu'il travaillait qu'une demi-journée par semaine...
Il y a quelques années, un pote m'avait raconté qu'il était allé à une réunion et y avait une nana qui ne faisait rien d'autres que faire les comptes-rendus de réunion et s'assurer que la réunion ne débordait pas en terme d'horaires (pour une réunion de 15h à 16h, elle chassait tout le monde à 15h59 pour laisser la salle libre aux prochains). Apparemment elle touchait énormément. Bon après, faut dire, les réunions c'est tellement chronophage, que payer une personne pour empêcher 12 autres de perdre une heure de plus, c'est peut-être rentable...
S'il est vrai qu'un dev doit se tenir à jour par de la veille techno, ce n'est pas sur son temps libre. Cela fait parti de ses responsabilités en tant que dev, c'est donc à faire pendant son temps de travail. S'il le fait déjà pendant son temps libre parce que ça l'intéresse personnellement, c'est tout bénèf pour lui et son employeur, mais ça n'est pas une contrainte. Cela ne remplace bien entendu pas une formation, mais il y a une grosse différence :
- Une formation vise à te donner un ensemble de connaissances précis, une formation se justifie donc par le besoin d'avoir ces connaissances là. Par exemple un client pose comme contrainte d'utiliser telle techno -> formation sur la techno si pas compétent.
- La veille techno consiste en revanche à parcourir l'état de l'art pour se tenir au courant de ce qui se fait de nouveau, faire des POCs, essayer de voir si de nouvelles technos pourraient être intéressantes, etc. Rien de confirmé, pas de périmètre prédéfini, que de l'expérimental, et donc à creuser juste ce qu'il faut pour se faire une idée de son utilité.
Tu peux éventuellement faire de la veille techno, confirmer l'utilité d'une techno, et donc justifier la mise en place d'une formation pour rapidement monter en compétence dessus. Mais il faut bien les voir comme deux choses complémentaires.
Je ne parle bien entendu pas des startups, qui semblent être des environnements à stress permanent.
Quand mon boss me propose de suivre une formation sur une réforme banquaire parce que je vais avoir un e-learning à produire sur le sujet, partir 1 semaine pour apprendre un truc qui ne me servira pas, je vois pas bien où est mon intérêt. Après, je comprends le besoin, mais bon. Attendre de ma part une motivation....
Souvent, il faut le reconnaître, les entreprises ne jouent pas le jeu. Une formation doit être utile pour l'avenir pro de l'employé.e, pas juste au businessde l'entreprise.
Un de mes collègues infographiste avait déposé une plainte auprès du CHSCT car il voulait utiliser son crédit formation pour se former au cinéma d'animation. L'employeur avait refusé avec pour seule justification : "C'est pas mon coeur de métier, ça ne m'apportera rien.". Ben, mon collègue à eu gain de cause et il est partie 1 mois aux Gobelins.
Et vous, auriez-vous aussi la clim en panne avec des collègues qui suent des masses ? :mrgreen::aie:
Ah non la clim fonctionne bien, c'est même un plaisir d'arriver au travail après l'enfer des transports !
Par contre ça m'est déjà arrivé quand j'étais junior de tomber dans des bureaux où le chauffage ne fonctionnait pas en plein hiver (obligé de frotter mes mains et souffler dessus pour les réchauffer, c'est pour dire...) puis la clim en plein été (où comment compter les gouttes de sueur perler sur son front en restant assis devant son pc...).
Idem, la clim fonctionne très bien c'est un plaisir !
Pour la vague de canicule, mon client a envoyé un e-mail à tous les employés et presta pour un plan d'urgence : les locaux ouvrent désormais une heure plus tôt, et les personnes qui ont une journée hebdomadaire de télétravail sont invités à venir profiter de la clim des locaux à la place ^^
La caniquoi ? Connais pas icitte :mouarf:
J'aime mon métier parce que il m'aide à:
- payer mon loyer,
- remplir le frigo,
- payer les vacances de ma famille,
- donner un statut social décent à ma famille (c'est juste un perçu),
- aborder plusieurs problématiques et challenges scientifiques intéressants,
- réaliser que j'ai contribué à mon échelle à faire prospérer une affaire qui fait vivre d'autres familles que la mienne.
Mais en vrai, je n'aime pas mon métier parce qu'il me contraint à:
- partir de chez moi avant 8h45 tous les matins,
- rentrer chez moi vers 19h tous les soirs,
- me farcir des transports en commun bondés, irréguliers, non climatisés (pour la plupart),
- diminuer mon niveau d'exigences techniques pour se conformer à certains budgets alloués,
- travailler mon hypocrisie pour être mieux vu, et donc, mieux rémunéré.
Je suis de plus en plus heureux au travail quand:
- j'accepte que SCRUM ne sera jamais appliqué dans sa vrai philosophie dans les entreprises (quand j'entends Scrum Master = Team Leader, ou Product Owner = Manager, j'hésite entre me suicider ou instruire les autres qui ne changeront pas d'avis de toute façon),
- j'accepte que mieux produire par rapport à mes pairs n'entraîne pas forcément une bonne rémunération,
- j'accepte que le vrai montant de ma retraite et mon âge de départ n'ont jamais été aussi incertains,
- je sais que de toute façon, je peux quitter mon entreprise actuelle pour aller voir ailleurs pour avoir 2 ou 3k en plus par an (soit 50€ net max par mois). Et encore, ce n'est pas si sûr.
Malheureusement, c'est la dure loi de l'offre et de la demande. Si la demande (poste) ne suit plus, il faudra modifier l'offre (candidature). En effet, les dévs de 40 ans et plus avec qui j'ai travaillé se comptent les doigts d'une seule main. Les postes techniques où j'ai rencontré un peu plus de quadra sont dba et architecte (réseau/système ou applicatif).
Sinon, je pense qu'à cause du grand vivier de dévs Web disponible sur le marché, ce poste sera de plus en plus inaccessible pour les seniors non spécialisés sur une niche.
Malheureusement, cela peut aller dans le sens inverse aussi. Il y a des "seniors" qui sont tellement enfermés dans leur zone de confort, qu'ils deviennent très résistants au changement. Il faut toujours se remettre en question et ne pas prendre la grosse tête même en ayant plusieurs années d'expériences derrière soi (et je parle pour moi aussi).
Moi aussi, j'ai augmenté mes tarifs et bizarrement, j'ai des meilleurs projets et des clients plus fidèles ;);) $$$$$$$$$$$$$$$Citation:
Envoyé par GuillaumeJ[...
Pas sur qu'ils codent comme un pied. Je pense qu'ils correspondent mieux à un dynamisme de production. Ils apprennent sur le tas, font des journées à rallonge et sont payés à coup de pizza / coca. Et ils font pas chié avec une famille qui les attend à la maison le soir.
En même temps, si tu as l'XP et les compétences, pourquoi te priver ? Ça n'aurait pas de sens. Brader ton savoir-faire parce que telle ou telle entreprise veut pas payer, c'est pas crédible.
J'ai refusé 2 offres avec des salaires en dessous de mes prétentions. Les mecs me disent que je suis trop cher ? Je leur répond qu'un profil comme le mien, ça se paye, sinon faut prendre un Junior.
À nos niveau, il ne faut pas craindre de dire non. Après tout, on a bossé dur pour avoir des exigences.
Après, plus I'm y aura de Juniors en entreprise, plus on aura besoin de presta pour rattraper leurs conneries.
C'est tout benef' pour moi.
Lorsque j'étais étudiant, j'ai fait en parallèle de mes études divers boulots (que je ne qualifierais pas de "petits", même s'ils demandaient peu ou pas de qualification académique).Citation:
Aimez-vous votre métier de developpeur ?
J'ai un bac +5 dans un domaine scientifique autre que l'informatique, et j'ai débuté ma carrière professionnelle dans un domaine autre que celui du développement.
Et ce que je tire de mon expérience, c'est que coder est un putain de privilège. Tout autour de moi, je vois des tas de gens qui ont des boulots qui ne sont pas stimulants intellectuellement et n'ont aucune utilité pratique (et ce même si les postes en question ont des intitulés ronflants et que ceux qui les occupent ont de grosses bagnoles). Un développeur, lui, doit réfléchir, et il va produire quelque chose de concret destiné à remplir un service (son application). Donc oui, j'aime mon boulot et je me considère même comme un privilégié.
Tu es dans la caricature. Ce dont tu parles, c'est vraiment des cas isolés, et encore... Les seniors ont une hauteur de vue sur leur métier. Toutes les erreurs qu'un junior fera, un senior les a déjà fait, du coup il en capable de prendre énormément de recul. Il a acquis une sagesse et son expérience aide énormément.
Pour ce qui est de la résistance au changement, je connais des jeunes qui, même si on leur prouve qu'ils vont droit dans le mur, ne changeront jamais de direction.
Et pour l'histoire du "melon", disons que c'est une impression vécue par un jeune face à un senior. L'ordre "naturel" des choses, c'est tout de même d'apprendre de ses aînés, de les respecter et de profiter de leur expérience. Un jeune aussi dans 20 ans, il sera Senior et pourra passer pour un vantard :)
Mais il peut aussi décider d'ignorer une nouvelle méthode qui pourtant apporte beaucoup. Il y a du pour et du contre dans les deux cas. Je suis personellement en faveur du mélange des classes d'âge, chacun a apporter à l'autre. (et ma fille avait 17 mois quand elle m'a appris comment ôter un cache-prises quand on a pas la clef idoine - autant pour les anciens qui savent tout)
Oui, ça, des cons, il y en a partout.
Pas dans un domaine qui change aussi vite. Nous les vieux avons certes un certain nombres d'avantages, mais certains de nos reflexes sont devenus contre productifs.
Un sénior est en moyenne plus fort qu'un junior, mais il ne suffit malheureusement pas de faire des erreurs pour comprendre que ce sont des erreurs.
En effet, il existe des séniors qui font toujours plein d'erreurs qu'ils faisaient déjà quand ils étaient juniors, car ils n'ont toujours pas compris que c'étaient des erreurs et voient les conséquences de ces erreurs comme une fatalité.
Par exemple, il existe des séniors qui n'écrivent pas de tests unitaires. Du coup :
- Quand ils constatent qu'ils ajoutent souvent des bogues dans leur code, ils voient ça comme une fatalité du cycle de vie du logiciel. Ils ne voient pas que la plupart de ces bogues auraient été interceptés par des tests unitaires.
- Quand le code a besoin d'être amélioré, par exemple pour être plus lisible ou pour extraire un morceau que l'on veut réutiliser ailleurs, ils ont tendance à adopter la maxime "Si ça marche, on ne touche pas". Du coup, le code dégueulasse s'amoncelle.
Franchement, pour avoir comparé mon JS avec un "jeune developpeur" fraichement formé... alors, okay, il est meilleur que moi sur les fonctions ES6 ou React ou Vue, mais dès qu'on parle d'algorithme (et y a toujours de l'algorithme)... y a pas photos. (1)
Idem pour la prise en compte de la maintenabilité.
Ce que je veux dire, c'est que quand même, plus ça change, moins ça change. les MFC, c'est pas les CSS, mais les traitements derrière, que ca soit du C ou du Node.JS ou du Go.. bah y a des reflexes et des habitudes qui sont toujours valides.
En fait, je crois que ce qui fait la qualité d'un code source, c'est intemporel, et c'est toujours applicable.
(1) et j'aurai tendance a penser que je vais bien plus vite rattraper son niveau de Vue que lui mon niveau d'algorithme (sens large)