Dans cet article, Matt, développeur à Los Angeles, s’attaque aux daily standups, ces réunions de la méthodologie SCRUM, très à la mode actuellement. Sous ce terme se cache une réunion quotidienne d’au plus 15 minutes, se déroulant normalement debout, qui a pour but la synchronisation de l’équipe. La traduction choisie ici est « mêlée quotidienne », mais on trouve aussi les appellations « Daily », « standups » ou réunions quotidiennes.

Source : The pointlessness of daily standups

Traduction framalang : Maïa, Côme, Evvin, Fabrice, Goofy et Marius

De l’inutilité des mêlées quotidiennes

Vos mêlées quotidiennes tuent votre productivité.

Peut-être est-ce de la naïveté ou peut-être est-ce seulement le fait d’avoir fait partie d’équipes où, c’est un point important à noter, personne (pas même moi) ne savait comment mener une mêlée quotidienne efficacement, mais je n’en ai jamais compris l’utilité. Ceci est doublement vrai si on prend en considération l’utilisation en parallèle d’outils tels que Jira ou Trello, couplés aux messages incessants que permet Slack.

Quelle est finalement l’utilité d’une mêlée quotidienne ? Si j’envisage de critiquer quelque chose, je préfère être certain de savoir de quoi je parle. J’ai une vague intuition de ce que doit être leur rôle, mais pour être complet, jetons (rapidement) un œil sur la description d’une mêlée quotidienne dans la documentation d’Atlassian :

[…] une mêlée quotidienne est une réunion qui implique l’équipe de base : les propriétaires du produit, les développeurs et le facilitateur SCRUM. Le style de cette réunion est propre à chaque équipe, mais chez Atlassian, nous utilisons trois questions simples pour la structurer :

• Sur quoi ai-je travaillé hier ?
• Sur quoi vais-je travailler aujourd’hui ?
• A quels obstacles suis-je confronté ?

… et un peu plus loin…

Ces questions mettent en lumière les progrès et aident à identifier ce qui bloque l’équipe. De même, cela renforce l’équipe car tout le monde partage les progrès qui contribuent à l’équipe. Le renforcement quotidien du partage des réussites et des plans individuels maintient l’enthousiasme collectif quant à la contribution globale de l’équipe à l’entreprise.

Ok, donc fondamentalement, le seul intérêt des mêlées quotidiennes est de « maintenir tout le monde enthousiaste » ?

… *** gros soupirs *** …

J’ai toujours eu l’impression que l’industrie aime traiter les équipes de développement comme une bande d’ados stupides. Permettez-moi de m’étendre là-dessus…

Nous devrions être enthousiastes et nous sentir chanceux de disposer de tables de ping-pong, d’en-cas gratuits, de jours de congés pour les anniversaires (avec durée indéterminée, pour écraser l’altruisme), et maintenant, d’être capable de voir les progrès de chacun ? Comprenez-moi bien, je ne suis pas cynique à ce point-là, mais cet argument en particulier pour les mêlées quotidiennes me frappe telle la carotte au bout du bâton du micro-management.

Peut-être que cela enthousiasme certains, et peut-être même que des gens en tirent des bénéfices. Je dirais plutôt qu’ils n’utilisent pas leur panoplie d’outils à leur maximum, mais passons, je leur laisse cela. Cependant, je préfère m’intéresser au ratio coût/bénéfice des mêlées quotidiennes et alors votre équipe pourra prendre une décision sur ces calculs.

Mettons de côté pour un instant le « facteur d’enthousiasme » qui n’est pas quantifiable. Nous devons être capables de régler les points suivants :

• Qu’a fait un membre de l’équipe hier
• Que fait un membre de l’équipe aujourd’hui
• N’importe quel élément bloquant qu’un membre de l’équipe rencontre

… d’accord, j’allais écrire un paragraphe ou deux sur ces points, mais je vais m’en remettre à Cervantes pour ce coup-ci :

Sois bref dans ton discours, car ce qui est prolixe ne peut être agréable

(Intelligence et sagesse de Don Quichotte)

Voici donc les contre-arguments :

• Jira, Trello, Asana, les post-it sur le mur, ou discussions sur Slack
• Jira, Trello, Asana, les post-it sur le mur, ou discussions sur Slack
• Ils devraient alerter le reste de l’équipe immédiatement

Les deux premières réfutations ne nécessitent pas de clarification j’espère. Pour le dernier point, soyons honnêtes, si vous êtes bloqué⋅e sur quelque chose et que vous attendez la prochaine mêlée pour prévenir le reste de l’équipe que vous êtes bloqué⋅e, d’autres soucis de communication doivent être pris en compte. Les points bloquants doivent être traités immédiatement.

« Attendez une minute ! », pourrait-on me dire, « cela va déranger l’équipe si les gens sont interrompus à cause d’un point bloquant ! ». Déranger l’équipe ? Vous voulez dire comme un point quotidien des tâches de chacun de la veille et du jour, sans compter les quasi-omniprésentes digressions ? Ce genre d’interruption ?

Je n’en vois pas le bénéfice global. J’argumenterais que la perte d’attention est plus probable que l’intérêt de savoir sur quoi travaille quelqu’un d’autre. Réellement. Réfléchissez-y. Combien de fois retirez-vous des informations utiles de vos mêlées (que vous n’auriez pas pu obtenir de vos outils de suivi de projet), par opposition à la perte de contexte de votre propre travail et — pour finir — par rapport à l’attention consacrée à des digressions qui devraient se dérouler en dehors des réunions ?
Vous voulez une équipe plus efficace ? Vous voulez des plages de concentration plus longues pour avancer sur les tâches de votre sprint ?
Soyez asynchrones, et supprimez les mêlées quotidiennes. De toute manière, elles ne servent à rien.

À propos de l’auteur

Matt est un développeur frontend qui vit (et skate) à Los Angeles. Il développe en React et en TypeScript, mais s’intéresse beaucoup aux langages bas-niveau (Rust, C++, C, …).

Il est joignable via Mastodon ou Twitter

Aujourd’hui nos employeurs peuvent intercepter nos communications passées sur notre lieu de travail, une nouvelle atteinte à la vie privée que n’auraient pas admise nos parents et dont nos enfants sont victimes.

Voici déjà le 20^e article de la série écrite par Rick Falkvinge. Le fondateur du Parti Pirate suédois aborde ici le droit légal des employeurs à prendre connaissance de nos messages quand ils sont passés dans l’entreprise.

Le fil directeur de la série de ces 21 articles, comme on peut le voir clairement dans les épisodes précédents que nous vous avons déjà livrés, c’est la perte de certaines libertés dont nous disposions encore assez récemment, avant que le passage au tout-numérique ne nous en prive.

Votre patron ne pouvait pas lire votre courrier. Jamais.

Source : Rick Falkvinge sur privateinternetaccess.com

Traduction Fralang : dodosan, Susyl, goofy.

Slack vient tout juste de mettre à jour ses conditions générales d’utilisation pour permettre à votre employeur de lire vos conversations privées sur des canaux privés. Nos parents auraient été choqués et horrifiés à l’idée que leurs chefs ouvrent les colis et lisent les messages personnels qui leur étaient adressés. Pour nos enfants dans le monde numérique, cela fait partie de la vie de tous les jours et ne mérite qu’un haussement d’épaule.

Le bon vieux système téléphonique, parfois appelé par son abréviation anglaise POTS, est un bon exemple de la façon dont les choses devraient se passer, même dans le monde numérique. Les législateurs avaient vu juste dans l’ensemble à ce sujet.

Lorsque quelqu’un passe un appel téléphonique – un appel à l’ancienne, analogique – on sait que la conversation est privée par défaut. Peu importe à qui appartient le téléphone. C’est la personne qui l’utilise, à cet instant précis, qui a tous les droits sur ses capacités de communication à l’instant T.

L’utilisateur a tous les droits d’utilisation. Le propriétaire n’a aucun droit d’intercepter les communications ou d’interférer avec elles sur la seule base du droit de propriété.

Autrement dit, être propriétaire d’un outil de communication ne donne pas automatiquement le droit d’écouter les conversations privées passant par cet équipement.

Malheureusement, cela ne s’applique qu’au réseau téléphonique. Qui plus est, uniquement à la partie analogique du réseau téléphonique. Si quelque chose est même de loin numérique, le propriétaire peut intercepter pratiquement tout ce qu’il veut, pour n’importe quelle raison.

Cela s’applique particulièrement au lieu de travail. On pourrait soutenir qu’on n’attend aucun respect de la vie privée quand on utilise l’équipement de son employeur. Cela revient précisément à oublier qu’une telle intimité était primordiale pour les POTS, il y a moins de deux décennies, quel que soit le propriétaire de l’équipement.

Certains employeurs installent même des certificats numériques wildcard¹ sur les ordinateurs de l’espace de travail, dans l’objectif bien particulier de contourner la sécurité de bout en bout entre les ordinateurs des salariés et le monde extérieur, effectuant ainsi une attaque dite « homme du milieu ». En termes politiquement corrects, cette pratique est appelée « interception HTTPS² » et non « attaque de l’homme du milieu » quand elle est menée par votre employeur et non par un autre attaquant.

Puisque nous en sommes à comparer analogique et numérique et la façon dont les droits à la vie privée se sont évaporés en passant d’une époque à l’autre, il est intéressant de jeter un coup d’œil aux lois qui régissaient un fort ancien moyen de communication, la correspondance postale. Demandez-vous si votre patron pouvait ouvrir votre courrier simplement parce qu’il vous était adressé sur votre lieu de travail.

Les lois sont un peu différentes selon les pays sur ce point, mais en général, même si votre patron ou entreprise étaient autorisés à ouvrir votre correspondance (c’est le cas aux USA mais non en Angleterre), ils n’étaient en général jamais autorisés à la lire (même aux USA) ;

Tout au contraire, pour le courrier électronique, vos employeurs ne se content pas de lire la totalité de vos courriels, mais ont souvent engagé une équipe entière pour le faire. En Europe, la chose est allée jusqu’à la Cour Européenne des Droits de l’Homme, qui a statué qu’il est tout à fait normal pour un employeur de lire la correspondance la plus privée, pourvu qu’il en informe les employés (ce qui piétine au passage l’espoir d’une confidentialité par défaut)

Il va de soi que ce principe qui s’applique aux courriels maintenant un peu démodés s’applique désormais aussi à tous les moyens de communication d’aujourd’hui, tels que Slack.

De sorte que pour nos enfants de l’ère numérique, l’idée suivant laquelle « le courrier c’est privé et il vous appartient, peu importe si vous le recevez au travail » semble définitivement oubliée. Encore un principe que nos aînés de l’époque analogique tenaient pour acquis, et pour lequel ils n’ont pas cru nécessaire de combattre.

La vie privée demeure de votre responsabilité.

Warning : cet article parle de forge logicielle qui sert à développer collaborativement du code. Il est donc un peu velu et technique, mais il fera plaisir aux plus « barbu-e-s » d’entre vous !

Préviousselaid, chez Framasoft : nous avions besoin d’une forge logicielle comme outil interne à l’asso… parce que même si nous ne développons pas (ou exceptionnellement) de logiciel libre ; les mettre en avant, les améliorer (parfois), les promouvoir et ouvrir des services au monde, ben ça demande de créer, maintenir, échanger et améliorer du code !

Nous nous étions donc installé Gitlab à la main, sur un coin de serveur, juste pour nous…  Étant les seuls utilisateurs, on s’est dit que ce ne serait pas grave s’il n’était pas toujours à jour, à traquer la dernière version… (oui : nous sommes moins exigeants sur nos outils internes que pour les services que nous ouvrons au grand public ^^).

Franchement, merci Google !

Merci, parce qu’à chaque fois que vous prenez des décisions unilatérales aux dépens de vos utilisateurs-produits, vous nous offrez l’occasion de prouver que le Libre offre des alternatives bien plus respectueuses des personnes qui vous ont confié leur vie numérique (et leur code).

Le jour où nous avons appris que Google Code fermait ses portes, nous avons donc décidé d’ouvrir les nôtres. Cela nous a aussi permis de sensibiliser au fait que, dans le mode des codeurs et développeuses, GitHub est devenu un point central et monopolistique assez inquiétant.

Forcément, l’ouverture à tous de notre git et les nouvelles fonctionnalités des nouvelles versions de Gitlab (une nouvelle version tous les 22 du mois) nous ont incités à mettre à jour plus régulièrement, ce qui prend plusieurs heures à chaque fois… et plusieurs fois par mois, car des versions correctives sont régulièrement publiées.

Améliorer le Framagit… une priorité

Ceci, ajouté à l’utilisation grandissante de notre forge qui allait bientôt poser des problèmes de taille de disques, nous a amenés à migrer (le 17 mars dernier) notre Gitlab vers une machine avec plus de disque et surtout avec une installation utilisant les paquets dits « omnibus ».

Ces paquets omnibus nous ont permis d’installer Gitlab à l’aide d’un simple apt-get install gitlab-ce plutôt que de suivre la longue procédure d’installation manuelle. Non seulement l’installation est simplifiée, mais — et c’est surtout là la plus-value que nous en attendions — mettre à jour Gitlab devient tout aussi simple avec une seule commande apt-get dist-upgrade.

Résultat : notre Gitlab suit scrupuleusement la publication des nouvelles versions, avec leur lot de nouvelles fonctionnalités !

Pour fêter cela, nous avons étrenné un nouveau nom de domaine… inspiré par vous ! Avouons-le, «Git point Framasoft point orrrrrrrgueh », ça accroche un peu en bouche. De partout, nous avons entendu parler du « Framagit » : alors tant qu’à faire, autant l’appeler comme vous le faites déjà. Bien entendu, il n’est nul besoin de modifier vos URL, elles restent valides… mais la nouvelle est à votre disposition !

Et si on ajoutait de l’intégration continue ?

Derrière ce terme barbare se cache une fonctionnalité très pratique : on crée une « recette » qui sera exécutée dans une machine virtuelle à chaque push. Cela peut par exemple permettre de lancer une suite de tests pour vérifier que l’on n’a rien cassé. 🙂

Pour utiliser cette fonctionnalité, il faut disposer de ce que l’on appelle un runner, c’est à dire un logiciel qui va récupérer la recette et l’exécuter. Il est possible d’installer un runner sur n’importe quel ordinateur, même votre ordinateur de bureau.

Pour ceux qui ne souhaitent pas gérer leur runner eux-mêmes, Framasoft met à disposition deux runners partagés entre tous les utilisateurs de Framagit, que vous pouvez utiliser comme bon vous semble. Notez toutefois que Gitlab indique que quiconque utilise un runner partagé peut accéder aux informations des projets utilisant ce runner : il vaut mieux monter votre propre runner pour vos projets sensibles.

De plus, en utilisant les runners partagés de Framasoft, il est possible que votre projet soit mis en file d’attente, en attendant que les recettes précédentes aient fini de s’exécuter… à vous de voir !

Vous voulez des pages Gitlab ? Nous aussi !

Github permet à tout un chacun d’héberger un site statique. Gitlab propose une fonctionnalité similaire mais hélas, uniquement dans sa version entreprise… Nous utilisons pour notre part la version communautaire qui est la version libre de Gitlab… donc sans les pages Gitlab.

Nous avons donc ouvert un ticket pour demander que cette fonctionnalité soit incluse dans la version communautaire. Si vous aussi vous aimeriez voir cela arriver, aidez-nous tout simplement en votant sur https://gitlab.com/gitlab-org/gitlab-ce/issues/14605.

En attendant, profitez d’une forge logicielle à jour et libre sur Framagit.org !