Voici une adaptation de la présentation que j’ai donné en octobre 2010 à la conférence Soft-Shake, pour l’ouverture. La présentation dure environ 25 minutes. Comment rendre notre métier passionnant ? Quelles sont les ingrédients d’une équipe qui s’amuse ? Suivez le guide !
Cliquez sur chacune des images pour les afficher en grand
La présentation est aussi disponible sur SlideShare
Bonjour à tous
Avouez qu’inviter un Touilleur à une conférence où le logo est un cocktail, c’était un signe.
C’est avec beaucoup de plaisir que j’ouvre ce matin la conférence Soft-Shake. L’idée de regrouper la communauté Agile, la communauté IPhone et la communauté Java est excellente. C’est vraiment une journée de mélange, une vraie journée de cocktail.
Un cocktail réussi, que ce soit dans le cadre de la réalisation d’un projet informatique ou d’un vrai cocktail, repose sur le mélange équilibré de plusieurs ingrédients.
Pour vous parler de passion, qui est finalement l’ingrédient le plus important, il faut tout d’abord regarder les autres éléments nécéssaire à la réalisation d’un projet informatique. Nous reviendrons sur le fruit de la passion dans quelques minutes.
Aujourd’hui nous allons parler Agilité, Java et d’iPhone. Plus largement de développement logiciel.
J’aimerai vous présenter l’un des premiers ingrédients de la recette du développeur passionné : «le pouvoir de la communauté». Cet ingrédient est représenté par vous aujourd’hui à Soft-Shake.
Pour moi en février 2008, lorsque j’ai participé à la première soirée du Paris JUG, ce fut le coup de foudre. Je venais de trouver ce que j’avais envie de faire. Discuter et échanger avec d’autres passionnés. Avoir la possibilité de rencontrer les développeurs des logiciels que j’utilise chaque jour. Mais surtout, c’était un moyen de rencontrer des gens en dehors de mon cadre professionnel, qui n’avaient pas les mêmes aspirations que mes collègues.
J’ai découvert des gens ouverts, passionnés, entiers. C’est certainement l’un des points les plus importants, qui explique ce matin ma présence devant vous. Si j’etais resté un auteur de Blog derrière mon écran, je pense que je n’aurai pas fait autant de rencontres.
La communauté dans le monde Java est un formidable levier. Il y a 10 ans nous nous intéressions au langage Java. Il y a 5 ans nous nous intéressions au projet open-source autour de langage. C’est seulement depuis quelques années que nous nous intéressons aux gens qui utilisent ce langage. Et je suis très heureux de voir que dans le monde de l’iPhone, les gens ont l’idée de s’associer et de se rencontrer. Je suis très heureux de voir des Agilites organiser des événements et proposer de se rencontrer comme lors des XP Days.
Bref vous l’aurez compris, le premier ingrédient de ma passion, c’est la communauté.
Passons à quelques points sur l’Agilité.
L’Agilité est une approche qui est de plus en plus populaire, qui vise à améliorer la conception des logiciels et des projets informatiques, en introduisant certains ingrédients, mais surtout en changeant de recette.
Lorsque j’ai présenté avec Eric Mignot, dit «Bob», la méthode Scrum au Paris JUG, l’une des personnes de la salle demande «mais à quoi ça sert Scrum ?» Et là, ceux qui connaissent Eric de Pyxis doivent me comprendre, Eric se retourne et me demande : mais à quoi ça sert ?
A quoi ça sert une Margharita ? A quoi cela sert-il de mettre en place une gestion de projet, où les gens vont se parler chaque matin, où le client va présenter sa liste de demandes en les classant par priorité, où le logiciel sera livré fonctionnel et de manière itérative à chaque Sprint ?
Et bien repensons à mon histoire d’ingrédient. L’ingrédient de base de l’Agilité est la communication. Pour moi, mettre en place de l’Agilité c’est surtout et avant tout pour améliorer la communication. Mettre en place par exemple un atelier de rétrospective, ou un indicateur Kanban, c’est belle est bien pour ajouter un ingrédient à son projet : la co-mu-ni-ca-tion !
Alors oui, l’Agilité comme la Tequila dans la Margharita, améliore la communication. J’ai quelques doutes sur la capacité de chacun à communiquer à la troisième margharita, j’arrête donc là l’exercice délicat de la métaphore.
Pourquoi mon ami, devrai-je m’intéresser à ces principes ?
Je crois que l’un des premiers pouvoirs de l’Agilité est de permettre de changer la perception sur notre métier de développeur. Ma propre expérience, depuis début 2008, montre que la mise en place de l’Agilité permet de changer le rôle du développeur.
Vous ne vous êtes jamais étonné de voir, particulièremenent dans le système Français, hérité des Francs-Maçons et du moyennage, la terminologie «Maitrise d’oeuvre», «Maitrise d’ouvrage» et «Architecte» ? Par contre, et c’est cela qui me fait sourire, on ne dit pas «ouvrier» mais «développeur».
C’est amusant non ?
L’Agilité est un moyen simple de changer la considération du métier de développeur. Lorsque j’explique à un client le principe de l’équipe auto-organisée, j’utilise des images. Vous savez que j’aime utiliser des images.
Je lui explique la chose suivante : voilà, tu as la meilleure équipe du monde (bon parfois ce n’est pas vrai). Alors cette équipe de développeurs, tu vas lui faire confiance. Lorsqu’ils te diront 3 jours pour développper cet écran, tu leur feras… confiance.
Si par contre dans 3 jours tu n’as pas ton résultat, nous pourrons alors revoir l’équipe et essayer de comprendre pourquoi. Mais sinon, essaye de voir ton équipe comme des cuisiniers dans un grand restaurant etoilé. Tu vas rester assis, et tu vas les laisser cuisine. Ta spécification c’est une recette. Nous savons ce que tu veux.. Non nous ne sommes pas intéressés pour savoir comment tu veux que ton plat soit cuisiné. Laisse nous et fait-nous confiance
Et lorsque vous commencez à voir un développeur comme un cuisinier compétent au lieu d’une aide-ménagère dans une cantine scolaire… croyez-moi que les gens commencent à aimer leur métier.
Par ailleurs, c’est bénéfique pour les développeurs.
Je n’aime pas les projets où le développeur ne pense plus. Je n’aime pas travailler sur un projet où le développeur compétent est placé en situation de réaliser, mais que son sens critique ne soit pas utiliser. Je trouve dommage de considérer des gens avec 5 ans d’études comme des ouvriers… ce qu’ils ne sont pas. Ce sont des développeurs.
En 2010, il y a encore des personnes qui n’y croient pas. J’ai cependant aussi vu des projets où il serait dangereux d’essayer de mettre de l’Agilité. Croyez-moi, certains projets mal gérés avec une méthode classique auront plus de chance de s’en sortir qu’avec de l’Agilité.
Car un des problèmes de l’Agilité, c’est que lorsque vous parlez de cet ingrédient à vos clients, vous ne parlez pas toujours des effets secondaires. Ils peuvent être positif : équipe motivée, client content, meilleur communication. Mais ils peuvent aussi être catastrophique.
J’ai l’impression que les gens préferent échouer avec un projet classique plutôt que de réussir avec un projet Agile, au prix d’un changement.
Je pense à l’expérience de Piatelli et Plamarini citée dans le livre d’Alistair Cockburn.
Prenons 2 groupes de personnes semblables. Au premier groupe, nous donnons 300 EUR à chacun. Et nous proposons soit de donner 100 EUR, soit de tirer à pile ou face 200 EUR.
Au deuxième groupe, nous donnons 500 EUR. Nous proposons soit de retirer 100 EUR, soit de tirer à pil ou face le fait de retirer 200 EUR.
A votre avis que se passe-t-il ? Et bien lorsque les gens peuvent gagner plus, comme le premier groupe, ils préfèrent l’option sûre, à savoir choisir de prendre 100 EUR.
Pour le deuxième groupe qui risque de perdre de l’argent, la majorité préfère tenter l’option pil-ou-face, au risque de perdre plus.
En fait, il se trouve que les gens préfèrent échouer de manière conservative plutôt que de prendre le risque de réussir différemment. Je préfère me planter un peu que réussir beaucoup, car je sais que je suis entrain de me planter, et cela me va.
J’ai une bonne nouvelle pour vous. Je crois que dans les années qui viennent, la majorité des projets seront réalisé en méthode Agile. Et cela sera complétement normal. Je sais grâce à Claude Aubry qui est là aujourd’hui, qu’un bon nombre d’étudiants sont formés à Scrum et aux méthodes Agiles dans le sud-ouest de la France. Je crois donc que l’Agilité sera banal d’ici quelques années. Nous aurons par ailleurs trouvé une nouvelle marotte, car nous avons encore un comportement d’adolescent. Sitôt Scrum encensé, il est maintenant de bon ton de préférer le Lean. Puis lorsque le Lean sera devenu à la mode, ce sera une nouvelle méthodoligie. Et l’histoire se répétera encore et encore. Car nous ne sommes pas plus que de simples adolescents, à la recherche d’un courant de mode.
Pour nos clients, nous pouvons penser de manière raisonable qu’un jour, il nous sera demandé de faire mieux pour le même prix. Or si nous ne changeons pas de méthode de développement logiciel, l’un des premiers facteurs de dérive de coûts, nous ne tiendrons pas.
L’ingrédient de base d’un projet piloté avec une méthode Agile c’est que l’on fixe la quantité de certains ingrédients. Je sélectionne la durée, le budget, puis le contenu. Or l’approche classique c’est tout le contraire. Moi j’appelle cela la liste au papa noel. Le client a sélectionné la date, le 25 décembre. Il s’empresse d’ajouter tout un tas de fonctions, et ensuite il sert très fort ses petits poings dans l’espoir d’être livré le jour de Noël, sans retard, avec tout ce qu’il a demandé, et avec la qualité demandée.
Mais il faut arrêter de croire au Père Noël.
Le papa Noël n’existe pas. La gestion de projet en mode je me prends un cocktail triple dose, c’est terminé. Dans le cadre d’un projet Agile, nous fixons le budget, la durée, puis nous travaillons en commun pour réaliser de manière incrémentale et itérative le logiciel. Ce sera Noël toutes les 2 semaines. Au lieu d’avoir un gros tas de cadeaux, tu auras plusieurs petits cadeaux. Et si tu changes d’avis dans les 2 semaines, pas de soucis. Les petits nains te fabriquerons un autre jouet…
Je crois que cette histoire de Noël m’a été inspirée par Jacques Couvreur et François Bechkmann lors d’Agile France 2010.
Une des recettes du plaisir de travailler et de développer est donc d’utiliser une approche Agile. Cela permet de réaliser un logiciel ou de travailler sur un projet de manière collaborative et incrémentale.
J’ai cependant quelques réserves sur l’application aveugle et brutale d’une méthode Agile. Quelque soit son nom. Est-ce qu’il est bon de mettre en place Scrum dans une équipe de junior ? Est-il réaliste de mettre en place Scrum alors que les clients ne sont pas co-localisés et qu’il est impossible de les joindre à l’équipe ?
En décidant de s’auto-soigner, une équipe peut aussi se faire du mal. La mise en place et le changement de méthodoligie demande beaucoup de courage ou sinon beaucoup d’innoncence.
Une équipe sans personne pour faire l’expression de besoin délivrera de manière progressive et incrémentale… un mauvais logiciel. Au lieu d’attendre quelques semaines, le client le verra toutes les 2 semaines. Génial !
Attention donc aux effets secondaires lorsque vous mettrez en place les principes de l’Agilité.
Conclusion sur l’Agilité
L’Agilité sera donc un ingrédient normal du développement logiciel dans les années qui viennent. Ce sera un moyen de rendre un peu plus intéressant certains développements, mais ce ne sera pas suffisant. J’aime l’Agilité et ses valeurs, car il y a une considération du développeur.
Alors attaquons-nous maintenant au sujet du développeur si vous le voulez bien. J’ai travaillé sur les critères qui font que nous sommes motivés ou non. Le cocktail d’un développeur heureux est composé de plusieurs ingrédients. La motivation en fait fonctionne sur des principes assez simples, bien expliqués par les sociologues.
Est-ce que le salaire peut motiver un développeur ?
Si nous devions payer un développeur à la ligne de code, en pensant que le salaire ne serait que la seule et unique source de motivation, ce serait un drame. Un développeur Java gagnerait bien sa vie, un développeur Scala qui écrit moins serait un peu plus pauvre. Par contre un gars qui fait du Lisp, avec toutes ces parenthèses, serait le roi du monde.
Non, l’argent n’est pas du tout le premier critère de motivation. Dans une enquête réalisée sur le Touilleur Express en mai 2010, sur 392 personnes interrogées le premier critère que les candidats déclarent comme important, pour décider d’une entreprise, est «la mission/le poste proposé» à 43%. Et 18% des personnes interrogées déclarent même que c’est la philosophie et les valeurs de l’entreprise qui les intéresse. Le salaire n’est cité qu’à 8% en premier par les candidats.
C’est pour cela que je dis que le salaire n’est pas le 1er critère de motivation. Lorsqu’il est suffisant, mais que la mission ou le poste est nul, croyez-moi, les développeurs s’en vont.
Un critère de motivation, que j’explique lorsque les gens me demandent comment motiver une équipe, c’est la reconnaissance. Lorsque mon fils de 5 ans me montre son dessin et qu’il dit «tu as vu Papa ce beau camion» je le félicite pour ses talents artistiques. Un petit qui vous demande de la reconnaissance, cela marche aussi pour les développeurs.
Didier Girard chez SFEIR place le développeur dans une démarche très novatrice. Lors de l’entretien d’embauche, il explique au candidat qu’il ne restera pas longtemps chez SFEIR. Mais que par contre, le temps qu’il restera ne sera que du bonheur. Si le développeur le souhaite, il pourra participer à la communauté. Par exemple faire des présentations lors des JUG, ou écrire des articles pour les blogs de SFEIR.
Je pense que dans les années qui viennent, les entreprises de services qui marcheront seront connues grâce aux développeurs qui y travaillent. J’ai cette image des équipes de football. Lorsqu’un joueur très connu rejoint une équipe, c’est un formidable moteur de motivaton pour les autres joueurs. Je crois un jour, et là je rêve un peu, qu’un développeur choisira son entreprise et apportera sa notoriété. Et je pense aussi que nous oublierons petit à petit le nom de l’entreprise au profit du nom des gens qui y travaillent.
La reconnaissance est donc un ingrédient de la passion.
J’ai une pensée émue pour cette dame avec qui j’ai travaillé, qui ne voulait pas embaucher de développeur pour son projet de Startup, faute de moyen. Elle comptait sur un senior très fort et sur une armée de stagiaire. J’ai une pensée émue car elle n’a pas compris que le plus important dans un projet de Startup ce n’est pas l’idée. C’est la réalisation de cette idée. Et ne pas investir un euro dans le salaire d’un développeur, c’est la garantie que son projet ne marchera pas.
La motivation et l’envie de travailler viennent aussi si vous avez des outils adaptés.
Je vais vous raconter une histoire. Là où je travaille, j’ai demandé l’autorisation de venir avec un deuxième écran. Nous n’avions qu’un seul écran. Et pour travailler, cela me fait perdre du temps. Avec 2 écrans, je peux mettre mon code à gauche et ma fenetre de navigateur à droite, je gagne un temps fou. Bref je demande l’accord à mon client, qui n’y voit pas d’objections. Et puis me voilà avec mon écran 24 pouces. Oui je ne fais pas les choses en petit. 220 EUR à la FNAC (300 CHF).
Quelques jours plus tard, le client finalement commandera 8 écrans pour toute l’équipe. Les écrans sont arrivés, et les développeurs sont heureux. De bonnes machines pour coder, c’est juste indispensable. Comment peut-on imaginer économiser 200 EUR sur un ordinateur, alors que la journée d’un développeur Java est facturé 400 EUR ? Perdre 2mn par jour car la machine rame, sur une équipe de 10 personnes cela chiffre très vite. Donc pour que vos développeurs ne soient pas démotivés, pensez simplement à acheter une machine décente.
Allez une autre histoire. En décembre je travaillais dans une Startup. La patronne n’avait pas beaucoup de moyens. Au lieu de me laisser commander 3 machines sur Dell.fr, elle a perdu 3 jours à acheter ces machines à Paris, à aller les chercher en Taxi. Et pendant ce temps là, les développeurs ne faisaient rien. Bref laissez nous faire, nous savons ce dont nous avons besoin.
De l’importance de la passion dans un projet
Tout d’abord vous connaissez tous des projets où l’unique moteur est la passion.
Avez-vous vu un projet de plusieurs millions d’euros, où aucune personne n’est payé, où les gens n’ont pas toujours de la reconnaissance, mais qui pourtant livre régulièrement une version ?
Moi oui. Prenez Linux, Wikipedia ou MySQL, l’open-source est le symptome que la communauté des développpeurs est capable de travailler de manière désintéressée, sur un objectif commun, en ne se basant que sur un seul ingrédient : la passion. Car il faut avour que si ce n’est pas de la passion, cela y ressemble non ? Vous ne croyez pas ?
Prenez un projet comme Wikipedia. Ce projet est formidable car il montre à nos DSI, à nos chefs d’entreprises et à nos gouvernements qu’il est possible de faire un projet libre, ouvert et autogéré sans que cela soit le foutoir. Qui se souvient d’Encarta ? La formidable encyclopédie de Microsoft ? Tuée par Wikipedia. Lorsque la communauté se réveille, et que la passion se met en marche, le marché des entreprises doit s’inquiéter.
Prenez un autre projet comme la plateforme Android. Laissez moi vous raconter l’histoire de 2 passionnés. J’etais au Jug Summer Camp. Je croise une connaissance du Paris JUG, stéphane. Il a monté une entreprise avant l’été. Avec un compère ils ont codé quelques jeux sur Android. Le premier jeu était simple. Mis sur l’Android Market ils pensaient gagner 100 EUR. En fait le truc a tellement marché qu’il a été téléchargé 860 000 fois. Et croyez moi ce n’est pas 100 EUR de chiffre d’affaire, car ils pourront se payer 2 salaires très bientôt.
Voilà c’est ça ! Cette passion est derrière ce type d’aventure.
N’est-ce pas génial lorsque nous sommes développeurs que de penser que nous avons le pouvoir de créer de manière artisanale de belles applications ?
J’aime le métier de développeur. J’ai faillit devenir éléctronicien. A l’heure qui l’est, je serai devenu un manager ou un commercial. Je pense que j’aurai fait un peu d’électronique pendant quelques années, mais que j’aurai rapidement décroché.
J’aime le métier de développeur.
Vous avez une idée ? Vous pouvez la coder et la mettre en ligne sur Google App Engine par exemple, un soir de chez vous. Pas besoin de laboratoire. Pas besoin de moyens coûteux ou chers. Vous pouvez facilement réaliser votre idée.
N’est-ce pas formidable ?
Savoir que nous avons tous, dès lors que nous connaissons un langage de programmation, la possibilité de coder un projet… moi je trouve cela formidable.
En résumé donc, les ingrédients qui rendent mon métier passionnant sont la communauté, les méthodes Agiles, la reconnaissance, l’importance d’avoir des outils efficaces pour travailler, et enfin cette capacité à créer.
0 no like
Je ne cherche pas à la défendre mais… elle a essayée de réduire les coûts la ou elle en avait un certaine maîtrise. S’il y avait d’autres moyens, ils auraient pu être utilisé… encore une fois on peut voir cela comme un problème de communication.
Ce qui me chagrine à propos d’agile, comme tu le remarques, c’est que l’on dirait une mode. Certaines entreprises emploient/essayent des méthodes agiles mais juste du point de vue méthodologie. C’est à dire qu’au contraire du manifesto, le processus et les outils sont désignés comme plus important que les individus et leurs interactions. Et à partir de la, c’est plus ‘Scrum’ que ‘Agile’.
Agile est’fail fast’. Et oui, effectivement, quelque soit la méthode un projet sans vision/direction n’ira nulle part.
Un point qui est rarement soulevé aussi est que parfois l’adoption d’une méthode Agile n’est faite qu’au niveau de l’équipe technique. Et bien qu’initialement, je conçoit que cela puisse ‘booster la passion’ de l’équipe mais si le changement n’est pas plus global cela ne sert finalement pas à grand chose…
Pour revenir plus à l’article.. en effet j’ai pas mal dérivé… je te rejoins parfaitement sur les ingrédients : « la communauté, les méthodes Agiles, la reconnaissance, et la capacité à créer. » Les « outils efficaces » sont pour moi plus un moyen, une conséquence mais finalement pas une fin en soi.