BodySplash.fr

Je ne l'ai peut-être pas encore assez crié sur tous les toits, mais Tiron est sorti dans sa première version publique. Plus besoin de parler Du Projet, je peux maintenant officiellement l'appeler Tiron, même si le mot avait déjà du m'échapper. Ceci n'est bien entendu pas la fin, finalement en terme de rythme de développement, ça ne change pas grand chose pour nous, modulo bien entendu certaines nouvelles tâches très marranteS comme maintenir le site de présentation, faire le support et déployer la nuit. A ça bien sûr il faut ajouter les joies du marketing et de la communication, car c'est bien d'avoir un bon produit, mais c'est mieux si tout le monde le sait.

Si vous avez suivi un peu ce blog, vous savez sans doute qu'un des objectifs premiers, avant même de penser à une exploitation commerciale, était de mieux nous former à l'agilité, et à XP en particulier. Et oui, il a plus de deux ans maintenant nous n'étions pas les extrémistes que nous sommes aujourd'hui. Même si nous avions déjà acquis un certain nombre de pratiques d'ingénieries, il nous manquait beaucoup du second côté de la pièce : la gestion du projet et la planification. On peut dire que de ce point de vue, l'objectif de Tiron est pleinement atteint. Nous avons non seulement très largement consolidés nos pratiques, mais nous avons également énormément appris sur la planification et la négociation avec le product owner. La particularité bien entendu du rythme de développement était que nous ne travaillons tous ensemble que deux demi-journées par semaine, et ce mode particulier a bien entendu beaucoup influencé Tiron. Tout d'abord, car le temps était très précieux, donc la priorisation par la valeur et toujours faire le plus simple qui fonctionne a été cruciale pour sortir quelque chose dans un temps raisonnable; ensuite nous avions du coup énormément de temps pour réfléchir sur nos décisions, ce qui n'était pas toujours un avantage d'ailleurs. Maintenant que nous avons une démarche commerciale, cette agilité sans concession nous fournit certains avantages sur la concurrence. Nous sommes réactifs, il n'y a moins de gaspillage (globalement toutes les fonctionnalités sont utilisées), et nos coûts de développement et d'exploitation sont inférieures nous permettant de pratiquent un prix plus attractif.

La nouvelle grande difficulté maintenant est que l'équipe est seulement partiellement à temps plein, et synchroniser le travail fait "le soir" et le travail de la journée est assez épineux, sans compter les soucis de rythme soutenable et de diffusion de la connaissance.

Pour conclure, bien sûr nous attendons de voir le succès que va remporter notre logiciel, mais l'agilité est clairement ce qui nous a permis de sortir un produit de qualité, concurrentiel et dans un délais raisonnable par rapport au temps que nous avions. Je pense que c'est un bon début de preuve empirique pour dire que rien n'est utopique, que non l'agilité et XP en particulier ne sont pas un ensemble de pratique ou l'en prend ce que l'on veut : l'agilité fonctionne vraiment à son plein potentiel que par la synergie de l'ensemble de ses pratiques, et bien entendu par les valeurs de ce qui la pratique.

Il y a quelque temps déjà, j'avais écrit un billet concercnant Scrum Vs XP. Peut-être l'avez vous lu, peut-être pas, mais l'essence de ce que je disais alors entre autre, était que je me méfiais de Scrum car il passait sous silence toutes les techniques d'ingénierie en se concentrant sur la gestion de projet. C'était un danger pour moi, car il me semblait, et me semble toujours, qu'il est impossible de réussir un projet agile sans les pratiques d'ingénierie qui vont bien. Comment travailler en itération si à chaque passage on ne fait que grossir la dette technique n'est-ce pas?

Je vous reparle de tout ça car il se trouve que Martin Fowler en parle aujourd'hui . Alors oui je vous link ça car vous vous en doutez, je suis fier d'avoir obtenu les mêmes concluions que Fowler Ceci dit, je vous le fait passer également car j'aime bien montrer que je ne parlais pas dans le vent, et que le phénomène que j'avais anticipé existe réellement. Fowler est plus dans le consensus que moi, et ne démonte pas Scrum. Mais personnellement, je maintiens ce que je disais: pourquoi choisir Scrum quand XP est complet et n'induit pas le risque d'oublier ou le planning ou l'ingénierie?

Sur le blog de Denis Dollfus, on peut trouver un petit test visant à mesurer le niveau d'agilité au sein de votre organisation.

Nous sommes d'accord pour dire que ce test n'est pas exhaustif, mais bon, c'est un commencement. Nous l'avons fait pour juger le niveau d'agilité du Projet, et nous avons obtenu... 100% ingénierie, 100% management.

Ça a tout de même quelque chose de rassurant de voir que nous sommes apparemment sur la bonne voie.

J'imagine que vous en avez entendu parler, c'est le grand buzz ces derniers temps, j'ai nommé donc le "Elastic cloud computing" d'amazon, ou Amazon EC2 pour les intimes. Je suivais l'histoire de loin, sans trop m'y intéresser, mais il se trouve que depuis 2 semaines, je suis amené à "jouer" avec, et je dois dire que je suis vraiment vraiment vraiment impressionné par ce que je découvre. Je pense même pouvoir dire que la plate-forme EC2 est enfin le premier outil agile dans le milieu de la production.

La base

Alors pourquoi une telle déclaration fracassante? Laissez-moi vous introduire aux concepts d'EC2 si vous ne les connaissez pas encore. Je ne vais pas essayer d'expliquer le buzz word qu'est devenu cloud computing, et je vais juste dire que le but d'EC2 est de pouvoir sans friction instancier des serveurs à la volée. Une tâche qui auparavant était incroyablement pénible se voit ici réduit à une banale opération de routine ne prenant que quelques minutes. Oui en un instant il est possible d'avoir un serveur booté et opérationnel. Bien entendu, pour réussir cet exploit, le service s'appuie sur de la virtualisation, et si mes informations sont bonnes il utilise VirtualBox.

Alors Comment ça s'attaque?

Par défaut, pour jouer avec le service, Amazon livre un ensemble d'outils en ligne de commande qui permettent donc de faire toutes les opérations (recherche d'images, création d'images, instanciation, sécurité, assignation d'adresse, fermeture des serveurs etc etc). Il faut avouer que ce n'est pas forcément très sexy, et l'utilisation intensive de clefs ssh plus le fait que les ids générés par Amazon ne sont pas très "users friendly" n'améliorent pas vraiment la chose. Ceci dit, étant donné que pour fonctionner, ces outils appellent juste une api publique exposée via WebService, il n'a pas fallu longtemps pour que quelqu'un ne nous sorte quelque chose de plus fun : ElasticFox. Et alors là les enfants, on rentre vraiment dans une nouvelle dimension. Instancier un serveur se fait en deux clicks. Tout n'est pas encore possible par cet outil, mais pour 90% des tâches, il fait bien le boulot.

Agile nous disons-donc

Alors pourquoi est-ce que je dis que c'est un outil agile? Parce qu'il automatise une tâche jusqu'à alors fastidieuse et la transforme en une opération d'une telle banalité qu'elle se fait oublier. De plus, la politique de facturation du "Pay Per Use" est également un concept lié à l'agilité (on ne paie que ce qu'on consomme). L'outil essaye de s'adapter juste à nos besoins, et ne nous fait payer que ce que nous avons consommé. Dans le genre 0 gaspillage, c'est pas mal.

Limites

Cependant, tout n'est pas merveilleux. Niveau tarification, il faut bien se rendre compte que même si on paie en fonction de notre consommation, il existe un seuil à parti duquel il est plus intéressant de louer un "vrai" serveur. C'est un excellent outil pour absorber des besoins ponctuels sans perdre un rein, mais pour des besoins "fixes", les solutions standards restent moins cher. Si on a besoin pour des questions de redondance d'avoir deux serveurs physiquement différents, Amazon ne peut pas le garantir, on peut très bien avoir instancier deux serveurs sur la même machine sans le savoir.

Enfin, quand Richard Stallman dit quelque chose, j'ai tendance à être plus méfiant

Au détour d'une conversation, un collègue nous a dit qu'il trouvait que Maven n'était pas un outil agile. Je dois avouer que je suis de plus en plus en grand suppprter de maven donc, forcément j'ai été choqué.

La raison évoquée était que quand on veut changer le comportement de base de maven, on rencontre beaucoup trop de résistance. Que ce besoin soit légitime ou pas, le fait est qu'effectivement maven était un frein dans ce cas. Mais l'agilité n'est pas une question d'outil. L'agilité est une question de s'améliorer et de réduires les résistences. Il n'y a pas d'outil magique, de balle d'argent, qui va permettre d'être agile du jour au lendemain. Dans notre cas, Maven a réduit la friction du processus de compilation et de déploiement, tout en nous permettant de gérer de manière plus saine nos dépendances. En gros, ça a été un franc succès, mais seulement je pense car nous avions expérimenté les limites d'Ant. Le grand intérêt de Maven, c'est justement ses conventions qui permettent de s'abstraire de beaucoup de la verbosité d'ant, pour ne parler que de la compilation. Enfin, il ne faut jamais oublier que tenter de tordre un outil ou d'essayer de l'utiliser dans une optique qui n'était pas la sienne n'est jamais une bonne idée.

Cette conclusion est assez conventionnelle, et on peut la lire finalement dans n'importe quel bon article sur l'agilité, mais il est, je trouve, toujours intéressant d'arriver par soit même aux mêmes conclusions.

J'aimerai aborder le sujet de scrum vs XP ici.

Je me bats contre cette vieille légende qui veut que Scrum couvre la gestion de projet, et XP le développement. Alors oui, Scrum ne couvre que la gestion de projet, mais XP couvre tout. Oui, oui, oui et encore oui, XP parle de gestion de projet, la preuve en image là ou là

Scrum je trouve, favorise cette vieille séparation développement/gestion tout en ignorant royalement l'importance de la mise en place de bonnes pratiques. Il se trouve qu'actuellement, je n'ai effectivement pas croisé d'environnement ou Scrum avait était mis en place seul, sans les pratiques issues d'XP pour le développement. Mais dans un futur pas si lointain que ça, quand l'agilité aura été reprise et vendue par des commerciaux ne voyant là qu'une offre de plus, je crains fort que l'importance de cet équilibre ne passe à la trappe. C'est pour cette même raison que le débat existe sur la certification Scrum.

XP est un tout cohérent, convaincu de la nécessité de ne rien délaisser: ni la gestion, ni le développement. De fait, XP me paraît plus agile que ne l'est Scrum. Dans le contexte ou il est encore difficile de vendre l'agilité, certains disent donc que mieux vaut vendre Scrum, la méthode fait moins peur. L'agilité était avant tout un changement radical de la manière d'envisager notre métier, et un ensemble de valeurs fortes, continuer à nourrir les fausses croyances me semble préjudiciable.

Ce que j'ai pu modestement observer jusque là, c'est qu'une adoption complète d' XP donne d'excellents résultats à tous les niveaux: qualité du projet, humeur et efficacité de l'équipe, sérénité globale etc etc; Une adoption par compromis ne donne qu'un sentiment mitigé chez tous les acteurs du projet, qui se demandent alors ou est ce fameux gain tant promis par l'agilité, car la différence n'est du coup, pas vraiment bluffante. La puissance d'XP est dans la synergie de TOUTE ses pratiques.

Pour conclure, ce qui m'attriste le plus dans cette histoire, c'est que nous devrions normalement nous concentrer à essayer de nous améliorer, plutôt que de juger de qui est le plus agile. Cependant, il me semble que ce grand virage vers l'agilité ne peut être entrepris par quelqu'un que s'il a toutes les cartes en main.