L'Agilitateur Création de logiciels : de l'agilité à l'artisanat

Le 3ème SigmaT s'est tenu vendredi dernier. Comme on pouvait l'espérer la session fut intéressante.

Camille Bloch nous a présenté l'expérience Scrum en cours chez Areva et les satisfactions qu'elle donne même si la route est encore longue. Le point qui m'a le plus marqué est que la quasi totalité de l'équipe de développement a fait le déplacement depuis Montpellier pour accompagner cette présentation : la méthode Scrum porte parfois très bien son nom.

Claude Aubry a évoqué les possibilités de réaliser des contrats au forfait en mode agile. A ma surprise, ce sujet assez polémique n'a que très peu déchaîné les passions. Est-ce que les quelques consommateurs de forfait qui se trouvaient éventuellement dans la salle étaient en fait convaincus que leur approche du forfait avait besoin d'une évolution radicale de leur part ?

Thierry Cros a dégagé la tendance agile du moment avec la montée en puissance de l'aspect globalisant de la gestion de projet (caractérisé par l'adoption de Scrum) par rapport à une approche plus complète telle eXtreme Programming. Certes un bon Scrum est toujours appuyé par les techniques sous-jacentes plus proches des développeurs mais je crains que des gens bien intentionnés se laissent aveugler par les aspects "amélioration de la communication" des méthodes agiles sans toutefois vouloir payer le prix d'une stricte discipline au niveau du développement proprement dit. Gare au retour de baton...

En ce qui me concerne, je me demande si le message sur la conception émergente est réellement passé.
J'ai eu une question qui me laisse penser le contraire. Dans ma présentation, je parle d'abord des méthodes "traditionnelles" de conception où l'on établit d'abord des plans avant de passer au code et au test et je dis, pour résumer, que c'est un peu stupide de vouloir appliquer au logiciel d'aujourd'hui une telle façon de faire : la conception d'un logiciel, c'est l'écriture de son code source. J'essaie ensuite d'illustrer par un exemple où je laisse ma conception être dirigée par les besoins, en classes et en méthodes, émergeant de l'écriture d'un test et du code associé.
Sur ce, on me demande où est le lien entre mon discours sur l'absence de plan et mon exemple où (je le crains) on n'a retenu que l'établissement d'un plan. Peut être qu'à trop montrer que la conception évolue itérativement, on en oublie de mettre en avant l'essentiel : l'intégralité du code est en train d'être écrite. Le fait que l'on puisse conjointement visualiser cela sous forme de diagrammes UML n'est finalement que très secondaire...

Pour ceux que ça intéresse, voici les slides de ma présentation :