J’ai plusieurs sociétés qui me servent comme modèles. Il y a bien sur Google (ca t’étonne Darky ?), Fog Creek mais il n’y a pas que dans l’informatique que je trouve mes modèles. Le dernier en date, c’est une société qui vend des chaussures sur Internet… Quoi de plus banal, il y a des 10ene de milliers de sites d’e-commerce rien qu’en France, comment se démarquer !

Imaginez une entreprise américaine qui rembourse elle-même 100% des soins de santé de leurs employés. Qui paye 4 semaines de formation à chaque nouvel employé qui bosseront dans leur callcenter (qui ce trouve en Amérique, dans les locaux même de la société et non pas délocalisé). Qui ensuite leur propose même de l’argent pour quitter la société ! Nourriture gratuite pour tous les employés. Et les clients ? Frais de livraison gratuits en service rapide et même possibilité de rendre les chaussures gratuitement… 365 jours après les avoir commandés ! Pour cela, dans chaque colis, ils fournissent en même temps que les chaussures un bordereau UPS prépayé pour les retourner.

N’importe quel banquier ou entrepreneur dirait que c’est du suicide. Une telle boite ne pourrait jamais gagner d’argent avec ce genre de pratiques ! Et pourtant… La société, Zappos, existe bien depuis 9 ans, et a fait près d’un milliard de dollars de chiffre d’affaire cette année… Et s’est même fait racheté par Amazon pour la modique somme de 979 millions de dollars. Pas mal pour une société d’e-commerce de chaussure !

En tant qu’entrepreneur, on lit toujours qu’il faut être innovant, faire quelque chose de jamais vu si on veut réussir. Baisser les coûts, exploiter au maximum les employés, abuser les clients, faire un maximum de pub… C’est clairement du capitalisme archaïque. Il y a un gros marché pour les entreprises qui dépensent leur argent dans le service et dans la qualité, et ce, quelque soit le domaine d’activité car les clients en ont marre d’être pris pour des lapins de 3 semaines.

Mon rêve serait de monter ou de travailler dans une entreprise ayant ce genre de valeurs ! N’hésitez pas à me contacter si c’est le cas ;-)

Je suis tombé sur un essai vraiment très intéressant donnant des conseils pour créer une startup:

http://www.paulgraham.com/really.html

Ca résume exactement la vision que j’ai sur comment créer et gérer une startups mais aussi pour créer et gérer tous projets informatiques (projets perso par exemple).

Je partage tous les points de l’article mais en tant que programmeur, je suis particulièrement sensible au point numéro 8. “Commencer avec quelque chose de minimal et itérer pour l’améliorer, les usines à gaz sont un poison”. La plus part des développeurs que je connais, bien que très compétent, ont cette fâcheuse tendance à vouloir trop en faire et finalement, laisse tomber leur projet avant même d’avoir sortie une première version ou alors mette en place des systèmes exagérément compliqués qui d’après eux servira dans le futur, peu être, un jour… si si je t’assure c’est pas une perte de temps…

A lire absolument!

Un jour en lisant mes blogs favoris, je tombe sur cet article que je vous invite à lire. Il parle de l’importance de la discipline lorsque l’on programme. Sans cela, tout part vite n’importe comment jusqu’au jour où ça devient ingérable et où les gens commencent à passer plus de temps à chercher et comprendre qu’à développer.

Il prend l’exemple des outils de source control et je ne peux qu’être d’accord avec lui… J’ai eu l’occasion de voir un bon nombre de projets utilisant des sources control et à chaque fois c’était un désastre ! Aucune discipline n’est apportée sur l’arborescence des répertoires alors que c’est la base du projet, ses fondations. Le problème principal est que personne ne s’intéresse à ce sujet, chacun met ses fichiers où il veut et s’il ne sait pas où, il va surement créer un répertoire quelque part portant son nom. Il y a ceux qui vont créer un répertoire par classe, d’autres qui vont tout mettre en vrac dans un même répertoire, après tout, on s’en fiche du moment que ça compile et que ça se lance !

Quelque chose qui m’horripile encore plus, c’est la nomenclature des noms de fichiers. Vous êtes vous déjà posé la question sur comment vous nommez vos fichiers ? En français ? En anglais ? En minuscule ? En majuscule ? Peu importe ? Pas tant que ça…

Par exemple, accepter les espaces dans les noms de fichiers peut devenir une réelle galère pour les programmeurs et peut entrainer un bon nombre de bugs.

Accepter les majuscules ne pose pas de problèmes sous Windows, car il ne fait pas la différence, mais si pour une raison quelconque vous devez faire fonctionner un outil sous Linux, alors vous allez le regretter. J’ai pu voir des projets où les règles de nommage des fichiers étaient différentes en fonction du programmeur. Il y avait des MyClass.h yourClass.h voir même des his_Class.h. Mais lors de l’inclusion dans le code avec la directive #include, les majuscules ne correspondaient pas. Ça marche très bien sous Windows mais aucune chance que ça passe sous Linux et vous êtes alors bon pour repasser sur tous les #include du code source. L’autre gros problème est pour les nouveaux programmeurs : comment peut-il s’y retrouver ? Un coup il y a un _, un autre coup non, en gros il faut apprendre par cœur le nom de chaque fichier !

Vous pouvez dire que c’est ce qui arrive fatalement quand on a une grosse équipe ou alors quand on engage des gens incompétents mais en fait non. Regardons ce projet développé par 2 programmeurs talentueux et expérimentés qui viennent de créer un studio ensemble dans le but de réaliser le projet de leurs rêves. Le projet a commencé il y a moins d’un an, et ils ne sont que 2. Ils s’amusent à afficher leurs commits alors profitons-en pour essayer de trouver les règles de nommage des fichiers et répertoires qu’ils ont mis en place :

• Règle 1: Nommage des répertoires et des code sources : une majuscule pour la première lettre de chaque mot et le reste en minuscule.


• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _.


• Règle 3: Nommage des répertoires des assets graphiques: c’est la que ça se complique… Il semblerait que ça soit la règle 1 pour les 2 premiers répertoires, puis la règle 2 pour les répertoires suivants.

• Règle 2: Nommage des assets graphiques : tout en minuscule avec les mots séparés par des _ ou des - en fonction du sens du vent (où tout autre paramètre aléatoire).

• Règle 1: Nommage de tous les fichiers et tous les répertoires : uniquement des caractères alphanumériques en minuscule, les mots étant séparés par des _. Pour les geeks, on peut résumer ça en [a-z0-9_]+


• Règle 2: pas de règle 2…

Honnêtement, je ne pense pas que plus de 5 % des entreprises savent recruter des programmeurs. Depuis que je suis dans la vie active (une demi-douzaine d’années), je n’ai dû en croiser qu’une qui savait vraiment bien le faire, qu’une ou deux où il y avait de l’idée et tout le reste, c’était du grand n’importe quoi.

Tout d’abord, il faut définir ce qu’est un “bon programmeur”. Selon moi, avoir un diplôme reconnu n’est pas un critère, connaître par coeur les puissances de 2 jusqu’à 2 puissance 32 non plus. Je définirais un bon programmeur comme quelqu’un d’extrêmement curieux, qui maîtrise ce qu’il fait, qui a une très bonne capacité d’écoute et de résolution de problèmes techniques. Il doit aussi être capable de se remettre en question, aimer travailler en équipe et être capable de finir ce qu’il commence.

Dans les 95 % des entreprises, on est confronté à l’un de ces scénarios :

- Si l’entreprise a de la chance, quelques bons ingénieurs vont être recrutés par erreur et se retrouveront au milieu d’une grande majorité d’ingénieurs qu’ils trouveront incompétents. Ces bons ingénieurs ont toutes les chances de vite quitter la société, car un bon ingénieur a besoin de trouver dans son environnement de travail des gens au moins aussi bons que lui. La société ne se retrouvera donc rapidement plus qu’avec des ingénieurs de niveau moyen ou mauvais et cela reviendra au cas suivant.

- Si l’entreprise n’a pas de chance, elle ne recrutera que des ingénieurs moyens ou incompétents. Pour que cela fonctionne quand même un minimum, la solution choisie est souvent de les encadrer de très près par des managers. Le problème est que ces managers n’ont aucune raison d’être mieux recrutés que les ingénieurs et donc sont du même niveau de compétence. Il faut alors mettre en place une énorme hiérarchie où tout le monde surveille tout le monde et où personne n’ose plus rien faire de peur de se faire taper sur les doigts par son chef… Dans ces entreprises, les managers mettent alors en place des méthodologies très lourdes et complexes avec beaucoup de paperasse, de planning, etc., pour essayer de se protéger en cas de problème et pouvoir rejeter la faute sur quelqu’un d’autre. On pourrait croire que ce genre de scénario n’arrive que dans les grosses sociétés, mais j’ai pu rencontrer des PME avec ce schéma (par exemple 6 ingénieurs pour 4 managers). Autant dire tout de suite, dans ces entreprises, les ingénieurs n’ont aucune reconnaissance. Ils sont vus comme le bas de l’échelle, les ouvriers, les moins bien payés, ceux qui sont à l’origine de tous les problèmes (retards, bugs, mauvaise qualité, …). Ils sont souvent considérés comme des gens qu’on peut remplacer comme on remplacerait une roue sur une voiture. Bref, il est évident que l’effet le plus indésirable de cette organisation est que l’ingénieur se trouve à détester sa position et va tout faire pour, soit partir, soit monter dans la hiérarchie pour gagner plus d’argent et arrêter de se sentir un moins que rien. Évidemment, on va vite se retrouver avec une énorme compétition entre ingénieurs, car le nombre de place de chef est inférieur au nombre de place d’ingénieur (enfin normalement). Ca crée alors des conflits d’intérêts, des histoires politiques entre équipes et les ingénieurs passent plus de temps à essayer de bien se faire voir par leurs chefs plutôt qu’à faire du bon code. Autre problème, c’est l’organisation idéale pour rencontrer le principe de Peter.

Dans ce genre d’entreprises, passer aux méthodes agiles où n’importe quelle autre méthode ne servira à rien, car c’est un problème de fond, un problème culturel où seule une prise de conscience de la part du boss peut prétendre à une amélioration. Mais même dans ce cas, il serait très long et très compliqué de faire des changements de fond, car cela nécessiterait forcément des licenciements, de remettre des managers en programmeurs et souvent les esprits sont trop habitués à la culture de leur entreprise et considèreraient ça comme un affront. Bref, je ne pense pas que ça soit réellement possible de changer une culture d’entreprise, car les personnes sont recrutées en général parce qu’ils partagent justement cette culture.

Maintenant, prenons le cas des 5 % restants (et encore, je crois que je suis gentil, je dirais plutôt 1 %), ce sont des sociétés où le recrutement est une partie primordiale et ils feront tout ce qui est nécessaire (ne pas céder à la pression, mettre les budgets et le temps nécessaire) pour ne pas laisser entrer dans leur société des individus qui ne correspondent pas. L’idée de base est la suivante : “On ne recrute que des gens vraiment intelligents, ou on ne recrute pas.” Dans ce genre de société, le recrutement est permanent et maximal. Permanent, car ces ingénieurs vraiment intelligents sont difficiles à trouver et souvent déjà en poste, si on ne recrute que 2 mois dans l’année, la probabilité de tomber dessus est très faible. Maximal, car pour être vu par les meilleurs, il faut se faire voir. C’est exactement la même chose que pour vendre un produit à un client sauf que dans ce cas, le produit c’est la société et le client est l’ingénieur talentueux. Et comme ils savent qu’ils sont bons, ils sont difficiles et veulent aller dans des sociétés où ils se sentiront vraiment bien. Comment réussir toucher ce genre de personnes mériterait un sujet à part entière (JoelOnSoftware en à déjà parlé). Cela n’est pas gratuit, ça coûte même cher à une entreprise aussi bien en temps (car il faut des gens pour faire passer les entretiens) qu’en argent. Mais c’est un investissement qui sera extrêmement rentable sur le long terme.

Une fois que vous avez réussi à attirer les meilleurs, il faut savoir faire le tri et c’est là qu’intervient l’entretien. Comment faire passer un bon entretien ? Encore une fois, ça mériterait un article complet (vous pouvez lire ça).

Supposons que la structure est en place pour ne recruter que des bons ingénieurs, qu’est ce que ça change ? Tout d’abord, vous pouvez avoir une confiance beaucoup plus importante dans ces personnes. Vous n’avez pas à fliquer leurs horaires de travail (ils en feront même surement beaucoup plus que la normale sans même le demander), à vérifier s’ils bossent vraiment ou s’ils se tournent les pouces, etc. Bref, vous pouvez alléger au maximum la hiérarchie. Du côté des ingénieurs, ils sont beaucoup plus contents, car ils sentent qu’on leur fait confiance, ils sont beaucoup plus libres et le résultat est qu’ils bosseront beaucoup mieux et qu’ils ne voudront pas aller voir ailleurs. En plus, ces ingénieurs se retrouvent avec d’autres bons ingénieurs, ils se comprennent, s’entraident, se respectent plus facilement. Ils ne vont pas se prendre la tête pour savoir s’il faut mettre des espaces ou des tabulations, s’il faut faire des tests unitaires ou pas, car ils sont assez intelligents et ont assez d’expérience pour savoir ce qu’il en retourne et où se situent les vrais problèmes.

Donc dans ces sociétés, la hiérarchie est réduite à son minimum, il y a des ingénieurs qui programment, des lead ingénieurs qui sont aussi très techniques, mais qui peuvent facilement gérer 10 à 20 personnes, car les méthodes de travail peuvent elles aussi être très simplifiées. Pour que cela fonctionne, il faut évidement savoir mettre l’argent où il faut, par exemple ne pas lésiner sur les locaux, les ordinateurs, les tables, chaises, etc. Plus l’environnement sera agréable, plus il y a de chances que l’ambiance y soit bonne et donc que les gens y travaillent bien.

Ça peut paraître simple de mettre en place ce genre d’équipes, mais ce n’est clairement pas le cas. Tout d’abord, les lois de la concurrence, la pression des investisseurs, le manque d’ingénieurs sur le marché du travail font que les boss ont souvent tendance à vouloir recruter au plus vite, quitte à ne pas suivre la règle de base en pensant qu’après tout, ce n’est pas si grave que ça, on verra plus tard. Au début, ça marche bien, car la boite est petite, mais au fur et à mesure que des personnes peu compétentes arrivent, les problèmes arrivent par la même occasion et l’entreprise tombe dans les 95 %. L’autre problème est que les fondateurs/boss ont beaucoup de mal à mettre de l’argent sur quelque chose qui n’est pas rentable à très court terme (le problème du bûcheron). Ils prendront les chaises premier prix qui font mal au dos sans penser que derrière cela augmentera le turn-over (qui veut passer 8 heures ou plus sur une chaise inconfortable?) qui au final coûtera beaucoup plus cher que d’avoir mis des fauteuils corrects dès le début (l’exemple de la chaise vous parait peut-être exagéré pourtant c’est du vécu et des histoires comme celle-là, j’en ai vu tellement d’autres…).

Le meilleur exemple d’entreprise qui utilise la 2ème méthode est Google. Bizarrement, ils sont devenus la boite la plus recherchée par les ingénieurs et c’est aussi une société qui fait beaucoup d’argent. Je suis convaincu que leur réussite tient d’abord à leurs méthodes de recrutement et leur culture d’entreprise. Je suis aussi convaincu que même s’ils n’avaient pas eu l’idée de faire un moteur de recherche ou un business sur Internet, ils auraient obtenu un résultat similaire dans une autre industrie.

Vous allez me dire que c’est facile pour eux, ils ont énormément argent, mais ils ont commencé à moins de 10 personnes et ont tout bâti eux même. C’est avant tout leur façon de construire la société (et donc l’équipe) qui leur a permis d’arriver là où ils sont aujourd’hui.

Un autre exemple d’une entreprise qui suit ces principes est FogCreek. C’est une petite société qui ne fait que grossir, doucement, mais sûrement. Ils ont un peu la même philosophie que Google, mais avec seulement une 20aine de personnes. Cette boite a toujours été rentable. Ils suivent la règle d’or qui dit que si on recrute les bonnes personnes, quel que soit le projet qui sera choisi, il sera rentable. Et ils le prouve par exemple avec leur bugtracker. Il existe des 10aines de bugtracker différents, dont beaucoup de gratuits, mais bien que le leur soit payant il se vend bien et suffit pour faire vivre la société.

Tout ça pour dire que le processus de recrutement commence dès les premiers jours de la vie d’une entreprise et que de mauvaises méthodes de recrutement risquent d’entrainer par la suite de gros problèmes qui ne pourront pas être rattrapés. Malheureusement, c’est aussi la période où il y a tellement de choses à faire que le recrutement des programmeurs peut être mis au second plan où alors les conséquences du choix de mauvais programmeurs sont clairement sous-estimées.

Je rêve un jour de pouvoir rencontrer des créateurs d’entreprises français assez ouverts pour pouvoir comprendre l’intérêt et le potentiel énorme de ces nouvelles façons de construire et gérer une société informatique. Si vous pensez en être un, n’hésitez pas à me contacter, je serais ravi d’en discuter plus longuement !

Demandez à un Québécois ce qui le dérange le plus chez les Français et il vous répondra en premier que les Français sont prétentieux, le fameux Maudit Français. En deuxième viendra le fait que les Français sont tout sauf pragmatique.

En caricaturant un peu, si on demande à un Québécois de construire un barbecue, la première chose qu’il fera sera d’aller chercher des tôles et de les arranger ensemble. Le Français va d’abord réunir un groupe de travail pour discuter de quoi ils vont discuter pendant les prochaines réunions qui détermineront quand faire les réunions pour écrire la documentation qui expliquera comment organiser les réunions !

Un mois plus tard, le Québécois aura un tas de tôle qui permettra de se cuire des saucisses et le Français aura une pile de documents qui permettront sans risque et rapidement de fabriquer le barbecue…

Quand des Québécois et des Français travaillent ensemble, le premier est exaspéré de voir le nombre de réunions, de discussions, de documents produits et le peu de temps à réaliser réellement le produit demandé. À l’inverse, le Français est exaspéré de voir le Québécois foncer tête baissée dans le projet sans même réfléchir aux risques, processus, méthodes, qu’il risquent de rencontrer.

Si je devais choisir entre ces 2 extrêmes, je choisirais surement la solution Québécoise, car au bout du compte on a quelque chose de concret à montrer qui a une réelle valeur pour le client.

Évidemment, la meilleure solution serait un mixe des deux et c’est exactement ce que prônent les méthodes agiles. Malgré ce que pensent beaucoup de monde, elles ne consistent pas à foncer tête baissée sans réfléchir, mais proposent d’avancer concrètement sur le projet jusqu’au moment où un problème survient, alors, à ce moment-là, l’équipe entière se pose autour d’une table pour trouver une solution. Tout le problème est donc de mettre en place des pratiques pour détecter facilement l’apparition des problèmes au cours du projet.

Pourquoi devoir faire des réunions pour trouver une solution à un problème qui n’existe même pas au moment où on fait cette réunion ? À moins d’êtres réellement voyants, vous n’avez aucune idée de quels problèmes se produiront réellement pendant votre projet.

En utilisant cette méthode, il sera facile aux anti-agilistes de dire au moment où un problème est détecté “Ah !! Vous voyez, je vous l’avais dit il y a 6 mois que vous aurez ce problème et maintenant on va mettre 2 fois plus de temps pour le résoudre que si on avait réfléchi à ce problème dès le début “. En effet, ça sera surement plus long à régler, mais à côté de ça, combien de réunion et de mise en production de solutions plus ou moins lourdes pour des problèmes qui ne se sont jamais produits ont été évités.

Ce pragmatisme s’applique à tous les niveaux, aussi bien pour le code (éviter de faire de l’overdesign) que pour le management. Pourquoi planifier des réunions pour faire communiquer les programmeurs entre eux s’il n’y a pas de problème de communication ? Même si sur un précédent projet, ce problème se posait, aucun élément ne permet d’affirmer de façon certaine que ça se reproduira. Les projets ne sont pas les mêmes, les équipes non plus, etc.

Dans le développement logiciel, il existe des milliers de problèmes qui peuvent se produire lors d’un développement. Mais vous ne saurez jamais à l’avance lesquels de ces milliers de problèmes tomberont sur votre prochain projet. Il est illusoire de croire que vous pourrez lister et prévoir tous les problèmes donc autant mettre en place des moyens de les détecter quand ils arriveront et de prendre le temps de les résoudre dès qu’ils apparaitront. Alors, profitez du fait que vous n’ayez pas de problème aujourd’hui pour avancer sur votre projet plutôt que vous prendre la tête à résoudre des non-problèmes !

Pour résumer simplement la démarche agile :

• L’équipe développe le projet jusqu’au moment où quelqu’un lève un problème.


• L’équipe se réunit pour exposer le problème et trouver une solution.


• L’équipe applique la solution et reprend le développement.


• À la fin de l’itération (une ou deux semaines), lors de la réunion de rétrospective, l’équipe se demande si la solution a bien résolu le problème. Si la réponse est oui, alors l’équipe continue à appliquer la solution. Si la solution n’a pas fonctionné, l’équipe se réunit pour trouver une nouvelle solution, l’applique pendant une itération, refait une rétrospective et ça boucle jusqu’à ce que le problème soit résolu.

« J’en ai marre, je vais devoir encore donner de l’argent à ce voleur qu’est l’État français, car je me suis fait flasher par un de ces maudits radars automatiques ! »
À chaque fois que j’entends ce genre chose, ça m’exaspère… pas vous ? Le jour où l’État a décidé de mettre des radars automatiques en France, je me suis dit : « c’est vraiment idiot de mettre des radars, les gens ne sont pas des hors-la-loi, ils connaissent très bien les limites de vitesse et donc les radars ne flasheront jamais ! »… Non c’est pour rire, je ne suis pas si naïf quand même ;-) En fait, je me suis dit « Puisque tout le monde sait qu’il y a un radar à cet endroit, qui serait assez bête pour dépasser la limite ? L’État ne se ferra jamais d’argent avec ça… » Comme il est clair que l’État gagne de l’argent, c’est que je me suis trompé, j’en déduis que les gens sont trop bons et qu’ils font exprès de faire des excès de vitesse pour donner de l’argent à ce pays qui en a tant besoin, car je ne vois pas d’autres explications !

Bon, que les gens n’arrivent pas à maîtriser leurs véhicules, ça m’est égal (sauf quand je suis sur la route). Ce qui est vraiment étonnant dans l’histoire c’est qu’on est très fort pour critiquer, mais seulement quand il s’agit de critiquer les autres… Quelqu’un s’est fait flasher ? C’est la faute de la voiture, du radar qui n’a rien à faire là, de l’État qui s’acharne sur lui, du vent-qui-était-trop-fort-d-habitude-ça-passe, de l’inclinaison de la route, du régulateur de vitesse, du tachymètre qui est biaisé… Je n’ai jamais entendu quelqu’un dire « j’ai fait une erreur, j’ai mal géré la vitesse de mon véhicule et je me suis fait flashé, ça me servira de leçon »… Pourtant, ce n’est pas la loterie, il y a bien un humain derrière la voiture qui a fait une erreur, volontairement ou involontairement, mais il est le seul responsable de ce qui lui est arrivé, il ne peut s’en prendre qu’à lui même. Alors, pourquoi reporter la faute ?

La vraie raison c’est que les gens n’aiment pas être pris en flagrant délit quand ils font quelque chose de pas bien. Et quand cela arrive, ils font tout pour rejeter la faute sur l’outil qui a permis ce flagrant délit plutôt que d’accepter l’erreur, de trouver un moyen pour que ça n’arrive plus et de passer à autre chose. Malheureusement, depuis notre plus tendre enfance, une erreur est synonyme de punition, donc on développe des moyens de plus en plus élaborés pour ne plus se faire prendre et donc de cacher au maximum les erreurs que l’on peut faire plutôt que de les assumer. Dans ce paradigme, il est tout à fait normal et compréhensible que les ingénieurs aient peur de prévenir leurs chefs quand quelque chose va mal. Il va tout faire pour enterrer le problème en espérant qu’il ne sera jamais vu et si cela arrive, trouver un bouc émissaire. Pire, quand quelqu’un se risque à montrer qu’une personne a fait une erreur, cette dernière se braque, n’accepte pas et fait la gueule ce qui aura pour conséquence de créer une mauvaise ambiance. Les problèmes cachés s’accumulent au fur et à mesure jusqu’au jour où cela devient trop gros et que tout explose à la figure et quand ça arrive, il est souvent trop tard pour réagir.

Les méthodes agiles proposent de casser ce paradigme du « pas vu, pas pris, pas de punition » en mettant en place le maximum de moyens pour détecter les problèmes au plus tôt. C’est à la fois très simple et très compliqué. Simple, car il existe des 10ène de techniques faciles à appliquer pour détecter les problèmes comme les dessins sur les murs. Mais c’est aussi très compliqué, car si vous faites uniquement cela, vous avez toutes les chances pour que ça ne marche absolument pas, car tout le monde restera dans le même état d’esprit erreur=punition. Pour que les développeurs osent parler de leurs erreurs, il faut une relation de confiance, du courage et qu’ils se sentent soutenus. Et ce n’est pas les beaux graphiques sur le mur qui vont les aider. Malheureusement, il n’y a pas de secrets, pour créer cet environnement de confiance, il faut du temps et surtout de la volonté… Beaucoup d’entreprises pensent que pour faire de l’XP, il suffit d’acheter un livre sur le sujet, appliquer les pratiques et c’est gagné ! Alors, ils le font, se rendent compte que ça ne marche pas et disent que XP c’est nul ! Les pratiques aident à créer un climat favorable, mais avant tout il faut une réelle remise en question de la part de chacun des membres du projet ; les développeurs, les managers, les clients. Sans cela, l’équipe ne sera jamais agile. À l’opposé, il existe des sociétés qui ne connaissent pas forcément XP, mais qui sont réellement agiles. L’agilité ne s’obtient pas en appliquant bêtement des pratiques, l’agilité c’est avant tout un état d’esprit, une philosophie, une façon de concevoir et de travailler.

J’ai vécu des situations où lorsqu’un problème était détecté, non seulement on n’en parlait pas à la personne qui en avait été la cause, mais la décision prise en conséquence était tout simplement de virer cette personne ! À l’opposé, il existe des sociétés, comme Google (étonnant comment on parle toujours des mêmes boites) qui, lorsqu’un employé a commis une erreur qui a couté des millions de dollars, on la félicite.

Pour qu’une entreprise informatique réussisse, elle doit prendre des risques. Les employés doivent donc prendre des risques à leur tour. Qui dit prendre des risques dit commettre des erreurs. Alors comme on sait que des erreurs seront faites quoi qu’il arrive, autant se donner tous les moyens possibles pour les détecter au plus vite afin d’y faire face.



Une bonne équipe n’est pas une équipe qui ne fait pas d’erreurs, mais une équipe qui est capable de les détecter rapidement et de les résoudre intelligemment…

Vous avez déjà remarqué? Un ingénieur passe en gros 22 ans de sa vie à apprendre non-stop lors de sa formation et une fois dans le monde du travail… C’est souvent le néant!

Je suis effaré de voir le peu de gens qui essaient d’aller plus loin que juste faire ce qui est demandé par leur boulot. En 6 ans de vie professionnelle dans l’industrie du jeu vidéo, le nombre de collègues qui s’instruisent doit tenir sur les doigts de mes mains. Quand je dis “s’instruisent”, je parle de personnes qui vont essayer d’améliorer leurs connaissances, que ca soit dans le domaine où ils travaillent ou dans tout autre domaine s’y rapprochant directement ou indirectement. Ca peut être en lisant des blogs, en discutant avec d’autres personnes, en lisant des livres… Ce n’est pas les sources d’informations qui manquent.

Je vous entends dire en ce moment même, “franchement, je n’ai pas le temps et puis mes connaissances actuelles sont suffisantes pour le boulot que je fais et en plus, rien ne vaut l’expérience vécue”. Bon, prenons les points un par un:

• Encore cette histoire de “pas le temps” ! Ce n’est pas un argument valide et je l’ai déjà expliqué. Qu’est-ce que vous faites dans le métro pour aller au boulot ? Vous ne pourriez pas lire un livre qui vous apprendra quelque chose plutôt que regarder les filles qui passent, lire un manga, faire un sudoku ou alors jouer avec votre Nintendo DS ?


• Comment pouvez-vous croire que vos connaissances actuelles sont suffisantes? Vous pensez tout connaître du langage que vous utilisez? Si vous faites du C++, vous savez ce qu’est la délégation croisée ? Si vous êtes dans cet état d’esprit où vous pensez que vous n’avez plus rien à apprendre dans le domaine où vous évoluez c’est que soit vous êtes de mauvaise foi, soit vous êtes un des ces cowboy programmers prétentieux qui pense tout savoir, soit vous êtes idiot ! Il y a toujours quelque chose à apprendre afin de s’améliorer. Ce qu’on apprend n’est pas toujours applicable dans le futur proche mais augmenter ses connaissances ne peut être que positif.


• Il est clair que l’expérience personnelle est importante et a beaucoup de valeur. Plus on a vécu d’échecs et de succès, plus on est capable d’appréhender les futurs problèmes. Mais au mieux, vous aurez 50 ans d’expérience dans votre vie, ce qui n’est vraiment pas beaucoup quand on voit le nombre de personnes sur terre et le nombre de générations qu’il y a eu avant vous. Bien sûr dans cette masse de gens, il y a beaucoup d’expériences qui ne vous sont pas utiles, mais il suffit qu’il y ait d’autres personnes qui travaillent dans le même domaine que vous, ou dans un domaine similaire pour que leur expérience ait sûrement de la valeur pour vous. Et même s’il n’y a que 10 personnes, cela représente déjà énormément plus que votre seule expérience. D’autant plus que très souvent des gens ont déjà fait ce que vous faites et ont déjà essuyé les plâtres, alors pourquoi vouloir à tout prix risquer de les reproduire ? Je pensais que vous n’aviez pas de temps à perdre ?

Combien de fois vous vous êtes dit que votre chef était un incapable ? Vous pensiez être le seul ? Et bien non, et pire encore, ce problème existe depuis longtemps très longtemps et ne s’est pas amélioré avec le temps. Un certain Laurence J. Peter à travailler sur ce sujet en… 1968 (c’est triste de voir à quel point c’est encore d’actualité de nos jours !) et a publié un article connu sous le nom du principe de Peter et tourne autour de cette phrase : « Dans une hiérarchie, tous les employés tendent à atteindre leurs niveaux d’incompétence ».

Voici résumé, comment, dans beaucoup d’entreprises, cela se passe :

Une personne est un à poste A, si elle est bonne, elle aura forcement une promotion un jour ou l’autre et passera à un poste B qui contiendra de nouvelles choses qu’elle ne maîtrisera pas forcement. Si elle arrive à les maîtriser, alors elle aura de bon résultat et elle aura une autre promotion pour passer à un poste C. Ainsi de suite elle va monter dans la hiérarchie jusqu’au jour où elle arrive sur un poste qu’elle n’arrive plus à gérer car elle a atteint ses limites de compétence. Ayant de mauvais résultat, elle n’évoluera plus dans la hiérarchie et stagnera à son denier poste, celui qu’elle n’arrive pas à maîtriser.

Ce stade d’incompétence arrive plus ou moins haut dans la hiérarchie, et au final, dans une société, on tend vers une limite où tout le monde atteint son niveau d’incompétence et donc plus rien ne fonctionne correctement.

La question est alors : Pourquoi les gens sont ils poussés pour monter en grade, au risque de devenir incompétent et être malheureux ?

Plusieurs raisons à cela ; d’une part pour la reconnaissance. C’est triste à dire mais, dans notre société, plus on est haut en hiérarchie, plus on est bien vu par les autres. Un patron est toujours mieux vu qu’un simple ouvrier. Le patron est plus respectable, même si il est le pire des pourris et si l’ouvrier est un employé modèle. D’autre part, c’est pour une raison de salaire ; Pour gagner plus d’argent, il faut monter dans la hiérarchie. Oui, il est possible d’être augmenté en gardant son même niveau hiérarchique mais c’est souvent sans commune mesure avec l’augmentation entraînée par une monté d’un échelon.

Le vrai souci réside donc le fonctionnement même de la société. Je connais beaucoup de très bons programmeurs qui ont été obligés d’encadrer d’autres programmeurs, non pas parce qu’ils aimaient ça, mais parce que c’était pour eux la seule chance de gagner plus d’argent et d’être mieux vu, car un Lead programmeur est mieux qu’un programmeur (ah bon ???). Le très bon programmeur passe alors de plus en plus de temps à ne pas programmer (ce qu’il faisait très bien et qu’il aimait faire par dessus tout) pour gérer son équipe (ce qu’il n’a jamais appris à faire et qui ne l’intéresse d’ailleurs pas du tout). Le résultat est simple, en faisant ça, l’entreprise à non seulement perdu un bon programmeur mais dispose en plus d’un incompétent qui n’est plus motivé par ce qu’il fait…

Comment faire pour éviter ça me direz-vous ? Et bien c’est très simple et certaines sociétés l’ont très bien compris, comme Microsoft ou Google qui n’ont rien à prouver en ce qui concerne leurs réussites. Déjà, il faut laisser les gens là où ils sont les meilleurs et les mettre en valeur. Un programmeur n’est pas moins bien qu’un chef de projet, non ! C’est 2 jobs différents qui demandent des compétences différentes. Si un programmeur est bon, alors laissez le programmer, payez le à sa juste valeur et ne lui demander pas d’encadrer d’autres personnes si ça ne l’intéresse pas. Créez des grilles de salaires non pas en fonction de la hiérarchie comme c’est souvent le cas mais en fonction de l’expérience sur chaque poste ; oui un programmeur peut avoir un salaire 2 ou 3 fois plus élevé que celui de son chef si ce programmeur est un expert et si le chef débute. Il n’y a rien de malsain, tout le monde peut le comprendre et l’accepter si c’est dans la culture d’entreprise. Le salaire est directement lié aux compétences de la personne et non uniquement au poste qu’il occupe dans la hiérarchie.

Si vous voulez en savoir plus sur le principe de Peter, lisez cette page web.

Lors d’une réunion Extreme Programming (XP) à Paris, nous avons pu participer en avant première à un tutorial présenté quelques temps plus tard à la conférence Agile 2006. Le sujet était « Ecrire sur les murs » , un des sujets polémiques d’XP. Pourquoi polémique ? Car il est difficile aujourd’hui de faire comprendre aux gens que des outils aussi simplistes que le papier et le crayon peuvent avoir un impact plus important que les outils électroniques comme Microsoft Office.

Un radiateur d’information est l’affichage d’informations sur un mur afin que tout le monde puisse voir l’information en un coup d’œil. Pas besoin d’ouvrir un mail perdu ou un document Word planqué au fin fond d’un répertoire réseau que de toute façon personne ne regarde car l’écran est trop petit pour afficher correctement le document. L’information est visible sans devoir la chercher.

Ce workshop avait pour but de présenter différents types d’informations que peuvent contenir ces radiateurs d’informations.

Taskboard

Le plus classique est l’affichage de la progression de l’itération. En XP, le projet est coupé en itérations fixes d’une durée de une à trois semaines selon les projets et chaque fonctionnalité est écrite sur une fiche bristol ou, dans notre cas, sur un post it.

L’information à disposer en permanence sous les yeux est donc l’avancement de l’itération en cours. C’est ce que l’on peut voir sur l’image suivante où les 3 colonnes contiennent les fonctionnalités « À faire », « En cours » et « Fait ».



Evidement, un des avantages de ce mur est qu’il est très facile de maintenir les informations à jour, lorsqu’une tâche est faite, il suffit de la déplacer d’une colonne à une autre. Tout le monde voit l’avancement de l’itération et sait donc si tout se passe bien ou pas.

PPP: Project Progress Poster

Le 2ème système propose d’afficher la planification pour les N itérations du projet, le but étant d’avoir une vision plus globale du projet et de son avancement.

Sur l’imagine suivante on voit les 6 itérations que comporte le projet avec les différentes fonctionnalités implémentées ou à implémenter. On remarque que la colonne 3 est vide ; c’est normal car c’est l’itération en cours, les post-it ont donc été déplacés sur le mur précédent. On voit en un coup d’œil où l’on en est dans le projet et ce qu’il reste à faire et si cela rentre.



Le dessin en rouge en bas à droite de l’image est un autre type d’information qui a été fait après le workshop. Le but est de dessiner un tableau avec différents critères pour le projet et de laisser le client mettre des croix comme il le souhaite en sachant que plus la croix est à droite, plus le critère est important. La seule contrainte pour le client est qu’il ne peut pas mettre 2 croix dans la même colonne (le tableau de l’image est buggé). Le but de ce tableau est de faire comprendre au client qu’il faut faire des choix et que l’on ne peut pas tout avoir ; mettre la qualité en avant augmente forcement les délais. C’est le client qui choisit pour son projet ce qu’il veut mettre en avant.

BDC: Burn Down Chart



Le dernier type de dessin sur les murs de ce tutorial est le Burn Down Chart. C’est un graphe qui représente la progression du projet dans le temps. En abscisse, on retrouve les itérations et en ordonné on peut soit afficher la valeur restante au projet (c’est-à-dire la somme des valeurs de chaque fonctionnalité restant à implémenter) ou alors la somme des valeurs réalisées depuis le début du projet (courbe montante). Dans le premier cas, la courbe descend jusqu’à atteindre le 0 (on a fini le projet). Ce genre de graphe est très intéressant car montre comment évolue le projet dans le temps. Il permet de détecter les ralentissements de production ou tout autres anomalies. Lors de la planification en XP, on a tendance à développer en premier lieu les fonctionnalités qui apportent le plus de valeur le plus rapidement. Forcement à la fin du projet, il ne reste plus que des fonctionnalités longues à développer et qui n’apportent pas beaucoup de valeur. La courbe va présenter de façon visuelle ce choix ; Plus le projet avancera et moins il y aura de valeur ajoutée en une itération et donc plus la courbe sera plate.

Une variante de ce graphe consiste à utiliser l’axe des ordonnées la valeur réalisée pour chaque itération (et non pas la somme). On pourrait imaginer que cette courbe sera stable au court du projet mais en réalité ce n’est jamais le cas. Ce graphe permet alors de détecter rapidement un problème, pourquoi a-t-on fait moins de valeur dans cette itération que d’habitude ? Ca peut être pour des centaines de raisons ; l’arrivée d’un nouveau, la fatigue de l’équipe, les tâches annexes qui prennent de plus en plus de temps (code difficile à maintenir et faire évoluer)… La courbe peut aussi monter ce qui signifie que l’équipe avance plus vite et donc que le projet pourra finir plus tôt ou que l’on pourra implémenter plus de fonctionnalités.

Il existe beaucoup d’autres types d’autres informations que l’on peut afficher sur les murs, voici quelques photos prisent dans des projets réels.

Je vais vous raconter une histoire étonnante :

« Il était une fois un programmeur dans une entreprise qui programmait gentiment sur son PC jusqu’au jour où BAM, plus rien, le PC ne démarre plus… Pas grave, il contacte son admin préféré et il lui demande de regarder ça. Rapidement il détecte que c’est le disque dur qui est cassé. Pas de problème, il suffit de le changer ! Oui sauf que voilà, il n’y a pas de disque dur en réserve. Et pour en commander un autre, ça va prendre du temps car il faut passer par un fournisseur spécial. Alors la solution ? Reformater le disque dur défectueux en invalidant les secteurs défectueux, comme ca plus de problème… Après 1 jour et demi de réinstallation, le programmeur peut reprendre la programmation… avec une sacrée épée de Damoclès sur la tête… »

Vous pensez que c’est une histoire purement imaginaire ? Eh bien non, loin de là, cette histoire est bien réelle , Et oui!

Faisons un rapide calcul :

• 1 disque dur : 100 Euros (encore moins si on retire la TVA)


• 1 programmeur pendant 1 jour et demi : 375 Euros (en comptant les charges patronales)

• Elles n’ont plus d’argent (raison acceptable mais dans ce cas il faut fermer la société tout de suite, car si elles ne peuvent pas acheter un PC, elles ne pourront pas jamais payer le loyer ni les employés)


• Elles n’ont pas le temps pour s’occuper de ça (très mauvaise raison)


• Parce que faire des stocks, ça coûte cher (faux : ca coûtera toujours moins cher quand le problème arrivera, et il arrivera forcement)