Moi sur Youtube
https://www.youtube.com/channel/UCN8...RmYqnb4xA0elvQ
Dans Scrum on travaille en itérations, des sprints, des user-story, des sous-taches techniques ci-besoin.Blablabla agile = Bullshit.
Entre autre sont des courtes itérations et avoir des items de petite taille à des tas d’avantages :
- La motivation. Quand on valide l’incrément du produit tous les jours, voir que l’on dépile les storys, c’est important. Beaucoup plus que de se dire « J’ai 5 jours à bosser sur le chapitre 3 de la SFD ».
- Pouvoir faire la critique de l’incrément, tant technique que fonctionnel, avant qu’il ne soit trop tard.
- …
Dans mon équipe on a beaucoup moins d’interruptions que ce que j’ai déjà vu.
- D’une part les tickets sont adressés à l’équipe, d’autre part chacun des devs ont des users story chiffrées en une unité plus proches des jours que des heures et des semaines.
- Entre chaque user-story, on regarde si il y a des problèmes urgents et tout au plus les utilisateurs ou CP dans le besoins ont attendus quelques minutes / heures et cela sans être interrompus.
Après, tout ça c’est du management d’équipe. On peut faire de bons systèmes avec cycle en V ou waterfall mais aucun aspect de ces derniers n’a un avantage direct avec les interruptions, contrairement à Scrum.
On s'en fou de ce que les autres pensent (tant qu'on est productif).
Et puis j'ai fait une description de la technique et si tu t'etais bien renseigné tu verrais que le mot pause peut être différent selon les personnes. Dans ces 5 minutes, tu peux bien aller voir le collègue qui t'a sollicité il y a quelques minutes parce que tu lui avais dit bien gentiment: "Je viens te voir dans 10 minutes", ou alors lire quelque chose d'interessant sur la tâche que tu viens d'interrompre, ou encore faire une revue de code de ce qu'a commité l'autre collègue, etc ... Par exemple rediger ce message m'a pris mes 5 minutes de pause
En tout cas, ça fait 4 ans que j'utilise la technique et ça n'a jamais dérangé personne. C'est ma manière de travailler. Si mon employeur n'est pas content, je peux gentiment m'en aller voir ailleur... Et puis cette façon de se surveiller entre collègues, c'est bien un truc frenchy ...
Et puis ça ne fait que 6 à 7h de temps de concentration et 2 heures de pauses dans une journée. Personnellement je trouve ça pas mal.
Pas vraiment car ta productivité est directement liée à ta capacité à bien travailler avec les autres qui est également liée aux rapports que tu entretiens avec eux.
On est bien plus productif dans une équipe où l'ambiance est bonne car cela facilite l'entre aide, la coopération, l'engagement, etc.
La productivité en info, ce n'est pas juste pisser du code sur des algo plus ou moins complexes.
Par contre, je connais bien la méthode Pomodoro et j'ai même certains membres de mon équipe qui l'appliquent.
Le mot "pause" est à prendre avec beaucoup de recul car cela ne signifie absolument pas l'arrêt du travail général mais juste sur la tache en cours.
L'idée est de faire une coupure sur la tâche en cours mais cela ne signifie pas forcément d'aller boire un café. Cela peut se faire en répondant à des mails pro qui portent sur des sujets totalement différents de la tache mise en suspend ou encore, d'aller voir un collègue qui avait sollicité notre aide, etc.
Dans mon équipe, on pratique les tests croisés et ces moments de pause sont particulièrement adaptés pour ça car justement, on profite de ces instants pour tester les dev du collègue ce qui permet de faire un break sur le travail en cours et de le reprendre avec des idées fraîches.
Autrement dit, lorsque Pomodoro est mis en oeuvre avec intelligence, ça se passe très bien.
Je n'ai jamais eu à redire là dessus et ma hiérarchie non plus.
Nous sommes pour la plupart des cadres au forfait jour et on gère notre organisation de temps de travail en autonomie et avec intelligence.
ça, c'est un problème managerial. Si tu as un intermédiaire qui peut filtrer les demandes, ça se passe mieux, quand même. J'ai été chez des clients ou en tant que développeur, je n'avais pas le droit de contacter directement les utilisateurs, et ce explicitement pour qu'ils n'aient pas accès à mon numéro, et ne viennent me déranger sans l'aval de la chef.
Ca peut poser des problèmes de transmissions de l'informations, mais au moins, le chef sait sur quoi bossent les programmeurs, et peut gérer les priorités. Et ça limite fortement les interruptions.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
On peut aussi éduquer les clients pour qu'ils communiquent préférentiellement par courriel.
En général, je réponds aux courriels dans la demi-journée, au moins pour accuser réception et informer que la question est en cours de traitement, si je n'ai pas la réponse immédiate.
Et ça marche dans les deux sens, je ne dérange pas avec le téléphone sans raison valable.
De cette façon, je suis rarement interrompu, même sans filtrage.
Oui c'est managérial : J'ai une directrice adjointe qui a la hantise de "perdre" ou de se "fâcher" avec un client si il a pas de réponse dans les 5 secondes... Du coup mes consignes aux standardistes (de prendre les appels) sont régulièrement
outrepassées au point que je dois parfois me fâcher afin que l'on nous laisse nous concentrer sur le travail en cours en toute tranquillité
Perso, c'est la méthode que j'applique au boulot. Un casque sur les oreilles pour m'isoler sur bruit incessant du bureau, et pour signaler aux autre : foutez moi la paix, je suis concentré. En général sa marche, surtout que lorsqu'on me dérange en pleine réflexion, je suis en général d'humeur massacrante .
Très honnêtement après 18 ans dans le développement il est devenu de plus en plus difficile de se concentrer sur une tache de dev. Je me souviens à mes débuts où je pouvais passer 10h sur un pb sans que personne ne viennent me déranger et j'avais le sentiment d'abattre du boulot à la fin de la journée aujourd'hui ma productivité au niveau code est proche de 10% comparativement à ce que je faisais avant. Les openspaces où tout le monde s’immiscent dans l'espace de travail des autres, provoque des réunions sur un coin de la table (merci la méthode agile !) où les téléphones sonnent en permanence ou maintenant un bruit de fond ne baisse pas avant la pause de midi, y sont pour quelque chose. Je milite pour le télé-travaille généralisé pour les développeurs qui peuvent bénéficier d'un environnement apaisé et calme chez eux. Je suis également plus disposé à la concentration entre 19h et 00h malheureusement c'est le moment où je dois rentrer chez moi donc je fais ce que l'on me dit :-(
Je suis convaincu pour l'avoir vécu moi même et vue chez mes collègues qu'on peut faire en 1 jour chez soi ce que l'on ferai péniblement en 5 au bureau si c'est souvent beaucoup plus. Mais bon je ne me fais pas d'illusion je sera déjà à la retraite (après une seconde partie de carrière solo), le jour où les décideurs comprendrons cela.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
En 18 ans, il s'est passé énormément de chose et tout mettre sur le dos de l'Agile et des openspaces est un peu simpliste.
Pour commencer, les openspaces, ça ne datent pas d'aujourd'hui.
Je travaille depuis 11 ans et j'ai tjrs connu les openspaces et ils ne sont pas devenus à la mode au moment où j'ai commencé à travailler.
Il y a beaucoup de choses qui se sont passées au cours des 11 dernières années qui à mon sens, ont énormément changés les méthodes de travail et le fonctionnement des entreprises.
Pour commencer, l'ère du portable est passée par là.
Depuis l’avènement des smartphones, les gens sont joignables partout et tout le temps que ce soit dans le privé ou dans le milieu pro et les gens se sont habitués à ça.
C'est un changement culturel majeur qui a affecté énormément notre rapport au temps et s'est répercuté dans le monde de l'entreprise.
Ensuite, on retrouve également le généralisation du haut débit et même du très haut débit.
Tout comme avec les smartphones, les gens n'attendent plus et ne savent plus attendre.
On est vraiment dans l'instantanéité permanente et cela se reflète également dans les entreprises.
L'arrivée des réseaux sociaux a également participé à l’accélération du temps.
Les infos circulent à toute vitesse et les gens, y compris via leur smartphone, sont sollicités en permanence par des notifications en tout genre.
Du coup, ils appliquent le même procédé au bureau.
La mondialisation, même si elle a débuté il y a une paire d'années, s'est particulièrement accélérée avec tous les points cités ci-dessus.
Comme les individus et les entreprises sont connectés avec le monde entier et tenus informés en quasi-temps réel, c'est une course à la concurrence permanente.
On va tjrs trouver une idée mise en place quelque part qu'il faut être le premier à reprendre ou encore, un concept ne reste pas exclusif / différenciant bien longtemps donc faut se renouveler en permanence et à tout allure.
L'Agile est donc venu accompagné toutes ces évolutions du monde économique et de la société.
Bien sûr que non j'ai moi même débuté dans un openspace, dans mon post je ne critique pas tant cet espace de travail qui bien utilisé est formidable, que le comportement de ceux qui y travaille qui lui a bien évolué en presque 2 décennies. La méthode agile oui par contre c'est bien un perturbateur de la concentration. Lorsqu'on fait 2 meetings par jour juste pour dire ce que l'on fait et dans la foulée qu'on se prend la tête avec les pbs des autres alors qu'on a un algo sur le feu et que le cheminement de notre pensée à ce moment là ne demande qu'à s'évanouir dans les limbes ... Ça m'est concrètement arrivé de devoir tout reprendre a zéro après une petite interruption parce que j'étais en train de me démener lors d'une séance intense de debuguage et que la personne qui vient me voir (le plus souvent un manager) n'a pas la patience d'attendre que je sorte la tête de l'eau pour lui répondre ...En 18 ans, il s'est passé énormément de chose et tout mettre sur le dos de l'Agile et des openspaces est un peu simpliste.
Pour commencer, les openspaces, ça ne datent pas d'aujourd'hui.
Je n'ai pas vraiment l'impression que l'on fait tellement plus de réunions avec l'Agile qu'avec un bon gros cycle V.
Le stand up meeting du matin, lorsque tu as bon CP qui cadre bien, ça ne dure que 10 à 15min et c'est en début de matinée donc pas trop le temps de démarrer du boulot avant et d'être coupé dans son élan.
Avec l'Agile, les réunions sont étalées dans le temps et sont, en moyenne, plus courtes.
Alors qu'avec le cycle en V, on fait de très grosses réunions en démarrage de projet pour en faire moins par la suite mais si des points de synchro sont tout de même nécessaires.
Pour le second point, il y a tjrs eu de l'entraide entre les développeurs et l'Agile ne change rien à ça.
Vu ta séniorité, je pense que tu dois être plus sollicité que les autres mais cela est plus lié à la reconnaissance de ton expérience qu'aux méthodes de travail choisies.
Par contre, le point particulièrement embêtant avec l'Agile en openspace c'est justement que les lean meeting se font dans l'openspace et que ça amène pas mal de bruit et de perturbations (car comme tout le monde en fait, impossible d'avoir une salle pour le faire).
Encore un gars qui va me dire agile === scrum.
Et l'extreme programming, c'est quoi. Combien de fois, les gens ont mélangé scrum et extrême programming.
J'ai vu aussi des trucs bizarre ou le gars fait du Scrum tout seul ... Mettre des post-it c'est pas du scrum merci. Il ya une todo list pour ça.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager