Pour introduire le sujet des spécifications agiles, nous allons aborder aujourd'hui un concept nommé la bande passante de communication. Nous verrons ensuite les principales différences entre la validation des spécifications dans un projet traditionnel et dans le cadre d'un projet Agile.
Extrait de la vidéo de formation : Challenge Scrum Master
Dans cette vidéo, nous allons aborder ensemble le sujet des spécifications agiles. Mais juste avant de rentrer dans le vif du sujet, je voudrais partager avec vous un graphique qui nous indique différents moyens de communication. Et entre ces différents moyens de communication, différents niveaux d’efficacité et de richesse. C’est ce que l’on appelle la bande passante de communication.
La bande passante de communication peut être représentée par un graphique où l’on trouve :
Alors quand on part de zéro, le moyen de communication le moins efficace et le moins riche est le papier (communication par lettre, courrier, spécifications).
Ensuite, on va monter un peu dans ce graphique avec le message audio qui nous donne la possibilité d’enregistrer une information et de la transmettre.
On trouve au-dessus la communication entre deux personnes par email. Là aussi on est sur un mode assez dégradé en terme d’efficacité.
Il y a aussi l’enregistrement vidéo qui transmet plus que la voix, c’est donc plus riche. Mais on est encore relativement limité en terme d’efficacité et de richesse.
Alors pourquoi les moyens de communication que nous venons d’évoquer sont limités ? Et bien simplement parce-que ce sont des moyens qui ne permettent pas de poser des questions ou de donner des réponses en direct. On est ici sur un mode de communication totalement asynchrone.
Pour progresser dans l’efficacité et la richesse, on dispose de :
Retenez juste que parfois un dessin vaut beaucoup plus qu’un long discours !
Voilà les éléments qu’il vous faut retenir si vous souhaitez comprendre ce que sont les spécifications dans un projet Agile. Gardez également à l’esprit que dans la méthode Agile, la documentation n’est pas un moyen de communication à elle-seule. Elle doit toujours servir de support ou être le résultat d'une discussion en face à face. Et c’est dans cet esprit là que l’on va essayer d’utiliser la documentation. Cela n’interdit pas de tracer des choses, d’écrire des choses, de faire de la documentation. Mais elle sera toujours le fruit d’un échange le plus direct possible, que l’on aura en face à face ou devant un tableau blanc.
Par conséquent, la validation dans un projet Agile ne porte pas sur les spécifications comme on le ferait dans un projet traditionnel. Dans ce cas, à l’issue de la phase de conception on fait valider de façon rigoureuse les spécifications. Donc cette validation porte un enjeu contractuel.
Ainsi, si par la suite le logiciel ne répond pas exactement à ce qui était indiqué dans la spécification, on peut être en position de force en tant que client, pour négocier une correction ou une amélioration du logiciel.
Inversement, lorsque l’on est fournisseur et que l’on nous demande une modification non contractualisée au moment de la livraison ou de la recette, les spécifications protègent et permettent légitimement de demander un avenant au contrat et donc un budget complémentaire.
Dans un projet Agile, on n'est pas du tout dans ce registre là. L’enjeu de validation porte plutôt sur les fonctionnalités concrètes et utilisables. Ce sont celles qui sortent du sprint dans un projet Scrum, et qui correspondent à un incrément.
Voilà ce que l’on pouvait dire avant de rentrer dans le détail des spécifications Agiles, où je vous apporterai des exemples de la manière dont on va rédiger ces spécifications dans un projet Agiles.
Envie de former vos équipes ? Découvrez le programme de notre session de formation
Une fois par mois, les tendances de la formation en ligne dans votre boîte e-mail