Un bon développeur est un développeur flemmard !

Si vous comptez un jour mettre en place du BDD ou encore du DDD. Mauvaise nouvelle pour vous... C'est vide...

L'idée du ces deux principes, est de basé le métier au centre du développement. Pour cela, il y a plein de framework et outils BDD cucumber, Jbehave, Jnario...
Mais, c'est là que ce trouve, l'erreur fondamental de ceux-ci. L'important, n'est pas d'avoir des tests métier "au vert", mais de prendre le temps de s'assoir et de parler avec la personne connaissant le métier. En Bref et en anglais, "Sit down and talk".

Cela m'a particulièrement marqué récemment lors d'une conférence lors du Mix-IT 2016 où l'un des talker nous à sortir la phrase suivante :

Et ne me parlez pas des framework de BDD. Cette méthodes parlent de communication pas de processus.

Puis, celui-ci continue avec sa propre version de "sit down and talk."

Au final, ces méthodes ne sont qu'un décorum.

Ce ne sont que des boites vides. Il n'y a rien dedans. Juste des boutons...

Note : Étant un fan de Doctor who, je vous conseil d'écouter "The Doctor's Zygon War Speech" / "Sit down and talk" The Zygon Inversion - Doctor Who Series 9 du point de vue de l'agilité avec le docteur entant que coach Agile et le Zygon un responsable qui veux mettre en place une nouvelle méthodologie en place, à la lettre. Vous y trouverez beaucoup de correspondance intéressante.

Alors, pourquoi ces méthodes ont-elles été créé et sont si populaire ?
Je pense que cela est principalement dû au fait que ces méthodologies sont un vecteur de changement. En effet, il est très compliquer de changer les mauvaises habitudes, en particulier, sans nécessité de changement.
Or dans notre métier tout dans être proprement rangé dans une boite. D'un côté, on a la boite BDD, de l'autre on a la boite DDD. Et beaucoup de responsable pensent et affirme :

I see a box with everything i need.

A ceux-ci, je ne peux que leur dire dire ceci :

Respirez un bon coup. Ces méthodes ne sont pas des solutions miracle ou des "Silver bullet".

Et que va-t-il se passer quand ça va déraper ? Car, dans la durée, c'est inévitable, ça va déraper...
Il est fort probable qu'on cherche un coupable, c'est le Product Owner qui n'a pas été assez précis? Ou le développeur trop bête pour comprendre la spécification correctement. Dans tout les cas, la guerre est lancé... jusqu'au moment où les deux parties feront ce qu'il auraient du faire depuis de début "sit down and talk".

A noter, qu'il n'est pas important de savoir qui est dans le vrai et qui ne l'est pas en particulier dans un problème de communication.

Il y a deux éléments importants :

1. "The only way anyone can live in peace, is if they’re prepared to forgive." : Le seul moyen pour que tout le monde vide en paix, est si tout le monde est près à pardonner.
2. "Being wrong fell like being right." : Être dans le faux sent comme être dans le vrai.

Je ferai un billet spécifique à ces deux points bientôt.

Ces deux points sont très important. Car, quelque soit l'origine problème, il est nécessaire que la personne ayant connaissance du problème n'aient pas peur d'exposer le problème.
Si vous demandez à un développeur pourquoi l'application plante. Il vous répondra qu'il pensait qu'il vous répondra qu'il pensait qu'elle ne planterait pas... (En tout cas, que ça ne lui retomberai pas dessus...)
Donc, pas besoin de lui poser cet question. Il sera bien plus utile de "sit down and talk" sur comment résoudre le problème.

C'est pourquoi, si vous comprenez pourquoi ces boites sont vides. Vous n'avez plus besoin des boites en elle-même. Et si vous travaillez avec des personnes qui veulent ces boites. Vous pouvez toujours "sit down and talk" en utilisant la boite comme chaise. Pourquoi apprend-on le BDD et le DDD en pair programming... C'est-ce pour "SIT DOWN AND TALK" !

Voilà, pourquoi le BDD et le DDD sont des boites vides. Mais cela s'applique de manière plus général à la majeur partie des méthodes agiles. Dans le monde de l'agile, il y a d'ailleurs la représentation connu du métro. Je voulais prendre le soin d’identifier ceux qui son en relation avec la communication.

En conclusion, je vous invite à vous s'assoir 5 minutes et parler, au lieu de vous précipité pour prendre le prochain métro de l'Agilité.

Cordialement,
Patrick Kolodziejczyk.

Ps : Je n'ai rien contre les "stand up". Mais, je suis développeur, donc flemmard par nature.

Source :
VIDEO: Peter Capaldi's epic 'Doctor Who' speech about war has the internet talking
http://guide.agilealliance.org/subway.html( Trouvé ici : ReferencesAgiles)