Ruminations From a Tortured Mind

J'ai récemment entendu un petit jeunot (vu l'âge moyen en informatique, ce sont maintenant tous des jeunots par rapport à moi) parler de son environnement de travail. Ce jeune homme disait donc qu'il devait obligatoirement venir en costume cravate, alors qu'il était au sous-sol sans jamais voir le moindre client. Les horaires sont 9h30 - 18h30, avec un manager aussi strict qu'un Suisse-Allemand. En gros, qui vous engueule pour 2 minutes de retard. Il travaille sur un poste Windows XP (alors qu'il code des applications sous Linux, cherchez l'erreur !), vérouillé à l'extrème ou il était impossible de modifier quoi que ce soit, dont son navigateur, ce brave IE6.

Son manager lui attribue régulièrement du travail à effectuer sans qu'il donne son avis. Bien évidemment, étant en prestation, il devait bien faire attention à tout : tenue vestimentaire mais aussi comportement, blagues à midi avec ses collègues. Car chez son client, la politique est partout, même entre collègues prestataires puisque les différentes SSII se battent entre elles pour gagner des marchés, et toute information est bonne pour faire sauter son concurrent. Il faut donc être sur ses gardes, et éviter de faire des erreurs fatales pour votre mission. Grand sourire et haleine fraiche de rigueur en toute circonstance ! Son chef est son commercial, qui n'a donc rien à foutre de ses problèmes tant qu'il ne fâche pas le client, ce qui lui permet de gagner sa comm mensuelle sans rien faire.

Sa mission est régulièrement entrecoupée de réunions, qui permet au manager de montrer son exceptionnelle capacité de non décision, malgré les 4 heures écoulées à parler (enfin surtout le manager, lui évite de trop parler histoire de ne pas rallonger la réunion dont il connait parfaitement le déroulement et surtout la fin). C'est quand même l'occasion de renconter des collègues qu'il voit rarement car il en a pas l'autorisation. On ne shint pas inpunément l'autorité du manager sans en subir les conséquences.

Bien évidemment, la qualité est un refrain martellé par son client, mais au abonné absent dans son quotidien. Le refactoring ? Connait pas. Les tests ? Par le stagiaire quand le code est fini. Mais comme le dit son commercial : «c'est une opportunité de changer les choses de l'intérieur !». Et devoir travailler 8h par jour sur une application qui pète en permanence, c'est comme disposer d'un bureau qui se pète la figure quand on bouge un peu trop. C'est juste très pénible.

Ayant travaillé 8 ans en SSII chez de gros clients publics comme privés, tout cela m'a rappellé bien des souvenirs (et ceux qui me connaissent n'auront aucun mal à imaginer le peu d'antrain que j'avais à «faire semblant» et à accepter ces conditions de travail).

Alors, pour toi, jeune informaticien, je vais te donner un aperçu de ce qui se passe dans mon quotidien :

• Tenue vestimentaire libre.

• Vous pouvez être en chaussette ou pied nu pendant la journée. Ou en n'importe quoi d'autre d'ailleurs.

• Horaire libre. La seule contrainte est le daily meeting à 11h45 d'une durée de 15 minutes.

• Les autres réunions sont lancés au besoin, par un membre de l'équipe. Généralement elles durent 15 à 20mn. On essaye de ne pas dépasser 1h. On fait aussi des réunions flashs de 5 mn.

• Estimant que 5h par jour de travail est un maximum niveau efficacité, vous ne serez pas bien vu en restant tard le soir. Le but est d'être efficace sur le long terme, pas sur un mois.

• On prend régulièrement 2h pour manger et faire autre chose après, comme jouer (à un jeu vidéo, au échecs...) ou matter des vidéos. On reprend le taff à 14h.

• RTT et jours de congés sans obligation, vous les prenez quand vous le voulez (en 4 ans, je crois n'avoir jamais refusé une demande).

• Si vous êtes malade ou peu productif dans la journée, alors on rentre. Pas la peine de se forcer. Ou alors faite une sieste !

• Le poste de travail est de votre responsabilité. Vous mettez l'OS de votre choix (bon, on est tous Unixiens dans l'âme), la distrib que vous voulez.

• Télétravail possible sur 1 ou 2 jours par semaine (mais faut avouer que l'on est pas bien organisé pour ça. Si on devait étendre à plus de monde, on changera notre organisation).

• Chacun choisi son travail sur le kanban, j'ai autre chose à foutre de mes journées qu'attribuer les tâches. On est tous des grands garçons (y'a pas de filles).

• Plus de fiche sur le kanban ? Alors profitez en pour étudier un truc qui vous intéresse, ou vous reposer un peu, ou faire un truc en rapport avec le dev. Ca s'appelle être en slack.

• Tous les choix de conception et de développement sont pris ensemble, malgré mes multiples casquettes, je n'ai pas celle d'architecte expert sénior certifié (ajouter les buzzwords à la mode).

• La revue de code obligatoire permet de s'aligner, de se tenir au courant du travail de ses collègues et de s'imprégner du projet dans sa globalité.

• Les techos sont séparés pour avoir du calme, ce qui joue beaucoup sur la concentration. On évite le téléphone au maximum. La pièce possède tout le nécessaire pour des réunions (tableau blanc, whitepaper, rétro-projecteur) ce qui évite de se déplacer en salle de réunion.

• Et parce que la valorisation se fait aussi par le salaire, les augmentations sont significatives (entre 8 et 12%). Le deal est clair à l'embauche sur le niveau de salaire que je souhaite donner à moyen terme.

Bon, je m'arrête la mais vous voyez le topo. Je peux glorifier cet environnement, mais ce n'est pas le cas, pour une raison bien simple : c'est normal. C'est l'environnement cité par notre jeunot qui est inadmissible, puant de médiocrité organisationnelle et rempli de petits chefs sans envergure.

L'informatique est un métier purement cognitif, la productivité est donc directement proportionnel à sa capacité à réfléchir et à être créatrif. Il est donc fondamental de disposer d'un environnement en rapport. Surveiller ou contrôler avec des processus contraingnants n'a donc aucun intérêt si on recherche l'efficacité.

Si vous voulez des gens motivés dans leur travail et qui donne le meilleur d'eux-mêmes, c'est donnant-donnant. A vous de construire une organisation qui leur donne l'impression d'être écoutés et impliqués. Et vous savez quoi ? Ca marche. Prenez des gens pour des gamins et ils se comporteront comme tels. Mais attention, on est de loin du monde sans management comme le pensent souvent les informaticiens, c'est même le contraire ! Mais c'est le sujet d'un autre billet.

Alors, si vous subissez ce genre d'environnement, changez d'air. Et si c'est vous le manager, alors changez de métier, il n'est pas fait pour vous.

On peut juger un développeur sur la compréhension qu'il possède de son métier : 5 niveaux qui détermine bien souvent sa plus value pour une organisation.

Niveau 0 : pisser de code

Il pense que son boulot est de produire des lignes et des lignes et des lignes de code. Généralement peu intéressé par ce qu'il fait, c'est juste un poste qui paye la soupe. Ou alors c'est un boulot temporaire avant de passer chef de projet.

Le développeur du niveau 0 se voit très fréquemment et forme le gros du bataillon des SSII. Chaque fois qu'on le rencontre, on se pince les lêvres pour ne pas lui demander pourquoi il fait ce métier. Mais il faut bien reconnaitre que c'est souvent ce que lui demande son chef de projet...

Niveau 1 : livrer du code

Intéressé par la qualité du code, il pense qu'il doit livrer du code fonctionnel. Il s'intéresse aux Design Patterns, lit des livres sur le développement logiciel, refactore de temps en temps son code pour le rendre plus beau et s'intéresse aux tests.

Celui ci peut se rencontrer dans les groupes de développeurs, dans les soirées consacrés aux codes... Il a souvent la passion de son métier. Il discute longuement de code, et lit régulièrement blogs et livres sur le sujet.

Niveau 2 : livrer un logiciel

Le développeur livre un ensemble de code cohérent, qui possède une structure et fonctionne comme un bloc uni. Il s'intéresse à la conception, à la robustesse, à l'architecture logicielle. Il sait que les tests sont très importants, autant unitaire que fonctionnel, avec une couverture suffisante pour être rassuré quand il modifie des pans entiers du logiciel.

Le niveau 2 est plus rare. Trop souvent, à la question quel est ton métier, un développeur me répond :

Liver du code !

Et non, ton métier est au minimum de livrer un logiciel. Avez vous déja vu un client satisfait d'une livraison d'un dépôt Git ?

Niveau 3 : livrer un produit

Le développeur livre plus qu'un logiciel, il livre un produit. Il s'intéresse donc à la couche système, aux procédures d'installation et de mise à jour, à la reprise sur incident, à la mise en production. Il participe à la documentation utilisateur et se met à la place des admins.

Livrer un produit signifie souvent l'abandon du travail d'intégration pour un travail de conception, bien plus difficile. Il faut réfléchir avant tout à ses problématiques (et non celles que le framework X à résolu pour vous), au développement sur le long terme et donc à l'évolution du produit.

Niveau 4 : livrer de la valeur

Plus qu'un produit, même bien ficellé, le développeur apporte de la valeur. Car le réel objectif est d'améliorer le business du client. Niveau ultime et de loin le plus difficile car il demande de bien comprendre le métier du client en plus de parfaitement maitriser le sein (le développement logiciel).

Constat

Je vous concède que c'est un poil schématique. Une des particularités quand on travaille chez un éditeur logiciel est que le niveau minimum est... 4.

Le niveau 3 est malheureusement rare alors que c'est pourtant le niveau que tout développeur devrait atteindre. Mais il faut bien avouer que le développement logiciel est un métier à la fois très exigeant et nouveau (moins de 40 ans !).

L'autre raison que la plupart des développeurs travaillent en France dans le service, et peu dans le monde de l'édition. Ce qui veut dire bien souvent être en cascade (peu ou prou, même ceux qui disent faire de l'agilité, voir mon article «l'agile est mort») avec un cahier des charges fixe. Il faut une collaboration étroite avec le client pour échanger sur son business et comprendre, au dela des besoins exprimés (qui sont le plus souvent des solutions exprimées et non des besoins), les besoins réels et utiles. Ce qui est rarement le cas en SSII ou la plupart des clients estiment que ce n'est pas votre boulot de remettre en cause leurs besoins (comment voulez vous ensuite que les développeurs se sentent conernés ?).

Je raconte souvent cette anectode : En tant qu'éditeur, il nous a fallu pratiquement un an entre la première version commerciale et la version crédible. Car nous avons trop misé sur des clients et partenaires incapables d'exprimer clairement des besoins, ce qui a affecté notre vision du produit. Nous avons donc sorti une version apportant peu de valeur. C'est en rencontrant des partenaires spécialisés et connaissant bien le métier que nous avons pu rectifier le tir et mieux comprendre ce dont ils avaient besoin.

C'est évidemment de notre responsabilité, et je ne rejète en aucun cas la faute sur des tierces personnes. Mais cela m'a bien un peu éloigné de la sainte croyance qu'il faut écouter le client. Comme le disait Henry Ford :

Si j'avais demandé à mes clients ce qu'ils voulaient, ils m'auraient réclamé un meilleur cheval

Au passage, c'est en rencontrant des partenaires et clients Suisses, Belges, Allemands... (et non plus Français) que cela s'est amélioré :).

Conclusion

Etre éditeur logiciel, c'est être capable de livrer un produit robuste et fiable rapidement. Il faut maitriser le développement logiciel de bout en bout : le codage bien sûr mais aussi l'infrastructure, la conception, le packaging, le déploiement, la production, la documentation, le support... Il faut être foncièrement multi-compétences et vouloir s'améliorer dans tous ces domaines. Mais ce qui rend le travail si intéressant et dur, c'est que vous devez aussi maitriser votre coeur de métier. Là ou les niveaux 0 à 3 se focalisent uniquement sur la technique (qu'elle soit système, réseau, algorithmie, ihm, gestion de projet...)

C'est pour cette raison que les livreurs de code, même excellents, ne sont bons au final, qu'a produire de la dette technique car plus intéressés par la beauté d'un code que de trouver une finalité utile à celle ci.

Coder dans le cadre professionnel, ce n'est pas se faire plaisir avec le pattern X ou la techno Y, c'est avant comprendre un métier et apporter le maximum de valeur. Même si cela peut sembler inintéressant au premier abord, livrer un produit fonctionnel, fiable et robuste, utilisé par des clients heureux est le summum de la satisfaction, bien loin d'un algo lisible et performant. C'est ce qui fait tout le charme du métier d'éditeur.

Mais ne me faites pas dire ce que je n'ai pas dit, il faut aussi se faire plaisir en tant que développeur :).

Sous ce titre qui peut paraitre provocateur se trouve un constat plutôt amère, d'autant plus amère que tout cela était prévisible depuis bien des années. L'Agile est devenu mainstream, on en parle régulièrement dans les journaux de décideurs (c'est bien la preuve de sa reconnaissance non ?), les développeurs disent le pratiquer au quotidien, les responsables de projet assurent en faire. Alors pourquoi ce pessimisme ? Parce qu'il ne se passe un mois sans en avoir la preuve, par exemple quand quelqu'un se pose en face de moi et me dit :

L'agilité, c'est vraiment de la merde !

Et cela m'arrive très souvent (certes ce n'est pas toujours aussi vulgaire). Il ne faut pas 2 minutes pour savoir que son contexte n'est pas Agile, ni de près, ni de loin. Mais le signe le plus tangible est d'entendre des soit-disant spécialistes dirent n'importe quoi à longueur de blogs, journaux ou listes de diffusion.

Oh, je vous vois venir : «mais qui es tu pour définir ce qui est de ce qui n'est pas Agile ?». Excellente question ! En fait, si définir avec précision les contours de l'agilité est difficile, surtout en 2011 où beaucoup de pratiques ou de mouvements se disent Agile, il est bien plus facile de dire ce qui n'est pas Agile quand c'est aux antipodes de la philosophie qu'il veut incarner. Certes le référenciel des pratiques a augmenté, mais il y'a toujours des fondamentaux clairs et bien visibles, et toutes pratiques agiles doivent en découler. J'aime comparer l'agilité avec le Logiciel Libre, deux mouvements auxquels je participe depuis longtemps (10 et 15 ans), car ils sont dans les deux cas un mélange de technique et d'humain. Dans les deux cas, c'est une certaine représentation du monde et des relations entre les gens :

Si je diffuse un logiciel avec une licence Libre, par exemple BSD, mais que je ne propose pas de bugtracker, de liste de diffusion, ou que je refuse toute contribution extérieure, ou que j'obfusque mon code, ou que j'envoie sur les roses les demandes d'utilisateurs, je fais du Logiciel Libre (ma licence le prouve) sur papier. Dans les faits, ce n'est qu'un ersatz, je ne respecte pas la philosophie du Logiciel Libre. Il en est de même avec l'agilité.

A mes yeux, l'agilité se résume en trois points dont leurs présences sont faciles à juger.

La recherche de la valeur

Souvent maladroitement appelé un logiciel qui marche, l'objectif est de donner aux utilisateurs un produit fonctionnel, utilisable et pratique. Et sauf à produire un logiciel maintes et maintes fois demandée, c'est une découverte, autant pour le client que pour l'équipe de développement. C'est donc une utopie de croire que l'on peut définir à l'avance les spécifications complètes du logiciel. Le but est avant de trouver ce logiciel agréable et fonctionnel, et non de le faire vite. La cascade est à bien des égards l'approche la plus efficiente pour faire du logiciel rapidement :

• J'écoute les besoins.
• Je conçois et valide les spécifications.
• Je développe.
• Je teste.
• Je livre.

Il n'y a pas plus rapide. Si vous faites depuis 20 ans la même chose, pas de soucis. Je n'ai entendu que deux (oui deux, pas trois) sociétés capables de livrer en temps et en heure avec de 99% succès en mode cascade. Et sans surprise ce sont deux sociétés développant en Cobol sur une plateforme assez ancienne des produits fortement similaires. En résumé :

• Equipe stable.
• Techno et plateforme archi connues.
• Métier fortement maitrisé.
• Produits similaires.

En sommes, un environnement idéal. Mais il est illusoire d'attendre d'un client la capacité à définir avec précision ses besoins. Non seulement il ne sait pas ce qu'il veut, mais il se rend souvent compte après coup que ce qu'il a réussi à expliquer est sans intérêt ! Voire même que son business ou ses besoins ont changés entre le début du développement et sa fin. Et je ne parle même pas de la capacité d'une équipe de développement à livrer un produit de bonne qualité d'une seule traite, surtout si c'est en découvrant le métier du client. Bref, pour résumer, c'est utopique. Mettons cela sur l'immaturité de notre métier, la jeunesse de nos outils et une formation trop basique.

Au contraire, l'agilité se veut une quête de sens :

• Que dois je obtenir ?
• Quelles sont les fonctionnalités réellement utiles ?
• Ce besoin est il justifié ? N'est elle pas le symptôme d'un problème non technique ?
• Voir même, ce logiciel est il utile ?

C'est un effort collectif, allant du développeur jusqu'au client pour comprendre, analyser et développer de la valeur métier à travers un logiciel. Sans cela, vous faites de la cascade : on se met d'accord sur une limite fonctionnelle, numéraire et temporelle et zou !

Passons au deuxième point.

L'humain est au centre

Ce qui ressort aussi est cette volonté permanente de mettre en avant les personnes, et non les outils ou les processus. les seconds sont aux services des premiers, et pas l'inverse ! Le développement est une histoire de développeurs avant tout. Vous devez faire confiance aux gens, les respecter dans leur capacité à produire, dans leur jugement. Cet accent me semble t'il est absent des approches précédentes comme la cascade ou RUP. Ces dernières sont plutôt axées processus, avec des dizaines de procédures et de la documentation à profusion, le développeur n'étant qu'un rouage du système.

CMMi est un bon exemple de cette vision : la documentation officielle parle sempiternellement d'organisation et de processus. Et pire, il faut être certifié CMMi pour savoir lire une doc CMMi (cherchez l'erreur) tellement elle est inbitable et truffée d'une terminologie incompréhensible. D'ailleurs la plupart font du cascade, c'est dire leur croyance dans les processus. Il faudra attendre 2010 pour entendre le CEI parler sérieusement d'agilité, 11 ans après le livre de Ken Beck !

Au contraire, l'agilité privilégie l'interaction sur le processus, le résultat sur la documentation, en rapprochant physiquement tous les participants, en poussant les réunions courtes mais régulières, et en écoutant les gens.

Passons maintenant au troisième point.

Le développement est une discipline

Le développeur remis en selle comme moteur du développement, on lui demande en échange de maitriser son métier : on veut du logiciel qui fonctionne ! Il doit remettre sans cesse se remettre en cause, apprendre à faire mieux et à affiner ses techniques de développement.

Le milieu logiciel aime bien se traiter d'artisan (chaque profession aime se dépeindre avec élégance) mais cela est identique chez les livreurs, les boulangers, les cuisiniers, les musiciens... Mis à part que le développement logiciel est un métier non seulement très complexe mais en plus à ces balbutiements : 60 ans. Cela est bien peu.

L'agilité apporte beaucoup de solutions intéressantes : le TDD, les tests, la revue par les pairs, l'intégration continue ou le refactoring par exemple. Bien sûr un développeur peut très bien travailler correctement depuis très longtemps sans avoir jamais lu un seul livre sur l'agilité. Après tout Ken Beck et ses accolytes ont découvert ces techniques, pourquoi pas les autres ? Certes, mais se passer de l'agilité, c'est mettre de coté des années de réflexion sur les pratiques de développement logiciel et ca serait bien dommage.

Alors, pourquoi dire que l'Agile est mort ?

je ne suis malheureusement pas assez vieux pour savoir ce qui se passait dans les années 70, 80 et 90 dans l'industrie du logiciel mais je ne crois pas me tromper en disant que l'agilité est une étape marquante. Je suis malgré tout un vieux Geek, j'achetais pas mal de livres sur la programmation voici 20 ans et je n'ai aucun souvenir des livres (en France en tout cas !) qui ressemblaient peu ou prou à l'agilité, on apprenait plutôt en copiant le code des maitres (en crackant des logiciels, en écoutant les démo-makers ou en bavardant sur les BBS). Des pratiques quasi inconnues voici 10 ans sont maintenant considérées comme des pratiques indispensables (vous faisiez beaucoup de tests unitaires en 2000 ?).

L'agilité a apporté la lumière à des milliers de développeurs, dont moi, et à fait progresser notre connaissance de notre métier, en construisant pour la première fois un socle stable. Nous en sommes encore au début mais nous tentons chaque jour de mieux comprendre ce métier Ô combien difficile.

Mais vous savez quoi ? Tout le monde s'en fout !

L'Agile est la nouvelle technique à la mode

On s'aperçoit rapidement qu'une majorité d'organisations utilise l'Agile parce qu'ils ont entendus que ça marche mais se foutent royalement de ce qu'il y a dedans. Et pour cause, cela signifie aussi remettre à cause deux visions fondamentales dans nos entreprises :

• L'informatique est un coût, pas un investissement.

• Les employés sont interchangeables, et non le socle de l'entreprise.

Ne voulant pas remettre en cause ces deux postulats, il ne peut en résulter qu'un dévoiement du mouvement Agile. Et c'est ce qui se passe. L'Agile est donc une mode, qui passe après le développement objet, les Design Patterns, le C++, Java, les frameworks, RUP et quelques autres. On verra dans quelques années fleurir de nouvelles modes quand les promesses des vendeurs Agiles se seront écrasé sur le mur de la réalité des entreprises.

Mais que font ils ?

Du développement itératif et incrémental. Ils découpent leurs développements en lots plus petits, avec vérification régulière. Le rapport avec l'Agile tel que je le décris au début du billet ? Aucun ! Faire confiance aux gens ? Soyons sérieux, ils pratiquent régulièrement le command & control, technique qui consiste à faire travailler les gens comme des marionnettes, et les accuser de faire du mauvais boulot en cas de pépin. Voir le développement comme une discipline ? Vous parlez de ces directions des achats qui écrasent le prix journalier des développeurs vers le bas ? Quand à la recherche de la valeur, cela signifie remettre douloureusement en cause le fonctionnement de l'organisation.

Vous commencez à me comprendre ? Ce n'est d'ailleurs pas pour rien que l'on vend du Scrum, qui consiste à faire des lots (appelé itération) avec démo régulière qu'on soupoudre avec une réunion quotidienne et une rétrospective de temps en temps. Le tour est joué, on fait de l'Agile !

Dites moi si ces quelques exemples vous dit quelques choses :

• Le Chef de projet est appellé ScrumMaster, parce qu'il a fait 2 jours de formation.

• On n'évalue pas la pertinence business d'une fonctionnalité.

• On a pris des développeurs sous qualifiés ou inexpérimentés car par chers.

• Le pair-programming ou la revue de code ? Trop cher et inutile.

• Le ScrumMaster assigne les tâches à chaque réunion quotidienne.

• La rétrospective se fait avec le client.

• Un cahier des charges est construit avant de développer.

• On ne prend jamais le temps de revoir les parties qui posent problèmes.

• On doit travailler tard pour rattraper le retard ou gérer les nouvelles demandes du marketing.

• Le projet va dans le mur mais on ne fait rien.

• On micro-manage les gens.

• On découpe le projet en équipe qui ne se voit pas.

• On ne fait pas monter en compétence les membres de l'équipe.

Je pourrais ajouter bien d'autres exemples, mais vous voyez l'idée. Où est la philosophie Agile ? Absente, car les organisations ne souhaitent pas changer leur vision du développement logiciel, encore moins leur mode de fonctionnement.

Pourquoi en faire ?

Parce que ça se vend, pardi ! Des sociétés de conseils se sont placés sur le marché, des associations se sont créés pour développer ce business. Alors ca se vend, et plutôt bien maintenant.

Mais comment faire de l'Agile :

• dans un environnement command & control ?

• dans une culture du blâme et de la recherche du coupable, ou chaque responsable sort son parapluie au moindre soucis ?

• quand on vous donne un cahier des charges sans remise en cause du besoin business ?

En le triturant pour que cela rentre dans les cases. Un exemple ? La grande tartuferie du développement Agile au forfait. Regardons de plus près : le forfait consiste à définir une limite fonctionnelle, temporelle et numéraire d'un développement. Cela vous rappelle quelque chose ? Pas pour rien que le forfait agile est un serpent de mer dans toutes les conférences Agile depuis des années, tous les responsables de SSII se demandant comment en faire.

L'Agile est mort en 2001

Plus précisemment en février 2001, à Snowbird Utah USA. C'est la création du Manifeste Agile et de l'emploi du terme Agile. Plus généralement, c'est une volonté de mettre en place un modèle, un cadre. C'est à partir de 2002 que l'on voit fleurir les livres avec le terme agile dans le titre.

Cela peut paraitre surprenant de dire cela, puisque c'est aussi le début du mouvement Agile. L'objectif de normaliser termes et principes, de les figer, est avant tout pour mieux le vendre. Il est curieux de voir 17 consultants sur les 17 signataires du manifeste : tous vendent des livres, tous vendent des formations. L'Agile Alliance fut créée dans la foulée pour en faire la promotion.

Un modèle sclérosé

Résultat en 2011 ? Malgré quelques avancées, le discours Agile officiel est proche de 2001. N'a t on rien appris en 10 ans ? Bien sûr que si : le développement par flux, la prise en compte de l'organisation dans le développement ne sont que deux exemples fondamentaux. Mais pourtant, le modèle Agile reste assez hémertique à ces changements. On a bien vu quelques nouveautés mais rien de bien méchant. Pourquoi ? Parce qu'on est plus intéressé à vendre qu'à réfléchir, car pour réfléchir il faut avant tout faire ! Ce n'est pas en écrivant des livres et en faisant du consulting qu'on peut produire. XP est le résultat de très nombreuses années de pratique de développement logiciel. Taiichi Ono (fondateur du Toyota Production System) à passé plusieurs décennies pour perfectionner son organisation. Il ne faisait surement pas passer des certifications TPS 5 ans après avoir débuté sa nouvelle organisation !

Il y a bien eu un déplacement léger du développeur vers l'organisation. Même si le modèle Agile s'ouvre sur l'extérieur, cela reste limité : il suffit de voir le rôle du PO (Product Owner), proxy du reste de la société, où se trouvent des stakeholders. Ou est le marketing commercial ? Technique ? La recherche de nouveaux marchés ? Le déploiement ? L'opérationnel ? L'expérience utilisateur ? Le design ? En gros, où est tout le reste ?! Le vide, les têtes pensantes du modèle Agile sont encore à rabacher TDD et planning poker, la belle affaire !

Pire, ce léger déplacement est contre balancé par le mouvement craftmanship, qui se veut un retour au source, auto-centré sur le développeur. La seule avancée intéressante vient de partir à l'eau ! Si vous voulez savoir pourquoi, regardez juste le business du fondateur de mouvement, Bob Martin, vendeur de livres et de formations... sur le code. Forcément, l'organisation, ce n'est pas utile pour son business. Il est d'ailleurs marrant d'entendre certains se pâmer devant ce mouvement comme ci c'était nouveau. XP disait peu ou prou la même chose voici 13 ans. Ce n'est d'ailleurs pas anodin que ce soit majoritairement des Scrumistes qui ont font (en France) la promotion, alors qu'ils critiquaient XP ouvertement.

Conclusion

J'espère avoir éclairci mon propos sur Twitter (140 caractères, c'est des fois trop court :). Non, il ne faut pas arrêter de faire des tests, du pair programming ou des réunions quotidiennes. Et non, il ne faut surtout pas minimiser l'impact de l'agilité sur notre métier, bien au contraire ! Je vous encourage à lire livres et blogs et à prendre ce dont vous avez besoin.

Il faut seulement avoir une vision systémique du mouvement, comprendre d'où il vient, pourquoi il a été créé et pourquoi certaines personnes vendent le modèle Agile. Cela permet par exemple de comprendre le Manifeste Agile au lieu de répéter bêtement son contenu qui est loin d'être optimal en 2011. Cela permet aussi de comprendre que ce modèle créé en 2001 (Scrum en 96, XP en 99) et qui a mis du temps à se propager n'apporte plus rien de neuf depuis de nombreuses années. Si l'argent fut toujours le moteur, le modèle est maintenant dévoyé pour rentrer dans la matrice consulting, loin des objectifs initiaux. Et ni les voix officielles (Agile Alliance, Scrum Alliance), ni ses têtes pensantes se sont élevés contre cela. Pire, elles ont participé activement à ce dévoiement (qui a dit certification ?).

Je pourrais résumer ma pensée ainsi : L'agilité est une avancée importante, mais le modèle Agile est inutile. C'est peut être le destin de tout modèle. En tout cas il est temps que chaque organisation invente, à l'instar de Toyota, son propre modèle de production. Un modèle adapté à son business, ses clients, ses collaborateurs. Un modèle qui prend en compte toutes les nouvelles avancées que l'on peut trouver dans les mouvements tels que Devops, Lean, Lean startup ou Kanban. Un modèle qui évolue sans cesse avec la maturité et la capacité de l'organisation à produire.

Mais pour essayer de le faire sans relâche depuis 4 ans, je vous concède que c'est bien plus difficile et pénible qu'une formation de 2 jours ou de répéter à l'envie ce que l'on a lu dans un livre...

Cela faisait quelques temps que cela me titillait : écrire des billets avec mon éditeur texte habituel, et de pousser en prod avec Git. C'est le blog de #gitfr qui m'a donné le courage de m'y mettre. Et c'est maintenant chose faites. Adieu Wordpress, boujour Blogofile !

Mais qu'utilises tu ?

Un générateur statique de site, autrement un outil qui transforme les documents textes (format markdown ou rst) en pages html, à l'aide de templates.

Beaucoup d'avantages :

• Tout se trouve dans des fichiers textes.
• Plus besoin d'être en ligne.
• Ecriture avec Vim et non un éditeur WYSIWIG dans un navigateur.
• Maintenance pratiquement nulle.
• Plus de problème de sécurité.
• Sauvegarde automatique sur GitHub.
• Liberté totale sur l'organisation du site.
• Hébergement simplifiée (plus besoin de PHP, Python...).
• Et bien sûr, utilisation de Git pour gérer le site :).

En contre partie, vous n'avez plus la facilité de créer un joli site en 2 clicks de souris. La, c'est à vous de créer votre template et de développer les services supplémentaires (affichage de tweets par exemple).

Un retour en arrière ?

Je faisais du statique en 96 quand j'apprenais l'html 3 (ou 2 je ne sais plus), et voila que je refais du statique en 2011, est ce vraiment raisonnable ? Il y'a en fait un changement important qui permet ce retour aux sources : le cloud. Pour disposer d'un blog, il faut un moteur de rendu de billets, mais aussi un système de commentaires, la gestion de flux RSS, le multi-compte, des droits et authorisations, etc.

Maintenant, vous pouvez externaliser tous les services importants :

• les commentaires : Disqus.
• les flux RSS : Feedburner.
• Suivi d'activité : Google Analytics.
• Hébergement, backup, droit et travail collaboratif : GitHub.

Cela permet de se concentrer sur l'essentiel : écrire du contenu.

Organisation

Il me faut deux dépôts. Pourquoi deux ? Ce n'est pas obligatoire bien sûr, mais j'utilise le service d'hébergement gratuit de pages statiques de GitHub. Ce dernier impose des contraintes, dont le nom du dépôt et l'emplacement des fichiers. Si vous hébergé vous même le site, un seul dépôt est suffisant.

Pour les utilisateurs de Git, les submodules font parfaitement l'affaire puisque la version générée se trouve dans un sous répertoire.

Un exemple ?

La mise en production se fait comme suit :

$ /path/to/blogofile/blogofile build
$ git add _site/*
$ git commit -m "nouveau billet sur Blogofile"
$ git push

(sans submodules, il suffit de copier le contenu manuellement).

Et voila ! Je vous laisse imaginer les possibilités intéressantes qu'offrent un DVCS comme Git ou Hg (si ce n'est pas le cas, vous êtes bon pour voir une de mes présentations Git ;) pour gérer votre site.

Pourquoi Blogofile ?

• Parce qu'il est en Python, et cela me permet de coder dans mon langage préféré et d'apprendre des moteurs de templates que je ne connaissais pas (Mako et bientôt jinja2).

• Parce qu'il est vraiment simple. Pas fioritures, il va à l'essentiel. Ecrire des controlleurs ne semblent vraiment pas dur et les quelques fonctionnalités dont j'avais besoin (Disqus, flux RSS et blog) sont là. Un site de base tiens dans 700 lignes de code Python, ce qui rend la compréhension aisé. Blogofile fait pour sa part 900 lignes.

• Il permet de gérer les documents drafts, le multi-auteur ou les transformations multiples.

• Parce que je sature un peu de Ruby. Utilisant pas mal d'outils codés en Ruby ces derniers temps, je commençais en avoir ras la casquette des erreurs d'installation ou des messages d'erreur complètement abscons. Mais des outils comme Jekyll ou Toto semblent pas mal du tout, j'ai fais joué ma fibre Pythonienne.

Alors, si vous avez un site à monter, je vous conseille fortement de jeter un oeil sur ces logiciels, cela peut vous intéresser ! :).

Cela fait maintenant plusieurs semaines que j'utilise la technique Pomodoro, qui consiste (en gros) à découper le temps par tranche de 30 minutes : 25 minutes de travail puis 5 minutes de repos. D'abord trés sceptique, je suis devenu un partisan convaincu.

Pourquoi tenter Pomodoro ?

Au boulot, j'ai constaté une dégradation progressive de mon efficacité, c'est à dire de ma capacité à produire de la valeur. Je dois selon les moments trouver des idées, réfléchir à des actions ou tout simplement agir. Pire, j'endosse différents rôles bien différent les uns des autres, ce qui accentue la difficulté : les tâches n'ont aucune relation entre elles, demande un état d'esprit adpaté, des connaissances différentes... Bref, ce n'est pas simple.

J'ai tenté plusieurs approches sans réussite comme jouer un rôle par jour : pas vraiment réaliste, on arrive vite à des situations de gachis extrême (exemple : tâches trop peu nombreuses pour la journée). Autre technique, la procrastination :). En gros, laisser courir le plus longtemps possible. Facile, mais pas efficace pour un sou. Bref, rien de convainquant, en retournant ça dans tous les sens, je n'ai guère le choix : abondonner certains aspects de mon travail ou trouver une méthode plus efficace. C'est la que j'ai tenté cette technique.

Ce qui repousse à priori

Le découpage en 25 minutes pardi ! "25 minutes, c'est bien trop court pour faire quoi que ce soit" est la première remarque qui vient à l'esprit. Ensuite le coté stressant de la chose, ce sentiment d'être minuté en permanence. Pas réjouissant. Enfin cet envie de repousser toute pratique qui demande à changer ses habitudes, surtout quand c'est 10 heures par jour... tous les jours.

Un outillage adapté

J'ai commencé par chercher une solution de chronométrage. L'idée d'avoir un chrono "physique" me semblait pas pratique, je ne me voyais pas en train de m'occuper du compteur régulièrement. J'ai donc cherché une version logicielle, fonctionnement bien sûr sous Linux (natif ou web).

Après quelques dizaines de minutes et plusieurs tests non concluants, je suis tombé sur Workrave. D'abord interloqué par la taille de l'engin (presque 7 Mo !), j'ai vite changé d'avis. Simple d'utilisation, il apporte quelques plus dont je n'avais pas imaginé en me lançant dans l'aventure :

• il bloque (option modifiable) le clavier pendant la pause, vous obligeant à vous arrêter. Cela semble ridicule mais quand on accepte difficilement de lâcher le clavier cela aide.
• il affiche des exercices pendant la pause (je vous laisse deviner la tête de mes collègues :).

Les raisons du succès

Mais alors, pourquoi cela marche ? Et bien c'est simple :

• il est difficile de garder sa concentration sur une longue période (les études disent souvent 45 minutes). Vous obliger à prendre une pause régulièrement vous rend plus efficace sur la journée.
• la pause de 5 minutes n'est pas suffisamment longue pour vous rendre inefficace en reprenant le travail. Surtout que cette pause programmée ne vous déconcentre pas car vous arrêtez non pas par fatigue mais par choix. Et oui, en reprenant le travail, vous n'avez rien perdu de votre concentration, il ne faut pas 10 minutes pour reprendre le fil de vos pensées, mais seulement quelques secondes.
• découper votre journée par tranche de 30 minutes ne veut pas dire que vous ne dépassez pas 30 minutes par tâches ! Rien ne vous interdit de passer 2 heures, ou 3, ou 4 ! Mais la, on voit le temps passer. On sait parfaitement que l'on vient de passer 2 heures sur ce foutu rapport car c'est la 4ème pause.
• enfin, un avantage intéressant et non visible au départ et la possibilité de laisser passer un tour. Au mileu d'un travail j'ai envie de faire une pause, par exemple pour répondre à ce mail important ou alors lire Twitter. Au lieu de se sentir coupable de laisser une tâche, je me donne un tour (25 minutes) pour cela, en me disant que je reprendrais le travail aprés. Cela semble un poil stupide, mais ça marche pour moi.

Conclusion

Voila un résumé sur l'avantage que je vois à Pomodoro. Il m'arrive encore d'oublier de lancer l'application le matin en arrivant au travail et je constate la différence. Pour moi c'est dorénavant jamais sans mon Pomodoro.