Crédit photo : USI 2010 flickr.com – Tous droits réservés
Martin Fowler et Neal Ford ouvrent cette deuxième journée de la conférence USI 2010. Deux des plus célèbres des Geeks pour commencer la journée… Avouez que cela vaut le coup non ? Leur présentation nous propose de comprendre non pas comment, mais pourquoi des logiciels fonctionnent… Suivez le guide.
Avant tout, je présente rapidement les deux speakers. Martin Fowler est d’origine anglaise, c’est un geek de 47 ans qui a participé au Manifeste Agile, a co-écrit des livres d’excellentes qualités sur le refactoring avec Kent Beck, et c’est surtout un conférencier de renom. Neal Ford est américain, Geek de 48 ans, passionné par la technologie, auteur de plusieurs livres comme l’excellent « The Productive Programmer« , il travaille aussi chez ThoughtWorks avec Martin Fowler.
Neal Ford débute la présentation en nous apostrophant, afin de nous demander si nous savons pourquoi certains logiciels marchent, pas comment ils marchent. Martin Fowler explique qu’une phrase anglaise célèbre dit : « Plan your work, work your plan« . Cette approche prédictive est intéressante. Un plan est une prédiction de ce que l’on souhaite, plutôt une prévision. Et pour aller plus loin, le succès d’un projet dans ce cas, serait de dire que vous avez respecté votre plan à la lettre. Le succès des projets est défini sur la base d’une prévision. Cette approche prédictive est intéressante dans certains domaines, mais elle doit être discutée lorsque l’on parle de développement logiciel. Elle ne fonctionne que si vous êtes en mesure de préparer un ensemble clair et indiscutable de demandes, et que cet ensemble n’évolue pas dans le temps.
Reconnaissez tout d’abord que c’est difficile. Il est assez difficile de tout prévoir, et de tout planifier. Et ce, d’autant plus que le projet est long.
Martin demande aux chefs de projets qu’il rencontre, si les exigences sont stables. Et c’est plutôt rare. Un sondage dans la salle remplie de près de 500 personnes montre aussi qu’en général, les demandes évoluent ou sont précisées alors que le développement a débuté. Presque personne n’a de demande stables. La communauté de l’approche traditionnelle le sait très bien. Alors ils cherchent à stabiliser et à figer les requierements. Ils mettent un point d’honneur à vous rendre la vie difficile si vous souhaitez changer quelque chose.
Dans le monde Agile, nous savons que le changement est une composante du développement logiciel. Cela nous permet de nous en servir comme d’un avantage, plutôt que de le subir. Nous avons développé des techniques pour absorber le changement, tout en délivrant le logiciel. La première de ces techniques, est de séparer la phase de recueil des exigences, de la phase d’implémentation. Pour parler de Scrum, nous avons une étape de capture des requierements, c’est l’alimentation du Product Backlog. Et nous avons par ailleurs un cycle de développement, qui travaille sur un périmètre stable. Vous voyez que nous avons bien besoin de figer à un moment donné les demandes, mais nous le faisons sur une petite période de 2 à 3 semaines.
How do we do this ?
Nous passons d’une approche prédictive à une approche adaptative. Le secret de l’Agilité c’est que l’on ne peut prévoir tout, mais que par contre on sait s’adapter. D’où ce mot « Agile » finalement. Faire de l’Agile ce n’est pas jeter des plannings. Au contraire, nous serons en mesure de donner un planning chaque semaine. Nous serons en mesure de prédire avec précision les 2 semaines qui arrivent.
Ensuite, pour réussir il ne faut pas uniquement appliquer des méthodes Agiles et penser que cela va réussir. Il faut absolument prendre de bonnes pratiques de programmation. Tests unitaires, intégration continue, refactoring, vous les connaissez tous je pense. Martin propose de relire un papier publié il y a 10 ans, remis au goût du jour en 2004, que chaque Architecte Agile devrait connaître : « Is Design Dead ?« . Faire de l’Agilité ce n’est pas jeter le Design à la poubelle. Au contraire.
Martin Fowler raconte qu’il va parfois dans certaines entreprises qui sont passées d’une approche classique à une approche Agile. Et les projets ne réussissent pas mieux. L’Agilité permet même de se planter plus vite en fait. Il rappelle l’importance des techniques de programmation et de développement telles que celles de l’eXtreme Programming. Faire de l’Agile sans changer sa méthode de travail ne permet pas de réussir mieux. A méditer lorsqu’un consultant de 19 ans de McKissé vous vend de l’Agilité… alors qu’il n’a jamais programmé.
Donc pour résumer cette première partie : passez de l’approche prédictive à l’approche adaptative.
La seconde distinction
Une photo de Taylor nous rappelle qu’au XXe siècle la vision du Taylorisme visait à séparer l’exécution d’une tâche de sa définition. Ecoutez bien ce qui va suivre, moi j’ai adoré. Il y a 100 ans, nous pensions que pour être plus effectif, il fallait que des gens pensent à ce qu’il faut faire, et que d’autres réalisent cette tâche. C’est le métier d’Ingénieur ou d’Architecte, ce métier où tu penses à ce qu’il faut faire. Mais dans le développement informatique, nous avons juste oublié la partie « réalisation », la partie « artisanale ». Et c’est pour cette raison que de très bons scientifiques, en mesure de penser, sont de très mauvais exécutants. Personne ne leur a appris à programmer.
Vous savez pourquoi il faut le faire, mais vous ne savez pas comment faire…
N.Martignole
L’approche traditionnelle du développement logicielle essaye de séparer ceux qui conçoivent de ceux qui réalisent. Cette vision fonctionne si les gens qui réalisent sont prévisibles. S’ils suivent à la lettre le processus standardisé, comme un ouvrier finalement, oui cette approche devrait marcher. Alistair Cockburne explique que les gens ne sont pas prédictibles :
In the title, [of his article] I refer to people as « components ». That is how people are treated in the process / methodology design literature. The mistake in this approach is that « people » are highly variable and non-linear, with unique success and failure modes. Those factors are first-order, not negligible factors. Failure of process and methodology designers to account for them contributes to the sorts of unplanned project trajectories we so often see.
[Alistair Cockburn non-linear]
Dans l’approche traditionnelle, nous pensons que les processus vont nous aider. Cela va plus loin, car certaines approches (Model Driven Architecture) proposent de retirer la possibilité de développer, pour plutôt générer du code. La génération automatique de code permettrait d’économiser du temps. Cette approche essaye de combattre le caractère imprévisible de l’être humain. Générer un logiciel par modélisation c’est mettre un terme au chaos de la programmation classique.
Je pense à titre personnel que l’approche MDA permet de déplacer la complexité, mais qu’elle ne peut pas être une solution pérenne pour développer des projets de bout en bout. Lorsque nous aurons compris que la programmation d’un logiciel complet ne peut pas être automatique, nous aurons fait un grand pas.
Les développeurs sont donc les personnages les plus importants dans le développement logiciel. Or ils ne sont pas prévisibles, il est donc stupide de voir les gens comme des ressources. L’utilisation du jour/homme fait beaucoup de tord à notre industrie. Je connais personnellement des personnes qui font en 1 journée ce que d’autres font en 20 jours. Et je me mets dans les 20 jours. Et inversement, je peux faire des choses en 1 journée qui demanderaient 20 jours à un autre développeur. Nous ne sommes pas égaux devant les problèmes de programmation. Nous ne pouvons donc pas prévoir la fin d’un projet en divisant le nombre de jours par la « quantité de ressources disponibles« . Mettez-vous cela dans le crâne une fois pour toute.
Alors comment cela fonctionne-t-il ? Martin Fowler explique que nous devons prendre un groupe de développeurs, mettre en place quelques règles, puis ensuite s’adapter et faire des rétrospectives afin de progresser. Il est contre-productif d’utiliser des processus et de la standardisation, cela tend à niveler par le bas les niveaux des équipes.
People comes first, and they chosse their own process they follow, not the opposite.
En résumé, Martin Fowler a parlé de l’attitude par rapport au planning, et de l’attitude par rapport aux gens.
Fin de la première partie
Retrouvez la suite de cette KeyNote dans un deuxième article demain
