On te l'a donnée 2 posts plus haut, pas de notre faute si tu refuses de la prendre... Crois moi, tu peux lire 20 bouquins sur l'agilité, tu auras la même. C'est aussi ton problème, tu t'en tiens au manifeste agile sans t'intéresser à la littérature autour du sujet ou aux méthodes bien concrètes qui implémentent le manifeste agile.
Quand au fait qu'il puisse exister, en matière de gestion de projet logiciel (puisqu'il s'agit quand même de ça), une quelconque définition "universelle" qui n'ait pas été énoncée par un individu ou un groupe, je n'y crois pas. Ou sinon, comment fais-tu pour consulter cette définition ? Tu la demandes au premier pékin que tu croises dans la rue et puisqu'elle est universelle, ça sera la bonne ?
Soit, faisons l'exercice.
La négation de "Nous accordons plus de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive" est :
"Nous accordons autant ou moins de valeur à un logiciel qui fonctionne qu'à une documentation exhaustive".
Ce n'est ni absurde ni faux, cela mène simplement, selon les signataires du manifeste agile, à un taux de succès dégradé (ou un taux d'échec plus important si tu préfères), en termes de respect des délais, des coûts et des fonctionnalités des projets informatiques où l'équipe a adopté cette approche.
En effet, dans chaque phase du développement, on va privilégier l'exhaustivité de la documentation au bon fonctionnement du code qu'on écrit. En cas de délai trop serré pour effectuer les deux activités (et cela arrive souvent dans les projets puisque les estimations de délais effectuées au départ ne sont... que des estimations, voir cette étude), notre principe nous dit qu'on doit écrire la documentation la plus exhaustive possible, quitte à faire des sacrifices sur le périmètre ou la qualité du code. D'où, en sortie, soit des fonctionnalités au rabais ou buggées, soit un non respect des délais ou des coûts si on veut quand même assurer exhaustivité de la doc ET fonctionnalité du code.
Dire qu'on veut un logiciel qui fonctionne ET une documentation exhaustive serait une approche valable si les prévisions de coûts et délais faits en début de projet étaient fiables, or ce n'est pas le cas. Donner la priorité à une tâche plutôt qu'une autre permet d'obtenir ce qui importe le plus au demandeur en cas de retard, d'imprévu technique ou fonctionnel en cours de route et cela arrive très souvent.
Partager