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.
8 réactions
1 De Cyrano - 23/12/2011, 08:23
Intéressant, sauf que j'accroche sévèrement sur un point particulier :
« 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... »
En d'autres termes, je traduis ça par « le client ne sait pas ce qu'il veut ... »
Je m'explique : tu me corrigeras si je fais fausse route, mais en faisant usage des méthodes agiles, il doit y avoir une implication importante de l'utilisateur/client qui affecte un interlocuteur privilégié dans l'élaboration et la mise au point de son application, interlocuteur qui sera le référent pour les développeurs. C'est à lui que revient de définir les règles de gestion et ces spécifications fonctionnelles. Supposons un instant que dans le cas que tu cites elles n'aient pas été écrites et que l'équipe de développement se soit attelée à la tâche : dans le délai qu'a pris la rédaction jusqu'au moment où le contenu s'est révélé obsolète, les développeurs auraient pratiquement bossé pour rien, la conclusion logique est qu'il aurait fallu recommencer le boulot. Du coup, écrire ou ne pas écrire les spécifications n'aurait pas changé grand chose en terme de délai.
Par ailleurs, un document écrit et validé par le client est une forme de contrat : même si la plus grande confiance règne dans l'équipe de développement, est-ce que ce n'est pas sur elle que risque d'être retournée la « faute » si finalement ce qui a été développé ne correspond plus au besoin ? Si on a une trace écrite, on garantit l'équipe de développement contre un possible client indélicat, et j'ai un peu de mal à croire que tous les clients font preuve d'une probité intellectuelle au dessus de ce genre de considérations.
J'en arrive à me demander si il ne conviendrait pas de préciser dans quelles phases d'un développement les écrits sont ou non indispensables ou parfaitement superflus... et dans ce cas, ton article mériterait peut-être un complément sur ce point ?
2 De mageekguy - 23/12/2011, 08:32
@Cyrano : Le développement itératif existe dans l'agilité pour palier à l'effet tunnel que tu décris.
Durant l'intervalle de temps qu'il a fallu pour rédiger les spécifications, l'équipe aurait eu le temps de faire au moins 2 sprints et aurait pu ajuster le tir en cours de route à moindre coût.
Et surtout, le logiciel existerait puisque du code aurait été écrit, alors qu'à l'issue du temps dédié à la rédaction des spécifications, le client n'avait absolument rien de tangible.
Quand à la garantie juridique apportée par le document écrit, elle sort complètement du cadre de ce billet complètement centré sur l'aspect technique et non sur l'aspect juridico-commercial, et cela le restera car ce dernier domaine est clairement hors de mon domaine de compétence.
Mais de toute façon, je ne suis pas convaincu qu'un cahier des charges fonctionnels non lu par le client (tu connais vraiment un client qui va se taper 100 pages de spécification technique dans leur intégralité et dans les détails ?) et non maintenu permette d'offrir un slip en titane à chacun des membres d'une équipe de développement.
J'ajouterais que le client est censé faire parti de l'équipe de développement, et qu'en conséquence, il faut tout autant lui faire confiance qu'à un développeur, et que commencer par tout mettre en œuvre pour couvrir ses fesses grâce à la rédaction d'un document écrit n'est pas la meilleure façon de montrer sa confiance (oui, je sais, je vis au pays des bisounours, mais cela ne veut pas dire qu'il ne faut pas essayer de faire bouger les choses).
Les questions "comment contractualiser l'agile ?" en général et du "comment contractualiser un développement ?" en particulier sont récurrentes et n'ont pas, à ma connaissance, reçues de réponse satisfaisante.
3 De Nicolas Laforêt - 23/12/2011, 10:55
Je trouve quelques idées un peu utopistes, et je rejoindrais Cyrano sur sa vision.
En effet, il est simple de répondre "Il faut faire confiance au client, il fait partie de l'équipe" ... un client reste un client, si quelque chose merde il ne laissera pas sa direction lui taper dessus il fera le passe plat vers le prestataire. Et sans écrit, voilà le beau bordel qui se profile a l'horizon ....
"Quand à la garantie juridique apportée par le document écrit, elle sort complètement du cadre de ce billet complètement centré sur l'aspect technique et non sur l'aspect juridico-commercial, et cela le restera car ce dernier domaine est clairement hors de mon domaine de compétence."
Idem ... tu ne résous pas le problème évoqué par Cyrano en disant "c'est pas le sujet, c'est pas dans mes compétences" car malheureusement, c'est une chose faisant partie d'un projet, au delà de l'aspect technique. Et c'est un aspect primordial, qui doit être pris en compte dans la gestion d'un projet.
Au niveau des spec tu indique qu'un client qui lit 100 pages des specs, ne les comprends pas. J’adhère a 100%, et justement, moi je faisais une lecture conjointe des specs fonctionnelles et la oui, la parole a de l’intérêt en effet, mais la formalisation par l'écrit est selon moi obligatoire.
Après pour indiquer a quelqu'un dans l'équipe, que le bouton-tout-rouge-en-bas-a-droite doit lancer le traitement-de-la-mort-qui-tue ... c'est clair qu'il n'y a pas forcement besoin d'écrire un mail, cela va de soit.
Et puis d'une même manière, une équipe de TMA qui reprends ton projet pour en assurer le suivis par la suite, voilà a nouveau le beau bordel s'ils n'ont quasi aucune doc de suivis ... car non, tu ne seras pas toujours la pour leur expliquer de vive voix, ou non, dans 1ans tu ne te souviendras surement plus que le bouton-tout-rouge-en-bas-a-droite lance certe le traitement-de-la-mort-qui-tue mais aussi un reboot du serveur pour assurer le processus-a-la-con-que-personne-se-rappelle .... exemple a la con, mais tellement réaliste ....
Bref ta prise de position est trop extrémiste pour le coup.
4 De Jean-Marc Fontaine - 23/12/2011, 12:53
Il me semblait que la parole était d'argent et que c'était le silence qui était d'or.
Ton article est intéressant mais quid du facteur bus (cf. https://en.wikipedia.org/wiki/Bus_f...) ?
5 De Cyrano - 23/12/2011, 17:11
Je ne faisais pas vraiment référence aux spécifications techniques mais aux spécifications fonctionnelles : Les techniques relèvent bien entendu du développeur, mais le fonctionnel, c'est au client de le définir, après tout, est-ce que ce n'est pas son outil qu'on va construire. Qu'on l'assiste dans sa rédaction, je peux le concevoir bien volontiers, mais il n'en demeure pas moins qu'il en est totalement responsable. Il lui revient à tout le moins de préparer au moins un squelette de base qui sera le fondement de l'analyse qui aboutira aux spécifications techniques et au développement par la suite : non ?
Je suis bien conscient du coté rébarbatif de ce genre de rédaction. Mais le développeur ne maitrise pas toujours, pour ne pas dire jamais, le métier de son client, il ne saura pas forcément prendre en compte certains détails au moment de construire son code si l'utilisateur final ne le lui précise pas clairement. Or, une application peut être particulièrement complexe, ce qui implique un nombre de détails qui peut devenir conséquent : comment se passer d'écrit quand le nombre des spécifications augmentent avec cette complexité ? Personne ne peut tout retenir, et se limiter à la simple version verbale expose l'équipe à des oublis qui pourraient être fâcheux pour l'utilisateur.
Après, au niveau technique, je ne contesterai certes pas la méthode que tu préconises ici, je ne suis absolument pas en mesure d'y opposer un quelconque argument, travaillant moi-même en solo et donc n'ayant pas à gérer cette question. Est-ce que ça peut aussi dépendre du type d'application qu'on a à construire ?
6 De mageekguy - 25/12/2011, 21:24
@Nicolas Laforêt : Avoir un document commercial/juridique/contractuel ne me pose aucun problème, d'autant que ce n'est pas mon problème de l'obtenir et/ou de le rédiger, car encore une fois, la contractualisation n'est clairement pas de ma compétence.
Et encore une fois, je ne connais personne qui a une solution satisfaisante pour toutes les parties, et j'ai assez d'expérience pour savoir que le document contractuel signé entre les parties n'a au final aucune utilité et que le litige se règle à l'aide d'une signature sur un chèque.
Quand à la formalisation par l'écrit, si tu développes par itération courte et que le client est impliqué dans le développement, elle devient totalement inutile.
Quand à la TMA, si le code est compréhensible, elle n'a aucun problème.
Et oui je suis un extrémisme, si tu suis ce blog depuis un moment, tu devrais l'avoir compris.
Et non, ce n'est pas une vision utopiste, puisque j'en suis à la quatrième société qui fonctionne dans ce mode sans le moindre problème.
Et même si elle était utopiste, ce n'est pas une raison pour ne pas en rêver et faire en sorte qu'elle devienne une réalité.
7 De mageekguy - 25/12/2011, 21:35
@Jean-Marc Fontaine : Pour une fois tu n'aurais pas saisi l'humour de l'un de mes titres ?
Sinon, vu que la communication orale oblige à la communication entre les membres de l'équipe, via le binômage, la réunion quotidienne, les rétrospectives et la vie quotidienne du développement, le code n'appartient plus à un seul homme et l'on parle alors de propriété collective du code.
Le facteur bus ne peut pas avoir une influence négative sur le projet.
8 De mageekguy - 25/12/2011, 21:40
@Cyrano : Par expérience, le client ne sait pas ce qu'il veut. Mais alors vraiment pas.
De fait, perdre du temps à rédiger des spécifications fonctionnelles complètes avant même le début du projet est totalement inutile et il vaut bien mieux faire des itérations courtes pour développer des blocs fonctionnels très réduits qui pourront être adapté à moindre coût en fonction des retours du client.
Et en cas d'applications complexes, il suffit d'itérer finement pour augmenter progressivement la complexité.
Les détails seront alors sauvegardés dans le code à chaque étape du développement.
Enfin, je ne pense pas que le type d'application est une quelconque importance.
Par contre, je suis convaincu que l'investissement du client et une confiance réciproque à la fois entre les développeurs et entre les développeurs et le client est la condition indispensable à la réussite d'un projet.