Quand remettre les gens à leur place

J’ai souvent parlé du comportement en entreprise, en insistant sur l’aspect humain que doivent avoir les relations professionnelles. L’empathie – la capacité de comprendre les gens – et la politesse – se mettre à la place des autres – sont des qualités plus qu’appréciables dans la vie de tous les jours, mais aussi au travail. L’ère des chefs d’entreprise-dictateurs est révolue. Le meilleur moyen de faire travailler une équipe est de faire en sorte que ses membres se sentent bien et apprécient de travailler en commun.

Toutefois, il existe un cas (un seul !) où l’on peut sortir de ses gonds. C’est quand on a en face de soi une personne qui, justement, n’en a rien à faire des autres. C’est un comportement détestable, qui pourtant se rencontre de temps en temps.

Commençons par analyser le cas. De manière générale, les gens sont relativement civilisés et polis. Parfois, certaines discussions peuvent s’envenimer un peu, mais les choses restent globalement à un niveau acceptable. Mais certaines personnes utilisent cet état de fait, la plupart du temps de manière inconsciente, pour s’affirmer par la force ; ces personnes savent pertinemment qu’elles prennent peu de risques à se montrer odieuses.
Prenez par exemple ceux qui mettent de la musique à fond dans les transports en commun. Ils gênent à eux seuls plusieurs dizaines de personnes, mais ils s’en moquent. Consciemment, ils se disent juste « Je fais ce que je veux » ; mais surtout, leur subconscient leur susurre « C’est bon, tu peux y aller, de toute façon personne ne va oser bouger le petit doigt ! ». Et finalement, c’est bien ce qui arrive ; tout le monde se laisse emmerder, se disant qu’il vaut mieux supporter ça 15 minutes que de chercher le conflit.
Autre exemple : Un enfant chahuteur ira chercher la bagarre avec les plus petits que lui, parce qu’il sait qu’ils ne répliqueront pas.

Dans le monde de l’entreprise, c’est pareil.

Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

(image © Avangel, Wikipedia)

  • Le directeur de produit : Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en temps que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

La diplomatie au travail

Quand on travaille en équipe, on doit apprendre à gérer les rapports humains. Nous ne sommes pas tous égaux face aux relations humaines. Certaines personnes se sentent à l’aise, d’autre non. Certaines personnes n’hésitent pas à imposer leurs vues, d’autres se mettent en retrait.

L’essentiel est de garder, en toute circonstance, un comportement qui permette de travailler efficacement. Si on peut se faire des amis au boulot, c’est la cerise sur le gâteau ; mais il ne faut pas se faire d’ennemis.

Les désaccords

Il existe un principe fondamental en entreprise : Critiquer les idées, pas les personnes

Quand on n’est pas d’accord avec les propositions de quelqu’un, il semble parfois plus facile de chercher à démolir la personne elle-même, plutôt que d’expliquer en quoi on est en désaccord. Ce n’est pas constructif, et vous attirera les inimitiés de vos confrères.

L’encadrement des juniors

L’encadrement de juniors (stagiaires et jeunes diplômés) est un sujet assez vaste, et je vais juste aborder ici un point de détail qui concerne la manière dont les entreprises abordent leur productivité.

Il existe un principe de base qui est valable pour tout le monde :
« Comprendre ce qu’on fait et ce sur quoi on travaille »

Quand on embauche une personne qui a de l’expérience, c’est souvent pour la faire travailler sur des projets assez pointus. Dans ce cas, on s’attend communément à ce que la complexité de la tâche implique un « temps de démarrage » conséquent.

Il est assez logique que les juniors, pour leur part, se voient affecter des tâches plus accessibles d’un point de vue technique. Mais de nombreuses personnes voudraient qu’un junior soit immédiatement opérationnel. La réflexion qui est faite est du style : « Ce n’est pas bien compliqué, franchement, il devrait avoir terminé dans 2 jours, non ? ».
Le problème, c’est que n’importe quel travail doit se faire en ayant une maîtrise de son environnement et de ses impacts potentiels.

On ne peut pas demander à un jeune embauché de faire du bon boulot, si on n’a pas pris le temps de le former correctement sur les méthodes et outils spécifiques employés dans l’entreprise. Même si le travail demandé semble mineur, il faut se souvenir que l’expérience du collaborateur est limitée elle aussi. Un défaut d’encadrement peut conduire à des situations désagréables. La plus commune est que le junior, après avoir travaillé 3 jours sans avoir reçu de formation interne, doit recommencer tout le travail parce qu’il n’a pas respecté les directives qu’il n’a pourtant pas eues. On voit aussi fréquemment des personnes qui commencent à modifier du code sans le comprendre, générant un nombre incroyable de bugs de régression.

La pire situation que j’ai vue, c’est une entreprise qui formait ses jeunes « à la dure » : aucune formation, directement affectés aux débuggages ! Autant vous dire que ce n’était pas très efficace…

Si vous encadrez un junior

Vous devez lui fournir toutes les informations nécessaires. On ne laisse pas les gens se débrouiller tous seuls ; cela revient à les laisser dans la merde. Prenez le temps d’expliquer les méthodes, outils et usages qui ont cours dans votre entreprise. Faites leur faire un premier projet pour se faire la main, sur lequel vous les encadrerez de très près.

Le nocif

Dans la série des billets consacrés aux types de collègues, et pour faire la suite à ceux consacrés aux affectifs et aux revendicateurs, je vais aujourd’hui vous parler des « nocifs », c’est-à-dire des personnes qui – pour une raison ou une autre – sont réellement néfastes pour une équipe ou une entreprise. Nous allons voir comment reconnaître un nocif, et quelles sont les solutions qui s’offrent à vous pour traiter leurs cas.

À quoi reconnaît-on un nocif ?

Nous avons tous cotoyé au moins une personne dont le comportement ne semblait pas correspondre à celui attendu. Cela peut toucher un assez grand nombre d’attitudes :

  • Connaissances techniques trop faible. Un développeur qui est tellement mauvais techniquement qu’il produit systématiquement du mauvais travail.
  • Problèmes d’horaires. Quelqu’un qui arrive à 11h00 le matin et part à 17h30 le soir, ou qui se prend 20 minutes de pause toutes les 45 minutes.
  • Non-implication dans son travail. Une personne qui se met dans un simple rôle d’exécutant, au lieu d’utiliser ses compétences et son imagination pour faire réellement avancer ses projets.
  • Mauvaise volonté systématique. Quelqu’un qui réfute par principe toutes les idées qui lui sont soumises, ou qui ne prend en compte que les choix qui l’arrangent.
  • Problèmes de communication. La personne qui reste dans son coin en parlant le minimum possible. La personne qui n’arrive pas à avoir un débat constructif, et s’énerve dès que ses idées ne sont pas suivies. Celui qui ramène toutes les discussions à ses propres problèmes immédiats.
  • Problèmes avec l’autorité. Quelqu’un qui n’accepte pas qu’une autre personne puisse décider de ses priorités et de son planning.
  • Comportement non professionnel. Une personne qui se permet d’insulter ses collègues. Un commercial qui tutoies les clients. Un chargé de clientèle qui n’offre pas toute l’écoute qu’li devrait.

Test Driven Development

Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.

Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.

Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.

  • On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
  • On écrit des tests pour vérifier les méthodes de l’objet.
  • On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
  • On exécute les tests unitaires, qui tombent évidemment en échec.
  • On écrit le code de l’objet, en vérifiant que les tests passent un à un.

L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.

Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.

Mon expérience

Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :

Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Sus aux emails

Il existe plusieurs méthodes de travail qui s’intéressent à la relation que nous avons avec nos boîtes aux lettres électroniques. Pour n’en citer que deux, je dirais GTD et Zero Inbox, dont le but est d’améliorer le traitement des messages que nous recevons, pour être certain de traiter convenablement les informations reçues. Ce sont des approches très intéressantes, dont je vous parlerai dans de futurs posts.

Pour le moment, je vais vous parler de quelque chose d’autre, qui concerne aussi la manière dont nous utilisons les emails en entreprise. Plus particulièrement, je vais vous expliquer pourquoi il ne faudrait jamais – jamais – échanger de documents de travail par email.

Très souvent, les gens ont tendance à s’échanger les documents (spécifications fonctionnelles, spécifications techniques, listes de choses à faire, relevés de bugs, …) par email. Ça commence par un petit document rédigé par quelqu’un sur son traitement de texte ou son tableur. Voulant que ce document soit lu et utilisé par les autres intervenants du projet, cette personne va donc le leur envoyer par email. Les destinataires vont recevoir le document, le lire, et éventuellement le modifier. Les modifications seront elles-mêmes envoyées par email à toutes les personnes impliquées. Jusque-là, c’est assez clair.

Pourtant, malgré cette clarté apparente, le vers est déjà dans la pomme. Plusieurs pièges classiques peuvent apparaître :

  • Plusieurs personnes modifient le même document, puis le renvoient. Vous vous retrouvez avec autant de versions différentes du même document. Tant que personne n’aura fait le travail de « réconciliation » pour fusionner ces versions, vous allez devoir jongler tel un acrobate.
  • Le premier document aura certainement été nommé en respectant une norme, incluant le numéro de version du document et/ou sa date de création. Mais il y a de fortes chances pour que ceux qui l’éditeront ne pensent pas à modifier le nom du fichier avant de le renvoyer.