Tout d'abord, la parole est gratuite, simple, rapide à mettre en œuvre et fiable, puisqu'à moins d'être victime d'une extinction de voix, il est toujours possible de dialoguer avec autrui.

Et à moins d'une révolution, la mise en place d'un outil informatique, quelque soit sa nature et sa conception, ne sera jamais aussi simple et rapide que le recours à la parole.

Ensuite, la communication est l'un des fondements de l'agilité, à tel point qu'elle transparait à la fois dans la première des valeurs du manifeste agile et qu'elle figure en bonne place parmi ses douze principes.

La première valeur du manifeste agile est en effet la suivante :

Les individus et leurs interactions plus que les processus et les outils.

La communication directe entre l'ensemble des intervenants d'un projet doit donc se faire le plus possible directement, sans passer par un quelconque intermédiaire, qu'il soit procédural, logiciel ou technique.

Parmi les douze valeurs du manifeste figure également ce qui suit :

La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.

En effet, une méthode écrite de l'information prend plus de temps et surtout nécessite d'être maintenue à jour, ce qui dans les faits, est assez rarement, voire jamais, le cas.

Au final, si la communication écrite est utilisée, quelqu'un passe du temps à rédiger un document, temps qu'il ne passe pas à augmenter la valeur du logiciel et donc à satisfaire le client.

De plus, son travail, au bout d'un laps de temps pouvant être extrémement court, n'aura plus aucune valeur car il ne sera plus à jour par rapport au logiciel.

J'ai ainsi connu par le passé le cas de spécifications fonctionnelles qui avait nécessité plusieurs jours de rédaction et qui n'était déjà plus à jour au moment de leur première impression...

J'ajouterais que je vois assez mal l'intérêt de garder une trace écrite des décisions prises, à partir du moment ou la confiance régne dans l'équipe.

Si l'on suppose que chacun fait son travail du mieux qu'il le peut, un document écrit décrivant précisément ce qui doit être fait me semble en effet totalement inutile, chacun sachant dans ce contexte ce qu'il a à faire et comment le faire pour atteindre l'objectif fixé.

De plus, même dans le cas ou la confiance n'est pas la règle, je ne vois aucune valeur ajoutée à un tel document, puisque démontrer que les choses n'auraient pas dut être faites comme elles l'ont été n'a jamais aidé à résoudre un problème.

D'autant plus qu'à mon sens, le code contient toute les informations nécessaires à la bonne compréhension du fonctionnement de l'application.

J'ai même tendance à penser, d'une manière assez extrème je le reconnais, que c'est d'ailleurs la seule source fiable d'informations au sein d'une équipe de développement.

Évidemment, cela suppose que le code soit suffisament clair et compréhensible pour être lu et compris rapidement.

Mais... l'un des moyens pour qu'il le soit n'est il pas justement d'obliger les développeurs à le rendre compréhensible en en faisant l'unique base de connaissance ?

Et en ce qui concerne la réflexion technique et fonctionelle au sein de l'équipe, je préfére de loin une méthode interactive efficace, telle que la méthode des 6 chapeaux, à une suite de courriers électroniques ou une discussion sur une messagerie instantannée, tous deux susceptible de partir dans tous les sens et devenir à la fois impossible à suivre et un nid à trolls.

Ceux qui ont le courage de suivre la liste de diffusion des développeurs de PHP, internals@, comprendront parfaitement ce dont je veux parler...

Attention cependant, cela ne veut pas dire qu'il ne faut rien écrire, bien au contraire.

Il faut juste veiller à le faire rapidement, efficacement et à bon escient en restant suffisament générique pour avoir une vision suffisamment précise de ce qu'il y a à faire sans pour autant perdre trop de temps à préciser les détails.

C'est la raison pour laquelle j'use et j'abuse des Post-It®, ce qui d'ailleurs fait bien rire mes collègues.

Leur surface réduite oblige en effet à aller à l'essentiel et à mettre les détails de côté.

Une image valant mille mots, j'utilise également de plus en plus les mock-up, qui permette de formaliser rapidement une fonctionnalité, mais là encore je prends bien soin de me limiter au strict minimum permettant une compréhension général de l'idée sous-jacente.

Les personnes qui consultent ces éléments sont donc obligées de communiquer au sein de l'équipe, autant pour savoir ce qu'il y a à faire précisément que pour définir comment le faire, et cela uniquement au moment où il faut le faire.

Évidemment, cette étape de communication prend du temps, mais on parle dans ce cas de quelques minutes, là où la rédaction d'un document écrit exhaustif peut demander des heures où des jours, et au final potentiellement ne servir à rien, et dans le pire des cas faire perdre du temps s'il n'est plus à jour.