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.
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?
